前の記事で、属性ベースのアクセス制御とは何か、そして今日最も一般的な役割ベースのアクセス制御と比較した場合の利点について説明しました。 XACMLと呼ばれる既存の標準を通して、ABACをより詳細に調べる時が来ました。



この規格はすでに3番目であり、おそらく最新版ではなく、その歴史は2003年に遡ります。 OASIS組織は、標準を監督およびサポートします。 この標準では、システムに必要なコンポーネント、その目的、相互作用および使用方法について説明しています。 実際、必要なものはすべて、細部まで網羅しています。



この記事では、ビジネスルールをセキュリティポリシー、セキュリティシステムの主要コンポーネント、その統合、および標準の影響を受けないが重要で興味深い他の側面の形で表現する方法について説明します。 すべての読者に、これらの質問をさらに詳しく知っていただくようお願いします。 コメント、コメント、質問、批判も歓迎します。



セキュリティポリシー

ルール

方針

ポリシーセット

システムの主なコンポーネント

ポリシー管理ポイント

ポリシー情報ポイント

ポリシー決定ポイント

ポリシー実施ポイント

例

舞台裏に残っているもの

標準を超えて

属性は任意です

インターフェイスとアクセス制御

データフィルタリング

管理パネルの概念

ポリシー編集

ポリシーセットの編集

ポリシー検索

指定されたコンテキストで利用可能なアクション

ポリシー実行テスト

アプリケーション統合

あとがき



ビジネスルールの変更の概要から標準の分析を開始し、これらのビジネスルールを処理するためのツールと方法の概要を続けます。

セキュリティポリシー

アクションまたはオブジェクトへのアクセスの可能性を担当するビジネスルールは、「アクセスはありますか？」という質問に答え、2つの可能な答えのうちの1つを与えます：「はい」または「いいえ」。 そして、そのようなビジネスルールの条件は、2つの可能な答えのうちの1つを計算する論理式のセットに還元されます。 したがって、セキュリティポリシーは、属性と定数値に作用する論理式です。



セキュリティポリシー自体と、標準がポリシーをどのように記述しているかを詳しく見てみましょう。









標準からのこのスキームは、一見すると少し恐ろしく見えるかもしれませんが、すべてが非常に単純です。 この図は、ビジネスルールを表現するために使用される主要なXACMLオブジェクトの階層を示しています。 階層の最も基本的な粒子はルールです。 ルールはポリシーに結合され、 ポリシーはポリシーセットに結合されます 。

ルール

標準で説明されているように、 ルールは単独では生きられないため、 ポリシーに含める必要があります。 つまり、アクセス権を計算するメカニズムは、 ポリシーの一部としてのみルールを使用して動作し、それ以外は何も実行しません。 それにもかかわらず、 ルールはビジネス感覚の観点から最も飽和した要素です。



ルール自体はいくつかの部分で構成されています。

• 標的
• 効果
• 調子
• 義務（ 義務 ）;
• 推奨事項（ アドバイス ）。

目標は、 ルールとポリシー 、およびポリシーグループの両方で同じ部分です。 したがって、ここで説明されていることは、彼らに当てはまります。 目標は、属性と定数のみで構成される論理式です。 通常、 目標はこの要件を満たすビジネスルールの一部です。 ビジネスルールを部分に分割する主なポイントは、不適切なルール 、 ポリシー、またはポリシーのグループをより迅速に除外することです。 これが必要な理由については、 PDPの説明で詳しく説明します。



より複雑で動的に計算された論理式を含む残りのビジネスルール（存在する場合）は、 ルールの別の部分（条件）に配置する必要があります。 conditionで指定できる要素、その形式、およびそれらに関連するすべてのものも標準で詳細に説明されていますが、その分析はこの記事の範囲外です。



ビジネスルールは、許容的または禁止的です。 ルールでこれを示すために、もう1つの部分があります-効果です。 「許可」または「拒否」の意味を取ることができます。 知っておくべき最も重要なこと： ルールの効果は、このルールを肯定的に評価する場合にのみ機能します。 つまり、 効果は、 ターゲットおよび条件の論理条件の計算結果が「true」（ true ）の場合にのみ適用されます 。 目標または条件の論理式の計算結果が「false」の場合、 ルールの評価結果は「該当なし」になります。 ターゲットまたは条件の論理条件を計算するプロセスでエラーが発生した場合、 ルール評価の結果は「未定義」（ 不定 ）になります。 したがって、 ルールを計算した結果は、「 許可 」、「 拒否 」、「 適用不可 」、「 未定義 」の4つの値のいずれかになります。



