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 i servizi di sicurezza di Azure Rete virtuale come Protezione DDoS di Azure, Firewall di Azure e gateway app Azure lication, quando usare ogni servizio e opzioni di progettazione di rete che combinano entrambi.

• Protezione DDoS di Azure, in combinazione con le procedure consigliate per la progettazione di applicazioni, offre funzionalità avanzate di mitigazione DDoS per difendersi meglio 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 funzionalità NAT (Network Address Translation). Firewall di Azure basa il filtraggio dei pacchetti su indirizzi IP (Internet Protocol) e porte TCP/UDP (Transmission Control Protocol/User Datagram Protocol) o su attributi HTTP(S) o SQL basati su applicazione. Questo firewall applica inoltre la tecnologia di intelligence sulle minacce di 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 sistema di rilevamento e protezione dalle intrusioni (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 X-Forwarded-For HTTP. Il gateway applicazione usa inoltre Web application firewall per ispezionare 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 componente aggiuntivo facoltativo del gateway applicazione di Azure. Fornisce funzionalità di ispezione delle richieste HTTP e impedisce attacchi dannosi a livello Web, come quelli di tipo SQL injection o scripting intersito. Per altre informazioni, vedere la documentazione di Web application firewall.

Questi servizi di Azure sono complementari. A seconda dei carichi di lavoro uno dei due può risultare più efficace dell'altro oppure è possibile usarli insieme per una protezione ottimale a livello di rete e di applicazione. Usare l'albero delle decisioni seguente e gli esempi in questo articolo per individuare l'opzione di sicurezza migliore per la rete virtuale della propria applicazione.

Firewall di Azure e il gateway applicazione di Azure usano tecnologie diverse e supportano funzionalità di sicurezza per flussi diversi:

Flusso applicazione	Può essere filtrato da Firewall di Azure	Può essere filtrato da Web application firewall nel gateway applicazione
Traffico HTTP(S) da ambiente locale o Internet ad Azure (in ingresso)	Sì	Sì
Traffico HTTP(S) da Azure ad ambiente locale o Internet (in uscita)	Sì	No
Traffico non HTTP(S), in ingresso o in uscita	Sì	No

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

In questo articolo vengono illustrate le opzioni di progettazione ampiamente consigliate in base al diagramma di flusso e altre opzioni applicabili in scenari meno comuni:

• Solo Firewall di Azure, quando non sono presenti applicazioni Web nella rete virtuale. In questo scenario viene controllato sia il traffico in ingresso verso le applicazioni sia il traffico in uscita.
• Solo il gateway applicazione, quando sono presenti solo applicazioni Web nella rete virtuale e i gruppi di sicurezza di rete forniscono un filtraggio di output sufficiente. Le funzionalità fornite da Firewall di Azure possono impedire molti scenari di attacco( ad esempio esfiltrazione di dati, IDPS e così via). A causa di questo motivo, lo scenario solo 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 è una delle opzioni di progettazione più comuni, che viene scelta quando si vuole usare il gateway applicazione di Azure per proteggere 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.
• Il gateway applicazione davanti a Firewall di Azure, quando si vuole che Firewall di Azure ispezioni tutto il traffico e Web application firewall protegga il traffico Web. L'applicazione deve conoscere l'indirizzo IP di origine del client. Con Firewall di Azure Premium e l'ispezione TLS, questa opzione di progettazione supporta anche lo scenario SSL end-to-end.
• Firewall di Azure davanti al gateway applicazione, quando si vuole che Firewall di Azure ispezioni e filtri il traffico prima che raggiunga il gateway applicazione. Poiché Firewall di Azure non esegue la decrittografia del traffico HTTPS, la funzionalità che aggiunge al gateway applicazione è limitata. Questo scenario non è documentato nel diagramma di flusso sopra illustrato.

Nell'ultima parte di questo articolo vengono descritte alcune varianti delle opzioni di progettazione di base elencate, ovvero:

• Client applicazioni locali.
• Reti hub-spoke.
• Implementazioni del servizio Azure Kubernetes Service.

È possibile aggiungere altri servizi di proxy inverso, 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 Web application firewall, è possibile usare solo Firewall di Azure. In questo caso l'opzione di progettazione è semplice, ma un'analisi del flusso dei pacchetti sarà utile per comprendere opzioni di progettazione più complesse. In questa progettazione tutto il traffico in ingresso viene inviato alla 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 del 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 nel diagramma seguente.

La tabella seguente include un riepilogo dei flussi di traffico per questo scenario:

Flow	Passa attraverso gateway applicazione/Web application firewall	Passa attraverso Firewall di Azure
Traffico HTTP(S) da Internet o ambiente locale ad Azure	N/D	Sì (vedere di seguito)
Traffico HTTP(S) da Azure a Internet o ambiente locale	N/D	Sì
Traffico non HTTP(S) da Internet o ambiente locale ad Azure	N/D	Sì
Traffico non HTTP(S) da Azure a Internet o ambiente locale	N/D	Sì

Firewall di Azure non ispeziona il traffico HTTP(S) in ingresso, Ma sarà in grado di applicare regole di livello 3 e livello 4 e regole dell'applicazione basate su FQDN. Firewall di Azure ispeziona il traffico HTTP(S) in uscita a seconda del livello di Firewall di Azure e della configurazione dell'ispezione TLS:

• Firewall di Azure Standard esamina solo gli attributi di livello 3 e 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 User-Agent) e l'abilitazione dell'ispezione TLS per l'analisi più approfondita dei pacchetti. Firewall di Azure non è equivalente a Web application firewall. Se nella rete virtuale sono presenti carichi di lavoro Web, è consigliabile usare Web application firewall.

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

