RBAC e ABAC: I modelli di controllo accesso che dovresti conoscere

Introduzione#

Controllo accessi è un aspetto critico della sicurezza in qualsiasi sistema. Garantisce che solo gli utenti autorizzati possano accedere alle risorse ed eseguire azioni. Il controllo accessi basato sui ruoli (RBAC) e il controllo accessi basato su attributi (ABAC) sono due dei modelli di controllo accessi più popolari utilizzati nei sistemi moderni. Entrambi i modelli sono ampiamente adottati e possono essere utilizzati per imporre efficacemente le politiche di controllo accessi. Ma cosa sono e come si distinguono?

Controllo accessi basato sui ruoli (RBAC)#

Il controllo accessi basato sui ruoli (RBAC) è stato introdotto per la prima volta nei primi anni '90. La formalizzazione del modello è attribuita a David Ferraiolo e Rick Kuhn in un articolo pubblicato nel 1992. Da allora, RBAC è diventato uno dei modelli di controllo accessi più ampiamente utilizzati nell'industria.

In RBAC, le politiche di controllo accessi sono basate sui ruoli, che sono collezioni di permessi. Gli utenti vengono assegnati ai ruoli (ad esempio, amministratore, editor, spettatore) e i loro diritti di accesso sono determinati dai permessi (ad esempio, creare, modificare, eliminare) per risorse specifiche (ad esempio, file, database, applicazioni). Semplifica la gestione delle politiche di controllo accessi raggruppando gli utenti in base ai loro ruoli e assegnando permessi ai ruoli. È facile aggiungere o rimuovere utenti dai ruoli, e le modifiche verranno automaticamente riflesse nelle politiche di controllo accessi.

Componenti chiave di RBAC#

• Risorsa: Una risorsa è un'entità a cui un utente può accedere. Le risorse possono essere qualsiasi cosa, da file, database, API, o qualsiasi altra entità di sistema che necessita di essere protetta.
• Permesso: Un permesso è un'azione specifica che un utente può eseguire su una risorsa. Ad esempio, creare, modificare, eliminare, visualizzare. La definizione dei permessi può variare a seconda del sistema. Nella maggior parte dei casi, i permessi sono definiti al livello della risorsa con una granularità minima.
• Ruolo: Un ruolo è una collezione di permessi che definiscono un insieme di azioni che un utente può eseguire. Ad esempio, un ruolo amministratore può avere permessi per creare, modificare e eliminare risorse, mentre un ruolo spettatore può avere il permesso di visualizzare le risorse.
• Utente: Un utente è un'entità che può essere assegnata a uno o più ruoli. Gli utenti hanno accesso alle risorse in base ai permessi associati ai ruoli a cui sono assegnati.

Varianti di RBAC#

Ci sono diverse varianti di RBAC che estendono il modello di base per soddisfare requisiti di controllo accessi più complessi:

• RBAC0: Il modello di base in cui agli utenti vengono assegnati ruoli e ai ruoli vengono assegnati permessi.
• RBAC1: Aggiunge il concetto di gerarchie di ruoli. I ruoli possono ereditare permessi da altri ruoli. È anche noto come RBAC gerarchico.
• RBAC2: Aggiunge vincoli ai ruoli. I vincoli possono essere utilizzati per definire condizioni aggiuntive che devono essere soddisfatte per assegnare un ruolo a un utente. È anche noto come RBAC basato su vincoli.
• RBAC3: Combina le caratteristiche di RBAC1 e RBAC2. Supporta sia gerarchie di ruoli che vincoli.

Per ulteriori informazioni su queste varianti, consulta modelli RBAC e la loro evoluzione.

Pro di RBAC#

• Semplicità: RBAC è facile da capire e implementare. Assegnare permessi ai ruoli e ruoli agli utenti è semplice.
• Efficienza: Semplifica la gestione delle politiche di controllo accessi raggruppando gli utenti in base ai loro ruoli. È facile aggiungere o rimuovere utenti dai ruoli senza cambiare le politiche di controllo accessi. Soprattutto nelle grandi organizzazioni con strutture di permessi ben definite, RBAC può essere molto efficiente.
• Trasparenza: RBAC fornisce una chiara mappatura tra ruoli, permessi e utenti. È facile controllare e rivedere le politiche di controllo accessi.

Contro di RBAC#

• Rigidità: RBAC può essere rigido quando si tratta di definire politiche di controllo accessi complesse. Potrebbe non essere adatto per sistemi in cui le politiche di controllo accessi devono essere più dinamiche e consapevoli del contesto.
• Granularità: RBAC potrebbe mancare della granularità richiesta per il controllo accessi fine-grained. Le politiche di controllo accessi sono legate a ruoli ben definiti e potrebbe essere richiesto un ulteriore sforzo per definire i permessi a un livello più granulare.
• Esplosione di ruoli: In grandi organizzazioni con strutture di permessi complesse, il numero di ruoli può crescere esponenzialmente, portando a un'esplosione di ruoli. Gestire un gran numero di ruoli può essere impegnativo.

Controllo accessi basato sugli attributi (ABAC)#

Alla fine degli anni 2000, man mano che i sistemi diventavano più complessi e dinamici, sempre più organizzazioni hanno iniziato ad adottare il controllo accessi basato sugli attributi (ABAC) come alternativa a RBAC. Un punto di riferimento nella formalizzazione di ABAC è la pubblicazione della NIST Special Publication 800-162 nel 2014.

ABAC è un modello di controllo accessi più flessibile rispetto a RBAC. È un modello di autorizzazione che definisce politiche di controllo accessi basate sugli attributi dell'utente, della risorsa, dell'azione e dell'ambiente. Consente alle organizzazioni di definire politiche di controllo accessi fine-grained che possono adattarsi a diversi contesti e condizioni.

Componenti chiave di ABAC#

• Soggetto: Un soggetto è un'entità che richiede accesso a una risorsa. Può essere un utente, un dispositivo, un'applicazione o qualsiasi altra entità che necessita di accedere a risorse.
• Risorsa: Proprio come in RBAC, una risorsa è un'entità a cui un soggetto può accedere. Le risorse possono essere file, database, API o qualsiasi altra entità di sistema.
• Azione: Un'azione è un'operazione specifica che un soggetto può eseguire su una risorsa. Può essere creare, leggere, aggiornare, eliminare o qualsiasi altra operazione che necessita di essere controllata.
• Ambiente: L'ambiente è il contesto in cui viene effettuata la richiesta di accesso. Può includere attributi come l'ora del giorno, la posizione, la rete, il dispositivo, ecc.
• Attributo: Un attributo è una caratteristica di un soggetto, risorsa, azione o ambiente. Gli attributi possono essere qualsiasi cosa, dai ruoli degli utenti, dipartimento, posizione, indirizzo IP, tipo di dispositivo, ecc.
• Politica: Una politica è una regola che definisce le condizioni in base alle quali l'accesso è concesso o negato. Le politiche sono definite in base agli attributi.

Pro di ABAC#

• Flessibilità: ABAC può accogliere politiche di controllo accessi complesse basate su più attributi. Consente alle organizzazioni di definire politiche fine-grained che possono adattarsi a diversi contesti e condizioni.
• Dinamico: Le politiche ABAC possono essere dinamiche e consapevoli del contesto. Le decisioni di controllo accessi possono essere prese in base ad attributi in tempo reale come la posizione, l'ora del giorno, il tipo di dispositivo, ecc.
• Granularità: ABAC fornisce un controllo accessi fine-grained permettendo alle organizzazioni di definire politiche basate su più attributi. A differenza della definizione di ruoli e permessi, le politiche basate sugli attributi possono essere più granulari.

Contro di ABAC#

• Complessità: ABAC può essere più complesso da implementare e gestire rispetto a RBAC. Definire attributi e politiche può richiedere più sforzi ed esperienza. A differenza di RBAC, dove i ruoli e i permessi sono ben strutturati, gli attributi possono essere più dinamici e così anche le politiche. Gestire un gran numero di attributi e politiche in un sistema complesso può essere impegnativo. Un motore di valutazione delle politiche centralizzato è spesso necessario per valutare le politiche.
• Prestazioni: La valutazione degli attributi può influire sulle prestazioni, soprattutto in ambienti in tempo reale. Le politiche basate su più attributi e condizioni in tempo reale possono introdurre latenza nelle decisioni di controllo accessi.

