Accesso a Internet in uscita: controllare l'uscita da Azure

Questo articolo illustra come controllare l'accesso a Internet in uscita da Azure reti virtuali. Confronta i modelli di gateway NAT, Firewall di Azure e uscita combinati per facilitare la scelta di un metodo prevedibile e sicuro per i carichi di lavoro.

Informazioni su questo articolo

Il controllo in uscita determina il modo in cui i carichi di lavoro Azure raggiungono la rete Internet pubblica. Una strategia di uscita ben progettata fornisce indirizzi IP pubblici prevedibili, impedisce l'esaurimento delle porte SNAT e, facoltativamente, filtra le connessioni in uscita in base alla destinazione.

Note

Questo articolo tratta i concetti specifici dell'egress. Per la copertura completa del firewall, vedere Firewall di Azure e ispezione del traffico.

Chi ha bisogno di questo articolo

Leggere questo articolo se si applicano una o più di queste condizioni:

  • I carichi di lavoro richiedono l'accesso in uscita controllato a Internet per aggiornamenti, API o servizi esterni.
  • Sono necessari indirizzi IP pubblici prevedibili per le connessioni in uscita.
  • È necessario impedire l'esaurimento delle porte SNAT o aumentare la connettività in uscita per carichi di lavoro con connessione elevata.
  • È necessario scegliere tra gateway NAT, Firewall di Azure o un modello combinato per il controllo e l'ispezione in uscita.

Tip

Si segue un percorso di scenario? Selezionare lo scenario nella parte superiore della pagina per indicazioni personalizzate. Le linee guida di base seguenti si applicano a tutti i lettori.

Focus su lift-and-shift:le macchine virtuali di cui è stata eseguita la migrazione richiedono l'accesso a Internet in uscita controllato. Centralizzare tutto il traffico in uscita attraverso il firewall hub per applicare criteri di sicurezza coerenti nei carichi di lavoro migrati.

Leggere questo articolo se:

  • Distribuire carichi di lavoro che devono raggiungere Internet per aggiornamenti, chiamate API o servizi di terze parti.
  • Si vuole centralizzare il controllo in uscita tramite Firewall di Azure nella rete virtuale dell'hub.
  • È necessario disattivare l'accesso in uscita predefinito nei carichi di lavoro migrati e sostituirlo con un metodo di uscita esplicito.
  • Richiedere un indirizzo IP pubblico fisso e prevedibile per le connessioni in uscita.

Focus sulla modernizzazione: tutte le reti virtuali spoke instradano il traffico in uscita tramite il firewall dell'hub usando route definite dall'utente (UDR). Questo modello di uscita centralizzato è parte integrante dell'architettura di sicurezza perché impedisce ai team dell'app di ignorare i controlli di sicurezza gestiti dall'IT.

Leggere questo articolo se:

  • È necessario garantire che tutti i carichi di lavoro spoke (AKS, servizio app, macchine virtuali) instradino il traffico in uscita attraverso il firewall dell'hub.
  • Si desidera un routing basato su UDR da ogni spoke verso l'hub Firewall di Azure, per garantire criteri di uscita uniformi.
  • Richiedere al firewall dell'hub di fungere da SNAT per tutte le connessioni in uscita.
  • È necessario evitare l'esaurimento delle porte SNAT per carichi di lavoro con numero elevato di connessioni.

Focus multi-cloud: includere un'uscita centralizzata se la progettazione di destinazione richiede criteri di uscita Internet controllati. In caso contrario, il traffico tra cloud passa attraverso il percorso di transito (Firewall di Azure nell'hub virtuale sicuro) e non richiede una configurazione in uscita separata.

Leggere questo articolo se:

  • Necessità di un criterio centralizzato per il traffico Internet in uscita nella landing zone di Azure.
  • Si desidera condividere lo stesso Firewall di Azure sia per l'ispezione del transito tra ambienti cloud sia per il traffico in uscita verso Internet.
  • Sostituisci l'accesso in uscita predefinito prima che venga ritirato gradualmente.

Azure servizi e funzionalità

Nella tabella seguente vengono descritti i servizi e le funzionalità disponibili per l'accesso a Internet in uscita in Azure reti virtuali.

