Implementare una rete Zero Trust per le applicazioni Web usando Firewall di Azure e il gateway applicazione di Azure

Questo articolo descrive come implementare la sicurezza Zero Trust per le app Web per abilitare l'ispezione e la crittografia end-to-end. Il modello Zero Trust include molti altri concetti, ad esempio la verifica continua dell'identità e la riduzione al minimo delle dimensioni delle aree di attendibilità implicite.

Questo articolo è incentrato sul componente di crittografia e ispezione di un'architettura Zero Trust per il traffico in ingresso da Internet pubblico. Per altre informazioni su altri aspetti della distribuzione sicura dell'applicazione, ad esempio l'autenticazione e l'autorizzazione, vedere la documentazione di Zero Trust. L'esempio in questo articolo usa un approccio multilivello. In un approccio multilivello, la sicurezza di rete costituisce uno dei livelli del modello Zero Trust. In questo livello, le appliance di rete controllano i pacchetti per garantire che solo il traffico legittimo raggiunga le applicazioni.

In genere, diversi tipi di appliance di rete controllano diversi aspetti dei pacchetti di rete:

• I web application firewall cercano modelli che indicano un attacco a livello di applicazione Web.

• I firewall di nuova generazione possono anche cercare minacce generiche.

Questa architettura è incentrata su un modello comune per ottimizzare la sicurezza, in cui il gateway applicazione di Azure controlla ed elabora il traffico prima che raggiunga Firewall di Azure Premium. In alcuni scenari, è possibile combinare diversi tipi di appliance di sicurezza di rete per aumentare la protezione. Per altre informazioni, vedere Firewall di Azure e gateway applicazione per le reti virtuali.

Architettura

In questo diagramma, una freccia etichettata HTTPS punta da un'icona che rappresenta i client alle icone che rappresentano il Gateway Applicazione e il Firewall per Applicazioni Web di Azure. Un'altra freccia etichettata come HTTPS punta da queste icone all'icona di Azure Firewall Premium. Due frecce puntano dall'icona Premium di Firewall di Azure. Una freccia è denominata Domain Name System (DNS) e punta a un server DNS o a una zona privata. L'altra freccia è contrassegnata con l'etichetta HTTPS e punta a un'icona che rappresenta macchine virtuali di Azure.

Scaricare un file di Visio di questa architettura.

Questa architettura usa il protocollo TLS (Transport Layer Security) per crittografare il traffico in ogni passaggio.

1. Un client invia pacchetti al gateway applicazione, un servizio di bilanciamento del carico. Viene eseguito con l'aggiunta facoltativa di Web application firewall di Azure.

2. Il gateway applicazione decrittografa i pacchetti e cerca le minacce alle applicazioni Web. Se non trova minacce, usa i principi Zero Trust per crittografare i pacchetti. Quindi li rilascia.

3. Firewall di Azure Premium esegue i controlli di sicurezza seguenti:

   • L'ispezione TLS decrittografa ed esamina i pacchetti.
   • Le funzionalità di rilevamento e prevenzione delle intrusioni (IDPS) controllano i pacchetti per individuare finalità dannose.

4. Se i pacchetti superano i test, Firewall di Azure Premium esegue questi passaggi:

   • Crittografa i pacchetti.
   • Usa un servizio DNS (Domain Name System) per determinare la macchina virtuale (VM) dell'applicazione.
   • Inoltra i pacchetti alla macchina virtuale dell'applicazione.

Vari motori di ispezione in questa architettura garantiscono l'integrità del traffico:

• Web application firewall di Azure usa regole per impedire attacchi a livello Web. Esempi di attacchi includono l'inserimento di codice SQL e lo scripting tra siti. Per altre informazioni sulle regole e sul set di regole di base OWASP (Open Worldwide Application Security Project), vedere Regole e gruppi di regole CRS del web application firewall.

• Firewall di Azure Premium usa regole generiche di rilevamento e prevenzione delle intrusioni. Queste regole consentono di identificare file dannosi e altre minacce destinate alle applicazioni Web.

Questa architettura supporta i tipi di progettazione di rete seguenti, illustrati in questo articolo:

• Reti hub-spoke tradizionali
• Reti che usano la rete WAN virtuale di Azure come piattaforma
• Reti che usano il server di route di Azure per semplificare il routing dinamico

