5

データベース主導のアクセス制御システムを実装したいと考えています。ACL、ロール、RBAC などについて読んでいますが、最も一般的なスキームにはいくつかの大きな欠点があるようです。たとえば、RBAC は、きめの細かいアクセス制御 (たとえば、特定のロールが特定のレコードの特定の列のみを更新できるようにするなど) の実装に関しては扱いにくいようです。

アクセス制御リストを次のように構成するとどうなるでしょうか。

| role  | table | action | columns  | conditions        |
| ----- | ----- | ------ | -------- | ----------------- |
| user  | user  | view   | name, id | self.id = user.id |
| user  | user  | update | password | self.id = user.id |
| admin | user  | update | *        |                   |
| admin | user  | create | *        |                   |
| admin | user  | delete | *        |                   |

アイデアは、ユーザーがデータベースにアクセスしようとしたときに、このテーブルに対してユーザーのロールがチェックされるというものです (したがって、モデル レベルで実装されます)。 actionのいずれかになり{create, view, update, delete, list}ます。selfスコープは、現在のユーザーのプロパティを参照する予約済みのキーワードになります。これにより、たとえば、ユーザーが自分のパスワードのみを更新できるようにすることができます (他のユーザーのパスワードは更新できません)。

これは頑丈ですか？明らかに、URI などの他のタイプのリソースへのアクセスを制御するには、別のリストが必要です。

4

1 に答える 1

8

素晴らしい質問です。ACL と RBAC の制限に達しています。属性ベースのアクセス制御 (ABAC) と呼ばれる、より柔軟な別の方法があります。

次の図は、より複雑なシナリオ (より多くのユーザー、より多くのデータ、より多くのデバイス、より多くのコンテキスト) に対応するために、アクセス制御が時間の経過とともにどのように進化したかを示しています。

時代を超えたアクセス制御

より具体的には、RBAC が関係をサポートしていないという事実に苦しんでいます。ただし、ABAC はそうします。ABAC は属性に基づいています。属性は、 role == managerやlocation == Arizonaなどの単なるキーと値のペアです。

ABAC は、属性を持つポリシーを使用して承認シナリオを表現します。たとえば、ABAC では次のようなシナリオを表現できます。

  • 役割 == 医師を持つユーザーは、医師の場所 == 患者の場所 の場合、タイプ == 医療記録のリソースに対してアクション == ビューを実行できます。

ABAC の実装に使用できる XACML (eXtensible Access Control Markup Language) と呼ばれる標準があります。Axiomatics Data Access Filterなど、データベースやデータ アクセス制御に特化した XACML を提供する製品もあります。

ABAC について詳しく知りたい場合は、次の 2 つの優れたリソースを参照することをお勧めします。

  1. NIST: 属性ベースのアクセス制御 (ABAC) の定義と考慮事項のガイド ( pdf )
  2. NIST ドキュメントに関するウェビナー。
于 2015-03-06T10:26:54.397 に答える