Microsoft AZ-700: Sicurezza di rete — Guida allo studio

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

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

Controllo dell’accesso alla rete: progettazione di NSG e ASG, routing e peering

I Network Security Group (NSG) rimangono il meccanismo principale e a basso costo per filtrare il traffico in entrata e in uscita da subnet e NIC. Gli NSG sono stateful, possono fare riferimento a tag di servizio (es. Internet, Storage) e supportano gli application security group (ASG) per raggruppare le NIC delle VM e scalare la manutenzione delle regole per flotte di grandi dimensioni. Applica gli NSG a livello di subnet per una segmentazione ampia e a livello di NIC per eccezioni specifiche dell’host; ricorda che vengono valutati entrambi e si applica il set di regole effettivo più restrittivo. Le trappole più comuni includono dimenticare le regole predefinite (regole di sistema di negazione/permesso con priorità elevate), ordinare in modo errato le priorità (le priorità delle regole NSG vanno da 100 a 4096; quelle predefinite di sistema si trovano a 65.000 e oltre) e presumere che gli NSG forniscano funzionalità IDS/antivirus — non ispezionano i payload. Quando si effettua il peering di reti virtuali, gli NSG governano ancora il traffico tra i peer, ma le UDR (user-defined route, route definite dall’utente) possono sovrascrivere le route di sistema e involontariamente causare un blackhole del traffico se un next hop (ad esempio, verso un Azure Firewall) non è raggiungibile in quel contesto. I compromessi di progettazione mettono a confronto il costo e la semplicità di NSG/ASG con la visibilità e i controlli avanzati di un firewall centralizzato: gli NSG sono economici e performanti per un filtraggio grossolano; utilizza un firewall gestito per il logging centralizzato, il controllo DNAT/NAT e le policy a livello di applicazione.

Controlli perimetrali ed est-ovest: Azure Firewall, DNAT, regole applicative e IDPS

Azure Firewall fornisce un perimetro stateful gestito in grado di gestire DNAT, SNAT e regole a livello di applicazione. Progettalo in una AzureFirewallSubnet dedicata e utilizza le tabelle di routing per dirigere il traffico est-ovest hub-spoke attraverso il firewall per l’ispezione. Usa le raccolte di regole DNAT per pubblicare servizi interni: specifica gli intervalli di origine, l’IP di destinazione, le porte di destinazione e l’IP:porta tradotti. Le raccolte di regole di applicazione ti consentono di autorizzare tramite FQDN per HTTP/S (es. *.microsoft.com), il che evita di usare fragili allowlist basate su IP. Per la deep packet inspection e l’ispezione del traffico crittografato, Azure Firewall Premium aggiunge un motore IDPS e l’ispezione TLS, a un costo e una complessità operativa maggiori per la gestione dei certificati e una potenziale latenza. Le NVA di terze parti rimangono una scelta valida quando hai bisogno di firme specializzate o caratteristiche di performance particolari. Le decisioni su scalabilità e resilienza includono l’uso dell’autoscale del Firewall (v2) o di distribuzioni con ridondanza di zona rispetto a istanze fisse: l’autoscale allevia i vincoli di throughput ma è più costoso. Monitora le metriche e i log del firewall in Log Analytics per rilevare l’esaurimento delle porte DNAT/SNAT e, se necessario, ottimizzare l’ordine delle regole e il numero di IP pubblici.

Azure Firewall Standard: filtraggio stateful L3–L7, NAT/DNAT, regole di applicazione e di rete, servizio gestito con opzioni di autoscale e logging integrato.
Azure Firewall Premium: include le funzionalità Standard più IDPS, ispezione TLS, threat intelligence avanzata e filtraggio URL; ha un costo maggiore e richiede la gestione di certificati/chiavi per l’ispezione TLS.

Protezione a livello applicativo, Private Link e DDoS

Proteggi le applicazioni web all’edge con i WAF e servizi edge distribuiti. Application Gateway WAF_v2 fornisce un WAF regionale con integrazione in una VNet ed è ideale quando i backend sono privati (App Service con ASE o VM). Azure Front Door (edge) fornisce bilanciamento del carico globale e WAF all’edge della CDN e riduce la latenza per i client globali; scegli Front Door per il failover globale e Application Gateway per la protezione di backend privati a livello regionale. La protezione DDoS (Basic inclusa) dovrebbe essere aggiornata a DDoS Protection Standard dove gli IP pubblici ospitano servizi importanti; profila automaticamente il traffico e mitiga gli attacchi volumetrici per le risorse in una rete virtuale protetta. Per l’accesso privato, Private Link/Private Endpoint forniscono un IP privato nella tua VNet per i servizi di piattaforma, eliminando l’esposizione pubblica. Le trappole più comuni includono dimenticare di disabilitare l’accesso di rete pubblico sulla risorsa PaaS, gestire in modo errato l’integrazione del DNS privato (è necessario possedere e mappare le zone privatelink o configurare forwarder condizionali) e aspettarsi che i WAF all’edge raggiungano i private endpoint senza un proxy regionale; spesso un piccolo reverse-proxy con hardening (Application Gateway o Firewall) in una subnet perimetrale instrada il traffico dal front-door al private endpoint.

Controlli operativi: logging, policy, monitoraggio e trappole comuni per gli ingegneri

L’igiene operativa è spesso l’elemento che distingue gli ambienti di rete sicuri da quelli fragili. Abilitare i NSG Flow Logs (v2) e la diagnostica di Azure Firewall verso un’area di lavoro Log Analytics gestita centralmente e collegarli ad Azure Monitor e Sentinel per l’analisi, la ricerca di minacce (threat hunting) e gli avvisi. Utilizzare Traffic Analytics per ottenere una topologia aggregata, individuare i principali comunicatori (top talkers) e le anomalie di flusso; ricordare che Traffic Analytics richiede Network Watcher e un’area di lavoro Log Analytics nella stessa regione. Per i collegamenti ibridi, Network Performance Monitor (NPM) e Connection Monitor forniscono misurazioni periodiche di latenza, jitter e stato del percorso, che aiutano a comprovare gli SLA per ExpressRoute e SD-WAN. Applicare i guardrail con Azure Policy: richiedere Azure Firewall negli hub, non consentire la creazione di IP pubblici su risorse destinate a essere solo private e verificare gli intervalli di priorità delle regole NSG o le regole senza tag. Le trappole comuni includono la precedenza delle route (le UDR sovrascrivono le route di sistema), l’esaurimento delle porte SNAT quando molte connessioni escono attraverso un singolo IP pubblico (mitigare aggiungendo IP pubblici o utilizzando la scalabilità automatica del firewall) e i requisiti di denominazione delle subnet (AzureFirewallSubnet deve esistere per il Firewall). Le decisioni sul bilanciamento tra resilienza e costo sono iterative: centralizzare l’ispezione per la visibilità, ma localizzarla per i percorsi sensibili alla latenza e utilizzare la scalabilità automatica/ridondanza di zona dove i carichi di lavoro sono critici.

Problema Pratico: Scenario d’Uso

Scenario: Contoso Ltd. gestisce una rete Azure hub-and-spoke che si estende su due regioni, con una VNet hub centrale contenente un Azure Firewall zonale e servizi condivisi. Le sedi secondarie (branch) si connettono tramite SD-WAN BGP agli hub regionali. Diverse app web PaaS utilizzano endpoint privati nelle VNet spoke.

Sfida: I clienti da Internet devono raggiungere una front door pubblica per il routing globale, ma il traffico di backend delle app web deve terminare su endpoint privati e tutto il traffico in uscita (egress) dagli spoke deve essere ispezionato e registrato senza esporre pubblicamente le risorse PaaS.

Approccio Raccomandato:

Distribuire Azure Front Door Standard/Premium come punto di ingresso pubblico globale e collegare un Application Gateway regionale in ogni hub come origine privata, oppure utilizzare Front Door Premium con una configurazione di origine privata sicura dove supportato.
Posizionare un Application Gateway v2 nella subnet della VNet hub (dedicata per ogni AGW) e configurarlo per inoltrare il traffico all’App Service Private Endpoint tramite peering VNet; abilitare WAF_v2 sull’Application Gateway e associare una policy WAF gestita.
Instradare tutto il traffico in uscita (outbound) degli spoke attraverso l’Azure Firewall Premium dell’hub (in AzureFirewallSubnet) utilizzando UDR sugli spoke; abilitare le regole DNAT per le traduzioni in ingresso (inbound) necessarie e le regole applicative per l’uscita (egress) basata su FQDN; abilitare l’IDPS e l’ispezione TLS sulla SKU Premium per la visibilità del traffico crittografato.
Centralizzare i log in un’area di lavoro Log Analytics, abilitare NSG Flow Logs e Traffic Analytics, abilitare DDoS Protection Standard sugli IP pubblici dell’hub e imporre l’architettura con Azure Policy (richiedere il Firewall, non consentire l’accesso di rete pubblico su PaaS).

Motivazione: Front Door offre disponibilità globale e bassa latenza, Application Gateway con WAF_v2 protegge i backend privati e Azure Firewall Premium fornisce ispezione centralizzata, DNAT e IDPS sia per il traffico in uscita (egress) che in entrata (ingress). La centralizzazione dei log e l’applicazione delle policy garantiscono visibilità e conformità, mantenendo privati gli endpoint PaaS.

← Azure DNS e risoluzione dei nomi · Tutti i domini · Bilanciamento del carico e gestione del traffico →

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