Risoluzione dei nomi e premium di Firewall di Azure

Quando Firewall di Azure Premium verifica la presenza di traffico dannoso, verifica che l'intestazione host HTTP corrisponda all'indirizzo IP del pacchetto e alla porta TCP (Transmission Control Protocol). Si supponga, ad esempio, che il gateway applicazione invii pacchetti Web all'indirizzo IP 172.16.1.4 e alla porta TCP 443. Il valore dell'intestazione host HTTP deve essere risolto in tale indirizzo IP.

Le intestazioni host HTTP in genere non contengono indirizzi IP. Le intestazioni contengono invece nomi corrispondenti al certificato digitale del server. In questo caso, Firewall di Azure Premium usa DNS per risolvere il nome dell'intestazione host in un indirizzo IP. La progettazione di rete determina quale soluzione DNS funziona al meglio.

Annotazioni

Il gateway applicazione non supporta i numeri di porta nelle intestazioni host HTTP. Di conseguenza:

• Firewall di Azure Premium presuppone una porta TCP HTTPS predefinita 443.
• La connessione tra il gateway applicazione e il server Web supporta solo la porta TCP 443, non le porte non standard.

Certificati digitali

Il diagramma seguente mostra i nomi comuni (CN) e le autorità di certificazione (CA) usati dalle sessioni e dai certificati TLS di questa architettura.

In questo diagramma, una freccia etichettata HTTPS punta da un'icona che rappresenta i client alle icone che rappresentano il Gateway Applicazione e il Firewall per Applicazioni Web di Azure. Sul lato sinistro di queste icone sono il CN, myapp.contoso.com e la CA DigiCert. Sul lato destro di queste icone è la CA radice di Firewall di Azure nelle impostazioni HTTP. Un'altra freccia etichettata come HTTPS punta da queste icone all'icona di Azure Firewall Premium. Sul lato sinistro di questa icona si trovano il CN, myapp.contoso.com, e l'autorità di certificazione, CA di Azure Firewall. Un'altra freccia con etichetta HTTPS punta a un'icona che rappresenta macchine virtuali di Azure. Sul lato sinistro di questa icona è presente il CN, myapp.contoso.com e la CA DigiCert.

Firewall di Azure genera dinamicamente i propri certificati. Questa funzionalità è uno dei motivi principali per cui si trova dietro l'Application Gateway. In caso contrario, il client dell'applicazione viene confrontato con i certificati generati automaticamente contrassegnati come rischio per la sicurezza.

Connessioni TLS

Questa architettura contiene tre connessioni TLS distinte. I certificati digitali convalidano ognuno di essi.

Dai client al gateway applicazione

Nel gateway applicazione si distribuisce il certificato digitale visualizzato dai client. Una CA nota, ad esempio DigiCert o Let's Encrypt, rilascia in genere un certificato di questo tipo. Questo meccanismo è fondamentalmente diverso dal modo in cui il Firewall di Azure genera dinamicamente i certificati digitali da un'autorità di certificazione autofirmata o da un'infrastruttura a chiave pubblica interna.

Dal gateway applicazione a Firewall di Azure Premium

Per decrittografare ed esaminare il traffico TLS, Firewall di Azure Premium genera in modo dinamico i certificati. Firewall di Azure Premium si presenta anche al gateway applicazione come server Web. Una CA privata firma i certificati generati da Firewall di Azure Premium. Per altre informazioni, vedere i certificati Premium di Firewall di Azure. Il gateway applicazione deve convalidare tali certificati. Nelle impostazioni HTTP dell'applicazione configurare la CA radice usata da Firewall di Azure Premium.

Da Firewall di Azure Premium al server Web

Firewall di Azure Premium stabilisce una sessione TLS con il server Web di destinazione. Firewall di Azure Premium verifica che una CA nota firma i pacchetti TLS del server Web.

Ruoli dei componenti

Il gateway applicazione e Firewall di Azure Premium gestiscono i certificati in modo diverso l'uno dall'altro perché i ruoli differiscono:

• Il gateway applicazione è un proxy Web inverso . Protegge i server Web da client dannosi intercettando le richieste HTTP e HTTPS. Ogni server protetto che si trova nel pool back-end del gateway applicazione viene dichiarato con l'indirizzo IP o il nome di dominio completo. I client legittimi devono essere in grado di accedere a ogni applicazione. Configuri quindi il gateway dell'applicazione con un certificato digitale firmato da un'autorità di certificazione pubblica. Usare una CA accettata da qualsiasi client TLS.

