Firewall di Azure e gateway applicazione per reti virtuali

Per proteggere i carichi di lavoro delle applicazioni di Azure, usare misure protettive come l'autenticazione e la crittografia nelle applicazioni stesse. È possibile aggiungere livelli di sicurezza alle reti virtuali che ospitano le applicazioni. Questi livelli di sicurezza consentono di proteggere i flussi in ingresso dell'applicazione dall'uso 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. Descrive anche quando usare ogni servizio e le opzioni di progettazione di rete che le combinano.

• protezione DDoS, insieme alle procedure consigliate per la progettazione delle applicazioni, fornisce funzionalità avanzate di mitigazione DDoS che migliorano la difesa dagli attacchi DDoS. È consigliabile abilitare Protezione DDoS in ogni rete virtuale perimetrale.

• firewall di Azure è un firewall gestito di nuova generazione che offre funzionalità NAT (Network Address Translation) . Firewall di Azure filtra i pacchetti in base agli indirizzi IP e alle porte TCP (Transmission Control Protocol) o UDP (User Datagram Protocol). Può filtrare il traffico usando attributi basati su applicazioni, ad esempio HTTP(S) e SQL. Firewall di Azure applica anche l'intelligence sulle minacce Microsoft per identificare gli indirizzi IP dannosi. Per altre informazioni, vedere documentazione di Firewall di Azure.

• firewall di Azure Premium include tutte le funzionalità di Firewall di Azure Standard, oltre a funzionalità come l'ispezione tls (Transport Layer Security) e il sistema di rilevamento e prevenzione delle intrusioni (IDPS).

• gateway applicazione è 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 di Azure per esaminare il traffico Web e rilevare gli attacchi a livello HTTP. Per altre informazioni, vedere documentazione del gateway applicazione.

• web application firewall è un'aggiunta facoltativa al gateway applicazione. Esamina le richieste HTTP e impedisce attacchi a livello Web, ad esempio SQL injection e scripting tra siti. Per altre informazioni, vedere documentazione di Web Application Firewall.

Questi servizi di Azure si integrano tra loro. A seconda delle esigenze, l'uso di un servizio potrebbe adattarsi meglio ai carichi di lavoro. Tuttavia, è possibile usare questi servizi insieme per garantire una protezione ottimale sia a livello di rete che di applicazione. Usare l'albero delle decisioni seguente e gli esempi in questo articolo per scegliere l'opzione di sicurezza migliore per la rete virtuale dell'applicazione.

Firewall di Azure e il gateway applicazione usano tecnologie diverse per proteggere diversi tipi di flussi di dati.

La progettazione può variare per ogni applicazione in base ai flussi di rete richiesti. Il diagramma seguente fornisce un albero delle decisioni semplificato che consente di scegliere l'approccio consigliato per l'applicazione. Questa scelta dipende dal fatto che l'applicazione venga pubblicata tramite HTTP(S) o un altro protocollo.

Questo articolo descrive le progettazioni ampiamente consigliate illustrate nel grafico di flusso e le progettazioni adatte per scenari meno comuni:

• Firewall di Azure: Usare questa progettazione 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 solo: Usare questa progettazione quando solo le applicazioni Web si trovano nella rete virtuale e gruppi di sicurezza di rete (NSG) forniscono filtri di output sufficienti. Firewall di Azure offre funzionalità che consentono di evitare diversi scenari di attacco, ad esempio l'esfiltrazione dei dati e l'IDPS. Di conseguenza, la progettazione solo del gateway applicazione non è in genere consigliata, quindi non è inclusa nel grafico di flusso precedente.

• Firewall di Azure e il gateway applicazione in parallelo: Usare questa progettazione quando si vuole che il gateway applicazione 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. Firewall di Azure e il gateway applicazione in parallelo sono una progettazione comune.

• gateway applicazione davanti a Firewall di Azure: Usare questa progettazione quando si vuole che Firewall di Azure esamini tutto il traffico, Web Application Firewall per proteggere il traffico Web e l'applicazione per identificare 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: Usare questa progettazione quando si vuole che Firewall di Azure controlli e filtri il traffico prima che raggiunga il gateway applicazione. Poiché Firewall di Azure non decrittografa il traffico HTTPS, la funzionalità aggiunta al gateway applicazione è limitata. Questo scenario non è documentato nel grafico di flusso precedente.

Le varianti di queste progettazioni fondamentali sono descritte più avanti in questo articolo e includono:

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

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

