web-dev-qa-db-ja.com

この役割と権限の管理設計を簡素化するにはどうすればよいですか？

私は複数のロールを持つユーザーがいるWebアプリケーションに取り組んでいます。各ユーザーは、ユーザーのロールと、ロールが操作に対して持っているアクセス許可レベルに基づいて、複数の操作を実行できます。私は次のスキーマを思いつきました。

ユーザー

+--------+-------------------+
| UserID | UserName          |
+--------+-------------------+
| 1      | Alice             |
+--------+-------------------+
| 2      | Bob               |
+--------+-------------------+
| 3      | Charlie           |
+--------+-------------------+
| 4      | David             |
+--------+-------------------+

役割

+--------+-----------------+
| RoleID | RoleName        |
+--------+-----------------+
| 1      | Tech_Admin      |
+--------+-----------------+
| 2      | Tech_Normal     |
+--------+-----------------+
| 3      | Non_Tech_Admin  |
+--------+-----------------+
| 4      | Non_Tech_Normal |
+--------+-----------------+

PermissionLevels

+-------------------+----------------------+
| PermissionLevelID | PermissionLevel      |
+-------------------+----------------------+
| 1                 | Tech_Account         |
+-------------------+----------------------+
| 2                 | Non_Tech_Own_Account |
+-------------------+----------------------+
| 3                 | Non_Tech_Any_Account |
+-------------------+----------------------+
| 4                 | Own_User             |
+-------------------+----------------------+

serRoles

+--------+--------+
| UserID | RoleID |
+--------+--------+
| 1      | 1      |
+--------+--------+
| 2      | 2      |
+--------+--------+
| 3      | 3      |
+--------+--------+
| 4      | 4      |
+--------+--------+

コマンド

+-----------+--------------+
| CommandID | CommandName  |
+-----------+--------------+
| 1         | CREATE_USER  |
+-----------+--------------+
| 2         | EDIT_USER    |
+-----------+--------------+
| 3         | VIEW_USER    |
+-----------+--------------+
| 4         | EDIT_PROFILE |
+-----------+--------------+
| 5         | VIEW_PROFILE |
+-----------+--------------+
| 6         | SUSPEND_USER |
+-----------+--------------+

RoleCommands

+--------+-----------+-------------------+
| RoleID | CommandID | PermissionLevelID |
+--------+-----------+-------------------+
| 1      | 1         | 1                 |
+--------+-----------+-------------------+
| 1      | 1         | 3                 |
+--------+-----------+-------------------+
| 2      | 2         | 1                 |
+--------+-----------+-------------------+
| 3      | 2         | 2                 |
+--------+-----------+-------------------+
| 4      | 5         | 4                 |
+--------+-----------+-------------------+

簡単にするために、アカウントの詳細については説明していませんが、各ユーザーは「Tech」または「Non-Tech」というアカウントに属しています。システムにはTechアカウントが1つしかありません。

以下は、RoleCommandsテーブルごとのサンプルビジネスルールです。

  • 技術管理者は技術アカウントでユーザーを作成できます。
  • 技術管理者は、非技術アカウントでユーザーを作成できます。
  • Tech NormalはTechアカウントのユーザーを編集できます。
  • 非技術管理者は、自分の非技術アカウントでユーザーを編集できます。
  • Non Tech Normalは自分のプロファイルを表示できます。つまり、表から、他のユーザーはこのユーザーのプロファイルを表示できません。

新しいREST APIリクエストを受け取ったら、リクエストパラメーターに基づいて操作を識別し、ユーザーがRoleCommandsテーブルに基づいて操作を実行する権限を持っているかどうかを確認します。これは妥当なように見えますか？役割および権限管理の設計？

更新

RoleCommandsテーブルのレコードが多すぎるように見えます。これは、コマンドごとに、役割と権限レベルの組み合わせがいくつかあるためです。特定のオブジェクトについて、オブジェクトが存在する可能性のあるn（たとえば、10）のステータスが存在する可能性があります。ユーザーにView_Object_Status1コマンドのアクセス許可を与えて、オブジェクトのステータスがStatus1のときにオブジェクトを表示できるようにしたいと考えています。それはRoleCommandsテーブルを爆破しています。これを簡素化する最良の方法は何ですか？

designdatabase-designrelational-databasepermissionsroles
3
TechCrunch

あなたの現在のデザインはこれです：

enter image description here

あなた自身に尋ねるべきです：

  • エンティティPERMISSION_LEVELは実際のレベルを表しますか？

それらが実際のレベルであるかどうかは、ユーザーに2つの異なる役割が付与され、両方の役割が同じコマンドを持っているが、レベルが異なる場合、アプリがそれらの最高レベルを取る必要があることを意味します。権限レベルのないロール権限モデルでは、セットロジックが使用されるため、ユーザーが同じ権限を2回持つことになっても、問題ではありません。重要なのは、許可がセットに存在することであり、それが何回存在するかではありません。ただし、モデルには権限レベルがあるため、ユーザーが同じロールコマンドを複数の権限レベルで何度も使用するようになった場合の対処方法を決定する必要があります。

一方、質問の更新では、OBJECTであるモデルに表示されない新しいエンティティについて言及します。

  • オブジェクトはどこにモデルに入りますか？

私が見ることができるものについては、モデルは次のように更新されます：

enter image description here

その結果、実際には結果のテーブルの行番号が大幅に増加します。しかし、適切なインデックスとFKを作成すれば、それほど心配する必要はありません。私が心配しているのは、役割を組み立てる複雑さですが、少なくとも一度だけ実行する必要があります。

結局、私が出した答えよりもさらに多くの質問を投げかけたかどうかはわかりません。

2
Tulains Córdova

これは、役割と権限の管理に適した設計のように見えますか？

