役割ベースのアクセス制御を設計するには？
役割ベースのアクセス制御モデルに従って、ユーザーがシステムで実行できることまたは実行できないことを制限しようとしています。
これまでのところ、私は次のエンティティを持っています：
users-システムを使用する人。ここにユーザー名とパスワードがあります。 roles-ユーザーが持つことができるロールのコレクション。 manager、adminなどのようなものresources-ユーザーが操作できるもの。契約、ユーザー、契約ドラフトなどのようにoperations-ユーザーがリソースで実行できること。作成、読み取り、更新、削除など。
さて、この疑問は、このような関係にある図でここに生じます。
operations（0 .. *）が実行されるresources（0 .. *）これはpermissionsと呼ばれるテーブルを生成し、operationとresource。
権限テーブルは次のようになります（その1行）：ID：1、operation：create、resource：契約。
つまり、permissionからcreateacontract。
一部のリソースにはすべての種類の操作がない可能性があると感じたので、この方法を使用しました。たとえば、contractsを登録する場合、ユーザーはファイルをアップロードできますが、これはoperationプロバイダーの登録には使用できません。
したがって、administratorがpermissionsをroleに付与すると、彼はシステムに登録されているすべての操作のリソースのリストはありません。
各resourceには、彼に対して実行できるoperationsの独自のコレクションがあると思います。
何かが理解できない場合、私は明確にすることができます。
これはrbacを実装する正しい方法ですか？
[〜＃〜]編集[〜＃〜]
つまり、permissionsテーブルにoperationおよびresource、resourcesをoperationsに関連付けたいので、2つの余分なテーブルがあります。 resourcesにpermissionsを実行することもできます。ここで、権限テーブルは権限を格納します。
しかし、その場合、管理者が割り当てたときに、一部のリソースには存在しないアクセス許可も表示されていました。
それで、1つの列操作と別のリソースを持つこのテーブル権限が正しいかどうか、データベース設計の観点から知りたいですか？このままでいると問題が発生しますか？
あなたのデザインは私にかなり近いようです。ほんのいくつかの提案。
ユーザー-システムを使用するユーザー。ここにユーザー名とパスワードがあります。
良い
ロール-ユーザーが持つことができるロールのコレクション。マネージャー、管理者などのようなもの.
も元気。ただし、どのユーザーにどの役割があるかを示す「UserRoles」エンティティ/テーブルも必要です。特定のユーザーが2つ以上の役割を持っている可能性があります。
リソース-ユーザーが操作できるもの。契約と同様に、ユーザー、契約ドラフトなど.
意味論の問題にすぎないかもしれません。ユーザーがリソースを直接操作することはないと思います。ロールが行います。したがって、ユーザー->ユーザーロール->ロール->操作->リソースになります
操作-ユーザーがリソースを使用して実行できること。作成、読み取り、更新、削除など。
うん、「ユーザー」の代わりに「役割」を除く
権限テーブルは次のようになります（その1行）：ID：1、操作：作成、リソース：コントラクト。これは、契約を作成する権限を意味します。
うーん。これには2つの方法があります。説明する権限テーブルを使用することもできますが、どのロールにどの権限が付与されているかを示す追加のRolePermissionsテーブル/エンティティも必要です。しかし、それが必要かどうかはわかりません。
これを行うためのより簡単な方法は、役割ID、操作ID、リソースIDなどの列/属性を持つ権限テーブル/エンティティです。このように、操作とリソースの組み合わせは、役割に割り当てられている権限に読み込まれるのではなく、役割に直接割り当てられます。 1つのエンティティを削除します。許可する許可の組み合わせと許可しない組み合わせを事前に定義したくない場合を除いて、個別の役割にとらわれない許可テーブルは実際には必要ありません。
RBACを使用または実装しません。代わりに、ABACを使用します。説明させてください...
- RBACまたは役割ベースのアクセス制御は、ユーザー管理と役割の割り当てに関するものです。 RBACでは、アリスがマネージャーであると言うことになります。静的なアクセス許可を定義できます。たとえば、マネージャーはローンを承認できます。したがって、アリスからマネージャーへのリンクがあり、許可としてLoanを承認します。これを可能にするシステムはたくさんあるので、独自のテーブルを実装する必要はありません。 LDAPでも、RBACの限定されたセットをサポートしています。役割と権限のセットが比較的小さい限り、これで問題ありません。 しかし、あなたの場合のように特定の権限を考慮したい場合はどうでしょうか？表示、削除、挿入？関係を考慮に入れたい場合はどうしますか？
- ABACまたは属性ベースのアクセス制御は、ポリシー主導のきめ細かい承認に関するものです。 ABACを使用すると、RBACで定義されたロールを使用して、ポリシーを記述できます（例：
- 管理者は自分の部門のドキュメントを表示できます
- 従業員は自分が所有するドキュメントを編集できます
あなたの質問では、本質的に情報モデルを定義しました。オブジェクトとその属性（例：ユーザー（名前、パスワード、部門...）;オブジェクト（契約など）など。
したがって、ABACでは、アプリケーションコード/ロジックを、属性を使用してポリシーとして保存される承認ロジックから完全に切り離します。権限自体はポリシーに直接格納されます（上記の例を参照）。 ABAC展開アーキテクチャは次のようになります。
ポイントは、ABACアプローチを採用する場合、ABACのポリシーを（XACMLまたはALFAのいずれかに）作成し、RBACをカスタムコードまたはカスタム実装したり、アクセス制御を再度行ったりする必要がないことです。