単純な属性ベースのアクセス制御（ABAC）の実装に向けて推奨されるロードマップは何ですか？
ACLとRBACについて読んだとき、私はそれを簡単に理解しているようです-アセットへのアクセス権が与えられているユーザー名またはロールがあります。また、それらを実装する方法も確認できます。
つまり、この画像はACLとRBACの明確なビューを提供します（上記に基づいてデータベーステーブルを設計し続けることができるように）： 
（画像提供 pressbooks ）
私が苦労しているのはABACです。これまでに見つけたさまざまな画像は、手が波打ったり過度に複雑であったり、承認を行うサードパーティの外部エンティティの使用を提案したりしています。または、奇妙な属性の例を挙げてください。使用方法は完全にはわかりません。
開始例
それでは、実際の生活から始めましょう。たとえば、70〜200人の会社があるとします。そして、私の保護すべき資産は、さまざまなページがたくさんあるウェブサイトです。特定の人に特定の資産へのアクセスを許可したい。
たとえば、Leslieという人にPrice ManagerというWebページへのアクセスを許可し、そのページのTravel価格グループの価格のみを管理できるようにして、同じページでProductグループの価格を管理できる。 ABACを使用してこれをどのように実装しますか？
これまでのところ、私はLeslieにいくつかの属性（ただし、どの属性とこれらの属性は何か）を割り当て、それらを格納するデータベーステーブルを作成できると思います。次に、これらの属性を見て（ただしLeslieをRBACのように「役割」としては見ない）エンジンを設計し、そこからページへのアクセスを許可するかどうかを決定します。そのエンジンはどのように見えますか？単純なif/elseブロックですか？他に何か？
レスリーが後で彼女の立場を変更し、誰かが彼女のアクセス権を変更する必要がある場合はどうなりますか？彼女がProductから移動してTravelを取り消す必要がある場合、どのように見えますか？ Price Managerページへのアクセスを完全に取り消す必要があるため、TravelとProductのどちらにもアクセスできなくなった場合、どのようにコード化されますか？
私の場合、言い直すとアセットはPrice Managerであり、ユーザーはTravel料金設定、Product料金設定など、そのページのさまざまな価格グループにアクセスできます。
私が探しているのは、詳細を明確にするための、そして推測することなく立ち去って実装できる場所への実装に向けた合理的に完全なロードマップです。つまり、概念的に完成したり、データベース構造を視覚化できる具体的な例を示したりすることができます。
おまけ：ABACは、比較的小さな許可の必要性、つまり70-200人を管理し、150-450の資産にアクセスするための適切な方法ですか？代わりにACL/RBACを使用する方が良いでしょうか？
ABACの実装は、ACL/RBACよりも複雑です。一部のフレームワークは、後者に対処するためのインフラストラクチャを提供します。人と資産を比較的少数の固定された数の役割/カテゴリーにグループ化できる場合は、おそらくACL/RBACを使用するのが最善です。パーミッションが人によって大きく異なる場合、ABACはより優れた、より柔軟なソリューションを提供できます。
ABACパスを選択する場合、最初に行う必要があるのは、 [〜＃〜] xacml [〜＃〜] 標準を読んで理解することです。このドキュメントで提供されている例はXACML互換の構文を使用しており、最初は少し難しいです。標準の互換性のあるソリューションを実装したくないので、そこからの一般的なアイデアだけが必要だと思います。
概念
XACMLは4つの概念とその属性を中心に展開します：subjects、actions、resourcesおよびenvironment。さらにいくつかありますが、これらは最も重要です。他のすべてはそれらの上に構築されます。私がこれらの概念で文章を作るとしたら、それは次のようなものになる可能性があります：subjectsperformactionsonresourcesin a某environment 。これをシナリオに適用すると、次のようになります。
- レスリーが価格マネージャーのWebページを開きます。
- レスリーは、価格マネージャーのWebページを使用して旅行価格を作成します。
属性コレクション
最初に行う必要があるのは、上記の概念の関連属性を収集することです。 XACMLが邪魔にならないようにして、システムが自然に提供するものだけに依存するため、理想的には、特定の属性を割り当てないでください。そして、私たちは持っています：
件名
システム内の任意のアクター（人であれサービスであれ）です。私たちの主題はレスリーです。レスリーを一意に識別するために必要な属性は何ですか？おそらく次のうちのいくつか：_first name_、_last name_、_e-mail_、ssn、_company id_、position(s)。
アクション
被験者が行った行動。標準のCRUD操作またはより複雑なものにすることができます。アクションは_open/view_とcreateです。これらのアクションの属性は、使用しているWebアプリケーションフレームワークによって異なる場合があります。リソースについては、この後で詳しく説明します。
リソース
かなり自明です。私たちのリソースは、_price manager page_、_travel prices_および_the newly created price_です。あなたが本当に望めば、もっとたくさんあるかもしれません。ユーザーが実行できないアクションを非表示にすることができます。例えば。 _create price button_は、ユーザーが価格を作成する権限を持っているかどうかに基づいて表示/非表示にできるリソースにすることができます。ユーザーが価格のリストを表示する唯一の方法はこのページを経由する可能性があるため、スタックをさらに下に移動するのではなく、このレベルで認証を実施することをお勧めします。
リソースへのアクセスは、特にデータベースからのものへの実装が最も複雑です。より細かいオプションは、行レベルのセキュリティです。一部のデータベースは、ある程度サポートしています。一部のXACML実装者は、SQLスーパーセットを作成するまでに至っています。これは実際には承認の必要性に依存しますが、実行したくないことの1つは、テーブルからすべてを取り出して、何を表示するかを決めることです。権限セットでリソースをグループ化し、APIの背後でそれらを抽象化して、APIエンドポイントで認証を実施できます。
環境
私はそれを適切に定義することはできません（XACMLにも適切な定義がありません）が、これがすべて発生する「バブル」であるとしましょう。これには、_web application_、_web server_、_operating system_、browser、officeが含まれます。 _ip address_、_time of day_、_user locale_、_user agent_、_operating system version_などの属性を抽出できます。これらを使用して、アプリケーションでサポートされていない環境（古いブラウザー、古いオペレーティングシステム、ネットワーク外のコンピューター、営業時間外のアクセスなど）からのユーザーアクセスをブロックすることもできます。
認可リクエスト
必要なすべての属性を収集したら、それらを承認リクエストにまとめて、これらの属性の値に基づいて承認決定を行うことができるエンティティに転送します。 XACMLリングアでは、これらの属性を収集し、そのときの決定を実施する場所をポリシー実施ポイント（PEP）と呼び、決定を行うポイントをポリシー決定ポイント（PDP）。属性値が取得される場所は、ポリシー情報ポイント（PIP）と呼ばれます。 PEP、PDP、PIPはアプリケーションの一部であり、外部システムである場合があります。 XACML標準では、これらが相互に通信する方法の図を見つけることができます。
決定プロセス
意思決定プロセスはrulesに基づいています。ルールはポリシーにグループ化でき、さらにポリシーセットにグループ化できます。 。これらのそれぞれにtargetがあります。ターゲットは、承認リクエストに適用されるルールがあるかどうかを決定するために使用されます。フィルターと考えてください。ターゲットには、属性名と値を使用して構築された条件が含まれています。たとえば、アプリケーションのルールは次のようにグループ化できます。
Webアプリケーション（ポリシーセット） |-ターゲット：アプリケーション名== "Webアプリケーション" `-バージョン1.0（ポリシーセット） | -ターゲット：application-version == "1.0" `-価格マネージャー（ポリシー）を表示 |-ターゲット：web-page-name =="価格マネージャー "&& action- name == "view" `-レスリーは価格マネージャー（ルール）を表示できます |-target：subject-name ==" Leslie " `-許可：許可
PDPは、上記のセットのすべてを、認証リクエストの属性値と照合します。一致するルールがない場合はどうなるかは、PDPの実装によって異なります。 PDPが決定（allow、denyまたは_not-applicable_）を行うと、リソースへのアクセスを許可または拒否することによってPDPに作用するPEPに送り返します。 PDPは、応答に加えて、PEPが実施プロセスで満たす必要がある、または満たすべきobligationsおよびadvicesのリストを送信できます。ルールの保存方法（テキストファイルまたはデータベース）に応じて、管理者は標準のテキストエディターまたはカスタム編集アプリケーションを使用して、必要に応じてこれらを変更できます。 Leslieの価格マネージャーへのアクセスを取り消すと、許可がallowからdenyに単純に変更され、PEPはその仕事を許可します。
執行
これはテクノロジースタックに大きく依存します。一部のWebフレームワークには自然な強制ポイントがあります（ASP.NET MVCには属性フィルターがあります）。ビジネス層は、そのような実施ポイントを定義する必要がある場合があります。サービス（マイクロサービスを考える）エンドポイントまたはUIレベルで強制を適用する方が簡単であることがわかりました。
他の利点
これを実装することの素晴らしい副作用は、他の目的に使用できるかなり豊富な監査証跡を作成することです。