ACLとRBACについて読んだとき、私はそれを簡単に理解しているようです-アセットへのアクセスが許可されているユーザー名またはロールがあります。また、それらを実装する方法も確認できます。

すなわち、この画像は、ACLとRBACの明確なビューを私に提供します（上に基づいてデータベーステーブルを設計し続けることができるように）：（ プレスブックの 画像提供）

私が苦労しているのはABACです。これまでに見つけたさまざまな画像は、手が波打ったり過度に複雑であったり、承認を行うサードパーティの外部エンティティの使用を提案したりしています。または、奇妙な属性の例を挙げてください。使用方法は完全にはわかりません。

開始例

それでは、実際の生活から始めましょう。たとえば、70〜200人の会社があるとします。そして、私が保護する資産は、さまざまなページがたくさんあるウェブサイトです。特定の人に特定の資産へのアクセスを許可したい。

たとえば、あるLeslieユーザーがと呼ばれるWebページにアクセスPrice ManagerできるようにしてTravel、そのページの価格グループの価格のみを管理できるようにしProduct、同じページのグループの価格は管理できないようにします。ABACを使用してこれをどのように実装しますか？

これまでのところ、私は、Leslieいくつかの属性（ただし、どの属性とこれらの属性は何か？）を割り当て、それらを格納するデータベーステーブルを作成できると思います。次に、これらの属性を調べ（LeslieRBACのように「役割」とは見なさない）エンジンを設計し、そこからページへのアクセスを許可するかどうかを決定します。そのエンジンはどのように見えますか？単純な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つの概念とその属性（サブジェクト、アクション、リソース、環境）を中心に展開します。さらにいくつかありますが、これらは最も重要です。他のすべてはそれらの上に構築されます。これらの概念を使って文章を書くとしたら、それは次のようなものになる可能性があります。被験者は特定の環境でリソースに対してアクションを実行します。これをシナリオに適用すると、次のようになります。

• レスリーが価格マネージャーの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標準では、これらが相互に通信する方法の図を見つけることができます。

決定プロセス

意思決定プロセスはルールに基づいています。ルールはポリシーにグループ化でき、さらにポリシーセットにグループ化できます。これらのそれぞれにターゲットがあります。ターゲットは、承認リクエストに適用されるルールがあるかどうかを決定するために使用されます。フィルターと考えてください。ターゲットには、属性名と値を使用して構築された条件が含まれています。たとえば、アプリケーションのルールは次のようにグループ化できます。

Webアプリケーション（ポリシーセット）
|-ターゲット：アプリケーション名== "Webアプリケーション"
`-バージョン1.0（ポリシーセット）
    |-target：application-version == "1.0"
    `-価格マネージャーを表示（ポリシー）
        |-target：web-page-name == "price manager" && action-name == "view"
        `-レスリーは価格マネージャーを表示できます（ルール）
            |-target：subject-name == "レスリー"
            `-許可：許可

PDPは、上記のセットのすべてを許可リクエストの属性値と照合します。一致するルールがない場合はどうなるかは、PDPの実装によって異なります。PDPは決定（allow、denyまたはnot-applicable）を行うと、それをPEPに送り返します。PEPは、リソースへのアクセスを許可または拒否することによってPEPに作用します。応答とともにPDPは、のリストを送信することができますobligationsし、advicesPEPの必要があることをまたは執行過程で果たすべきです。ルールの保存方法（テキストファイルまたはデータベース）に応じて、管理者は標準のテキストエディターまたはカスタム編集アプリケーションを使用して、適切と思われるようにこれらを変更できます。レスリーの価格マネージャーへのアクセスを取り消すと、許可がからallowに変更されます。deny、PEPがその仕事をすることを認めた。

執行

これはテクノロジースタックに大きく依存します。一部のWebフレームワークには自然な強制ポイントがあります（ASP.NET MVCには属性フィルターがあります）。ビジネス層は、そのような実施ポイントを定義する必要がある場合があります。サービス（マイクロサービスを考える）エンドポイントまたはUIレベルで適用を適用する方が簡単であることがわかりました。

他の利点

これを実装することの優れた副作用は、他の目的に使用できるかなり豊富な監査証跡が作成されることです。