Microsoft AZ-104: Reti virtuali di Azure — Guida allo studio

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Administrator Associate AZ-104 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Azure Virtual Networking costituisce il fabric del data center definito dal software (software-defined) per i carichi di lavoro IaaS e PaaS. Si progetta un piano di indirizzamento con CIDR, si suddividono le subnet allineandole ai confini di attendibilità (trust boundary), si proteggono i flussi est-ovest e nord-sud con i Network Security Group (NSG) e Azure Firewall, si connettono gli ambienti usando il VNet peering, VPN Gateway o ExpressRoute, si modella il traffico con le route definite dall’utente e si fornisce una risoluzione dei nomi affidabile con Azure DNS. L’implementazione corretta di questi costrutti abilita architetture hub-and-spoke scalabili, l’accesso sicuro ai servizi PaaS tramite Private Endpoint e un routing prevedibile che soddisfa i requisiti di conformità e prestazioni.

Indirizzamento, Segmentazione e Policy (VNet, Subnet, NSG, ASG, UDR)

Una rete virtuale (VNet) definisce uno o più spazi di indirizzi RFC1918 non sovrapposti utilizzando la notazione CIDR (ad esempio, 10.0.0.0/16). È possibile aggiungere prefissi di indirizzo aggiuntivi in un secondo momento, a condizione che non esistano conflitti con le reti in peering. Le subnet segmentano la VNet in blocchi instradabili (ad esempio, 10.0.1.0/24 per il web, 10.0.2.0/24 per le applicazioni). Riservare una GatewaySubnet dedicata per i gateway VPN/ExpressRoute; allocarla generosamente (almeno /27) per evitare futuri limiti di scalabilità. L’allocazione degli IP è dinamica per impostazione predefinita; è possibile impostare IP privati statici sulle NIC quando necessario.

Le route di sistema predefinite consentono il traffico intra-VNet e inviano 0.0.0.0/0 a Internet (in presenza di un IP pubblico). Le route definite dall’utente (UDR) sovrascrivono queste impostazioni predefinite a livello di subnet. Si crea una tabella di routing e la si associa a una subnet; le voci includono:

Next hop: Appliance virtuale (l’IP di una NVA sulla stessa VNet), Gateway di rete virtuale (per instradare verso l’on-premise tramite VPN/ExpressRoute), Internet (per forzare l’uscita verso Internet) o None (blackhole).
Forced tunneling: Inviare 0.0.0.0/0 a un gateway di rete virtuale per forzare tutto il traffico in uscita verso l’on-premise, o a una NVA/Azure Firewall per un controllo centralizzato dell’uscita. Se si utilizza BGP con un gateway che annuncia una route predefinita, considerare la disabilitazione della propagazione delle route del gateway su subnet specifiche per prevenire una selezione del percorso non intenzionale.

Gli NSG applicano policy stateful di livello L3-L4 sulle NIC o sulle subnet; entrambi gli ambiti possono essere usati simultaneamente e il traffico deve essere consentito da tutti gli NSG applicabili. Le regole vengono valutate per priorità (100–4096; i numeri più bassi hanno la precedenza) e direzione (in entrata/in uscita). Le regole predefinite includono:

In entrata (Inbound): AllowVnetInBound (65000), AllowLoadBalancerInBound (65001), DenyAllInBound (65500)
In uscita (Outbound): AllowVnetOutBound (65000), AllowInternetOutBound (65001), DenyAllOutBound (65500) È possibile sovrascrivere le impostazioni predefinite con regole personalizzate a priorità più alta. Utilizzare i service tag (ad esempio, Internet, AzureLoadBalancer, Storage) per semplificare la manutenzione e gli IP Group per elenchi di indirizzi riutilizzabili.

Gli Application Security Group (ASG) disaccoppiano l’indirizzamento IP dalla policy. Si assegnano le NIC agli ASG che rappresentano i ruoli (ad esempio, Web, App, DB) e si fa riferimento a tali ASG nelle regole degli NSG. Questo permette di modificare le policy senza intervenire su IP o subnet e facilita una segmentazione coerente basata sui ruoli all’interno di una VNet.

Opzioni di connettività: Peering, Gateway VPN ed ExpressRoute

Il peering di VNet connette le VNet tramite il backbone di Microsoft con bassa latenza e larghezza di banda elevata. Il peering locale è all’interno di una regione; il peering globale si estende tra regioni. Il peering non è transitivo e richiede spazi di indirizzi non sovrapposti. Flag principali:

