it-swarm.it

Modello di database con utenti, ruoli e diritti

Ho un modello di database con una tabella utente e una tabella dei ruoli. Voglio controllare l'accesso (diritti) a un massimo di 10 elementi diversi. L'accesso può essere concesso a un ruolo oa un singolo utente. Di seguito è riportata la definizione della tabella di utenti, ruoli ed elementi:

CREATE TABLE users
(
  id serial NOT NULL PRIMARY KEY,
  username character varying UNIQUE,
  password character varying,
  first_name character varying,
  last_name character varying,
  ...
);

CREATE TABLE roles
(
  id serial NOT NULL PRIMARY KEY,
  name character varying NOT NULL,
  description character varying,
  ...
);

CREATE TABLE element_1
(
  id serial NOT NULL PRIMARY KEY,
  name character varying NOT NULL,
  description character varying,
  ...
);

...

Ora ho due modi diversi di progettare i diritti. Una tabella con una colonna del tipo di diritti o 10 tabelle dei diritti, una per ogni elemento a cui voglio controllare l'accesso.

Quali sono i pro e i contro di una tabella dei diritti rispetto a una tabella dei diritti per elemento? - o è il modo più adatto per farlo?

40
taudorf

Innanzitutto, che tipo di modello di sicurezza prevedi di implementare? Controllo degli accessi in base al ruolo (RBAC) o Controllo dell'accesso discrezionale (DAC)?

RBAC nel modello RBAC (Role-Based Access Control), l'accesso alle risorse si basa sul ruolo assegnato a un utente. In questo modello, un amministratore assegna un utente a un ruolo che ha determinati diritti e privilegi predeterminati. A causa dell'associazione dell'utente al ruolo, l'utente può accedere a determinate risorse ed eseguire attività specifiche. RBAC è anche noto come controllo di accesso non discrezionale. I ruoli assegnati agli utenti sono amministrati centralmente.

DAC Nel modello Discretionary Access Control (DAC), l'accesso alle risorse si basa sull'identità dell'utente. A un utente vengono concesse le autorizzazioni per una risorsa essendo collocato in un elenco di controllo di accesso (ACL) associato alla risorsa. Una voce nell'ACL di una risorsa è nota come voce di controllo di accesso (ACE). Quando un utente (o gruppo) è il proprietario di un oggetto nel modello DAC, l'utente può concedere l'autorizzazione ad altri utenti e gruppi. Il modello DAC si basa sulla proprietà delle risorse.

vedi fonte

1) In RBAC: è necessaria la tabella ElementType per assegnare i diritti al ruolo (gli utenti sono assegnati ai ruoli). RBAC definisce: "Cosa può fare questo ruolo/utente". L'amministratore assegna i diritti per i ruoli e le autorizzazioni ai ruoli, assegna gli utenti ai ruoli per accedere alle risorse. 2) Nel DAC: utenti e ruoli hanno diritti sugli elementi tramite l'elenco di controllo degli accessi (proprietà). Il DAC definisce: "chi ha accesso ai miei dati". L'utente (proprietario) concede le autorizzazioni alla risorsa posseduta.

Ad ogni modo suggerisco questo modello di dati:

CREATE TABLE ElementType
(
    Id (PK)
    Name
    ...
)

CREATE TABLE ElementBase
(
    Id (PK)
    Type (FK to ElementType)
    ...
)

(relazione uno a uno)

CREATE TABLE Element_A
(
    Id (PK, FK to ElementBase)
    ...
)

CREATE TABLE Element_B
(
    Id (PK, FK to ElementBase)
    ...
)

1) RBAC (relazione molti-a molti)

CREATE TABLE ElementType_To_Role_Rights
(
    RightId (PK)
    RoleId  (FK to Role)
    ElementTypeId (FK to ElementType)
    ...
)

2) DAC (rapporto molti-a-molti)

CREATE TABLE ElementBase_To_Actor_Rights
(
    RightId (PK)
    ElementBaseId (FK to ElementBase)
    ActorId (FK to Actor)
    ...
)

CREATE TABLE Actor
(
    Id (PK)
    Name
)

CREATE TABLE User
(
    Id (PK, FK to Actor)
    Password
    ...
)

CREATE TABLE Role
(
    Id (PK, FK to Actor)
    ...
)
35
garik

Con una tabella dei diritti per ogni elemento, non appena aggiungi un elemento dovrai aggiungere una tabella. Ciò aggiungerebbe alla manutenzione dell'applicazione.

L'aspetto negativo di mettere tutto in una tabella è che potresti incorrere in problemi di ridimensionamento, ma questi potrebbero essere mitigati usando il partizionamento, le viste materializzate e/o le colonne virtuali. Probabilmente tali misure non sarebbero necessarie.

Per quanto riguarda il design del tavolo, se questo fosse su Oracle potrei suggerire qualcosa del genere:

CREATE SEQUENCE UserRoleID;

CREATE TABLE USERROLE 
(
  USERID NUMBER(7) NOT NULL 
, ROLEID NUMBER(7) NOT NULL 
, CONSTRAINT USERROLE_PK PRIMARY KEY 
  (
    USERID 
  , ROLEID 
  )
  ENABLE 
) 
ORGANIZATION INDEX;

CREATE TABLE PERMISSIONS 
(
  ID NUMBER(7) NOT NULL 
, ELEMENTID NUMBER(7) NOT NULL 
, CONSTRAINT USERROLE_PK PRIMARY KEY 
  (
    ID 
  , ELEMENTID 
  )
  ENABLE 
) 
ORGANIZATION INDEX;

Il codice del pacchetto potrebbe utilizzare la sequenza UserRoleID per popolare l'id nella tabella Users e l'id nella tabella Ruoli, se necessario. La tabella Autorizzazioni può quindi avere elementi assegnati a ruoli a loro volta assegnati agli utenti e/o elementi assegnati direttamente agli utenti.

5
Leigh Riffel