かなり単純なルールの形成の例を考えてみましょう。







最初の論理条件は、属性と定数の比較であり、 ルールのターゲットに配置することをお 勧めします （ただし、 条件に配置することもできます ）。 2番目の論理条件は、2つの属性の比較です。 ルール 条件にのみ配置できます 。 ビジネスルールが許可しているため、効果は " allow "として定義されます 。 その結果、次のルールが得られます。







セキュリティシステムへのアクセス権の付与に関する意思決定機能に加えて、追加の機能要件が課される場合があります。 そのような機能の例は、セキュリティ監査です。 義務と勧告があるのは、標準のそのような問題を解決するためです。 概して、両者の違いは、 義務を履行する必要があるという事実のみにあり、 推奨事項は無視できます。 義務と推奨事項の両方は、それらが適用されるルールの効果 、実行されるアクション、および現在のコンテキストに基づいてこのアクションのパラメーターを取得するための式を記述します。



単純な義務の例を考えてみましょう。 誰かがオブジェクトの所有者とやり取りするときに、セキュリティシステムがオブジェクトの所有者に手紙を送る必要がある場合、このために次のようなコミットメントを行うことができます。







推奨事項として、たとえば、デバッグのためにいくつかの情報を記録するアクションの説明を示すことができます。

方針

ポリシーは 、一連のルールを結合するために使用されます 。 通常、このようなルールのセットは1つのビジネスルールです。 したがって、いくつかのタスクが一度に解決されます。 第一に、 ルールで表現された論理条件の小さな部分は、これらの条件を複製することなく簡単に再利用できます。 第二に、このようなパーツへの分割は、ビジネスルール全体の理解を促進し、メンテナンスを簡素化します。



ポリシーの構成：

• 目標（ ターゲット ）;
• ルール
• ルール結合アルゴリズム ;
• 義務（ 義務 ）;
• 推奨事項（ アドバイス ）。

前述したように、 目標は不適切なポリシーを迅速に除外することです。 これが必要な理由は、 PDPレビューの後半で説明します。



ルールセットは、このポリシーのすべてのルールを単にリストします。 ルールの場合と同様に、 ポリシーの計算結果は特定の1つの値です。 これは、 ポリシー に含まれるすべてのルールを評価した結果から、使用可能な4つの値のうち1つだけを取得する必要があることを意味します。 すべてのルールを計算した結果からこのような値を取得するには、 ポリシーに指定されたルールの組み合わせアルゴリズムが適用されます。 この規格は、さまざまな状況で役立ついくつかの異なるアルゴリズムを定義しています。 たとえば、「許可されていない場合は禁止」（ deny-unless-permit ）。 このアルゴリズムは、少なくとも1つのルールの計算結果が「 allow 」である場合にのみ、値「 allow 」を返します。 すべてのルールの評価結果が他の値のセット（「 禁止 」、「 適用外 」、「 未定義 」）である場合、この組み合わせアルゴリズムは「 禁止 」を返します。



この規格には、 ルール評価結果の概念を追加する、はるかに複雑な組み合わせアルゴリズムもリストされています。 このような例は、「定義されていないが許可される」（ 不定{D} ）のように聞こえる結果であり、エラーが発生したルールを参照し、評価が成功した場合の効果は「 禁止 」になります。



単純なビジネスルールに基づくポリシーの例を考えてみましょう。







このビジネスルールは複数の部分に分割され、 ポリシーに結合できる2つの単純なルールから形成されます。







義務と推薦は 規則の記述で少し高く議論されます。

ポリシーセット

ポリシーのグループの目的で指定された一般的な目的に基づいてそれらをより迅速にフィルタリングするために、 ポリシーのグループを結合するために、ポリシーのセットが必要です。 また、コンポーネントにさらに分離するための非常に複雑なビジネスルールがある場合にも適用できます。 構成部分のポリシーのセットは通常のポリシーと非常に類似しています。 唯一の違いは、 一連の ポリシーの場合、 ルールではなくポリシーが結合されること、および標準では、 ルール に対してよりもポリシーに対してわずかに異なる組み合わせアルゴリズムのセットが提供されることです。