Allow virtual network access abilita la connettività instradata tra le reti in peering.
Allow forwarded traffic permette al traffico inoltrato dalle NVA di attraversare il peering.
Use remote gateways consente a una VNet di utilizzare un gateway VPN/ER in un “hub” in peering. L’hub deve avere l’opzione Allow gateway transit abilitata. Una VNet può utilizzare i gateway remoti di un solo peer. Le VNet in peering non ricevono automaticamente le route dei client P2S; gli utenti finali devono installare configurazioni aggiornate del client VPN che includano le route verso i nuovi spoke.

Il Gateway VPN di Azure fornisce tunnel IPSec/IKE:

Da sito a sito (S2S) connette dispositivi VPN locali (on-premise) ad Azure; utilizzare una VPN basata su route (IKEv2) per la maggior parte degli scenari, specialmente con BGP e tunnel multipli.
Da punto a sito (P2S) consente a client individuali (Windows, macOS, Linux) di connettersi utilizzando OpenVPN, IKEv2 o SSTP. La configurazione del client contiene route statiche verso i prefissi di Azure; riscaricarla quando gli spazi di indirizzi cambiano o si aggiungono spoke raggiungibili dietro un hub.
Da VNet a VNet utilizza S2S all’interno di regioni/tenant di Azure, richiedendo indirizzi non sovrapposti. Utile quando il peering non è possibile (ad esempio, tra tenant diversi con confini amministrativi).
SKU: Preferire VpnGw1–VpnGw5 (e le varianti AZ per la ridondanza di zona). Lo SKU Basic è obsoleto e privo di funzionalità (nessun supporto IKEv2/BGP). Quello basato su route supporta P2S, BGP e la modalità attivo-attivo. Quello basato su policy è limitato (solo S2S, nessun BGP).
BGP annuncia i prefissi dinamicamente, supporta il transito attraverso più tunnel e semplifica il failover delle route. Le regole NAT della VPN possono tradurre prefissi locali/Azure sovrapposti quando ciò è inevitabile.

ExpressRoute fornisce connettività privata, supportata da SLA, tramite il circuito di un partner verso la rete perimetrale (edge) di Microsoft:

Un circuito viene fornito dal provider (larghezza di banda, misurazione, SKU) e collegato alla propria sottoscrizione tramite una chiave di servizio. La ridondanza è integrata: ogni circuito espone doppie connessioni primarie/secondarie; il router dovrebbe stabilire doppie sessioni BGP per l’alta disponibilità (HA).
Tipi di peering:
- Peering privato trasporta il traffico privato RFC1918 verso le VNet tramite un gateway di rete virtuale ExpressRoute (ErGw1AZ–ErGw3AZ). Supporta BGP, failover rapido e l’opzione FastPath per l’accelerazione del piano dati.
- Peering Microsoft espone i servizi pubblici di Microsoft (ad esempio, Archiviazione, SQL, Microsoft 365) tramite IP pubblici con filtri di route. Utilizzare per endpoint esposti su Internet rimanendo al di fuori della rete Internet pubblica. Microsoft 365 richiede una revisione aggiuntiva.
Utilizzare ExpressRoute Global Reach per interconnettere siti locali tramite il backbone di Microsoft. Per il tunneling forzato, annunciare una route predefinita sul peering privato, oppure abbinarlo a UDR/Azure Firewall per un’uscita selettiva del traffico.

Coesistenza: Una VNet può avere sia un gateway VPN che uno ExpressRoute utilizzando la stessa GatewaySubnet; utilizzare il transito del gateway e le UDR per controllare i flussi. ExpressRoute è preferibile per il traffico aziendale a regime; la VPN funge da backup o per raggiungere filiali/piccoli uffici.

Risoluzione dei nomi e accesso sicuro a PaaS (Azure DNS, Endpoint)

Azure DNS ospita zone pubbliche in modo che i record esposti su Internet risiedano sulla piattaforma DNS globale di Azure con alta disponibilità. Per la risoluzione all’interno delle VNet, le Zone private di Azure DNS forniscono un servizio di nomi split-horizon. Collega le VNet a una zona privata per abilitare la risoluzione; opzionalmente, abilita la registrazione automatica in modo che i record A delle VM si registrino e si aggiornino automaticamente al cambio di IP della NIC. Per la risoluzione dei nomi ibrida e l’inoltro condizionale tra Azure e l’ambiente locale, implementare Azure DNS Private Resolver con endpoint in ingresso/in uscita e set di regole che inoltrano domini selezionati (ad esempio, corp.contoso.com al DNS locale, o privatelink.* di nuovo verso Azure).

