• Cloud, Guide, Sicurezza
• 1 Maggio 2024

Attualmente quando si creano macchine virtuali in una rete virtuale in Azure senza una connettività in uscita esplicitamente configurata, queste ricevono automaticamente un indirizzo IP pubblico per le connessioni in uscita. Tuttavia, questa configurazione di default verrà eliminata il 30 settembre 2025, come annunciato alla pagina Default outbound access for VMs in Azure will be retired— transition to a new method of internet access | Azure updates | Microsoft Azure. Dopo questa data, tutte le nuove macchine virtuali che necessiteranno di accesso a Internet dovranno utilizzare uno dei metodi di connettività in uscita espliciti, come:

• Azure NAT Gateway
• Azure Firewall
• Regole di uscita di Azure Load Balancer
• Un indirizzo IP pubblico direttamente assegnato.

La funzione di sottorete privata (Azure Private Subnet) permette di evitare questa connettività in uscita implicita e potenzialmente insicura per le nuove sottoreti create. Impostando la sottorete come privata, si impedirà alle macchine virtuali all’interno di quella sottorete di utilizzare l’accesso in uscita predefinito per connettersi a endpoint pubblici.

Figura 1: esempio di explicit outbound connectivity per le Azure VM

Figura 2: Gestione dell’outbound connectivity per le Azure VM

Disabilitazione dell’accesso in uscita (outbound connectivity)

Disabilitare l’accesso in uscita predefinito è raccomandato per vari motivi legati alla sicurezza e alla stabilità delle reti virtuali in Azure. Ecco i principali motivi per cui si consiglia questa pratica:

1. Sicurezza di default: Non è raccomandato aprire una rete virtuale a Internet in modo predefinito seguendo il principio di sicurezza della rete zero trust. Questo principio sostiene che non si dovrebbe fidarsi di nessuna entità all’interno o all’esterno della rete senza verifica.
2. Esplicito vs Implicito: È consigliabile avere metodi di connettività espliciti invece che impliciti quando si concede l’accesso alle risorse nella rete virtuale. Questo approccio aumenta la visibilità e il controllo sulla sicurezza, riducendo il rischio di accessi non autorizzati o configurazioni errate.
3. Modifica dell’indirizzo IP: I clienti non possiedono l’indirizzo IP usato per l’accesso in uscita predefinito. Questo indirizzo può cambiare e qualsiasi dipendenza da esso potrebbe causare problemi in futuro. Utilizzando metodi di uscita espliciti, si ha un controllo maggiore e si evitano interruzioni dovute a cambiamenti imprevisti dell’IP.

Alcuni esempi di configurazioni che potrebbero non funzionare con l’accesso in uscita predefinito sono:

• Quando una macchina virtuale ha più schede di rete (NIC), gli indirizzi IP in uscita predefiniti potrebbero non essere consistenti tra tutte le NIC.
• Nel caso di scalabilità dei Virtual Machine Scale Sets, gli indirizzi IP in uscita assegnati alle singole istanze possono cambiare frequentemente.
• Similmente, gli indirizzi IP in uscita predefiniti non sono consistenti o contigui tra le istanze di macchine virtuali in un set di scalabilità.

Disabilitare l’accesso in uscita predefinito e optare per configurazioni di connettività esplicite aiuta a garantire una maggiore sicurezza e stabilità nella gestione delle reti e delle risorse cloud.

Creazione di una Azure Private Subnet

Nelle vostre architetture di rete su Microsoft Azure potete utilizzare le Azure Private Subnet per organizzare e isolare le risorse in modo efficace e sicuro all’interno di una rete virtuale. Queste sottoreti vi permettono di separare le risorse di rete, garantendo così migliore sicurezza e una gestione del traffico più efficiente.

Quando configurate una sottorete privata, potete applicare gruppi di sicurezza di rete (NSG) per controllare rigorosamente chi può accedere a queste risorse e in che modo. Questo vi dà un controllo granulare sul traffico in entrata e in uscita, aumentando la sicurezza delle vostre applicazioni e dati.

Le sottoreti private possono anche essere configurate per interfacciarsi in modo sicuro con altri servizi di Azure, come Azure SQL Database e Azure Storage, utilizzando endpoint di servizio o Azure Private Link per un accesso diretto e sicuro.

Per le aziende che richiedono integrazione con infrastrutture esistenti, le sottoreti private in Azure possono essere collegate alla vostra rete on-premise attraverso soluzioni VPN o Azure ExpressRoute, offrendo una connessione continua e protetta tra cloud e locale.

Infine, le sottoreti private in Azure sono altamente scalabili e configurabili, permettendovi di adattare le risorse di rete alle esigenze specifiche del vostro ambiente, senza compromettere la sicurezza o le prestazioni.

La creazione di una Azure Private Subnet è molto semplice e può essere effettuata dal portale di Azure. Nelle figure sotto sono mostrati tutti i passaggi.

NOTA: La definizione di Private Subnet deve essere effettuata al momento della creazione e non può essere successivamente cambiata.

Figura 3: Creazione di una nuova VNET

Figura 4: Scheda Security del wizard per la creazione di una nuova VNET

Nella scheda IP Addresses del wizard per la creazione di una nuova VNET aggiungete una nuova Subnet e mettete il segno di spunta su Enable private subnet (no default outboud access).

NOTA: Per attivare o aggiornare i sistemi operativi delle macchine virtuali, inclusi quelli Windows, è necessario disporre di un metodo esplicito di connettività in uscita. Questo requisito è fondamentale perché le operazioni di attivazione e aggiornamento spesso richiedono una connessione a server esterni per verificare licenze o scaricare aggiornamenti software.

Figura 5: Creazione della Azure Private Subnet