ポリシーのセットは以下で構成されます。

• 目標（ ターゲット ）;
• 政治家
• ポリシー結合アルゴリズム 。
• 義務（ 義務 ）;
• 推奨事項（ アドバイス ）。

注意するべき唯一のことは、標準が方針と方針の グループのために同じで異なった組み合わせアルゴリズムの両方について説明するということです。



このための一連のビジネスルールを使用した一連のポリシーの例を見てみましょう。







これら3つのビジネスルールから、3つの同様のポリシーが形成されます。

1. ドキュメント作成ポリシー。
   
   
   
   
2. ドキュメント変更ポリシー。
   
   
   
   
3. ドキュメント削除ポリシー。
   
   
   
   

これらすべてのルールには共通点があります。同じタイプのオブジェクトに対するアクションと特定の時間におけるアクションの可用性を記述します。 したがって、これらを自信を持ってポリシーのセットに組み合わせることができます。







義務と推薦は 規則の記述で少し高く議論されます。



そのため、ビジネスルールをセキュリティシステムが理解できる要素に変えることを標準がどのように提案しているのかを発見しました。 次に、セキュリティシステムを構成するコンポーネントと、これらのビジネスルールがどのように処理されるかを検討します。

システムの主なコンポーネント

ポリシー計算エンジンはシステムの中心的なコンポーネントであり、標準ではポリシー決定ポイント（ PDP ）と呼ばれます。

セキュリティポリシーを計算するには、どこかで作成する必要があります。 システムの別のコンポーネントがこれに責任があります。標準ではポリシー管理ポイント（ PAP ）と呼ばれるポリシー管理メカニズムです。 PDPの計算に必要なデータのもう1つのソースは、ポリシー情報ポイント（ PIP ）と呼ばれる属性値ソースです。 最後になりましたが、コンポーネントはPDPを呼び出し、その応答を正しく処理するメカニズムです。これは、ポリシー施行ポイント（ PEP ）と呼ばれます。

ポリシー管理ポイント

これは、セキュリティポリシー管理が行われるコンポーネントです。 原則として、システム管理者がビジネスルールをポリシーに変換し、 PDPで使用できるようにする特定のインターフェイスを表します。 PAPがポリシーを管理するには、次のことを知っている必要があります。

• 入力の正確さを制御できるようにするためのポリシー構造。
• 論理条件で指定できる関数のリスト。
• 論理条件の関数の引数として指定できる属性のリスト。

ポリシーの構造については上記で説明されており、それらの詳細な説明は標準で提供されています。 関数については、それらの特定のリストがすでに標準で説明されており、それらの動作のロジックも説明されています。 さらに、この標準は、独自の任意の関数を追加する機能を暗示しています。 したがって、必要に応じて、使用可能な機能の最終リストを作成します。このリストの一部をどこかから受け取る必要がある場合があります。



属性に関しては、規格にも多くのことが書かれています。 属性の入力と命名の問題に主に対処しています。 通常、属性自体はビジネスに固有のものであるため、このリストはシステムごとに異なります。 これは、システムが何らかの形で必要な情報を提供できる必要があることを意味します。 また、 ルールで指定された定数をチェックできるようにするために、特定の属性に使用できる値に関する情報を提供することも有効です。 属性名にはローカライズが必要な場合があることに注意してください。 つまり、属性の名前とタイプに加えて、ローカライズ可能な表示名も提供する必要があります。 これにより、 ポリシー自体を変更せずに、異なる言語でポリシーを表示できます。



セキュリティの観点から、 PAPは重要な役割を果たしません。 しかし、セキュリティシステムの管理の観点から、これは最も重要な場所の1つです。 これで、このコンポーネントの目的についてのみ触れました。 セキュリティシステムを管理するためのその潜在的能力は後で調べられるでしょう。

ポリシー情報ポイント

前述のように、 PDPを機能させるには、セキュリティポリシーのソースと属性値のソースの2つのことが必要です。 最初の話をしたばかりですが、今度は2つ目の話をしましょう。 PIPの動作原理は、一見すると非常に簡単です。 入力では、属性の名前を受け取り、出力では、現在の実行コンテキストで見つけることができるすべての値を提供します。 PIPの全体的な複雑さは、その内部構造、属性値を検索する方法と場所にあります。



