Microsoft AZ-500: Architettura della sicurezza di rete — Guida allo studio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

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

Panoramica

L’architettura di sicurezza di rete di Azure impone una connettività basata sul principio del privilegio minimo, presuppone la violazione (assume breach) e implementa un monitoraggio continuo. Combina la micro-segmentazione all’interno delle reti virtuali, piani di controllo stateful per il traffico est-ovest e in uscita (egress), protezioni perimetrali (edge) per gli endpoint esposti a Internet e accesso privato a PaaS. Una progettazione solida dà priorità all’accesso basato sull’identità a livello di applicazione, mantenendo al contempo confini di rete robusti, routing esplicito e telemetria verificabile.

Controlli e Segmentazione della Rete Virtuale

Le subnet sono il primo confine di segmentazione. Collocare i workload con livelli di fiducia, ciclo di vita e policy simili nella stessa subnet; separare i livelli (web, app, dati) in modo da poter applicare policy e route indipendenti. Evitare subnet “condivise” e piatte che mescolano strumenti di amministrazione, jump host e workload di business; complicano le policy e aumentano il raggio d’impatto (blast radius).

I Network Security Group (NSG) applicano un filtraggio stateful di livello L3-L4 per subnet o per NIC. Le regole in entrata (inbound) e in uscita (outbound) vengono valutate per priorità (il numero più basso per primo), con un DenyAll implicito alla fine. Gli NSG sono stateful: le risposte ai flussi consentiti sono permesse automaticamente, quindi raramente sono necessarie regole per le porte effimere. A livello operativo, associare gli NSG alle subnet per controlli ampi, per poi rifinire sulle NIC critiche. Documentare sempre proprietario, scopo e scadenza per qualsiasi regola di “allow” temporanea.

Gli Application Security Group (ASG) consentono di fare riferimento a gruppi di VM per nome anziché per IP, in modo che le regole sopravvivano allo scaling e alla variazione degli IP. Taggare le VM in ASG basati sul ruolo (es. asg-web, asg-app) ed esprimere policy come “asg-web → asg-app TCP 443”. Ciò riduce la proliferazione delle regole e la deriva operativa.

Le regole di sicurezza effettive risultano dalla fusione degli NSG applicati sia a una NIC che alla sua subnet. La regola di allow/deny corrispondente più specifica (in base alla priorità) prevale. Validare con le “Regole di sicurezza effettive” nel portale o tramite la verifica del flusso IP di Network Watcher per individuare voci in conflitto prima delle finestre di deployment.

I tag di servizio (es. AzureLoadBalancer, Storage, Sql, Internet, VirtualNetwork) sono gestiti da Microsoft e condensano spazi IP ampi e dinamici in destinazioni stabili per le regole. Preferire i tag di servizio alle liste di IP manuali per evitare interruzioni dovute alla rotazione degli IP dei servizi. Ad esempio, limitare il traffico in uscita (egress) verso Storage e Sql negando l’accesso generico a Internet.

La micro-segmentazione e lo Zero Trust si realizzano:

Applicando NSG con policy deny-by-default e aprendo solo percorsi espliciti e minimi.
Usando gli ASG per codificare l’intento del workload.
Limitando il traffico in uscita (egress) con tag di servizio o filtraggio basato su FQDN tramite Azure Firewall.
Imponendo la regola “nessun IP pubblico sui server” e instradando tutto il traffico in uscita attraverso un punto di ispezione controllato.

Esempio: creare una regola NSG che consenta il traffico da web ad app su TLS usando gli ASG e negare esplicitamente tutto il resto con una priorità più alta rispetto al deny implicito per documentare l’intento.

az network nsg rule create \
  --resource-group rg-sec \
  --nsg-name nsg-app \
  --name allow-web-to-app-443 \
  --priority 200 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-asgs asg-web \
  --destination-asgs asg-app \
  --destination-port-ranges 443

Servizi di Sicurezza di Rete e Protezione Perimetrale

Azure Firewall è un firewall completamente stateful, ad alta disponibilità e con policy centralizzata. Utilizzarlo per:

Controllo del traffico est-ovest e in uscita (egress) quando gli NSG non sono sufficienti (nomi di dominio, ispezione TLS).
DNAT per un’esposizione in entrata limitata quando Application Gateway non è adatto.
Logging centralizzato e threat intelligence.

I gruppi di raccolte di regole contengono raccolte di regole (Rete, Applicazione, NAT) con priorità che definiscono l’ordine di valutazione. All’interno di un gruppo, le raccolte con priorità più bassa vengono valutate per prime; le regole vengono abbinate in base ai criteri più specifici. Mantenere le regole DNAT in un proprio gruppo con la priorità di valutazione più alta per intercettare il traffico in entrata in modo deterministico.

