Azure RBAC: assegnazioni, built-in roles e scope

Che cos’è Azure RBAC

Azure RBAC (Role-Based Access Control) è il sistema di autorizzazione, costruito su Azure Resource Manager (ARM), che governa chi può fare cosa e dove sulle risorse Azure. Non gestisce le identità (compito di Microsoft Entra ID) ma decide quali operazioni un’identità già autenticata è abilitata a compiere. Ogni permesso concesso si concretizza in una role assignment.

I tre elementi di una role assignment

Ogni assegnazione lega insieme tre componenti:

• Security principal (chi) — l’identità a cui concedi l’accesso: un utente, un gruppo, una service principal (app registration) o una managed identity. Best practice: assegnare i ruoli a gruppi Entra ID, non a singoli utenti, per governare l’accesso su scala.
• Role definition (cosa) — la collezione di permessi (Actions, NotActions, DataActions, NotDataActions) che descrive le operazioni consentite.
• Scope (dove) — il perimetro di risorse su cui l’assegnazione ha effetto.

I quattro scope e l’ereditarietà

Gli scope formano una gerarchia dal più ampio al più stretto:

1. Management group — raggruppa più subscription (es. per business unit o ambiente).
2. Subscription
3. Resource group
4. Resource (la singola risorsa, es. uno storage account).

L’ereditarietà è top-down: un ruolo assegnato a un livello superiore si propaga automaticamente a tutti i livelli sottostanti. Assegnare Contributor a livello di subscription significa Contributor su tutti i resource group e le risorse contenute. Regola pratica d’esame: assegna il ruolo allo scope più basso possibile che soddisfa il requisito (least privilege). Gli effetti di più assegnazioni sono cumulativi (additivi): i permessi si sommano lungo la gerarchia — non esiste un “deny” implicito per sovrapposizione (i deny esistono solo tramite gli espliciti Azure deny assignments, che vincono sempre).

I built-in role chiave (control plane)

• Owner — controllo completo, incluso il diritto di delegare l’accesso (creare role assignment).
• Contributor — può creare, modificare ed eliminare qualsiasi risorsa, ma non può gestire le role assignment né i blueprint di accesso.
• Reader — sola visualizzazione.
• User Access Administrator — l’inverso di Contributor: gestisce solo gli accessi (assegnazioni RBAC), senza toccare le risorse. Ideale per separare la governance degli accessi dall’operatività.

Control plane vs data plane

I ruoli sopra agiscono sul control plane (gestione ARM della risorsa). L’accesso ai dati interni richiede spesso data-plane role separati, definiti tramite DataActions:

• Storage Blob Data Contributor / Reader / Owner — permettono di leggere/scrivere i blob dentro uno storage account.
• Key Vault Secrets User, Cosmos DB Built-in Data Reader, ecc.

Punto architetturale cruciale: Contributor sullo storage account consente di gestire l’account (chiavi, config, endpoint) ma non concede di per sé l’accesso ai dati blob via Entra ID. Per leggere i blob con identità Entra serve un data-plane role come Storage Blob Data Reader. Viceversa, un ruolo data-plane non permette di riconfigurare la risorsa.

Custom role e verifica

Quando i built-in non bastano, si crea un custom role in JSON (Actions/NotActions/DataActions), assegnabile solo entro subscription/management group definiti in AssignableScopes. Per capire perché un’identità ha (o non ha) un permesso, si usa Check access nel portale o il comando:

az role assignment list --assignee <upn> --all

Trappole tipiche d’esame

• “Un utente deve creare VM e concedere ad altri l’accesso a quelle VM” → non basta Contributor (non assegna accessi): serve Owner oppure la coppia Contributor + User Access Administrator.
• “App deve leggere blob autenticandosi con Entra ID; ha già Contributor sullo storage account” → aggiungi Storage Blob Data Reader: Contributor è control plane e non copre il data plane.
• “Minimo privilegio per delegare solo gli accessi senza gestire risorse” → User Access Administrator, non Owner.
• “Ruolo assegnato al management group ma serve limitarlo a un solo resource group” → ricorda l’ereditarietà top-down: assegna allo scope più basso (resource group), non in alto.
• “Un utente ha Reader alla subscription e Contributor a un resource group: cosa può fare nel RG?” → i permessi sono additivi: agisce come Contributor in quel resource group.