アクセス制御システムがアプリケーション自体に組み込まれ、 PIPが現在のアプリケーションオブジェクト間で属性値を検索できる場合、たとえば、属性名をオブジェクトプロパティへのパスに変換し、このプロパティの値を取得できます。 アクセス制御システムが別のサービスとして配置され、外部呼び出しを受け入れる場合、 PIPはこの呼び出しから属性値を抽出できる場合があります。 または、 PIPは時刻、日付、IPアドレスなどの現在の環境パラメーターを取得できる場合があります。また、 PIPはいくつかのストアに「移動」して、属性値を検索できる場合があります。 一般に、ここでのすべては、アクセス制御システムの開発者の想像力によってのみ制限されます。

ポリシー決定ポイント

アクセス制御システムの場合、これがおそらく中心的なコンポーネントです。 これは、現在のコールコンテキストに基づいてポリシーが計算される場所です。 PDPは属性のみで動作することを理解することが非常に重要です。 PDPの観点からの属性は、値を見つけて計算式に代入するための共通キーです。 彼は何も知らず、アクション、ユーザー、環境、オブジェクトがあることを知ってはいけません。 これを理解することにより、アクセス制御システムのフルパワーを最大限に効率的に使用できます。



ほとんどの場合、疑問がすぐに発生する可能性があります： PDPは、区別しない場合、現在のアクションのコンテキストで計算する必要があるセキュリティポリシーをどのように理解しますか？ 答えは非常に簡単です。 彼は利用可能なすべてのポリシーを単に計算し、これに基づいて彼の決定を形成します。 これは、パフォーマンスの観点から見ると、おかしなアイデアのように思えるかもしれませんが、よく見ると、すべてが適切に配置されています。



まず、アクセスチェック中に毎回数千のルールを計算するプロセスはひどいようです。 大規模なシステムでは通常、役割の数がそのような順序で計算されるという事実によって、数千の観点から考える必要があります。 しかし、 政治家は役割ではありません。 適切に設計された多数のポリシーで 、数千の役割を置き換えることができます。 ですから、ここで他の方法で考える必要があります。 さらに、 ポリシーの構造を検討する際に既に述べたように、その構造で提供される目的は、現在のコンテキストに適さないポリシーを迅速に除外するように設計されています。 実際、ポリシーの単位のみが計算されます。 一般に、ここではさまざまな最適化手法を適用できますが、これは想像力とリソースの広さにも依存します。



どのポリシーが現在適用可能かを理解するために、 PDPは、指定された属性の現在の値をそこに代入することにより、それぞれのポリシーの目的を計算する必要があります。 PDPはPIPを使用してそれらを見つけます。 PIPの検索ロジックは異なる場合があるため、 PIPのコレクション全体を同時に使用できます。各PIPは、独自のロジックに基づいて、指定された属性の値を検索します。 PDPはすべてのPIPを同時にポーリングして目的の属性を見つけ、応答から受信した値の配列を形成します。 標準では、すべての属性は、各属性について、以前は未知のサイズの値の配列を返すことができるという事実に焦点を当てています。 複数のポリシーまたはポリシーの グループが現在のコンテキストで計算された場合、それらの計算の結果は、 PDP用に事前定義された組み合わせアルゴリズムとも結合されます。



他の要素とともに、 ルール 、 ポリシー、またはポリシーの グループに 義務または推奨事項を割り当てることができます。 これらは、応答の一部としてPEPに渡されるいくつかの属性の値を評価する式で構成されます。 また、その計算は、 ルール自体、 ポリシー、またはポリシーのグループの計算結果に影響を与える可能性があります。

目的がルール 、 ポリシー、またはポリシーのグループの計算から得られる効果と一致する義務と推奨事項のみが計算されます。 義務または推奨属性の値の計算が不確実な結果で終了した場合、対応するルール 、 ポリシーまたはポリシーの グループの計算結果も不確実になります。



すべての計算の結果は、アクセスの許可に関する決定を含む回答である必要があります。これは、既に上記で説明した4つの値のいずれかをとることができます。 さらに、応答には義務または推奨事項のリストが含まれる場合があります。 規格には、 義務または推奨事項の最終リストを作成するためのすべての条件が記載されていることに注意してください。

ポリシー実施ポイント

