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

Diagramma dell'architettura che mostra il flusso di pacchetti in una rete di web app che usa il Application Gateway davanti al Firewall di Azure Premium.

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 all'Application Gateway. Viene eseguito con l'aggiunta facoltativa di Web application firewall di Azure.

  2. Application Gateway esegue la terminazione TLS. Se Web application firewall di Azure è abilitato, controlla la richiesta di minacce all'applicazione Web. Il gateway applicazione stabilisce quindi una nuova sessione TLS e inoltra le richieste consentite in base alle regole di routing configurate.

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

  4. Se i pacchetti superano questi controlli, 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

Firewall di Azure Premium e risoluzione dei nomi

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 corrispondere a quell'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 utilizza 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 delle applicazioni 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.

Diagramma che mostra i CN e le CA usate da una rete di app Web quando un servizio di bilanciamento del carico si trova davanti a un firewall.

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 applicativo si distribuisce il certificato digitale che i client vedono. 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 all'Application Gateway come server web. Il certificato CA intermedio configurato per Firewall di Azure Premium firma i certificati generati Firewall di Azure Premium. Per altre informazioni, vedere i certificati Premium di Firewall di Azure. Il gateway applicativo deve convalidare tali certificati. Nelle impostazioni del back-end di Application Gateway (talvolta denominate impostazioni HTTP), caricare il certificato della CA radice corrispondente (.cer) come certificato radice attendibile.

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 applicativo e il Firewall Premium di Azure gestiscono i certificati in modo diverso tra loro perché i loro ruoli differiscono.

  • Il gateway applicativo è 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 dell'Application Gateway viene specificato 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 in avanti. Ciò significa che funge da proxy Web, proteggendo 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, il Firewall di Azure Premium protegge le richieste dal gateway delle applicazioni al server web. Il Gateway Applicazione considera attendibile la CA privata usata dal Firewall di Azure Premium.

Instradamento 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:

  • Application Gateway agisce sempre come proxy. In questa architettura, Firewall di Azure Premium funge anche da proxy perché l'ispezione TLS è abilitata in una regola dell'applicazione. Application Gateway termina le sessioni TLS provenienti dai client e stabilisce nuove sessioni TLS verso Firewall di Azure. Firewall di Azure termina tali sessioni e compila nuove sessioni TLS verso i carichi di lavoro. Se il traffico corrisponde invece a una regola di rete, Firewall di Azure lo inoltra senza l'ispezione TLS delle regole dell'applicazione. Se Firewall di Azure applica criteri IDPS dipende dalla configurazione IDPS. Per altre informazioni, vedere IDPS e indirizzi IP privati.

  • Per il traffico elaborato da una regola dell'applicazione, il carico di lavoro vede le connessioni provenienti dall'indirizzo IP della subnet Firewall di Azure perché le regole dell'applicazione forzano il firewall a fungere da proxy, con l'effetto che la destinazione finale vede il pacchetto come proveniente dagli indirizzi IP del firewall. Anche se il proxy non è uguale alla conversione degli indirizzi, è possibile semplificare questo comportamento con il modello mentale che le regole dell'applicazione usano sempre SNAT (Source Network Address Translation). 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 distribuisci l'Application Gateway nell'hub, potresti affrontare problemi di controllo degli accessi basati sul 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 Application Gateway si trova in una rete virtuale spoke. In questo caso, un client si connette dalla rete Internet pubblica.

Diagramma che mostra il flusso di pacchetti in una rete hub-spoke che include un servizio di bilanciamento del carico e un firewall. I client si connettono dalla rete Internet pubblica.

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

  2. Il gateway applicativo intercetta i pacchetti client ed esamina. Se i pacchetti superano l'ispezione, Application Gateway invia i pacchetti alla VM back-end. Una UDR nella subnet di Application Gateway imposta Firewall di Azure Premium come hop successivo, quindi i pacchetti passano attraverso Firewall di Azure Premium prima di raggiungere la VM dell'applicazione.

  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 in una nuova connessione TLS.

  4. La macchina virtuale risponde direttamente al firewall, poiché Firewall di Azure usa le regole dell'applicazione e quindi la macchina virtuale vede solo gli indirizzi IP di Firewall di Azure come origini.

  5. Firewall di Azure Premium riconosce dalle tabelle interne che questa connessione proviene dal gateway applicazione e inoltra il traffico di conseguenza.

  6. Il gateway applicativo 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.