Gli Endpoint di servizio estendono l’identità della VNet a servizi Azure selezionati (ad esempio, Archiviazione, SQL) tramite il backbone di Microsoft, mantenendo l’IP pubblico del servizio. Sul firewall PaaS, si limita l’accesso a specifiche VNet/subnet. Sono facili da abilitare per subnet e per servizio, non richiedono modifiche al DNS e funzionano bene per scenari semplici, esclusivamente su Azure. Tuttavia, la risorsa ha ancora un IP pubblico e non è indirizzabile privatamente dall’ambiente locale senza passare attraverso l’endpoint pubblico.

Gli Endpoint privati collocano una NIC con un IP privato dalla propria subnet sulla risorsa PaaS tramite Private Link. Il traffico rimane sulla rete privata, consentendo un controllo granulare sull’esfiltrazione dei dati e l’accesso dall’ambiente locale tramite VPN/ExpressRoute. Un DNS configurato correttamente è essenziale: sovrascrivere l’FQDN pubblico della risorsa affinché si risolva nel suo FQDN privatelink, che punta all’IP privato. Utilizzare le zone DNS private di Azure (ad esempio, privatelink.blob.core.windows.net) collegate alle VNet. Scegliere gli Endpoint privati quando si necessita di un indirizzamento veramente privato, di accesso tra ambienti diversi (locale e cloud) e di controlli rigorosi sul traffico in uscita.

Azure Firewall e governance centralizzata del traffico in uscita/entrata (Egress/Ingress)

Azure Firewall è un firewall stateful e cloud-native che si adatta in modo elastico e fornisce policy centralizzate per architetture hub-and-spoke. Va distribuito in una AzureFirewallSubnet dedicata. Per scenari di forced tunneling, aggiungere una AzureFirewallManagementSubnet in modo che il traffico di gestione utilizzi Internet, mentre il traffico dati segua la rotta predefinita.

I tipi di raccolte di regole (rule collection) vengono applicati in questo ordine e secondo la priorità della raccolta:

Regole DNAT: traducono IP/porte pubblici in entrata sul firewall in indirizzi privati (ad esempio, mappano l’IP pubblico del firewall sulla porta 443 a una VM web). Abbinare con NSG sulla subnet di destinazione per applicare il principio del privilegio minimo (least privilege).
Regole di rete (Network rules): filtrano il traffico L3–L4 (IP di origine/destinazione, protocolli, porte). Utilizzare per protocolli non HTTP(S) e per controllare i flussi in uscita e tra spoke.
Regole applicative (Application rules): controllano il traffico HTTP/S in uscita per FQDN o tag FQDN (ad esempio, WindowsUpdate). Lo SKU Premium aggiunge l’ispezione TLS e l’IDPS per un filtraggio approfondito di HTTP(S). La Threat Intelligence può essere impostata su Alert (Avvisa) o Deny (Nega) per agire su IP/domini malevoli noti. Combinare Azure Firewall con UDR (0.0.0.0/0 verso il firewall come appliance virtuale) per centralizzare il traffico in uscita; consentire il traffico inoltrato (forwarded traffic) sul peering per gli spoke. Inviare i log a Log Analytics per audit e analisi, e utilizzare gerarchie di policy e Azure Firewall Manager per standardizzare su larga scala.

Scenario di un problema pratico

Adobe deve modernizzare una rete ibrida: un hub sicuro in Azure deve fornire un’uscita centralizzata verso Internet, connettività on-premise ad alta disponibilità, accesso privato a Storage e SQL, e una risoluzione dei nomi prevedibile tra Azure e i data center. Gli sviluppatori remoti necessitano anche di un accesso P2S a tutti gli spoke.

Progettare lo spazio di indirizzamento e la segmentazione

