Web application firewall per le reti Azure

Web application firewall di Azure (WAF) protegge le applicazioni Web da attacchi comuni a livello HTTP, come SQL injection, cross-site scripting (XSS) e path traversal. A differenza di Firewall di Azure, che controlla il traffico a livelli da 3 a 7 per le minacce a livello di rete, WAF opera solo al livello 7 e comprende la semantica HTTP, incluse le intestazioni delle richieste, le stringhe di query, i corpi delle richieste e i cookie. Distribuisci WAF come criterio associato ad gateway applicazione di Azure (regionale) o ad Frontdoor di Azure (edge globale) per allineare l'ambito di protezione all'architettura dell'applicazione.

Informazioni su questo articolo

Questo articolo illustra la protezione a livello HTTP usando Web application firewall di Azure. Vengono fornite informazioni su:

• Confronto di piattaforme tra WAF in Gateway applicazione v2 e WAF in Frontdoor di Azure.
• Set di regole basati su OWASP, inclusi il set di regole predefinito (DRS) e il set di regole di base (CRS).
• Modalità di rilevamento e modalità prevenzione e quando usare ognuna di esse.
• Opzioni di ambito dei criteri WAF: associazioni globali, per sito e per listener.
• Regole personalizzate per la limitazione della frequenza, il filtro geografico e la logica specifica dell'applicazione.
• La distinzione tra WAF (HTTP di livello 7) e Firewall di Azure (rete layer 3-7).

Chi ha bisogno di questo articolo

Distribuire WAF quando i carichi di lavoro soddisfano uno o più dei criteri seguenti:

• Applicazioni Web pubbliche: Le applicazioni accettano il traffico HTTP/HTTPS in ingresso da Internet, esponendole alle vulnerabilità top 10 di OWASP, inclusi attacchi di inserimento, abusi di autenticazione interrotti e tentativi di esposizione dei dati sensibili.
• Requisiti di conformità: I framework normativi come PCI DSS (Payment Card Industry Data Security Standard) impongono un web application firewall davanti a qualsiasi applicazione che elabora i dati delle carte di pagamento.
• Protezione API: Le API sono accessibili pubblicamente e richiedono protezione contro il contrabbando di richieste, payload sovradimensionati e attacchi a livello di protocollo che i firewall di rete non controllano.
• Mitigazione bot: È necessario classificare e controllare il traffico automatizzato, bloccando i bot dannosi, consentendo al contempo i crawler legittimi e i servizi di monitoraggio.

Le organizzazioni che necessitano solo del filtraggio del traffico a livello di rete (IP, porta e protocollo), senza ispezione delle richieste HTTP, dovrebbero invece usare Firewall di Azure o gruppi di sicurezza di rete.

confronto tra piattaforme WAF Azure

Azure WAF è disponibile su due piattaforme. Ogni piattaforma integra l'ispezione WAF in un punto diverso nel flusso del traffico.

Come scegliere la piattaforma WAF

Usare i criteri decisionali seguenti:

• Scegli WAF su Application Gateway quando l'applicazione è distribuita in un'unica area geografica e utilizzi già Application Gateway per il bilanciamento del carico di livello 7, la terminazione TLS o il routing basato sul percorso. WAF aggiunge l'ispezione HTTP in linea senza introdurre un passaggio di servizio aggiuntivo.
• Scegliere WAF in Frontdoor di Azure quando l'applicazione si estende su più aree, richiede il bilanciamento del carico globale o vantaggi derivanti dall'accelerazione della rete per la distribuzione di contenuti (RETE CDN). Frontdoor WAF ispeziona il traffico nel punto di presenza perimetrale (PoP) più vicino. Il servizio blocca le richieste dannose prima di attraversare il backbone Azure per raggiungere l'origine. Questo approccio riduce l'esposizione della superficie di attacco e assorbe gli attacchi volumetrici di livello 7 all'edge.
• Scegliere entrambi (a più livelli) quando un'applicazione multiregione gestita da Frontdoor richiede anche criteri WAF a livello di area che differiscono per ogni back-end. Front Door offre una protezione globale di primo livello, mentre il WAF di Application Gateway applica regole personalizzate specifiche della regione più vicino al carico di lavoro.

Considerazioni relative alla progettazione

Prerequisiti

Prima di distribuire Web application firewall di Azure, assicurarsi di disporre di:

