web-dev-qa-db-ja.com

RBACモデル：2つの役割のユーザーがジレンマにアクセスする

Role-Based Access Control（RBAC）モデルのセキュリティシステムを実装していますが、ジレンマがあります。1人のUser1がRole1とRole2にいます。 Role1はResource1へのアクセスを許可し、Role2は同じアクセスを拒否します。これはよく知られた問題です。誰かが私を助けてくれませんか、それを解決する方法、おそらくいくつかの説明。 User1が一部のリソースにアクセスできない理由を説明する方法。それを賢く克服するための解決策はありますか？.

ありがとう。

rbacauthorizationaccess-control
10
garik

RBACとDAC（Discretionary Access Control）を融合しているようです：Deny Accessは通常RBACで採用されていませんが、DACの世界で採用されています。 F.e. NTFS ACL（アクセス制御リスト）にDENYが含まれているのが一般的です。

マージされたモデルを実装しようとしている可能性があります（私の応答の例を参照 here ）-たとえば、ロールをポイントするACE（アクセス制御エントリ）を使用してACLを構築する。例えば。グループを使用してフォルダへのアクセスを許可しています...

使用できる2つの可能なソリューションがあり、おそらくミックスアンドマッチも、システムにとって何が理にかなっているかに依存します（私は異なるコンテキストで両方を構築して使用しました）。

  • 順序付きACL-つまり、ACLはACEの大きな山ではありませんが、特定の順序になっています。リストの上の方が優先され、PERMIT ACEが見つかるまでACEを評価し続けますまたはそのユーザーの拒否ACE。リストの最初の方が勝ちます。
  • DENY ACEは他のすべてのACEを上書きします。つまり、Role1を介してユーザーにアクセス権が付与されている場合は、ACLをスキャンしてユーザーに適用されるDENYを探し、Role2は何があってもアクセスをブロックします。

標準のACLモデルではこれを実装しない可能性がありますが、実際にはユーザーの役割のみを確認していることに注意してください。それでも問題ありません。上記が適用されます（視覚化して説明するのが難しい）。

あなたが理解する必要がある本当の質問は、「あなたのシステムにとって何が意味があるのですか？」です。 SoD（分離/職務分離）を実装しようとしていますか？その場合、DENYがすべてのPERMITをオーバーライドする必要があることは明らかです。 ISそれを回避する方法があるので、ユーザーがこれを構成する場合（この場合はRBACではなくそのDAC））、最初のオプションが最も柔軟性を与えます。

7
AviD

これがよく知られている問題かどうかはわかりません。デフォルトの位置がdeny-to-allであり、そうである必要がある場合、ルールは各ロールができることが行うことのみを記述する必要があります。ユーザー/ロールが何らかのルールでリソースにアクセスできる場合、それらは許可されるべきだと思います。

役割のレイアウト方法を再考する必要があるかもしれません。紛争では、最高の特権が勝つと思います。ツールはこれをさまざまな方法で処理します。環境がどのように機能するかを正確に理解することが重要であり、どのようにすべきか ）仕事。

4
pboin

私は何かが足りないかもしれませんが、「アクティブな役割」のような概念を使用するためのかなり単純な解決策ではありませんか？

つまり、ユーザーは割り当てられているロールのリストからアクティブなロールを選択し、その単一のロールに対してACLのみをチェックします。

2
Van Gale

ハイブリッドクレームベースのアクセスセキュリティと呼ばれるものを使用することを検討してください。このモデルでは、基本的に各タスクが分割され、セキュリティの管理を容易にするためのプロファイルとして使用されます（ただし、初期実装は困難です）。

基本的に次のようなテーブルをセットアップします。

Users --> Groups --> Profiles --> Rights
 |         |_______________________^
 |____________________^
 |_________________________________^

ユーザーテーブル、各ユーザーは1つ以上のグループを持つことができますユーザーは1つ以上のプロファイル（別名：タスクのサブグループの権限）を持つこともできますユーザーは1つ以上の権限を持つことができますグループは1つ以上のプロファイルを持つことができますグループは1つ以上を持つことができます権利プロファイルには1つ以上の権利がある場合があります

不利な点は、タスク指向のグループの追加レイヤーにありますが、ほとんどの非開発者にとって、この設計を概念化することは簡単です。

また、純粋なクレームベースのシステムを使用できますが、そのような長期的なIMOのようなものを維持することは困難です。おそらく、標準のRBAC（RB-RBACではない）を使用して、競合=アクセス拒否などの一貫したルールセットを使用する方がよいでしょう。

1
Dave