Servizio o funzionalità Elementi forniti Quando usarlo
Accesso in uscita predefinito (ritirato) Azure assegna automaticamente un indirizzo IP pubblico temporaneo per le connessioni in uscita. L'indirizzo IP assegnato non è prevedibile e può cambiare senza preavviso. Non usare per le nuove distribuzioni. Sostituire con il gateway NAT o Firewall di Azure. Vedere Considerazioni sulla sicurezza.
Gateway NAT di Azure Servizio SNAT gestito con indirizzi IP pubblici fissi e prevedibili. Fornisce 64.512 porte SNAT per ip pubblico, fino a 16 indirizzi IP pubblici (oltre 1 milione di porte totali). Nessun filtro del contenuto. Carichi di lavoro solo in uscita che necessitano di un indirizzo IP in uscita fisso, applicazioni con numero elevato di connessioni e scenari in cui l'esaurimento delle porte SNAT è un rischio.
Firewall di Azure Ispezione completa del livello 3-7 per il traffico in uscita. filtraggio FQDN, filtraggio URL, categorie web e IDPS (Premium SKU). Gestione centralizzata dei criteri. Quando è necessario controllare a quali destinazioni si connettono le risorse, non solo che abbiano accesso in uscita.
Gateway NAT + Firewall di Azure NAT Gateway gestisce la scalabilità SNAT nella sottorete del firewall. Firewall di Azure gestisce l'ispezione e il filtro. Non si verifica alcun double NAT. Ambienti di produzione che richiedono filtri in uscita scalabili e con riconoscimento del contenuto. Architettura consigliata per i carichi di lavoro aziendali.
VM con indirizzo IP pubblico (in uscita) La macchina virtuale usa il proprio indirizzo IP pubblico per il traffico in uscita. Nessun controllo centralizzato o filtro. Da non usare in produzione. Nessuna gestione centralizzata, imprevedibile su larga scala e non trae vantaggio dalle risorse SNAT condivise.

Come scegliere

Diagramma che mostra tre percorsi in uscita da una rete virtuale del carico di lavoro tramite gateway NAT, Firewall di Azure o entrambi.

Come controllare l'accesso in uscita

Usare la tabella seguente per selezionare un metodo in uscita in base ai requisiti.

Requisiti Approccio consigliato Perché
Correzione solo dell'indirizzo IP in uscita, nessun filtro necessario Gateway di NAT Fornisce indirizzi IP pubblici prevedibili con allocazione automatica delle porte SNAT. Nessun costo di ispezione o filtro. Opzione più semplice pronta per la produzione.
Filtro FQDN, filtro URL o ispezione del traffico Firewall di Azure Filtra le connessioni in uscita in base al nome di dominio completo o all'URL di destinazione. Lo SKU Premium aggiunge IDPS e l'ispezione TLS per il rilevamento avanzato delle minacce.
IP in uscita fisso e filtraggio dei contenuti NAT Gateway + Firewall di Azure Il gateway NAT in AzureFirewallSubnet offre SNAT scalabile. Il firewall controlla il traffico prima dell'uscita. Meglio di entrambe le funzionalità.
Non usare per le nuove distribuzioni Accesso in uscita predefinito o IP pubblico della macchina virtuale L'accesso predefinito in uscita è stato ritirato. Gli indirizzi IP pubblici delle macchine virtuali non forniscono alcun controllo centralizzato. Entrambi non sono adatti per i carichi di lavoro di produzione.

NAT Gateway rispetto ad Firewall di Azure per il traffico in uscita

Usare il confronto seguente per comprendere i compromessi tra gateway NAT e Firewall di Azure quando vengono usati in modo indipendente.

Capability Gateway di NAT Firewall di Azure
Porte SNAT 64.512 per IP pubblico (fino a 16 INDIRIZZI IP, oltre 1 milione totale) 2.496 per indirizzo IP pubblico per istanza back-end (massimo 250 IP)
Filtro del traffico Nessuno: passa tutto il traffico in uscita Regole FQDN, filtro URL, categorie Web, regole di rete
IdPS e ispezione TLS Non disponibile Solo SKU premium
Throughput Velocità di linea per la subnet (nessun limite documentato per SNAT) Fino a 100 Gbps (Premium), 30 Gbps (Standard), 250 Mbps (Basic)
Modello di costo Risorsa all'ora + dati per GB elaborati Risorsa per ora + dati per GB elaborati (costo di base superiore)
Complessità del routing Si associa direttamente a una subnet, non è necessario alcun UDR Richiede UDR (0.0.0.0/0 → IP privato del firewall) nelle subnet dei carichi di lavoro
caso d'uso Connessioni in uscita con volume elevato che richiedono indirizzi IP fissi Ambienti regolamentati che richiedono filtraggio e registrazione del traffico in uscita