Le regole di rete filtrano per 5-tupla (IP/porta/protocollo).
Le regole di applicazione filtrano per FQDN, categorie di URL (Premium) e possono usare tag FQDN.
Le regole NAT traducono indirizzi/porte pubblici in privati per scenari in entrata.

Il filtraggio basato sulla threat intelligence blocca IP/domini malevoli noti. Eseguire in modalità Avviso (Alert) durante la fase di analisi iniziale (baselining), poi passare a Nega (Deny) una volta risolti i falsi positivi.

Le funzionalità Premium aggiungono:

Ispezione TLS con decrittografia in uscita e in entrata, abilitando la visibilità L7 e l’IDPS.
Intrusion Detection and Prevention (IDPS) con firme e prioritizzazione delle vulnerabilità.
Filtraggio URL e categorie web per un controllo granulare del traffico in uscita.
Controlli avanzati per certificati e policy TLS.

A livello operativo, isolare il firewall in una subnet dedicata (AzureFirewallSubnet), instradare tutto il traffico diretto a Internet verso di esso con UDR (Route definite dall’utente) e abilitare le Availability Zones. Utilizzare Firewall Policy (non le regole classiche) per un’amministrazione scalabile, l’ereditarietà e la divergenza tra Dev/Test con una policy di base condivisa.

Il Web Application Firewall (WAF) mitiga gli attacchi L7 (SQLi, XSS).

Su Application Gateway, il WAF protegge le app regionali con TLS end-to-end e policy per sito; termina la connessione TLS del client e opzionalmente ricrittografa il traffico verso il backend.
Su Azure Front Door, il WAF protegge le app distribuite a livello globale sul perimetro (edge) con CDN integrata, protezioni anti-bot e controlli geografici.

Creare policy WAF e associarle a gateway, listener o route. Scegliere inizialmente la modalità Rilevamento (Detection) per l’ottimizzazione, poi la modalità Prevenzione (Prevention) per bloccare. Utilizzare i set di regole gestite (OWASP 3.x) e aggiungere regole personalizzate per limiti di frequenza (rate limit) o intervalli IP. Configurare esclusioni (es. campi JSON o header specifici) per ridurre i falsi positivi senza indebolire la protezione complessiva.

Distributed Denial of Service (DDoS):

Il piano Basic è una protezione sempre attiva a livello di piattaforma, ma non offre telemetria per risorsa né ottimizzazione della mitigazione.
DDoS Protection: Il piano Network Protection aggiunge ottimizzazione adattiva per IP pubblico, mitigazione automatica, analisi degli attacchi, avvisi, credito per la protezione dei costi e accesso al DDoS Rapid Response.

Abilitare Network Protection sulle VNet che ospitano IP pubblici (SKU Standard). Utilizzare la telemetria (Metriche, Log di diagnostica) per osservare i vettori di attacco, il ciclo di vita della mitigazione e la sua efficacia. Progettare le risorse protette dietro a load balancer o Application Gateway per assorbire il carico volumetrico e minimizzare l’esposizione pubblica diretta. Combinare WAF e DDoS per una difesa a più livelli.

Accesso privato, connettività ibrida e routing

Private Link e gli endpoint privati forniscono accesso tramite IP privato dalla tua VNet ai servizi PaaS. Un endpoint privato è una NIC nella tua subnet mappata alla risorsa PaaS; il traffico rimane sul backbone di Microsoft. Passaggi operativi:

Disabilitare l’accesso alla rete pubblica sulla risorsa PaaS per prevenire bypass.
Distribuire zone DNS private (es. privatelink.blob.core.windows.net) e collegarle alle VNet per una risoluzione dei nomi trasparente.
Gestire le approvazioni centralmente; considerare l’isolamento a livello di sottoscrizione/tenant con un flusso di lavoro di approvazione manuale.

Gli endpoint di servizio estendono l’identità della tua subnet alle risorse PaaS tramite i loro IP pubblici, consentendo al firewall PaaS di limitare l’accesso a subnet specifiche. Non creano IP privati, quindi il traffico in uscita passa attraverso il perimetro pubblico ma rimane all’interno della rete Microsoft. Utilizzare le policy degli endpoint di servizio per consentire solo gli account di archiviazione approvati. Per i carichi di lavoro containerizzati su VM IaaS, assicurarsi che venga utilizzato Azure CNI in modo che gli IP dei pod/container provengano dalla subnet; in caso contrario, l’endpoint di servizio non riconoscerà la sorgente e l’accesso potrebbe fallire.

