Firewall e gateway applicazione per le reti virtuali

Per proteggere i carichi di lavoro delle applicazioni di Azure, è consigliabile usare misure di protezione, ad esempio l'autenticazione e la crittografia, nelle applicazioni stesse. È anche possibile aggiungere livelli di sicurezza alle reti virtuali che ospitano le applicazioni. Questi livelli di sicurezza proteggono i flussi in ingresso dell'applicazione dall'utilizzo imprevisto. Limitano anche i flussi in uscita a Internet solo agli endpoint richiesti dall'applicazione. Questo articolo descrive rete virtuale di Azure servizi di sicurezza come Protezione DDoS di Azure, Firewall di Azure e gateway applicazione di Azure, quando usare ogni servizio e opzioni di progettazione di rete che combinano entrambi.

• Protezione DDoS di Azure, combinata con le procedure consigliate per la progettazione delle applicazioni, fornisce funzionalità avanzate di mitigazione DDoS per offrire maggiore difesa dagli attacchi DDoS. È consigliabile abilitare protezione DDOS di Azure in qualsiasi rete virtuale perimetrale.
• firewall di Azure è un firewall di nuova generazione gestito che offre NAT (Network Address Translation). Firewall di Azure basa il filtro dei pacchetti sugli indirizzi IP (Internet Protocol) e sulle porte TCP/UDP (Transmission Control Protocol) e sulle porte TCP/UDP (Transmission Control Protocol) o su attributi SQL basati su applicazioni. Firewall di Azure applica anche l'intelligence sulle minacce Microsoft per identificare gli indirizzi IP dannosi. Per altre informazioni, vedere la documentazione di Firewall di Azure .
• firewall di Azure Premium include tutte le funzionalità di Firewall di Azure Standard e altre funzionalità, ad esempio l'ispezione TLS e il rilevamento delle intrusioni e il sistema di protezione (IDPS).
• il gateway applicazione di Azure è un servizio di bilanciamento del carico del traffico Web gestito e un proxy inverso completo HTTP(S) in grado di eseguire la crittografia e la decrittografia ssl (Secure Socket Layer). Il gateway applicazione mantiene l'indirizzo IP client originale in un'intestazione HTTP X-Forwarded-For. Il gateway applicazione usa anche web application firewall per esaminare il traffico Web e rilevare gli attacchi a livello HTTP. Per altre informazioni, vedere la documentazione del gateway applicazione .
• web application firewall (WAF) di Azure è un'aggiunta facoltativa al gateway applicazione di Azure. Fornisce l'ispezione delle richieste HTTP e impedisce attacchi dannosi a livello Web, ad esempio SQL Injection o scripting intersito. Per altre informazioni, vedere la documentazione di web application firewall .

Questi servizi di Azure sono complementari. Uno o l'altro può essere migliore per i carichi di lavoro oppure usarli insieme per una protezione ottimale sia a livello di rete che di applicazione. Usare l'albero delle decisioni seguente e gli esempi in questo articolo per determinare l'opzione di sicurezza migliore per la rete virtuale dell'applicazione.

Firewall di Azure e gateway applicazione di Azure usano tecnologie diverse e supportano la protezione diretta di flussi diversi:

A seconda dei flussi di rete richiesti da un'applicazione, la progettazione può essere diversa per ogni applicazione. Il diagramma seguente offre un albero delle decisioni semplificato che consente di scegliere l'approccio consigliato per un'applicazione. La decisione dipende dal fatto che l'applicazione venga pubblicata tramite HTTP(S) o un altro protocollo:

Questo articolo illustra le progettazioni ampiamente consigliate dal grafico di flusso e altre applicabili in scenari meno comuni:

• firewall di Azure da solo, quando non sono presenti applicazioni Web nella rete virtuale. Controlla sia il traffico in ingresso verso le applicazioni che il traffico in uscita.
• gateway applicazione da solo, quando solo le applicazioni Web si trovano nella rete virtuale e gruppi di sicurezza di rete (NSG) forniscono filtri di output sufficienti. Le funzionalità fornite da Firewall di Azure possono impedire molti scenari di attacco, ad esempio esfiltrazione dei dati, IDPS e così via. A causa di questo motivo, lo scenario da solo del gateway applicazione non è in genere consigliato e quindi non è documentato e non è presente nel grafico di flusso precedente.
• Firewall di Azure e il gateway applicazione in parallelo, uno dei progetti più comuni. Usare questa combinazione quando si vuole che il gateway applicazione di Azure protegga le applicazioni HTTP(S) da attacchi Web e Firewall di Azure per proteggere tutti gli altri carichi di lavoro e filtrare il traffico in uscita.
• gateway applicazione davanti a Firewall di Azure, quando si vuole che Firewall di Azure controlli tutto il traffico, WAF per proteggere il traffico Web e l'applicazione per conoscere l'indirizzo IP di origine del client. Con l'ispezione di Firewall di Azure Premium e TLS, questa progettazione supporta anche lo scenario SSL end-to-end.
• Firewall di Azure davanti al gateway applicazione, quando si vuole che Firewall di Azure controlli e filtrare il traffico prima di raggiungere il gateway applicazione. Poiché Firewall di Azure non decrittografa il traffico HTTPS, la funzionalità che aggiunge al gateway applicazione è limitata. Questo scenario non è documentato nel grafico di flusso precedente.