Creare una VNet Hub 10.0.0.0/16 con le subnet: AzureFirewallSubnet 10.0.0.0/26, GatewaySubnet 10.0.0.64/27, SharedServices 10.0.1.0/24. Creare VNet Spoke per le App 10.1.0.0/16 e per i Dati 10.2.0.0/16.
Motivazione: CIDR non sovrapposti consentono il peering e la crescita futura; le subnet dedicate soddisfano i requisiti della piattaforma e semplificano la definizione dell’ambito di UDR/NSG.

Stabilire la connettività hub-and-spoke

Eseguire il peering Hub↔Apps e Hub↔Data con le opzioni Allow virtual network access e Allow forwarded traffic. Sull’hub, impostare Allow gateway transit; sugli spoke, impostare Use remote gateways.
Motivazione: Centralizza i flussi nord-sud attraverso il gateway/firewall dell’hub, consentendo al contempo i flussi est-ovest tramite l’hub, evitando la complessità di una topologia mesh.

Fornire connettività on-premise privata e ridondante

Ordinare un circuito ExpressRoute (Private Peering) tramite un provider; configurare due sessioni BGP. Distribuire un gateway di rete virtuale ExpressRoute (ErGw2AZ) nella GatewaySubnet dell’hub e collegare il circuito.
Motivazione: Una connettività privata, supportata da SLA, con ridondanza integrata e un gateway con ridondanza di zona (zone-redundant) soddisfa le esigenze aziendali di alta disponibilità e prestazioni.

Centralizzare il traffico in uscita e proteggere i workload

Distribuire un Azure Firewall Standard nella AzureFirewallSubnet. Creare una UDR su ogni subnet degli spoke: hop successivo (next hop) 0.0.0.0/0 di tipo Virtual appliance → IP privato del firewall. Aggiungere NSG agli spoke consentendo solo le porte necessarie verso il firewall e all’interno della VNet.
Motivazione: Azure Firewall + UDR applicano policy di uscita coerenti, logging e threat intelligence; gli NSG forniscono micro-segmentazione a livello di subnet/NIC.

Mettere in sicurezza i servizi PaaS con un accesso realmente privato

Creare Private Endpoint per Storage e SQL nello spoke dei Dati. Collegare le zone DNS privato di Azure (privatelink.blob.core.windows.net, privatelink.database.windows.net) all’Hub e agli Spoke. Disabilitare l’accesso dalla rete pubblica sulle risorse PaaS.
Motivazione: I Private Endpoint eliminano l’esposizione pubblica e consentono l’accesso dall’ambiente on-premise tramite ExpressRoute; Azure Private DNS garantisce la corretta risoluzione dei nomi.

Implementare la risoluzione dei nomi ibrida e l’inoltro condizionale

Distribuire Azure DNS Private Resolver nell’hub con endpoint in entrata e in uscita. Creare regole per inoltrare le query per corp.adobe.com al DNS on-premise e per risolvere le zone privatelink all’interno di Azure.
Motivazione: Fornisce un DNS deterministico di tipo split-horizon tra Azure e l’ambiente on-premise senza la necessità di VM DNS personalizzate.

Abilitare l’accesso degli sviluppatori remoti a tutti gli spoke

Configurare una VPN P2S sul VPN Gateway dell’hub in coesistenza con ExpressRoute. Distribuire il profilo del client VPN. Dopo aver aggiunto gli spoke, scaricare nuovamente il pacchetto client in modo che le rotte verso 10.1.0.0/16 e 10.2.0.0/16 siano incluse.
Motivazione: Una P2S basata sull’hub semplifica le operazioni e, con le rotte client aggiornate e il transito del gateway di peering, offre agli utenti la raggiungibilità di tutti gli spoke.

Rafforzare la sicurezza con ASG e NSG

Assegnare le NIC agli ASG (Web, App, DB) e implementare regole NSG che consentano Web→App (TCP 443), App→DB (TCP 1433) per ASG, negando tutto il resto. Mantenere le regole predefinite dove appropriato.
Motivazione: Le policy basate sui ruoli sono scalabili senza la gestione degli IP e applicano il principio del privilegio minimo.

Questa architettura soddisfa i requisiti di Adobe con la ridondanza di ExpressRoute, la governance centralizzata di Azure Firewall, l’accesso privato ai servizi PaaS e un DNS coerente, garantendo al contempo che gli utenti remoti e i sistemi on-premise possano raggiungere in modo sicuro ogni workload attraverso l’hub.

← Macchine virtuali di Azure e Compute · Tutti i domini · Bilanciamento del carico di Azure e Gestione del traffico →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →