Role-based access control

Nell'ambito della sicurezza informatica, il role-based access control^[1][2] (in italiano: controllo degli accessi basato sui ruoli; in sigla RBAC) è una tecnica di controllo di accesso degli utenti alle risorse di un sistema informatico. È una più recente alternativa al mandatory access control ("controllo degli accessi vincolato", in sigla MAC) e al discretionary access control ("controllo degli accessi discrezionale", in sigla DAC).

Si tratta di un meccanismo di accesso definito basandosi sui concetti di ruolo e permesso. I componenti del RBAC, come i permessi dei ruoli, il ruolo utente e le relazioni ruolo-ruolo, consentono di semplificare l'assegnazione dei permessi agli utenti. Uno studio diretto dal NIST (National Institute of Standard Technologies) ha dimostrato che il RBAC risponde a molte necessità di organizzazioni commerciali e governative. Infatti, il RBAC può essere usato per facilitare la gestione della sicurezza nelle organizzazioni composte da centinaia di utenti e migliaia di permessi diversi. Benché il RBAC sia diverso dal MAC e dal DAC, può contribuire a migliorare queste politiche senza aggiungere delle complicazioni. La popolarità del RBAC è evidenziata dal fatto che molti prodotti e organizzazioni lo usano direttamente o indirettamente.

All'interno di un'organizzazione, i ruoli definiscono differenti attività lavorative. I permessi di eseguire specifiche operazioni sono assegnati a specifici ruoli. Ai membri di un gruppo sono assegnati particolari ruoli e, attraverso queste assegnazioni, questi acquisiscono il permesso di eseguire specifiche funzioni. Poiché i permessi non sono assegnati direttamente all'utente, ma vengono acquisiti solo tramite il ruolo (o i ruoli) assegnati all'utente, la gestione dei diritti individuali di un utente diventa una semplice assegnazione di ruoli appropriati all'utente stesso. Questo semplifica le operazioni comuni, come l'aggiunta di un utente o il cambio di dipartimento.

Tre regole fondamentali sono definite per il modello RBAC:

1. Assegnazione dei ruoli: un soggetto può eseguire una transazione solo se il soggetto ha selezionato o è stato assegnato ad un ruolo.
2. Autorizzazione dei ruoli: un ruolo attivo per un soggetto deve essere stato autorizzato per il soggetto. Insieme alla regola 1 questa regola garantisce che gli utenti possono avere esclusivamente ruoli ai quali sono stati autorizzati.
3. Autorizzazione alla transazione: un soggetto può eseguire una transazione solo se la transazione è autorizzata per il ruolo attivo del soggetto. Insieme alle regole 1 e 2 questa regola garantisce che l'utente possa eseguire solo transazioni alle quali è stato autorizzato.

Possono anche essere applicati vincoli aggiuntivi ed i ruoli possono essere combinati in una gerarchia dove livelli più alti sono composti dai permessi dei ruoli dei livelli inferiori.

Con i concetti di vincoli e di gerarchia dei ruoli si può creare o simulare un approccio Lattice-Based Access Control (LBAC). Pertanto il RBAC può essere considerato un ampliamento del LBAC.

Quando si definisce un RBAC sono utili le seguenti convenzioni:

• S = Soggetto = una persona o un agente automatico;
• R = Ruolo = attività lavorativa o titolo che definisce un livello di autorità;
• P = Permessi = approvazione della modalità di accesso alla risorsa;
• SE = Sessione = un collegamento che coinvolge S, R e/o P;
• SA = Assegnazione al soggetto;
• PA = Assegnazione di permesso;
• RH = Gerarchia di ruolo ordinata parzialmente (RH può anche essere scritta come: ≥ dove la notazione x ≥ y significa che x eredita i permessi di y).

Inoltre, si seguono le seguenti regole:

• Un soggetto può avere più ruoli.
• Un ruolo può avere più soggetti.
• Un ruolo può avere più permessi.
• Un permesso può essere assegnato a più ruoli.
• Un'operazione può essere assegnata a più permessi.
• Un permesso può essere assegnato a più operazioni.

Un vincolo crea anche una regola restrittiva sulla potenziale eredità di permessi da ruoli antitetici e perciò può essere usato per raggiungere un'appropriata separazione dei compiti. Ad esempio, una persona non abilitata a creare un account non dovrebbe poter autorizzare la creazione di un account.

