Rete senza attendibilità per le applicazioni Web con Firewall di Azure e il gateway applicazione

Questa guida descrive una strategia per l'implementazione di sicurezza senza attendibilità per le app Web per l'ispezione e la crittografia. Il paradigma zero-trust include molti altri concetti, ad esempio la verifica costante dell'identità degli attori o la riduzione delle dimensioni delle aree di attendibilità implicite al minimo. Questo articolo si riferisce al componente di crittografia e ispezione di un'architettura senza trust per il traffico in ingresso da Internet pubblico. Leggere altri documenti senza attendibilità per altri aspetti della distribuzione sicura dell'applicazione, ad esempio l'autenticazione. Ai fini di questo articolo, un approccio multilivello funziona al meglio, in cui 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.

In alcune situazioni, è possibile combinare diversi tipi di appliance di sicurezza di rete per aumentare la protezione. Una guida separata, firewall e gateway applicazione per le reti virtuali, descrive i modelli di progettazione che è possibile usare per disporre le varie appliance. Questo documento è incentrato su un modello comune per ottimizzare la sicurezza, in cui il gateway applicazione di Azure agisce prima di Firewall di Azure Premium. Il diagramma seguente illustra questo modello:

Scaricare un file di Visio di questa architettura.

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

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

• Il gateway applicazione decrittografa i pacchetti e cerca le minacce alle applicazioni Web. Se non trova alcuna minaccia, usa principi zero-trust per crittografare i pacchetti. Quindi li rilascia.

• Firewall di Azure Premium esegue controlli di sicurezza:

  • 'ispezione TLS (Transport Layer Security) decrittografa ed esamina i pacchetti.
  • il rilevamento e la protezione delle intrusioni funzionalità controllano i pacchetti per finalità dannose.

• 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 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 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 Web Application Security Project), vedere Web Application Firewall CRS rule groups and rules.
• 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 diversi tipi di progettazione di rete, 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 si verifica il traffico dannoso, Firewall di Azure Premium verifica che l'intestazione host HTTP corrisponda all'indirizzo IP del pacchetto e alla porta TCP. 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 la soluzione DNS più adatta, come descritto nelle sezioni successive.

Certificati digitali

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

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.

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. Configurare quindi il gateway applicazione con un certificato digitale firmato da una CA pubblica. Usare una CA che qualsiasi client TLS accetterà.
• 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 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 sarà leggermente diverso a seconda della topologia della progettazione della rete, le sezioni seguenti illustrano in dettaglio gli esempi di topologia hub-spoke, rete WAN virtuale e server di route. Esistono tuttavia alcuni aspetti comuni a tutte le topologie:

• Il gateway applicazione di Azure si comporta sempre come proxy e Firewall di Azure Premium funziona anche quando è configurato per l'ispezione TLS: le sessioni TLS dai client verranno terminate dal gateway applicazione e le nuove sessioni TLS verranno compilate per Firewall di Azure. Firewall di Azure riceverà e terminerà le sessioni TLS generate dal gateway applicazione e creerà nuove sessioni TLS verso i carichi di lavoro. Questo fatto ha implicazioni per la configurazione IDPS di Firewall Di Azure Premium, le sezioni più avanti contengono altri dettagli su questo argomento.
• Il carico di lavoro vedrà le connessioni provenienti dall'indirizzo IP della subnet di Firewall di Azure. L'indirizzo IP client originale viene mantenuto nell'intestazione HTTP X-Forwarded-For inserita dal gateway applicazione.
• Il traffico dal gateway applicazione al carico di lavoro viene in genere inviato al Firewall di Azure usando meccanismi di routing di Azure, con User-Defined route configurate nella subnet del gateway applicazione o con route inserite dalla rete WAN virtuale di Azure o dal server di route di Azure. Sebbene sia possibile definire in modo esplicito l'indirizzo IP privato di Firewall di Azure nel pool back-end del gateway applicazione, è tecnicamente sconsigliato perché elimina alcune delle funzionalità di Firewall di Azure, ad esempio bilanciamento del carico e persistenza.

Le sezioni seguenti illustrano in dettaglio alcune delle topologie più comuni usate con Firewall di Azure e il gateway applicazione.

Topologia hub-spoke

In genere, una progettazione hub-spoke distribuisce componenti di rete condivisa nella rete virtuale hub e componenti specifici dell'applicazione negli spoke. Nella maggior parte dei sistemi, Firewall di Azure Premium è una risorsa condivisa. Ma Web Application Firewall può essere un dispositivo di rete condiviso o un componente specifico dell'applicazione. Per i motivi seguenti, in genere è preferibile considerare il gateway applicazione come componente dell'applicazione e distribuirlo in una rete virtuale spoke:

• Può essere difficile risolvere i problemi relativi agli avvisi di Web Application Firewall. In genere è necessaria una conoscenza approfondita dell'applicazione per decidere se i messaggi che attivano tali allarmi sono legittimi.
• Se si considera il gateway applicazione come risorsa condivisa, è possibile superare limiti del gateway applicazione di Azure.
• 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.

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

• Configurare una zona privata DNS.
• Collegare la zona alla rete virtuale che contiene Firewall di Azure Premium.
• Assicurarsi che esista un record A per il valore usato dal gateway applicazione 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.

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, il gateway applicazione invierà il pacchetto alla macchina virtuale back-end. Quando il pacchetto raggiunge Azure, una route definita dall'utente nella subnet del gateway applicazione inoltra i pacchetti a Firewall di Azure 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 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 ExpressRoute. In questo scenario, il traffico raggiunge prima un gateway di rete virtuale nell'hub. Il resto del flusso di rete è uguale al caso precedente.

