La network security in un modello zero-trust-network non si limita a “mettere un firewall al perimetro”: richiede un design a strati che assuma la compromissione (assume breach) e limiti il movimento laterale. L’esame SC-100 valuta la capacità di raccomandare la topologia giusta dato un requisito, non di configurare regole.
Segmentazione: hub-spoke come fondamento
La topologia hub-spoke resta il pattern di riferimento per centralizzare i controlli. L’hub ospita i servizi condivisi e ispettivi (Azure Firewall, gateway VPN/ExpressRoute, Bastion), mentre ogni spoke isola un workload o un ambiente (prod, dev, PCI). Il traffico spoke-to-spoke è forzato attraverso l’hub via User-Defined Route (UDR con next-hop l’IP privato del firewall), rendendo ispezionabile ogni flusso est-ovest.
Per topologie multi-region o multi-hub si valuta Azure Virtual WAN, che gestisce il routing transitivo in modo nativo (routing intent) senza UDR manuali. La scelta è un trade-off: hub-spoke classico = massimo controllo e costo prevedibile; Virtual WAN = scalabilità e minor overhead operativo su decine di rami.
La segmentazione non finisce alla VNet. Dentro lo spoke si applica la micro-segmentazione con Network Security Group e Application Security Group, raggruppando i workload per ruolo (web, app, data) invece che per subnet/IP. Questo allinea le regole all’identità del carico e sopravvive ai cambi di indirizzamento.
Azure Firewall Premium: quando e perché
Azure Firewall Premium aggiunge tre capacità decisive per zero-trust:
- IDPS (signature-based, circa 67k firme) per detection/prevention su traffico noto-malevolo.
- TLS inspection: decripta il traffico in uscita (e con Application Gateway davanti, anche in ingresso) per ispezionare payload cifrato — indispensabile perché >90% del traffico è HTTPS e senza decrittazione l’IDPS è cieco.
- URL filtering e web categories granulari.
Il trade-off chiave d’esame è Azure Firewall Premium vs NVA di terze parti (Palo Alto, Fortinet, Check Point):
| Criterio | Azure Firewall Premium | NVA di terze parti |
|---|---|---|
| Gestione | PaaS, scaling e HA automatici | IaaS, patching e HA a carico tuo |
| Ispezione | IDPS + TLS inspection, integrato Azure Policy/Firewall Manager | Feature avanzate (sandboxing, DLP, threat intel proprietaria) |
| Costo | Orario + per-GB, prevedibile | Licenza + compute VMSS + operations |
| Skill | Nativa Azure | Riusa competenze e policy on-prem esistenti |
Raccomandazione tipo: se il requisito è “capacità cloud-native con minimo overhead operativo e IDPS/TLS”, scegli Azure Firewall Premium. Se il requisito impone parità di policy con l’on-prem o feature non presenti in Azure (es. sandboxing avanzato), l’NVA giustifica il costo maggiore. Difficilmente serve entrambi in serie.
Private Endpoint: eliminare il public endpoint PaaS
Il pilastro Security del Azure Well-Architected Framework impone di ridurre la superficie esposta. I servizi PaaS (Storage, SQL, Key Vault) nascono con endpoint pubblico: la risposta zero-trust è Private Endpoint (Private Link), che proietta il servizio con un IP privato dentro la VNet, risolto via Private DNS Zone. Il traffico non tocca mai Internet e puoi disabilitare del tutto l’accesso pubblico (Public network access = Disabled).
Distinguere da Service Endpoint: quest’ultimo ottimizza il routing ma il servizio mantiene IP pubblico e non copre l’accesso da on-prem. Quando il requisito parla di “accesso solo privato” o “da rete ibrida”, la risposta è Private Endpoint, mai Service Endpoint.
Azure Policy: enforcement, non speranza
Un design zero-trust senza enforcement degrada. Azure Policy codifica i pattern: nega la creazione di risorse con IP pubblico, obbliga il Private Endpoint su Storage/SQL, forza l’associazione NSG alle subnet, richiede TLS 1.2+. Effetti Deny (blocca) e DeployIfNotExists (rimedia) trasformano l’architettura in un guardrail governato, allineandosi al pilastro Operational Excellence del Well-Architected.
Trappole tipiche d’esame
- Requisito: SQL/Storage accessibile solo dalla rete privata e da on-prem → Private Endpoint, non Service Endpoint. Il Service Endpoint lascia l’IP pubblico e non funziona via ExpressRoute/VPN. Trappola classica: opzione “Service Endpoint” che sembra sufficiente ma non lo è.
- Requisito: ispezionare traffico HTTPS in uscita per malware/exfiltration → Azure Firewall Premium con TLS inspection + IDPS. Il firewall Standard o un NSG non decrittano nulla.
- Requisito: bloccare a livello organizzativo la creazione di risorse con endpoint pubblico → Azure Policy con effetto Deny, non revisione manuale né semplice raccomandazione in Defender for Cloud.
- Requisito: parità di policy con firewall on-prem esistente e feature proprietarie → NVA di terze parti in hub-spoke, accettando il maggior costo operativo; non forzare Azure Firewall se manca la feature richiesta.
- Requisito: routing transitivo spoke-to-spoke su molte region → Virtual WAN (routing intent) o UDR verso l’hub firewall. Errore comune: assumere che il peering VNet sia transitivo — non lo è.