Rete Zero Trust per le applicazioni Web con Firewall di Azure e gateway applicazione

Questa guida descrive una strategia per implementare la 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 esaminano aspetti diversi dei pacchetti di rete:

• I web application firewall ricercano 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 gli schemi progettuali che è possibile usare per organizzare le varie appliance. Questo documento si concentra su un modello comune per ottimizzare la sicurezza, in cui il gateway applicazione di Azure agisce prima del Firewall di Azure Premium. La figura seguente illustra questo modello:

Scaricare un file di Visio di questa architettura.

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

• 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.

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

• Firewall di Azure Premium esegue i controlli di sicurezza:

  • L'ispezione Transport Layer Security (TLS) decrittografa ed esamina i pacchetti.
  • Le funzionalità di rilevamento e protezione delle intrusioni controllano la presenza di finalità dannose nei pacchetti.

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

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

Diversi 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 code injection SQL e scripting intersito. Per altre informazioni sulle regole e sul set di regole OWASP (Open Web Application Security Project) di base, vedere Regole e gruppi di regole CRS di Web application firewall.
• Firewall di Azure Premium usa regole generiche di rilevamento e prevenzione delle intrusioni. Queste regole consentono di identificare i file dannosi e altre minacce per le applicazioni Web.

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

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

Firewall di Azure Premium e risoluzione dei nomi

Quando esegue l'analisi per individuare 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 risolversi in tale indirizzo IP.

Le intestazioni host HTTP in genere non contengono indirizzi IP. Al contrario, le intestazioni contengono nomi che corrispondono 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 della rete determina la soluzione DNS più adatta, come descritto nelle sezioni successive.

Certificati digitali

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

Connessioni TLS

Questa architettura contiene tre connessioni TLS distinte. I certificati digitali convalidano ognuna di esse:

Dai client al gateway applicazione

Nel gateway applicazione si distribuisce il certificato digitale visualizzato dai client. Un'autorità di certificazione nota, ad esempio DigiCert o Let's Encrypt, in genere emette un certificato di questo tipo.

Dal gateway applicazione al Firewall di Azure Premium

Per decrittografare ed esaminare il traffico TLS, Firewall di Azure Premium genera i certificati in modo dinamico. Firewall di Azure Premium si presenta anche al gateway applicazione come server Web. Un'autorità di certificazione privata firma i certificati generati da Firewall di Azure Premium. Per altre informazioni, vedere Certificati di Firewall di Azure Premium. Il gateway applicazione deve convalidare tali certificati. Nelle impostazioni HTTP dell'applicazione si configura l'autorità di certificazione 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 un'autorità di certificazione nota firmi 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 relativi ruoli sono diversi:

• Il gateway applicazione è un proxy Web inverso. Protegge i server Web da client dannosi intercettando le richieste HTTP e HTTPS. Ogni server protetto presente nel pool back-end del gateway applicazione viene dichiarato con il relativo indirizzo IP o 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 un'autorità di certificazione pubblica. Usare un'autorità di certificazione che verrà accettata da qualsiasi client TLS.
• Firewall di Azure Premium è un proxy Web di inoltro 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 un'autorità di certificazione privata, che firma i certificati generati dinamicamente. Configurare i client protetti in modo da considerare attendibile l'autorità di certificazione privata. In questa architettura, Firewall di Azure Premium protegge le richieste dal gateway applicazione al server Web. Il gateway applicazione considera attendibile l'autorità di certificazione privata usata da Firewall di Azure Premium.

Routing e inoltro del traffico

Il routing sarà leggermente diverso a seconda della topologia della progettazione di rete, le sezioni seguenti illustrano in dettaglio le specifiche di Hub e Spoke, rete WAN virtuale e gli esempi di topologia del server di route. Esistono tuttavia alcuni aspetti comuni a tutte le topologie:

• app Azure lication Gateway 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 da 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 creeranno 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 visualizzerà le connessioni provenienti dall'indirizzo IP della subnet del Firewall di Azure. L'indirizzo IP del client originale viene mantenuto nell'intestazione X-Forwarded-For HTTP 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 route definite dall'utente configurate nella subnet del gateway applicazione o con route inserite da Azure rete WAN virtuale o dal server di route di Azure. Sebbene sia possibile definire in modo esplicito l'indirizzo IP privato del Firewall di Azure nel pool back-end di gateway applicazione, è tecnicamente sconsigliato poiché elimina alcune delle funzionalità di Firewall di Azure, ad esempio il bilanciamento del carico e la persistenza.

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

Topologia hub-spoke

In genere, una progettazione hub-spoke distribuisce componenti di rete condivisi nella rete virtuale hub e componenti specifici dell'applicazione negli spoke. Nella maggior parte dei sistemi, Firewall di Azure Premium è una risorsa condivisa. Web application firewall può tuttavia essere un dispositivo di rete condiviso o un componente specifico dell'applicazione. Per i motivi seguenti, in genere è meglio 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 una risorsa condivisa, è possibile che si superino i limiti del gateway applicazione di Azure.
• Se si distribuisce il gateway applicazione nell'hub, potrebbero verificarsi 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 DNS private offrono un modo semplice per usare DNS:

• Configurare una zona DNS privata.
• Collegare la zona alla rete virtuale che contiene Firewall di Azure Premium.
• Assicurarsi che esista un record A per il valore che il gateway applicazione usa per il traffico e per i controlli di integrità.

Il diagramma seguente illustra 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 e li esamina. 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 i controlli di sicurezza nei 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 per il 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é dalla rete Internet pubblica. Il traffico passa attraverso una rete privata virtuale (VPN) da sito a sito o ExpressRoute. In questo scenario, il traffico raggiunge prima un gateway di rete virtuale nell'hub. Il resto del flusso di rete è lo stesso del 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 i controlli di sicurezza nei 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 per il 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 rete WAN virtuale

In questa architettura, è anche possibile usare la rete WAN virtuale del servizio di rete. Questo componente offre numerosi vantaggi. Ad esempio, elimina la necessità delle 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 con cui ci si connette all'hub contiene quindi queste route.

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

• Non è possibile collegare zone DNS private 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 DNS privata all'hub protetto che contiene Firewall di Azure Premium. Per implementare la risoluzione DNS per Firewall di Azure Premium, usare invece i server DNS:

  • Configurare le impostazioni del DNS di Firewall di Azure per l'uso di server DNS personalizzati.
  • Distribuire i server in una rete virtuale di servizi condivisi che si connette alla rete WAN virtuale.
  • Collegare una zona DNS privata alla rete virtuale dei servizi condivisi. I server DNS possono quindi risolvere i nomi utilizzati dal gateway applicazione nelle intestazioni host HTTP. Per altre informazioni, vedere Impostazioni del DNS di Firewall di Azure.

• È possibile usare 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, rete WAN virtuale non sarebbe 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, rete WAN virtuale non può attirare il traffico tra due subnet che si trovano nella stessa rete virtuale. Questa limitazione diventa evidente quando gateway applicazione e il server Web di destinazione si trovano nella stessa rete virtuale: rete WAN virtuale non può forzare il traffico tra 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 in cui viene usata la rete WAN virtuale. In questo caso, l'accesso al gateway applicazione viene da una rete locale. Una VPN da sito a sito o ExpressRoute connette la rete alla rete WAN virtuale. L'accesso da Internet è simile.

1. Un client locale si connette alla VPN.
2. La rete privata virtuale 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 i controlli di sicurezza nei 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 per il 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 rete privata virtuale.
10. La rete privata virtuale risponde al client.

Con questa progettazione, potrebbe essere necessario modificare il routing che l'hub annuncia 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 della route alla subnet del gateway applicazione tramite uno di questi passaggi:

• Creare una tabella di route con una route per 0.0.0.0/0 e un tipo di hop successivo di Internet. Associare la 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

Il server di route offre un altro modo per inserire automaticamente le route negli spoke. Con questa funzionalità si evita il sovraccarico amministrativo dovuto alla gestione delle tabelle di route. Il server di route combina la rete WAN virtuale e le varianti hub-spoke:

• Con il server di route, i clienti gestiscono le reti virtuali hub. Di conseguenza, è possibile collegare la rete virtuale hub a una zona DNS privata.
• Il server di route ha la stessa limitazione che la rete WAN virtuale presenta relativamente ai prefissi degli 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 essere in reti virtuali diverse.

Il diagramma seguente illustra il flusso di pacchetti quando il server di route semplifica il routing dinamico. Tenere presente quanto segue:

• Il server di route richiede attualmente il dispositivo che inserisce le route per inviarle tramite Border Gateway Protocol (BGP). 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 del gateway applicazione inserita dal server di route inoltra il traffico a un'appliance virtuale di rete.
4. L'appliance virtuale di rete esegue i 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 per il 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, questa 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 nella tabella.

IDPS e indirizzi IP privati

Come illustrato in Firewall di Azure regole IDPS, 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/8192.168.0.0/16e 172.16.0.0/12) e RFC 6598 (100.64.0.0/10) come interni. Di conseguenza, se come nei diagrammi di questo articolo la gateway applicazione viene distribuita 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 verranno usate 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 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 che Firewall di Azure Premium considerano interni per IDPS. Ad esempio, se l'organizzazione non usa l'intervallo100.64.0.0/10, è possibile eliminare questo intervallo dall'elenco dei prefissi interni per IDPS (vedere Firewall di Azure intervalli IPDS privati Premium per altri dettagli su come eseguire questa operazione) e distribuire gateway applicazione in una subnet configurata con un indirizzo IP in 100.64.0.0/10.

Collaboratori

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

Autore principale:

• Jose Moreno | Principal Customer Engineer

Passaggi successivi

• Proteggere le reti con Zero Trust
• Routing del traffico di rete virtuale
• Funzionamento del gateway applicazione

Risorse correlate

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