Lo svantaggio principale dell'RBAC è quello che viene più spesso chiamato "esplosione di ruolo": a causa del crescente numero di ruoli (nel mondo reale) diversi (a volte le differenze sono molto minori) è necessario un numero crescente di ruoli (RBAC) incapsulare correttamente le autorizzazioni (un'autorizzazione in RBAC è un'azione / operazione su un oggetto / entità). Gestire tutti questi ruoli può diventare un affare complesso.

A causa delle scelte di astrazione che costituiscono le fondamenta di RBAC, non è anche molto adatto per gestire i diritti individuali, ma in genere questo è considerato meno di un problema.

L'alternativa tipicamente proposta è ABAC (Attribute Based Access Control). ABAC non ha ruoli, quindi nessuna esplosione di ruolo. Tuttavia, con ABAC, ottieni ciò che le persone ora chiamano un'esplosione di attributi. I due problemi sono diversi nei dettagli, ma in gran parte gli stessi a un livello più astratto. (Un cinico potrebbe indicare la saturazione del mercato per le soluzioni RBAC e la conseguente necessità di una soluzione di controllo degli accessi "nuova" e "migliore", ma questa è un'altra discussione.)

Ci sono diversi problemi con l'RBAC, ma come dice Jacco, tutto si riduce a esplosioni di ruolo.

RBAC è:

• incentrato sull'identità, ovvero l'identità dell'utente, il ruolo utente e facoltativamente il gruppo di utenti
• generalmente gestito interamente dal team IAM
• admin-time: i ruoli e le autorizzazioni vengono assegnati al momento dell'amministrazione e in tempo reale per la durata per cui sono stati predisposti.

Cosa non va bene con RBAC?

• è a grana grossa. Se hai un ruolo chiamato dottore, allora daresti al medico il permesso di "vedere la cartella clinica". Ciò darebbe al medico il diritto di visualizzare tutte le cartelle cliniche, compresa la propria. Questo è ciò che porta all'esplosione di ruoli
• è statico. RBAC non può utilizzare le informazioni contestuali, ad es. ora, posizione dell'utente, tipo di dispositivo ...
• ignora i metadati delle risorse, ad es. proprietario della cartella clinica.
• è difficile da gestire e mantenere. Molto spesso, gli amministratori continueranno ad aggiungere ruoli agli utenti ma mai a rimuoverli. Finisci con utenti che dozzine se non centinaia di ruoli e permessi
• non può soddisfare la segregazione dinamica del dovere.
• si basa su un codice personalizzato all'interno dei livelli dell'applicazione (API, app, DB ...) per implementare controlli più dettagliati.
• Le recensioni di accesso sono dolorose, soggette a errori e lunghe

ABAC è la soluzione?

ABAC - Controllo dell'accesso basato sugli attributi - è il modo di gestione della prossima generazione di autorizzazione. È guidato da: NIST e OASIS così come le comunità open source (Apache) e i fornitori IAM (Oracle, IBM, Axiomatics ).

ABAC può essere visto come autorizzazione:

• Esternalizzato : il controllo di accesso è esternalizzato dalla logica aziendale
• Centralizzato : i criteri di controllo accessi sono gestiti centralmente
• Standardizzati : le policy di controllo accessi utilizzano XACML, l'eXtensible Access Control Markup Language, lo standard definito da OASIS e implementato dalla maggior parte delle soluzioni ABAC
• Flessibile : ABAC può essere applicato a API, database e altro
• Dinamico : le decisioni di accesso vengono prese dinamicamente in fase di runtime
• Basato sul contesto / Basato sul rischio: ABAC può prendere in considerazione tempo, posizione e altri attributi contestuali quando prende decisioni.

ABAC fornisce:

• un'architettura con la nozione di punto di decisione della politica (PDP) e punto di applicazione della politica (PEP)
• un linguaggio dei criteri (XACML)
• uno schema di richiesta / risposta (JSON / XACML)

Usa lo strumento giusto per il lavoro come si suol dire. RBAC, come qualsiasi modello di controllo accessi, ha i suoi punti deboli. Molti sono ben compresi, anche discussi dal team NIST originale che ha inquadrato il modello.

link

Tuttavia, ci sono state alcune imprecisioni nella risposta di David Brossard. Ad esempio ...

I. It is static. RBAC cannot use contextual information e.g. time, user location, device type...

I vincoli vengono comunemente applicati durante l'attivazione di utenti, ruoli e permessi in RBAC. Ad esempio, ponendo vincoli temporali su un'attivazione di ruolo. Infatti INCITS 494 prescrive il loro uso:

5.4 RBAC Policy Enhanced Constraints

I vincoli avanzati vanno oltre lo standard RBAC INCITS 359 includendo ulteriori tipi di vincoli. I vincoli sui ruoli possono essere statici o dinamici. I vincoli statici vengono applicati off-line prima che il ruolo venga attivato dall'utente. I vincoli dinamici vengono applicati in linea dopo l'attivazione dei ruoli. Questi vincoli dinamici potenziati possono introdurre attributi nell'ambiente RBAC.

INCENSI 494-2012, p. 8

II. It cannot cater to dynamic segregation-of-duty.

L'RBAC supporta i vincoli SoD dinamici. Dalla specifica:

Separazione dinamica delle relazioni di dovere La separazione statica delle relazioni di dovere riduce il numero di potenziali autorizzazioni che possono essere rese disponibili a un utente ponendo vincoli agli utenti che possono essere assegnati a un insieme di ruoli. Le relazioni di separazione dinamica dei compiti (DSD), come le relazioni SSD, hanno lo scopo di limitare le autorizzazioni disponibili per un utente. Tuttavia, le relazioni DSD differiscono dalle relazioni SSD dal contesto in cui sono imposte tali limitazioni. Le relazioni SSD definiscono e posizionano i vincoli sullo spazio di autorizzazione totale di un utente. Questo componente del modello definisce le proprietà DSD che limitano la disponibilità delle autorizzazioni in base all'autorizzazione dell'utente spazio ponendo vincoli sui ruoli che possono essere attivati all'interno o attraverso le sessioni di un utente.

ANSI INCITS 359-2004, p. 10

III. It relies on custom code within application layers (API, apps, DB...) to implement finer-grained controls.

Un po 'confuso da questa affermazione perché in precedenza hai affermato che RBAC è a grana grossa.

Vuoi dire che il codice personalizzato deve essere scritto perché i controlli RBAC non soddisfano adeguatamente i requisiti di sicurezza per l'autorizzazione?

Dove sono le specifiche funzionali pubblicate da ABAC? Dove sono il modello standard (dati) e funzionale (api) per calcolare (e memorizzare) le sue decisioni?

Forse è meglio usare un'implementazione ABAC comprovata e non standard rispetto a un widget app personalizzato? Se è questo che stai dicendo, sono d'accordo, ma nessuno dei due è l'ideale.

ABAC ha il suo posto come RBAC. Sapere quando usare uno, l'altro o entrambi è importante. Comprendere i limiti e i punti di forza di ciascuno è fondamentale prima di affrontare adeguatamente le sfide che affrontiamo come operatori della sicurezza.