Governance Azure: tag, policy e controllo dei costi nelle organizzazioni

C'è un momento preciso in cui un ambiente Azure smette di essere un progetto e diventa un problema: quando la prima fattura arriva senza che nessuno sappia dire a quale reparto appartenga la metà dei costi. Non è un fallimento tecnico. È il risultato prevedibile di sei mesi in cui ogni team ha creato le proprie risorse, con i propri nomi, i propri tag — o nessun tag — e la propria idea di dove mettere le cose.

Recuperare quella situazione è possibile, ma costoso: si finisce a ricostruire la storia da log e convenzioni orali. La governance conviene farla prima, e in Azure non richiede strumenti esotici: tre componenti coprono la maggior parte del fabbisogno.

Policy e RBAC non sono la stessa cosa

La distinzione che chiarisce tutto il resto sta nella documentazione di Azure Policy: il controllo degli accessi basato sui ruoli decide chi può compiere un'azione; Azure Policy valuta lo stato delle risorse, indipendentemente da chi le ha create e da quali permessi avesse. Un amministratore con ruolo Owner su una sottoscrizione può creare una macchina virtuale con disco pubblico: il RBAC non lo ferma, una policy sì.

Da qui due conseguenze pratiche:

• il RBAC va progettato per ruolo (chi amministra cosa), la policy per conformità (cosa è ammesso nel patrimonio);
• le regole di policy vivono in JSON e si assegnano a uno scope: gruppo di gestione, sottoscrizione, gruppo di risorse o singola risorsa. Si possono escludere sottoscrizioni o gruppi di risorse specifici, ed è la valvola che serve per non bloccare i casi legittimi.

Le iniziative (policySet) raggruppano più definizioni e si assegnano come un blocco unico: è così che si evita di avere quaranta assegnazioni da mantenere a mano.

Tag: prima la tassonomia, poi l'automazione

I tag sono la spina dorsale di tutto il resto: senza, né il chargeback né le policy di conformità hanno su cosa appoggiarsi. Tre vincoli tecnici da conoscere prima di scegliere i nomi:

• ogni risorsa, gruppo di risorse e sottoscrizione può avere al massimo 50 coppie nome-valore; il nome può arrivare a 512 caratteri (128 per gli account di archiviazione), il valore a 256;
• i tag non si ereditano: una risorsa non riceve i tag del gruppo di risorse o della sottoscrizione in cui vive. Se serve ereditarietà, si ottiene con una policy dedicata;
• esiste una chiave speciale, cm-resource-parent, che raggruppa i costi di più risorse sotto un genitore logico e permette di leggerli in Cost Management senza costruire filtri.

Il primo vincolo è quello che manda all'aria i piani più ambiziosi: chi progetta venti tag finisce per usarne tre. Meglio partire da un set minimo, con un proprietario per ciascuno:

Quattro tag coprono l'80% dei casi. Tutto il resto — versione, progetto, data di dismissione — è utile solo se c'è qualcuno che lo legge.

Policy: iniziare in audit, non in deny

La raccomandazione che Microsoft mette nero su bianco nella guida è controintuitiva per chi vuole «mettere in sicurezza» subito: partire da audit o auditIfNotExists invece che da un effetto di enforcement. Il motivo è semplice: una deny su una regola scritta male blocca i deployment, e il giorno in cui succede nessuno ricorda più chi l'ha assegnata.

Gli effetti disponibili sono più articolati di quanto si pensi:

• deny blocca la creazione o la modifica non conforme;
• audit registra la non conformità senza intervenire;
• modify aggiunge o aggiorna proprietà (è l'effetto che serve per l'ereditarietà dei tag);
• deployIfNotExists distribuisce risorse correlate, come la diagnostica;
• denyAction blocca azioni specifiche su risorse esistenti, come la cancellazione.