Priorità di routing per il traffico in uscita

Azure valuta i metodi in uscita nell'ordine di priorità seguente. I metodi con priorità più alta sostituiscono quelli con priorità più bassa nella stessa subnet:

  1. UDR verso un'appliance virtuale o un gateway di rete virtuale: ha la precedenza su tutti gli altri metodi in uscita, incluso il gateway NAT.
  2. NAT Gateway: ha la priorità rispetto agli indirizzi IP pubblici a livello di istanza e alle regole in uscita del bilanciamento del carico.
  3. Indirizzo IP pubblico a livello di istanza sulla macchina virtuale.
  4. Regole in uscita del bilanciamento del carico.
  5. Route di sistema predefinita a Internet (Microsoft ritirata questa opzione per le nuove distribuzioni).

Importante

Una route definita dall'utente con destinazione 0.0.0.0/0 che punta a un'appliance virtuale (ad esempio Firewall di Azure) esegue l'override del gateway NAT. Questo comportamento è progettato per l'architettura combinata del gateway NAT e del firewall. La route definita dall'utente (UDR) nelle subnet dei carichi di lavoro forza il traffico attraverso il firewall, mentre il gateway NAT nella subnet AzureFirewallSubnet fornisce gli indirizzi IP di uscita finali.

Architettura combinata: gateway NAT e Firewall di Azure

Il modello di produzione consigliato per l'uscita aziendale combina entrambi i servizi:

  1. Le subnet dei carichi di lavoro hanno una route definita dall'utente (UDR) che instrada il traffico 0.0.0.0/0 all'indirizzo IP privato del firewall di Azure.
  2. Firewall di Azure controlla e filtra il traffico in uscita usando regole di rete, regole dell'applicazione o entrambi.
  3. Il gateway NAT viene associato ad AzureFirewallSubnet e fornisce SNAT scalabile per le connessioni in uscita del firewall.
  4. Non si verifica alcun doppio NAT. Il firewall invia il traffico al gateway NAT usando l'INDIRIZZO IP privato e il gateway NAT applica SNAT una volta usando gli indirizzi IP pubblici.

Questa architettura offre un'ispezione centralizzata con SNAT scalabile. AzureFirewallSubnet non richiede route definite dall'utente aggiuntive perché il gateway NAT instrada automaticamente il traffico Internet in uscita quando associato.

Note

Il Gateway NAT Standard è una risorsa a livello di zona e non supporta le distribuzioni con ridondanza di zona. Se distribuisci un Firewall di Azure con ridondanza di zona, usa NAT Gateway V2 (SKU StandardV2) per SNAT con ridondanza di zona. Il NAT Gateway standard diventa un singolo punto di guasto durante un'interruzione a livello di zona quando è associato a un firewall con ridondanza tra zone. Per altre informazioni, vedere SKU del gateway NAT.

Procedura dettagliata per il flusso di dati

La sequenza seguente illustra il flusso di una singola richiesta in uscita attraverso l'architettura combinata:

  1. Una macchina virtuale in una subnet del carico di lavoro avvia una connessione TCP a un'API esterna , ad esempio api.contoso.com:443.
  2. L'UDR della subnet corrisponde a 0.0.0.0/0 e invia il pacchetto all'indirizzo IP privato di Firewall di Azure.
  3. Firewall di Azure valuta la connessione rispetto alle regole dell'applicazione e alle regole di rete. Se una regola dell'applicazione con una voce di autorizzazione FQDN corrisponde, il firewall consente la connessione.
  4. Il firewall invia il pacchetto consentito dalla propria interfaccia in AzureFirewallSubnet.
  5. Il gateway NAT, associato ad AzureFirewallSubnet, esegue SNAT. Converte l'IP di origine privata del firewall in uno degli indirizzi IP pubblici e alloca una porta SNAT dal pool.
  6. La risposta dell'API esterna ritorna all'indirizzo IP pubblico del gateway NAT. Il gateway NAT esegue la conversione inversa e restituisce il pacchetto al firewall.
  7. Il firewall invia la risposta alla macchina virtuale di origine tramite lo stato di connessione esistente.

