Perché Azure Policy

Azure Policy applica regole di governance alle risorse per garantire che rispettino standard aziendali e requisiti di conformità. La differenza chiave rispetto ad Azure RBAC è netta: RBAC decide chi può eseguire un’azione (permessi sull’identità), mentre Azure Policy decide cosa può essere creato o come deve essere configurata una risorsa (proprietà del risorsa stessa). Un utente può avere il ruolo Contributor (RBAC gli permette di creare qualsiasi cosa), ma una policy con effect Deny può comunque bloccare la creazione di una VM in una region non consentita. I due meccanismi sono complementari, non alternativi.

Definition, initiative, assignment e scope

  • Policy definition: descrive la condizione da valutare (if) e l’azione da eseguire (then, cioè l’effect). Esistono decine di definizioni built-in (es. “Allowed locations”, “Require a tag on resources”).
  • Initiative (policy set): raggruppa più policy definition sotto un unico obiettivo, tipicamente uno standard di compliance (es. ISO 27001, Azure Security Benchmark). Si assegna e si monitora come un’unità sola.
  • Assignment: applica una definition o initiative a uno scope. Lo scope segue la gerarchia management group → subscription → resource group → risorsa. Assegnare a un management group propaga a tutte le subscription figlie; le exclusion permettono di escludere rami specifici.

Per parametri come le region consentite, si usano i parameters dell’assignment: la stessa definition viene riutilizzata con valori diversi in scope diversi.

Gli effect e quando usarli

  • Deny: blocca la richiesta di creazione o update se non conforme. Valutato prima che la risorsa venga scritta. È l’effect da scegliere per impedire configurazioni non ammesse (region, SKU, risorse pubbliche).
  • Audit: non blocca nulla, ma marca la risorsa come non compliant nel report. Usato per visibilità senza impatto operativo, tipico in fase di roll-out prima di passare a Deny.
  • Append: aggiunge campi mancanti alla richiesta (es. un tag o una regola di rete) durante la creazione, senza rivalutare risorse esistenti.
  • Modify: aggiunge, aggiorna o rimuove proprietà o tag su risorse, anche esistenti, tramite operazioni add/replace/remove. Ideale per standardizzare la taggatura su larga scala.
  • DeployIfNotExists (DINE): se una risorsa correlata manca, esegue il deployment di un template per rimediare (es. abilitare i diagnostic settings, installare un agent). Valutato dopo la creazione della risorsa.

Regola pratica per l’esame: serve impedire → Deny; serve osservare → Audit; serve correggere/aggiungere configurazione → Modify o DeployIfNotExists.

Compliance state e remediation

Dopo l’assignment, Azure Policy valuta le risorse e assegna un compliance state: Compliant, Non-compliant o Exempt (tramite policy exemption). La valutazione avviene alla creazione/modifica e in scansioni periodiche (circa ogni 24 ore, forzabile con una scan on-demand).

Gli effect Modify e DeployIfNotExists non correggono automaticamente le risorse già esistenti al momento dell’assignment: quelle risultano non compliant finché non si esegue un remediation task, che applica l’azione retroattivamente sulle risorse pre-esistenti.

La managed identity per la remediation

Per eseguire un remediation task, l’assignment deve possedere una managed identity (system-assigned o user-assigned) a cui vanno concessi i ruoli RBAC necessari sullo scope. Esempio: una policy DINE che abilita i diagnostic settings richiede che l’identità abbia i permessi per scrivere quelle impostazioni (es. Contributor o un ruolo mirato). Il campo roleDefinitionIds nella definition dichiara quali ruoli servono. Senza identità o senza i ruoli adeguati, la remediation fallisce silenziosamente anche se l’assignment è corretto.

Trappole tipiche d’esame

  • Scenario: devi impedire la creazione di risorse fuori da alcune region → Deny con parametro “allowed locations”, non Audit (Audit segnala soltanto).
  • Scenario: una policy DINE è assegnata ma le risorse esistenti restano non-compliant → serve creare un remediation task; DINE/Modify non toccano le risorse pre-esistenti da soli.
  • Scenario: il remediation task fallisce → verifica che la managed identity dell’assignment esista e abbia i ruoli RBAC dichiarati in roleDefinitionIds sullo scope corretto.
  • Scenario: vuoi applicare più standard di compliance insieme e monitorarli come un blocco → usa un’initiative (policy set), non decine di assignment singoli.
  • Scenario: un Owner riesce comunque a violare una regola? → No: RBAC dà i permessi, ma un effect Deny blocca l’operazione indipendentemente dal ruolo. Policy e RBAC agiscono su piani diversi.