Progettazione solo firewall di Azure

Se nella rete virtuale non sono presenti carichi di lavoro basati sul Web che possono trarre vantaggio da Web Application Firewall, è possibile usare la progettazione solo firewall di Azure. La progettazione in questo esempio è semplice, ma è possibile esaminare il flusso di pacchetti per comprendere meglio le progettazioni più complesse. 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. Le route definite dall'utente indirizzano il traffico in uscita dalle reti virtuali di Azure a Firewall di Azure, 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 può applicare regole di livello 3 e livello 4 e regole dell'applicazione basate su nome di dominio completo (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 controlla solo gli attributi di livello 3 e 4 dei pacchetti nelle regole di rete e l'intestazione HTTP host nelle regole dell'applicazione.

• Firewall di Azure Premium aggiunge funzionalità, ad esempio l'ispezione di altre intestazioni HTTP (ad esempio l'agente utente) e l'abilitazione dell'ispezione TLS per l'analisi più approfondita dei pacchetti. Tuttavia, Firewall di Azure non è uguale a Web Application Firewall. Se nella rete virtuale sono presenti carichi di lavoro Web, è consigliabile usare Web Application Firewall.

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à, esistono più istanze dell'applicazione dietro un servizio di bilanciamento del carico. In questa progettazione Firewall di Azure controlla le connessioni in ingresso dalla rete Internet pubblica e le connessioni in uscita dalla macchina virtuale della subnet dell'applicazione usando la route definita dall'utente.

• In questo esempio Firewall di Azure distribuisce automaticamente diverse istanze con l'indirizzo IP front-end 192.168.100.4 e gli indirizzi interni all'interno dell'intervallo 192.168.100.0/26. In genere, queste istanze non sono visibili all'amministratore di Azure. Tuttavia, essere consapevoli di questi problemi può essere utile 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 e presuppone 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, che è 192.168.100.7 in questo esempio. La regola DNAT (Destination Network Address Translation) di Firewall di Azure converte l'indirizzo IP di destinazione nell'indirizzo IP dell'applicazione all'interno della rete virtuale. Firewall di Azure implementa anche SNAT (Source Network Address Translation) nel pacchetto se usa 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, che inverte sia gli indirizzi IP di origine che di destinazione. Il flusso in ingresso non richiede una route definita dall'utente perché l'indirizzo IP di origine è l'indirizzo IP del firewall di Azure. La route definita dall'utente nel diagramma per 0.0.0.0/0 riguarda le connessioni in uscita per garantire 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. 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

Progettazione solo gateway applicazione

Questa progettazione descrive lo scenario 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 di Firewall di Azure è che il gateway applicazione non funge da dispositivo di routing con NAT. Funziona invece come proxy di applicazione inverso completo. Questo approccio significa che il gateway applicazione arresta la sessione Web dal client e stabilisce una sessione separata con uno dei server back-end. Le connessioni HTTP(S) in ingresso da Internet vengono inviate all'indirizzo IP pubblico del gateway applicazione e le connessioni da Azure o in locale usano l'indirizzo IP privato del gateway. Il traffico restituito dalle macchine virtuali di Azure segue il routing di rete virtuale standard al gateway applicazione. Per altre informazioni, vedere la procedura dettagliata per i pacchetti più avanti in questo articolo. I flussi Internet in uscita dalle macchine virtuali di Azure passano 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.

   • 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, che è 192.168.200.7 in questo esempio. 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 del client originale.

   • Indirizzo IP di origine, ovvero l'indirizzo IP privato dell'istanza del gateway applicazione: 192.168.200.7
   • Indirizzo IP di destinazione: 192.168.1.4
   • intestazione X-Forwarded-For: ClientPIP

3. La macchina virtuale risponde alla richiesta dell'applicazione e inverte gli indirizzi IP di origine e di destinazione. La macchina virtuale può 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. L'istanza del gateway applicazione risponde al client.

   • Indirizzo IP di origine: AppGwPIP
   • Indirizzo IP di destinazione: ClientPIP

Il gateway applicazione aggiunge metadati alle intestazioni HTTP del pacchetto, ad esempio l'intestazione X-Forwarded-For che contiene 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.

• In questo esempio, l'indirizzo IP 192.168.200.7 è una delle istanze distribuite automaticamente dal servizio gateway applicazione. Ha 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 può essere utile, ad esempio quando si risolvono i 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 IP pubblico.

