Distribuzione del gateway applicazione privato (anteprima)
Introduzione
In passato, gli SKU v2 del gateway applicazione e, in un certo modo i v1, hanno richiesto indirizzi IP pubblici per abilitare la gestione del servizio. Questo requisito ha imposto diverse limitazioni nell'uso di controlli granulari nei gruppi di sicurezza di rete e nelle tabelle di route. In particolare, sono state osservate le sfide seguenti:
- Tutte le distribuzioni di gateway applicazione v2 devono contenere la configurazione IP front-end pubblico per abilitare la comunicazione con il tag del servizio Gateway Manager.
- Le associazioni del gruppo di sicurezza di rete richiedono regole per consentire l'accesso in ingresso da GatewayManager e l'accesso in uscita a Internet.
- Quando si introduce una route predefinita (0.0.0.0/0) per inoltrare il traffico in qualsiasi punto diverso da Internet, metriche, monitoraggio e aggiornamenti del gateway, si verifica un errore.
Il gateway applicazione v2 può ora risolvere ognuno di questi elementi per eliminare ulteriormente il rischio di esfiltrazione dei dati e controllare la privacy della comunicazione dall'interno della rete virtuale. Queste modifiche includono le funzionalità seguenti:
- Configurazione IP front-end solo indirizzo IP privato
- Nessuna risorsa indirizzo IP pubblico necessaria
- Eliminazione del traffico in ingresso dal tag del servizio GatewayManager tramite il gruppo di sicurezza di rete
- Possibilità di definire una regola Nega tutto per il gruppo di sicurezza di rete in uscita (NSG) per limitare il traffico in uscita verso Internet
- Possibilità di eseguire l'override della route predefinita a Internet (0.0.0.0/0)
- Risoluzione DNS tramite resolver definiti nella rete virtuale Altre informazioni, incluse le zone DNS private di collegamento privato.
Ognuna di queste funzionalità può essere configurata in modo indipendente. Ad esempio, un indirizzo IP pubblico può essere usato per consentire il traffico in ingresso da Internet ed è possibile definire una regola Nega tutto in uscita nella configurazione del gruppo di sicurezza di rete per impedire l'esfiltrazione dei dati.
Eseguire l'onboarding nell'anteprima pubblica
Le funzionalità dei nuovi controlli della configurazione front-end IP privato, il controllo sulle regole del gruppo di sicurezza di rete e il controllo sulle tabelle di route sono attualmente in anteprima pubblica. Per partecipare all'anteprima pubblica, è possibile acconsentire esplicitamente all'esperienza usando il portale di Azure, PowerShell, l'interfaccia della riga di comando o l'API REST.
Quando si partecipa all'anteprima, tutti i nuovi gateway applicazione effettuano il provisioning con la possibilità di definire qualsiasi combinazione delle funzionalità di NSG, tabella di route o di configurazione IP privata. Se si vuole rifiutare esplicitamente la nuova funzionalità e tornare alla funzionalità disponibile a livello generale corrente del gateway applicazione, è possibile annullare la registrazione dall'anteprima.
Per altre informazioni sulle funzionalità di anteprima, vedere Configurare le funzionalità di anteprima nella sottoscrizione di Azure
Registrarsi all'anteprima
Usare la procedura seguente per eseguire la registrazione nell'anteprima pubblica per i controlli di rete del gateway applicazione avanzati tramite il portale di Azure:
Accedere al portale di Azure.
Nella casella di ricerca immettere sottoscrizioni e selezionare Sottoscrizioni.
Selezionare il collegamento per il nome della sottoscrizione.
Nel menu a sinistra, in Impostazioni selezionare Funzionalità di anteprima.
Viene visualizzato un elenco delle funzionalità di anteprima disponibili e lo stato di registrazione corrente.
In Anteprima funzionalità digitare nella casella di filtro EnableApplicationGatewayNetworkIsolation, selezionare la funzionalità e fare clic su Registra.
Nota
La registrazione delle funzionalità può richiedere fino a 30 minuti per passare dalla registrazione allo stato registrato.
Per altre informazioni sulle funzionalità di anteprima, vedere Configurare le funzionalità di anteprima nella sottoscrizione di Azure
Annullare la registrazione dall'anteprima
Per rifiutare esplicitamente l'anteprima pubblica per i controlli di rete del gateway applicazione avanzati tramite il portale, seguire questa procedura:
Accedere al portale di Azure.
Nella casella di ricerca immettere sottoscrizioni e selezionare Sottoscrizioni.
Selezionare il collegamento per il nome della sottoscrizione.
Nel menu a sinistra, in Impostazioni selezionare Funzionalità di anteprima.
Viene visualizzato un elenco delle funzionalità di anteprima disponibili e lo stato di registrazione corrente.
In Anteprima funzionalità digitare nella casella di filtro EnableApplicationGatewayNetworkIsolation, selezionare la funzionalità e fare clic su Annulla registrazione.
Aree e disponibilità
L'anteprima del gateway applicazione privato è disponibile per tutte le aree cloud pubbliche in cui è supportato lo SKU v2 del gateway applicazione.
Configurazione dei controlli di rete
Dopo la registrazione nell'anteprima pubblica, è possibile eseguire la configurazione del front-end NSG, della tabella di route e dell'indirizzo IP privato usando qualsiasi metodo. Ad esempio: API REST, modello ARM, distribuzione Bicep, Terraform, PowerShell, interfaccia della riga di comando o portale. Con questa anteprima pubblica non vengono introdotte modifiche all'API o ai comandi.
Modifiche di risorsa
Dopo il provisioning del gateway, viene assegnato automaticamente un tag di risorsa con il nome EnhancedNetworkControl e il valore True. Vedere l'esempio seguente:
Il tag di risorsa è cosmetico e serve a confermare che è stato effettuato il provisioning del gateway con le funzionalità per configurare qualsiasi combinazione delle funzionalità del gateway privato. La modifica o l'eliminazione del tag o del valore non modifica alcun funzionamento del gateway.
Suggerimento
Il tag EnhancedNetworkControl può essere utile quando i gateway applicazione esistenti sono stati distribuiti nella sottoscrizione prima dell'abilitazione delle funzionalità e si vuole distinguere il gateway che può usare la nuova funzionalità.
Subnet del gateway applicazione
La subnet del gateway applicazione è la subnet all'interno della rete virtuale in cui saranno distribuite le risorse del gateway applicazione. Nella configurazione IP privato front-end è importante che questa subnet possa raggiungere privatamente le risorse che vogliono connettersi all'app o al sito esposto.
Connettività Internet in uscita
Le distribuzioni del gateway applicazione che contengono solo una configurazione IP front-end privata (non hanno una configurazione front-end IP pubblico associata a una regola di gestione delle richieste) non sono in grado di inoltrare il traffico in uscita destinato a Internet. Questa configurazione influisce sulla comunicazione con le destinazioni back-end accessibili pubblicamente tramite Internet.
Per abilitare la connettività in uscita dal gateway applicazione a una destinazione back-end con connessione Internet, è possibile usare NAT di rete virtuale o inoltrare il traffico a un'appliance virtuale che ha accesso a Internet.
NAT di rete virtuale offre il controllo sull'indirizzo IP o sul prefisso da usare, nonché sul timeout di inattività configurabile. Per configurare, creare un nuovo gateway NAT con un indirizzo IP pubblico o un prefisso pubblico e associarlo alla subnet contenente il gateway applicazione.
Se per internet è necessaria un'appliance virtuale, vedere la sezione controllo tabella di route in questo documento.
Scenari comuni in cui è necessario l'utilizzo di indirizzi IP pubblici:
- Comunicazione con l'insieme di credenziali delle chiavi senza usare endpoint privati o endpoint di servizio
- La comunicazione in uscita non è necessaria per i file pfx caricati direttamente nel gateway applicazione
- Comunicazione con destinazioni back-end tramite Internet
- Comunicazione con gli endpoint CRL o OCSP con connessione Internet
Controllo del gruppo di sicurezza di rete
I gruppi di sicurezza di rete associati a una subnet del gateway applicazione non richiedono più regole in ingresso per GatewayManager e non richiedono l'accesso in uscita a Internet. L'unica regola necessaria è Consentire l'ingresso da AzureLoadBalancer per garantire che i probe di integrità possano raggiungere il gateway.
La configurazione seguente è un esempio del set più restrittivo di regole in ingresso, che nega tutto il traffico tranne i probe di integrità di Azure. Oltre alle regole definite, vengono definite delle regole esplicite per consentire al traffico client di raggiungere il listener del gateway.
Nota
Il gateway applicazione visualizzerà un avviso che chiede di assicurarsi che l'opzione Consenti LoadBalanceRule sia specificata se una regola DenyAll limita inavvertitamente l'accesso ai probe di integrità.
Scenario di esempio
Questo esempio illustra la creazione di un gruppo di sicurezza di rete usando il portale di Azure con le regole seguenti:
- Consentire il traffico in ingresso alla porta 80 e 8080 al gateway applicazione dalle richieste client provenienti da Internet
- Negare tutto il traffico in ingresso
- Consentire il traffico in uscita verso una destinazione back-end in un'altra rete virtuale
- Consentire il traffico in uscita verso una destinazione back-end accessibile da Internet
- Negare tutto il traffico in uscita
Prima di tutto, creare un gruppo di sicurezza di rete. Questo gruppo di sicurezza contiene le regole in ingresso e in uscita.
Regole in ingresso
È già stato effettuato il provisioning di tre regole in ingresso predefinite nel gruppo di sicurezza. Vedere l'esempio seguente:
Creare quindi le quattro nuove regole di sicurezza in ingresso seguenti:
- Consentire la porta in ingresso 80, tcp, da Internet (qualsiasi)
- Consentire la porta in ingresso 8080, tcp, da Internet (qualsiasi)
- Consentire l'ingresso da AzureLoadBalancer
- Nega eventuali connessioni in ingresso
Per creare queste regole:
- Selezionare Regole di sicurezza in ingresso
- Seleziona Aggiungi
- Immettere le informazioni seguenti per ogni regola nel riquadro Aggiungi regola di sicurezza in ingresso.
- Dopo aver immesso le informazioni, selezionare Aggiungi per creare la regola.
- La creazione di ogni regola richiede un attimo.
| N. regola | Origine | Tag del servizio di origine | Intervalli porte di origine | Destinazione | Servizio | Intervalli di porte Dest | Protocollo | Azione | Priorità | Nome |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Qualsiasi | * | Qualsiasi | HTTP | 80 | TCP | Consenti | 1028 | AllowWeb | |
| 2 | Qualsiasi | * | Qualsiasi | Personalizzazione | 8080 | TCP | Consenti | 1029 | AllowWeb8080 | |
| 3 | Tag del servizio | AzureLoadBalancer | * | Any | Personalizzazione | * | Qualsiasi | Consenti | 1045 | AllowLB |
| 4 | Qualsiasi | * | Qualsiasi | Personalizzazione | * | Qualsiasi | Nega | 4095 | DenyAllInbound |
Selezionare Aggiorna per esaminare tutte le regole al termine del provisioning.
Regole in uscita
È già stato effettuato il provisioning di tre regole in uscita predefinite con priorità 65000, 65001 e 65500.
Creare le tre nuove regole di sicurezza in uscita seguenti:
- Consentire TCP 443 da 10.10.4.0/24 alla destinazione back-end 203.0.113.1
- Consenti TCP 80 dall'origine 10.10.4.0/24 alla destinazione 10.13.0.4
- Regola per negare tutto il traffico
Queste regole vengono assegnate rispettivamente a una priorità pari a 400, 401 e 4096.
Nota
- 10.10.4.0/24 è lo spazio di indirizzi della subnet del gateway applicazione.
- 10.13.0.4 è una macchina virtuale in una rete virtuale con peering.
- 203.0.113.1 è una macchina virtuale di destinazione back-end.
Per creare queste regole:
- Selezionare regole di sicurezza in uscita
- Seleziona Aggiungi
- Immettere le informazioni seguenti per ogni regola nel riquadro Aggiungi regola di sicurezza in uscita.
- Dopo aver immesso le informazioni, selezionare Aggiungi per creare la regola.
- La creazione di ogni regola richiede un attimo.
| N. regola | Origine | Indirizzi IP/Intervalli CIDR di origine | Intervalli porte di origine | Destinazione | Indirizzi IP/Intervalli CIDR di destinazione | Servizio | Intervalli di porte Dest | Protocollo | Azione | Priorità | Nome |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Indirizzi IP | 10.10.4.0/24 | * | Indirizzi IP | 203.0.113.1 | HTTPS | 443 | TCP | Consenti | 400 | AllowToBackendTarget |
| 2 | Indirizzi IP | 10.10.4.0/24 | * | Indirizzi IP | 10.13.0.4 | HTTP | 80 | TCP | Consenti | 401 | AllowToPeeredVnetVM |
| 3 | Qualsiasi | * | Qualsiasi | Personalizzazione | * | Qualsiasi | Nega | 4096 | DenyAll |
Selezionare Aggiorna per esaminare tutte le regole al termine del provisioning.
Associare un gruppo di sicurezza di rete alla subnet
L'ultimo passaggio consiste nell'associare il gruppo di sicurezza di rete alla subnet che contiene il gateway applicazione.
Risultato:
Importante
Prestare attenzione quando si definiscono le regole di DenyAll, in quanto è possibile negare inavvertitamente il traffico in ingresso dai client a cui si intende consentire l'accesso. È anche possibile che si neghi inavvertitamente il traffico in uscita alla destinazione back-end, causando l'esito negativo dell'integrità del back-end e produrre delle risposte 5XX.
Controllo tabella di route
Nell'offerta corrente del gateway applicazione, l'associazione di una tabella di route con una regola (o creazione di regola) definita come 0.0.0.0/0 con un hop successivo come appliance virtuale non è supportata per garantire una corretta gestione del gateway applicazione.
Dopo la registrazione della funzionalità di anteprima pubblica, è ora possibile inoltrare il traffico a un'appliance virtuale tramite la definizione di una regola di tabella di route che definisce 0.0.0.0/0 con un hop successivo all'appliance virtuale.
Il tunneling forzato o l'apprendimento della route 0.0.0.0/0 tramite annunci BGP non influisce sull'integrità del gateway applicazione e viene rispettato per il flusso del traffico. Questo scenario può essere applicabile quando si usa VPN, ExpressRoute, Server di route o rete WAN virtuale.
Scenario di esempio
Nell'esempio seguente viene creata una tabella di route e la si associa alla subnet del gateway applicazione per garantire che l'accesso a Internet in uscita dalla subnet esca da un'appliance virtuale. A livello generale, la progettazione seguente è riepilogata nella figura 1:
- Il gateway applicazione si trova nella rete virtuale spoke
- Nella rete hub è presente un'appliance virtuale di rete (una macchina virtuale)
- Una tabella di route con una route predefinita (0.0.0.0/0) all'appliance virtuale è associata alla subnet del gateway applicazione
Figura 1: Accesso a Internet in uscita tramite appliance virtuale
Per creare una tabella di route e associarla alla subnet del gateway applicazione:
- Selezionare Route e creare la regola hop successiva per 0.0.0.0/0 e configurare la destinazione come indirizzo IP della macchina virtuale:
- Selezionare Subnet e associare la tabella di route alla subnet del gateway applicazione:
- Verificare che il traffico passi attraverso l'appliance virtuale.
Limitazioni e problemi noti
Durante l'anteprima pubblica, sono note le limitazioni seguenti.
Configurazione del collegamento privato
Il supporto della configurazione del collegamento privato per il tunneling del traffico attraverso endpoint privati al gateway applicazione non è supportato con il gateway privato.
Limitazione della velocità WAF
Le regole personalizzate di limitazione della velocità per WAF v2 del gateway applicazione non sono attualmente supportate.
Configurazione front-end IP privato solo con AGIC
È necessario usare AGIC v1.7 per introdurre il supporto solo per l'indirizzo IP front-end privato.
Connettività dell'endpoint privato tramite peering reti virtuali globali
Se il gateway applicazione ha una destinazione back-end o un riferimento all'insieme di credenziali delle chiavi a un endpoint privato che si trova in una rete virtuale accessibile tramite peering di rete virtuale globale, il traffico viene eliminato, causando uno stato non integro.
Integrazione di Network Watcher
La risoluzione dei problemi di connessione e la diagnostica del gruppo di sicurezza di rete (NSG) restituiscono un errore durante l'esecuzione di test di controllo e diagnostica.
Gateway applicativi v2 coesistenti creati prima dell'abilitazione del controllo di rete avanzato
Se una subnet condivide le distribuzioni del gateway applicazione v2 create sia prima che dopo l'abilitazione della funzionalità di controllo di rete avanzata, la funzionalità gruppo di sicurezza di rete (NSG) e tabella di route è limitata alla distribuzione del gateway precedente. Dei gateway applicazione di cui è stato effettuato il provisioning prima dell'abilitazione della nuova funzionalità, deve essere rieffettuato il provisioning, oppure i gateway appena creati devono usare una subnet diversa per abilitare funzionalità avanzate del gruppo di sicurezza di rete e della tabella di route.
- Se nella subnet è presente un gateway distribuito prima dell'abilitazione della nuova funzionalità, potrebbero verificarsi errori come:
For routes associated to subnet containing Application Gateway V2, please ensure '0.0.0.0/0' uses Next Hop Type as 'Internet'quando si aggiungono voci della tabella di route. - Quando si aggiungono regole del gruppo di sicurezza di rete alla subnet, è possibile che venga visualizzato:
Failed to create security rule 'DenyAnyCustomAnyOutbound'. Error: Network security group \<NSG-name\> blocks outgoing Internet traffic on subnet \<AppGWSubnetId\>, associated with Application Gateway \<AppGWResourceId\>. This isn't permitted for Application Gateways that have fast update enabled or have V2 Sku.
Stato di integrità back-end sconosciuto
Se l'integrità back-end è Sconosciuta, potrebbe essere visualizzato l'errore seguente:
- Impossibile recuperare lo stato di integrità back-end. Questo problema si verifica quando un NSG/una UDR/un firewall nella subnet di Gateway applicazione blocca il traffico sulle porte 65503-65534 se è presente lo SKU v1, e sulle porte 65200-65535 se è presente lo SKU v2, o se non è stato possibile risolvere in un indirizzo IP il FQDN configurato nel pool back-end. Per altre informazioni, vedere: https://aka.ms/UnknownBackendHealth.
Questo errore può essere ignorato e verrà spiegato in una versione futura.
Passaggi successivi
- Per altre procedure consigliate per la sicurezza, vedere Baseline di sicurezza di Azure per il gateway applicazione.