Tabella di confronto#

Dalla tabella di confronto, è chiaro che RBAC è più adatto a sistemi con strutture di permessi ben definite e dove le politiche di controllo accessi sono relativamente statiche. D'altra parte, ABAC è più adatto a sistemi in cui le politiche di controllo accessi devono essere dinamiche, consapevoli del contesto e fine-grained.

Esempi#

Scenario: Un sistema ospedaliero che deve gestire l'accesso ai record dei pazienti per diversi membri del personale.

• Staff: Medici, Infermieri, Amministratori
• Risorse: Record dei pazienti
• Permessi: Leggere, Scrivere, Eliminare

Caso 1#

Le politiche di controllo accessi sono relativamente semplici:

1. I medici possono leggere e scrivere i record dei pazienti.
2. Gli infermieri possono leggere i record dei pazienti.
3. Gli amministratori possono leggere, scrivere ed eliminare i record dei pazienti.

Modello RBAC#

In questo caso, RBAC è semplice ed efficace. Possiamo definire ruoli per medici, infermieri e amministratori, e assegnare i permessi appropriati a ciascun ruolo.

La valutazione del controllo accessi è diretta:

• GET /patient-records: user.permission.includes('leggere')
• POST /patient-records: user.permission.includes('scrivere')
• DELETE /patient-records: user.permission.includes('eliminare')

Modello ABAC#

In questo caso, ABAC potrebbe essere eccessivo, ma può ancora essere utilizzato per definire politiche fine-grained basate su attributi come dipartimento, ruolo, ecc.

Attributi:

• user.ruolo: medico, infermiera, admin
• resource.name: record-paziente
• azione: leggere, scrivere, eliminare

Politiche:

• Politica 1: Consentire l'accesso in lettura basato su user.ruolo e resource.name
  • subject: Utente con ruolo medico, infermiera, admin
  • resource: Risorsa con nome record-paziente
  • azione: leggere
  • effect: consentire
  • rationale: "Consentire l'accesso in lettura ai record dei pazienti per tutti i ruoli"
• Politica 2: Accesso modifica per medici e admin
  • subject: Utente con ruolo medico, admin
  • resource: Risorsa con nome record-paziente
  • azione: scrivere
  • effect: consentire
  • rationale: "Consentire l'accesso in scrittura ai record dei pazienti per medici e admin"
• Politica 3: Accesso eliminazione per admin
  • subject: Utente con ruolo admin
  • resource: Risorsa con nome record-paziente
  • azione: eliminare
  • effect: consentire
  • rationale: "Consentire l'accesso in eliminazione ai record dei pazienti per admin"

Per ogni richiesta di lettura/scrittura/eliminazione, il motore delle politiche valuta tutte le politiche rilevanti in base agli attributi e prende una decisione di controllo accessi.

Confronto#

In questo caso, le politiche di controllo accessi sono semplici e ben strutturate. Richiede solo un controllo di permesso a livello singolo per determinare se un utente ha accesso a una risorsa. Immagina che il sistema ospedaliero abbia una struttura più complessa con più dipartimenti, ruoli e permessi:

• In un modello RBAC, il processo di valutazione del controllo accessi della risorsa record del paziente rimarrà semplice e diretto, se l'utente ha il permesso leggere, scrivere, o eliminare;
• ABAC, d'altra parte, ha bisogno di coinvolgere attributi aggiuntivi come department-id e doctor-id. E se un dispositivo IoT ha bisogno di accedere ai record dei pazienti? Sarà necessario introdurre un nuovo attributo device-id nella valutazione della politica. Come si potrebbe concedere temporaneamente il permesso leggere a un medico interno?

In conclusione, RBAC è una scelta migliore. RBAC è semplice ed efficiente per sistemi con strutture di permessi ben definite e dove le politiche di controllo accessi sono statiche.

Caso 2#

Lo stesso sistema ospedaliero, ora introdurremo un nuovo ruolo paziente e un nuovo attributo patient-id.

Le politiche di controllo accessi sono:

1. I medici possono leggere e scrivere i record dei pazienti.
2. Gli infermieri possono leggere i record dei pazienti.
3. Gli amministratori possono leggere, scrivere ed eliminare i record dei pazienti.
4. I pazienti possono leggere i propri record.

