Che cos'è il controllo degli accessi basato sui ruoli (RBAC)?

Il controllo degli accessi basato sui ruoli è un modello di autorizzazione in cui i permessi si agganciano ai ruoli, mai direttamente alle persone. L’indirezione è tutta l’idea: nulla viene mai concesso direttamente a una persona, così il cambiamento organizzativo diventa cambiamento di dati – una promozione è una riassegnazione di ruolo, non uno scavo archeologico fra concessioni sparse. Proposto da Ferraiolo e Kuhn nel 1992 come alternativa ai più vecchi modelli discrezionale e obbligatorio, è diventato lo standard ANSI/INCITS 359 e il vocabolario di autorizzazione predefinito del software aziendale.

Punti chiave

Utenti, ruoli, permessi – l’indirezione all’opera

Permessi                    Ruoli                    Utenti
─────────────               ─────────────            ─────────────
posts:read        ─┐
posts:write        ├──▶     Editor          ◀──────  Ada, Grace
posts:publish     ─┘
users:manage      ─┐
billing:view       ├──▶     Admin           ◀──────  Linus
posts:*           ─┘
posts:read        ────▶     Viewer          ◀──────  tutti gli altri

Ada pubblica perché Editor porta posts:publish – riassegnando il suo
ruolo, ogni permesso che esso portava si sposta. Una modifica, non N.

I ruoli come dati vivi, collegati ai permessi degli oggetti:

// JavaScript / Node.js — Back4app JS SDK
// Roles as data: create a role, add members, grant through it
const roleACL = new Parse.ACL();
roleACL.setPublicReadAccess(true);
const editors = new Parse.Role('Editors', roleACL);
editors.getUsers().add(adaUser);
await editors.save();

// Grant by role, not by user — membership changes in one place
const post = new Parse.Object('Post');
const acl = new Parse.ACL(currentUser);  // owner entry
acl.setRoleWriteAccess('Editors', true); // RBAC meets the object's ACL
post.setACL(acl);
await post.save();

// Flutter / Dart — Back4app Flutter SDK
// Roles as data: create a role, add members, grant through it
final roleACL = ParseACL()..setPublicReadAccess(allowed: true);
final editors = ParseObject('_Role')
  ..set('name', 'Editors')
  ..setACL(roleACL)
  ..addRelation('users', [adaUser]);
await editors.save();

// Grant by role, not by user — membership changes in one place
final post = ParseObject('Post');
final acl = ParseACL(owner: currentUser)  // owner entry
  ..setRoleWriteAccess('Editors', true);  // RBAC meets the object's ACL
post.setACL(acl);
await post.save();

// iOS / Swift — Back4app Swift SDK
// Roles as data: create a role, add members, grant through it
var editors = try ParseRole(name: "Editors")
let savedRole = try await editors.save()
try await savedRole.users.add([adaUser]).save() // membership = a relation

// Grant by role, not by user — membership changes in one place
var post = Post()
var acl = ParseACL()
acl.setReadAccess(user: currentUser, value: true)
acl.setWriteAccess(user: currentUser, value: true)   // owner entry
acl.setWriteAccess(roleName: "Editors", value: true) // RBAC meets the ACL
post.ACL = acl
try await post.save()

// Android / Kotlin — Back4app Android SDK
// Roles as data: create a role, add members, grant through it
val roleACL = ParseACL()
roleACL.publicReadAccess = true
val editors = ParseRole("Editors", roleACL)
editors.users.add(adaUser)
editors.save()

// Grant by role, not by user — membership changes in one place
val post = ParseObject("Post")
val acl = ParseACL(ParseUser.getCurrentUser()) // owner entry
acl.setRoleWriteAccess("Editors", true)        // RBAC meets the object's ACL
post.acl = acl
post.save()

Il modello NIST, per davvero

Quasi tutte le spiegazioni comprimono lo standard in un elenco puntato; la struttura reale merita trenta secondi. RBAC di base definisce utenti, ruoli, permessi – e le sessioni, l’elemento dimenticato: un utente attiva un sottoinsieme dei propri ruoli per sessione, ed è così che un amministratore può navigare per impostazione predefinita con poteri da semplice membro ed elevarsi in modo deliberato. Le tre regole dell’articolo originale tengono insieme il tutto: agire solo attraverso un ruolo, detenere solo ruoli autorizzati, fare solo ciò che il ruolo attivo permette. RBAC gerarchico aggiunge l’ereditarietà – i ruoli senior inglobano quelli junior (Manager ⊇ Employee), eliminando i duplicati. RBAC vincolato aggiunge la separazione dei compiti: le regole statiche vietano in blocco le assegnazioni di ruoli in conflitto (mai creatore e approvatore dei pagamenti insieme); quelle dinamiche consentono l’assegnazione ma vietano di attivare entrambi i ruoli in una stessa sessione. E la precisazione più tagliente del NIST, regolarmente storpiata: un gruppo è una raccolta di utenti; un ruolo è una raccolta di permessi – il ruolo si definisce per ciò che può fare, non per chi ne fa parte.

RBAC vs. ACL vs. ABAC