Come si può vedere dalla figura sotto, nella VNET ho creato sue subnet diverse, una “normale” ed una “private”.

Figura 6: Subnet create nella Azure VNET

Figura 7: Schermata di riepilogo del wizard di creazione una nuova VNET

Test di funzionamento

Ho proceduto quindi alla creazione di due Azure VM, la prima collegata alla subnet default e la seconda collegata alla provate subnet Private. Come si può vedere dalla figura sotto, la VM chiamata VM-PRIVATE è collegata alla subnet Private e non ha un IP pubblico.

Figura 8: la VM chiamata VM-PRIVATE è collegata alla subnet Private e non ha un IP pubblico

Collegandomi alla VM chiamata VM-PRIVATE ho verificato che effettivamente la VM non aveva connettività in uscita, come mostrato nella figura sotto.

Figura 9: La VM chiamata VM-PRIVATE non ha connettività in uscita

Creazione dell’Azure NAT Gateway per permettere la connettività in uscita

Come già scritto prima, per attivare o aggiornare i sistemi operativi delle macchine virtuali, inclusi quelli Windows, è necessario disporre di un metodo esplicito di connettività in uscita. Questo requisito è fondamentale perché le operazioni di attivazione e aggiornamento spesso richiedono una connessione a server esterni per verificare licenze o scaricare aggiornamenti software.

Io ho deciso di configurare la connettività in uscita attraverso un Azure NAT Gateway, di cui avevo già parlato nella guida Azure NAT Gateway – Gestione del traffico in uscita dalle VM eseguite in Azure – ICT Power

L’Azure NAT Gateway è un servizio di Microsoft Azure che fornisce Network Address Translation (NAT) per le risorse all’interno di una rete virtuale di Azure. Questo servizio consente alle macchine virtuali e ad altre risorse senza indirizzi IP pubblici diretti di accedere a Internet per operazioni di uscita, garantendo al contempo che il traffico in entrata rimanga non consentito, a meno che non sia configurato diversamente.

Azure NAT Gateway permette di utilizzare uno o più indirizzi IP pubblici statici per il traffico in uscita ed è progettato per gestire carichi di lavoro di grandi dimensioni, offrendo una capacità di throughput elevata. Poiché il NAT Gateway gestisce solo il traffico in uscita, l’accesso in entrata non è permesso a meno di configurazioni specifiche, contribuendo a una migliore postura di sicurezza della rete.

Figura 10: Wizard di creazione di un nuovo Azure NAT Gateway

Nella schermata successiva vi verrà richiesto di indicare (se già ne avete creato uno) o di creare l’indirizzo IP pubblico che verrà associato al NAT Gateway. È anche possibile associare un Public IP Prefix, cioè un intervallo riservato di indirizzi IP per gli endpoint pubblici in Azure. Azure consente di allocare un intervallo contiguo di indirizzi IP alla sottoscrizione in base al numero specificato. Trovate maggiori info alla pagina Azure Public IP address prefix – Azure Virtual Network | Microsoft Learn

Figura 11: Assegnazione dell’indirizzo IP pubblico stato all’Azure NAT Gateway

Scegliete a questo punto a quale rete virtuale e rispettive subnet volete associare il NAT Gateway. Lo stesso gateway può essere associato a più subnet contemporaneamente.

Ho associato quindi l’Azure NAT Gateway alla VNET e alla Private subnet che ho configurato precedentemente.

Figura 12: Connessione dell’Azure NAT Gateway alla VNET e alla Private Subnet

Controllate i valori inseriti e procedete alla creazione del NAT Gateway.

Figura 13: Schermata di riepilogo del wizard di creazione dell’Azure NAT Gateway

Dopo un paio di minuti il NAT Gateway sarà creato, sarà operativo e le Azure VM collegate alla private subnet potranno navigare.

Azure NAT Gateway supporta i protocolli UDP (User Datagram Protocol) e TCP (Transmission Control Protocol) IPv4. Il ping non è supportato perché utilizza il protocollo ICMP. Vi rimando alla pagina Risolvere i problemi del gateway NAT di Azure – Azure NAT Gateway | Microsoft Learn per eventuali approfondimenti.

Come si può vedere dalla figura sotto, la VM non riesce ad utilizzare il protocollo ICMP ma è in grado di navigare in internet.

Figura 14: La Azure VM collegata alla Private subnet è in grado di navigare attraverso il NAT Gateway

Conclusioni

La gestione della navigazione in uscita delle Azure VM tramite l’uso delle Azure Private Subnet rappresenta un approccio fondamentale per rafforzare la sicurezza delle vostre architetture di rete in cloud. L’implementazione di sottoreti private e la scelta di metodi di connettività in uscita espliciti, come Azure NAT Gateway, Azure Firewall, Azure Load Balancer con regole di uscita o l’assegnazione diretta di indirizzi IP pubblici, vi permettono di controllare rigorosamente il traffico in uscita, minimizzando l’esposizione a rischi di sicurezza.

Ricordate che la configurazione di una rete sicura non solo protegge le vostre risorse da accessi non autorizzati, ma garantisce anche che le operazioni critiche, come l’aggiornamento e la manutenzione dei sistemi operativi delle VM, siano eseguite senza interruzioni. Implementando questi controlli, potete migliorare notevolmente la gestione della sicurezza e delle prestazioni delle vostre risorse cloud.

Infine, è essenziale continuare a monitorare e valutare l’efficacia delle vostre strategie di sicurezza di rete per assicurarvi che siano sempre allineate con le migliori pratiche e con le esigenze aziendali in evoluzione. L’utilizzo di strumenti e servizi Azure per la diagnostica e il monitoraggio del traffico può aiutarvi a mantenere le vostre configurazioni ottimali e sicure nel tempo.