Perché la landing zone è il primo controllo di sicurezza

Quando progetti la security posture di un ambiente Azure enterprise, la tentazione è partire dai controlli di dettaglio (NSG, firewall, identità). Da architetto SC-100 devi invece partire dalla struttura: la landing zone definita dal Cloud Adoption Framework (CAF) è il contenitore che rende scalabili e ripetibili tutti i controlli successivi. La metodologia Secure del CAF fornisce la strategia (Zero Trust, difesa in profondità, resilienza), mentre il pilastro Security dell’Azure Well-Architected Framework ti dà i criteri di qualità con cui valutare ogni singolo workload. Le due viste sono complementari: CAF governa l’ambiente, Well-Architected governa il carico di lavoro.

Gerarchia dei management group come telaio del blast radius

La prima decisione di design è la gerarchia dei management group (MG). Sotto il Tenant Root Group si colloca un MG intermedio (tipicamente Platform + Landing Zones + Sandbox + Decommissioned), replicando l’archetipo Azure Landing Zone.

  • Platform raccoglie identità, connettività e management: qui applichi i controlli più rigidi.
  • Landing Zones si suddivide in Corp (workload interni) e Online (workload esposti), perché i requisiti di rete e di esposizione sono strutturalmente diversi.
  • Sandbox ha guardrail minimi per non frenare la sperimentazione, ma è isolata dalla connettività aziendale.

Il criterio di design è il blast radius: assegni le policy al livello di MG più alto possibile che condivide lo stesso requisito, così l’ereditarietà propaga il controllo a tutte le subscription figlie senza duplicazione. Non assegnare policy direttamente alle subscription se non per eccezioni giustificate: perdi la ripetibilità e crei configuration drift.

Azure Policy come guardrail: enforce vs audit

Azure Policy è lo strumento che trasforma la strategia in guardrail applicati automaticamente. La distinzione architetturale chiave è tra effetti:

  • Enforce (Deny, Modify, DeployIfNotExists): impedisce o corregge configurazioni non conformi. Usalo per controlli non negoziabili — es. negare IP pubblici su VM in Corp, forzare private endpoint, applicare tag di cost center, imporre l’uso di regioni approvate per data residency.
  • Audit (Audit, AuditIfNotExists): registra la non conformità senza bloccare. Usalo quando il controllo è desiderabile ma non ancora maturo, o durante la fase di rollout, per misurare l’impatto prima di irrigidire.

Il pattern raccomandato è audit-first, then enforce: distribuisci una nuova policy in Audit, misuri il tasso di non conformità sul compliance dashboard, comunichi ai team, poi promuovi a Deny. Questo evita di rompere workload esistenti e costruisce fiducia. Le Azure Policy initiative (set di definizioni) sono il veicolo giusto per allineare interi standard — es. l’initiative di Microsoft Defender for Cloud per la Microsoft Cloud Security Benchmark, o initiative regolatorie (ISO 27001, PCI-DSS) esposte in Purview/Defender for Cloud come baseline.

Dove la telemetria alimenta la governance

I guardrail non vivono isolati: Microsoft Defender for Cloud valuta la secure posture e il compliance rispetto agli standard, Microsoft Sentinel raccoglie e correla i segnali per detection e response, Microsoft Defender XDR unifica la protezione su identità, endpoint e cloud app, e Microsoft Purview governa la classificazione e la protezione del dato. In sede d’esame, sapere quale strumento risponde a quale requisito (posture vs SIEM/SOAR vs XDR vs data governance) è tanto importante quanto la gerarchia MG.

Il trade-off centrale: guardrail rigidi vs velocità dei team

Il cuore della progettazione è un bilanciamento. Guardrail troppo permissivi lasciano superficie d’attacco e configuration drift; guardrail troppo rigidi generano attrito e spingono i team verso lo shadow IT — sottoscrizioni personali, risorse fuori governance, aggiramenti che sono più rischiosi del controllo che volevi imporre.

La raccomandazione architetturale è differenziare i guardrail per zona: massima rigidità dove l’esposizione e la sensibilità del dato sono alte (Corp, Platform), massima autonomia dove il rischio è contenuto (Sandbox). Accompagna sempre l’enforcement con un processo di eccezione rapido e tracciabile (richiesta, approvazione, tag, scadenza): un guardrail senza via d’uscita legittima è un guardrail che verrà aggirato. Questo è coerente sia con la metodologia Secure del CAF (governance come enabler, non come freno) sia col pilastro Security del Well-Architected (sicurezza come proprietà del sistema, non layer bolt-on).

Trappole tipiche d’esame

  • Requisito: impedire risorse in regioni non conformi per data residency → soluzione: Azure Policy con effetto Deny su allowedLocations, assegnata al management group Landing Zones, non alle singole subscription (ereditarietà + ripetibilità).
  • Requisito: nuovo controllo di baseline che rischia di rompere workload esistenti → soluzione: distribuire la policy prima in Audit, misurare la compliance su Defender for Cloud, poi promuovere a Deny (audit-first).
  • Requisito: i team lamentano lentezza e creano risorse fuori governance (shadow IT) → soluzione: non irrigidire di più; introdurre un MG Sandbox con guardrail minimi e isolato + processo di eccezione tracciato, riducendo l’attrito senza perdere visibilità.
  • Requisito: garantire che ogni nuova risorsa abbia diagnostica verso il workspace centrale → soluzione: effetto DeployIfNotExists (remediation automatica), non Audit, perché il requisito richiede la configurazione effettiva, non solo la segnalazione.
  • Requisito: allineare l’ambiente a uno standard regolatorio (es. ISO 27001) → soluzione: assegnare l’initiative corrispondente e monitorare il regulatory compliance dashboard di Defender for Cloud, invece di creare policy singole scollegate.