Perciò, usando la notazione insiemistica:

• ${\displaystyle PA\subseteq P\times R}$: è una relazione molti a molti tra i permessi e i ruoli;
• ${\displaystyle SA\subseteq S\times R}$: è una relazione molti a molti tra i soggetti e i ruoli;
• ${\displaystyle RH\subseteq R\times R}$: è una relazione molti a molti tra ruoli ed altri ruoli.

Da notare che un soggetto può avere diverse sessioni simultanee con/in ruoli differenti.

Il RBAC è una tecnologia di controllo degli accessi flessibile che consente di implementare sistemi DAC^[3] o MAC.^[4] Viceversa, il DAC con gruppi (come ad esempio il sistema implementato nei file system POSIX) può emulare il RBAC.^[5] Anche il MAC può simulare il RBAC se il grafico dei ruoli assume la forma di albero e non di insieme parzialmente ordinato.^[6]

Prima dello sviluppo del RBAC, il modello Bell-LaPadula (BLP) era sinonimo di MAC e i permessi del file system erano equivalenti al DAC. Essi erano considerati gli unici modelli conosciuti per il controllo dell'accesso: se un modello non ricadeva in un modello BLP, allora era considerato un DAC, e viceversa. Diverse ricerche della fine degli anni Novanta hanno dimostrato che il RBAC non ricade in nessuna delle due categorie.^[7][8] A differenza del Context-Based Access Control (CBAC), il RBAC non si basa sui messaggi di contesto (come la fonte della connessione). Il RBAC è stato criticato in quanto comporta un grande numero di ruoli^[9], un problema nei sistemi delle grandi imprese, che richiedono un controllo degli accessi più fine rispetto a quello che il RBAC può fornire tramite i ruoli assegnati attraverso ereditarietà ad operazioni e ai tipi di dato. In somiglianza al CBAC, un sistema basato su Entity-Relationship Based Access Control (ERBAC, da non confondere con l'Extended Role-Based Access Control, una versione modificata del RBAC^[1] che usa lo stesso acronimino), è capace di assicurare istanze di dati considerando la loro associazione con il soggetto che sta eseguendo.^[10]

Il RBAC è diverso anche dalle liste di controllo degli accessi (ACL), usate nei sistemi tradizionali a controllo discrezionale degli accessi, in cui si assegnano permessi per specifiche operazioni legate ad oggetti di alto livello, più che a dati di basso livello. Per esempio, una lista di controllo degli accessi può essere usata per permettere o vietare l'accesso in scrittura ad un particolare file di sistema, ma non può stabilire come quel file può essere cambiato. In un sistema basato su RBAC, un'operazione può essere definita a livello molto più dettagliato: ad esempio, può esistere l'operazione di creazione di un account di credito in un'applicazione bancaria oppure l'aggiunta di un esame del livello degli zuccheri nel sangue in un software medico. L'assegnazione del permesso di svolgere una particolare operazione è molto importante, in quanto ogni operazione ha un proprio significato all'interno dell'applicazione. Il RBAC ha dimostrato di essere particolarmente adatto nei requisiti di separazione dei compiti (in inglese, SoD, Separation of Duties), che assicurano che debbano essere coinvolte due o più persone nell'autorizzazione di operazioni critiche. Sono state individuate le condizioni necessarie e sufficienti per la corretta SoD in un sistema RBAC. Un principio sottinteso della SoD è quello che nessun individuo dovrebbe essere in grado di provocare una violazione della sicurezza attraverso un privilegio duale. Per estensione, nessuna persona dovrebbe coprire un ruolo che controlla e verifica l'operato di un altro ruolo che sta ricoprendo, ovvero non può essere supervisore di sé stesso.^[11][12]

Nel Discretionary Access Control (DAC) un utente può permettere o meno l'accesso a ciò che possiede ad altri soggetti (identificati singolarmente o dal gruppo di cui fanno parte) a propria discrezione. Il controllo è discrezionale nel senso che un soggetto con certi permessi di accesso può passare tali permessi (anche indirettamente) a qualsiasi altro soggetto, senza l'intermediazione di un amministratore di sistema.

