Domanda:
Qual è la differenza tra RBAC e DAC / ACL?
AviD
2010-11-15 01:27:09 UTC
view on stackexchange narkive permalink

Quali sono i vantaggi di ciascuno e quando dovrei sceglierne uno rispetto all'altro? Ci sono situazioni in cui questi dovrebbero essere uniti?

Hai esempi di usi comuni?

E per quanto riguarda il MAC, dove si inserisce?

Una risposta:
#1
+88
AviD
2010-11-15 01:42:02 UTC
view on stackexchange narkive permalink

RBAC (controllo dell'accesso basato sui ruoli) si basa sulla definizione di un elenco di ruoli aziendali e sull'aggiunta di ogni utente nel sistema a uno o più ruoli. Le autorizzazioni e i privilegi vengono quindi concessi a ciascun ruolo e gli utenti li ricevono tramite la loro appartenenza al ruolo (praticamente equivalente a un gruppo). Le applicazioni in genere testano l'utente per l'appartenenza a un ruolo specifico e concedono o negano l'accesso in base a questo.
Discretionary Access Control (DAC) consente a un utente o amministratore di definire un elenco di controllo di accesso (ACL) su una risorsa specifica ( es. file, chiave di registro, tabella di database, oggetto del sistema operativo, ecc.), questo elenco conterrà voci (ACE) che definiscono ogni utente che ha accesso alla risorsa e quali sono i suoi privilegi per quella risorsa.

Il vantaggio principale di RBAC rispetto a DAC è la facilità di gestione: in linea di principio hai pochissimi ruoli, amministrati centralmente, indipendentemente dal numero di utenti, ed è solo questione di concedere a ciascun utente il ruolo corretto ; a differenza di DAC, dove per ogni nuovo utente (o cambio di utente, eliminazione, ecc.), devi andare in giro per tutte le risorse a cui ha bisogno di accedere e aggiungerle all'elenco.
D'altra parte, DAC è spesso più semplice e generalmente più granulare. Inoltre, nel modello DAC il proprietario dei dati può decidere chi ha accesso (se dispone di tale autorizzazione sui dati) e aggiungere o rimuovere persone dall'elenco.

Un esempio molto comune di DAC è il file system di Windows. D'altra parte, un esempio molto comune di RBAC è il DAC sui file server aziendali: chiunque nel gruppo ActiveDirectory "Sales" avrà accesso alla cartella \ Sales \ shared. Più comunemente è il gruppo Administrators in Windows.

MAC è il controllo di accesso obbligatorio, può essere visto come una classificazione o un livello di privacy. Questo è più spesso utilizzato nei sistemi militari e ai tempi del mainframe :). Non molto usato più, anche se gli attuali sistemi operativi stanno implementando un sapore di questo, come i livelli di integrità di Vista / Win7.

