Indietro

ⓘ Role-based access control




Role-based access control
                                     

ⓘ Role-based access control

Nella sicurezza informatica, il role-based access control è una tecnica di accesso a sistemi ristretto per utenti autorizzati. È una più recente alternativa al mandatory access control e al discretionary access control.

Si tratta di un meccanismo di accesso definito basandosi sui concetti di ruolo e privilegio. I componenti del RBAC, come i permessi dei ruoli, il ruolo utente le relazioni ruolo-ruolo, fanno in modo di semplificare lassegnamento dei ruoli 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.

                                     

1. Design

Allinterno di una organizzazione, i ruoli sono creati per diverse funzioni di lavoro. I permessi per 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 agli utenti ma vengono acquisiti solo tramite il ruolo o i ruoli ad essi assegnati, la gestione dei diritti individuali per un utente diventa una semplice assegnazione dei ruoli appropriati per lutente stesso. Questo semplifica le operazioni comuni, come laggiunta di un utente o il cambio di dipartimento.

Tre regole fondamentali sono definite per il modello RBAC:

  • Assegnazione dei ruoli: un soggetto può eseguire una transazione solo se il soggetto ha selezionato o è stato assegnato ad un ruolo.
  • 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.
  • 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 lutente 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:

  • SE = Sessione = un collegamento che coinvolge S, R e/o P;
  • SA = Assegnazione al soggetto;
  • 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.
  • PA = Assegnazione di permesso;
  • R = Ruolo = funzione di lavoro o titolo che definisce un livello di autorità;
  • S = Soggetto = una persona o un agente automatico;
  • P = Permessi = approvazione della modalità di accesso alla risorsa;

Inoltre, si seguono le seguenti regole:

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

Un vincolo crea anche una regola restrittiva sulla potenziale eredità di permessi da ruoli antitetici e perciò può essere usato per raggiungere unappropriata 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:

  • P A ⊆ P × R {\displaystyle PA\subseteq P\times R}: è una relazione molti a molti tra i permessi e i ruoli;
  • S A ⊆ S × R {\displaystyle SA\subseteq S\times R}: è una relazione molti a molti tra i soggetti e i ruoli;
  • R H ⊆ R × R {\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.

                                     

2. Relazione del RBAC con altri modelli

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

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 dellaccesso: 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. 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, 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, è capace di assicurare istanze di dati considerando la loro associazione con il soggetto che sta eseguendo.

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 laccesso in scrittura ad un particolare file di sistema, ma non può stabilire come quel file può essere cambiato. In un sistema basato su RBAC, unoperazione può essere definita a livello molto più dettagliato: ad esempio, può esistere loperazione di creazione di un account di credito in unapplicazione bancaria oppure laggiunta di un esame del livello degli zuccheri nel sangue in un software medico. Lassegnamento del permesso di svolgere una particolare operazione è molto importante, in quanto ogni operazione ha un proprio significato allinterno dellapplicazione. Il RBAC ha dimostrato di essere particolarmente adatto nei requisiti di separazione dei compiti, che assicurano che debbano essere coinvolte due o più persone nellautorizzazione 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 loperato di un altro ruolo che sta ricoprendo, ovvero non può essere supervisore di sé stesso.

                                     

2.1. Relazione del RBAC con altri modelli Confronto con il Discretionary Access Control DAC

Nel Discretionary Access Control DAC un utente può permettere o meno laccesso 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 lintermediazione di un amministratore di sistema.

Nel RBAC, al contrario, è lamministratore 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.

                                     

2.2. Relazione del RBAC con altri modelli Confronto con il Mandatory Access Control MAC

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 allaccesso a funzioni ed informazioni che non strettamente allaccesso 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 dellintegrità delle informazioni, ovvero si concentra su "chi può fare cosa su cosa".

                                     

2.3. Relazione del RBAC con altri modelli Confronto con le liste di controllo degli accessi ACL

Unopzione 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 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 lereditarietà 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.

                                     

2.4. Relazione del RBAC con altri modelli Attribute-Based Access Control ABAC

LAttribute-Based Access Control acronimo: ABAC è unevoluzione del RBAC, che considera attributi addizionali in aggiunta ai ruoli ed ai gruppi. NellABAC, è possibile usare attributi per:

  • lutente, come ad esempio la cittadinanza, lautorizzazione;
  • lazione;
  • il contesto, come ad esempio lora, il luogo, lindirizzo IP.
  • la risorsa, come ad esempio la classificazione, il dipartimento, il proprietario;

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

                                     

3. Pregi e difetti

Luso del RBAC per gestire i privilegi utente e i permessi su un computer allinterno di un singolo sistema o applicazione è largamente accettata come la tecnica migliore. Un report del 2010 preparato dal NIST dal Reasearch Triangle Institute ha analizzato il valore economico del RBAC per le imprese ed ha stimato i benefici per impiegato, come un ridotto tempo di inattività ed una più efficiente amministrazione della politica del controllo degli accessi.

In unorganizzazione 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 assegnamento di permessi. I sistemi più recenti estendono il vecchio modello RBAC del NIST per rivolgersi alle limitazioni del RBAC delle distribuzioni per le grandi imprese. Il modello del NIST è stata adottato come standard dallINCITS come ANSI/INCITS 359-2004. Inoltre, è stata pubblicata una discussione su alcune scelte di design per il modello NIST.