Mô hình cơ sở dữ liệu với người dùng, vai trò và quyền

Tôi có một mô hình cơ sở dữ liệu với bảng người dùng và bảng vai trò. Tôi muốn kiểm soát quyền truy cập (quyền) tối đa 10 yếu tố khác nhau. Quyền truy cập có thể được cấp cho một vai trò hoặc một người dùng. Dưới đây là định nghĩa bảng của người dùng, vai trò và mục:

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

...

Bây giờ tôi có hai cách khác nhau để thiết kế các quyền. Một bảng có cột loại quyền hoặc 10 bảng quyền - một bảng cho mỗi thành phần tôi muốn kiểm soát quyền truy cập.

Những ưu và nhược điểm của một bảng quyền so với một bảng quyền cho mỗi phần tử là gì? - hoặc là một cách phù hợp hơn để làm điều này?

Trước hết, loại kế hoạch bảo mật nào bạn dự định thực hiện? Kiểm soát truy cập dựa trên vai trò (RBAC) hoặc Kiểm soát truy cập tùy ý (DAC)?

RBAC trong mô hình Điều khiển truy cập dựa trên vai trò (RBAC), quyền truy cập vào tài nguyên dựa trên vai trò được gán cho người dùng. Trong mô hình này, quản trị viên gán cho người dùng một vai trò có quyền và đặc quyền được xác định trước. Do sự liên kết của người dùng với vai trò, người dùng có thể truy cập vào một số tài nguyên nhất định và thực hiện các tác vụ cụ thể. RBAC còn được gọi là Kiểm soát truy cập không tùy ý. Các vai trò được gán cho người dùng được quản lý tập trung.

DAC Trong mô hình Kiểm soát truy cập tùy ý (DAC), quyền truy cập vào tài nguyên dựa trên danh tính của người dùng. Người dùng được cấp quyền cho tài nguyên bằng cách được đặt trong danh sách kiểm soát truy cập (ACL) được liên kết với tài nguyên. Một mục trên ACL của tài nguyên được gọi là Mục kiểm soát truy cập (ACE). Khi người dùng (hoặc nhóm) là chủ sở hữu của một đối tượng trong mô hình DAC, người dùng có thể cấp quyền cho người dùng và nhóm khác. Mô hình DAC dựa trên quyền sở hữu tài nguyên.

xem nguồn

1) Trong RBAC: bạn cần bảng ElementType để gán quyền cho vai trò (người dùng được gán cho vai trò). RBAC định nghĩa: "Vai trò / người dùng này có thể làm gì". Quản trị viên gán quyền cho vai trò và quyền cho vai trò, gán người dùng cho (các) vai trò để truy cập tài nguyên. 2) Trong DAC: người dùng và vai trò có quyền đối với các yếu tố thông qua danh sách kiểm soát truy cập (quyền sở hữu). DAC định nghĩa: "ai có quyền truy cập vào dữ liệu của tôi". Người dùng (chủ sở hữu) cấp quyền cho tài nguyên thuộc sở hữu.

Bất kỳ cách nào tôi đề xuất mô hình dữ liệu này:

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

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

(mối quan hệ 1-1)

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

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

1) RBAC (mối quan hệ nhiều-nhiều)

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

2) DAC (mối quan hệ nhiều-nhiều)

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

Với bảng quyền cho từng thành phần, ngay khi bạn thêm một yếu tố, bạn sẽ cần thêm bảng. Điều này sẽ thêm vào bảo trì ứng dụng.

Nhược điểm của việc đặt mọi thứ vào một bảng là bạn có thể gặp phải các vấn đề mở rộng, nhưng những vấn đề đó có thể được giảm thiểu bằng cách sử dụng phân vùng, khung nhìn cụ thể hóa và / hoặc cột ảo. Có khả năng các biện pháp như vậy sẽ không cần thiết.

Theo như thiết kế bảng, nếu điều này là trên Oracle tôi có thể đề xuất một cái gì đó như thế này:

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;

Mã gói có thể sử dụng chuỗi UserRoleID để điền Id trong bảng Người dùng và Id trong bảng Vai trò nếu cần. Bảng Quyền sau đó có thể có các phần tử được gán cho các vai trò lần lượt được gán cho người dùng và / hoặc có các phần tử được gán trực tiếp cho người dùng.