Governance as code con Azure Policy

Azure Policy è lo strumento di enforcement dichiarativo su cui si fonda una landing zone conforme: valuta le risorse rispetto a regole e applica un effetto in fase di creazione, aggiornamento o valutazione periodica. Come architetto, la domanda chiave non è “quale policy scrivo”, ma “quale effetto serve dato il requisito di rischio e la maturità operativa del cliente”.

Scegliere l’effetto giusto

  • Audit: registra la non conformità senza bloccare. È la scelta corretta quando devi misurare la deriva su un estate esistente prima di irrigidire i controlli, o quando il blocco romperebbe workload legacy. Nessuna remediation, solo visibilità.
  • Deny: impedisce il deployment non conforme. Raccomandalo per controlli hard, non negoziabili (es. “nessuna risorsa fuori da West Europe”, “no IP pubblico su NIC”). Attenzione: agisce solo su create/update, non tocca le risorse già esistenti.
  • DeployIfNotExists (DINE): valuta una risorsa correlata e, se assente, ne effettua il deployment tramite un template ARM. È il meccanismo per la remediation automatica — abilitare diagnostic settings verso un Log Analytics workspace, installare l’agente Azure Monitor, forzare Microsoft Defender for Cloud. Richiede una managed identity con i ruoli RBAC adeguati sullo scope.
  • Modify: aggiunge/rimuove tag o proprietà (es. TLS minimo) senza redeploy completo; più leggero di DINE quando basta patchare un attributo.

Trade-off tipico: per un requisito “tutti gli storage account devono avere i log diagnostici”, Deny fallirebbe (non crea nulla), mentre DINE è la risposta corretta perché provisiona la configurazione mancante.

Initiative, scope e remediation

Non deployare policy sparse: aggregale in initiative (policy set) per esporre un unico stato di compliance mappato a standard come ISO 27001, PCI-DSS o CIS. Assegna l’initiative al livello più alto possibile — management group — così l’eredità copre le subscription nuove automaticamente; usa exemption puntuali invece di riscrivere gli scope.

Il punto d’esame ricorrente: DINE e Modify non agiscono retroattivamente. Su risorse preesistenti generano solo uno stato non-compliant; per correggerle servono i remediation task, che eseguono l’effetto sulle risorse già presenti tramite la managed identity dell’assignment. Ricorda inoltre che le nuove policy impiegano fino a circa 30 minuti per la valutazione e che il compliance state non è istantaneo.

Compliance mapping con Microsoft Purview

Azure Policy risponde alla domanda “la mia infrastruttura rispetta i controlli tecnici?”. Microsoft Purview copre il piano dei dati: classificazione, sensitivity label, data map e catalogo. In un design end-to-end mappi i requisiti normativi su due assi complementari — Purview per dove risiedono e come sono classificati i dati sensibili, Azure Policy + Microsoft Defender for Cloud (regulatory compliance dashboard) per la postura delle risorse. Confondere i due layer è un errore d’esame frequente.

Strategia di encryption e key management

L’encryption at rest è sempre attiva in Azure con platform-managed key (PMK): Microsoft gestisce rotazione e ciclo di vita, zero overhead. La scelta architetturale è quando salire a customer-managed key (CMK).

PMK vs CMK vs HSM

  • PMK: default. Raccomandalo salvo requisito esplicito di controllo sulle chiavi. Semplice, resiliente, nessun rischio di lockout.
  • CMK in Azure Key Vault: la chiave vive nel Key Vault del cliente, che controlla rotazione, revoca e audit. Necessario quando la compliance impone separation of duties o crittografia con chiave propria. Costo: complessità operativa e rischio di indisponibilità se la chiave viene revocata o eliminata.
  • CMK con HSM-backed key: obbligatorio per requisiti HSM-backed, ma attenzione al livello FIPS richiesto. Key Vault Premium usa HSM multi-tenant validati FIPS 140-2 Level 2; Managed HSM offre HSM single-tenant validati FIPS 140-2 Level 3, con controllo esclusivo (anche verso Microsoft) e BYOK. Un requisito esplicito di Level 3 impone Managed HSM, non Key Vault Premium.

Design essenziale per CMK: abilita soft-delete e purge protection sul Key Vault (previene la perdita permanente della chiave → dati irrecuperabili), configura l’auto-rotation delle chiavi e usa una user-assigned managed identity per l’accesso, così la rotazione dell’identità della risorsa non spezza il wrapping. Per SQL/Storage il pattern è Infrastructure Encryption (doppio layer) quando serve difesa in profondità.

Trappole tipiche d’esame

  • Requisito: “loggare risorse non conformi ma non bloccare i team durante il rollout” → effetto Audit (non Deny): visibilità senza attrito.
  • Requisito: “abilitare automaticamente i diagnostic settings mancanti” → DeployIfNotExists + remediation task per le risorse esistenti, con managed identity a cui assegni il ruolo RBAC minimo.
  • Requisito: “impedire la creazione di VM con IP pubblico” → Deny a livello di management group; ricorda che non rimuove gli IP già esistenti (serve un report/remediation separato).
  • Requisito: “il cliente deve poter revocare le chiavi e provare la separation of duties” → CMK in Key Vault (Managed HSM se serve FIPS 140-2 L3), con soft-delete + purge protection per evitare lockout.
  • Requisito: “due initiative in conflitto, una Audit e una Deny sullo stesso controllo” → prevale sempre il più restrittivo: Deny vince su Audit; verifica gli scope e usa exemption anziché disabilitare l’assignment.