PEPは、すべてのアクセス制御アクションの開始点と終了点の両方です。 出発点としてのPEPの責任には、要求の準備とPDPの呼び出しが含まれます。 本質的に、 PEPは現在の実行コンテキストをPDPに渡す役割を果たします。 現在のコンテキストには、アクションを実行するサブジェクト（名前、役職、部門、ブランチ）、アクション（アクションの名前）、アクションのオブジェクト（タイプ、番号、所有者）、環境（曜日、日付、 IPアドレス）。 これらの属性のすべてが集まり、 PDPに渡されます。



最後のポイントとして、 PEPはPDPからの応答を受信し、その解釈と正しい実行を担当します。 アクセスを許可する決定は4つの値のいずれかを取ることができるため、 PEPはそれらを2つに変換できる必要があります（「 allow 」または「 deny 」）。 値の解釈に応じて、 PEPは2つのタイプに分けられます。 許可ベースの PEPは、「明示的に禁止されていない許可」の原則に基づいて動作します。 これは、否定的な決定の場合にのみアクセスが拒否されることを意味します。 残りの3つのケースでは、アクセスが許可されます。 拒否ベースの PEPは、「禁じられているものだけが明らかに許可されていない」という原則に基づいて行動します。 これは、肯定的な決定の場合にのみアクセスが許可されることを意味します。 残りの3つのケースでは、アクセスが拒否されます。



アクセスを許可する決定に加えて、 PDPからの応答には、 PEPが準拠しなければならない義務と推奨事項のリストが含まれる場合があります。 上記のように、 義務は義務であり、その適用が必要です。 そしてこれはPDPから受け取った決定の実行にマークを残します。 PEPが義務を果たす方法を理解していない場合、 PEPのタイプに応じて、禁止を取り消すか、許可を取り消します。 PEPが 許可している場合、「 禁止 」の決定がPDPから受け取られ、 義務を果たすことができない場合、 PEPは実行を許可します。 「 未定義 」の決定を受け取った場合と同じように機能します。 逆に、 PEPが 禁止的である場合、 PDPからの決定の値は「 許可 」であり、 義務を果たすことができないため、 PEPは実装を禁止します。 PDPのソリューションが「 未定義 」であるかのように機能します。 同様に、 推奨事項は実装されない場合があり、これはアクセスを許可する決定に影響しません。

例

クライアント、アプリケーションサーバー、およびアクセス制御システムの主要コンポーネントで構成されるアプリケーションの場合のアクセス制御システムの例を考えてみましょう。

1. 各アプリケーションには独自のビジネスモデルがあります。 このモデルには、オブジェクト、その属性などが格納されています。これらの属性は、アクセス制御システムの属性モデルのデータのソースです。
2. このモデルに基づいて、PAPはこれらの属性を使用するポリシーとポリシーのグループを作成します。
3. PAPで作成されたポリシーおよびポリシーグループは、PDPがアクセスするリポジトリに保存されます。
4. ユーザー（サブジェクト）が何らかのアクションを実行する場合、ユーザーはインターフェイスを使用して対応する操作を実行し、それによってアプリケーションサーバーに要求を送信します。 アプリケーションサーバーでは、この要求はアプリケーションロジックに分類され、ビジネスロジックに入る前に、実行の可能性についてテストされます。
5. これを行うには、アプリケーションロジックに組み込まれたPEPが要求を生成し、現在のコンテキスト（ユーザー、アクション、オブジェクトなど）のすべての属性の値をそこに配置し、PDPに渡します。
6. PDPは、主にリポジトリからすべてのポリシーとポリシーグループを受け取ります。
7. 次に、PDPは、ポリシーおよびポリシーグループで指定されたすべての必須属性の値を取得するために、すべてのPIPに要求を送信します。
8. 各PIPは、独自のロジックによって導かれ、PEPに渡された現在のコンテキストを使用して、指定された属性の値を検索します。 PIP操作のロジックは、一部のストレージから値を取得することを意味する場合があり、この目的でコンテキストからの値を使用します（ルールとして、必要なエンティティのキ​​ー値として）。
9. その後、PIPは応答を生成し、PDPに送信します。
10. 受信したデータに基づいて、PDPはポリシーおよびポリシーのグループを計算し、アクセスの許可に関する決定を受信し、それを新しい応答に追加します。 さらに、PDPは、ポリシーまたはポリシーのグループに関連付けられた義務と推奨事項を計算し、それらを応答に追加します。
11. 受信した応答は、実行のためにPEPに渡されます。
12. PEPは受信した応答を分析し、義務と推奨事項を満たし、肯定的な決定が下された場合、呼び出しをビジネスロジックに転送します。