In questo flusso end-to-end, il firewall ispeziona il traffico esattamente una volta e NAT Gateway applica SNAT esattamente una volta, senza doppio NAT.

Monitoraggio e diagnostica

Monitorare l'infrastruttura in uscita per rilevare i problemi di capacità prima che influiscano sui carichi di lavoro:

  • Metriche del gateway NAT: Monitorare il numero totale di connessioni SNAT, il numero di connessioni SNAT (per stato) e la disponibilità del percorso dati in Monitoraggio di Azure. Impostare avvisi quando l'utilizzo delle porte SNAT supera 80% della capacità allocata.
  • Firewall di Azure log: abilitare le impostazioni di diagnostica per inviare i log a Log Analytics. Usare le categorie di log AzureFirewallApplicationRule e AzureFirewallNetworkRule per controllare le connessioni in uscita consentite e negate.
  • Monitoraggio connessione: usare Network Watcher Monitoraggio connessione per testare la connettività end-to-end dalle macchine virtuali del carico di lavoro agli endpoint esterni. Monitoraggio connessione rileva gli aumenti della latenza e gli errori di connettività che potrebbero indicare l'esaurimento SNAT o la configurazione errata del firewall.
  • Metriche del firewall: Tenere traccia della velocità effettiva, delle regole hit count e dell'utilizzo delle porte SNAT per ridimensionare correttamente lo SKU del firewall e identificare le regole di accesso frequente.

Considerazioni relative alla progettazione

Usare Firewall di Azure per tutte le comunicazioni in uscita dai carichi di lavoro migrati. Questo approccio offre filtro FQDN centralizzato, registrazione e rilevamento delle minacce fin dal primo giorno:

  • Disattivare l'accesso in uscita predefinito: Per le nuove distribuzioni, per impostazione predefinita le subnet sono private (nessuna uscita automatica). Per le VNet esistenti, sostituire esplicitamente l’uscita predefinita con il traffico in uscita tramite Firewall di Azure per non dipendere da indirizzi IP pubblici imprevedibili e non controllati.
  • UDR nelle subnet del carico di lavoro: Creare una route definita dall'utente (0.0.0.0/0 → IP privato del firewall di Azure) in ogni subnet spoke del carico di lavoro. Questa configurazione forza tutto il traffico associato a Internet attraverso il firewall hub.
  • Gateway NAT in AzureFirewallSubnet: Associare il gateway NAT alla subnet del firewall per SNAT scalabile. Questa combinazione fornisce indirizzi IP in uscita prevedibili ed evita l'esaurimento delle porte SNAT.
  • Iniziate con regole di autorizzazione ampie, restringetele gradualmente: Durante la migrazione, consentite il traffico in uscita verso le destinazioni necessarie alle vostre applicazioni (Windows Update, repository di pacchetti, API di terze parti). Una volta stabilizzata la migrazione, esaminare i log del firewall e limitare agli FQDN noti.

Il routing basato su UDR da ogni spoke verso il firewall dell’hub costituisce il fondamento del modello di sicurezza del traffico in uscita. I team delle app non possono ignorare i controlli in uscita gestiti dall'IT:

  • UDR in ogni rete virtuale spoke: Ogni subnet del carico di lavoro della spoke dispone di una tabella di routing con indirizzo IP 0.0.0.0/0 → privato del firewall di Azure nell'hub. Questa configurazione garantisce che i nodi AKS, le subnet di App Service integrate nella VNet e le macchine virtuali instradino tutto il traffico in uscita attraverso il firewall.
  • Firewall dell'hub come SNAT: Firewall di Azure esegue NAT di origine per tutte le connessioni in uscita. Tutti i carichi di lavoro spoke condividono gli indirizzi IP in uscita del firewall, semplificando l'elenco di elementi consentiti del firewall partner.
  • Gateway NAT per il ridimensionamento SNAT: associare il gateway NAT ad AzureFirewallSubnet. Con 16 indirizzi IP pubblici (oltre 1 milione di porte SNAT), si gestiscono carichi di lavoro con numero elevato di connessioni, ad esempio cluster del servizio Azure Kubernetes con molti pod che effettuano chiamate API esterne.
  • Regole applicative per il controllo FQDN: Usare le regole applicative di Firewall di Azure per limitare il traffico in uscita in base all'FQDN. I team applicativi richiedono l'inserimento di voci di autorizzazione FQDN attraverso un processo di gestione delle modifiche. Il criterio di rifiuto predefinito impedisce l'esfiltrazione dei dati.

