XACMLのセキュリティ
XACMLのセキュリティはXACMLの主要なプレーヤ（PEP、PDP、PAP）間のトランザクションに関連する。PEPとPDP間での相互認証（Authentication）はXACMLの性質上重要なContextの交換を安全に行うために必須な要素である。このためにはセッションレベルのセキュリティとしてVPNやTLSが用いられる。Contextのメッセージのいくつかがノードを超えて行われる場合、エンド・ツー・エンドのセキュリティを確保するために要求、応答Contextのデジタル署名が必要になる。
PAPが作成するポリシーやポリシー集合の完全性も重要な関心事である。PAP-PDPがポイント・ツー・ポイントのセッションを持つ場合はTLSによるセッション認証とチャネルの暗号化を用いることができる。しかし、ポリシーが組織間に分散されるか、ポリシーがいくつかのノードを渡り歩く場合、ポリシーにデジタル署名を付けることがポリシーの完全性を保証するために強く推奨される。
ポリシーはポリシー識別子（URI）で参照される。ポリシーの識別子をユニークに保つことが特に重要である。ポリシーを変更した場合には異なったポリシー識別子を用いるべきである。
ポリシー＜Policy＞、要求Context＜Request＞、
応答Context＜Response＞の例
XACMLのPDPがポリシーに対して要求Contextをどのように評価し、認可決定の応答Contextを返すかを理解するためにサンプルのポリシーと要求Contextに対する応答Contextの例を示す。
●ポリシー＜Policy＞
日本語で記述する以下のようなポリシーが定められたとする。
ポリシー例1：
「要求主体がsales.abc.co.jpドメインのe-mailユーザーで、roleがmanagerであればbusiness-plan.xmlをreadできる」
上記のポリシーをXACMLのPolicyスキーマに従ってXMLで記述するとリスト6のようになる。日本語では簡単なポリシー記述でもXMLで記述するとかなり長くなる。
この例では、ポリシーのTargetに何も制限を与えていない。すなわち、AnySubject、AnyResorce、AnyActionなのでどのようなSubject、Target、Actionにもマッチする。従ってTargetに対する制約はルールのTargetに従うことになる。ルールのTargetでは、以下のような規則を定めている。
- Subjectはrfc822のe-mail名を持ち、managerのRole属性を指定している。評価方法はrfc822のe-mail名については文字列の部分一致（rfc822Name-match）、roleについては文字列の完全一致（string-equal）としている。
- Resourceはhttp://abc.co.jp/sales/business-plan.xmlである。評価方法は（anyURI-equal）でURIが一致すればよい。
- Actionはreadを認めている。評価方法は文字列の完全一致（string-equal）とする。
このポリシーのルールではTargetについての規則のみで、Conditionは含めていない。従ってPDPの認可決定は、要求ContextのSubject、Resource、Actionがルールの規則とマッチすればルールのEffect＝Permit属性に従ってPermitとなる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
●要求Context＜Request＞
リスト7に示す要求Contextは、メールユーザーSuzuki.Yuichi@sales.abc.co.jpがmanagerのroleで“business-plan.xml”のファイルにread要求する例である。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
●評価のプロセス
PDPはポリシーに対して要求Contextがマッチするかを調べることになる。リスト6のポリシーの＜Target＞はAnySubject、AnyResouce、AnyActionなのでどのようなSubject、Resource、Action要求に対してもポリシーの＜Target＞はマッチする。従ってポリシーの＜Target＞の評価はMatchとなる。次にルールの＜Target＞の評価になる。ルールの＜Target＞の＜Subject＞ではSubject-idとしてrfc822Name形式でsales.abc.co.jp、リスト7の要求＜Request＞の＜Subject＞はYuichi.Suzuki@sales.abc.co.jp なので評価関数rfc822-matchを用いると文字列の部分一致を見てTrueとなる。さらにroleとしてmanagerを指定しているので評価関数string-equalを用いるとTrueとなる。次に＜Resource＞についても要求の＜Resource＞属性とルールの属性を評価関数anyURI-equalで比較すると一致しているのでこれもTrueとなる。＜Action＞としては要求はreadである。ルールの＜Action＞はreadなのでこれの評価関数string-equalを用いるとTrueとなる。従ってルールの評価結果はすべてTrueなので、ルールの属性Effect＝Permitが適用される。
ここでポリシーの評価はポリシーのTargetがMatch、ルールの＜Target＞がPermitなのでポリシーは規則結合アルゴリズムで評価すると適合で、その結果ルールのEffectのPermitが認可決定の値となる。
●応答Context＜Response＞
PDPはリスト7に示したPEPの要求Contextに対して、リスト8に示す＜Response＞では＜Result＞の＜Decision＞として認可決定Permitを与える。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
もし要求ContextのSubjectの「abc.co.jp」ドメインのサブドメインがsalesではなくdevelopサブドメインのメールユーザーTaro.Yamada@develop.abc.co.jpであれば、たとえroleがmanagerであってもSubjectMatchの評価関数（rfc822Name-match）がFalseとなり、Targetはマッチせず認可決定はDenyとなる。
XACML1.0の仕様書（Committee Specification 1.0,7 November 2002）には今回の冒頭の節「XACMLポリシーでのアクセス制御ルールの例」で述べたルール例1とルール例3についてのExampleが丁寧な説明付きで示されている。
またOASISではXACML標準との適合性テストのために＜Request＞、＜Policy＞、＜Response＞についての多くのテストケースを用意している。これらはXACMLの具体的な例となっているので、さらに多くの例を調べるにはOASIS XACML TCのConformance Test Casesが参考になる。
これまで6回にわたってWebサービスのセキュリティの基本的な技術として、Webサービス・セキュリティのフレームワーク、XMLセキュリティの基礎であるXML署名、暗号、そして鍵管理サービス（XKMS）、認証、認可のフレームワークとしてのSAML、そして柔軟な認可決定のポリシー記述言語としてのXACMLについて詳しく見てきた。
Webサービスは言語独立、プラットフォーム独立で、Web環境で疎結合のクライアント／サーバの分散システムを容易に構築できる技術として脚光を浴びてきている。Webサービスは状態情報をリクエスタとプロバイダ間で伝達する仕組みを提供し、基幹業務もこの仕組みを使って構築できるようになってきた。これらのメッセージはインターネットを介して送ることができる。しかしそこではセキュリティ確保が必須となる。
さらにこの技術をベースに一般のWebサービスのアプリケーションに適用する際の標準的な枠組みをIBM、Microsoft、VeriSignが「Web Service Security（WSS）」として提唱している。WSSはXML署名やSAMLのアサーションを標準的な手順でSOAPのHeaderに記述する方法を定めている。WSSはOASISに提案されOASISのTCが形成された。
またRoleベースの署名を行うサービスやXMLタイムスタンププロトコル策定するためのDigital Signature Services（DSS） TCがEntrustのChairのもとにOASISに作られた。このDSSでは、署名の検証も外部サーバでサポートすることを計画している。
WebサービスはPC環境のみならず、携帯電話などでもアプリケーションのベースとして多いに期待されている。今後これらの活動の進化によってWebサービスのセキュリティをより強化し、Webサービスのアプリケーションを安心してインターネットの中でPCやPDAそして携帯電話で垣根なく使えるようになることを期待しよう。（今回で本連載は終了です。ご愛読ありがとうございました。）
Copyright © ITmedia, Inc. All Rights Reserved.