舞台裏に残っているもの

この規格はすべてを最小の詳細までカバーしているため、この記事では小さな詳細は省略しました。 標準では、ルールの条件として指定できる式の説明に多くの注意が払われています。 どのような機能が必要ですか？ どのような種類のデータを使用できますか？ これらの関数はどのように計算する必要がありますか？ 属性のカテゴリーは何ですか？ どんな組み合わせアルゴリズムがありますか？ これらはすべて、全体像の理解に影響を与えるべきではない詳細です。 はい、それらの詳細な分析はABAC自体とはほとんど関係がなく、実装の技術的な詳細とは関係ありません。

標準を超えて

この規格では、細部に至るまで多くのことが説明されていますが、いくつかの点はまだ照らされていません。 さらに、これらの興味深い点に触れて、それらについてさらに詳しく説明したいと思います。

属性は任意です

属性を任意に指定できることをもう一度説明します。 異なるカテゴリへの属性のすべての分割は、人々によるより便利な認識のために行われます。 PDPは、サブジェクト属性とオブジェクト属性またはアクション属性を区別しません。 PDPの属性の名前、カテゴリ、所有者などは、何らかの論理式で不明な変数の値を見つけるために必要なキーにすぎません。 したがって、システムで属性を使用する可能性は、実際には、開発者の想像力と、おそらくは技術リソースによってのみ制限されます。 主なことは、すべてのPIPがそのような属性の値を返すことができるということです。



たとえば、エンティティの現在の属性値と新しい属性値の両方に同時に制限が課されるビジネスルールがよく見られます。 つまり、エンティティを変更しようとするときは、提案された変更の前後に変更可能な属性の値を確認する必要があります。 このようなチェックは、変更するエンティティと属性、変更する新しい値を知るアプリケーションロジックに組み込むことができます。 たとえば、属性名のプレフィックス（古いまたは新しい）に基づいて、古いまたは新しい属性値を取得できる特別なPIPを作成するだけです。 現在のコンテキストに古いエンティティ値が存在しない場合、そのようなPIPはキー属性の値に基づいてストアからそれらを取得できる場合があります。 幸いなことに、システムに必要なメタ情報はすべてあるはずです。

インターフェイスとアクセス制御

ユーザーの利便性のために、そのような実装が不可能であることを事実を通知するよりも、インターフェース上でアクションを実行する機会をユーザーに与えない方がはるかに優れています。 ユーザーがアクションを実行できない場合は、インターフェイスの「禁止」コントロールを無効にするか、すべて非表示にすることをお勧めします。 これにはアクセス制御システムを使用することもできます。 現在のコンテキストをそのコンテキストに渡し、得られたソリューションに基づいて、コントロールで何をする価値があるかを理解する必要があります。

データフィルタリング

この規格では、アクションの実行を制限する可能性について、これに関する複雑なルールを使用して詳しく説明しています。 しかし、データの一部の表示へのアクセスを制限する必要がある問題の解決については何も言われていませんでした。つまり、実際には、このデータをフィルタリングします。 この問題の解決策は、セキュリティシステムの開発者にかかっています。 このようなビジネスルールの例を見ると、オブジェクトにアクセスするためのビジネスルールと同じ論理式であることがわかります。 さて、これは論理式なので、データを照会するための述語として使用できます。



最初に思い浮かぶのは、 PDPをトレーニングして、たとえばORMに転送するためのビジネスルールから述語を作成することです。 通常のポリシーとの違いは、必要な属性がすべて存在する場合、アクションの可能性を記述するポリシーが計算されることです。一方、データフィルタリングを説明するポリシーのすべての属性の値は、フィルタリング自体と、各特定のオブジェクトに述語を適用するときにのみ認識されます。



もちろん、すべてのビジネスルールから述語を作成することは過剰であり、原則的には不要です。これは、述語が形成される前に一部の属性がまだわかっているためです。そのため、標準の場合と同様に、ビジネスルールの一部を除外し、必要なルールのみを残すことができます。ただし、選択したポリシーが1つでも非常に大きい場合があります。また、ポリシーの計算結果には4つではなく4つの値を使用できることを考慮すると、PEPは許可と拒否の両方を行うことができるという事実、さまざまな組み合わせアルゴリズムが存在するという事実を理解する必要があります。巨大な述語はこれらすべてから形成されます。このような述語は、条件付きANDおよびORで結合された多くの式で構成されます。