Firewall di Azure nell'hub virtuale sicuro controlla sia il traffico di transito tra cloud sia l'uscita internet. La condivisione di un singolo firewall per entrambi i percorsi semplifica l'architettura:

  • Proteggere il firewall dell'hub virtuale per l'uscita: Se si distribuisce rete WAN virtuale con un hub sicuro, Firewall di Azure nell'hub gestisce l'uscita Internet per tutte le reti virtuali connesse. Configurare i criteri di routing del traffico Internet dell'hub sicuro per inviare 0.0.0.0/0 tramite il firewall.
  • I dati in uscita e il transito tra cloud condividono lo stesso firewall: Il traffico destinato a Internet e al traffico destinato a AWS/Google Cloud attraverso tunnel IPSec passano entrambi attraverso Firewall di Azure per l'ispezione. Questa progettazione significa che si mantiene un set di regole per tutti i percorsi in uscita.
  • Centralizzare solo se necessario: Se la progettazione tra cloud non impone l'uscita internet centralizzata (ad esempio, i carichi di lavoro comunicano solo tra cloud), è possibile ignorare questa configurazione e basarsi solo sull'ispezione del firewall di transito tra cloud.

Prerequisiti

Prima di implementare i controlli in uscita, verificare gli elementi seguenti:

  • Una rete virtuale viene implementata con subnet dimensionate per i carichi di lavoro. Per indicazioni sulla progettazione delle subnet, vedere Reti virtuali e subnet .
  • Conosci le route definite dall'utente (UDR) e il modo in cui hanno la precedenza sul routing predefinito di Azure. Per i dettagli sulla configurazione delle route definite dall'utente (UDR), vedere Reti virtuali e subnet.
  • Se si usa Firewall di Azure, la subnet del firewall viene ridimensionata correttamente. AzureFirewallSubnet richiede almeno /26 (64 indirizzi).
  • Conosci i tuoi requisiti di scalabilità per SNAT. Calcolare le connessioni in uscita simultanee di picco per determinare il numero di INDIRIZZI IP pubblici del gateway NAT necessari (64.512 porte per IP).

Considerazioni relative alla sicurezza

Sostituire l'accesso in uscita predefinito

L'accesso in uscita predefinito non è più disponibile. Per le versioni API rilasciate dopo il 31 marzo 2026, per impostazione predefinita le nuove reti virtuali sono subnet private (nessuna uscita automatica). Le reti virtuali esistenti non sono interessate, ma è consigliabile eseguire la migrazione a un metodo in uscita esplicito. Per informazioni dettagliate, vedere la documentazione di accesso in uscita predefinita.

Note

Le reti virtuali e le macchine virtuali esistenti che attualmente usano l'accesso in uscita predefinito continuano a funzionare. Tuttavia, l'indirizzo IP pubblico assegnato non è prevedibile, non offre alcun filtro e genera avvisi di Azure Advisor. Pianificare la migrazione al gateway NAT o Firewall di Azure indipendentemente dalla sequenza temporale del ritiro.

Routing UDR per l'ispezione centralizzata del firewall

Quando si utilizza Firewall di Azure per il controllo del traffico in uscita, crea una UDR in ogni subnet del carico di lavoro con:

  • Destinazione: 0.0.0.0/0
  • Tipo di hop successivo: Appliance virtuale
  • Indirizzo del next hop: indirizzo IP privato di Firewall di Azure (ad esempio, 10.0.1.4)

Questa configurazione garantisce che tutto il traffico associato a Internet dalle subnet del carico di lavoro passi attraverso il firewall per l'ispezione. Senza questa UDR, il traffico aggira il firewall e usa qualunque metodo di uscita configurato direttamente sulla subnet.

