Модель бази даних з користувачами, ролями та правами

У мене є модель бази даних з таблицею користувачів та таблицею ролей. Я хочу контролювати доступ (права) до 10 різних елементів. Доступ може бути наданий або ролі, або одному користувачеві. Нижче наведено визначення таблиці користувачів, ролей та елементів:

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

...

Зараз у мене є два різні способи оформлення прав. Одна таблиця зі стовпцем типу прав або 10 таблиць прав - по одній для кожного елемента, до якого я хочу контролювати доступ.

Які плюси і мінуси однієї таблиці прав проти однієї таблиці прав на елемент? - чи є більш підходящим способом це зробити?

Перш за все, який тип безпеки ви плануєте реалізувати? Рольовий контроль доступу (RBAC) або дискреційний контроль доступу (DAC)?

RBAC в моделі рольового контролю доступу (RBAC), доступ до ресурсів базується на ролі, відведеній користувачеві. У цій моделі адміністратор призначає користувача ролі, яка має певні заздалегідь визначені права та привілеї. Через асоціацію користувача з роллю користувач може отримати доступ до певних ресурсів і виконувати конкретні завдання. RBAC також відомий як недискреційний контроль доступу. Ролі, призначені користувачам, здійснюються централізовано.

ЦАП У моделі дискреційного контролю доступу (ЦАП) доступ до ресурсів базується на особі користувача. Користувачеві надаються дозволи на ресурс, розміщуючись у списку контролю доступу (ACL), пов’язаному з ресурсом. Запис ACL ресурсу відомий як запис доступу доступу (ACE). Коли користувач (або група) є власником об'єкта в моделі DAC, він може надати дозвіл іншим користувачам і групам. Модель ЦАП заснована на власності на ресурси.

див. джерело

1) У RBAC: вам потрібна таблиця ElementType для присвоєння прав ролі (користувачі присвоюються ролям). RBAC визначає: "Що може робити ця роль / користувач". Адміністратор призначає права на ролі та дозволи на ролі, призначає користувачів на ролі (и) для доступу до ресурсів. 2) У DAC: користувачі та ролі мають права на елементи через список контролю доступу (права власності). ЦАП визначає: "хто має доступ до моїх даних". Користувач (власник) надає дозволи на ресурс, що належить.

Будь-який спосіб я пропоную цю модель даних:

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

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

(стосунки один до одного)

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

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

1) RBAC (відносини багато-багато)

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

2) ЦАП (відносини багато-багато)

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

З таблицею прав для кожного елемента, як тільки ви додасте елемент, вам потрібно буде додати таблицю. Це додало б до обслуговування додатків.

Мінус розміщення всього в одній таблиці полягає в тому, що ви можете зіткнутися з проблемами масштабування, але їх можна пом'якшити за допомогою розділення, матеріалізованих представлень та / або віртуальних стовпців. Ймовірно, такі заходи не знадобляться.

Що стосується дизайну столу, якби це було на Oracle, я можу запропонувати щось подібне:

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;

Код пакета може використовувати послідовність UserRoleID для заповнення Id в таблиці користувачів та Id в таблиці Roles, якщо це необхідно. Потім у таблиці Дозволів можуть бути елементи, призначені ролям, які в свою чергу призначені користувачам та / або мати елементи, призначені безпосередньо користувачам.