Firewall di Azure e gateway applicazione in progettazione parallela

Grazie alla semplicità e alla flessibilità, è spesso consigliabile eseguire il gateway applicazione e Firewall di Azure in parallelo.

Implementare questa progettazione se nella rete virtuale sono presenti carichi di lavoro Web e non Web. Web Application Firewall nel gateway applicazione consente di proteggere il traffico in ingresso verso i carichi di lavoro Web. Firewall di Azure controlla il traffico in ingresso per le altre applicazioni. Firewall di Azure copre 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 devono essere inviate al relativo indirizzo IP privato. Il routing di rete virtuale standard invia i pacchetti dal gateway applicazione alle macchine virtuali di destinazione e dalle macchine virtuali di destinazione al gateway applicazione. Per altre informazioni, vedere la procedura dettagliata per i pacchetti più avanti in questo articolo.

Per le connessioni non HTTP(S) in ingresso, il traffico deve essere destinato all'indirizzo IP pubblico di Firewall di Azure se proviene dalla rete Internet pubblica. Il traffico deve essere inviato tramite Firewall di Azure da route definite dall'utente se proviene da altre reti virtuali di Azure o da reti locali. Tutti i flussi in uscita dalle macchine virtuali di Azure vengono 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 all'uso esclusivo dei 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 FQDN. Con i filtri basati su FQDN, le applicazioni non inviano dati ad account di archiviazione non autorizzati. Se si usano solo gruppi di sicurezza di rete, non è possibile impedire questo scenario. Questa progettazione viene spesso usata quando il traffico in uscita richiede filtri basati su FQDN. Uno scenario è quando si limitare il traffico in uscita da un cluster del servizio 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 davanti alla progettazione di Firewall di Azure

Questa progettazione è illustrata in modo più dettagliato in rete Senza attendibilità per le applicazioni Web con Firewall di Azure e il gateway applicazione. Questo articolo è incentrato sul confronto con le altre opzioni di progettazione. In questa topologia il traffico Web in ingresso passa attraverso Firewall di Azure e Web Application Firewall. Web Application Firewall 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. In questa progettazione, il gateway applicazione e Firewall di Azure non si trovano in parallelo, ma siedono uno davanti all'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 è adatta alle applicazioni che devono identificare gli indirizzi IP di origine client in ingresso. Ad esempio, può essere usato per gestire contenuti specifici della georilevazione o per la registrazione. Il gateway applicazione davanti alla progettazione di 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 devono essere inviate al relativo indirizzo IP privato. Dal gateway applicazione, le route definite dall'utente assicurano che i pacchetti vengano instradati tramite Firewall di Azure. Per altre informazioni, vedere la procedura dettagliata per i pacchetti più avanti in questo articolo.

Per le connessioni non HTTP(S) in ingresso, il traffico deve essere destinato all'indirizzo IP pubblico di Firewall di Azure se proviene dalla rete Internet pubblica. Il traffico deve essere inviato tramite Firewall di Azure da route definite dall'utente se proviene da altre reti virtuali di Azure o da reti locali. Tutti i flussi in uscita dalle macchine virtuali di Azure vengono inoltrati a Firewall di Azure da route definite dall'utente.

Un aspetto importante di questa progettazione è che Firewall di Azure Premium vede 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/12o 100.64.0.0/10), Firewall di Azure Premium considera il traffico dal gateway applicazione come interno e non applica regole IDPS per il traffico in ingresso. Di conseguenza, è consigliabile modificare i prefissi privati IDPS nei criteri di Firewall di Azure. Questa modifica garantisce che la subnet del gateway applicazione non sia considerata un'origine interna, che consente l'applicazione delle firme IDPS in ingresso e in uscita al traffico. Altre informazioni sulle direzioni delle regole IDPS di Firewall di Azure e sui prefissi IP privati per IDPS sono disponibili in regole IDPS di Firewall di Azure.

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 consentiti da Web Application Firewall. A seconda che il gateway applicazione crittografi il traffico back-end, ovvero il traffico dal gateway applicazione ai server applicazioni, possono verificarsi scenari diversi:

• Il gateway applicazione crittografa il traffico seguendo principi senza attendibilità, ad esempio crittografia TLS end-to-ende Firewall di Azure riceve traffico crittografato. Firewall di Azure Standard può comunque applicare regole di ispezione, ad esempio il filtro di livello 3 e 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.

