「第1回 Webサービスのセキュリティ概要」はWebサービス・セキュリティのフレームワークについて、「第2回 XMLデジタル署名とXML暗号」はXML署名とXML暗号について述べた。「第3回 XML鍵管理サービスとXMLプロトコル」は鍵情報の登録と鍵情報の検証サービス（XKMS）と、これらの情報を伝達するためのXMLプロトコルSOAPについて、「第4回 強力なSSOを実現するXML認証・認可サービス」はシングルサインオン（SSO）と属性情報やアクセス制御情報を伝達するプロトコルSAML（Security Assertion Markup Language）について述べた。今回からは本連載の最終段階として、柔軟で拡張性のあるアクセス制御を実現するためのポリシー記述言語XACML（eXtensible Access Control Markup Language）について述べる。SAMLやXACMLはPKIと権限管理のインフラストラクチャであるPMI（Privilege Management Infrastructure）を融合させる次世代のフレームワークである。
XACMLは11月8日にXACML 1.0としてOASISのComittee Specificationになり、1カ月のパブリックレビューを受けて正式のOASIS標準となることになった。XACML1.0の仕様書はOASIS eXtensible Access Control Markup Language TCを参照してほしい。
XML認可サービス（XACML）
前回述べたSAMLは、認証を受けた主体がその資格や属性によってあるルールの下に資源へのアクセス権限を証明する仕組みを定めたものである。XACMLは、このSAMLのフレームワークの上で特にポリシー決定点（PDP：Policy Decision Point）に対する認可決定を判断させるためのポリシーおよびルール規定の仕様を定め、併せてポリシー決定点に対する認可要求やその応答のプロトコルを定めたものである。PDPはこの柔軟なポリシー規定と認可要求の適合性を判断し、要求者の資源へのアクセスの許可、拒否を決定する。
XACMLは、以前IBMの定めたXACL（XML Access Control Language）をベースとし、ポリシー記述の柔軟性と拡張性を高めたものとなっている。XACLはファイルの読み、書き、生成、削除を制御する仕様を規定したものでシンプルな構造であったが、柔軟なポリシー記述やより多様な資源へのアクセスを制御する点では拡張性に欠けるものであった。XACLの初めの文字XはXMLを指しているが、XACMLのXはeXtensible（拡張性）としており、XACLの持っていた制約をできるだけ排除し、多様な資源へのアクセス制御を実現させる拡張性のある柔軟なポリシー仕様を規定できるようにした。
またXACMLは、XACLをベースにSAMLのフレームワークの中で認可決定のためのポリシー記述言語としてSAMLの仕組みを拡張するものとして企画されたが、現在の仕様はSAML環境以外にも適用できるように独立した認可決定の仕様としてまとめられている。例えばXACMLはSAMLのほかにJ2SE、CORBAなどにも用いることができる。
XACMLではこの仕様の記述のために特有の用語を使用しているので、ここではXACMLで用いられる用語について解説しておく。
XACMLでの特有の用語
・PDP（Policy Decision Point）
定められたポリシーに従ってPEPが示したアクセス要求が正しい権限を持つものかどうかを判断し、許可、不許可の決定を行うところ。SAMLのPDP（ポリシー決定点）の定義と同じもの。
・PEP（Policy Enforcement Point）
PEP（Policy Enforcement Point）アクセス要求者からの要求を受けてPDPに資源へのアクセス判断を問い、PDPの示す許可、不許可の決定に基づき資源へのアクセスの制御を実施するところ。SAMLのPEP（ポリシー実行点）の定義と同じもの。
・PAP（Policy Administration Point）
PAP（Policy Administration Point）PDPが参照するアクセス制御のルールを定義し、ポリシーやポリシー集合を生成するところ。
・PIP（Policy Information Point）
PEPの問合わせに対し、主体や資源や環境に関する属性値を提供するところ。SAMLの属性オーソリティに相当する。
・Context
PEPとPDP間で、認可要求と認可決定（応答）の正規化したプロトコルの構文。
・Target
ルールやポリシーで、評価すべき対象としての主体、資源、動作のルールを定めたもの。
・Condition
ルール内でTargetのルール以外にオプションとして指定する条件としての規則。
・Obligation
PDPが認可決定に当ってPEPに責務として実行を強制する指示。ポリシーで規定する。
データフロー・モデル
図1はXACMLのデータフロー・モデルを示している。XACMLのキープレーヤは図の中央に示している認可決定のPDP、認可ポリシーをまとめてポリシーを提供するPAP（Policy Administration Point）、認可決定要求を出し、認可決定応答を受けてアクセス制御を実行するPEP（Policy Enforcement Point）である。
- PAPは主体（Subject）と資源（Resource）と動作（Action）に関するアクセス制御のルール（Rule）を集めてポリシー（Policy）またはポリシーの集合（Policy Set）を作りPDPに提出する。
- アクセスの要求者は主体に対する資源へのアクセスをPEPに要求する。
- PEPは主体に関する環境や資源の属性をPIP（Policy information point）に尋ねる。PIPはSAMLの属性オーソリティに相当する。
- PIPはあらかじめ登録された主体、環境、資源に関する属性情報を収集する。
- PIPはPEPに上記の属性情報を返す（属性アサーション）。
- PEPは必要なら資源に関する情報も収集する。
- PEPはこれらの情報を含めてPDPに要求Contextを投げる。
- PDPはこれらの要求ContextとPAPから得たポリシーを比較し、要求の許可（Permit）または不許可（Deny）の決定をPEPに返す。
- PDPはオプションとしてアクセス要求に対する実行に対して、PEPの実行に対する責務（Obligation）を与えることがある。例えば必要なメッセージを要求者に伝えなさいとか、アクセスの記録を取りなさいなど。
- PEPはアクセスの要求者に対して資源へのアクセス制御を行う。
PEPの資源へのアクセス要求に対し、この認可決定を判断するためのルールやポリシーを定める部署は1つとは限らない。例えばある部署は主体の資格に対するルールを定めるかもしれず、ある部署は資源に対するアクセス条件を定めるかもしれない。XACML仕様では、複数の部署が提供するルールやポリシーをPAPが結合してポリシーやポリシー集合を作るとしている。PAPは一定のルールに従って複数あるルールを結合してポリシーを作り、またポリシーがさらに複数あればこれらを結合してポリシー集合を作りリポジトリに登録する。PDPはLDAPなどでポリシーを検索し、このポリシーやポリシー集合とPEPが示した属性を含む要求とのマッチングを図り認可決定を下すのである。
XACMLは図1で示した3つの赤矢印、すなわちPAPからPDPに示すルールやポリシーを記述するためのXMLスキーマ、PEPがアクセス要求者の属性情報を記述してPDPに提示する要求Context、およびPDPがPEPに返す認可決定の応答Contextのスキーマを定めている。SAMLではこのような要求や応答をプロトコルといっていたが、XACMLではContextと呼んでいる。
図1ではPDPに対する要求ContextはPEPから直接PDPに出され、応答ContextもPDPからPEPに直接返されるように示しているが、PEPは認可決定を受けて実際に資源に対するアクセス制御を実行するところで、具体的にはPEPは業務のアプリケーションであるかもしれない。このようなアプリケーションは独自のアクセス制御要求を出し、独自の応答で処理するようになっており、XACMLで定めた要求や応答のContextを処理できないかもしれない。従って実際のXACMLの実装に当たっては図2に示すようにXACMLの仕様で定める正規化されたContextとPEPの独自のプロトコルを変換するcontext handlerを設けることになろう。
Context構文
PEPからPDPへのアクセス要求やPDPからPEPに対する応答をそれぞれ要求Context、応答Contextという。XACMLの要求と応答のContextの概要を図3に示す。
PEPは要求Contextでアクセスを要求する主体の資格などの属性、アクセスしたい資源についての属性情報をPIPに問い合わせて収集し、資源に対してのアクセス方法（Read、Write）などを指定した要求をPDPに送る。PDPはこれらの要求をあらかじめ登録されたポリシーを検索して要求Contextと比較評価し、許可（Permit）または拒否（Deny）をPEPに応答する。ポリシーに責務＜Obligation＞があれば責務もPEPに示される。PEPはこれらの応答メッセージに従って資源へのアクセス制御を実行することになる。
●XACML 要求Context＜Request＞
XACML要求Contextの＜Request＞要素はリスト1の例に示す構文で構成される。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
要求Contextは主体＜Subject＞がどのような資格や属性を持っているか、アクセスしたい資源＜Resource＞は何なのか、資源に対してどんな動作＜Action＞を要求するのかを、それぞれの属性＜Attribute＞要素に記述する。オプションとして主体、資源、動作以外の要求条件をオプションとしての環境＜Environment＞に与えることもできる。
●XACML 応答Context＜Response＞
リスト1に示す要求Contextに対してPDPは要求Contextの主体、資源、動作についてのそれぞれの属性をポリシーの対象＜Target＞のそれぞれ主体、資源、動作の規則と比較評価し、要求とポリシーがマッチすれば、リスト2に示すような応答Contextを返す。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
応答Contextはリスト2に示すように資源に対してのアクセスの認可決定＜Decision＞要素でPermitまたはDenyを指定する。PDPが要求に対するポリシーを評価する際、適用できるルールがなかった場合の決定＜Decision＞はNotApplicableとなり、評価でエラーが起こった場合の決定＜Decision＞はIndeterminateとなる。
もし評価するポリシーに責務＜Obligations＞が記載されていれば、応答Contextに責務＜Obligations＞をそのまま含める。責務＜Obligations＞を指定されたPEPは責務を実行しなければならない。
今回は、XACMLのデータフロー・モデルとそれに関連してContext構文の解説を行った。次回は、引き続きXACMLポリシーでのアクセス制御ルールの例やポリシー言語の仕様に関して解説をする。
「第4回」へ
「第6回」へ
Copyright © ITmedia, Inc. All Rights Reserved.