Nell'ultima parte di questo articolo vengono descritte le varianti delle progettazioni fondamentali precedenti. Queste varianti includono:

• client di applicazioni locali.
• le reti hub-spoke.
• implementazioni del servizio Azure Kubernetes.

È possibile aggiungere altri servizi proxy inversi, ad esempio un gateway di Gestione API o Frontdoor di Azure. In alternativa, è possibile sostituire le risorse di Azure con appliance virtuali di rete di terze parti .

Solo Firewall di Azure

Se nella rete virtuale non sono presenti carichi di lavoro basati sul Web che possono trarre vantaggio da WAF, è possibile usare solo Firewall di Azure. La progettazione in questo caso è semplice, ma la revisione del flusso di pacchetti consentirà di comprendere progetti più complessi. In questa progettazione tutto il traffico in ingresso viene inviato a Firewall di Azure tramite route definite dall'utente (UDR) per le connessioni da reti virtuali locali o altre reti virtuali di Azure. Viene indirizzato all'indirizzo IP pubblico di Firewall di Azure per le connessioni da Internet pubblico, come illustrato nel diagramma seguente. Il traffico in uscita dalle reti virtuali di Azure viene inviato al firewall tramite route definite dall'utente, come illustrato nella finestra di dialogo seguente.

La tabella seguente riepiloga i flussi di traffico per questo scenario:

Firewall di Azure non esamina il traffico HTTP(S) in ingresso. Ma sarà in grado di applicare le regole di livello 3 & livello 4 e le regole dell'applicazione basate su FQDN. Firewall di Azure esamina il traffico HTTP(S) in uscita a seconda del livello firewall di Azure e se si configura l'ispezione TLS:

• Firewall di Azure Standard esamina solo gli attributi di livello 3 & livello 4 dei pacchetti nelle regole di rete e l'intestazione HTTP host nelle regole dell'applicazione.
• Firewall di Azure Premium aggiunge funzionalità come l'ispezione di altre intestazioni HTTP (ad esempio il User-Agent) e l'abilitazione dell'ispezione TLS per l'analisi più approfondita dei pacchetti. Firewall di Azure non equivale a un web application firewall. Se nella rete virtuale sono presenti carichi di lavoro Web, è consigliabile usare WAF.

L'esempio di descrizione dettagliata dei pacchetti seguente illustra come un client accede a un'applicazione ospitata da una macchina virtuale dalla rete Internet pubblica. Il diagramma include una sola macchina virtuale per semplicità. Per una maggiore disponibilità e scalabilità, è necessario avere più istanze dell'applicazione dietro un servizio di bilanciamento del carico. In questa progettazione Firewall di Azure controlla sia le connessioni in ingresso dalla rete Internet pubblica che le connessioni in uscita dalla macchina virtuale della subnet dell'applicazione usando la route definita dall'utente.

• Il servizio Firewall di Azure distribuisce diverse istanze, qui con l'indirizzo IP front-end 192.168.100.4 e gli indirizzi interni compresi nell'intervallo 192.168.100.0/26. Queste singole istanze sono in genere invisibili all'amministratore di Azure. Ma notare la differenza è utile in alcuni casi, ad esempio per la risoluzione dei problemi di rete.
• Se il traffico proviene da una rete privata virtuale locale (VPN) o gateway azure ExpressRoute anziché da Internet, il client avvia la connessione all'indirizzo IP della macchina virtuale. Non avvia la connessione all'indirizzo IP del firewall e il firewall non esegue NAT di origine per impostazione predefinita.

Architettura

Il diagramma seguente illustra il flusso del traffico presupponendo che l'indirizzo IP dell'istanza sia 192.168.100.7.

Flusso di lavoro

1. Il client avvia la connessione all'indirizzo IP pubblico di Firewall di Azure:
   • Indirizzo IP di origine: ClientPIP
   • Indirizzo IP di destinazione: AzFwPIP
2. La richiesta all'indirizzo IP pubblico di Firewall di Azure viene distribuita a un'istanza back-end del firewall, in questo caso 192.168.100.7. La regola NAT (DNAT) del firewall di Azure converte l'indirizzo IP di destinazione nell'indirizzo IP dell'applicazione all'interno della rete virtuale. Il firewall di Azure anche le SNAT (Source NATs) il pacchetto se esegue DNAT. Per altre informazioni, vedere problemi noti di Firewall di Azure. La macchina virtuale vede gli indirizzi IP seguenti nel pacchetto in ingresso:
   • Indirizzo IP di origine: 192.168.100.7
   • Indirizzo IP di destinazione: 192.168.1.4
3. La macchina virtuale risponde alla richiesta dell'applicazione, ripristinando gli indirizzi IP di origine e di destinazione. Il flusso in ingresso non richiede un route definita dall'utente (UDR), perché l'indirizzo IP di origine è l'indirizzo IP di Firewall di Azure. La route definita dall'utente nel diagramma per 0.0.0.0/0 riguarda le connessioni in uscita, per assicurarsi che i pacchetti verso Internet pubblico vengano passati attraverso Firewall di Azure.
   • Indirizzo IP di origine: 192.168.1.4
   • Indirizzo IP di destinazione: 192.168.100.7