Modello RBAC#

In questo caso, oltre al vecchio permesso leggere, dobbiamo introdurre un nuovo permesso leggere-proprio. Possiamo definire ruoli per medici, infermieri, amministratori e pazienti, e assegnare i permessi appropriati a ciascun ruolo.

Ora la valutazione del controllo accessi è un po' più complessa, specialmente per l'azione leggere il record del paziente:

• GET /patient-records: user.permission.includes('leggere')
• POST /patient-records: user.permission.includes('scrivere')
• DELETE /patient-records: user.permission.includes('eliminare')
• GET /patient-records/:patient-id: user.permission.includes('leggere-proprio') && user.id === patient-id || user.permission.includes('leggere')

Modello ABAC#

Ora aggiorniamo gli attributi e le politiche nel modello ABAC per soddisfare i nuovi requisiti.

Attributi:

• user.ruolo: medico, infermiera, admin, paziente
• user.id: patient-id
• resource.name: record-paziente
• resource.patient-id: patient-id
• azione: leggere, scrivere, eliminare

Politiche:

• Politica 1: Consentire l'accesso in lettura a tutti i record dei pazienti
  • subject: Utente con ruolo medico, infermiera, admin
  • resource: Risorsa con nome record-paziente
  • azione: leggere
  • effect: consentire
  • rationale: "Consentire l'accesso in lettura ai record dei pazienti per tutto il personale e il paziente stesso"
• Politica 2: Consentire l'accesso in scrittura a tutti i record dei pazienti per medici e admin
  • subject: Utente con ruolo medico, admin
  • resource: Risorsa con nome record-paziente
  • azione: scrivere
  • effect: consentire
  • rationale: "Consentire l'accesso in scrittura ai record dei pazienti per medici e admin"
• Politica 3: Consentire l'accesso in eliminazione a tutti i record dei pazienti per admin
  • subject: Utente con ruolo admin
  • resource: Risorsa con nome record-paziente
  • azione: eliminare
  • effect: consentire
  • rationale: "Consentire l'accesso in eliminazione ai record dei pazienti per admin"
• Politica 4: Consentire l'accesso in lettura ai propri record dei pazienti
  • subject: Utente con ruolo paziente
  • resource: Risorsa con nome record-paziente
  • azione: leggere
  • condizione: user.id === resource.patient-id
  • effect: consentire
  • rationale: "Consentire l'accesso in lettura ai propri record dei pazienti"

Confronto#

In questo caso, le politiche di controllo accessi sono più complesse e consapevoli del contesto. Il processo di valutazione del controllo accessi della risorsa record del paziente richiederà più livelli di controlli di permesso per determinare se un utente ha accesso a una risorsa.

• In un modello RBAC, il processo di valutazione del controllo accessi della risorsa record del paziente richiederà più livelli di controlli di permesso per determinare se un utente ha accesso a una risorsa. Ad esempio, per determinare se un paziente ha accesso ai propri record, il sistema deve verificare se l'utente ha il permesso leggere-proprio e se l'ID utente corrisponde all'id del paziente.
• In un modello ABAC, il processo di valutazione del controllo accessi può essere più diretto. Le politiche possono essere definite in base agli attributi dell'utente, della risorsa, e dell'azione. Ad esempio, per determinare se un paziente ha accesso ai propri record, il motore delle politiche può valutare la politica in base all'ID utente e all'ID del paziente.

In questo caso, ABAC potrebbe essere una scelta migliore. ABAC è più adatto a sistemi in cui le politiche di controllo accessi devono essere dinamiche, consapevoli del contesto e fine-grained.

Conclusione#

La scelta tra RBAC e ABAC dipende dai requisiti specifici del sistema. RBAC è più adatto a sistemi con strutture di permessi ben definite e dove le politiche di controllo accessi sono statiche. ABAC è più adatto a sistemi in cui le politiche di controllo accessi devono essere dinamiche, consapevoli del contesto e fine-grained. Nella pratica, le organizzazioni possono scegliere di utilizzare una combinazione di entrambi i modelli per raggiungere il livello desiderato di controllo accessi.