La sicurezza di rete in Azure si costruisce a livelli: un firewall stateless e gratuito attaccato alle risorse (Network Security Group), un raggruppamento logico per ruolo applicativo (Application Security Group) e un firewall gestito centralizzato con ispezione fino a L7 (Azure Firewall). Sapere quale strumento scegliere in un dato scenario è il cuore di questa area d’esame.

Network Security Group (NSG)

Un NSG è un firewall distribuito stateful a livello L3/L4 che filtra il traffico IP in base a un insieme di regole. È gratuito e non introduce un hop dedicato: le regole vengono applicate direttamente sull’host della risorsa.

Regole e valutazione per priorità

Ogni regola si basa su una 5-tuple: source, source port, destination, destination port e protocol (TCP/UDP/ICMP/Any). Ogni regola ha una priorità da 100 a 4096: le regole si valutano in ordine di priorità crescente e la prima corrispondenza vince, interrompendo la valutazione delle successive.

Ogni NSG include default rules non eliminabili (priorità 65000+):

  • AllowVNetInBound / AllowVNetOutBound — traffico interno alla VNet e VNet peered
  • AllowAzureLoadBalancerInBound — probe dell’health monitor
  • DenyAllInBound / DenyAllOutBound — blocco finale a priorità più bassa

Poiché lo stato è mantenuto, se una regola inbound consente una connessione, il traffico di risposta è automaticamente permesso senza una regola outbound speculare.

Associazione: subnet vs NIC

Un NSG può essere associato a una subnet o direttamente alla NIC di una VM (o a entrambe). Best practice: applicare l’NSG a livello di subnet per governare interi tier (web, app, data) con un’unica policy, riservando l’NSG sulla NIC a eccezioni per singole VM.

Punto critico: quando entrambi esistono, si applicano tutti e due. Per il traffico inbound Azure valuta prima l’NSG di subnet poi quello della NIC; per l’outbound l’ordine è invertito. Un deny in uno qualsiasi dei due blocca il traffico: entrambi devono consentire il pacchetto perché passi.

Application Security Group (ASG)

Gli ASG permettono di raggruppare le NIC delle VM per ruolo applicativo (es. asg-web, asg-db) invece di ragionare su IP o subnet statiche. Nelle regole NSG si usa l’ASG come source o destination: aggiungendo una VM all’ASG eredita automaticamente le policy, senza toccare le regole. Ideale in ambienti dinamici dove gli indirizzi cambiano.

Azure Firewall

Quando servono controlli oltre L4, l’NSG non basta. Azure Firewall è un servizio PaaS gestito, stateful, altamente disponibile e scalabile, con IP pubblico statico.

Offre capacità che l’NSG non ha:

  • Application rules con FQDN filtering (es. consenti solo *.microsoft.com in uscita)
  • Network rules L3/L4 e NAT rules per DNAT del traffico inbound
  • Threat intelligence per allertare o negare traffico da IP/domini malevoli noti
  • FQDN tags e service tags per semplificare le policy
  • Logging centralizzato verso Azure Monitor / Log Analytics

Nella pratica architetturale, il Firewall si colloca in una subnet dedicata AzureFirewallSubnet (hub di una topologia hub-and-spoke) e si forza il traffico verso di esso con una User Defined Route (0.0.0.0/0 → IP privato del Firewall). NSG e Azure Firewall coesistono: microsegmentazione fine con NSG/ASG, egress e ispezione L7 centralizzati con il Firewall.

Azure Bastion

Per l’accesso amministrativo RDP/SSH senza esporre porte pubbliche, si usa Azure Bastion: un servizio PaaS in AzureBastionSubnet che fornisce connettività direttamente dal portale via TLS 443. Le VM non necessitano di IP pubblico né di regole inbound 3389/22 aperte da Internet, riducendo drasticamente la superficie d’attacco.

Trappole tipiche d’esame

  • Traffico bloccato con NSG su subnet E NIC → verifica entrambi: un deny in uno qualsiasi dei due vince, entrambi devono consentire il pacchetto.
  • Serve filtrare l’uscita per nome di dominio (FQDN) → NSG lavora solo su IP/porta (L3/L4); la risposta è Azure Firewall con application rules.
  • Due regole NSG in conflitto → vince quella con priorità numerica più bassa (valutazione crescente, prima corrispondenza applicata).
  • Accesso RDP/SSH sicuro senza IP pubblico → Azure Bastion, non aprire la porta 3389/22 in una regola NSG.
  • Raggruppare VM per ruolo evitando di gestire IP nelle regole → Application Security Group, non subnet o IP statici.
  • Health probe del load balancer non funziona → non rimuovere la default rule AllowAzureLoadBalancerInBound o non sovrascriverla con un deny a priorità più alta.