Il percorso che funziona in un'organizzazione reale è in tre tempi: due settimane di solo audit per misurare quanto è sporco l'ambiente, poi le modify per i tag mancanti, e solo alla fine le deny sulle cose che non devono mai accadere — dischi pubblici, regole di rete aperte a Internet, risorse in aree geografiche non ammesse.

Un dettaglio operativo che fa risparmiare ore: le policy di conformità vanno assegnate al gruppo di gestione, non alle singole sottoscrizioni. Assegnare in basso significa replicare la stessa regola venti volte e, puntualmente, dimenticarne una.

Costi: da bolletta a dato

Microsoft Cost Management non è solo il grafico della spesa. Le funzioni che servono davvero in un'organizzazione sono quattro:

• budget con avvisi su soglie, inviati a chi consuma e non solo a chi paga;
• anomaly detection giornaliera, calibrata sull'utilizzo normalizzato: intercetta la macchina accesa per errore prima che diventi un'abitudine;
• cost allocation rules, che applicano l'ereditarietà dei tag e ripartiscono i costi condivisi (rete, log, piattaforma) tra i centri di costo;
• export programmati verso un account di archiviazione, per portare i dati in Power BI o in un data warehouse e confrontarli con il resto della contabilità.

L'ultima è la meno usata e la più utile: finché il costo vive solo nel portale, il confronto con il budget aziendale avviene una volta al mese e in ritardo. Un export giornaliero trasforma la discussione da «quanto abbiamo speso» a «perché questa applicazione costa il 30% in più del mese scorso».

Un piano realistico per i primi trenta giorni

Chi eredita un ambiente disordinato non deve scegliere tra rifare tutto e non fare nulla. La sequenza che consigliamo:

1. Settimana 1 — censimento. Elenco delle sottoscrizioni, dei gruppi di gestione esistenti e dei tag realmente presenti, con la distribuzione per risorsa. Serve a sapere se il problema è di tassonomia o di disciplina.
2. Settimana 2 — tassonomia. Scelta dei 4-6 tag, con nome, valori ammessi e proprietario. Documentata in una pagina, non in una chat.
3. Settimane 3-4 — policy in audit. Definizioni e iniziativa assegnate al gruppo di gestione, effetto audit, report di conformità letto con i team.
4. Mese 2 — automazione dei tag. Policy modify per l'ereditarietà, bonifica delle risorse non conformi, primo budget per applicazione con avviso al proprietario.

Le deny arrivano al mese 3, quando le regole sono state provate e nessuno si sorprende. Chi inverte l'ordine ottiene il risultato opposto: regole aggirate con deroghe, e un ambiente che sembra conforme solo perché nessuno prova più a crearci nulla.

L'errore che costa più di tutti

Il fallimento tipico non è tecnico, è organizzativo: una governance senza un proprietario. Le policy assegnate e mai riviste diventano rumore; i tag compilati a mano decadono alla prima urgenza; i budget senza destinatario degli avvisi non li guarda nessuno.

Prima di scrivere la prima definizione JSON servono tre nomi: chi decide la tassonomia dei tag, chi approva le deroghe alle policy, chi riceve gli avvisi di budget. Senza questi, Azure offre strumenti ottimi che restano spenti.

Se la tua organizzazione ha già una landing zone impostata e il problema è il livello successivo — chi fa cosa, come si distribuiscono i costi, come si gestiscono le eccezioni — il passo utile è ragionare per ruoli e processi. Il percorso Microsoft Azure per amministratori di Digital Lab srl copre policy, tag e gestione dei costi proprio in questa prospettiva, con laboratori su sottoscrizioni reali: prima si misura, poi si applica.

Per chi sta ancora progettando l'impianto, è utile leggere prima Azure Landing Zone: perché serve prima di migrare workload nel cloud e tenere a portata di mano Azure per amministratori: le competenze essenziali.

Fonti

• Azure Policy — overview
• Use tags to organize your Azure resources
• What is Microsoft Cost Management?