1. Un client locale si connette al gateway di rete virtuale.
2. Il gateway inoltra i pacchetti client al gateway applicazione.
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 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 il collegamento di 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 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. Ad esempio, nei diagrammi sopra la rete virtuale spoke è presente il prefisso 172.16.0.0/16: in questo caso, La rete WAN virtuale non è in grado di inserire una route corrispondente al prefisso della 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ò attirare 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 il gateway applicazione e il server Web per passare attraverso Firewall di Azure Premium (una soluzione alternativa consiste nella configurazione manuale delle route definite dall'utente nelle subnet del gateway applicazione e del server Web).

Il diagramma seguente illustra il flusso di pacchetti in un caso che usa la rete WAN virtuale. In questo caso, l'accesso al gateway applicazione proviene da una rete locale. Una VPN da sito a sito o ExpressRoute connette tale rete alla rete WAN virtuale. L'accesso da Internet è simile.

1. Un client locale si connette alla VPN.
2. La 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 applicazione invia i pacchetti alla VPN.
10. La VPN risponde al client.

Con questa progettazione, potrebbe essere necessario modificare il routing annunciato dall'hub alle reti virtuali spoke. In particolare, il gateway applicazione v2 supporta solo una route 0.0.0.0/0 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 route 0.0.0.0/0, impedire la propagazione di tale route alla subnet del gateway applicazione 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

server di route offre un altro modo per inserire automaticamente le route negli spoke. Con questa funzionalità, è possibile 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:

• Con Il server di route, i clienti gestiscono 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. Tenere presente questi punti:

• Il server di route richiede attualmente il dispositivo che inserisce le route da inviare tramite BGP (Border Gateway Protocol). Poiché Firewall di Azure Premium non supporta BGP, usare invece un'appliance virtuale di rete di terze parti.
• La funzionalità dell'appliance virtuale di rete nell'hub determina se l'implementazione necessita di DNS.

1. Un client locale si connette al gateway di rete virtuale.
2. Il gateway 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 un computer back-end. Una route nella subnet ApplicationGateway inserita dal server di route inoltra il traffico a un'appliance virtuale di rete.
4. 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.
5. La macchina virtuale risponde e imposta l'indirizzo IP di destinazione sul gateway applicazione. Una route inserita nella subnet della macchina virtuale dal server di route reindirizza i pacchetti all'appliance virtuale di rete.
6. L'appliance virtuale di rete inoltra i pacchetti al gateway applicazione.
7. Il gateway applicazione invia i pacchetti al gateway di rete virtuale.
8. Il gateway risponde al client.

Come per la rete WAN virtuale, potrebbe essere necessario modificare il routing quando si usa il server di route. Se si annuncia la route 0.0.0.0/0, potrebbe propagarsi 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

Come illustrato in regole IDPS del firewall di Azure, Firewall di Azure Premium deciderà quali regole IDPS applicare a seconda degli indirizzi IP di origine e di destinazione dei pacchetti. Firewall di Azure considererà gli indirizzi IP privati predefiniti negli intervalli RFC 1918 (10.0.0.0/8, 192.168.0.0/16 e 172.16.0.0/12) e l'intervallo RFC 6598 (100.64.0.0/10) come interno. Di conseguenza, se come nei diagrammi di questo articolo il gateway applicazione viene distribuito in una subnet in uno di questi intervalli (172.16.0.0/24 negli esempi precedenti), Firewall di Azure Premium considererà il traffico tra il gateway applicazione e il carico di lavoro da interno e solo le firme IDPS contrassegnate per essere applicate al traffico interno o a qualsiasi traffico. Le firme IDPS contrassegnate per essere applicate per il traffico in ingresso o in uscita non verranno applicate al traffico tra il gateway applicazione e il carico di lavoro.

Il modo più semplice per forzare l'applicazione delle regole di firma in ingresso IDPS al traffico tra il gateway applicazione e il carico di lavoro consiste nell'inserire il gateway applicazione in una subnet con un prefisso esterno agli intervalli privati. Non è necessario usare necessariamente indirizzi IP pubblici per questa subnet, ma è possibile personalizzare gli indirizzi IP considerati come interni per IDPS da Firewall di Azure Premium. Ad esempio, se l'organizzazione non usa l'intervallo di 100.64.0.0/10, è possibile eliminare questo intervallo dall'elenco dei prefissi interni per IDPS (vedere intervalli IPDS privati di Firewall di Azure per altri dettagli su come eseguire questa operazione) e distribuire il gateway applicazione in una subnet configurata con un indirizzo IP in 100.64.0.0/10.

Contributori

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

Autore principale:

• Jose Moreno | Principal Customer Engineer

Passaggi successivi

• Reti sicure con senza attendibilità
• routing del traffico di rete virtuale
• Funzionamento di un gateway applicazione

Risorse correlate

• [Proteggere e gestire i carichi di lavoro con segmentazione a livello di rete][Proteggere e gestire i carichi di lavoro con segmentazione a livello di rete]
• Implementare una rete ibrida sicura
• topologia di rete hub-spoke in Azure
• topologia di rete hub-spoke con la rete WAN virtuale di Azure