Il RBAC (Role-Based Access Control, controllo degli accessi basato sui ruoli) è il modello di controllo degli accessi dominante nei sistemi informativi aziendali. I permessi non vengono assegnati direttamente agli utenti, ma a ruoli che rappresentano funzioni lavorative; gli utenti vengono poi assegnati ai ruoli che corrispondono alle loro responsabilità. Standardizzato dal NIST (NIST SP 800-192), distingue quattro componenti: Utenti, Ruoli, Permessi e Sessioni.
Struttura
Utente → Ruolo → Permessi → Operazione → OggettoEsempio pratico:
| Utente | Ruoli assegnati | Permessi ereditati |
|---|---|---|
| alice | Sviluppatore, TeamLead | read/write/deploy su /repo, read su /staging |
| bob | Sviluppatore | read/write su /repo |
| carol | Auditor | read su /logs, read su /reports |
| dave | Amministratore DB | read/write su /db, nessun accesso a /repo |
Vantaggi rispetto al DAC
Scalabilità: aggiungere un nuovo dipendente significa assegnargli i ruoli appropriati, non configurare centinaia di permessi individuali. Revocare l’accesso al momento del termine del rapporto significa rimuovere tutti i ruoli.
Separazione dei compiti (SoD): il RBAC permette di imporre che nessun singolo utente possa compiere da solo operazioni critiche che richiedono due persone (es. richiedere e approvare un bonifico). Si definiscono coppie di ruoli mutuamente esclusivi che non possono essere assegnati allo stesso utente.
Audit semplificato: i permessi sono definiti a livello di ruolo — documentati e verificabili — non dispersi tra migliaia di utenti con assegnazioni individuali difficili da tracciare.
Principio del minimo privilegio: i ruoli possono essere disegnati per includere solo i permessi strettamente necessari alla funzione lavorativa.
RBAC gerarchico
Il RBAC gerarchico (RBAC1 nel modello NIST) aggiunge l’ereditarietà tra ruoli: un ruolo “superiore” eredita tutti i permessi dei ruoli “base”. Un ruolo “TeamLead” eredita tutti i permessi di “Sviluppatore” e ne aggiunge di propri (es. deploy in produzione). Questo rispecchia le gerarchie organizzative ed evita la duplicazione dei permessi.
Implementazioni
Database: i GRANT/REVOKE SQL operano su ruoli (GRANT SELECT ON tabella TO ruolo_lettura). Kubernetes: RBAC è il meccanismo nativo di autorizzazione per l’accesso all’API server. AWS IAM: i permission boundaries e i ruoli IAM implementano RBAC per le risorse cloud. Active Directory: i gruppi di sicurezza implementano RBAC per le risorse Windows.
Limite: Permission Creep
Il rischio principale del RBAC mal gestito è il permission creep: utenti che accumulano ruoli aggiuntivi nel tempo (per esigenze temporanee, cambi di mansione) senza che vengano revocati quelli precedenti. Dopo anni, molti utenti hanno diritti di accesso molto superiori a quelli necessari. La soluzione è la access recertification periodica: revisione sistematica dei ruoli assegnati per revocare quelli non più necessari.