• Firewall di Azure Premium è un proxy Web o semplicemente un proxy Web. Protegge i client da server Web dannosi intercettando le chiamate TLS dai client protetti. Quando un client protetto effettua una richiesta HTTP, il proxy Web di inoltro rappresenta il server Web di destinazione generando certificati digitali e presentandoli al client. Firewall di Azure Premium usa una CA privata, che firma i certificati generati dinamicamente. I client protetti vengono configurati in modo che considerino attendibile la CA privata. In questa architettura Firewall di Azure Premium protegge le richieste dal gateway applicazione al server Web. Il gateway applicazione considera attendibile la CA privata usata da Firewall di Azure Premium.

Routing e inoltro del traffico

Il routing è leggermente diverso a seconda della topologia della progettazione della rete. Le sezioni seguenti descrivono esempi di topologie hub-spoke, rete WAN virtuale e server di route. Tutte le topologie presentano gli aspetti seguenti in comune:

• Il gateway applicativo funge sempre da proxy. Firewall di Azure Premium funge anche da proxy quando è configurato per l'ispezione TLS. Il gateway applicazione termina le sessioni TLS dai client e le nuove sessioni TLS vengono compilate per Firewall di Azure. Azure Firewall riceve e termina le sessioni TLS generate dall'Application Gateway e crea nuove sessioni TLS verso i carichi di lavoro. Questo processo influisce sulla configurazione IDPS di Firewall di Azure Premium. Per altre informazioni, vedere IDPS e indirizzi IP privati.

• Il carico di lavoro vede le connessioni provenienti dall'indirizzo IP della subnet del Firewall di Azure. L'indirizzo IP client originale viene mantenuto nell'intestazione X-Forwarded-For HTTP inserita da Application Gateway. Firewall di Azure supporta anche l'inserimento dell'indirizzo IP del client di origine nell'intestazione X-Forwarded-For . In questo scenario, l'indirizzo IP del client di origine è l'indirizzo IP del gateway applicazione.

• Il traffico dal gateway applicazione al carico di lavoro viene in genere inviato a Firewall di Azure usando meccanismi di routing di Azure. Questi meccanismi includono route definite dall'utente configurate nella subnet del Gateway Applicazione o route che la rete WAN Virtuale o il server di route iniettano. È possibile definire in modo esplicito l'indirizzo IP privato di Firewall di Azure nel pool back-end del gateway applicazione, ma non è consigliabile farlo perché rimuove alcune delle funzionalità native del gateway applicazione, ad esempio il bilanciamento del carico e la persistenza della sessione.

Le sezioni seguenti descrivono alcune delle topologie più comuni che è possibile usare con Firewall di Azure e Application Gateway.

Topologia hub-spoke

Una progettazione hub e spoke distribuisce in genere componenti di rete condivisi nella rete virtuale dell'hub e componenti specifici dell'applicazione negli spoke. Nella maggior parte dei sistemi, Firewall di Azure Premium è una risorsa condivisa. Web application firewall di Azure può essere un dispositivo di rete condiviso o un componente specifico dell'applicazione. È una prassi consigliata trattare il gateway dell'applicazione come componente dell'applicazione e distribuirlo in una rete virtuale spoke per i motivi seguenti:

• Può essere difficile risolvere i problemi relativi agli avvisi di Web application firewall di Azure. In genere è necessaria una conoscenza approfondita dell'applicazione per decidere se i messaggi che attivano tali allarmi sono legittimi.

• Se si considera l'Application Gateway come una risorsa condivisa, è possibile superare i limiti dell'Application Gateway.

• Se si distribuisce il gateway applicazione nell'hub, è possibile che si verifichino problemi di controllo degli accessi in base al ruolo. Questa situazione può verificarsi quando i team gestiscono applicazioni diverse, ma usano la stessa istanza del gateway applicazione. Ogni team ha quindi accesso all'intera configurazione del gateway applicazione.

Nelle architetture hub-spoke tradizionali, le zone private DNS offrono un modo semplice per usare DNS:

1. Configurare una zona privata DNS.
2. Collegare la zona alla rete virtuale che contiene Firewall di Azure Premium.
3. Assicurarsi che esista un record di indirizzo per il valore utilizzato da Application Gateway per il traffico e per i controlli di integrità.

Il diagramma seguente mostra il flusso di pacchetti quando il gateway applicazione si trova in una rete virtuale spoke. In questo caso, un client si connette dalla rete Internet pubblica.

Il diagramma è costituito da due sezioni principali, la rete virtuale hub e la rete virtuale spoke. Una freccia blu rappresenta il percorso di una richiesta client da Internet alla subnet dell'applicazione nella rete virtuale spoke. La freccia blu inizia da un'icona che rappresenta Internet e punta alla subnet del gateway di applicazione nella rete virtuale secondaria (spoke). La freccia blu prosegue dalla subnet del Gateway Applicazione alla subnet dell'Azure Firewall nella rete virtuale hub. Punta quindi dalla subnet di Firewall di Azure alla subnet dell'applicazione nella rete virtuale spoke. Un peering di rete virtuale a due lati collega la rete virtuale hub e le sezioni della rete virtuale spoke. Una freccia verde rappresenta il percorso della richiesta client dalla subnet dell'applicazione al client. La freccia verde inizia nella subnet dell'applicazione e punta alla subnet di Firewall di Azure. La freccia verde continua dalla subnet del Firewall di Azure alla subnet dell'Application Gateway e torna al client.

1. Un client invia una richiesta a un server Web.

2. Il gateway applicazione intercetta i pacchetti client ed esamina i pacchetti. Se i pacchetti superano l'ispezione, Application Gateway invia i pacchetti alla macchina virtuale back-end. Quando i pacchetti raggiungono Azure, una route definita dall'utente nella subnet del Gateway Applicazione li inoltra ad Azure Firewall Premium.

3. Firewall di Azure Premium esegue controlli di sicurezza sui pacchetti. Se superano i test, Firewall di Azure Premium inoltra i pacchetti alla macchina virtuale dell'applicazione.

4. La macchina virtuale risponde e imposta l'indirizzo IP di destinazione sul gateway dell'applicazione. Una route definita dall'utente nella subnet della macchina virtuale reindirizza i pacchetti a Firewall di Azure Premium.

5. Firewall di Azure Premium inoltra i pacchetti al gateway applicazione.

6. Il gateway applicazione risponde al client.

Il traffico può anche arrivare da una rete locale anziché da Internet pubblico. Il traffico passa attraverso una rete privata virtuale (VPN) da sito a sito o tramite Azure ExpressRoute. In questo scenario, il traffico raggiunge prima un gateway di rete virtuale nell'hub. Il resto del flusso di rete è uguale al diagramma precedente.

Il diagramma è costituito da due sezioni principali, la rete virtuale hub e la rete virtuale spoke. Una freccia blu rappresenta il percorso di una richiesta client dall'ambiente locale alla macchina virtuale dell'applicazione. La freccia blu inizia dal client on-premise e punta alla subnet del gateway di rete virtuale nella rete virtuale hub. La freccia blu continua dalla subnet del gateway di rete virtuale alla subnet del gateway dell'applicazione nella rete virtuale 'spoke'. Punta quindi alla subnet di Firewall di Azure nella rete virtuale hub e continua con la subnet dell'applicazione nella rete virtuale spoke. Un peering di rete virtuale a due lati collega la rete virtuale hub e le sezioni della rete virtuale spoke. Una freccia verde rappresenta il percorso della richiesta client dalla macchina virtuale dell'applicazione al client locale. La freccia verde inizia nella macchina virtuale dell'applicazione e punta alla subnet di Firewall di Azure. Punta quindi alla subnet del gateway dell'applicazione, al gateway di rete virtuale e quindi al client.

1. Un client locale si connette al gateway di rete virtuale.

2. Il gateway di rete virtuale inoltra i pacchetti client all'Application Gateway.

3. Il gateway applicazione esamina i pacchetti. Se superano l'ispezione, una route definita dall'utente nella subnet del gateway applicazione inoltra i pacchetti a Firewall di Azure Premium.

4. Firewall di Azure Premium esegue controlli di sicurezza sui pacchetti. Se superano i test, Firewall di Azure Premium inoltra i pacchetti alla macchina virtuale dell'applicazione.

5. La macchina virtuale risponde e imposta l'indirizzo IP di destinazione sul gateway applicazione. Una route definita dall'utente nella subnet della macchina virtuale reindirizza i pacchetti a Firewall di Azure Premium.

6. Firewall di Azure Premium inoltra i pacchetti al gateway applicazione.

7. Il gateway applicazione invia i pacchetti al gateway di rete virtuale.

8. Il gateway di rete virtuale risponde al client.

Topologia della rete WAN virtuale

È anche possibile usare il servizio di rete rete WAN virtuale in questa architettura. Questo componente offre molti vantaggi. Ad esempio, elimina la necessità di route definite dall'utente nelle reti virtuali spoke. È invece possibile definire route statiche nelle tabelle di route dell'hub virtuale. La programmazione di ogni rete virtuale che ci si connette all'hub contiene quindi queste route.

Quando si usa la rete WAN virtuale come piattaforma di rete, due differenze principali risultano:

• Non è possibile collegare zone private DNS a un hub virtuale perché Microsoft gestisce gli hub virtuali. Il proprietario della sottoscrizione non dispone delle autorizzazioni per collegare le zone DNS private. Di conseguenza, non è possibile associare una zona privata DNS all'hub sicuro che contiene Firewall di Azure Premium.

  Per implementare la risoluzione DNS per Firewall di Azure Premium, usare invece i server DNS:

  • Configurare le impostazioni DNS di Firewall di Azure per l'uso di server DNS personalizzati.

  • Distribuire i server in una rete virtuale di servizi condivisi che si connettono alla rete WAN virtuale.

  • Collegare una zona privata DNS alla rete virtuale dei servizi condivisi. I server DNS possono quindi risolvere i nomi usati dal gateway applicazione nelle intestazioni host HTTP. Per altre informazioni, vedere Impostazioni del DNS di Firewall di Azure.

• È possibile usare la rete WAN virtuale solo per programmare le route in uno spoke se il prefisso è più breve (meno specifico) del prefisso della rete virtuale. Nei diagrammi precedenti, ad esempio, la rete virtuale spoke ha il prefisso 172.16.0.0/16. In questo caso, la rete WAN virtuale non è in grado di inserire una route corrispondente al prefisso di rete virtuale (172.16.0.0/16) o a una delle subnet (172.16.0.0/24, 172.16.1.0/24). In altre parole, la rete WAN virtuale non può indirizzare il traffico tra due subnet che si trovano nella stessa rete virtuale.

  Questa limitazione diventa evidente quando il gateway applicazione e il server Web di destinazione si trovano nella stessa rete virtuale. La rete WAN virtuale non può forzare il traffico tra Application Gateway e il server Web a passare attraverso Azure Firewall Premium. Una soluzione alternativa consiste nel configurare manualmente le UDR nelle subnet del Gateway delle applicazioni e del Server Web.

Il diagramma seguente illustra il flusso di pacchetti in un'architettura che usa la rete WAN virtuale. In questo scenario, l'accesso al gateway applicazione proviene da una rete locale. Un'istanza VPN da sito a sito o ExpressRoute connette tale rete alla rete WAN virtuale. L'accesso basato su Internet segue un percorso simile.

Il diagramma è costituito da quattro sezioni, la rete virtuale hub, la rete virtuale del gateway applicazione, la rete virtuale dell'applicazione e la rete virtuale dei servizi condivisi. Una freccia blu rappresenta il percorso di una richiesta client dall'ambiente locale alla macchina virtuale dell'applicazione. La freccia blu inizia dal client locale e punta al gateway VPN nella rete virtuale hub. La freccia blu punta quindi dal gateway VPN alla subnet del gateway di applicazione nella rete virtuale del gateway di applicazione. Continua dalla subnet dell'Application Gateway a un'icona che rappresenta Azure Firewall Premium nella rete virtuale del hub. Punta quindi dall'icona di Azure Firewall Premium verso la subnet DNS nella rete virtuale dei servizi condivisi. Una freccia verde rappresenta il percorso della richiesta del client al client locale. La freccia verde inizia nella subnet DNS e punta all'icona Premium di Firewall di Azure nella rete virtuale hub. Una freccia blu rappresenta i pacchetti che superano i controlli di sicurezza Premium di Firewall di Azure. Punta alla macchina virtuale dell'applicazione nella rete virtuale dell'applicazione. La freccia verde torna a Azure Firewall Premium, attraversa la subnet del gateway applicazione, il gateway VPN, e infine torna al client.

