XACMLとは?
その名が示す通り、eXtensible Access Control Markup Language (XACML) は、主にアクセス制御に使用される XML ベースの言語です。これは、Organization for the Advancement of Structured Information Standards (OASIS) によって定義された標準です。
XACML 3.0 は、この標準の最新バージョンであり、2013年にリリースされました。特定のアクセスコントロールモデルを指定しているわけではありませんが、XACMLはしばしば 属性ベースのアクセス制御 (Attribute-based access control, ABAC) ポリシーの実装に利用されます。XACMLを使用して ABAC ポリシーを表現する簡単な例を見てみましょう:
<PolicySet PolicySetId="ABAC_Policies" PolicyCombiningAlgId="urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides">
<Description>ABAC Policies</Description>
<Policy PolicyId="Policy1" RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides">
<Description>Employees can read data</Description>
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"
/>
</Match>
</AllOf>
</AnyOf>
</Target>
<Rule RuleId="Rule1" Effect="Permit">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">employee</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"
/>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
<Rule RuleId="Rule2" Effect="Deny">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">user</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"
/>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
</Policy>
<!-- ...other policies... -->
</PolicySet>
XACMLは、自己説明的な命名規則をうまく行っていると言えます。この言語は人間に読みやすく、理解しやすいように設計されています。
要するに、このポリシーは、従業員がデータを読むことが許可されており、ユーザーがデータを読むことが拒否されることを述べています。キーコンポーネントを分析することによってポリシーを分解してみましょう:
<PolicySet>
: ポリシーセットのルート要素。PolicySet
は、複数のPolicy
やPolicySet
要素を含めることができ、ポリシーの階層を形成します。<Policy>
: 1つ以上のルールを含むポリシー。各ポリシーは以下を持つことができます:- ポリシーが適用される条件を指定する
Target
要素。 - アクセス制御ルールを定義する複数の
Rule
要素。 - ルールを組み合わせて判断を下す方法を指定する
RuleCombiningAlgId
属性。
- ポリシーが適用される条件を指定する
<Rule>
: アクセスが許可されるまたは拒否される条件を定義するルール。各ルールは以下を持ちます:- ルールが適用される条件を指定する
Target
要素。 - ルールがアクセスを許可するか拒否するかを指定する
Effect
属性。
- ルールが適用される条件を指定する
[!Note] XACMLの利用可能なコンポーネントと属性は、ここで述べたものに限られていません。要素と属性の完全なリストについては、 XACML 3.0 の仕様 を参照してください。
以下に、さまざまなキーコンポーネント間の関係を示す図を示します:
例における他の要素や属性の詳細な説明は、次のセクションで提供されます。
XACMLの仕組み
簡単にするために、上記のポリシーセットで定義されているポリシーが1つだけあると仮定します。ポリシー評価プロセスをトリガーするために、決定リクエストをポリシー適用ポイント (PEP)からポリシー決定ポイント (PDP)に送信する必要があります。PDPはリクエストをポリシーと照合して評価し、PEPに認可決定を返します。
- PEP: 決定リクエストを PDP に送信し、 アクセス制御 (Access control) を実行して、認可決定を適用するコンポーネント。
- PDP: 決定リクエストをポリシーと照合して評価し、認可決定を返すコンポーネント。
シェイクスピア風の言葉を置き換えるために、実世界の例を使用しましょう。従業員が特定のリソースにアクセスすることを許可する Web アプリケーションがあり、そのアプリケーションが XACML ベースの認可システムと統合されていると仮定します。
従業員がリソースにアクセスしようとすると、Web アプリケーション(PEP)は認可システム(PDP)に決定リクエストを送信します。認可システムが XACML ポリシーと照合してリクエストを評価した後、Web アプリケーションに認可決定を返します。
決定リクエスト
XACMLにおける決定リクエストは、次の重要なコンポーネントで構成されます:
- Subject: リソースへのアクセスを要求するエンティティ。ユーザー、デバイス、またはその他のエンティティである可能性があります。
- Resource: アクセスされるリソース。ファイル、データベース、API エンドポイント、またはその他のリソースである可能性があります。
- Action: リソース上で実行されるアクション。読み取り、書き込み、削除、またはその他のアクションである可能性があります。
- Environment: アクセスリクエストが行われるコンテキスト。時間帯、場所、またはその他のコンテキスト情報を含むことができます。
以下は、XACMLでの決定リクエストの例です:
<Request>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>http://example.com/data</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>read</AttributeValue>
</Attribute>
</Attributes>
<Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:subject">
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>employee</AttributeValue>
</Attribute>
</Attributes>
</Request>
評価プロセス
PDPがポリシーセットを取得すると、以下の手順で決定リクエストが評価されます:
- ターゲットマッチング: 各ポリシーに対して、PDPはリクエストがポリシーのターゲットと一致するかどうかを確認します。リクエストがターゲットと一致する場合、PDPはルールを評価します。
- ルール評価: PDPはポリシー内の各ルールを評価します。ルールのターゲットがリクエストと一致すると、PDPはルールの条件を評価します。条件が
true
の場合、PDPはルールの効果(許可または拒否)を返します。条件がfalse
の場合、PDPは次のルールの評価を続行します。 - ルール組み合わせ: PDPは、ポリシーの
RuleCombiningAlgId
属性に基づいて、ポリシー内のすべてのルールの効果を組み合わせます。その組み合わされた効果がポリシーの決定として返されます。 - ポリシー組み合わせ: ポリシーセットに複数のポリシーが含まれている場合、PDPはポリシーセットの
PolicyCombiningAlgId
属性に基づいて、すべてのポリシーの決定を組み合わせます。その組み合わされた決定が最終的な認可決定として返されます。
例1
たとえば、例のポリシーセットで、決定リクエストが上記のようであると仮定します。PDPはPolicy1
ポリシーに対してリクエストを次のように評価します:
ターゲットマッチング
ポリシーの Target
は、アクションIDが read
であるすべてのサブジェクトがポリシーによって評価されるべきであると指定しています。リクエストのアクションが read
であるため、リクエストはポリシーのターゲットと一致します。
ルール評価
ポリシーには2つのルールがあります:
Rule1
: リクエストのサブジェクトIDがemployee
であるため、ルールの条件はtrue
と評価され、ルールの効果はPermit
です。Rule2
: リクエストのサブジェクトIDがuser
でないため、ルールの条件はfalse
と評価され、ルールの効果はNotApplicable
です。
ルールとポリシーの組み合わせ
Policy1
はdeny-overrides
ルール結合アルゴリズムを使用しているため、Rule1
が許可するため、ポリシー決定はPermit
です。- ポリシーセットも
deny-overrides
ポリシー結合アルゴリズムを使用しているため、最終決定もPermit
です。
評価プロセスの非公式の図を以下に示します:
例2
次に、すべての属性が同じで、サブジェクトIDが employee
でなく user
の場合の別の決定リクエストを検討します。
ターゲットマッチング
アクションは変更されていないため、リクエストはまだポリシーのターゲットと一致します。
ルール評価
Rule1
: リクエストのサブジェクトIDがemployee
でないため、ルールの条件はfalse
と評価され、ルールの効果はNotApplicable
です。Rule2
: リクエストのサブジェクトIDがuser
であるため、ルールの条件はtrue
と評価され、ルールの効果はDeny
です。
ルールとポリシーの組み合わせ
Rule2
がアクセスを拒否するため、ポリシー決定はDeny
になり、その効果はRule1
のNotApplicable
効果を上書きします。- ポリシーセットの
deny-overrides
ポリシー結合アルゴリズムは、最も厳格な決定を返すため、最終決定はDeny
になります。
評価プロセスの非公式の図を以下に示します:
例3
最後に、アクションが read
ではなく write
である場合の決定リクエストを考慮します。その他の属性は例1と同じです。
ターゲットマッチング
リクエストは、アクションが write
であり read
ではないため、ポリシーのターゲットと一致しません。したがって、ポリシーは評価されません。
ルールとポリシーの組み合わせ
ポリシーが評価されないため、最終決定は NotApplicable
です。
評価プロセスの非公式の図を以下に示します:
結合アルゴリズム
XACMLは、複数のルールやポリシーの効果を組み合わせて決定を下す方法を決定するいくつかの標準的な結合アルゴリズムを定義しています。上記の例では、ルールとポリシーの両方で deny-overrides
結合アルゴリズムを示しました。
その名が示す通り、deny-overrides
アルゴリズムは Deny
の決定を Permit
の決定よりも優先します。以下は、deny-overrides
アルゴリズムの簡略化された説明です:
- いずれかのルールまたはポリシーがアクセスを拒否する場合、最終決定は
Deny
です。 - いずれのルールやポリシーもアクセスを拒否せず、少なくとも1つのルールやポリシーがアクセスを許可する場合、最終決定は
Permit
です。 - いずれのルールやポリシーもアクセスを拒否せず、許可もしていない場合、最終決定は
NotApplicable
です。
実際のアルゴリズムはより複雑で、Indeterminate{D}
や Indeterminate{P}
などの他の「未確定」の決定も考慮に入れます。
[!Note] このアルゴリズムは、どのルールやポリシーもリクエストにマッチしない場合の「フォールバック」決定を提供しません。そのような場合の決定は
NotApplicable
です。
結合アルゴリズムの完全なリストとその動作については、 XACML 3.0 の仕様 を参照してください。
実装における考慮事項
XACMLは、属性ベースのアクセス制御ポリシーを表現するための強力な言語です。システムに XACML を導入する前に、次のことを考慮してください:
- アクセス制御設計: XACML は柔軟で表現力豊かですが、複雑なポリシーセットを含むことがあるため、慎重な設計が必要です。それにより意図しない結果を招くことがあります。
- 複雑さ: XACML ポリシーはしばしば複雑で、管理が難しい場合があります。ほとんどのアプリケーションでは、 ロールベースのアクセス制御 (RBAC) のようなよりシンプルなアクセス制御モデルが適しているでしょう。
- パフォーマンス: 大規模なポリシーセットを扱う場合、XACML ポリシーの評価は計算コストが高くなる可能性があります。システムで XACML を使用する際のパフォーマンスへの影響を考慮してください。