この問題をいくつかの段階で解決することもできます。最初の段階で、すべての既知の属性の値を結果の述部に代入し、何が起こったかを計算できます。これにより、オブジェクト自体の属性を除くすべての属性の値を知る必要があるため、述語を大幅に削減できます。 2番目の段階では、たとえばQuine – McCluskeyメソッドを使用して、ブール関数を最小化することにより、残りの述部を単純化することができます。その後、述部は可能な限りコンパクトになります。そして、すべては、たとえば、リクエストを生成するORMの能力と、このリクエストを処理するデータベースの能力に依存します。



したがって、たとえば、ビジネスルール：







述語を生成







します。コンテキストから値を代入した後のこの述語は、次の形式を取ります。







単純化後は、以下のみが残ります。

管理パネルの概念

上記のように、アクセス制御システムにとって、管理パネルは最も重要なコンポーネントです。そして、これは驚くことではありません。ポリシーを作成および編集するタスクに加えて、他の多くの同様に重要な問題を解決できます。ポリシーを



編集することから始めましょう。ポリシーの標準と例を見ると、XACMLで記述された非常に単純なビジネスルールでさえ、特に準備がなければ理解と修正が難しいことが明らかになります。多少のトレーニングを行っても、この形式で多少複雑なビジネスルールを変更することは非常に問題です。





管理パネルは、 ポリシーを編集するという点でユーザーの生活を大幅に簡素化できます。ユーザーがビジネスルールをより簡単な形式で設定できれば、それが後でXACMLに変わります。 また、管理パネルは、他の多くの同様に重要なタスクを解決できます。

ポリシー編集

ポリシーを編集するための便利で思慮深いインターフェースは、アクセス制御システムで重要な役割を果たします。 ルールが人間の言語に近ければ近いほど、 ルールの管理と維持が改善されます。 インターフェイスはできるだけシンプルで、理解しやすく、同時に機能的でなければなりません。 これは、タイプAND 、 OR 、 および括弧内の式、属性のタイプの明示的な指示などの構造の可能な限り拒否を意味する場合があります。属性またはポリシーの構造に関するメタ情報に基づいて計算または決定できるものはすべて、インターフェースから削除することができ、削除する必要があります、ビジネスルールを入力するために必要な最小限のみを残します。このルールは、できるだけ人間の言語に近いものでなければなりません。 入力を簡単にするために、IntelliSense、便利なドロップダウンリスト、さまざまなヒントなどのテクノロジーを適用できます。 主な目標は、直感的で便利なインターフェイスを作成することです。



以下の概念図は、 「注文の作成」 ポリシーの編集を示しています。 ウィンドウの上部に目標が示されています-このポリシーが適用される対象。 以下は、ルールを結合するためのアルゴリズムです-「 許可されない場合は禁止 」。 以下は、チェックされる条件と、各ルールの実装の結果となる効果で構成される3つのルールです。

ポリシーセットの編集

上記のように、より便利な管理とフィルタリングを行うには、 ポリシーセットが必要です。 このウィンドウには特に注目すべき点はありませんが、その存在を忘れてはなりません。



ウィンドウの左側の次の概念図は、すでに作成されているポリシーとポリシーの セットのリストを示しています。 ポリシーセットはネストできます。 ウィンドウの右側で、編集自体が行われます。 一連のポリシーについて、 目標を設定することもできます- 目標全体をセット全体に適用します。 以下は、キットに含まれているもののリストです。 以下は、 義務の表示例です。オブジェクトへのアクセス権を付与するという積極的な決定があった場合に、管理者に電子メールメッセージを送信するアクションです。 レイアウトからわかるように、 義務の既存の属性を使用できます（ユーザー名またはオブジェクトタイプ）。 これは義務を使用する十分な機会を与えます。

ポリシー検索

発生する可能性のある問題の1つは、それらに関連するポリシーまたは属性を見つける必要があることです。 目標 、 ルール 、 ポリシーなど、いくつかのカテゴリを一度に検索するユニバーサル検索ボックスを作成できます。 したがって、追加の指示なしで、すべてのカテゴリで検索が行われ、下の概念図に示す形式で結果が提供されます。 表示された結果では、検索された単語が強調表示され、検索されたテキストが検出されたルールの部分（ goal ）が表示されます。