Per riassumere le differenze:

  • DAC si basa su autorizzazioni personali, RBAC su autorizzazioni di livello "gruppo"
  • DAC è impostato dal proprietario dei dati, RBAC dal proprietario / i del sistema (di solito lo sviluppatore definisce l'accesso dato a ciascuno ruolo e l'amministratore operativo inserisce gli utenti nei ruoli)
  • Le definizioni DAC sono generalmente allegate ai dati / risorsa, mentre RBAC è solitamente definito in due posizioni: in codice / configurazione / metadati (l'accesso ai ruoli), e sull'oggetto utente (o tabella - i ruoli che ogni utente ha).
  • D'altra parte, i ruoli RBAC sono amministrati centralmente (chi è associato a quali ruoli), mentre DAC è amministrato "sulla risorsa" (cioè si amministra ogni risorsa individualmente).
  • La definizione delle autorizzazioni per ruolo è in genere statica in RBAC e agli utenti vengono concessi solo ruoli; in DAC le autorizzazioni per risorsa vengono spesso modificate in fase di esecuzione.
  • DAC dovrebbe essere visto come un'enumerazione "chi ha accesso ai miei dati" e RBAC definisce "cosa può fare questo utente".
Da quello che ho capito di RBAC è che non ci sono oggetti, solo azioni che possono essere eseguite.
@sims sì, anche questo è vero. RBAC non si riferisce a elementi di dati specifici, ma solo "cosa può fare questo ruolo".
Anche in RBAC c'è il concetto di sessione: i ruoli che hai attualmente sono legati alla tua sessione di accesso. (Ad esempio: puoi essere sia un amministratore che un utente normale, ma non entrambi contemporaneamente, la tua sessione indica quale ruolo / i hai attualmente)
@RolfRander sebbene questo sia comune in molte implementazioni, non è inerente al modello.
@AviD ok, in realtà ho pensato che fosse il contrario, che fosse una parte centrale del modello ma non ampiamente implementato. Ma non ho alcuna esperienza con i prodotti tipici, l'ho letto solo qui: https://blogs.oracle.com/identitythink/entry/whats_wrong_with_the_nist_rbac
Potrebbe essere carino notare che RBAC e ACL possono sostituirsi a vicenda; è possibile configurare le autorizzazioni RBAC per coprire i criteri stabiliti da ACL e viceversa. Inoltre, ci sono alcune implementazioni di RBAC là fuori che concedono poteri discrezionali agli utenti. Questi sistemi RBAC hanno dimostrato di essere in grado di offrire tutte le funzionalità del DAC.
Potrebbe anche essere carino notare che in RBAC non ci sono permessi negativi (negare). Sebbene alcune implementazioni li forniscano, le autorizzazioni negative sono generalmente associate a ACL / DAC e non a RBAC.
@Jacco Sono d'accordo con il tuo primo commento (anche se di solito è complesso e non ben implementato), ma non sono d'accordo con il tuo secondo. Sebbene non integrato e spesso complesso, RBAC * può essere * (ed è stato) utilizzato per SoD (separazione dei compiti), ad es. bloccare una determinata azione se ricopri anche un altro ruolo. Non lo consiglio necessariamente, ma è possibile.
@AviD, Suppongo che stiamo parlando della stessa cosa, SoD è sicuramente parte dei modelli RBAC (più complessi) (incluso lo standard NIST). Ma, per quanto ne so, SoD è implementato come un costruttivo "Le autorizzazioni in conflitto non possono essere incluse nello stesso ruolo, ecc." Invece delle autorizzazioni negative "Consenti a TUTTI + Nega DELETE" set di autorizzazioni di tipo. (Sebbene alcune implementazioni RBAC includano anche quest'ultimo)
@AviD, suggerisce di aggiungere MAC al riepilogo poiché l'accesso alle risorse di sistema non può essere controllato dall'utente
Per autorizzazioni negative e autorizzazioni più dettagliate sulle risorse, utilizzare il controllo degli accessi basato sugli attributi (ABAC)
Questo suona come se fossero aggiunti dei gruppi.Correggimi se sbaglio, ma penso che i ruoli debbano essere indipendenti dai gruppi di utenti.Ad esempio, un ruolo può essere un insieme di azioni che possono essere applicate da un utente / gruppo su un elenco di oggetti.Pertanto, il ruolo è indipendente sia dall'oggetto che dall'utente.Ciò consente di specificare un utente / gruppo per poter eseguire backup (ruolo di backup) su un database, ma non su un altro.
I gruppi @rfportilla sono un'implementazione comune dei ruoli, specialmente quando si utilizza una piattaforma di directory utente (ad esempio ActiveDirectory).E questi possono essere nidificati, quindi anche l'aggiunta di un gruppo a un ruolo (o un gruppo a un gruppo) funziona.
Certo, AviD.Voglio solo essere chiaro che lo scopo non è raggruppare utenti o oggetti, ma raggruppare attività.Il solo raggruppamento degli utenti non è realmente RBAC, vero?
Bene, assegneresti gli utenti ai ruoli (inserirli in gruppi) e quindi concedere le autorizzazioni ai ruoli.A rigor di termini, un ruolo non raggruppa nemmeno i compiti - ci sono altri modelli per questo, sebbene spesso i sistemi implementeranno questo tipo di "RBAC espanso", e io sono a favore di quello (come lo chiami, ma la chiarezza è importante in quantobene).
@AviD potresti individuare la differenza tra autorizzazioni e privilegi?
Penso che sia principalmente una questione di nomenclatura, ma spesso i "permessi" vengono utilizzati su un oggetto dati specifico, mentre i privilegi sono più a livello di sistema.Ma questa potrebbe essere la mia visione soggettiva.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...