Un NSG è un filtro stateful a cinque tuple che si aggancia a una subnet o a una NIC. Non ispeziona il contenuto, non fa NAT, non registra nulla di suo: consente o nega, e basta. Il problema non è capire le regole che scrivi tu, sono quelle che ci sono già.

Come viene valutata davvero una regola

Ogni regola ha una priorità fra 100 e 4096: numero più basso, valutato prima, e alla prima corrispondenza la valutazione si ferma. Non puoi avere due regole con la stessa priorità nella stessa direzione. La corrispondenza avviene su origine, porta di origine, destinazione, porta di destinazione e protocollo.

Il NSG è stateful: viene creato un flow record, quindi il traffico di ritorno passa senza una regola simmetrica. Se consenti in uscita verso la porta 443, non devi consentire nulla in entrata per le risposte.

Il dettaglio che salta fuori durante un incidente: rimuovere una regola non chiude le connessioni già aperte. Le regole nuove o modificate valgono solo per le connessioni nuove. Se togli la regola che permetteva SSH mentre qualcuno è dentro, quella sessione resta viva.

Ultimo punto sugli indirizzi: il NSG lavora su IP privati. In entrata è valutato dopo la traduzione dell’indirizzo pubblico in privato, in uscita prima. Una regola che indica l’IP pubblico della VM come destinazione non corrisponderà mai.

Le regole di default decidono al posto tuo

Ogni NSG nasce con sei regole che non puoi cancellare, solo scavalcare con priorità più alta:

IN   65000  AllowVNetInBound              VirtualNetwork -> VirtualNetwork   Allow
IN   65001  AllowAzureLoadBalancerInBound AzureLoadBalancer -> 0.0.0.0/0     Allow
IN   65500  DenyAllInBound                0.0.0.0/0 -> 0.0.0.0/0             Deny
OUT  65000  AllowVnetOutBound             VirtualNetwork -> VirtualNetwork   Allow
OUT  65001  AllowInternetOutBound         0.0.0.0/0 -> Internet              Allow
OUT  65500  DenyAllOutBound               0.0.0.0/0 -> 0.0.0.0/0             Deny

Leggile come una dichiarazione di intenti della piattaforma: da Internet in entrata è chiuso, dentro la rete virtuale è tutto aperto, verso Internet in uscita è tutto aperto. Un NSG applicato «così com’è» non è segmentazione e non è controllo dell’egress: AllowVNetInBound consente tutta la comunicazione fra risorse della stessa rete virtuale, quindi due workload che non devono parlarsi si parlano finché non scrivi un deny esplicito.

Non tutto passa dal NSG. Gli indirizzi di piattaforma 168.63.129.16 e 169.254.169.254 (DHCP, DNS, IMDS, health probe) non sono soggetti alle tue regole a meno che tu non li colpisca con i service tag AzurePlatformDNS, AzurePlatformIMDS, AzurePlatformLKM. E una VM senza alcun NSG, né su subnet né su NIC, resta comunque irraggiungibile da Internet, ma esce liberamente.

Subnet e NIC insieme: l’ordine cambia il risultato

Quando i NSG sono due, l’ordine non è simmetrico:

  • in entrata: prima il NSG della subnet, poi quello della NIC. Devono entrambi consentire;
  • in uscita: prima il NSG della NIC, poi quello della subnet. Uno solo che neghi è sufficiente.

Lo stesso ordine vale per il traffico interno alla subnet. Il consiglio di Microsoft è di non associare NSG a subnet e NIC contemporaneamente: le regole entrano in conflitto e i problemi che ne nascono sono i più difficili da diagnosticare.

ASG: smettere di scrivere indirizzi IP

Un application security group è un’etichetta che metti sulla configurazione IP di una NIC e che puoi usare come origine o destinazione di una regola, al posto di un indirizzo. Una NIC può appartenere a più ASG. I vincoli sono due, e sono duri: tutte le NIC di un ASG devono stare nella stessa rete virtuale (quella della prima NIC aggiunta), e se usi un ASG sia come origine sia come destinazione, entrambi devono vivere nella stessa rete virtuale.

Il pattern canonico, con un solo NSG sulle subnet:

100  Internet -> AsgWeb    TCP 80    Allow
110  AsgLogic -> AsgDb     TCP 1433  Allow
120  *        -> AsgDb     Any 1433  Deny

La regola 120 serve proprio perché AllowVNetInBound lascerebbe passare tutto est-ovest; la 110 la precede e ritaglia l’unica eccezione. Una NIC che non è membro dell’ASG non viene toccata da queste regole, anche se il NSG è sulla sua subnet.

Le augmented rule ti lasciano mettere più indirizzi, più intervalli e più porte nello stesso campo, ma non più service tag né più ASG nello stesso campo: uno per regola.

Quando non torna: chi ha bloccato il pacchetto

Tre strumenti, e servono a cose diverse.

Effective security rules mostra l’aggregato applicato a una NIC: regole del NSG della NIC, del NSG della subnet e le admin rule di Azure Virtual Network Manager. È l’unico posto in cui vedi una regola che non hai scritto tu e che nessun NSG spiega. Si esporta in CSV, il che lo rende utile come audit periodico contro un set di regole prescritte.

NSG diagnostics simula un flusso: gli dai origine e destinazione e ti dice se passa e quale regola decide. Funziona su macchine virtuali, NIC, NIC di scale set e Application Gateway v2 (esclusi i deployment privati). IP flow verify fa la stessa verifica per singola NIC.

Nota di pianificazione: i NSG flow log vanno in pensione il 30 settembre 2027 e non se ne possono più creare di nuovi. La telemetria di flusso si fa con i virtual network flow log.