Progettare il perimetro: protezione di rete e delivery globale

In AZ-305 non ti viene chiesto di configurare un firewall, ma di scegliere il componente giusto dato un requisito e di giustificare il trade-off in termini di sicurezza, affidabilità e costo (i pilastri dell’Azure Well-Architected Framework). La sfida ricorrente è distinguere ciò che ispeziona il traffico L3/L4 da ciò che ispeziona il traffico applicativo L7, ed evitare di esporre servizi PaaS su internet quando esiste un’alternativa privata.

Protezione perimetrale: Azure Firewall vs NVA

Azure Firewall è un servizio managed, stateful, con alta disponibilità e scalabilità automatica integrate. Governa il traffico network e application layer (regole di rete, application rule con FQDN filtering, threat intelligence). Lo raccomandi quando il requisito è ridurre l’overhead operativo e centralizzare il controllo egress in un modello hub-spoke, tipicamente con lo SKU Premium quando servono TLS inspection, IDPS e URL filtering.

Una Network Virtual Appliance (NVA) di terze parti (Palo Alto, Fortinet, Check Point) è la scelta obbligata quando il cliente ha requisiti di feature specifiche non coperte da Azure Firewall o vuole coerenza con un firewall già in uso on-premises. Il prezzo è maggiore complessità: gestisci tu patching, HA (load balancer + set di appliance) e scaling. Regola pratica d’esame: “minimizzare la gestione” → Azure Firewall; “parità con vendor esistente / feature avanzate proprietarie” → NVA.

Web Application Firewall (WAF)

Il WAF protegge dalle minacce applicative (OWASP Top 10: SQL injection, XSS) e vive su due prodotti: Azure Front Door (protezione al bordo globale, vicino all’utente) o Application Gateway (protezione regionale). Non confondere il WAF con Azure Firewall: il primo ispeziona payload HTTP/S in ingresso verso le web app, il secondo governa il traffico di rete generale. Per un’app esposta globalmente, il WAF su Front Door blocca gli attacchi prima che entrino in Azure.

Application delivery: la scelta del load balancer

Questa è la decisione più testata. Il criterio è scope geografico + livello OSI:

  • Azure Front Door — L7 globale, anycast + CDN, SSL offload, path-based routing e failover inter-regione. Scegli quando servi utenti worldwide e vuoi latenza bassa + WAF al bordo.
  • Application Gateway — L7 regionale, con WAF, cookie-based session affinity e routing verso backend dentro una regione. Scegli per il bilanciamento HTTP/S all’interno di una singola regione.
  • Traffic Manager — bilanciamento a livello DNS (non è nel data path). Instrada per performance, priority, weighted o geographic. Scegli quando devi distribuire traffico non-HTTP o combinare endpoint cross-region/ibridi a livello di risoluzione nomi.

Pattern architetturale robusto e multi-regione: Front Door (globale) → Application Gateway (regionale con WAF) → backend. Traffic Manager sopravvive quando serve failover DNS per protocolli non-web. Non esiste un “unico vincitore”: la risposta corretta dipende da globale vs regionale e L7 vs DNS.

Accesso privato ai PaaS: Private Endpoint

Un requisito classico è: “il database/storage non deve essere raggiungibile da internet pubblico”. La soluzione raccomandata è il Private Endpoint, che proietta il servizio PaaS (SQL Database, Storage, Key Vault) su un IP privato della tua VNet tramite Azure Private Link, disabilitando l’esposizione pubblica. Va abbinato a una Private DNS Zone per risolvere l’FQDN verso l’IP privato. L’alternativa più debole — Service Endpoint — mantiene il traffico sulla backbone Azure ma non dà un IP privato né estende l’accesso a on-premises: per requisiti di isolamento stringenti e connettività ibrida, preferisci sempre Private Endpoint.

Gestione dei certificati con Key Vault

Certificati TLS, chiavi e segreti vanno centralizzati in Azure Key Vault, con rotazione automatica e integrazione nativa: Application Gateway e Front Door referenziano il certificato direttamente dal vault tramite managed identity, evitando segreti hard-coded. Design corretto: accesso al vault via Azure RBAC + Private Endpoint sul vault stesso, così la superficie di attacco resta interna.

Trappole tipiche d’esame

  • Servizio PaaS “non esposto a internet” + accesso da on-premises → Private Endpoint + Private DNS Zone (Service Endpoint non basta: niente IP privato né estensione ibrida).
  • App globale con utenti in più continenti + WAF → Front Door con WAF al bordo; Application Gateway da solo è regionale e non copre il routing globale.
  • Filtrare il traffico egress verso FQDN specifici con minimo overhead → Azure Firewall (application rule); scegliere una NVA solo se servono feature vendor proprietarie.
  • Bilanciare traffico non-HTTP tra regioni / failover a livello nome → Traffic Manager (DNS), non Front Door né Application Gateway (entrambi L7 HTTP/S).
  • Certificati TLS per il gateway senza segreti nel codice → Key Vault + managed identity, non certificati caricati manualmente sul singolo servizio.