Perché i permessi RBAC sono additivi

In Azure RBAC l’accesso nasce dalla combinazione di tre elementi in un role assignment: un security principal (utente, gruppo, service principal o managed identity), una role definition e uno scope (management group, subscription, resource group o singola risorsa). La regola chiave è che i permessi sono additivi: l’accesso effettivo di un principal è l’unione di tutti i suoi role assignment ereditati lungo la gerarchia di scope. Non esiste un concetto di “nega vince” tra assignment: se un ruolo concede un’azione, un altro ruolo non può revocarla. L’unica eccezione sono le deny assignment.

Quando i built-in role (Owner, Contributor, Reader, o ruoli specifici come Virtual Machine Contributor) non corrispondono esattamente a ciò che serve, si crea un custom role. Il criterio da tenere a mente per l’esame: usa un built-in role finché copre lo scenario; crea un custom role solo quando devi concedere un sottoinsieme preciso di permessi che nessun built-in rappresenta (least privilege granulare).

Struttura di una role definition

Una custom role è un documento JSON con quattro campi di permessi più gli scope assegnabili:

  • Actions — le operazioni del control plane (management, via Azure Resource Manager) consentite, es. Microsoft.Compute/virtualMachines/start/action.
  • NotActions — operazioni sottratte dall’insieme delle Actions. Il permesso effettivo di control plane è Actions − NotActions.
  • DataActions — operazioni sul data plane, cioè sui dati dentro la risorsa (es. leggere un blob: Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read).
  • NotDataActions — sottrazione analoga applicata alle DataActions.
"Actions": [ "Microsoft.Compute/virtualMachines/*/read" ],
"NotActions": [],
"DataActions": [],
"AssignableScopes": [ "/subscriptions/{subId}/resourceGroups/prod-rg" ]

Il campo AssignableScopes definisce dove il ruolo può essere assegnato (non cosa può fare): deve contenere almeno uno scope. Restringerlo (es. a una singola subscription o resource group) evita che il ruolo compaia come assegnabile in tutto il tenant. Un custom role può avere un management group negli AssignableScopes, ma può essere definito a un solo management group.

Least privilege e deny assignment

Il principio del least privilege significa concedere solo i permessi minimi necessari, allo scope più stretto possibile. In pratica: preferire Reader a Contributor, assegnare a resource group invece che a subscription, e costruire custom role mirati invece di partire da Contributor “togliendo” pezzi.

Le deny assignment bloccano azioni specifiche per determinati principal a uno scope, e hanno precedenza sui role assignment (deny wins). Non sono normalmente create a mano dagli amministratori: le genera la piattaforma, ad esempio i Deployment Stacks con le deny settings per proteggere le risorse gestite da modifiche o cancellazioni. Per l’esame ricorda: la deny assignment è l’unico meccanismo che sovrascrive l’additività dei permessi.

Attenzione: NotActions non è un deny

L’errore concettuale più insidioso: NotActions non è un blocco esplicito. È solo una sottrazione interna a quella singola role definition. Se lo stesso principal riceve, tramite un altro role assignment, un ruolo le cui Actions includono quell’operazione, il principal la ottiene comunque (i permessi restano additivi). Per impedire davvero un’azione a chiunque servono le deny assignment, non le NotActions.

Infine, esiste un limite di 5.000 custom role per tenant (directory) — rilevante negli ambienti enterprise che proliferano ruoli quasi-identici invece di parametrizzare gli scope.

Trappole tipiche d’esame

  • Serve garantire che un gruppo NON possa mai eliminare le VM, anche se altrove ha Contributor → una NotAction nel custom role non basta (additività); serve una deny assignment (o rimuovere l’assegnazione più permissiva).
  • Un ruolo deve permettere di leggere i dati dentro un container blob, non solo gestire lo storage account → il permesso va in DataActions (data plane), non in Actions.
  • Vuoi che un custom role sia assegnabile solo in una resource group specifica → configura AssignableScopes, non le Actions.
  • Un utente ha Reader su una subscription e Contributor su una resource group figlia → prevale l’unione: è Contributor su quella RG (i permessi si sommano, non si sottraggono ereditando).
  • Nessun built-in role corrisponde e devi concedere solo l’avvio/arresto delle VM → crea un custom role con le Actions minime; non assegnare Virtual Machine Contributor (troppo ampio, viola il least privilege).