• Gateway applicazione v2 o risorsa Frontdoor di Azure: WAF viene distribuito come criterio associato a una di queste piattaforme. È necessario disporre di un'istanza di Application Gateway v2 esistente o di un profilo di Frontdoor di Azure di cui è già stato effettuato il provisioning prima di creare e associare un criterio WAF.
• Carico di lavoro HTTP/HTTPS esposto pubblicamente: L'applicazione deve ricevere traffico HTTP/HTTPS in ingresso. WAF esamina la semantica a livello di richiesta e non offre alcun vantaggio per carichi di lavoro non HTTP o servizi puramente interni.
• Informazioni sui modelli di traffico HTTP: La familiarità con i normali modelli di richiesta dell'applicazione (intestazioni, parametri di query e contenuto del corpo) consente di configurare le esclusioni e ottimizzare le regole per ridurre al minimo i falsi positivi durante la transizione in modalità rilevamento-prevenzione.

Set di regole ed elaborazione delle regole

WAF usa set di regole per rilevare modelli dannosi nelle richieste HTTP. La comprensione della gerarchia delle regole e dell'ordine di elaborazione consente di ottimizzare WAF per le applicazioni specifiche.

Set di regole gestite

Microsoft gestisce i set di regole gestite in base ai modelli CRS (OWASP Core Rule Set). Il set di regole consigliato per le nuove distribuzioni è DRS 2.2 (set di regole predefinito). DRS 2.2 si basa su OWASP CRS 3.3.4 e aggiunge le firme Microsoft di intelligence sulle minacce.

I set di regole DRS e CRS utilizzano il punteggio di anomalia. Ogni regola corrispondente contribuisce a un punteggio invece di bloccare immediatamente la richiesta. Quando il punteggio di anomalia cumulativo supera una soglia configurabile, il WAF esegue un'azione (blocco o log). Questo approccio riduce i falsi positivi rispetto al blocco basato su singole regole, perché una singola corrispondenza a bassa attendibilità non fa scattare l'applicazione.

Regole personalizzate

Le regole personalizzate vengono eseguite prima delle regole gestite e usano i numeri di priorità per controllare l'ordine di valutazione (numero inferiore = priorità più alta). Usare regole personalizzate per:

• Limitazione della frequenza delle richieste: Limitare le richieste provenienti da ciascun indirizzo IP client nell’arco di un determinato intervallo di tempo per mitigare gli attacchi di credential stuffing e di forza bruta.
• Filtro geografico: Consentire o negare il traffico in base al paese o all'area geografica del client di origine.
• Elenchi di indirizzi IP consentiti e elenchi di rifiuto: Consentire indirizzi IP partner noti o bloccare gli attori non autorizzati noti prima della valutazione delle regole gestite.
• Ispezione dell'intestazione della richiesta: Far rispettare requisiti specifici dell'applicazione, ad esempio chiavi API obbligatorie o tipi di contenuto previsti.

Set di regole di protezione bot

Entrambe le piattaforme offrono un set di regole di protezione bot che classifica il traffico automatizzato in bot validi (motori di ricerca verificati), bot non validi (scanner dannosi noti) e bot sconosciuti. Configurare le azioni per ogni categoria: consentire bot validi, bloccare bot non validi e sfidare bot sconosciuti con limitazione della frequenza o CAPTCHA.

Modalità di rilevamento e modalità prevenzione

I criteri WAF operano in una delle due modalità che determinano il modo in cui il sistema gestisce le richieste corrispondenti:

Flusso di lavoro di ottimizzazione consigliato

1. Distribuisci in modalità di rilevamento: Abilita WAF con il set di regole selezionato nella modalità di rilevamento. Instradare il traffico di produzione tramite il WAF.
2. Analizzare i log: Esaminare i log WAF per identificare i falsi positivi. Determinare le regole che attivano il traffico legittimo dell'applicazione.
3. Crea esclusioni: Per le regole che generano falsi positivi, definisci esclusioni che specificano i campi della richiesta (intestazioni, cookie e parametri di query) da ignorare per regole specifiche.
4. Passare alla modalità prevenzione: Dopo 1-2 settimane di log di rilevamento puliti con percentuali di falsi positivi accettabili, passare alla modalità prevenzione per il blocco attivo.
5. Monitoraggio continuo: Continuare a monitorare i log dopo il passaggio alla modalità prevenzione. Le nuove funzionalità dell'applicazione o le modifiche all'API possono introdurre nuovi modelli falsi positivi.

Ambito di applicazione e associazione del criterio WAF

Un criterio WAF è una risorsa Azure autonoma che contiene la selezione della modalità, la configurazione del set di regole, le regole personalizzate e le esclusioni. Associare il criterio a uno o più target per definire l'ambito di protezione.

Ambito del criterio WAF di Application Gateway

In Application Gateway, associare un criterio WAF a tre livelli di granularità:

• Globale (a livello dell’intero gateway): Il criterio si applica a tutti i listener e alle regole di percorso in Application Gateway. Usare l'ambito globale quando tutte le applicazioni dietro il gateway condividono gli stessi requisiti di protezione.
• Livello di listener: Un criterio WAF diverso si applica a un listener specifico (combinazione nome host e porta). Usare l'ambito a livello di listener quando più applicazioni condividono un gateway, ma necessitano di diverse esclusioni o ottimizzazione delle regole.
• Livello della regola di percorso: Un criterio WAF si applica a una regola di percorso URL specifica all'interno di un listener. Utilizza l'ambito delle regole basate sul percorso per un controllo granulare sulle applicazioni con diversi livelli di sensibilità del back-end.

Quando più ambiti si applicano a una singola richiesta, il criterio più specifico ha la precedenza: la regola del percorso ha la precedenza su quella a livello di listener, che a sua volta ha la precedenza su quella globale.

Ambito dei criteri WAF di Frontdoor

In Frontdoor i criteri WAF vengono associati a livello di endpoint o route. Ogni endpoint di Front Door può avere un proprio criterio WAF. Questo approccio abilita i profili di protezione specifici dell'applicazione all'interno di una singola istanza di Frontdoor.

Condivisione dei criteri tra le risorse

Condividi un singolo criterio WAF tra più istanze di Application Gateway o endpoint di Front Door. Gestione firewall di Azure offre visibilità e gestione centralizzate in tutti i criteri WAF, indipendentemente dalla piattaforma. Usare i criteri condivisi quando più risorse richiedono una protezione identica per semplificare la gestione e mantenere un comportamento di sicurezza coerente.

Distinzione da Firewall di Azure

WAF e Firewall di Azure proteggono diversi livelli dello stack di rete e svolgono ruoli complementari. Implementarli entrambi per una difesa in profondità.

Usare WAF per la protezione delle applicazioni HTTP e Firewall di Azure per l'ispezione centralizzata del traffico di rete. In un'architettura hub-and-spoke, il traffico proveniente da Internet verso un'applicazione web passa in genere attraverso Firewall di Azure (per DNAT e l'ispezione a livello di rete) e quindi attraverso Application Gateway con WAF (per l'ispezione a livello HTTP). Vedere Firewall di Azure e ispezione del traffico per il componente a livello di rete.

Considerazioni relative alla sicurezza

Le procedure di sicurezza seguenti consentono di ottenere la massima protezione da WAF:

• Modalità di prevenzione per la produzione: non lasciare mai carichi di lavoro di produzione in modalità di rilevamento. La modalità di rilevamento offre visibilità, ma nessuna imposizione, lasciando le applicazioni esposte agli attacchi.
• L'ottimizzazione delle regole è in corso: Le applicazioni si evolvono. I nuovi endpoint API, i parametri e i tipi di contenuto possono generare falsi positivi nei set di regole esistenti. Controlla regolarmente i log WAF dopo i rilasci.
• integrazione Log Analytics: inviare i log di diagnostica WAF a un'area di lavoro Log Analytics. Usa la cartella di lavoro WAF per visualizzare le richieste bloccate, le regole attivate e la distribuzione dei punteggi di anomalia.
• DDoS e WAF insieme: WAF protegge dagli attacchi dell'applicazione di livello 7, ma non attenua gli attacchi DDoS a livello di rete tridimensionale. Abbina WAF a Azure DDoS Protection per una copertura completa dell'intero stack.
• Blocco dell'origine: Quando si utilizza Frontdoor WAF, configurare l'origine in modo che accetti traffico solo dal tag di servizio Frontdoor. Senza il blocco dell'origine, gli utenti malintenzionati possono ignorare Frontdoor e inviare richieste direttamente all'indirizzo IP di origine.
• Protezione dei dati sensibili: I log WAF possono contenere dati di richiesta. Configura le regole di ripulitura dei log per mascherare i campi sensibili (header di autorizzazione, cookie o contenuto del corpo della richiesta) nei log di diagnostica di WAF.

Articoli correlati

Gli articoli seguenti trattano gli argomenti correlati relativi alla sicurezza della rete:

• Ingresso e routing del traffico Internet: modelli di ingresso per applicazioni pubbliche.
• Servizi di distribuzione delle applicazioni: Application Gateway e Front Door quali piattaforme di distribuzione.
• Firewall di Azure e ispezione del traffico: ispezione a livello di rete che integra la protezione WAF Layer 7.
• Protezione DDoS: protezione dagli attacchi volumetrici per gli indirizzi IP pubblici.

Ulteriori informazioni

• Panoramica di Web application firewall di Azure
• WAF nel gateway applicazione
• WAF in Frontdoor di Azure
• Panoramica dei criteri WAF
• Gruppi di regole CRS e regole del Web application firewall
• Ottimizzazione Web application firewall per Frontdoor di Azure

Passaggi successivi