Lo scorso anno Microsoft ha annunciato il ritiro del Default outbound access per le macchine virtuali in Azure, previsto per il 30 settembre 2025.
A partire da questa data, le nuove VM che necessitano di accesso a Internet dovranno utilizzare metodi di connettività in uscita espliciti, come Azure NAT Gateway, Azure Load Balancer con outbound rules oppure dovranno avere un IP pubblico associato.
Attualmente alle istanze create in una rete virtuale senza metodi di explicit outbound connectivity viene assegnato un default public IP che abilita le risorse all’accesso a Internet:
L’indirizzo IP in questa casistica viene definito default outbound access IP ed è condiviso tra più risorse e cambia periodicamente. Per questi e altri motivi che vedremo successivamente, non è raccomandabile l’utilizzo per i workload di produzione.
Dalla tabella a seguito, presa direttamente dalla documentazione ufficiale Microsoft, capiamo in quali condizioni viene applicato il Default outbound access:
Per completezza andiamo a vedere in dettaglio quali sono i metodi espliciti, anticipati all’inizio dell’articolo, più utilizzati in Azure per garantire il traffico outbound:
Perché è consigliabile disabilitare il Default outbound access?
1. Motivi di sicurezza
Con un metodo implicito le risorse possono accedere a Internet senza che vi sia un controllo sulle connessioni in uscita dei sistemi e con un indirizzo IP difficilmente identificabile in quanto passibile di cambiamento.
Usando il principio di sicurezza di rete Zero Trust non è consigliabile aprire una rete virtuale su Internet per impostazione predefinita.
2. Conformità e auditing
Con il Default outbound access tracciare tutte le connessioni in uscita può essere complicato, molte organizzazioni necessitano un monitoraggio rigoroso del traffico di rete per poter rispettare determinati criteri di conformità.
Con un metodo esplicito è possibile definire policy più precise e controllare quali risorse possono comunicare con l’esterno.
3. Controllo dei costi
Il traffico egress in Azure può avere un impatto economico importante, motivo per cui è bene definire delle regole e, soprattutto, controllare le connessioni così da prevedere meglio i costi.
Come è possibile passare a un metodo esplicito di connettività?
Per disabilitare l’accesso in uscita predefinito ci sono alcune possibilità, ad esempio:
– Configurare un Network Security Group (NSG) per bloccare il traffico in uscita verso Internet.
– Impostare una Route Table per “forzare” il traffico Internet verso una appliance preposta alla navigazione.
In generale inibire totalmente il collegamento verso l’esterno può non essere l’approccio ideale poiché limita i processi di update e di attivazione dell’OS (Windows).
Oltre a queste soluzioni, Microsoft ha rilasciato in Public Preview la funzionalità Private Subnet proprio per favorire il passaggio ai metodi espliciti, disabilitando il default implicito.
Utilizzando le subnet private dovremo, poi, eseguire una di queste operazioni per garantire alle risorse l’accesso in uscita:
– Associare un indirizzo IP pubblico a una qualsiasi delle interfacce di rete delle macchine virtuali.
– Associare un Load Balancer configurato con regole in uscita.
– Associare un NAT Gateway alla subnet della macchina virtuale.
– Associare una Route Table, come visto in precedenza.
Ci sono, però, delle limitazioni nell’utilizzo di questa opzione:
– E’ possibile indicare una subnet come privata solo in fase di creazione.
– Le subnet preesistenti non possono essere convertite in private.
– Le Delegated Subnet non possono essere impostate come private.
Attivare la funzionalità Private Subnet.
Abbiamo appena detto che, al momento, è possibile attivare l’opzione solo in fase di creazione, ma la procedura è, sostanzialmente, la stessa che useremmo per una classica subnet. Servirà solo spuntare la voce “Enable private subnet”:
E’ possibile eseguire la stessa operazione anche in altro modo:
- Con PowerShell creando la subnet con New-AzVirtualNetworkSubnetConfig con l’opzione
DefaultOutboundAccess
scegliendo “$false“ - Usando la CLI con il comando az network vnet subnet create e utilizzando l’opzione
--default-outbound
con “false“ - Con Azure Resource Manager impostando il valore del parametro
defaultOutboundAccess
a “false“
In conclusione… le virtual machine esistenti che utilizzano l’accesso in uscita predefinito continueranno a funzionare. Sarà, però, importante definire già da ora una strategia atta a modificare le configurazioni di rete per adeguarsi alle nuove modalità imposte da Microsoft a partire dal 30 settembre 2025.