Azure Firewall: cos’è e quando sceglierlo

Azure Firewall è un firewall-as-a-service gestito, stateful e cloud-native, con high availability integrata e autoscaling automatico. Non richiede patching né provisioning di appliance: Azure gestisce il piano dati. Esiste in tre SKU con capacità crescenti. Basic copre scenari SMB a basso throughput e offre threat intelligence solo in modalità alert. Standard aggiunge filtering L3-L7, application rule con FQDN, network rule e threat intel in deny. Premium introduce TLS inspection, IDPS signature-based, URL filtering granulare e web categories.

Il trade-off ricorrente all’esame è Azure Firewall vs Network Security Group. Un NSG è stateful ma opera a livello L3/L4 su subnet o NIC, senza filtering per FQDN, logging centralizzato o threat intelligence. Azure Firewall è la scelta quando serve controllo centralizzato del traffico per l’intera hub-and-spoke o per il perimetro Internet: i due strumenti sono complementari, non alternativi.

Firewall policy e organizzazione delle regole

La firewall policy è la risorsa Azure Resource Manager che contiene le regole ed è riutilizzabile su più firewall, anche in region diverse. Supporta una gerarchia parent/child: una policy figlia eredita dalla policy padre e non può sovrascriverne le regole, permettendo a un team centrale di imporre baseline di sicurezza mentre i team locali aggiungono regole specifiche. Le regole sono raggruppate in Rule Collection Group, che contengono Rule Collection di tre tipi: DNAT, Network e Application.

L’ordine di elaborazione è deterministico e va memorizzato: DNAT → Network → Application, e la threat intelligence viene valutata prima di tutte le regole. All’interno dello stesso tipo, conta la priorità numerica. Le classic rules (senza policy) restano supportate ma la firewall policy è raccomandata ed è obbligatoria per le funzionalità Premium.

DNAT, TLS inspection e threat intelligence

Il DNAT traduce l’indirizzo IP pubblico e la porta del firewall verso un IP privato e porta interni, abilitando l’accesso inbound a servizi backend (per esempio RDP/SSH o un web server) senza esporli direttamente. Azure crea implicitamente la network rule per il traffico di ritorno.

La TLS inspection è disponibile solo in Premium: il firewall decripta il traffico TLS in uscita, lo ispeziona applicando IDPS e URL filtering completo, poi lo ricripta. Richiede un intermediate CA certificate archiviato in Azure Key Vault e una user-assigned managed identity per accedervi. Senza decrittazione, sul traffico HTTPS puoi filtrare solo per FQDN via SNI, non per URL completo.

La threat intelligence si basa sul feed Microsoft Threat Intelligence e blocca traffico da/verso IP e domini malevoli noti. Ha tre modalità: Off, Alert only e Alert and deny. È la prima linea di difesa, valutata prima di ogni rule collection.

Secured virtual hub e routing intent

In un’architettura Azure Virtual WAN, il secured virtual hub è un hub in cui è stato distribuito Azure Firewall (o una security appliance di terze parti) tramite Azure Firewall Manager. Serve a ispezionare centralmente il traffico che attraversa la topologia globale.

Il routing intent è il meccanismo che dirotta automaticamente il traffico attraverso il firewall dell’hub, sostituendo le route table statiche gestite a mano. Si configura per due categorie: Internet traffic (traffico verso Internet, 0.0.0.0/0) e Private traffic (spazi RFC 1918 più i prefissi di branch e VNet). Con il routing intent attivo, il traffico spoke-to-spoke, spoke-to-Internet e branch-to-spoke viene forzato nel firewall senza User Defined Route manuali sugli spoke. Firewall Manager consente inoltre di applicare la stessa firewall policy a più hub e firewall in modo coerente.

Trappole tipiche d’esame

  • Serve URL filtering completo e IDPS su traffico HTTPS → Azure Firewall Premium con TLS inspection: Standard filtra HTTPS solo per FQDN via SNI; l’ispezione dell’URL completo richiede la decrittazione, disponibile solo in Premium.
  • TLS inspection non funziona / errore certificato → intermediate CA in Key Vault + user-assigned managed identity: senza CA intermedia e identity per leggerla, il firewall non può firmare i certificati e la decrittazione fallisce.
  • Pubblicare un servizio interno su IP pubblico → DNAT rule collection, non Application rule: le application rule filtrano traffico in uscita per FQDN; l’inbound con traduzione di indirizzo è compito del DNAT.
  • Forzare il traffico spoke-to-spoke nel firewall in Virtual WAN → routing intent per Private traffic, non UDR manuali: in secured hub il routing intent gestisce la propagazione; le UDR statiche sono l’approccio legacy e fragile.
  • Bloccare comunicazioni verso IP/domini malevoli noti senza scrivere regole → threat intelligence in modalità Alert and deny: è pensata esattamente per questo e viene valutata prima di ogni altra regola.
  • Regola configurata ma il traffico passa comunque → verifica l’ordine DNAT → Network → Application e la threat intel: una application rule non blocca ciò che una network rule più prioritaria ha già consentito.