ユーザー、ロール、権利を持つデータベースモデル

ユーザーテーブルとロールテーブルを持つデータベースモデルがあります。最大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,
  ...
);

...

今、私は権利を設計する2つの異なる方法を持っています。権利タイプの列を持つ1つのテーブルまたは10個の権利テーブル-アクセスを制御する要素ごとに1つ。

要素ごとに1つの権利テーブルと1つの権利テーブルの長所と短所は何ですか？-またはこれを行うにはより適切な方法ですか？

まず、どのタイプのセキュリティモデルを実装する予定ですか？役割ベースのアクセス制御（RBAC）または任意アクセス制御（DAC）

RBAC（役割ベースのアクセス制御）モデルでは、リソースへのアクセスはユーザーに割り当てられた役割に基づいています。このモデルでは、管理者は特定の事前に決定された権利と特権を持つロールにユーザーを割り当てます。ユーザーはロールに関連付けられているため、ユーザーは特定のリソースにアクセスして特定のタスクを実行できます。RBACは、非任意アクセス制御とも呼ばれます。ユーザーに割り当てられた役割は集中管理されます。

DAC随意アクセス制御（DAC）モデルでは、リソースへのアクセスはユーザーのIDに基づいています。ユーザーは、リソースに関連付けられたアクセス制御リスト（ACL）に配置されることにより、リソースへのアクセス許可を付与されます。リソースのACLのエントリは、アクセス制御エントリ（ACE）と呼ばれます。ユーザー（またはグループ）がDACモデルのオブジェクトの所有者である場合、ユーザーは他のユーザーおよびグループにアクセス許可を付与できます。DACモデルは、リソースの所有権に基づいています。

ソースを見る

1）RBACの場合：ロールに権利を割り当てるにはElementTypeテーブルが必要です（ユーザーはロールに割り当てられます）。RBACは、「この役割/ユーザーができること」を定義しています。管理者は、ロールの権限およびロールへのアクセス許可を割り当て、ユーザーをロールに割り当ててリソースにアクセスします。2）DACの場合：ユーザーとロールには、アクセス制御リスト（所有権）を介して要素に対する権限があります。DACは、「誰が私のデータにアクセスできるか」を定義しています。ユーザー（所有者）は所有リソースにアクセス許可を付与します。

私はこのデータモデルを提案します：

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

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

（1対1の関係）

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）DAC（多対多の関係）

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

各要素の権利テーブルでは、要素を追加したらすぐにテーブルを追加する必要があります。これにより、アプリケーションのメンテナンスが追加されます。

すべてを1つのテーブルに入れることのデメリットは、スケーリングの問題が発生する可能性があることですが、パーティション化、マテリアライズドビュー、仮想列を使用してそれらを緩和できる可能性があります。おそらく、そのような措置は必要ないでしょう。

テーブルの設計に関しては、これが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シーケンスを使用して、必要に応じて、UsersテーブルのIdとRolesテーブルのIdを設定できます。次に、Permissionsテーブルの要素をロールに割り当て、その要素をユーザーに割り当てたり、要素をユーザーに直接割り当てたりできます。