web-dev-qa-db-ja.com

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

ユーザーテーブルとロールテーブルを持つデータベースモデルがあります。最大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つずつ、権利タイプ列のある1つのテーブルまたは10個の権利テーブル。

要素ごとに1つの権限テーブルと1つの権限テーブルの賛否両論は何ですか？-またはこれを行うためのより適切な方法はありますか？

database-designbest-practices
40
taudorf

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

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

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

各要素の権限テーブルを使用すると、要素を追加するとすぐに、テーブルを追加する必要があります。これはアプリケーションのメンテナンスに追加されます。

すべてを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テーブルには、役割に割り当てられた要素がユーザーに割り当てられたり、ユーザーに直接割り当てられた要素が含まれたりします。

5
Leigh Riffel