Nel RBAC, al contrario, è l'amministratore della sicurezza ad essere responsabile di far rispettare le politiche di sicurezza: le decisioni sul controllo degli accessi sono determinati dai ruoli dei singoli utenti, che determinano compiti, responsabilità e permessi, che non possono essere trasferiti ad altri soggetti su decisione del singolo utente. Questa caratteristica rappresenta la differenza fondamentale tra DAC e RBAC.^[1]

Il RBAC può essere visto come una forma di Mandatory Access Control (MAC), benché non sia basato su requisiti di sicurezza multi-livello. Inoltre, il RBAC è più orientato all'accesso a funzioni ed informazioni che non strettamente all'accesso delle informazioni. Infatti, la politica MAC usata in ambito militare si basa sul rispetto di un solo tipo di permesso: "chi può leggere cosa". Per questi sistemi, il problema principale è rappresentato da un eventuale flusso di informazioni non autorizzato dai livelli più alti a quelli più bassi. Così i vincoli su lettura e scrittura supportano questa regola. Ma in un sistema RBAC, il principale problema è la protezione dell'integrità delle informazioni, ovvero si concentra su "chi può fare cosa su cosa".^[1]

Un'opzione alternativa al modello RBAC è il modello basato sulle liste di controllo degli accessi. Un "modello minimale RBAC" (RBACm in sigla) può essere confrontato con un meccanismo delle ACL basato sui gruppi (ACLg in sigla), dove solo i gruppi possono essere registrati nelle ACL. Barkley (1997)^[13] ha dimostrato che RBACm e ACLg sono equivalenti.

Nelle ultime implementazioni SQL, come le ACL per il framework CakePHP, le ACL gestiscono sia i gruppi che l'ereditarietà nella gerarchia dei gruppi. Quindi, particolari implementazioni di "ACL moderne" possono essere confrontate con particolari implementazioni di "RBAC moderni", più correttamente rispetto al confronto tra RBAC e implementazioni di "vecchi file system".

Per lo scambio di dati, e per confronti di alto livello, le informazioni delle ACL possono essere tradotte in XACML.

L'Attribute-Based Access Control (acronimo: ABAC) è un'evoluzione del RBAC, che considera attributi addizionali in aggiunta ai ruoli ed ai gruppi. Nell'ABAC, è possibile usare attributi per:

• l'utente, come ad esempio la cittadinanza, l'autorizzazione;
• la risorsa, come ad esempio la classificazione, il dipartimento, il proprietario;
• l'azione;
• il contesto, come ad esempio l'ora, il luogo, l'indirizzo IP.

L'ABAC è basato su politiche, nel senso che usa politiche dinamiche rispetto a permessi statici per definire cosa è permesso e cosa no.

L'uso del RBAC per gestire i privilegi utente (e i permessi su un computer) all'interno di un singolo sistema o applicazione è largamente accettata come la tecnica migliore. Un report del 2010 preparato dal Reasearch Triangle Institute per il NIST ha analizzato il valore economico del RBAC per le imprese ed ha stimato i benefici per impiegato, espressi come minori tempi morti ed una più efficiente amministrazione della politica del controllo degli accessi.^[14]

In un'organizzazione con infrastrutture informatiche eterogenee e requisiti che coprono decine o centinaia di sistemi ed applicazioni, usare il RBAC per gestire ruoli sufficienti ed assegnare gli utenti a ruoli adeguati diventa estremamente complesso senza la creazione gerarchica di ruoli ed assegnazione di permessi.^[15] I sistemi più recenti estendono il vecchio modello RBAC del NIST^[16] per rivolgersi alle limitazioni del RBAC delle distribuzioni per le grandi imprese. Il modello del NIST è stata adottato come standard dall'INCITS come ANSI/INCITS 359-2004. Inoltre, è stata pubblicata una discussione su alcune scelte di design per il modello NIST.^[17]

• David F. Ferraiolo; D. Richard Kuhn; Ramaswamy Chandramouli (2007). Role-based Access Control (2nd ed.). Artech House.

• Lista di controllo degli accessi
• Discretionary Access Control
• Mandatory Access Control
• Capability
• PERMIS
• XACML

• FAQ on RBAC models and standards
• Role Based Access Controls at NIST
• XACML core and hierarchical role based access control profile
• Practical experiences in implementing RBAC Archiviato il 24 luglio 2011 in Internet Archive.
• Role-based approach to Active Directory delegation