• Se il gateway applicazione invia traffico non crittografato ai server applicazioni, Firewall di Azure rileva il traffico in ingresso in testo non crittografato. L'ispezione TLS non è necessaria in Firewall di Azure.

• Se IDPS è abilitato in Firewall di Azure, verifica che l'intestazione host HTTP corrisponda all'indirizzo IP di destinazione. Per eseguire questa verifica, è necessaria la risoluzione dei nomi per il nome di dominio completo specificato nell'intestazione Host. Questa risoluzione dei nomi può essere eseguita usando le zone private dns di Azure e le impostazioni dns predefinite firewall di Azure. Può essere ottenuto anche con server DNS personalizzati che devono essere configurati nelle impostazioni di Firewall di Azure. Se non si ha accesso amministrativo alla rete virtuale in cui è distribuito Firewall di Azure, quest'ultimo metodo è l'unica opzione. Un esempio consiste nell'usare le istanze di Firewall di Azure distribuite negli hub protetti dalla rete WAN virtuale di Azure.

Architettura

Per il resto dei flussi, che includono il traffico non HTTP(S) in ingresso e qualsiasi traffico in uscita, Firewall di Azure fornisce 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.

   • 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, che è 192.168.200.7 in questo esempio. 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 e mantiene l'indirizzo IP di destinazione all'applicazione Web.

   • Indirizzo IP di origine, ovvero l'indirizzo IP privato dell'istanza del gateway applicazione: 192.168.200.7
   • Indirizzo IP di destinazione: 192.168.1.4
   • intestazione X-Forwarded-For: ClientPIP

3. Firewall di Azure non applica SNAT al 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 Intervalli di indirizzi IP privati SNAT di Firewall di Azure. Tuttavia, se il traffico raggiunge una regola dell'applicazione nel firewall, il carico di lavoro vede l'indirizzo IP di origine dell'istanza del firewall specifica che ha elaborato il pacchetto perché Firewall di Azure esegue il proxy della connessione.

   • Indirizzo IP di origine se il traffico è consentito da una regola di rete di Firewall di Azure ed è l'indirizzo IP privato di una delle istanze del gateway applicazione: 192.168.200.7
   • Indirizzo IP di origine se il traffico è consentito da una regola dell'applicazione firewall di Azure ed è l'indirizzo IP privato di una delle istanze di Firewall di Azure: 192.168.100.7
   • Indirizzo IP di destinazione: 192.168.1.4
   • intestazione X-Forwarded-For: ClientPIP

4. La macchina virtuale risponde alla richiesta, che inverte sia gli indirizzi IP di origine che di destinazione. La route definita dall'utente per 192.168.200.0/24 acquisisce il pacchetto inviato al gateway applicazione, lo reindirizza a Firewall di Azure e mantiene 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 applica SNAT al 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. 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, che la route definita dall'utente per 0.0.0.0/0.

Come variante di questa progettazione, è possibile configurare DNAT privato in Firewall di Azure in modo che il carico di lavoro dell'applicazione veda gli indirizzi IP delle istanze di Firewall di Azure come origine e che non siano necessarie route definite dall'utente. L'indirizzo IP di origine dei client dell'applicazione viene già mantenuto nell'intestazione HTTP X-Forwarded-For dal gateway applicazione. Quindi, se Firewall di Azure applica DNAT al traffico, non viene persa alcuna informazione. Per altre informazioni, vedere Filtrare il traffico Internet in ingresso o Intranet con DNAT dei criteri di Firewall di Azure usando il portale di Azure.

Firewall di Azure davanti alla progettazione del gateway applicazione

Questa progettazione consente di filtrare e eliminare il traffico dannoso prima che raggiunga 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. Esistono tre modalità in cui è possibile configurare teoricamente Firewall di Azure:

• Firewall di Azure con regole DNAT: Firewall di Azure scambia solo gli indirizzi IP a livello di indirizzo IP, ma non elabora il payload. Di conseguenza, non cambia alcuna intestazione HTTP.

• Firewall di Azure con regole dell'applicazione e ispezione TLS disabilitata: Firewall di Azure può esaminare l'intestazione SNI in TLS, ma non la decrittografa. Viene creata una nuova connessione TCP dal firewall all'hop successivo. In questo esempio si tratta del gateway applicazione.

• Firewall di Azure con le regole dell'applicazione e l'ispezione TLS abilitata: Firewall di Azure esamina il contenuto dei pacchetti e li decrittografa. Funge da proxy HTTP e può impostare le intestazioni HTTP X-Forwarded-For per mantenere l'indirizzo IP. Tuttavia, presenta un certificato generato automaticamente al client. Per le applicazioni basate su Internet, l'uso di un certificato generato automaticamente non è un'opzione perché viene inviato un avviso di sicurezza ai client dell'applicazione dal browser.

Nelle prime due opzioni, che sono le uniche opzioni valide per le applicazioni basate su Internet, Firewall di Azure applica SNAT al traffico in ingresso senza impostare l'intestazione X-Forwarded-For. Di conseguenza, l'applicazione non può visualizzare l'indirizzo IP originale delle richieste HTTP. Per le attività amministrative, ad esempio la risoluzione dei problemi, è possibile ottenere l'indirizzo IP client effettivo per una connessione specifica correlandolo con i log SNAT di Firewall di Azure.

I vantaggi di questo scenario sono limitati perché, a meno che non si usi l'ispezione TLS e non presentino certificati autogenerati ai client, Firewall di Azure vede solo il traffico crittografato che passa al gateway applicazione. Questo scenario è in genere possibile solo per le applicazioni interne. Tuttavia, potrebbero esserci scenari in cui è preferibile questa progettazione. Uno scenario è se un altro Web Application Firewall esiste in precedenza nella rete (ad esempio, con Frontdoor di Azure), che può acquisire l'INDIRIZZO IP di origine originale nell'intestazione HTTP X-Forwarded-For. È anche possibile preferire questa progettazione se sono necessari molti indirizzi IP pubblici perché il gateway applicazione supporta un singolo indirizzo IP.

I flussi in ingresso HTTP(S) dalla rete Internet pubblica devono essere destinati all'indirizzo IP pubblico di Firewall di Azure. Firewall di Azure eseguirà 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 di rete virtuale standard garantisce che il traffico restituito dalle macchine virtuali di Azure torni al gateway applicazione e dal gateway applicazione a Firewall di Azure se sono state usate regole DNAT. Per il traffico proveniente dall'ambiente locale o da Azure, usare le route definite dall'utente nella subnet del gateway applicazione. Per altre informazioni, vedere la procedura dettagliata per i pacchetti più avanti in questo articolo. Tutto il traffico in uscita dalle macchine virtuali di Azure a Internet viene 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 sugli indirizzi 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 applica SNAT ai pacchetti man mano che arrivano alla 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, che è 192.168.100.7 in questo esempio. Firewall di Azure applica DNAT alla porta Web, in genere TCP 443, all'indirizzo IP privato dell'istanza del gateway applicazione. Firewall di Azure applica anche SNAT quando si esegue DNAT. Per altre informazioni, vedere problemi noti di Firewall di Azure.

   • Indirizzo IP di origine, ovvero l'indirizzo IP privato dell'istanza di Firewall di Azure: 192.168.100.7
   • Indirizzo IP di destinazione: 192.168.200.4

3. Il gateway applicazione stabilisce una nuova sessione tra l'istanza di che gestisce la connessione e uno dei server back-end. L'indirizzo IP originale del client non è incluso nel pacchetto.

   • Indirizzo IP di origine, ovvero l'indirizzo IP privato dell'istanza del gateway applicazione: 192.168.200.7
   • Indirizzo IP di destinazione: 192.168.1.4
   • intestazione X-Forwarded-For: 192.168.100.7

4. La macchina virtuale risponde al gateway applicazione, che inverte 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. Firewall di Azure vede l'indirizzo IP interno del gateway applicazione, .4, come indirizzo IP di origine, anche se la connessione proviene da un'istanza specifica del gateway applicazione, ad esempio .7.

   • Indirizzo IP di origine: 192.168.200.4
   • Indirizzo IP di destinazione: 192.168.100.7

6. Firewall di Azure annulla SNAT e DNAT e risponde al client.

   • Indirizzo IP di origine: AzFwPIP
   • Indirizzo IP di destinazione: ClientPIP

Il gateway applicazione necessita di un indirizzo IP pubblico in modo che Microsoft possa gestirlo, anche se non dispone di listener configurati per le applicazioni.

Client locali

Le progettazioni precedenti mostrano tutti i client dell'applicazione in ingresso dalla rete Internet pubblica. Anche le reti locali accedono alle applicazioni. La maggior parte delle informazioni precedenti e dei flussi di traffico è 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.

• Web Application Firewall usa l'indirizzo IP privato del gateway applicazione.

• Firewall di Azure non supporta DNAT per gli indirizzi IP privati, quindi è 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 gateway applicazione 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 perché interrompe il traffico di controllo. Per il gateway applicazione, la route predefinita deve puntare a Internet pubblico.

Architettura

Il diagramma seguente illustra la progettazione parallela del gateway applicazione e del 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 e Firewall di Azure devono avere entrambi indirizzi IP pubblici. Questi indirizzi IP pubblici consentono a Microsoft di gestire i servizi.

Topologia hub-spoke

Le progettazioni in questo articolo si applicano a una topologia hub-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 come distribuire il gateway applicazione nell'hub. I team delle applicazioni spesso gestiscono componenti come gateway applicazione o gateway di Gestione API. In questo scenario, 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, ad esempio l'indirizzo IP 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. Questa situazione causa il routing asimmetrico. Se sono presenti route definite dall'utente nelle reti virtuali spoke, assicurarsi di 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 inverso 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 di rete virtuale. 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 illustra come uno spoke invia nuovamente il traffico SNAT al servizio di bilanciamento del carico di Azure di 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 e con solo le subnet in cui si trovano i servizi condivisi. Nel diagramma precedente la route definita dall'utente corretta nello spoke deve contenere solo 192.168.1.0/24. Non deve contenere l'intero intervallo 192.168.0.0/16, contrassegnato in rosso.

Integrazione con altri prodotti Azure

È possibile integrare Firewall di Azure e il gateway applicazione 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 del gateway di Gestione API non influisce significativamente sulle progettazioni. La differenza principale è che, invece del singolo proxy inverso del gateway applicazione, sono presenti due proxy inverso concatenati tra loro.

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

AKS (Servizio Azure Kubernetes)

Per i carichi di lavoro eseguiti in un cluster del servizio Azure Kubernetes, è possibile distribuire il gateway applicazione indipendentemente dal cluster. In alternativa, è possibile integrarlo con il cluster del servizio Azure Kubernetes usando il controller di ingresso del gateway applicazione . Quando si configurano oggetti specifici 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. Fornisce 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 Limitare il traffico di rete con Firewall di Azure nel 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 Web Application Firewall elabora le richieste di connessione in ingresso alle applicazioni Web nel cluster. Firewall di Azure consente solo connessioni in uscita consentite in modo esplicito. Per altre informazioni sull'opzione di progettazione parallela, vedere architettura di base per un cluster del servizio Azure Kubernetes.

Frontdoor di Azure

frontdoor di Azure include funzionalità che si sovrappongono al gateway applicazione in diverse aree. Entrambi i servizi forniscono web application firewalling, offload SSL e routing basato su URL. Tuttavia, una differenza fondamentale è che mentre il gateway applicazione opera 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 in questo articolo è ancora applicabile, ad eccezione dell'opzione per posizionare Firewall di Azure davanti a Frontdoor di Azure.

Uno scenario consiste nell'usare Firewall di Azure davanti al gateway applicazione nella rete virtuale. Il gateway applicazione inserisce l'intestazione X-Forwarded-For con l'indirizzo IP dell'istanza del firewall, non con 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 raggiunga Firewall di Azure. È anche possibile proteggere l'origine con collegamento privato di Azure 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 potrebbero 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 attive e la scalabilità automatica configurazioni in modo che queste appliance non siano un collo di bottiglia per le applicazioni eseguite nella rete virtuale.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autore principale:

• Jose Moreno | Principal Customer Engineer

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Altre informazioni sulle tecnologie dei componenti:

• Che cos'è il gateway applicazione?
• Che cos'è Firewall di Azure?
• Che cos'è Frontdoor di Azure?
• Azure Kubernetes Service
• Che cos'è la rete virtuale?
• Che cos'è web application firewall?
• Architettura di base per un cluster del servizio Azure Kubernetes

Risorse correlate

Esplorare le architetture correlate:

• Implementare una rete ibrida sicura
• applicazioni Web gestite in modo sicuro
• Proteggere il bot del canale e l'app Web di Microsoft Teams con un firewall
• software multi-tenant come servizio in Azure
• distribuzione di Enterprise usando l'ambiente del servizio app
• distribuzione aziendale a disponibilità elevata usando l'ambiente del servizio app