Impedire l'esaurimento delle porte SNAT

L'esaurimento delle porte SNAT si verifica quando un carico di lavoro apre più connessioni simultanee in uscita di quante ne supporti il numero di porte disponibili. I sintomi includono timeout di connessione intermittenti, pacchetti TCP RST nelle connessioni in uscita e richieste HTTP non riuscite con errori del socket. I log dell'applicazione mostrano gli errori "indirizzo già in uso" o "non è possibile assegnare l'indirizzo richiesto". L'esaurimento si manifesta in genere sotto carico quando molte connessioni di breve durata si aprono rapidamente allo stesso indirizzo IP e porta di destinazione.

Per evitare l'esaurimento:

  • Usare il gateway NAT per i carichi di lavoro con numero elevato di connessioni in uscita. Ogni indirizzo IP pubblico fornisce 64.512 porte SNAT con allocazione dinamica in tutte le risorse nella subnet.
  • Aggiungere indirizzi IP pubblici al gateway NAT se il monitoraggio mostra l'utilizzo delle porte superiore a 80%. Aggiungere fino a 16 indirizzi IP pubblici.
  • Usare il pool di connessioni nel codice dell'applicazione per riutilizzare le connessioni esistenti anziché aprirle nuove per ogni richiesta.
  • Diversificare gli endpoint di destinazione quando possibile. L'allocazione delle porte SNAT avviene per ogni coppia IP/porta di destinazione, quindi distribuire il traffico tra più indirizzi IP di destinazione riduce la pressione sulle porte.
  • Ridurre i timeout di inattività per liberare le porte più rapidamente. Il timeout di inattività predefinito del gateway NAT è di 4 minuti. Ridurre questo valore per i carichi di lavoro che creano molte connessioni di breve durata.

I gruppi di sicurezza di rete completano il controllo del traffico in uscita

I gruppi di sicurezza di rete (NSG) e i metodi in uscita servono scopi diversi e interagiscono. Gli NSG filtrano il traffico in base all'indirizzo IP e alla porta a livello di subnet o NIC. Gateway NAT e Firewall di Azure controllano come il traffico raggiunge Internet. Usare entrambi i livelli per la difesa in profondità. Per indicazioni sulla progettazione del gruppo di sicurezza di rete, vedere Gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni .

Considerazioni sul tunneling forzato

Il tunneling forzato attraverso l'ambiente locale può introdurre latenza e aggiunge dipendenza dal firewall locale. Prendere in considerazione Firewall di Azure per l'ispezione in uscita se è importante una bassa latenza. Se i requisiti di conformità impongono l'ispezione on-premises, verificare la latenza end-to-end dalle subnet dei carichi di lavoro e assicurarsi che il percorso on-premises sia in grado di soddisfare i requisiti di throughput senza diventare un collo di bottiglia.

Evitare l'esfiltrazione di dati

Firewall di Azure filtro FQDN impedisce l'esfiltrazione dei dati limitando le connessioni in uscita solo ai nomi di dominio approvati. Definire le regole dell'applicazione che consentono il traffico verso FQDN specifici (ad esempio, *.blob.core.windows.net o api.partner.com) e negare tutte le altre connessioni in uscita. Questo approccio garantisce che i carichi di lavoro compromessi non possano inviare dati agli endpoint controllati dall'utente malintenzionato.

Ulteriori informazioni

Passaggi successivi

Tip

Esplorazione da sola? Tornare allo strumento di navigazione di panoramica per trovare l'articolo successivo in base alla funzionalità.

Successivamente, nel viaggio in modalità lift-and-shift:

Configurare il firewall dell'hub: configurare Firewall di Azure per l'ispezione centralizzata a est-ovest e il controllo del traffico in uscita.

Nel prossimo percorso di modernizzazione:

Configurare il firewall dell'hub: configurare Firewall di Azure come SNAT/DNAT nell'hub per eliminare tutto il traffico prima che raggiunga il livello dell'app.

Il prossimo passo nel tuo percorso multicloud:

Configura il monitoraggio multicloud: Gli ambienti multicloud sono più difficili da diagnosticare. Stabilire il monitoraggio prima di andare in diretta.

  • Last updated on