Come progettare il controllo degli accessi basato sui ruoli?

Question

Come progettare il controllo degli accessi basato sui ruoli?

#1 da (4 voti)
#2 da (4 voti)

11

Sto cercando di seguire il ruolo di base del modello di controllo dell'accesso per limitare ciò che gli utenti possono o non possono fare nel mio sistema.

Finora ho le seguenti entità:

utenti : persone che utilizzeranno il sistema. Qui ho username e password. ruoli - Raccolta di ruoli che gli utenti possono avere. Roba come manager, amministratore, ecc. risorse : elementi che gli utenti possono manipolare. Come i contratti, gli utenti, le bozze di contratto, ecc. operazioni : cose che gli utenti possono fare con le risorse. Come creare, leggere, aggiornare o eliminare.

Ora, il mio dubbio sorge qui nel diagramma in cui ho una relazione come questa:

operazioni (0 .. *) vengono eseguite su risorse (0 .. *) che genera una tabella che ho chiamato permessi e che memorizzerà l'operazione e la risorsa .

La tabella delle autorizzazioni sarà simile a questa (una riga di esso): ID: 1, operazione: crea, risorsa: contratto.

Che significa permesso per creare un contratto .

L'ho fatto in questo modo perché ritengo che alcune risorse potrebbero non avere tutti i tipi di operazioni. Ad esempio, per la registrazione di contratti , gli utenti possono caricare file , ma questa operazione non è disponibile per la registrazione di un provider .

Quindi ora quando l'amministratore assegnerà le autorizzazioni a un ruolo , non disporrà di un elenco di risorse con ogni singola operazione registrata in il sistema.

Penso che ciascuna risorsa abbia una propria raccolta di operazioni che può essere eseguita su di lui.

Posso chiarire se qualcosa non è comprensibile.

È questo il modo corretto di implementare rbac?

Modifica

Ciò che intendo è che avendo una autorizzazione tabella che ha operazione e risorsa , ho DUE tabelle extra perché voglio associarla risorse con operazioni . Avrei anche potuto fare solo risorse avere permessi dove la tabella delle autorizzazioni memorizzerebbe le autorizzazioni.

Ma poi quello che sarebbe successo è che alcune autorizzazioni che non esistono nemmeno per alcune risorse sarebbero apparse quando l'amministratore le avrebbe assegnate.

Quindi voglio sapere da un punto di vista della progettazione del database se questa autorizzazione di tabella che ha un'operazione di una colonna e un'altra risorsa è corretta? Mi imbatterò in problemi se rimane così?

database-design permissions authorization access-control roles

posta imran.razak 09.05.2017 - 21:05

fonte

2 risposte

4

Non vorrei usare o implementare RBAC. Invece vorrei usare ABAC. Lasciami spiegare ...

Il controllo degli accessi basato sul ruolo o RBAC riguarda la gestione degli utenti e l'assegnazione dei ruoli. In RBAC, si arriva a dire che Alice è un manager. È possibile definire autorizzazioni statiche insieme a quello. Ad esempio, un manager può approvare prestiti. Quindi c'è un collegamento da Alice a manager per approvareLoan come permesso. Ci sono molti sistemi che ti permetteranno di farlo in modo da non dover implementare i tuoi tavoli. Anche LDAP ha il supporto per serie limitate di RBAC. Questo è OK finché hai un set relativamente piccolo di ruoli e permessi. Ma se si desidera prendere in considerazione autorizzazioni specifiche come è il tuo caso? Visualizza, cancella, inserisci? Cosa succede se si desidera prendere in considerazione le relazioni?
ABAC o controllo degli accessi basato sugli attributi riguarda l'autorizzazione basata su policy e ben definita. Con ABAC è possibile utilizzare i ruoli definiti in RBAC e scrivere le politiche, ad es.
- I manager possono visualizzare i documenti nel loro dipartimento
- I dipendenti possono modificare i documenti di loro proprietà

Nella tua domanda, hai sostanzialmente definito il modello di informazioni. I tuoi oggetti e i loro attributi, ad es. un utente (nome, password, dipartimento ...); un oggetto (ad esempio un contratto) e così via.

InABAC,sidisaccoppieràquindicompletamenteilcodice/logicadellapropriaappdallalogicadiautorizzazionecheverràquindimemorizzatacomecriterioutilizzandogliattributi.Leautorizzazionistessesonomemorizzatedirettamentenelcriterio(vediesempiosopra).L'architetturadiimplementazioneABACèsimileallaseguente

Il punto è che se si segue un approccio ABAC, si scrivono politiche per ABAC (in XACML o ALFA - ci sono molti strumenti per questo) e non si deve mai creare codice personalizzato o RBAC personalizzato o controllo di accesso ancora una volta.

risposta data 10.05.2017 - 22:57

fonte

Leggi altre domande sui tag database-design permissions authorization access-control roles

Strategie di promozione delle dipendenze: silenziate o orchestrate? Utilizzo del mio codice in progetti freelance

score 4 · Accepted Answer

Il tuo design mi sembra molto vicino. Solo un paio di suggerimenti.

users - People who will use the system. Here I have usernames and passwords.

fine

roles - Collection of roles that users can have. Stuff like manager, admin, etc.

Anche bene. Ma avrai anche bisogno di un'entità / tabella "UserRoles" che ti indicherà quali utenti hanno quali ruoli. È probabile che un determinato utente abbia due o più ruoli.

resources - Things that users can manipulate. Like contracts, users, contract drafts, etc.

Potrebbe essere solo una questione di semantica. Non penso che gli utenti manipolino direttamente le risorse; i ruoli lo fanno Così va utente - > ruolo utente - > ruolo - > operazione - > risorsa

operations - Things that users can do with the resources. Like create, read, update or delete.

sì, tranne "ruoli" anziché "utenti"

The permissions table will look like this (one row of it): ID: 1, operation: create, resource: contract. Which means a permission to create a contract.

Hmmm. Ci sono due modi per farlo. Potresti avere la tabella delle autorizzazioni che descrivi, ma avresti anche bisogno di un ulteriore RolePermissions table / entity che ti indichi quale ruolo ha quale permesso. Ma non sono sicuro che sia necessario.

Un modo più semplice per farlo è una tabella / entità delle autorizzazioni con queste colonne / attributi: ID ruolo, ID operazione, ID risorsa. In questo modo, le operazioni x le combinazioni di risorse vengono assegnate direttamente a un ruolo, anziché caricate in un'autorizzazione assegnata a un ruolo. Elimina un'entità. Non c'è davvero bisogno di una tabella dei permessi indipendenti dai ruoli indipendenti, a meno che tu non voglia predefinire quali combinazioni di permessi sono consentite e quali no.