Con i soli NSG l’imposizione su scala è un compromesso: o li gestisce il team centrale e l’onere esplode, o li gestiscono i team applicativi e nessuno garantisce che la 3389 sia chiusa ovunque. Nemmeno crearli con Azure Policy risolve, perché chi possiede il NSG può modificarlo. Virtual Network Manager e Virtual WAN attaccano il problema da due lati: il primo impone regole che i team non possono togliere, il secondo concentra l’ispezione in un punto solo.

Network group: chi riceve la regola

Un’istanza di network manager ha uno scope — un management group o una sottoscrizione — e agisce solo sulle reti virtuali che ci stanno dentro. Il destinatario delle configurazioni è il network group, contenitore globale di reti virtuali di qualunque regione. Una rete può stare in più gruppi.

L’appartenenza è statica (le scegli a mano, adatta a pochi elementi stabili) oppure dinamica: la valuta Azure Policy in base a condizioni che scrivi tu, tipicamente un tag o una convenzione di nome. La dinamica richiede permessi di lettura e scrittura sulla policy sottostante, oltre al permesso RBAC di aggiungere al gruppo.

Security admin rule: tre azioni, non due

Le security admin rule stanno in una security admin configuration, organizzate in rule collection, e ogni collection punta a uno o più network group. La priorità va da 1 a 4096, numero più basso valutato prima. Protocolli: TCP, UDP, ICMP, ESP, AH o qualsiasi. Origine e destinazione possono essere indirizzi, blocchi CIDR o service tag — con l’esclusione di AzurePlatformDNS, AzurePlatformIMDS e AzurePlatformLKM.

Il punto che distingue queste regole dai NSG sono le tre azioni, non due, e vanno lette in relazione alla valutazione dei NSG, che avviene sempre dopo:

  • Allow: consente, poi il traffico passa comunque alla valutazione dei NSG, che possono ancora negarlo;
  • Always allow: termina la valutazione e consegna il traffico alla risorsa, scavalcando i NSG;
  • Deny: termina la valutazione, il traffico non viene consegnato.

«Allow» è un permesso revocabile a valle, «Always allow» è una garanzia. Il pattern delle eccezioni: deny SSH in entrata a priorità 100 sul gruppo con tutte le reti, allow SSH a priorità 10 sul gruppo che fa eccezione.

Due vincoli operativi: per regione puoi distribuire una sola security admin configuration — se ti servono più insiemi di regole, crei più rule collection dentro la stessa configurazione — e il modello è a consistenza finale: le VM aggiunte dopo a una rete virtuale coperta ricevono le regole con un ritardo.

Dove le regole non arrivano

È la parte che nessuno legge e che spiega gli incidenti. Alcuni servizi hanno requisiti di rete imposti da una network intent policy e le admin rule non si applicano.

A livello di rete virtuale, una VNet che contiene Azure SQL Managed Instance o Azure Databricks viene saltata del tutto. Se vuoi che almeno le regole Allow ci arrivino, la configurazione va creata con il campo AllowRulesOnly: le Deny restano comunque escluse. Quando due network manager applicano impostazioni diverse alla stessa rete, vince quello con lo scope più alto.

A livello di subnet, le regole non toccano le subnet che ospitano Application Gateway, Azure Bastion, Azure Firewall, Route Server, VPN Gateway, Virtual WAN ed ExpressRoute Gateway — le altre subnet della stessa rete restano coperte. Per Application Gateway c’è un’eccezione all’eccezione: le regole si applicano solo se il gateway è provisionato con network isolation. Infine, i private endpoint dentro una rete gestita al momento non ricevono admin rule.

Prima di dichiarare chiusa una porta ovunque, verificala con effective security rules su una NIC reale.

Virtual WAN: l’hub protetto è metà del lavoro

Un secured virtual hub è un hub Virtual WAN con policy di sicurezza e di routing configurate da Azure Firewall Manager; il provider può essere Azure Firewall, un SECaaS di terze parti, o entrambi. Il vantaggio è il routing automatico: non scrivi UDR. Puoi convertire un hub esistente dal portale Virtual WAN, sezione Security. Attenzione: quel percorso di conversione non consente le zone di disponibilità per Azure Firewall — per averle si passa dal flusso di Firewall Manager.

Distribuire il firewall nell’hub però non protegge il traffico tra hub e tra branch: per quello serve il routing intent, anche con un hub solo.

Routing intent: due policy e quattro trappole

Ogni hub ammette al massimo una Internet Traffic Routing Policy e una Private Traffic Routing Policy, ciascuna con un solo next hop (Azure Firewall, NVA next-generation firewall o soluzione SaaS). La prima fa annunciare 0.0.0.0/0 a spoke, gateway e NVA; la seconda manda al next hop tutto il traffico branch-to-branch, branch-to-VNet, VNet-to-branch e inter-hub.

Le trappole:

  1. La rotta di default non si propaga fra hub. Uno spoke su un hub senza policy Internet non esce attraverso il firewall di un altro hub: ogni hub ha bisogno della propria.
  2. Prerequisiti stretti. Niente route table personalizzate (solo defaultRouteTable e noneRouteTable) e nessuna rotta statica con next hop una Virtual Network Connection, altrimenti l’opzione resta disabilitata.
  3. Le modifiche alla defaultRouteTable sono irreversibili. Vengono create _policy_PrivateTraffic (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) e _policy_PublicTraffic (0.0.0.0/0), e le altre rotte statiche vengono consolidate o rimosse. Salva prima uno snapshot di gateway, connessioni e route table: rimuovere il routing intent non ripristina niente.
  4. I prefissi privati non RFC1918 vanno dichiarati a mano in Private Traffic Prefixes, su tutti gli hub con policy privata — comprese le subnet delegate dei servizi bare-metal. Non dichiarati, quel traffico non viene ispezionato; dichiarati, valuta di disabilitare il SNAT del firewall su quegli intervalli.