• Firewall di Azure servizio distribuisce diverse istanze, qui con l'indirizzo IP front-end 192.168.100.4 e gli indirizzi interni dell'intervallo 192.168.100.0/26. Queste singole istanze sono in genere invisibili all'amministratore di Azure. È tuttavia utile notare la differenza in alcuni casi, ad esempio durante la risoluzione dei problemi di rete.
• Se il traffico proviene da una rete privata virtuale (VPN) locale o da un 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 il Source NAT per impostazione predefinita.

Architettura

Il diagramma seguente mostra 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 del Firewall di Azure:
   • Indirizzo IP di origine: ClientPIP
   • Indirizzo IP di destinazione: AzFwPIP
2. La richiesta all'indirizzo IP pubblico Firewall di Azure viene distribuita a un'istanza back-end del firewall, in questo caso 192.168.100.7. La regola DNAT (Destination NAT) di Firewall di Azure converte l'indirizzo IP di destinazione nell'indirizzo IP dell'applicazione all'interno della rete virtuale. Se esegue il DNAT, Firewall di Azure applica anche lo SNAT (Source NAT) al pacchetto. 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 invertendo gli indirizzi IP di origine e di destinazione. Il flusso in ingresso non richiede una route definita dall'utente 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 viene usata per le connessioni in uscita e consente di assicurarsi che i pacchetti verso la rete Internet pubblica passino 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 il gateway applicazione

Questa opzione di progettazione si applica al caso in cui nella rete virtuale sono presenti solo applicazioni Web e l'ispezione del traffico in uscita con i gruppi di sicurezza di rete è sufficiente per proteggere i flussi in uscita verso Internet.

La differenza principale rispetto all'opzione di progettazione precedente, in cui è presente solo Firewall di Azure, consiste nel fatto che il gateway applicazione non funge da dispositivo di routing con NAT, ma si comporta come un proxy di applicazione inverso completo. In altre parole, 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 devono essere inviate all'indirizzo IP pubblico del gateway applicazione, le connessioni da Azure o locali all'indirizzo IP privato del gateway. Il traffico di ritorno dalle macchine virtuali di Azure seguirà il routing standard della rete virtuale verso il gateway applicazione. Per altri dettagli, vedere l'itinerario dei pacchetti illustrato più avanti. I flussi Internet in uscita dalle macchine virtuali di Azure passano direttamente a Internet.

La tabella seguente include un riepilogo dei flussi di traffico:

Flow	Passa attraverso gateway applicazione/Web application firewall	Passa attraverso Firewall di Azure
Traffico HTTP(S) da Internet o ambiente locale ad Azure	Sì	N/D
Traffico HTTP(S) da Azure a Internet o ambiente locale	No	N/D
Traffico non HTTP(S) da Internet o ambiente locale ad Azure	No	N/D
Traffico non HTTP(S) da Azure a Internet o ambiente locale	No	N/D

Architettura

L'esempio seguente di itinerario dei pacchetti illustra come un client accede all'applicazione ospitata da una macchina virtuale dalla rete Internet pubblica.

Flusso di lavoro

1. Il client avvia la connessione all'indirizzo IP pubblico del gateway di app Azure lication:
   • Indirizzo IP di origine: ClientPIP
   • Indirizzo IP di destinazione: AppGwPIP
2. La richiesta all'indirizzo IP pubblico 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 del client originario.
   • 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 invertendo gli indirizzi IP di origine e di destinazione. La macchina virtuale sa già come raggiungere il gateway applicazione e quindi non ha bisogno di 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 di 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 originario. Alcuni server applicazioni necessitano dell'indirizzo IP del client di origine per gestire contenuto specifico della georilevazione o per la registrazione. Per altre informazioni, vedere Funzionamento di un gateway applicazione.

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

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

Firewall di Azure e gateway applicazione in parallelo

Grazie alla semplicità e alla flessibilità che lo contraddistingue, lo scenario in cui il gateway applicazione e Firewall di Azure vengono eseguiti in parallelo è spesso il migliore.

Implementare questa opzione di progettazione se nella rete virtuale è presente una combinazione di carichi di lavoro Web e non Web. Azure WAF in app Azure lication Gateway protegge il traffico in ingresso verso i carichi di lavoro Web e il Firewall di Azure controlla il traffico in ingresso per le altre applicazioni. Firewall di Azure protegge inoltre 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 e le connessioni HTTP(S) da Azure o dall'ambiente locale devono essere inviate all'indirizzo IP privato. Il routing della rete virtuale Standard invia i pacchetti dal gateway applicazione alle macchine virtuali di destinazione e viceversa. Per altri dettagli, vedere l'itinerario dei pacchetti illustrato più avanti. 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 viene inviato attraverso Firewall di Azure da route definite dall'utente (se proveniente 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 include un riepilogo dei flussi di traffico per questo scenario:

Flow	Passa attraverso gateway applicazione/Web application firewall	Passa attraverso Firewall di Azure
Traffico HTTP(S) da Internet o ambiente locale ad Azure	Sì	No
Traffico HTTP(S) da Azure a Internet o ambiente locale	No	Sì
Traffico non HTTP(S) da Internet o ambiente locale ad Azure	No	Sì
Traffico non HTTP(S) da Azure a Internet o ambiente locale	No	Sì

Questa opzione di progettazione offre filtri in uscita molto più dettagliati rispetto ai gruppi di sicurezza di rete. Ad esempio, se le applicazioni necessitano di connettività a un account 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 evitato usando semplicemente i gruppi di sicurezza di rete. Questa opzione di progettazione viene usata spesso quando il traffico in uscita richiede un filtraggio basati su FQDN. Un esempio è dato dal caso in cui si limita 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 verso Internet. Un esempio è dato dalla connessione a sistemi back-end o dal download di aggiornamenti del sistema operativo:

I passaggi del flusso di pacchetti per ogni servizio sono identici a quelli delle opzioni di progettazione autonome illustrate in precedenza.

Gateway applicazione davanti al firewall

Questa progettazione è illustrata in modo più dettagliato nella 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 sia Firewall di Azure che WAF. Web application firewall fornisce protezione a livello di applicazione Web. Firewall di Azure funge da punto centrale di registrazione e controllo e ispeziona il traffico tra il gateway applicazione e i server back-end. Il gateway applicazione e Firewall di Azure non agiscono in parallelo, ma uno dopo l'altro.

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

Questa opzione di progettazione è adatta alle applicazioni che devono conoscere gli indirizzi IP di origine dei client in ingresso, ad esempio per gestire contenuto specifico 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, impedendo così al server Web di vedere l'indirizzo IP originario 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 e le connessioni HTTP(S) da Azure o dall'ambiente locale devono essere inviate all'indirizzo IP privato. Dal gateway applicazione, le route definite dall'utente assicurano che i pacchetti vengano instradati attraverso Firewall di Azure. Per altri dettagli, vedere l'itinerario dei pacchetti illustrato più avanti. 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 viene inviato attraverso Firewall di Azure da route definite dall'utente (se proveniente 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.

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

La tabella seguente include un riepilogo dei flussi di traffico per questo scenario:

Flow	Passa attraverso gateway applicazione/Web application firewall	Passa attraverso Firewall di Azure
Traffico HTTP(S) da Internet o ambiente locale ad Azure	Sì	Sì
Traffico HTTP(S) da Azure a Internet o ambiente locale	No	Sì
Traffico non HTTP(S) da Internet o ambiente locale ad Azure	No	Sì
Traffico non HTTP(S) da Azure a Internet o ambiente locale	No	Sì

Per il traffico Web dall'ambiente locale o da Internet ad Azure, Firewall di Azure ispeziona i flussi già consentiti da Web application firewall. 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 in base a principi Zero Trust (crittografia TLS end-to-end) e Firewall di Azure riceve il traffico crittografato. Tuttavia, Firewall di Azure Standard sarà in grado di applicare regole di ispezione, ad esempio il filtro di livello 3 e livello 4 nelle regole di rete o il filtro FQDN nelle regole dell'applicazione usando l'intestazione SNI (TLS Server Name Indication). Firewall di Azure Premium 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 vedrà il traffico in ingresso in testo non crittografato. L'ispezione TLS non è necessaria in Firewall di Azure.
3. Se il sistema IDPS è abilitato in Firewall di Azure, verificherà che l'intestazione Host HTTP corrisponda all'indirizzo IP di destinazione. A tale scopo, sarà necessario eseguire la risoluzione dei nomi per l'FQDN specificato nell'intestazione Host. La risoluzione dei nomi può essere eseguita con Zone private di DNS di Azure e con le impostazioni predefinite del DNS di Firewall di Azure usando DNS di Azure. Può inoltre essere eseguita con server DNS personalizzati da configurare nelle impostazioni di Firewall di Azure. Per altre informazioni, vedere Firewall di Azure Impostazioni DNS. Se non è disponibile l'accesso amministrativo al Rete virtuale in cui viene distribuito il Firewall di Azure, quest'ultimo metodo è l'unica possibilità. Un esempio è dato dalla distribuzione di Firewall di Azure in hub protetti della rete WAN virtuale.

Architettura

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

Flusso di lavoro

Il traffico proveniente dalla rete Internet pubblica segue questo flusso:

1. Il client avvia la connessione all'indirizzo IP pubblico del gateway di app Azure lication:
   • Indirizzo IP di origine: ClientPIP
   • Indirizzo IP di destinazione: AppGwPIP
2. La richiesta all'indirizzo IP pubblico 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 a 192.168.1.0/24 nella subnet gateway applicazione inoltra il pacchetto al 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 è diretto verso un indirizzo IP privato. Inoltra il traffico alla macchina virtuale dell'applicazione, se consentito dalle regole. Per altre informazioni, vedere SNAT di 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é il Firewall di Azure proxyrà la connessione:
   • Indirizzo IP di origine se il traffico è consentito da una regola di rete Firewall di Azure: 192.168.200.7 (indirizzo IP privato di una delle istanze di 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 invertendo gli indirizzi IP di origine e di destinazione. La route definita dall'utente verso 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é è diretto verso un indirizzo IP privato, e lo inoltra al gateway applicazione.
   • Indirizzo IP di origine: 192.168.1.4
   • Indirizzo IP di destinazione: 192.168.200.7
6. Infine, l'istanza di 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 indicato dalla route definita dall'utente verso 0.0.0.0/0.

Gateway applicazione dietro il firewall

Questa opzione di progettazione consente a Firewall di Azure di filtrare ed eliminare il traffico dannoso prima che raggiunga il gateway applicazione. Può ad esempio applicare funzionalità come il filtraggio basato sull'intelligence per le 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 esegue tuttavia lo SNAT del traffico in ingresso, in modo che l'indirizzo IP originario delle richieste HTTP non risulti visibile all'applicazione. 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 ha un vantaggio limitato, perché Firewall di Azure vede solo il traffico crittografato verso il gateway applicazione. Questa opzione di progettazione può essere preferibile in alcuni scenari, ad esempio se un altro Web application firewall si trova più avanti nella rete (ad esempio, con Frontdoor di Azure) e può quindi acquisire l'indirizzo IP di origine originario nell'intestazione HTTP X-Forwarded-For. L'opzione è preferibile anche quando sono necessari molti indirizzi IP pubblici.

I flussi in ingresso HTTP(S) dalla rete Internet pubblica devono essere indirizzati all'indirizzo IP pubblico di Firewall di Azure e Firewall di Azure esegue il DNAT (e lo SNAT) dei pacchetti nell'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 dell'gateway applicazione e inoltrato tramite il Firewall di Azure con route definite dall'utente. Il routing della rete virtuale Standard assicura che il traffico restituito dalle macchine virtuali di Azure torni al gateway applicazione e quindi passi dal gateway applicazione a Firewall di Azure se sono state usate regole DNAT. Per il traffico proveniente da route definite dall'utente locali o di Azure nella subnet gateway applicazione deve essere usato (vedere la procedura dettagliata per i pacchetti per altri dettagli). Tutto il traffico in uscita dalle macchine virtuali di Azure a Internet viene inviato attraverso Firewall di Azure da route definite dall'utente.

La tabella seguente include un riepilogo dei flussi di traffico per questo scenario:

Flow	Passa attraverso gateway applicazione/Web application firewall	Passa attraverso Firewall di Azure
Traffico HTTP(S) da Internet o ambiente locale ad Azure	Sì	Sì (vedere di seguito)
Traffico HTTP(S) da Azure a Internet o ambiente locale	No	Sì
Traffico non HTTP(S) da Internet o ambiente locale ad Azure	No	Sì
Traffico non HTTP(S) da Azure a Internet o ambiente locale	No	Sì

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

Architettura

L'applicazione non può vedere l'indirizzo IP di origine originario del traffico Web. Firewall di Azure esegue lo SNAT dei pacchetti non appena arrivano 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 proveniente dalla rete Internet pubblica segue questo flusso:

1. Il client avvia la connessione all'indirizzo IP pubblico del Firewall di Azure:
   • Indirizzo IP di origine: ClientPIP
   • Indirizzo IP di destinazione: AzFWPIP
2. La richiesta all'indirizzo IP pubblico Firewall di Azure viene distribuita a un'istanza back-end del firewall, in questo caso 192.168.100.7. Firewall di Azure esegue il DNAT della porta Web, in genere TCP 443, nell'indirizzo IP privato dell'istanza del gateway applicazione. Insieme al DNAT, Firewall di Azure esegue anche lo SNAT. Per altre informazioni, vedere Firewall di Azure problemi noti:
   • 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 alle 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 di gateway applicazione specifica, ad .7esempio , 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, deve comunque avere un indirizzo IP pubblico in modo che Microsoft possa gestirlo.

client locali

Tutte le opzioni di progettazione appena illustrate mostrano client applicazioni 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 definita per i client Internet, ma esistono alcune differenze importanti:

• Un gateway VPN o un gateway ExpressRoute si trova davanti a Firewall di Azure o al gateway applicazione.
• Web application firewall usa l'indirizzo IP privato del gateway applicazione.
• Firewall di Azure non supporta il DNAT per gli indirizzi IP privati. Per questo motivo è necessario usare route definite dall'utente per inviare il traffico in ingresso verso Firewall di Azure dai gateway VPN o ExpressRoute.
• Verificare con attenzione le avvertenze relative al tunneling forzato per il gateway applicazione di Azure e per Firewall di Azure. Anche se il carico di lavoro non richiede connettività in uscita verso la rete Internet pubblica, non è possibile inserire una route predefinita come 0.0.0.0/0 per il gateway applicazione che punta alla rete locale, altrimenti si interromperà il traffico di controllo. Per il gateway applicazione di Azure, la route predefinita deve puntare alla rete Internet pubblica.

Architettura

Il diagramma seguente illustra l'opzione di progettazione con il gateway applicazione di Azure e Firewall di Azure in parallelo. I client applicazioni provengono da una rete locale connessa ad Azure tramite VPN o ExpressRoute:

Anche se tutti i client si trovano nella rete locale o in Azure, il gateway applicazione di Azure e Firewall di Azure devono avere entrambi indirizzi IP pubblici, poiché con questi indirizzi Microsoft può gestire i servizi.

Topologia hub-spoke

Le opzioni di progettazione illustrate in questo articolo sono applicabili anche a una topologia hub-spoke. Le risorse condivise nella rete virtuale di un hub centrale si connettono alle applicazioni in reti virtuali spoke separate tramite peering di reti virtuali.

Architettura

Considerazioni

Di seguito sono indicate alcune considerazioni relative a questa topologia:

• 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 gestiscono spesso componenti come gateway applicazione di Azure o gateway di Gestione API di Azure. 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 una rete spoke riceve il traffico da una determinata istanza di Firewall di Azure, come l'indirizzo 192.168.100.7 negli esempi precedenti, deve inviare il traffico di ritorno alla stessa istanza. Se una route definita dall'utente nella rete spoke imposta l'indirizzo IP di Firewall di Azure (192.168.100.4 nei diagrammi precedenti) come hop successivo del traffico indirizzato all'hub, i pacchetti di ritorno potrebbero finire in un'istanza diversa di Firewall di Azure, causando così un routing asimmetrico. Se nelle reti virtuali spoke vengono usate route definite dall'utente per inviare il traffico ai servizi condivisi nell'hub attraverso Firewall di Azure, assicurarsi che tali route non includano il prefisso della subnet di Firewall di Azure.
• La raccomandazione precedente si applica anche alla subnet del gateway applicazione e a qualsiasi appliance virtuale di rete o proxy inverso che potrebbe essere distribuito nella rete virtuale dell'hub.
• Non è possibile impostare l'hop successivo per le subnet del gateway applicazione o di Firewall di Azure tramite route statiche con un hop successivo di tipo Virtual Network. Questo tipo di hop successivo è valido solo nella rete virtuale locale e non su peering di 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 sottoposto a SNAT al servizio di bilanciamento del carico delle applicazioni (ALB) di un'istanza di Firewall di Azure. Questa configurazione genera un routing asimmetrico:

Per risolvere questo problema, specificare 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 indicato in rosso.

Integrazione con altri prodotti di 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 di proxy inverso come Gestione API nelle opzioni di progettazione precedenti per fornire funzionalità quali la limitazione delle richieste API o il proxy di autenticazione. L'integrazione di un gateway di Gestione API non modifica gli schemi di progettazione in maniera significativa. La differenza principale è data dalla presenza di due proxy inversi concatenati uno dietro l'altro in alternativa al singolo proxy inverso del gateway applicazione.

Per altre informazioni, vedere la Guida alla progettazione per integrare Gestione API e il gateway applicazione in una rete virtuale e il modello di applicazione API Gateway 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 in maniera indipendente dal cluster. In alternativa, è possibile integrare il gateway con il cluster del servizio Azure Kubernetes usando il Controller in ingresso del gateway applicazione di Azure. Quando si configurano determinati oggetti a livello di Kubernetes, ad esempio servizi e risorse in ingresso, il gateway applicazione si adatta automaticamente senza richiedere passaggi manuali aggiuntivi.

Firewall di Azure svolge un ruolo importante nella sicurezza del cluster del servizio Azure Kubernetes. Offre le funzionalità necessarie per filtrare il traffico in uscita dal cluster in base al nome di dominio completo e 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 combinano il gateway applicazione e Firewall di Azure per proteggere un cluster del servizio Azure Kubernetes, è preferibile usare l'opzione di progettazione in parallelo. Il gateway applicazione con Web application firewall elabora le richieste di connessione in ingresso verso le applicazioni Web nel cluster. Firewall di Azure consente solo connessioni in uscita autorizzate in modo esplicito. Per un esempio dell'opzione di progettazione parallela, vedere Architettura di base per un cluster servizio Azure Kubernetes del servizio Azure Kubernetes (AKS).

Frontdoor di Azure

La funzionalità Frontdoor di Azure si sovrappone in parte al gateway applicazione di Azure. Ad esempio, entrambi i servizi offrono funzionalità di firewall per applicazioni Web, offload SSL e routing basato su URL. Una delle differenze principali è data dal fatto che il gateway applicazione di Azure si trova all'interno di una rete virtuale, mentre Frontdoor di Azure è un servizio globale decentralizzato.

È talvolta possibile semplificare lo schema di progettazione della rete virtuale sostituendo il gateway applicazione con un'istanza di Frontdoor di Azure decentralizzata. La maggior parte delle opzioni di progettazione descritte in questo articolo rimane valida, ad eccezione di quella in cui Firewall di Azure è posizionato davanti a Frontdoor di Azure.

Un caso d'uso interessante consiste nel posizionamento di 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 e 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 incontri 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 sui relativi scenari d'uso, vedere Domande frequenti su Frontdoor di Azure.

Altre appliance virtuali di rete

I prodotti Microsoft non sono l'unica opzione per implementare Web application firewall o funzionalità firewall di nuova generazione in Azure. Un'ampia gamma di partner Microsoft offre appliance virtuali di rete (NVA). I concetti e le opzioni di progettazione sono essenzialmente uguali a quelli illustrati in questo articolo, ma è opportuno tenere presenti alcune considerazioni importanti:

• Le appliance virtuali di rete dei partner per i firewall di nuova generazione possono offrire maggiore controllo e flessibilità per le configurazioni NAT non supportate da Firewall di Azure, ad esempio DNAT dalla rete locale o DNAT dalla rete Internet senza SNAT.
• Le appliance virtuali di rete gestite da Azure, come 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 per molte appliance.
• Quando si usano appliance virtuali di rete in Azure, adottare configurazioni di tipo attivo-attivo con scalabilità automatica in modo che tali appliance non costituiscano un collo di bottiglia per le applicazioni in esecuzione nella rete virtuale.

Collaboratori

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

Autore principale:

• Jose Moreno | Principal Customer Engineer

Passaggi successivi

Altre informazioni sulle tecnologie dei componenti:

• Cos'è il gateway applicazione di Azure?
• Cos'è Firewall di Azure?
• Che cos'è Frontdoor di Azure?
• Servizio Azure Kubernetes
• Che cos'è Azure Rete virtuale?
• 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 di canale e dell'app Web di Microsoft Teams dietro un firewall
• Portale di servizi sanitari rivolto ai consumatori in Azure
• Considerazioni sulla sicurezza per le app IaaS estremamente sensibili in Azure
• SaaS multi-tenant in Azure
• Distribuzione aziendale con ambiente servizio app s
• Distribuzione aziendale a disponibilità elevata con servizio app Environment
• Architettura di base per un cluster del servizio Azure Kubernetes (servizio Azure Kubernetes AKS)