it-swarm-eu.dev

Databázový model s uživateli, rolemi a právy

Mám databázový model s uživatelskou tabulkou a tabulkou rolí. Chci řídit přístup (práva) až k 10 různým prvkům. Přístup lze udělit buď roli, nebo jedinému uživateli. Níže je uvedena tabulka definice uživatelů, rolí a položek:

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

...

Nyní mám dva různé způsoby navrhování práv. Jedna tabulka se sloupcem typu práv nebo 10 tabulek práv - jedna pro každý prvek, ke kterému chci řídit přístup.

Jaké jsou výhody a nevýhody jedné tabulky práv vs. jedné tabulky práv na prvek? - nebo je to vhodnější způsob?

database-designbest-practices
40
taudorf

Za prvé, jaký typ modelu zabezpečení plánujete implementovat? Řízení přístupu založené na rolích (RBAC) nebo diskrétní řízení přístupu (DAC)?

RBAC v modelu RBAC (Access Based Based Control) je přístup k prostředkům založen na roli přiřazené uživateli. V tomto modelu administrátor přiřadí uživatele roli, která má určitá předdefinovaná práva a oprávnění. Z důvodu přidružení uživatele k roli může uživatel přistupovat k určitým prostředkům a provádět specifické úkoly. RBAC je také známý jako nediskreční řízení přístupu. Role přiřazené uživatelům jsou centrálně spravovány.

DAC V modelu diskrétního řízení přístupu (DAC) je přístup k prostředkům založen na totožnosti uživatele. Uživateli je uděleno oprávnění ke zdroji umístěním na seznam řízení přístupu (ACL) spojený s prostředkem. Položka na ACL zdroje je známá jako položka ACE (Access Control Entry). Pokud je uživatel (nebo skupina) vlastníkem objektu v modelu DAC, může uživatel udělit oprávnění ostatním uživatelům a skupinám. Model DAC je založen na vlastnictví zdrojů.

viz zdroj

1) V RBAC: k přiřazení práv k roli potřebujete tabulku ElementType (uživatelé jsou přiřazeni k rolím). RBAC definuje: „Co může tato role/uživatel dělat“. Správce přiřadí práva pro role a oprávnění k rolím, přiřadí uživatele k rolím pro přístup k prostředkům. 2) V DAC: uživatelé a role mají práva na prvky prostřednictvím seznamu řízení přístupu (vlastnictví). DAC definuje: „kdo má přístup k mým údajům“. Uživatel (vlastník) uděluje oprávnění pro vlastněný zdroj.

Jakkoli navrhuji tento datový model:

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

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

(vztah jeden k jednomu)

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

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

1) RBAC (vztah mnoho k mnoha)

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

2) DAC (vztah mnoho k mnoha)

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

S tabulkou práv pro každý prvek, jakmile přidáte prvek, budete muset přidat tabulku. To by přispělo k údržbě aplikace.

Nevýhodou umístění všeho v jedné tabulce je to, že se můžete setkat s problémy s škálováním, ale ty lze zmírnit pomocí rozdělení, materializovaných pohledů nebo virtuálních sloupců. Pravděpodobně by taková opatření nebyla nutná.

Pokud jde o design stolu, pokud by to bylo na Oracle, mohl bych navrhnout něco takového:

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;

Kód balíčku by mohl podle potřeby použít posloupnost UserRoleID k naplnění ID v tabulce Users a Id v tabulce Roles. Tabulka oprávnění by pak mohla mít prvky přiřazené k rolím, které jsou zase přiřazeny uživatelům nebo mohou mít prvky přiřazené přímo uživatelům.

5
Leigh Riffel