A ogni utente una chiave per aprire le porte che conducono ai dati a cui può accedere. Questo è in sintesi il Role-Based Access Control (RBAC) definito con una frase.
RBAC sovrascrive il modello non più attuale secondo cui gli amministratori di sistema, usando profili utente con privilegi elevati, sono in grado di accedere ai server dell’azienda e quindi a tutti i file (database inclusi) e alle interfacce per la creazione e la gestione di policy, dispositivi e i profili di ogni singolo dipendente dell’azienda.
Se anche uno solo degli account con diritti amministrativi venisse hackerato, i danni potrebbero estendersi a cascata su tutta l’organizzazione.
Ed è soprattutto nelle realtà aziendali più grandi e complesse che il RBAC trova una propria dimensione.
Indice degli argomenti
Cosa è il Role-Based Access Control
Il RBAC sposa la logica dei ruoli e non quella dei singoli oggetti. Quindi, per quanto riguarda i profili utente, questi non vengono più considerati singolarmente ma come parti integranti di un ruolo.
È da considerare una base solida su cui fare appoggiare la gestione delle identità e il controllo degli accessi.
Di fatto, il RBAC certifica che soltanto gli utenti autorizzati possano accedere a un set di risorse, siano queste dati, applicazioni o persino interi server o database.
Le policy dei ruoli sono configurabili per gestire ogni esigenza, dando accesso in lettura o scrittura a directory e database e consentendo anche un pool specifico di comandi di sistema.
L’implementazione del RBAC è di per sé semplice, assume una propria macchinosità nei contesti basati su Cloud o nel caso in cui un’organizzazione faccia ricorso a piattaforme Software-as-a-Service, peraltro sempre più nelle mire del cyber crimine.
Per soddisfare esigenze orizzontali in modo più fluido, l’implementazione del RBAC si snoda attraverso tre modelli differenti.
I tre modelli di implementazione RBAC
Si tratta di tre logiche di implementazione che consentono una strutturazione dei ruoli il più possibile lineare a seconda del numero di utenti e delle necessità specifiche delle diverse imprese e organizzazioni.
- Flat RBAC: è lo schema più semplice ed è indicato soprattutto per quelle organizzazioni non troppo grandi che non hanno un’ampia varietà di logiche di accesso.
- Hierarchical RBAC:in questo modello i ruoli sono organizzati secondo logiche gerarchiche. Così, per esempio, ai dipendenti del dipartimento contabile vengono assegnati dei permessi e questi vengono ereditati in toto da chi lavora nell’ambito del controllo di gruppo, unitamente ai permessi specifici che questo ruolo prevede.
- Constrained RBAC:è la logica di implementazione più complicata ed è pensata per le grandi organizzazioni nelle quali è necessaria la definizione di tanti ruoli. L’idea è quella di fare in modo che nessun utente abbia accesso a tutte le fasi di un processo business critical. Nasce quindi l’esigenza di ingegnerizzare i ruoli in modo certosino, evitando anche conflitti tra i ruoli stessi. Per fare un esempio, sempre restando nei meandri della contabilità aziendale, il dipendente che controlla e autorizza il pagamento delle fatture passive non può avere i diritti per procedere alla disposizione dei bonifici.
Il modello Constrained risponde anche a specifici requisiti di ordine legale e di compliance tipici delle aziende più grandi e che operano in diversi Stati o continenti.
Il discorso dei benefici e dei limiti è ampio e può essere contestualizzato nel suo insieme soltanto all’interno dei flussi e dei processi delle aziende che decidono di implementare delle politiche RBAC. Possiamo però trattarli per sommi capi.
I benefici del RBAC
Un’analisi del National Institute of Standards and Technology (NIST) fatta nel 2002 colloca l’RBAC tra le migliori soluzioni per le grandi infrastrutture di rete con necessità complesse di accesso e gestione dei privilegi degli utenti.
Su esplicita richiesta del NIST, nel 2010, è stato allestito un report che stima i benefici economici del RBAC per ogni singolo utente, oltre a mettere in risalto la maggiore agilità con cui i sistemisti possono gestire i permessi, ricorrendo di fatto al principio “last privilege” (minimo privilegio) con il quale gli utenti gli hanno accesso soltanto alle risorse indispensabili allo svolgimento delle rispettive attività professionali.
Ci sono anche benefici meno evidenti:
- Conformità e auditing: RBAC facilita il rispetto delle norme vigenti in materia di sicurezza e privacy giacché consente di tracciare a quali file hanno avuto accesso gli utenti
- Scalabilità e flessibilità: RBAC si adatta a organizzazioni di qualsiasi dimensione e può essere implementato e modificato al fine di rispondere alle necessità delle imprese.
Il modello RBAC proposto dal NIST già durante gli anni Novanta è con il tempo evoluto nello standard ANSI/INCITS 359-2004.
RBAC in pratica
Il web è densamente popolato di soluzioni RBAC. Solarwinds, per esempio, consente di provare gratuitamente per 30 giorni il software che propone.
Tra le soluzioni Open source più interessanti figura Casbin, una libreria dedicata alla gestione dei controlli che offre la possibilità di implementare autorizzazioni RBAC e che supporta diversi linguaggi di programmazione, tra i quali C++, Java, Python e PHP.
Inoltre, tra i servizi offerti da Microsoft Azure, figurano anche gli strumenti per la gestione delle risorse. Il sistema RBAC di Microsoft include dei ruoli predefiniti (owner, contributor oppure reader) che hanno diversi diritti di accesso e di gestione delle risorse e consente di creare ruoli personalizzati affinché vengano coperte tutte le necessità dell’organizzazione.
A prescindere dalla soluzione scelta e implementata, ciò che occorre tenere presente che la parola d’ordine è flessibilità, poiché i sistemi RBAC devono potersi adattare a diversi scenari, e a diverse piattaforme. Scalabilità e personalizzazione diventano quindi inalienabili.