1. Un client locale si connette al gateway VPN.

2. Il gateway VPN inoltra i pacchetti client al Gateway Applicazione.

3. Il gateway applicazione esamina i pacchetti. Se superano l'ispezione, la subnet del gateway applicazione inoltra i pacchetti a Firewall di Azure Premium.

4. Firewall di Azure Premium richiede la risoluzione DNS da un server DNS nella rete virtuale dei servizi condivisi.

5. Il server DNS risponde alla richiesta di risoluzione.

6. Firewall di Azure Premium esegue controlli di sicurezza sui pacchetti. Se superano i test, Firewall di Azure Premium inoltra i pacchetti alla macchina virtuale dell'applicazione.

7. La macchina virtuale risponde e imposta l'indirizzo IP di destinazione sul gateway applicazione. La subnet dell'applicazione reindirizza i pacchetti a Firewall di Azure Premium.

8. Firewall di Azure Premium inoltra i pacchetti al gateway applicazione.

9. Il gateway applicativo invia i pacchetti al gateway VPN.

10. Il gateway VPN risponde al client.

Se si usa questa progettazione, potrebbe essere necessario modificare il routing annunciato dall'hub alle reti virtuali spoke. In particolare, il gateway applicativo v2 supporta solo una 0.0.0.0/0 rotta che punta a internet. Le route con questo indirizzo che non puntano a Internet interrompono la connettività richiesta da Microsoft per la gestione del gateway applicazione. Se l'hub virtuale annuncia una 0.0.0.0/0 route, impedendo che la route venga propagata alla subnet dell'Application Gateway eseguendo uno dei passaggi seguenti:

• Creare una tabella di route con una route per 0.0.0.0/0 e un tipo di hop successivo di Internet. Associare tale route alla subnet in cui si distribuisce il gateway applicazione.

• Se si distribuisce il gateway applicazione in uno spoke dedicato, disabilitare la propagazione della route predefinita nelle impostazioni per la connessione di rete virtuale.

Topologia del server di route

Route Server offre un altro metodo per inserire automaticamente le route nei nodi. Usare questa funzionalità per evitare il sovraccarico amministrativo della gestione delle tabelle di route. Il server di route combina le varianti della rete WAN virtuale e dell'hub e spoke:

• È possibile usare Il server di route per gestire le reti virtuali hub. Di conseguenza, è possibile collegare la rete virtuale hub a una zona privata DNS.

• Il server di route presenta la stessa limitazione per cui la rete WAN virtuale presenta prefissi di indirizzi IP. È possibile inserire route in uno spoke solo se il prefisso è più breve (meno specifico) del prefisso della rete virtuale. A causa di questa limitazione, il gateway applicazione e il server Web di destinazione devono trovarsi in reti virtuali diverse.

Il diagramma seguente illustra il flusso di pacchetti quando Il server di route semplifica il routing dinamico. Considerare i punti seguenti:

• Il server di route richiede attualmente il dispositivo che inserisce le route da inviare tramite BGP (Border Gateway Protocol). Firewall di Azure Premium non supporta BGP, quindi usare invece un'appliance virtuale di rete (NVA) non Microsoft.

• La funzionalità dell'appliance virtuale di rete nell'hub determina se l'implementazione necessita di DNS.

Il diagramma è costituito da quattro sezioni, la rete virtuale hub, la rete virtuale del gateway applicazione, la rete virtuale dell'applicazione e la rete virtuale dei servizi condivisi. La rete virtuale hub contiene tre blocchi che rappresentano la subnet del gateway di rete virtuale, la subnet del server di route e la subnet dell'appliance virtuale di rete. Una freccia blu rappresenta il percorso di una richiesta client dall'ambiente locale alla macchina virtuale dell'applicazione. La freccia blu inizia dal client locale e punta al gateway di rete virtuale nella sezione rete virtuale hub. La freccia blu punta quindi alla subnet del Gateway Applicazione nella rete virtuale del Gateway Applicazione. La freccia blu continua verso la subnet NVA nella rete virtuale hub. Punta quindi dalla subnet NVA alla subnet DNS nella rete virtuale dei servizi condivisi. Una freccia verde rappresenta il percorso della richiesta del client al client locale. Inizia dalla subnet DNS e indirizza alla subnet della NVA nella rete virtuale hub. Una freccia blu rappresenta i pacchetti che superano i controlli di sicurezza dell'NVA. Punta alla macchina virtuale dell'applicazione nella rete virtuale dell'applicazione. La freccia verde punta nuovamente alla subnet dell'NVA e continua nella subnet del gateway applicazione, quindi al gateway di rete virtuale e infine torna al client.