ここでは「合理的」という用語はややあいまいです。

目的に適う

このデザインはそれの目的を達成します。これにより、ログインしたユーザーが特定のビジネスオブジェクトに対して実行できる操作を決定できます。

  • ユーザーが識別されます
  • 役割が識別されます
  • ユーザーは役割に割り当てられます
  • コマンドが識別されます-明らかにコマンドはビジネスオブジェクト（この例ではユーザーアカウント）の操作を参照しています
  • 許可レベルが識別されます-明らかに、許可レベルはコマンドで管理されるビジネスオブジェクトを制限します
  • 権限レベルを持つコマンドはロールに割り当てられています

力

この設計により、現代のビジネスアプリケーションで期待されているように、簡単な日常のロールベースのアクセス管理が可能になります。

このデザインは柔軟です。これにより、役割を非常に細かく調整できるため、望ましいアクセス構成を実装できます（アクセス許可レベルがセグメンテーションのニーズを適切に表していると想定）。

弱点

ロールの構築には、すべての組み合わせを明示的に入力する必要があります。コマンドまたは権限レベルが細かすぎる場合、これは面倒な場合があります。

アクセス許可レベルは、すべてのビジネスオブジェクトに共通です。

  • 同様のアクセスルールを共有するいくつかのビジネスオブジェクトのみを管理する場合は、問題ありません。
  • さまざまなビジネスオブジェクトに異なるアクセスルールが必要な場合は、コマンドとアクセス許可レベルの間に矛盾が生じるリスクがあるため、さらにアクセス許可レベルを追加する必要があります。

ちなみに、現在のアクセス許可レベルのリストは、データのセット全体を明確にカバーしていません。「Own」の名前を「Tech_Own」に、「Tech」の名前を「Tech_any」に変更することをお勧めします。 「どれでも」は「自分のもの以外」を意味することを理解しています。

編集：

複数のビジネスオブジェクトの管理に関するコメントに続いて、ビジネスオブジェクトテーブルを追加し、コマンドテーブルとアクセス許可レベルを変更して、両方がビジネスオブジェクトに関連するようにすることをお勧めします。

このようにして、プロファイルが互換性のあるコマンドとアクセス許可レベルを常に関連付けていることを確認します。この表でbusiness-object-idを導入するだけで済みます。

これは役割を単純化しませんが、これは問題を解決するだけでなく、エントリを容易にするために（常に互換性のある要素の中から選択する）ニースユーザーインターフェイスを役割マネージャに提供することもできます。

1
Christophe

ここに私が状況に取り組む方法があります：

  1. ユーザーテーブルを保持する
  2. ロールと見なすのは、基本的にはユーザーのグループです。そこで、新しいテーブルグループを作成します
  3. PermissionLevelとは、グループのメンバーが持つことができるロールと同じです（たとえば、Tech_Adminであるユーザーは、Tech_AccountおよびNon_Tech_accountのロールを持つことができます）
  4. コマンドテーブルをモジュールと呼ばれるテーブルに置き換えます。モジュールには、アクセス許可を適用する必要があるさまざまな領域（ユーザー、プロファイル、レポートなど）が保持されます。
  5. アクセス許可を維持するために、CRUD（作成、読み取り、更新、削除）アプローチを使用します。制限的な場合もありますが、権限の設計によく使用されます。 CRUD値は、ビットをチェックするバイトとして、または個別の列に格納できます。

ここで、アプリケーションと設計に関する重要な質問に行きます。コマンドの権限を定義するものは何ですか？役割、グループ、またはユーザーは、グループ権限を上書きする個別の権限を持つことができますか？

次の表を使用できます。

GroupPermissions

GPID-ModuleID-CRUD（またはC-R-U-Dの個別の列）

RolePermissions

RoleID-ModuleID-CRUD

次の質問：アプリでは、グループに依存せずにロールを存在させることができますか？はいの場合、上記の表で十分です。それ以外の場合は、2つをリンクするテーブルが必要です

グループ役割

GRID-GroupID-RoleID

次の質問：ユーザーはグループの一部のみになることも、所属するグループとは独立してロールを持つこともできますか？

前者の場合、このようなテーブルが必要ですか？

GroupsUsers

GUID-ユーザーID-グループID

後者の場合、もう1つのテーブルが必要です

RolesUsers

RUID-ユーザーID-ロールID

最後に、グループまたはロールへの参加に関係なく、ユーザーが個々のレベルの権限を持つことができる場合、このテーブルは必須です

モジュールユーザー

MUID-ユーザーID-モジュールID-CRUD

アクセス許可の伝達に関するポリシーに応じて、最後の3つのテーブルのチェックを開始し、ユーザーが実行できることを決定できます。

1
John Kouraklis

PermissionLevelsはコマンド権限を定義する必要があります。これにより、設計が大幅に簡素化されるため、各権限レベルには事前定義されたcrud権限が付属します。

別のオプションは、許可とロールをRESTサービスのURNの第2レベルと第1レベルとして定義することです。

例：sales、operation、report、configなどのURNを持つRESTサービス。各URNが役割になります。各役割には、CRUD（読み取り、作成、更新、削除、監査など）のようなアクセス許可を設定できます。1人のユーザーに対して、1つ以上の役割のアクセス許可を付与し、それぞれに自分の持っているcrudアクセス許可を指示することができます。

 User1
 Roles           Permissions
 Sales            CRUD
 Report           R
 Operation        CR

注：役割階層を実装することもできます。これにより、高いホールにはデフォルトでサブ役割が許可されます。つまり、ユーザーに権限を適用するためのデータベースレコードが少なくなります。

詳細は https://en.m.wikipedia.org/wiki/Role-based_access_control にあります

0
Please_Dont_Bully_Me_SO_Lords