Strategia di risoluzione DNS:

Per Private Link, assicurarsi che il percorso DNS risolva l’FQDN del servizio PaaS nell’endpoint privato. Utilizzare le zone DNS private di Azure, server d’inoltro condizionali sul DNS on-premise o Azure DNS Private Resolver per l’inoltro ibrido.
Mantenere chiari i mapping autorevoli di tipo split-horizon per evitare risoluzioni pubbliche intermittenti.

Connettività ibrida:

VPN Gateway: Per il site-to-site, utilizzare una VPN route-based con IKEv2 e algoritmi di cifratura robusti. Usare BGP per scambiare le route dinamicamente, semplificando la crescita e il failover. Applicare VPN NAT in presenza di spazi di indirizzamento sovrapposti. Per il tunneling forzato, annunciare la rotta 0.0.0.0/0 dall’ambiente on-premise tramite BGP o applicare UDR che inviano 0/0 a un’appliance virtuale; assicurarsi che esista una rotta di eccezione per gli intervalli privati PaaS, se necessario.
ExpressRoute: Fornisce connettività privata; la crittografia non è intrinseca. Utilizzare MACsec (per ExpressRoute Direct) o eseguire IPsec su ER per la riservatezza. Usare le community BGP e i filtri di rotta per il peering Microsoft. Supportare una configurazione attivo-attivo con ECMP tra i circuiti per la resilienza. Per il tunneling forzato, accettare le route predefinite dall’ambiente on-premise e assicurarsi che nessuna UDR in conflitto causi il blackhole dei percorsi internet.

Route definite dall’utente (UDR), NVA e precedenza:

La selezione della rotta utilizza il “longest prefix match” (corrispondenza del prefisso più lungo), poi l’origine: UDR > BGP > sistema. UDR 0/0 applicate in modo errato possono causare il blackhole dei percorsi di ritorno; verificare con la funzionalità next-hop di Network Watcher.
Per le NVA, abilitare l’inoltro IP sulle NIC e posizionarle dietro un servizio di bilanciamento del carico o un Gateway Load Balancer per un inserimento trasparente e scalabile. Preferire Azure Firewall per scenari gestiti; quando sono richieste funzionalità specifiche del fornitore, progettare l’alta disponibilità (HA) con più zone di disponibilità e un bilanciamento del carico basato su health probe.

Amministrazione Sicura, Monitoraggio e Telemetria

Connettività amministrativa sicura:

Azure Bastion fornisce connettività RDP/SSH su TLS dal portale o da un client nativo senza esporre gli IP pubblici delle VM. Utilizzare lo SKU Standard per la scalabilità, le connessioni basate su IP e i link condivisibili. Limitare l’accesso a Bastion tramite RBAC e Just-in-Time.
L’accesso Just-in-Time alle VM (Defender for Cloud) chiude le porte di gestione negli NSG e le apre su richiesta a tempo, con approvazione e limiti sugli IP di origine. Combinare con Bastion per una postura senza IP pubblici e una traccia di audit precisa.

Network Watcher fornisce verifica operativa e analisi forense:

I log di flusso NSG (v2) scrivono su uno storage e possono essere inviati a Traffic Analytics in Log Analytics per ottenere insight sui principali “talker”, sui flussi consentiti/negati e sulla geografia.
Connection troubleshoot testa attivamente la connettività end-to-end e segnala dove un percorso è bloccato (NSG, UDR, DNS, firewall).
La cattura dei pacchetti (Packet capture) può essere attivata on-demand o tramite alert; utilizzare buffer circolari (ring buffer) per ridurre lo storage e catturare solo le porte pertinenti.
Effective routes e IP flow verify mappano le decisioni a runtime tra UDR, BGP e NSG; automatizzare questi controlli nel preflight CI/CD.

Abilitare rapidamente i log di flusso NSG e l’analisi:

az network watcher flow-log configure \
  --resource-group rg-sec \
  --nsg nsg-app \
  --enabled true \
  --traffic-analytics true \
  --storage-account saflowlogs \
  --workspace /subscriptions/<sub>/resourceGroups/rg-la/providers/Microsoft.OperationalInsights/workspaces/la-workspace

Scenario Pratico

Starbucks sta modernizzando una piattaforma di gestione degli ordini su Azure. Obiettivi di sicurezza: nessun IP pubblico sui livelli applicativo e dati, egress restrittivo, protezione web globale e visibilità operativa.

