La superficie applicativa è oggi il vettore d’attacco dominante: API esposte, secret dimenticati nel codice e pipeline non presidiate. Come architetti dobbiamo progettare una difesa a strati allineata ai pilastri Security e Operational Excellence dell’Azure Well-Architected Framework, spostando i controlli il più possibile a sinistra (shift-left) senza sacrificare le prestazioni.

Il perimetro applicativo: dove posizionare il WAF

Il Web Application Firewall (WAF) è la prima linea contro OWASP Top 10, bot e attacchi L7. La scelta di posizionamento è un trade-off architetturale:

  • WAF su Azure Front Door: WAF globale all’edge, ideale per applicazioni multi-region o esposte pubblicamente su Internet. Blocca il traffico malevolo prima che raggiunga la region, riducendo latenza e costi di egress. Raccomandato quando serve CDN, anycast e protezione DDoS integrata.
  • WAF su Application Gettway: WAF regionale, opportuno quando il traffico è già interno alla VNet o quando servono routing L7 fine e terminazione TLS vicino al backend.

Pattern raccomandato: Front Door (WAF edge) → Application Gateway (WAF regionale) solo se il requisito impone doppia ispezione o segmentazione; nella maggior parte dei casi un singolo layer basta ed evita costi e complessità.

Managed rule set vs regole custom: il trade-off

Il Microsoft-managed rule set (basato su OWASP CRS + Microsoft Threat Intelligence) offre copertura ampia e aggiornata automaticamente, ma può generare falsi positivi su applicazioni legittime con payload complessi (es. JSON grandi, editor rich-text). Le regole custom consentono di risolvere casi specifici — rate limiting, geo-filtering, allow/deny per pattern — ma vanno mantenute e testate.

Linea guida d’esame:

  • Prima attivare il rule set gestito in modalità Detection, analizzare i log in Microsoft Sentinel, poi passare a Prevention.
  • Risolvere i falsi positivi con exclusions mirate o regole custom, non disabilitando intere regole gestite (riduce la copertura).
  • Ogni regola custom aggiunge overhead di valutazione: troppe regole degradano il throughput. Preferire pochi controlli custom ad alto valore.

Eliminare i secret: managed identity

Il vero salto di postura è rimuovere del tutto i secret dal codice e dalla configurazione. Con le managed identity di Microsoft Entra ID, la risorsa Azure (App Service, Function, Container App, VM) ottiene un’identità gestita e richiede token OAuth 2.0 direttamente all’IMDS, senza credenziali persistite.

Decisione tra le due varianti:

  • System-assigned: ciclo di vita legato alla risorsa. Ideale per workload 1:1, isolamento massimo.
  • User-assigned: identità condivisibile fra più risorse. Preferibile per fleet omogenee o per pre-provisioning delle RBAC prima del deploy (evita la corsa creazione-risorsa/assegnazione-ruolo).

Per i secret che restano inevitabili (chiavi di terze parti), l’accesso avviene via managed identity verso Azure Key Vault, mai in appsettings o variabili d’ambiente in chiaro.

Shift-left: DevOps security in Defender for Cloud

La sicurezza applicativa inizia nella pipeline. La DevOps security in Microsoft Defender for Cloud (già “Defender for DevOps”) connette GitHub e Azure DevOps e porta a sinistra:

  • Secret scanning su repo e pipeline (intercetta chiavi hardcoded prima del merge).
  • IaC scanning (Bicep/Terraform) per misconfigurazioni di sicurezza.
  • Dependency/CodeQL per vulnerabilità del codice.
  • Findings consolidati nel Defender for Cloud Secure Score e correlati in Microsoft Defender XDR / Sentinel.

Threat modeling delle API esposte

Ogni endpoint pubblico va modellato (STRIDE): autenticazione mancante, BOLA/broken object level authorization, mass assignment, rate abuse. Fronteggiarli con Azure API Management (validazione JWT Entra ID, throttling, schema validation), classificazione dei dati sensibili trasportati tramite Microsoft Purview, e audit trail verso Sentinel.

Trappole tipiche d’esame

  • Requisito: app globale con molti falsi positivi del WAF, serve blocco ma senza rompere il legittimo → attivare il managed rule set su Front Door in Detection, analizzare i log in Sentinel, poi Prevention con exclusions mirate; non disabilitare le regole core.
  • Requisito: eliminare le connection string dal codice di una Function che accede a SQL/Key Vault → managed identity + RBAC/Key Vault access policy, mai secret in configurazione; scegliere user-assigned se l’identità serve a più risorse o va pre-autorizzata.
  • Requisito: managed identity con Contributor su tutta la subscription → è un over-privilege: assegnare ruoli least-privilege allo scope minimo (es. Key Vault Secrets User sul singolo vault), non ruoli ampi.
  • Requisito: impedire che chiavi API finiscano nei repository → abilitare secret scanning della DevOps security in Defender for Cloud (shift-left), non affidarsi a review manuali.
  • Requisito: proteggere API REST pubbliche da abusi e accessi non autorizzati → API Management con validazione JWT Entra ID + rate limiting davanti al backend, e WAF a monte; il threat modeling deve coprire BOLA e authorization a livello di oggetto.