Quello che le pagine dei fornitori seppelliscono: questi modelli si compongono, non si escludono. I ruoli gestiscono l’accesso che segue la funzione lavorativa; le voci di ACL gestiscono le eccezioni su singoli oggetti – e la cerniera è l’ACE di ruolo, una riga di ACL che nomina un ruolo invece di un utente, offrendo controllo a livello di oggetto con gestione dei membri in un unico posto. Le condizioni su attributi si sovrappongono dove il contesto (orario, tenant, stato del record) decide davvero. “Quale scegliere?” è quasi sempre la domanda sbagliata; “quale strato prende quale decisione?” è la progettazione.

L’esplosione dei ruoli – il modo in cui RBAC fallisce

La malattia caratteristica di RBAC: ogni eccezione conia un ruolo, poi ogni progetto, regione e tenant li moltiplica – Project-A-Manager-Region-West-ReadOnly – finché i ruoli superano in numero gli utenti e la risposta dell’audit a “chi può fare che cosa?” è “nessuno lo sa”. La causa profonda è sempre la stessa: attributi contestuali codificati come ruoli. Le mitigazioni, nell’ordine: tenere gli attributi fuori dai nomi dei ruoli (regione e tenant sono condizioni o ambiti, non ruoli); gestire la condivisione per oggetto con le voci di ACL, mai con ruoli per singolo oggetto; confinare i ruoli per tenant in modo strutturale anziché storpiando i nomi; e verificare – i ruoli che nessuno detiene, i permessi che nessun ruolo usa e le concessioni di cui nessuno si ricorda sono deriva, ed è per deriva che il privilegio minimo muore in silenzio. Un’euristica che funziona: se l’elenco dei ruoli smette di stare in uno schermo, il modello sta assorbendo lavoro che appartiene a un altro strato.

Progettare i ruoli: top-down, bottom-up o entrambi

La parte che nessuna spiegazione ben posizionata copre: da dove vengono i ruoli. L’approccio top-down li deriva dall’organizzazione e dai suoi processi – intervistare il business, nominare le funzioni, assegnare permessi minimi; accurato ma lento. L’approccio bottom-up li estrae dalle concessioni esistenti – raggruppare chi già detiene che cosa, e i ruoli candidati emergono da soli; rapido, ma riciclano in politica ufficiale gli errori del passato. La pratica è ibrida: estrarre i candidati, validarli rispetto alle funzioni, poi applicare il test 80/20 – una manciata di ruoli ampi per il grosso dell’organizzazione, con le eccezioni gestite da ACL o condizioni anziché da ruoli su misura. E una regola di implementazione che sopravvive a ogni riorganizzazione: il codice deve controllare i permessi, non i nomi dei ruoli – can('posts:publish'), non hasRole('Editor') – così che ridefinire un ruolo sia un cambiamento di dati e non un refactoring, con applicazione delle regole lato server e rifiuto per impostazione predefinita.

Casi d’uso tipici

• Pannelli di amministrazione e back-office – supporto, moderatore, finanza, superamministratore: le funzioni si traducono pulitamente in ruoli.
• Flussi di contenuti e pubblicazione – autore, editor, pubblicatore, con una separazione fra scrivere e rilasciare.
• Permessi di squadra nel SaaS B2B – owner/admin/membro/fatturazione per spazio di lavoro, confinati per tenant.
• Operazioni soggette a conformità – la separazione dei compiti come vincolo sui ruoli applicabile, con l’appartenenza ai ruoli come prova di audit.
• La barriera dei ruoli sugli strati dei dati – i ruoli come il “chi” dei permessi di classe e delle politiche a livello di riga.

Conviene usare RBAC? Matrice decisionale

Limiti e trade-off

• La condivisione per oggetto resta fuori perimetro. “Condividere questo documento con Ana” non ha risposta in RBAC, se non creando un ruolo per documento – quella decisione appartiene alle ACL.
• Stesso ruolo, stessi poteri. Due Editor sono indistinguibili; la sfumatura individuale richiede un altro strato, non un ruolo quasi duplicato.
• L’ingegneria dei ruoli è vero lavoro iniziale. Salterla produce ruoli che non rispecchiano né l’organizzazione né il modello di rischio – e che vengono copiati per sempre.
• I ruoli statici non vedono il rischio dinamico. L’appartenenza a un ruolo non percepisce orari insoliti, dispositivi nuovi o stati sensibili di un record; quello è territorio degli attributi.
• La deriva è lo stato stazionario. Senza ricertificazione periodica l’ampiezza dei ruoli può solo crescere; la verificabilità di RBAC è una possibilità, non una garanzia.

I ruoli su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Qui i ruoli sono dati, non codice: ciascuno è un oggetto della classe _Role con una relazione users per i membri e una relazione roles per l’annidamento – e l’annidamento è gerarchia gratis, perché i membri di un ruolo figlio ereditano tutto ciò che è concesso ai suoi ruoli padre. Le concessioni avvengono esattamente dove indica la sezione sulla composizione: i nomi dei ruoli compaiono nei permessi di classe per le linee generali e nelle voci di ACL per oggetto per le eccezioni – le schede di codice mostrano entrambe le metà – e Back4app applica il risultato a ogni richiesta REST, GraphQL e Live Query. Poiché i ruoli sono oggetti interrogabili, la gestione dei membri, gli audit e le interfacce di amministrazione diventano normale lavoro sul database: prevenire l’esplosione dei ruoli come abitudine di modellazione, non come progetto di governance.