指定されたコンテキストで利用可能なアクション

アクセス制御システムの重要なタスクの1つは、ユーザーが利用できるアクションを検索することです。 このような機能は、セキュリティ担当者または管理者が必要とする場合があります。 アクセス権の検証は動的であり、どのポリシーが肯定的に評価されるかが事前にわからないため、そのような情報の表示は困難に思えるかもしれません。 しかし、これは一見すると思えるほど深刻な問題ではありません。 結局、ユーザー属性の値はすでにあり、少なくともこれらの値に対応するポリシーを選択できます。 さらに、より明確な理解またはより正確な検索のために、関心のある他の属性の値を指定できます。必要なコンテキストまたはコンテキストの一部を示し、そのような属性値で利用可能なものを確認します。 さらに、部分的に表示されたポリシーを表示できます。 それらの場合、実装に必要な残りの条件を表示できます。

ポリシー実行テスト

別の重要な問題は、管理者の意見では、すべてが異なる方法で行われなければならないという事実にもかかわらず、このまたはそのポリシーがこのように計算される理由を理解していないことです。 ポリシーが設定され、すべての属性が正しく指定されているが、まだアクセスできない状況は、非常に不快な場合があります。 政治家や政策グループは多くの論理的条件で構成されている可能性があるため、この問題を手動で分析するのは退屈であり、エラーを伴う可能性があります。 ポリシーは徐々に計算される多くの条件で構成されるため、この計算のプロセスを視覚化できます。 管理者は、便利なインターフェイスを使用して、目的のコンテキストを指定し、 ポリシーを選択し、計算プロセスを段階的に検討できます。

アプリケーション統合

統合は、既存のアプリケーションと新しいアプリケーションの両方で実行できます。



新しいアプリケーションとの統合は、かなり単純でなければなりません。 開発者は最初に属性モデルについて知っているため、その概念を考えて、必要に応じてすぐに開発できるようになります。 すべてがうまく機能するためには、2つの基本的なことを実装する必要があります。 まず、属性について必要なすべてのメタ情報がシステムに存在する必要があります。 このメタ情報には、名前、タイプ、使用可能な値、ローカライズが含まれる場合があります。

次に、 PEPをアプリケーションに正しく埋め込む必要があります。 通常、 PEPは 、ビジネスロジックを呼び出す前のどこかに、アプリケーションロジックに埋め込まれます。 システムにメタ情報を入力してPEPを正しく配置するのが適切な場合は、ビジネスルールとそれに応じてポリシーを変更するときに、プログラマーの関与は必要ありません。 以前は不明で計画外のビジネスルールでも。



既存のアプリケーションとの統合は、さまざまな方法で実行できます。 現在、ほとんどのアプリケーションはロールベースの1次元アクセスモデルを使用しており、属性への切り替えは多次元モデルでは困難な場合があります。 ロールモデルから属性モデルへの直接的な移行は、いくつかの理由により、非常に複雑、高価、または不可能にさえなる可能性があります。 それでもこのような移行が可能な場合、アクションの原則は最初から統合する場合と同じになります。 属性モデルにメタ情報を入力し、必要なすべての場所にPEPを埋め込む必要があります。



そのような移行が不可能な場合は、いくつかの段階で行動を試みることができます。 最初の段階で、ロールモデルの上に属性モデルを追加する必要があります。 ポイントは、アドインがロールモデルを属性モデルに変換し、属性スタイルでビジネスルールを設定し、それをロールモデルに戻すことができることです。 はい、最初は奇妙に思えるかもしれません。 しかし、このようなアプローチは、属性モデルの多くの利点をもたらし、役割モデルの多くの欠点を取り除くことができます。 そして、第2段階では、ロールモデルの形で過剰なレイヤーを徐々に放棄し、属性モデルに完全に切り替えることができます。

両方のケースの詳細な分析は非常に広範囲であり、現在の記事の範囲を超えています。

あとがき

XACML標準の問題と親しみを紹介することで、読者がABACを詳しく見て、その動作の原理をよりよく理解するのに役立つことを願っています。また、標準外で触れられたポイントが、ABACへの切り替え時にサポートを提供できるこの分野のさまざまな側面を考慮できるようになることを願っています。