web-dev-qa-db-ja.com

迅速に実装および理解でき、しかも十分に保守可能で柔軟性のあるアクセス制御システムを設計する方法は？

現在、SaaSスタートアップ向けにアクセス制御システムを再設計しています（この2年間で、ビジネスと共に成長し、この時点でクリーンアップすることを決定しました）。アクセス制御システムは、それぞれ500-10,000ユーザーの顧客にサービスを提供します。

それはサポートする必要があります：

  1. 読み取り専用ユーザー（つまり、一部のユーザーはログインしてアイテムを表示するだけです）
  2. ごく一部のユーザーのみがグローバル設定（統合の管理、請求情報など）を変更できます
  3. 数人のユーザーのみが3つの製品モジュールのいずれかの設定を変更できます
  4. 作成されたリソース（プロジェクト、チームなど）ごとに、プロジェクトメンバー/チームメンバーのみがリソースを変更できます。
  5. デフォルトでは、すべてのユーザーがすべてのプロジェクトを表示できますが、プロジェクトを「非表示」にして、プロジェクトメンバーだけが非表示のプロジェクトを表示できるようにする必要があります。

ここでの課題は、ロールベースのアクセス制御が1〜3を満たしているだけで、4または5は満たしていないように見えることです。ABACは次の方法ですか？

全体として、私たちはJIRAと同様の要件を持っていると思います。これは、非常に柔軟でありながら非常に複雑な（直感的でない）許可システムを提供しているようです

アクセスコントロールシステムを最適に設計する方法についての推奨事項、つまり、私たちが自問する必要がある質問や、おそらくどのようなトレードオフを行う必要があるでしょうか？

access-controlpermissionsrbacabac
4
Sarah

バックグラウンド

他のコメントと回答、そしてあなたの投稿はあなたを正しい方向に導きます。現在の承認のニーズだけでなく将来の承認のニーズにも対応できる柔軟性のあるフレームワークが必要です。そのフレームワーク（またはモデル）は確かに属性ベースのアクセス制御（ abac ）です。これは、動的承認管理およびポリシーベースのアクセス制御とも呼ばれます。 Gartner、Kuppinger Cole、およびAxiomatics（私が作業している場所）はすべて、このトピックについて広範囲にわたって執筆しています。

そうは言っても、あなたの要件を考えると、ABACは方程式の半分、つまり承認ポリシーとロジックしか解決しません。属性管理は解決されません。それでも、ユーザーまたはリソース（この場合はプロジェクト）のメタデータまたは属性について検討する必要があります。これにより、許可ポリシーが決まります。

ユースケース

読み取り専用ユーザー（つまり、一部のユーザーはログインしてアイテムを表示するだけです）

読み取り専用であることを示すには、ユーザーに割り当てることができるペルソナまたはロールを定義する必要があります。多分それはあなたのシステムの基本的な役割です。多分それは役割の不在ですが、あなたが認証に成功したという事実です。

ごく一部のユーザーのみがグローバル設定（統合の管理、請求情報など）を変更できます

これらのユーザーは何が特別なのですか？役割「管理者」または「スーパーユーザー」？それを定義する必要があり、その役割をユーザーに割り当てるプロセスが必要です。

数人のユーザーのみが3つの製品モジュールのいずれかの設定を変更できます

上記と同じストーリー。

作成されたリソース（プロジェクト、チームなど）ごとに、プロジェクトメンバー/チームメンバーのみがリソースを変更できます。

あなたが言ったように、これはスポットオンABACです。 （疑似コード-できます ALFAも使用 ）を示す簡単なポリシー（またはルール-単語は交換可能）を記述する必要があります。

A user with role=="..." can do action=="edit" on object of type=="record" if record.assignedProject == user.assignedProject.

デフォルトでは、すべてのユーザーがすべてのプロジェクトを表示できますが、プロジェクトを「非表示」にして、プロジェクトメンバーだけが非表示のプロジェクトを表示できるようにする必要があります。

ALFAの例については、以下を参照してください

ABACの実施

ポリシーとユースケースを考えることは素晴らしいことですが、決定の実施についても考える必要があります。 ABACには、ポリシー実施ポイント（PEP）およびポリシー決定ポイント（PDP）の概念があります。 PEPはゴムが道を開くところです：あなたは何を保護していますか？ウェブポータル？ビジネスプロセス？ API？どちらの方法でも、適切な承認を適用できるPEPまたはインターセプターを配置する必要があります。アーキテクチャの概要は次のとおりです。

Axiomatics Attribute Based Access Control Architecture & Flow

ALFAコードのサンプル

承認の略語であるALFAは、XACMLとともに承認の2つの主要な標準の1つです。 ALFAは、XACMLが従う同じモデル（ポリシーセット、ポリシー、ルール）の簡略表記です。私はあなたのユースケースに基づいていくつかのサンプルを書きました：

namespace com.axiomatics.examples{
    /**
     * Projects
     */
     policyset projects{
         target clause objectType == "project"
         apply firstApplicable
         /**
          * View Projects
          */
         policy viewProjects{
             target clause action == "view"
             apply firstApplicable
             /** Anyone can view a project */
             rule viewVisibleProjects{
                 target clause project.hidden == false
                 permit
             }
             /**
              * Only members can view hidden projects - it should be possible to "hide" projects so that only the project members may view the hidden project.
              */
              rule viewHiddenProjects{
                  target clause project.hidden == true
                  permit
                  condition stringAtLeastOneMemberOf(user.name, project.members)
              }
         }
     }

     /**
      * For each created resource (e.g. a project, a team, ...), only the project members / team members may change the resource.
      */
      policyset records{
         target clause objectType == "record"
         apply firstApplicable
         /**
          * Edit records
          */
         policy editRecord{
             target clause action == "edit"
             apply firstApplicable
             /** Project members can edit a record in their project */
             rule viewVisibleProjects{
                 permit
                 condition record.project == user.assignedProject
             }
         }          
      }

     /**
      * Global settings - Only a few users may change global settings (like managing integrations, billing information etc.)
      */
     policy globalSettings{
         target clause objectType == "global settings"
         apply firstApplicable
         /**
          * Administrators can view and change global settings
          */
         rule administrators{
             target clause user.role=="administrator"
                     clause action=="view" or action=="edit"
             permit
         }
     }
}

実装

ABACにはいくつかの優れた実装があります。

  • オープンソース
    • AuthZForceはXACML準拠の認証エンジンを提供します
    • Open Policy Agent（OPA）は、REGO準拠の認証エンジンを提供します。 OPAはインフラストラクチャに重点を置いています（Kubernetes、Istio ...）
  • 商業の
    • 公理学（私が働いている場所）は、おそらくリストの中で最も古い会社です。 2006年からABACを導入しています。すべてXACMLとALFAに基づいており、ポータル、API、データベースに承認を適用できます。
    • Oracle、IBM、およびその他の大手ベンダーも独自のソリューションを持っています。
1
David Brossard

次のような権限を作成できます。

  • 割り当てられたプロジェクトを表示する
  • 割り当てられたプロジェクトを編集する
  • 非表示でないプロジェクトを表示する
  • すべてのプロジェクトを表示

ユーザーの観点から見ると、これは非常に単純で理解しやすいものです。開発者の観点から見ると、権限のチェックは少し複雑ですが、それでも管理可能です。

これを行うと、これらの権限は固定ロールよりも動的になるため、技術的にABACを実行しています。しかし、それでもRBACに非常によく似ています。

0
paj28