Model bazy danych z użytkownikami, rolami i uprawnieniami

Mam model bazy danych z tabelą użytkowników i tabelą ról. Chcę kontrolować dostęp (prawa) do 10 różnych elementów. Dostęp może zostać przyznany roli lub pojedynczemu użytkownikowi. Poniżej znajduje się definicja tabeli użytkowników, ról i elementów:

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,
  ...
);

...

Teraz mam dwa różne sposoby projektowania praw. Jedna tabela z kolumną typu uprawnień lub 10 tabel uprawnień - po jednym dla każdego elementu, do którego chcę kontrolować dostęp.

Jakie są zalety i wady jednej tabeli uprawnień w porównaniu do jednej tabeli uprawnień na element? - czy jest to bardziej odpowiedni sposób na zrobienie tego?

Po pierwsze, jaki typ modelu bezpieczeństwa planujesz wdrożyć? Kontrola dostępu oparta na rolach (RBAC) czy dyskrecjonalna kontrola dostępu (DAC)?

RBAC w modelu kontroli dostępu opartej na rolach (RBAC) dostęp do zasobów zależy od roli przypisanej użytkownikowi. W tym modelu administrator przypisuje użytkownika do roli, która ma pewne określone prawa i uprawnienia. Ze względu na powiązanie użytkownika z rolą użytkownik może uzyskać dostęp do niektórych zasobów i wykonywać określone zadania. RBAC jest również znany jako niedyskrecjonalna kontrola dostępu. Role przypisane do użytkowników są administrowane centralnie.

DAC W modelu dyskretnej kontroli dostępu (DAC) dostęp do zasobów zależy od tożsamości użytkownika. Użytkownik otrzymuje uprawnienia do zasobu poprzez umieszczenie go na liście kontroli dostępu (ACL) powiązanej z zasobem. Wpis na liście ACL zasobu jest znany jako wpis kontroli dostępu (ACE). Gdy użytkownik (lub grupa) jest właścicielem obiektu w modelu DAC, użytkownik może udzielić uprawnienia innym użytkownikom i grupom. Model DAC opiera się na własności zasobów.

patrz źródło

1) W RBAC: potrzebujesz tabeli ElementType, aby przypisać prawa do roli (użytkownicy są przypisani do ról). RBAC definiuje: „Co może zrobić ta rola / użytkownik”. Administrator przypisuje prawa do ról i uprawnienia do ról, przypisuje użytkowników do ról w celu uzyskania dostępu do zasobów. 2) W DAC: użytkownicy i role mają prawa do elementów poprzez listę kontroli dostępu (własność). DAC definiuje: „kto ma dostęp do moich danych”. Użytkownik (właściciel) przyznaje uprawnienia do posiadanego zasobu.

W dowolny sposób sugeruję ten model danych:

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

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

(relacja jeden do jednego)

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

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

1) RBAC (relacja wiele do wielu)

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

2) DAC (relacja wiele do wielu)

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)
    ...
)

Z tabelą praw dla każdego elementu, jak tylko dodasz element, będziesz musiał dodać tabelę. Zwiększy to utrzymanie aplikacji.

Minusem umieszczania wszystkiego w jednej tabeli jest to, że możesz napotkać problemy ze skalowaniem, ale można je złagodzić za pomocą partycjonowania, zmaterializowanych widoków i / lub wirtualnych kolumn. Prawdopodobnie takie środki nie byłyby konieczne.

Jeśli chodzi o projekt tabeli, gdyby to było na Oracle, mógłbym zasugerować coś takiego:

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;

Kod pakietu może w razie potrzeby użyć sekwencji UserRoleID, aby wypełnić identyfikator w tabeli Users i identyfikator w tabeli Roles. W tabeli Uprawnienia można następnie przypisać elementy do ról, które z kolei są przypisane do użytkowników i / lub mają elementy przypisane bezpośrednio do użytkowników.