前回「第5回 PKIとPMIを融合させる次世代言語XACML」は、XACML（eXtensible Access Control Markup Language）のデータフロー・モデルとそれに関連してContext構文の解説を行った。今回は、引き続きXACMLポリシーでのアクセス制御ルールの例やポリシー記述言語の仕様に関して解説をしていく。
XACMLポリシーでのアクセス制御ルールの例
アクセス制御のルールを自然言語で示せば、例えば以下のように記述される。
| ルール例1 | 「abc.co.jp」ドメインのe-mailユーザーのみが「abc.co.jp」ドメインのすべての資源にアクセスできる |
|---|---|
| ルール例2 | 18歳未満の人はhttp://www.abc.co.jp/x/picture.jpegのページにアクセスできない |
| ルール例3 （4つのルールがある） |
1.指定された患者はどのようなカルテも読むことができる 2.患者が16歳以下で、指定された両親または保護者は患者のどのようなカルテも読んでよい 3.患者にe-mailを出せば、指定主任医師はカルテにどのような治療記録を書いてもよい 4.病院の事務管理者は患者のカルテの読み書きを許されない |
ルール例1は、単純なアクセス制御で、主体の属性としてメールアドレス名suzuki@abc.co.jpを要求Contextで示せば、この主体は「abc.co.jp」ドメイン内にあるので、PDP（Policy Decision Point）はこのルールに従って「abc.co.jp」ドメイン内のすべての資源へのアクセスを許可する。要求主体のドメイン名とルールで定めているドメイン名との文字列比較演算が行われる。
ルール例2では、要求主体の年齢属性とルールで定めている年齢との算術演算による比較がなされなければならない。
ルール例3は、いくぶん複雑な規則群で、主体の限定や資源の指定、動作（Read、Write）の指定などを含み、要求Contextとの比較に当たっては文字列比較演算、論理演算、算術演算などを必要とする。
ポリシー記述言語の構造
XACMLのポリシー記述言語の構造は図1のようになる。ポリシー記述言語は上に述べたようなアクセス規則をいくつかのXMLのルール＜Rule＞要素に記述する。ルール＜Rule＞は対象＜Target＞（主体、資源、動作）に対する規則を定めるものである。ルールには条件＜Condition＞を加えることもできる。ポリシー＜Policy＞は複数のルール＜Rule＞を結合したものである。ポリシーにはオプションとして＜Obligation＞を指定できる。ポリシーが複数あった場合、このポリシーを結合してポリシー集合＜PolicySet＞を作る。また、ポリシー集合を集めて集合の集合を作ってもよい。ポリシー集合＜PolicySet＞は対象＜Target＞と＜Policy＞およびオプションとしての責務＜Obligation＞を含めてよい。
このように複数のルールを結合してポリシーを作り、ポリシーを結合してポリシー集合を作るのはPAP（Policy Administration Point）が行う。作られたポリシーはPDPが検索できるようにリポジトリなどに置かれる。
以下に図1に示した各要素の内容について述べる。
●ルール＜Rule＞
ルール＜Rule＞は、XACMLのアクセス制御のベースとなるもので、図6に示されるように適用する対象＜Target＞の主体＜Subjects＞、資源＜Resources＞、動作＜Actions＞に対する規則からなり、さらにオプションとして条件＜Conditions＞としての規則を付けることができる。ルールにはルール作成者が示す方針に従って、アクセス要求Contextの主体＜Subjects＞、資源＜Resources＞、動作＜Actions＞の属性が、このルールにそれぞれ適合した場合に決定する値（許可：Permit、または不許可：Deny）を、ルールの属性（Effect）として設定しておく。
●対象＜Target＞
アクセス制御の対象である主体＜Subjects＞、資源＜Resources＞、動作＜Actions＞の3つの要素に対する規則を定める。ルールはだれ＜Subjects＞に対して、どのような資源＜Resources＞を、どのように動作＜Actions＞させるかを記述する。PDPは、このルールに沿って要求Contextに示された主体、資源、動作の属性と、以下に示すルールの主体、資源、動作との比較をする。評価結果はTrueまたはFalseとなる。
- 主体＜Subjects＞
複数の＜Subject＞を指定でき、要求Contextで示される主体の属性が、ルールで規定する主体の条件とマッチするかを評価できるように、それぞれの主体の資格など、属性のルールを記述する。要求とルールとの比較を行うためにどのような比較関数を用いるかも指定しなければならない。PDPは主体の資格がmanagerとして要求されれば、ルールで決めた対象資格の文字列比較を行って一致を検査する。またルールで20歳以上などと主体を限定する場合、要求Contextの主体の年齢との比較を行うために算術演算の関数を指定することになる。どのような主体でも許すのであればすべての主体を示す＜AnySubject＞要素を指定する。
- 資源＜Resources＞
複数の＜Resource＞を指定でき、要求Contextが示す＜Resource＞属性に対して、ルールを適用する資源を限定し、アクセスの対象とする資源を指定する。＜Subject＞と同様に要求とルールを比較するために比較演算の関数が用意されている。どのような資源でも許すのであればすべての資源を示す＜AnyResource＞要素を指定する。
- 動作＜Actions＞
複数の＜Action＞を指定でき、要求Contextが示す＜Actions＞属性に対して、ルールを適用する資源へのアクセスに対する動作を指定する。SAML（Security Assertion Markup Language）で定めているようにRead、Write、Deleteなどの動作に加えてXACMLではどのような動作も定義することができる。ほかに要求とルールを比較するために比較演算の関数が用意されている。どのような資源でも許すのであればすべての資源を示す＜AnyAction＞要素を指定する。
●条件＜Condition＞
オプションとして指定できる条件＜Condition＞は、対象＜Target＞に対するルール以外に適用する規則である。例えば「午前9時から午後6時までアクセスを許可する」というルールが与えられた場合、このルールは＜Target＞に対するルールではなく、条件＜Condition＞として指定することになる。この条件を評価したとき＜Condition＞の値はTrueかFalseを取る。
PDPは要求Contextの主体、資源、動作の属性と、ルールの＜Target＞の各主体、資源、動作を比較評価し、かつ＜Condition＞があれば＜Condition＞も評価して認可決定を下すことになる。この場合、要求Contextとルールの＜Target＞の主体、資源、動作がすべてマッチし、＜Condition＞がTrueの場合のみルールの値は、結果属性Effectで指定されたPermitまたはDenyとなる。＜Target＞がマッチしても＜Condition＞がFalseの場合は＜Rule＞の値はNotApplicableとなる。
●ポリシー＜Policy＞
ポリシー＜Policy＞は複数のルール＜Rule＞をまとめたものである。PAPは複数のルールを１つのポリシーに結合する。ポリシー＜Policy＞の子要素には対象＜Target＞、複数の＜Rule＞、責務＜Obligations＞があり、ポリシーIDとPDPがこのポリシーを評価するときに用いるルール結合アルゴリズムID（RuleCombiningAlgID）を＜Policy＞の属性に指定する。
対象＜target＞はこのポリシーの対象で、主体、資源、動作のルールを規定する。ポリシー＜Policy＞に複数のルール＜Rule＞がある場合、PDPはルール結合アルゴリズムIDで示された以下に示すルール結合アルゴリズムで評価し、ポリシーの評価（Permit、Deny、NotApplicable、Indeterminate）を決定する。
もしこのポリシーに責務＜Obligations＞が規定された場合は、PDPはこの債務をPEP（Policy Enforcement Point）に示して責務の実行をPEPに課すことになる。PEPはPDPの結果がPermitであっても責務＜Obligations＞も同時に実施しなければならない。例えば債務は「PEPは要求者の資源へアクセスする際、アクセスログを取りなさい」とか「アクセスに対する注意事項を要求者に伝えなさい」などである。PEPは責務＜Obligations＞が実施できなければ資源へのアクセスを拒否しなければならない。
ルール結合アルゴリズム
ポリシー＜Policy＞にはポリシー属性として、PDPがルールを評価し認可決定するために用いるルール結合アルゴリズムを指定しておく。ルール結合アルゴリズムとしては以下の3つのアルゴリズムが規定されている。
・Deny-overrides
ポリシー内のすべてのルールについて、どれか１つのルールのEffectが“Deny”であれば結果は“Deny”とする。すべてのルールが“Permit”、あるいは幾つかのルールが“Permit”で残りのルールすべてが“NotApplicable”の場合のみ結果を“Permit”とする。
・Permit-overrides
ポリシー内のすべてのルールについて、どれか１つのルールのEffectがが“Permit”であれば結果は“Permit”とする。すべてのルールが“Deny”、あるいは幾つかのルールが“Deny”で残りのルールすべてが“NotApplicable”の場合のみ結果を“Deny”とする。
・First-applicable
ポリシー内のすべてのルールについて順番に評価して、対象＜Target＞がマッチした場合、以後の＜Rule＞の評価を中断し＜Target＞の評価結果をMatchとし、次にConditionを評価し、これがTrueなら結果はEffectで指定された“Permit”または“Deny”とする。
ルール結合アルゴリズムはルールを評価するとき、上記の“Permit”または“Deny”の決定以外に、要求Contextが用意されたルールにすべてマッチしなければ評価結果は“NotApplicable”を、評価の過程で構文エラーとなった場合“Indeterminate”を返す。
●ポリシー集合＜PolicySet＞
ポリシー集合＜PolicySet＞は複数のポリシー＜Policy＞をまとめたものである。もし複数のポリシーが登録されるならPAPのポリシーは複数のポリシーを１つのポリシー集合に結合する。ポリシー集合をさらに結合することもできる。ポリシー集合＜PolicySet＞の子要素には対象＜Target＞、複数の＜Policy＞、＜PolicySet＞、責務＜Obligation＞があり、＜PolicySet＞の属性にポリシー集合ID（PolicySetID）とポリシー結合アルゴリズムID（PolicyCombiningAlgID）を指定する。ポリシー結合アルゴリズムIDは、このポリシー集合を評価するPDPが適用するポリシー結合アルゴリズムで、ルール結合アルゴリズムと同様な3つのポリシー結合アルゴリズムが規定されている。
対象はこのポリシー集合の対象で、主体、資源、動作を規定する。もしこのポリシー集合に責務＜Obligation＞が規定された場合は、PDPがこの責務をPEPに課すことになる。
XACMLポリシー言語構文はリスト1のような構造となる。以下の例はルール＜Rule＞が2つある場合を示している。
リスト2にルールの対象＜Target＞の主体＜Subjects＞の構文例を示す。
この＜Subject＞のルールと要求Contextの＜Subject＞のマッチングをどのように行うかを示すために要求Contextが以下のようになっていたとしよう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
要求Contextの＜Subject＞の＜Attribute＞にはroleの属性値として文字列 “administrator”が指定してある。PDPは要求Contextの＜AttributeValue＞に示されたadministratorと、図8のルールの＜SubjectMatch＞の属性MatchId=で指定している文字列比較関数string-matchを用いてルールにある文字列administratorとの文字列比較を行う。結果は文字列がマッチするのでSubjectの評価値はTrueとなる。
ポリシーの＜Resource＞や＜Action＞も＜Subject＞の＜Attribute＞と同様な構文構成を取り、それぞれ
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
などと記述される。＜Subject＞で評価したのと同様にMatchId=で指定される評価関数で要求Contextのそれぞれの属性との比較が行われる。結果はそれぞれTrueかFalseとなる。
評価関数
XACMLではポリシやルールで指定する＜Target＞の主体、資源、動作を、それぞれ要求Contextの主体、資源、動作と比較評価を行うために“MatchId=”で指定する標準の関数を数多く用意している。これらの関数には一致比較関数、算術関数、算術比較関数、非算術比較関数、論理関数、集合関数などがある。これらの関数評価結果の値はTrueかFalseとなり、評価が出来なければ結果は“Indeterminate”となる。
これらの評価関数は＜Condition＞や＜Condition＞の子要素＜Apply＞の属性“Function=”での関数指定にも用いられる。
●ルールの評価
ルールの評価はルールの＜Target＞の評価と＜Condition＞の評価からなる。ルールの評価結果はこれらを結合したときのものとなり、以下のような真理表で表される。Targetがマッチし、ConditionがTrueの場合のみルールの値がルール属性Effectで示されたPermitまたはDenyとなる。
| Target | Condition | ルールの値 |
|---|---|---|
| Match | True | Effect(Permit or Deny) |
| Match | False | NotApplicable |
| Match | Indeterminate | Indeterminate |
| No-Match | DON'T CARE | NotApplicable |
| Indeterminate | DON'T CARE | Indeterminate |
●ポリシーの評価
ポリシーの評価はポリシーの＜Target＞と＜Rule＞の評価結果の結合となる。ポリシーの評価の真理表を次に示す。
| Target | Rules | ポリシーの値 |
|---|---|---|
| Match | いくつかが適合 | ルール結合アルゴリズムの結果の値（Permit or Deny） |
| Match | すべてNotApplicable | NotApplicable |
| Match | Indeterminate | ルール結合アルゴリズムの結果の値（NotApplicable or Indeterminate） |
| No-Match | DON'T CARE | NotApplicable |
| Indeterminate | DON'T CARE | Indeterminate |
以上の真理表に従ってポリシーの決定値はPermit、Deny、NotApplicable、Indeterminateのどれかの値となる。PEPはPermit以外の認可決定を受けたとき、資源へのアクセスを拒否しなければならない。NotApplicableの場合、要求Contextとポリシーが不適合なので、PEPは適切な要求Contextを再度出し直すか、別のPDPに要求Contextを出すことになる。
「第5回」へ
Copyright © ITmedia, Inc. All Rights Reserved.