4. Infine, Firewall di Azure annulla le operazioni SNAT e DNAT e invia la risposta al client:
   • Indirizzo IP di origine: AzFwPIP
   • Indirizzo IP di destinazione: ClientPIP

Solo gateway applicazione

Questa progettazione illustra la situazione in cui esistono solo le applicazioni Web nella rete virtuale e l'ispezione del traffico in uscita con gruppi di sicurezza di rete è sufficiente per proteggere i flussi in uscita verso Internet.

La differenza principale rispetto alla progettazione precedente con solo Firewall di Azure è che il gateway applicazione non funge da dispositivo di routing con NAT. Si comporta come proxy di applicazione inverso completo. Ovvero, il gateway applicazione arresta la sessione Web dal client e stabilisce una sessione separata con uno dei relativi server back-end. Le connessioni HTTP(S) in ingresso da Internet devono essere inviate all'indirizzo IP pubblico del gateway applicazione, le connessioni da Azure o locale all'indirizzo IP privato del gateway. Il traffico restituito dalle macchine virtuali di Azure seguirà il routing standard della rete virtuale al gateway applicazione . Per altri dettagli, vedere la procedura dettagliata per i pacchetti. I flussi Internet in uscita dalle macchine virtuali di Azure passeranno direttamente a Internet.

La tabella seguente riepiloga i flussi di traffico:

Architettura

L'esempio seguente illustra come un client accede all'applicazione ospitata dalla macchina virtuale da Internet pubblica.

Flusso di lavoro

1. Il client avvia la connessione all'indirizzo IP pubblico del gateway applicazione di Azure:
   • Indirizzo IP di origine: ClientPIP
   • Indirizzo IP di destinazione: AppGwPIP