Creare tre subnet per regione: web, app, data, ciascuna con il proprio NSG e ASG allineati al ruolo.

Motivazione: La micro-segmentazione basata su subnet con ASG codifica i flussi secondo il principio del privilegio minimo (web→app 443, app→data 1433) e riduce il raggio d’impatto (blast radius). NSG separati per ogni livello evitano l’accoppiamento accidentale delle policy.

Distribuire Azure Front Door Standard/Premium con una policy WAF in modalità Prevention utilizzando OWASP 3.x e regole personalizzate per il rate limiting e le restrizioni geografiche.

Motivazione: La protezione perimetrale globale (edge) assorbe il traffico volumetrico, blocca gli attacchi L7 comuni prima che raggiungano la regione e riduce la latenza tramite anycast. Le policy WAF sul perimetro forniscono un’applicazione coerente tra le regioni.

Posizionare un Application Gateway con WAF v2 in ogni regione di fronte al livello web; terminare il TLS sull’App Gateway e ricifrare verso il backend.

Motivazione: Il routing L7 regionale e il WAF completano Front Door, abilitando mTLS per-applicazione verso i backend, affinità basata su cookie e deployment blue/green, mantenendo al contempo la capacità di ispezione.

Abilitare la protezione DDoS: Network Protection sulle VNet che contengono gli IP pubblici dell’Application Gateway.

Motivazione: La mitigazione adattiva per-IP, la telemetria e la protezione dei costi riducono il rischio di attacchi volumetrici diretti ai punti di ingresso regionali. Lo scoping a livello di VNet garantisce che tutti gli IP pubblici attuali e futuri siano protetti senza configurazione per singola risorsa.

Distribuire Azure Firewall Premium in un hub protetto; instradare tutto il traffico in uscita (egress) dalle subnet app e data verso di esso con delle UDR. Abilitare l’ispezione TLS e l’IDPS per il traffico in uscita e configurare regole applicative per consentire solo gli FQDN richiesti.

Motivazione: Il controllo centralizzato dell’egress con decrittografia e rilevamento basato su firme previene il command-and-control e l’esfiltrazione di dati. Le regole applicative riducono la manutenzione rispetto alle regole basate su IP e si allineano a un approccio Zero Trust per l’egress.

Usare Private Link per Azure SQL e Storage; disabilitare l’accesso dalla rete pubblica e configurare zone DNS private collegate a tutte le VNet. Per i carichi di lavoro containerizzati, usare Azure CNI.

Motivazione: Gli endpoint privati mantengono i percorsi dei dati sulla backbone ed eliminano l’esposizione pubblica. Il DNS privato garantisce una risoluzione dei nomi trasparente. Azure CNI garantisce che gli IP dei pod provengano dalla subnet, in modo che Private Link e i service endpoint funzionino correttamente.

Stabilire una connessione ExpressRoute con doppi circuiti in modalità attivo-attivo e annunciare le rotte on-premise con BGP; abilitare IPsec su ER per il traffico sensibile. Inizialmente, non annunciare la rotta 0/0; testare il forced tunneling prima in una subnet di staging.

Motivazione: ER fornisce connettività privata e prevedibile; la crittografia a più livelli protegge i flussi ad alta sensibilità. Un rollout controllato del forced tunneling previene il blackholing accidentale di internet e convalida le rotte di eccezione.

Fornire accesso amministrativo tramite Azure Bastion e imporre il Just-in-Time su tutte le VM; rimuovere tutti gli IP pubblici dai server.

Motivazione: Elimina le superfici di gestione esposte preservando un accesso tracciabile, a tempo e allineato al principio del privilegio minimo.

Attivare i log di flusso NSG e Traffic Analytics, configurare la diagnostica di Firewall e WAF verso Log Analytics e impostare alert per le mitigazioni DDoS e per picchi di blocchi del WAF.

Motivazione: La telemetria unificata abilita il rilevamento proattivo, la pianificazione della capacità e una risposta rapida agli incidenti. L’invio di alert su pattern anomali permette di intercettare precocemente attacchi e configurazioni errate.

Implementare Azure Policy per negare gli IP pubblici sulle NIC, richiedere NSG su tutte le subnet e verificare le VNet senza protezione DDoS abilitata; integrare i controlli di policy nella CI/CD.

Motivazione: Previene il drift, impone guardrail su larga scala e rende i default sicuri ripetibili per i carichi di lavoro futuri.

← Gestione dell’identità e degli accessi · Tutti i domini · Sicurezza di compute →

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