1. Un client locale si connette al gateway di rete virtuale.

2. Il gateway di rete virtuale inoltra i pacchetti client all'Application Gateway.

3. Il gateway applicazione esamina i pacchetti. Se superano l'ispezione, la subnet del gateway applicativo inoltra i pacchetti a una macchina back-end. Il Route Server inserisce una route nella subnet dell'Application Gateway che inoltra il traffico a un'appliance virtuale di rete (NVA).

4. La subnet NVA richiede la risoluzione del DNS da un server DNS nella rete virtuale dei servizi condivisi.

5. Il server DNS risponde alla richiesta di risoluzione.

6. L'appliance virtuale di rete esegue controlli di sicurezza sui pacchetti. Se superano i test, l'appliance virtuale di rete inoltra i pacchetti alla macchina virtuale dell'applicazione.

7. La macchina virtuale dell'applicazione risponde e imposta l'indirizzo IP di destinazione sull'Application Gateway. Il Route Server inserisce un percorso nella subnet della macchina virtuale che reindirizza i pacchetti all'NVA.

8. L'appliance virtuale di rete inoltra i pacchetti al gateway applicazione.

9. Il gateway applicazione invia i pacchetti al gateway di rete virtuale.

10. Il gateway di rete virtuale risponde al client.

Analogamente alla rete WAN virtuale, potrebbe essere necessario modificare il routing quando si usa Il server di route. Se si annuncia la 0.0.0.0/0 route, potrebbe essere propagata alla subnet del gateway applicazione. Ma il gateway applicazione non supporta tale route. In questo caso, configurare una tabella di route per la subnet del gateway applicazione. Includere una route per 0.0.0.0/0 e un tipo di hop successivo di Internet in tale tabella.

IDPS e indirizzi IP privati

Firewall di Azure Premium decide quali regole IDPS applicare in base agli indirizzi IP di origine e di destinazione dei pacchetti. Per impostazione predefinita, Firewall di Azure considera gli indirizzi IP privati negli intervalli RFC 1918 (10.0.0.0/8, 192.168.0.0/16e 172.16.0.0/12) e RFC 6598 (100.64.0.0/10) come interni. Pertanto, se si distribuisce l'Application Gateway in una subnet in uno di questi intervalli, Azure Firewall Premium considera il traffico tra l'Application Gateway e il carico di lavoro come interno. Pertanto, vengono usate solo le firme IDPS contrassegnate per essere applicate al traffico interno o a qualsiasi traffico. Le firme IDPS contrassegnate per essere applicate al traffico in ingresso o in uscita non vengono applicate al traffico tra il Gateway Applicazione e il carico di lavoro. Per altre informazioni, vedere Regole IDPS di Firewall di Azure.

Il modo più semplice per applicare le regole di firma in ingresso IDPS al traffico tra il Gateway Applicazione e il workload consiste nel collocare il Gateway Applicazione in una subnet che utilizza un prefisso al di fuori degli intervalli privati. Non è necessario usare necessariamente indirizzi IP pubblici per questa subnet. È invece possibile personalizzare gli indirizzi IP considerati da Firewall di Azure Premium come interni per IDPS. Ad esempio, se l'organizzazione non usa l'intervallo 100.64.0.0/10, è possibile eliminare questo intervallo dall'elenco dei prefissi interni per IDPS e distribuire il Gateway Applicazione in una subnet configurata con un indirizzo IP in 100.64.0.0/10. Per altre informazioni, vedere Intervalli IPDS privati di Firewall di Azure Premium.

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

• Proteggere le reti con Zero Trust
• Instradamento del traffico della rete virtuale
• Funzionamento di un gateway applicazione

" output is necessary.)

• Implementare una rete ibrida sicura
• Topologia di rete hub-spoke in Azure
• Topologia di rete hub-spoke che usa la rete WAN virtuale