it-swarm.dev

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 (uprawnienia) do 10 różnych elementów. Dostęp można przyznać roli lub jednemu użytkownikowi. Poniżej znajduje się definicja użytkowników, ról i przedmiotów w tabeli:

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?

40
taudorf

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) udziela uprawnień 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)
    ...
)
35
garik

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 do wypełnienia identyfikatora w tabeli Users i identyfikatora 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.

5
Leigh Riffel