8

最近、アプリケーションで使用するのに最適なアクセス制御モデルを検討しています。私はRBACについて読んでいますが、役割の概念は優れています（特に、さまざまな権限が大量にある場合）。ただし、次のような階層型ユーザー管理にどの程度適用できるかはわかりません。

すべてのユーザーは1つ以上のグループに属しています。グループはツリーに編成されます（ディレクトリ構造のように）。グループとユーザーの両方にアクセス許可（またはRBACについて話している場合はロール）を割り当てることができ、おそらく何らかの継承（つまり、ユーザーとグループが属するグループのアクセス許可を継承する）とオーバーライド機能が必要です。グループ自体の目的は、権限の管理だけではありません。アプリ内で他の用途もあります。

パーミッションは非常に細かく、ロールはよりモノリシックであるため、パーミッションがロールなしで使用された場合（「ロール」はRBAC用語でのパーミッションのコレクション）、上記のすべてをさらに設計して実装するのにそれほど問題はないと思います。グループ/ユーザーレベルでのアクセス許可の継承/オーバーライドの実装はそれほど難しくありません。ロールで同じことを行うのはおそらくもっと難しいでしょうが、一方で、ロールは平均的なユーザーにとってより簡単に理解できます。

現在、私自身、「許可のみ」のモデルに傾倒しています。理由は次のとおりです。

  • アプリにはおそらく30を超える異なる権限はありません。
  • グループ自体を使用して権限を設定できます。これにより、ロールの利点の1つである複数のユーザーの権限管理が容易になります。
  • コンセプトは明確で、実装が簡単なようです

ただし、「許可のみ」のモデルよりも優れた、論理的で理解しやすい役割ベースのモデルが提示された場合は、それを真剣に検討します。上記の要件に適用/適応できる、明確に定義されたRBACモデル（ペーパー、実装など）がすでに利用可能ですか（私はしばらくの間それらを探していましたが、私が見つけたものは制限が多すぎるか、しませんでした階層的なユーザー管理を取り入れないでください）？この問題についてのあなたの全体的な意見は何ですか？この場合、RBACはそれだけの価値がありますか？

4

2 に答える 2

4

基本的なRBACシステムは、許可システムを使用するのと同じくらい簡単だと思います。

RBACの「役割」という用語は、実装を制限する可能性があることに注意してください。つまり、従来のRBACシステムには、次のような典型的なルールがあります。

allow (a) role (to do an) action (on an) object

擬似コードでは、次のようなメソッドがあります。

myRbac.allow(Member, View, Post)

ただし、抽象化の役割を妨げるものは何もありません。通常、ロールは文字列名です。その文字列名を使用して、グループやユーザーに名前を付けることもできます。「役割」ベースは、創造的に使用する場合、役割以上のものを可能にします。それをオブジェクトベースまたは他の何かと呼びますが、本質的には同じです。何かが何かに対してアクションを実行できるようにします。

allow (an) object (to do an) action (on an) object

この観点から見ると、IMHOの実装は、実装のコストを正当化するのに十分単純です。'role'という用語が、実装の単純さを制限しないようにしてください。そして、あなたがそれをそれほど単純に実装することができるなら、なぜそれのために行きませんか？

PHPをご存知のようです。Zend Framework ACLを見ると、役割ベースの実装がわかります。多分それはあなたを刺激するでしょう。

編集：階層について：ロール（オブジェクトまたは拡張子による名前）の階層を実装することは難しくありません。要求されたobject-action-objectのルールがあるかどうかを確認します。何も存在しない場合は、許可または拒否されるまで階層を上に移動します。ユーザーが複数の役割を持つことができる場合（たとえば、メンバーの役割であり、グループAdministrators（別名AdministratorGroupと呼ばれる役割）にある場合）、拒否が許可を無効にするか、またはその逆を選択する必要があります。レベルが並列である場合に許可を獲得することを好みます（たとえば、アクションはロールAで許可されているが、ロールBで拒否されている場合、ユーザーにはロールAとBの両方があり、ロールAとBは関連しておらず、階層内にありません）。

再：あなたの例の階層。Zend Framework ACLでは、これは次のようになります。

$acl->addRole(new Zend_Acl_Role('Role1'))
    ->addRole(new Zend_Acl_Role('Group1', array('Role1'))
    ->addRole(new Zend_Acl_Role('Group2', array('Group1));
$acl->allow('Role1', 'someAction', 'someObject'); // permission 1
$acl->allow('Role1', 'otherAction', 'otherObject'); // permission 2
$acl->deny('Group2', 'someAction', 'someObject');

正直なところ、私は自分のシステムを作成しているので、Zend_Aclで実際にこれを行ったのはしばらく前のことです。

于 2009-12-29T15:46:07.750 に答える
1

カスタム アプリケーションのアクセス許可にグループを使用する際の課題は、グループとそれらが保護するために使用されているリソースとの間に関係がないことです。たとえば、カスタム アプリケーションで AD グループを使用してアクセス権を付与する場合、そのグループが他に何にアクセス権を付与しているかはわかりません。共有フォルダー、他のアプリ、ほとんどすべてへのアクセスを許可するグループに、うっかり追加してしまう可能性があります。独自のアプリを作成する場合は、ロールベースのシステム (アプリ コードの外部ですべてのセキュリティを維持するクレーム モデルの一部としてさらに優れたロール) のようなものをお勧めします。ここでは、ロールとそれが可能なリソースとの間に制約された関係があります。へのアクセスを許可するために使用されます。これにより、誰が何に、なぜアクセスできるかをすべてのディメンションから確認できます。グループは、可視性の観点からブラック ホールを表します。

私たちは、保護するリソースの種類ごとに制限されたポリアーキカルなビジネス ロールと技術ロールを使用して、かなり複雑な RBAC を製品に実装しています - http://blog.identitymanagement.com/downloads/ Microsoft には、 Windows Identity Foundation - ほとんどの配管を処理します

パトリック・パーカー

于 2009-12-30T02:27:54.363 に答える