Diagramma che mostra il flusso di pacchetti in una rete hub-spoke che include un servizio di bilanciamento del carico e un firewall. I client si connettono da una rete locale.

  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. L'Application Gateway esamina i pacchetti. Se superano l'ispezione, una Route Definita dall'Utente (UDR) 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 in una nuova connessione TLS.

  5. La macchina virtuale risponde direttamente al firewall, poiché Firewall di Azure usa le regole dell'applicazione e quindi la macchina virtuale vede solo gli indirizzi IP di Firewall di Azure come origini.

  6. Firewall di Azure Premium riconosce dalle tabelle interne che questa connessione proviene dal gateway applicazione e inoltra il traffico di conseguenza.

  7. Application Gateway invia i pacchetti al client, con il gateway di rete virtuale come hop successivo.

  8. Il gateway di rete virtuale inoltra i pacchetti 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 UDR 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 a cui si connette all'hub contiene queste rotte.

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

  • 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 connette alla WAN virtuale.

    • Collegare una zona privata DNS alla rete virtuale dei servizi condivisi. I server DNS possono quindi risolvere i nomi usati dall'Application Gateway 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 Firewall di Azure 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 gateway VPN da sito a sito o ExpressRoute connette la rete a rete WAN virtuale. Il flusso di pacchetti seguente descrive il traffico attraverso un gateway VPN, ma il flusso attraverso un gateway ExpressRoute sarebbe identico. L'accesso basato su Internet segue un percorso simile.

Diagramma che mostra il flusso di pacchetti in una rete hub-spoke che include un servizio di bilanciamento del carico, un firewall e una rete WAN virtuale.

  1. Un client locale si connette al gateway VPN dell'hub virtuale.

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

  3. L'Application Gateway esamina i pacchetti. Se superano l'ispezione, la subnet di Application Gateway inoltra i pacchetti ad 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 in una nuova connessione TLS.

  7. La macchina virtuale risponde direttamente al firewall, poiché Firewall di Azure usa le regole dell'applicazione e quindi la macchina virtuale vede solo gli indirizzi IP di Firewall di Azure come origini.

  8. Firewall di Azure Premium riconosce dalle tabelle interne che questa connessione proviene dal gateway applicazione e inoltra il traffico di conseguenza.

  9. Il gateway applicativo invia i pacchetti al client, avendo come hop successivo il gateway VPN dell'hub virtuale.

  10. Il gateway VPN dell'hub virtuale inoltra i pacchetti al client.

In passato, era necessario modificare il routing annunciato dall'hub verso le reti virtuali spoke, poiché Application Gateway v2 supportava solo una route 0.0.0.0/0 con tipo di hop successivo Internet. Tuttavia, questa limitazione è stata risolta con la funzionalità distribuzione di Private Application Gateway. Al momento della stesura di questo articolo, è necessario eseguire manualmente l'onboarding della sottoscrizione Azure a questa funzionalità. Se è stato effettuato il provisioning di Application Gateway prima di abilitare questa funzionalità, è necessario assicurarsi che non venga propagata alcuna route predefinita alla subnet di Application Gateway tramite uno dei due metodi 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 deployerai il Gateway di Applicazione.

  • Se si distribuisce l'Application Gateway in uno spoke dedicato, disabilitare la propagazione della rotta predefinita nelle impostazioni per la connessione di rete virtuale.

NVA e Route Server

È possibile usare appliance virtuali di rete che terminano ed esaminano le connessioni TLS in questa topologia. Facoltativamente, è possibile utilizzare Route Server per inserire automaticamente le route negli spoke. Usare questa funzionalità per evitare il sovraccarico amministrativo della gestione delle tabelle di route. Il Route Server combina le varianti della WAN virtuale e della topologia hub and 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 ha la stessa limitazione della WAN virtuale riguardo ai 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 questa topologia è applicabile solo per appliance virtuali di rete di terze parti.

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

Diagramma che mostra il flusso di pacchetti in una rete hub-spoke che include un servizio di bilanciamento del carico, un firewall e un server di route.

  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. L'Application Gateway 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'NVA esegue controlli di sicurezza sui pacchetti. Se superano i test, l'NVA inoltra i pacchetti alla macchina virtuale dell'applicazione in una nuova connessione TLS.

  7. La macchina virtuale risponde direttamente all'appliance virtuale di rete, poiché l'appliance virtuale di rete si comporta come proxy e avvia una nuova connessione TLS. Di conseguenza, la macchina virtuale dell'applicazione vede solo gli indirizzi IP dell'NVA come indirizzi di origine.

  8. L'NVA sa, in base alle proprie tabelle interne, che questa connessione proviene da Application Gateway e inoltra il traffico di conseguenza.

  9. Il gateway applicativo invia i pacchetti al client, avendo il gateway di rete virtuale come hop successivo.

  10. Il gateway di rete virtuale inoltra i pacchetti al client.

Come per rete WAN virtuale, potrebbe essere necessario modificare il routing quando si usa Route Server, a meno che Application Gateway non sia stato sottoposto a provisioning dopo aver abilitato la funzionalità di distribuzione di Application Gateway privato. Se si annuncia la 0.0.0.0/0 route dall'NVA ad Server di route Azure, per impostazione predefinita, viene propagata alla subnet di Application Gateway. Se il tuo Application Gateway non supporta le distribuzioni private, non supporta quel percorso. In tal caso, configurare una tabella di routing per la subnet di Application Gateway e includere in tale tabella una rotta per 0.0.0.0/0 con un tipo di hop successivo pari a Internet.

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, Firewall di Azure 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:

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

Passaggi successivi

  • Last updated on