2. La richiesta all'indirizzo IP pubblico del gateway applicazione viene distribuita a un'istanza back-end del gateway, in questo caso 192.168.200.7. L'istanza del gateway applicazione che riceve la richiesta arresta la connessione dal client e stabilisce una nuova connessione con uno dei back-end. Il back-end vede l'istanza del gateway applicazione come indirizzo IP di origine. Il gateway applicazione inserisce un'intestazione HTTP X-Forwarded-For con l'indirizzo IP client originale.
   • Indirizzo IP di origine: 192.168.200.7 (indirizzo IP privato dell'istanza del gateway applicazione)
   • Indirizzo IP di destinazione: 192.168.1.4
   • Intestazione X-Forwarded-For: ClientPIP
3. La macchina virtuale risponde alla richiesta dell'applicazione, ripristinando gli indirizzi IP di origine e di destinazione. La macchina virtuale sa già come raggiungere il gateway applicazione, quindi non è necessaria una route definita dall'utente.
   • Indirizzo IP di origine: 192.168.1.4
   • Indirizzo IP di destinazione: 192.168.200.7
4. Infine, l'istanza del gateway applicazione risponde al client:
   • Indirizzo IP di origine: AppGwPIP
   • Indirizzo IP di destinazione: ClientPIP

Il gateway applicazione di Azure aggiunge metadati alle intestazioni HTTP del pacchetto, ad esempio l'intestazione X-Forwarded-For contenente l'indirizzo IP del client originale. Alcuni server applicazioni necessitano dell'indirizzo IP del client di origine per gestire il contenuto specifico della georilevazione o per la registrazione. Per altre informazioni, vedere Funzionamento di un gateway applicazione.

• L'indirizzo IP 192.168.200.7 è una delle istanze distribuite dal servizio gateway applicazione di Azure, qui con l'indirizzo IP front-end interno e privato 192.168.200.4. Queste singole istanze sono in genere invisibili all'amministratore di Azure. Ma notare la differenza è utile in alcuni casi, ad esempio per la risoluzione dei problemi di rete.

• Il flusso è simile se il client proviene da una rete locale tramite un gateway VPN o ExpressRoute. La differenza è che il client accede all'indirizzo IP privato del gateway applicazione anziché all'indirizzo pubblico.

Firewall e gateway applicazione in parallelo

Grazie alla semplicità e alla flessibilità, l'esecuzione del gateway applicazione e del firewall di Azure in parallelo è spesso lo scenario migliore.

Implementare questa progettazione se è presente una combinazione di carichi di lavoro Web e non Web nella rete virtuale. Azure WAF nel gateway applicazione di Azure protegge il traffico in ingresso verso i carichi di lavoro Web e Firewall di Azure controlla il traffico in ingresso per le altre applicazioni. Firewall di Azure coprirà i flussi in uscita da entrambi i tipi di carico di lavoro.

Le connessioni HTTP(S) in ingresso da Internet devono essere inviate all'indirizzo IP pubblico del gateway applicazione, le connessioni HTTP(S) da Azure o in locale al relativo indirizzo IP privato. Il routing della rete virtuale standard invierà i pacchetti dal gateway applicazione alle macchine virtuali di destinazione, nonché dalle macchine virtuali di destinazione al gateway applicazione .Per altre informazioni, vedere la procedura dettagliata per i pacchetti. Per le connessioni non HTTP(S) in ingresso, il traffico deve essere destinato all'indirizzo IP pubblico di Firewall di Azure (se proveniente dalla rete Internet pubblica) oppure verrà inviato tramite firewall di Azure da route definite dall'utente (se provenienti da altre reti virtuali di Azure o reti locali). Tutti i flussi in uscita dalle macchine virtuali di Azure verranno inoltrati a Firewall di Azure da route definite dall'utente.

La tabella seguente riepiloga i flussi di traffico per questo scenario:

Questa progettazione offre un filtro in uscita molto più granulare rispetto ai gruppi di sicurezza di rete. Ad esempio, se le applicazioni necessitano di connettività a un account di archiviazione di Azure specifico, è possibile usare filtri basati su nome di dominio completo (FQDN). Con i filtri basati su FQDN, le applicazioni non inviano dati ad account di archiviazione non autorizzati. Questo scenario non può essere impedito solo usando i gruppi di sicurezza di rete. Questa progettazione viene spesso usata in cui il traffico in uscita richiede filtri basati su FQDN. Una situazione di esempio è quando limitare il traffico in uscita da un cluster dei servizi Azure Kubernetes.

Architetture

Il diagramma seguente illustra il flusso di traffico per le connessioni HTTP(S) in ingresso da un client esterno:

Il diagramma seguente illustra il flusso del traffico per le connessioni in uscita dalle macchine virtuali di rete a Internet. Un esempio consiste nel connettersi ai sistemi back-end o ottenere gli aggiornamenti del sistema operativo:

I passaggi del flusso di pacchetto per ogni servizio sono gli stessi delle opzioni di progettazione autonome precedenti.

Gateway applicazione prima del firewall

Questa progettazione è illustrata in modo più dettagliato in rete zero-trust per le applicazioni Web con Firewall di Azure e gateway applicazione, questo documento si concentrerà sul confronto con le altre opzioni di progettazione. In questa topologia, il traffico Web in ingresso passa attraverso Firewall di Azure e WAF. WAF offre protezione a livello di applicazione Web. Firewall di Azure funge da punto di registrazione e controllo centrale e controlla il traffico tra il gateway applicazione e i server back-end. Il gateway applicazione e Firewall di Azure non sono seduti in parallelo, ma uno dopo l'altro.

Con Firewall di Azure Premium, questa progettazione può supportare scenari end-to-end, in cui Firewall di Azure applica l'ispezione TLS per eseguire IDPS sul traffico crittografato tra il gateway applicazione e il back-end Web.

Questa progettazione è appropriata per le applicazioni che devono conoscere gli indirizzi IP di origine client in ingresso, ad esempio per gestire contenuti specifici della georilevazione o per la registrazione. Il gateway applicazione davanti a Firewall di Azure acquisisce l'indirizzo IP di origine del pacchetto in ingresso nell'intestazione X-forwarded-for, in modo che il server Web possa visualizzare l'indirizzo IP originale in questa intestazione. Per altre informazioni, vedere Funzionamento di un gateway applicazione.

Le connessioni HTTP(S) in ingresso da Internet devono essere inviate all'indirizzo IP pubblico del gateway applicazione, le connessioni HTTP(S) da Azure o in locale all'indirizzo IP privato. Dalle route definite dall'utente del gateway applicazione si assicurerà che i pacchetti vengano instradati attraverso Firewall di Azure . Per altri dettagli, vedere la procedura dettagliata per i pacchetti. Per le connessioni non HTTP(S) in ingresso, il traffico deve essere destinato all'indirizzo IP pubblico di Firewall di Azure (se proveniente dalla rete Internet pubblica) oppure verrà inviato tramite firewall di Azure da route definite dall'utente (se provenienti da altre reti virtuali di Azure o reti locali). Tutti i flussi in uscita dalle macchine virtuali di Azure verranno inoltrati a Firewall di Azure da route definite dall'utente.

Una nota importante di questa progettazione è che Firewall di Azure Premium vedrà il traffico con un indirizzo IP di origine dalla subnet del gateway applicazione. Se questa subnet è configurata con un indirizzo IP privato (in 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 o 100.64.0.0/10), Firewall di Azure Premium considererà il traffico dal gateway applicazione come interno e non applicherà regole IDPS per il traffico in ingresso. Altre informazioni sulle direzioni delle regole IDPS di Firewall di Azure e sui prefissi IP privati per IDPS sono disponibili in regole IDPS del firewall di Azure. Di conseguenza, è consigliabile modificare i prefissi privati IDPS nei criteri di Firewall di Azure in modo che la subnet del gateway applicazione non sia considerata come un'origine interna, per applicare firme IDPS in ingresso e in uscita al traffico.

La tabella seguente riepiloga i flussi di traffico per questo scenario:

Per il traffico Web dall'ambiente locale o da Internet ad Azure, Firewall di Azure controlla i flussi già consentiti dal WAF. A seconda che il gateway applicazione crittografi il traffico back-end (traffico dal gateway applicazione ai server applicazioni), si avranno scenari potenziali diversi:

1. Il gateway applicazione crittografa il traffico seguendo i principi zero-trust (crittografia TLS end-to-end) e il firewall di Azure riceverà traffico crittografato. Tuttavia, Firewall Di Azure Standard sarà in grado di applicare regole di ispezione, ad esempio il livello 3 & filtro di livello 4 nelle regole di rete o il filtro FQDN nelle regole dell'applicazione usando l'intestazione SNI (TLS Server Name Indication). Premium di Firewall di Azure offre visibilità più approfondita con l'ispezione TLS, ad esempio il filtro basato su URL.
2. Se il gateway applicazione invia traffico non crittografato ai server applicazioni, Firewall di Azure visualizzerà il traffico in ingresso in testo non crittografato. L'ispezione TLS non è necessaria in Firewall di Azure.
3. Se IDPS è abilitato in Firewall di Azure, verificherà che l'intestazione host HTTP corrisponda all'IP di destinazione. A tale scopo, sarà necessaria la risoluzione dei nomi per il nome di dominio completo specificato nell'intestazione Host. Questa risoluzione dei nomi può essere ottenuta con le zone private dns di Azure e le impostazioni DNS predefinite di Firewall di Azure tramite DNS di Azure. Può essere ottenuto anche con server DNS personalizzati che devono essere configurati nelle impostazioni di Firewall di Azure. Per altre informazioni, vedere impostazioni DNS di Firewall di Azure.) Se non è disponibile l'accesso amministrativo alla rete virtuale in cui è distribuito Firewall di Azure, quest'ultimo metodo è l'unica possibilità. Un esempio è rappresentato dai firewall di Azure distribuiti negli hub protetti della rete WAN virtuale.

Architettura

Per il resto dei flussi (traffico non HTTP(S) in ingresso e qualsiasi traffico in uscita, Firewall di Azure fornirà l'ispezione IDPS e l'ispezione TLS, se appropriato. Fornisce inoltre filtro basato su FQDN nelle regole di rete in base al DNS.

Flusso di lavoro

Il traffico di rete da Internet pubblico segue questo flusso:

1. Il client avvia la connessione all'indirizzo IP pubblico del gateway applicazione di Azure:
   • Indirizzo IP di origine: ClientPIP
   • Indirizzo IP di destinazione: AppGwPIP
2. La richiesta all'indirizzo IP pubblico del gateway applicazione viene distribuita a un'istanza back-end del gateway, in questo caso 192.168.200.7. L'istanza del gateway applicazione arresta la connessione dal client e stabilisce una nuova connessione con uno dei back-end. La route definita dall'utente da 192.168.1.0/24 nella subnet del gateway applicazione inoltra il pacchetto a Firewall di Azure, mantenendo l'indirizzo IP di destinazione all'applicazione Web:
   • Indirizzo IP di origine: 192.168.200.7 (indirizzo IP privato dell'istanza del gateway applicazione)
   • Indirizzo IP di destinazione: 192.168.1.4
   • Intestazione X-Forwarded-For: ClientPIP
3. Firewall di Azure non esegue lo SNAT del traffico, perché il traffico passa a un indirizzo IP privato. Inoltra il traffico alla macchina virtuale dell'applicazione se le regole lo consentono. Per altre informazioni, vedere firewall di Azure. Tuttavia, se il traffico raggiunge una regola dell'applicazione nel firewall, il carico di lavoro visualizzerà l'indirizzo IP di origine dell'istanza del firewall specifica che ha elaborato il pacchetto, poiché Firewall di Azure proxyrà la connessione:
   • Indirizzo IP di origine se il traffico è consentito da una regola di rete di Firewall di Azure: 192.168.200.7 (indirizzo IP privato di una delle istanze del gateway applicazione).
   • Indirizzo IP di origine se il traffico è consentito da una regola dell'applicazione firewall di Azure: 192.168.100.7 (indirizzo IP privato di una delle istanze di Firewall di Azure).
   • Indirizzo IP di destinazione: 192.168.1.4
   • Intestazione X-Forwarded-For: ClientPIP
4. La macchina virtuale risponde alla richiesta, ripristinando gli indirizzi IP di origine e di destinazione. La route definita dall'utente per 192.168.200.0/24 acquisisce il pacchetto inviato al gateway applicazione e lo reindirizza a Firewall di Azure, mantenendo l'INDIRIZZO IP di destinazione verso il gateway applicazione.
   • Indirizzo IP di origine: 192.168.1.4
   • Indirizzo IP di destinazione: 192.168.200.7
5. Anche in questo caso Firewall di Azure non esegue lo SNAT del traffico, perché passa a un indirizzo IP privato e inoltra il traffico al gateway applicazione.
   • Indirizzo IP di origine: 192.168.1.4
   • Indirizzo IP di destinazione: 192.168.200.7
6. Infine, l'istanza del gateway applicazione risponde al client:
   • Indirizzo IP di origine: AppGwPIP
   • Indirizzo IP di destinazione: ClientPIP

I flussi in uscita dalle macchine virtuali alla rete Internet pubblica passano attraverso Firewall di Azure, come definito dalla route definita dall'utente per 0.0.0.0/0.

Gateway applicazione dopo il firewall

Questa progettazione consente di filtrare e eliminare il traffico dannoso prima di raggiungere il gateway applicazione. Ad esempio, può applicare funzionalità come il filtro basato sull'intelligence sulle minacce. Un altro vantaggio è che l'applicazione ottiene lo stesso indirizzo IP pubblico sia per il traffico in ingresso che in uscita, indipendentemente dal protocollo. Firewall di Azure, tuttavia, esegue lo SNAT del traffico in ingresso, quindi l'applicazione non avrà visibilità sull'indirizzo IP originale delle richieste HTTP. Dal punto di vista dell'amministrazione, ad esempio per la risoluzione dei problemi, è possibile ottenere l'indirizzo IP client effettivo per una connessione specifica correlandolo con i log SNAT del Firewall di Azure.

Questo scenario offre un vantaggio limitato, perché Firewall di Azure visualizzerà solo il traffico crittografato che passa al gateway applicazione. Potrebbero esserci scenari in cui si preferisce questa progettazione. Un caso è se un altro WAF è precedente nella rete (ad esempio, con Frontdoor di Azure), che potrebbe acquisire l'indirizzo IP di origine originale nell'intestazione HTTP X-Forwarded-For. Oppure la progettazione è preferibile se sono necessari molti indirizzi IP pubblici.

I flussi in ingresso HTTP(S) dalla rete Internet pubblica devono essere destinati all'indirizzo IP pubblico di Firewall di Azure e Firewall di Azure dnat (e SNAT) i pacchetti all'indirizzo IP privato del gateway applicazione. Da altre reti virtuali di Azure o reti locali, il traffico HTTP(S) deve essere inviato all'INDIRIZZO IP privato del gateway applicazione e inoltrato tramite Firewall di Azure con route definite dall'utente. Il routing della rete virtuale standard garantisce che il traffico restituito dalle macchine virtuali di Azure torni al gateway applicazione e dal gateway applicazione al firewall di Azure se sono state usate regole DNAT. Per il traffico proveniente dall'istanza locale o dalle route definite dall'utente di Azure nella subnet del gateway applicazione, vedere la procedura dettagliata per i pacchetti per altri dettagli. Tutto il traffico in uscita dalle macchine virtuali di Azure a Internet verrà inviato tramite Firewall di Azure da route definite dall'utente.

La tabella seguente riepiloga i flussi di traffico per questo scenario:

Per il traffico HTTP(S) in ingresso, Firewall di Azure in genere non decrittografa il traffico. Applica invece criteri IDPS che non richiedono l'ispezione TLS, ad esempio il filtro basato su IP o l'uso di intestazioni HTTP.

Architettura

L'applicazione non può visualizzare l'indirizzo IP di origine originale del traffico Web; Firewall di Azure SNAT i pacchetti non appena vengono inseriti nella rete virtuale. Per evitare questo problema, usare frontdoor di Azure davanti al firewall. Frontdoor di Azure inserisce l'indirizzo IP del client come intestazione HTTP prima di accedere alla rete virtuale di Azure.

Flusso di lavoro

Il traffico di rete da Internet pubblico segue questo flusso:

1. Il client avvia la connessione all'indirizzo IP pubblico di Firewall di Azure:
   • Indirizzo IP di origine: ClientPIP
   • Indirizzo IP di destinazione: AzFWPIP
2. La richiesta all'indirizzo IP pubblico di Firewall di Azure viene distribuita a un'istanza back-end del firewall, in questo caso 192.168.100.7. Il DNA di Firewall di Azure esegue il mapping della porta Web, in genere TCP 443, all'indirizzo IP privato dell'istanza del gateway applicazione. Firewall di Azure esegue anche SNAT durante l'operazione DNAT. Per altre informazioni, vedere problemi noti di Firewall di Azure:
   • Indirizzo IP di origine: 192.168.100.7 (indirizzo IP privato dell'istanza di Firewall di Azure)
   • Indirizzo IP di destinazione: 192.168.200.4
3. Il gateway applicazione stabilisce una nuova sessione tra l'istanza che gestisce la connessione e uno dei server back-end. L'indirizzo IP originale del client non è incluso nel pacchetto:
   • Indirizzo IP di origine: 192.168.200.7 (indirizzo IP privato dell'istanza del gateway applicazione)
   • Indirizzo IP di destinazione: 192.168.1.4
   • Intestazione X-Forwarded-For: 192.168.100.7
4. La macchina virtuale risponde al gateway applicazione, ripristinando gli indirizzi IP di origine e di destinazione:
   • Indirizzo IP di origine: 192.168.1.4
   • Indirizzo IP di destinazione: 192.168.200.7
5. Il gateway applicazione risponde all'indirizzo IP di origine SNAT dell'istanza di Firewall di Azure. Anche se la connessione proviene da un'istanza specifica del gateway applicazione come .7, Firewall di Azure vede l'indirizzo IP interno del gateway applicazione .4 come INDIRIZZO IP di origine:
   • Indirizzo IP di origine: 192.168.200.4
   • Indirizzo IP di destinazione: 192.168.100.7
6. Infine, Firewall di Azure annulla SNAT e DNAT e risponde al client:
   • Indirizzo IP di origine: AzFwPIP
   • Indirizzo IP di destinazione: ClientPIP

Anche se il gateway applicazione non ha listener configurati per le applicazioni, ha comunque bisogno di un indirizzo IP pubblico in modo che Microsoft possa gestirlo.

Client locali

Le progettazioni precedenti mostrano tutti i client dell'applicazione provenienti dalla rete Internet pubblica. Anche le reti locali accedono alle applicazioni. La maggior parte delle informazioni e dei flussi di traffico precedenti è identica a quella dei client Internet, ma esistono alcune differenze significative:

• Un gateway VPN o un gateway ExpressRoute si trova davanti a Firewall di Azure o gateway applicazione.
• WAF usa l'indirizzo IP privato del gateway applicazione.
• Firewall di Azure non supporta DNAT per gli indirizzi IP privati. Ecco perché è necessario usare le route definite dall'utente per inviare il traffico in ingresso a Firewall di Azure dai gateway VPN o ExpressRoute.
• Assicurarsi di verificare le avvertenze relative di tunneling forzato per il del gateway applicazione di Azure e per Firewall di Azure. Anche se il carico di lavoro non richiede la connettività in uscita a Internet pubblico, non è possibile inserire una route predefinita come 0.0.0.0/0 per il gateway applicazione che punta alla rete locale oppure si interromperà il traffico. Per il gateway applicazione di Azure, la route predefinita deve puntare a Internet pubblico.

Architettura

Il diagramma seguente illustra la progettazione parallela del gateway applicazione di Azure e di Firewall di Azure. I client dell'applicazione provengono da una rete locale connessa ad Azure tramite VPN o ExpressRoute:

Anche se tutti i client si trovano in locale o in Azure, il gateway applicazione di Azure e Firewall di Azure devono avere entrambi indirizzi IP pubblici. Gli indirizzi IP pubblici consentono a Microsoft di gestire i servizi.

Topologia hub-spoke

Le progettazioni in questo articolo si applicano ancora in una topologia hub e spoke . Le risorse condivise in una rete virtuale hub centrale si connettono alle applicazioni in reti virtuali spoke separate tramite peering di rete virtuale.

Architettura

Considerazioni

Alcune considerazioni per questa topologia includono:

• Firewall di Azure viene distribuito nella rete virtuale dell'hub centrale. Il diagramma precedente illustra la procedura di distribuzione del gateway applicazione nell'hub. I team delle applicazioni spesso gestiscono componenti come gateway applicazione di Azure o gateway di Gestione API di Azure, anche se. In questo caso, questi componenti vengono distribuiti nelle reti virtuali spoke.
• Prestare particolare attenzione alle route definite dall'utente nelle reti spoke: quando un server applicazioni in uno spoke riceve traffico da un'istanza specifica di Firewall di Azure, come l'indirizzo 192.168.100.7 negli esempi precedenti, deve inviare nuovamente il traffico alla stessa istanza. Se una route definita dall'utente nello spoke imposta l'hop successivo del traffico indirizzato all'hub all'indirizzo IP di Firewall di Azure (192.168.100.4 nei diagrammi precedenti), i pacchetti restituiti potrebbero terminare in un'altra istanza di Firewall di Azure, causando il routing asimmetrico. Assicurarsi che se sono presenti route definite dall'utente nelle reti virtuali spoke per inviare il traffico ai servizi condivisi nell'hub tramite Firewall di Azure, queste route definite dall'utente non includono il prefisso della subnet di Firewall di Azure.
• La raccomandazione precedente si applica allo stesso modo alla subnet del gateway applicazione e a qualsiasi altra appliance virtuale di rete o proxy inversi che potrebbero essere distribuiti nella rete virtuale dell'hub.
• Non è possibile impostare l'hop successivo per il gateway applicazione o le subnet di Firewall di Azure tramite route statiche con un tipo di hop successivo di Virtual Network. Questo tipo di hop successivo è valido solo nella rete virtuale locale e non tra peering reti virtuali. Per altre informazioni sulle route definite dall'utente e sui tipi di hop successivo, vedere routing del traffico di rete virtuale.

Routing asimmetrico

Il diagramma seguente mostra come uno spoke restituisce il traffico SNATted alB di un firewall di Azure. Questa configurazione causa il routing asimmetrico:

Per risolvere questo problema, definire le route definite dall'utente nello spoke senza la subnet di Firewall di Azure, ma con solo le subnet in cui si trovano i servizi condivisi. Nell'esempio la route definita dall'utente corretta nello spoke deve contenere solo 192.168.1.0/24. Non deve contenere l'intero 192.168.0.0/16, come contrassegnato in rosso.

Integrazione con altri prodotti Azure

È possibile integrare Firewall di Azure e il gateway applicazione di Azure con altri prodotti e servizi di Azure.

Gateway di Gestione API

Integrare servizi proxy inversi come Gestione API gateway nelle progettazioni precedenti per fornire funzionalità come la limitazione api o il proxy di autenticazione. L'integrazione di un gateway di Gestione API non modifica notevolmente le progettazioni. La differenza principale è che, invece del singolo proxy inverso del gateway applicazione, esistono due proxy inverso concatenati tra loro.

Per altre informazioni, vedere guida alla progettazione di per integrare Gestione API e gateway applicazione in una rete virtuale e il modello di applicazione gateway API per microservizi.

Servizio Azure Kubernetes

Per i carichi di lavoro in esecuzione in un cluster del servizio Azure Kubernetes, è possibile distribuire il gateway applicazione di Azure indipendentemente dal cluster. In alternativa, è possibile integrarlo con il cluster del servizio Azure Kubernetes usando controller di ingresso del gateway applicazione di Azure. Quando si configurano determinati oggetti a livello di Kubernetes (ad esempio servizi e ingresso), il gateway applicazione si adatta automaticamente senza dover eseguire passaggi manuali aggiuntivi.

Firewall di Azure svolge un ruolo importante nella sicurezza del cluster del servizio Azure Kubernetes. Offre la funzionalità necessaria per filtrare il traffico in uscita dal cluster del servizio Azure Kubernetes in base al nome di dominio completo, non solo all'indirizzo IP. Per altre informazioni, vedere Controllare il traffico in uscita per i nodi del cluster del servizio Azure Kubernetes.

Quando si combina il gateway applicazione e Firewall di Azure per proteggere un cluster del servizio Azure Kubernetes, è consigliabile usare l'opzione di progettazione parallela. Il gateway applicazione con WAF elabora le richieste di connessione in ingresso alle applicazioni Web nel cluster. Firewall di Azure consente solo connessioni in uscita consentite in modo esplicito. Vedere Architettura di base per un cluster del servizio Azure Kubernetes per un esempio dell'opzione di progettazione parallela.

Frontdoor di Azure

funzionalità frontdoor di Azure si sovrappongono parzialmente al gateway applicazione di Azure. Ad esempio, entrambi i servizi offrono web application firewalling, offload SSL e routing basato su URL. Una differenza principale è che mentre il gateway applicazione di Azure si trova all'interno di una rete virtuale, Frontdoor di Azure è un servizio globale decentralizzato.

A volte è possibile semplificare la progettazione della rete virtuale sostituendo il gateway applicazione con una frontdoor di Azure decentralizzata. La maggior parte delle progettazioni descritte qui rimane valida, ad eccezione dell'opzione di posizionare Firewall di Azure davanti a Frontdoor di Azure.

Un caso d'uso interessante consiste nell'usare Firewall di Azure davanti al gateway applicazione nella rete virtuale. Come descritto in precedenza, l'intestazione X-Forwarded-For inserita dal gateway applicazione conterrà l'indirizzo IP dell'istanza del firewall, non l'indirizzo IP del client. Una soluzione alternativa consiste nell'usare Frontdoor di Azure davanti al firewall per inserire l'indirizzo IP del client come intestazione X-Forwarded-For prima che il traffico entri nella rete virtuale e raggiunge Firewall di Azure. Una seconda opzione consiste nel Proteggere l'origine con collegamento privato in Frontdoor di Azure Premium.

Per altre informazioni sulle differenze tra i due servizi o su quando usarli, vedere domande frequenti su Frontdoor di Azure.

Altre appliance virtuali di rete

I prodotti Microsoft non sono l'unica scelta per implementare web application firewall o funzionalità firewall di nuova generazione in Azure. Un'ampia gamma di partner Microsoft offre appliance virtuali di rete . I concetti e le progettazioni sono essenzialmente gli stessi di questo articolo, ma esistono alcune considerazioni importanti:

• Le appliance virtuali di rete partner per il firewall di nuova generazione possono offrire maggiore controllo e flessibilità per le configurazioni NAT non supportate da Firewall di Azure. Gli esempi includono DNAT dall'ambiente locale o DNAT da Internet senza SNAT.
• Le appliance virtuali di rete gestite da Azure (ad esempio il gateway applicazione e Firewall di Azure) riducono la complessità, rispetto alle appliance virtuali di rete in cui gli utenti devono gestire la scalabilità e la resilienza in più appliance.
• Quando si usano appliance virtuali di rete in Azure, usare attivo-attivo e la scalabilità automatica configurazioni, quindi queste appliance non sono un collo di bottiglia per le applicazioni in esecuzione nella rete virtuale.

Contributori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai collaboratori seguenti.

Autore principale:

• Jose Moreno | Principal Customer Engineer

Passaggi successivi

Altre informazioni sulle tecnologie dei componenti:

• Che cos'è il gateway applicazione di Azure?
• Che cos'è Firewall di Azure?
• Che cos'è Frontdoor di Azure?
• del servizio Azure Kubernetes
• Che cos'è la rete virtuale di Azure?
• Che cos'è Web application firewall di Azure?

Risorse correlate

Esplorare le architetture correlate:

• Implementare una rete ibrida sicura
• applicazioni Web gestite in modo sicuro
• Protezione del bot del canale e dell'app Web di Microsoft Teams dietro un firewall
• Considerazioni sulla sicurezza per le app IaaS altamente sensibili in Azure
• SaaS multi-tenant in Azure
• distribuzione di Enterprise con l'ambiente dei servizi app
• distribuzione aziendale a disponibilità elevata con l'ambiente dei servizi app
• architettura di base per un cluster del servizio Azure Kubernetes