JP4805615B2 - アクセス制御方法 - Google Patents

Description

本発明は、情報システムにおいて管理される情報資源に対するアクセスを制御する方法に関し、特にロールベースのアクセス制御方法、すなわち情報資源に対するアクセスの要求を、そのアクセス要求に相当する権限が、そのアクセスを要求するサブジェクトが帰属し、かつ、そのアクセスに使用されるロールに対応付けられているアクセス権限集合に含まれるか否かに基づいて認可判定するアクセス制御方法に関する。

情報システムにおいては、そのシステムにおいて管理されるデータあるいはプログラムなどの情報資源の機密性や資産価値を維持するために、これら情報資源に対する参照、実行、変更、削除などのアクセスを制御する必要がある。一般に、保護対象にアクセスするものをサブジェクトと呼び、保護対象となる情報資源をオブジェクトと呼ぶ。アクセス制御の方法を特徴付ける主たる要素として、サブジェクトの有するアクセス権限、すなわち、サブジェクトに対してその実行を許可するオブジェクトとその操作（参照、実行、変更などの区分）との組をどのように管理するかという点がある。

古典的なアクセス権限の管理手法では、サブジェクトと、そのサブジェクトに許可するオブジェクトと操作の組すなわち権限とを直接的に結び付けるアクセス制御リストによって、アクセス権限管理を行っていた。しかしこの方法では、サブジェクトの追加や個々のサブジェクトに認めるべき権限レベルの変更、あるいは、オブジェクトの追加や個々のオブジェクトに必要とされる機密レベルの変更などに従って、アクセス制御リストを適正な状態に保つよう修正し続ける必要があり、サブジェクトやオブジェクトの数が多数に上る場合においてアクセス制御リストを適正な状態に維持し続けるための管理コストが極めて高かった。また、この管理コストの高さに起因して、誤った設定がなされて運用される事態が生じるなど、適切なセキュリティを保つのが困難であった。

これを改善する方法として、［非特許文献１］などで示されているロールベースのアクセス制御方法（以下ロールベース方式と呼ぶ）が考案された。ロールベース方式では、サブジェクトとオブジェクトの間に、両者を間接的に結び付けるロール（role；役割）という中間構造体を設ける。ロールには、サブジェクトの集合とオブジェクトと操作の組すなわち権限の集合が、それぞれ独立に対応付けられる。あるアクセス要求が発生した場合には、その対応付けに基づき、そのアクセスを要求したサブジェクトがそのアクセスにおいて明示的あるいは暗黙的に使用するロールに帰属するか、また、要求されたアクセスに相当する権限がそのロールに割り当てられているかが判定され、両者が真である場合においてのみ、そのアクセスが許可される。このようにロールは、情報システムを使用する組織等における職務上その他の意味合いにおいて同様の権限を持つべきサブジェクトを集約するという側面と、権限の割り当て上のアトミックな単位として同時に許可あるいは拒絶されるべきオブジェクトと操作の組の集合を形成するという側面を併せ持つ。ロールを介してサブジェクトと権限とを間接的に結合させて管理することによって、サブジェクトの追加や権限レベルの変更あるいはオブジェクトの追加や機密レベル等の変更が必要となった場合の管理上の作業は、ロールへのサブジェクトの割り当ての変更、あるいは、ロールへの権限の割り当ての変更に局所化され、かつ、その設定量もアクセス制御リストに比べて小さくなる。したがってロールベース方式を採用することにより、情報システムの管理者における管理プロセス上の負担は大きく軽減される。

しかしながら、ロールベース方式といえども、大規模な組織で用いられる情報システムでは、適切に権限を付与し管理するために必要となるロールの数が膨大になる場合がある。これは、セキュリティポリシ上、サブジェクトに付与すべき権限群は、類似してはいるものの細部において少しずつ異なる権限の集合となる場合が多く、そのような権限集合に応じて個々にロールを定義する必要が生じるためである。この点に着目して改良されたロールベースのアクセス制御方法（以下、拡張ロールベース方式と呼ぶ）が［特許文献１］に開示されている。

拡張ロールベース方式では、それ以前のようにロールに対して具体的な権限の集合を割り当てる代わりに、サブジェクトの有する属性をパラメータとする抽象化された権限集合（抽象権限集合とする）を割り当て、管理する。あるアクセス要求が発生した場合には、まず、そのアクセスを要求したサブジェクトが有する属性の値をそのアクセスに使用するロールに対応する抽象権限集合に適用し、具体的な権限集合を特定する。以降、この具体的な権限集合を用いて、通常のロールベースアクセス制御方法と同様にしてアクセスの可否を判定する。このように、パラメータ化された権限集合を使用することによって、サブジェクトごとに少しずつ異なる権限の割り当てを、少ない数のロールならびに権限集合の定義で実現可能となる。なお、［特許文献１］では、権限集合だけでなくロールそのものもパラメータ化された抽象的な管理情報として記載されているが、サブジェクトが有する権限集合の管理および特定という観点においては、権限集合の抽象的定義こそが本質であり、ここではロールの抽象化についての説明は割愛する。

拡張ロールベース方式における権限管理の構造を、サブジェクトに対する権限集合の割り当てという観点から模式化したものが図２である。

サブジェクトのロールへの所属関係、すなわち、サブジェクトへのロール割り当ては、一般に、サブジェクトの識別子とロールの識別子とを直接的に対応付けて定義され、管理される。これは、通常のロールベース方式と同様である。［特許文献１］では、サブジェクトとロールとの間にサブジェクトの属する組織を介在させて両者の対応付けを行う方法も開示されているが、この場合もサブジェクトの識別子を元にロールを特定するという意味においては同様である。サブジェクトへの属性割り当てもまた、サブジェクトの識別子と属性の値とを直接対応付けられる。このようなサブジェクトの属性情報は、一般に、ＲＤＢＭＳ（リレーショナルデータベース管理システム）やＸ５００ディレクトリシステムなどによって実現される従業員データベースなどで管理される。

抽象権限集合においては、具体的なオブジェクトをその識別子などを用いて指定するのではなく、オブジェクトの種別や検索条件などによって一群のオブジェクトを指定する。たとえば、抽象権限集合には“プリンタ，印刷”と記述される。ここで“プリンタ”とは特定のプリンタではなく、当該情報システム内でプリンタという種別で管理されている情報資源全般を総称する。制約規則には抽象権限集合に含まれるオブジェクト群の有する属性と、サブジェクトの有する属性等とが対応付けて記述される。先ほど例に挙げた抽象権限集合に対応する制約規則に、“情報資源：ロケーション＝サブジェクト：オフィス”と記述されていたとする。これはサブジェクトのオフィス属性の値がプリンタのロケーション属性に適用されることを示す。すなわち、先の権限集合における記述は「サブジェクトのオフィス属性の値と同じ値をロケーション属性の値として持つようなプリンタ（を使った印刷）」を示す。
特許第３０７４６３８号 D.Ferraiolo and D.Kuhn, "Role-Based Access Control", 15th National Computer Security Conference, pp. 554-563, 1992

上述したように、従前のロールベース方式あるいは拡張ロールベース方式では、サブジェクトのロールへの所属は、サブジェクトの識別子とロールの識別子とを直接的に対応付けて管理するのが一般的であった。これは、以下に示すような課題を有する。

まず、一般に、情報システムが従うべきセキュリティポリシは中長期にわたって安定しているが、個々のサブジェクトの組織上の帰属や役職、担当などは比較的短期間に変動しうる。従前の拡張ロールベースによるアクセス制御機構に係る管理情報のうち、後者に該当するのはサブジェクトへの属性割り当ておよびロール割り当てである。すなわち、従前の拡張ロールベース方式では、サブジェクトの異動などに伴ってセキュリティレベルを保つために行わなければならない管理プロセスは、サブジェクトへの属性割り当てとロール割り当てという、２つの異なる管理情報に対する修正ステップである。これらの作業は煩雑でかつ量も多く、管理者にとって大きな負担となる。このような性質は、特に、非常に多数の利用者がアクセスを行いうる情報システム、例えば、企業間での商取引を実現する情報システムのように管理者が所属する企業や組織と異なる組織に属する利用者がアクセスを行うものにおいては大きな問題となる。

さらに、従前の拡張ロールベース方式では、権限を付与する管理者は、抽象ロールにサブジェクトを割り当てるために、アクセスを行いうる全ての潜在的なサブジェクトについて予め識別可能である必要がある。また、実際にアクセスを制御する際にサブジェクトの権限を特定するためには、サブジェクトの識別子が必要である。このような性質を有するアクセス制御機構は、インターネット上で不特定多数の利用者を対象に提供される情報サービスのように、利用者の匿名性あるいは仮名性が必要なものや事前の利用者登録等による識別子の払い出しが不適切なものには適用が極めて困難であったり、不可能であったりする。

本発明は係る点に鑑みてなされたものであり、非常に多数の利用者がアクセスを行いうる情報システムにおいて、情報資源へのアクセスを制御するために必要なアクセス権限の管理業務にかかるコストを極めて少なくするとともに、不特定多数の利用者がアクセスを行いうる情報システムにおいてもアクセス権限を適正に設定し管理可能としたアクセス制御方法を提供することを目的とする。

従来の技術では上述したように、サブジェクトのロールへの割り当てをサブジェクトの識別子を用いて直接行っていたが、本発明では、サブジェクトの属性を用いてサブジェクトとロールとを間接的に結び付けて権限を管理するようにしている。

すなわち本発明のアクセス制御方法は、サブジェクトによるオブジェクトに対するアクセスの要求を受信した場合に、サブジェクトが帰属するロールに基づいてアクセス要求の認可判定を行う、情報システムにおけるアクセス制御方法であって、サブジェクトがアクセス要求に使用するロールを特定するロール特定ステップと、サブジェクトの属性を取得する属性取得ステップと、属性取得ステップにおいて取得したサブジェクトの属性に基づいて、ロール特定ステップにおいて特定したロールにサブジェクトが帰属するか否かを判定するロール帰属判定ステップと、ロール帰属判定ステップにおいてサブジェクトがロールに帰属すると判定された場合に、ロールに対応付けて定義された第一の権限集合を取得し、属性取得ステップにおいて取得したサブジェクトの属性に基づいて、第一の権限集合から第二の権限集合を抽出し、第二の権限集合にアクセス要求に対応するアクセス権限が含まれるか否かを判定する権限有無確認ステップと、を有し、権限有無確認ステップでの判定結果に基づいて、要求されたアクセスの可否を判定する。後述の発明の実施の形態に即して言えば、第一の権限集合は、（ロールに対応付けて定義された）１ないし複数の単位権限集合定義に対応する権限の和集合のことでであり、第二の権限集合はサブジェクト権限集合のことである。

本発明の第一の効果は、サブジェクトすなわち情報システムの利用者などの業務上の職責や役職、担当などの変更があった場合に、オブジェクトすなわち情報資源を適切な保護レベルに保つために必要となるアクセス制御情報の管理コストを従前と比べて極めて小さくできることにある。その理由は、上記の場合には、従前の技術によればサブジェクトへの属性の割り当てに加えてサブジェクトのロールへの割り当てをも更新する必要があったが、本発明によれば、サブジェクトのロールへの割り当てがサブジェクトの識別子ではなくサブジェクトの属性によって行われるから、サブジェクトへの属性の割り当てのみを更新すればよいためである。

本発明の第二の効果は、インターネットなどの不特定多数の利用者が参加する情報システムにおけるアクセス制御が、ロールベースで効率的にできることにある。その理由は、上記の通り、管理プロセスにおいてはサブジェクトすなわち利用者のロールへの割り当てをサブジェクトの識別子ではなくサブジェクトの属性によって行い、さらに、アクセス制御の実行プロセスにおいては属性証明書などを利用してサブジェクトの属性を取得するが可能であることから、サブジェクトすなわち利用者の当該情報システムへの事前の登録や、アクセス制御時におけるサブジェクトの識別を必要としないためである。

さらに本発明では、従前のようにサブジェクトの有する属性をすべて参照するのではなく、サブジェクトのロールへの帰属の確認あるいはサブジェクトに割り当てるべき具体的権限を特定する際に用いるサブジェクトの属性を、帰属確認あるいは権限特定に真に必要なものに限定して取得するように構成することができる。そのように構成した場合には、サブジェクトに係る情報の情報システムへの開示を必要最低限に抑え、サブジェクトのプライバシの保護などを図ることができるという効果が得られる。

本発明では、サブジェクトのロールへの帰属の確認あるいはサブジェクトに割り当てるべき具体的権限を特定する際に、従前のようにサブジェクトの属性の値を用いるだけでなく、属性の値を証明する主体や当該属性の正しさが確認された日時を条件として用いるように構成してもよい。そのように構成した場合には、サブジェクトへの権限の割り当てにおいて、属性の値の信憑性や正確性に応じてきめ細かく条件付けできるようになる。

さらに本発明では、従前のようにロールの特定をサブジェクトによる指定のみにより決定するのではなく、サブジェクトが要求するアクセスを含むロールを情報システムが自動的に抽出し、アクセスに使用するロールとして用いることができるように構成することができる。そのように構成した場合には、サブジェクトがアクセス要求に使用するロールを適切に決定し、サブジェクトによるアクセスのやり直しなどの煩雑さや情報システムへの無駄な負荷を取り除くことができる。

以下、本発明の好適な実施の形態について、図面を参照しながら詳細に説明する。

図１は本発明における権限割り当てのモデルを示している。本発明では、図１に示すように、サブジェクトに対して属性割り当ての形で属性を割り宛て、またサブジェクトの属性に対して帰属条件という形で抽象ロールを割り当てており、結局、サブジェクトの属性を用いてサブジェクトとロールとが間接的に結び付けられていることなっている。本発明では、このような権限割り当てモデルを用いて権限を管理している。一方、従来の方法による権限割り当てモデルでは、図２に示すように、サブジェクトの識別子に対してロール割り当ての形で抽象ロールを直接結び付けている。本発明は、このように間接的にサブジェクトとロールとを結び付けて権限を管理するよう構成した点を特徴とする。

（第一の実施形態）
まず、本発明の第一の好適な実施形態について説明する。

図３は、本発明の第一の実施形態のアクセス制御方法が適用される情報システムの全体構成を示すブロック図である。この情報システムは、例えば、ある企業内の業務システムの一つであって、その企業の社員等などが業務の遂行に必要な電子化された文書の共有を図るために使用されるものであるとする。

図３に示す情報システムは、ファイルサーバ１と複数の利用者端末２と利用者属性管理装置３とが通信ネットワーク４を介して接続するように、構成されている。ファイルサーバ１は、企業秘密や個人情報などの保護すべき情報を含む電子ファイルを保持し、本発明に基づくアクセス制御を行いながら、利用者にこれら電子ファイルへのアクセスを提供する。利用者端末２は、利用者が、ファイルサーバ１によって管理される電子ファイルにアクセスし、その電子ファイルに対する閲覧、登録、削除、更新などの操作を行うために用いる端末である。利用者属性管理装置３は、この情報システムが稼動する企業における社員等の情報を一元管理するものであり、ファイルサーバ１をはじめとするその企業内の各種業務システムに対してそのような情報を提供する。ここでファイルサーバ１、利用者端末２及び利用者属性管理装置３は、通信ネットワーク４を介して相互に通信可能である。

図４は、ファイルサーバ１の構成を機能ブロックによって示すブロック図である。ファイルサーバ１は、送受信部１０、ファイル管理部１１、認可判定部１２、認証部１３、アクセス制御規則管理部１４、属性取得部１５及びメンテナンス部１６の各機能ブロックから構成されている。これらの機能ブロックの動作は、それぞれ次のようである。

送受信部１０は、通信ネットワーク４を介して、利用者端末２や利用者属性管理装置３と通信する機能ブロックであり、利用者端末２からのアクセスの要求を受け付けるとともにそれに対する応答を返したり、利用者属性管理装置３に利用者の属性を問い合わせるとともにその応答を取得したりする。

ファイル管理部１１は、電子ファイルをその属性とともに複数記憶し、さらに、その読み出しや書き込み、作成、消去などの操作機能を提供する。図１０は、この実施形態においてファイル管理部１１によって管理される電子ファイルとその属性の定義（すなわちオブジェクト管理情報）の状態の具体例を示している。図中、「ＩＤ」は、各電子ファイルのファイルサーバ１における識別子を示し、「名称」は、利用者の理解と把握が容易となるように電子ファイルを一覧などで表示する際にＩＤの代わりに用いられる見掛けの名称を示している。「種別」、「作成部署」、「対象ロケ」は、それぞれ、電子ファイルの内容の種別、電子ファイルを作成した部署、電子ファイルはどの地域（ロケーション）に関するかの情報であって、各電子ファイルに設定されている属性である。「種別」、「作成部署」、「対象ロケ」については、電子ファイルによっては対応する属性値をもたないものもある。

認可判定部１２は、ファイルサーバ１において管理される電子ファイルへの利用者によるアクセスの可否を判定する。

認証部１３は、ファイルサーバ１において管理される電子ファイルへのアクセスを行う利用者の認証を行う。本実施形態では、利用者の認証は、公開鍵証明書を用いた公開鍵暗号に基づく認証によって行なわれるものとし、認証部１３は、利用者の公開鍵証明書の正当性を検証するための認証局の公開鍵証明書も保持する。ただし、本発明によるアクセス制御方法を実施する上では、認証部１３は、認証局の公開鍵証明書の代わりに認証局の公開鍵を保持したり、あるいは、他の認証メカニズム、例えば、パスワードの照合による認証などを用いたりしてもよい。

アクセス制御規則管理部１４は、認可判定部１２が利用者による電子ファイルへのアクセスの可否を判定する際に判定基準として使用するアクセス制御規則群を保持し、認可判定部１２に提供する。このアクセス制御規則群については後に詳述する。

属性取得部１５は、認可判定部１２が利用者による電子ファイルへのアクセスの可否を判定する際にパラメータとして使用する利用者の属性を、送受信部１０を介して利用者属性管理装置３に問い合わせて取得し、認可判定部１２に提供する。

メンテナンス部１６は、システム管理者あるいは情報管理者などが情報システムのセキュリティポリシに基づきアクセス制御規則管理部１４において管理されるアクセス制御規則群の設定、更新、削除などを行うためのインターフェイスを備えている。

図５は、利用者端末２の構成を機能ブロックによって示している。利用者端末２は、送受信部２０、指示部２１、記憶部２２、表示部２３、処理部２４及び被認証部２５から構成されている。これらの各機能ブロックの動作はそれぞれ次のようである。

送受信部２０は、通信ネットワーク４を介してファイルサーバ１と通信するためのものであり、ファイルサーバ１にアクセスの要求を送信するとともに、それに対する応答を取得する。

指示部２１は、利用者端末２を使用する利用者からのファイルサーバ１へのアクセスやその結果に対する編集操作などの指示を受け付ける部分であり、具体的にはマウスやキーボードなどから構成される。

記憶部２２は、ファイルサーバ１から取得した電子ファイルやファイルサーバ１に登録する予定の電子ファイルの内容を記憶するものである。

表示部２３は、ファイルサーバ１へのアクセス要求に対する応答や、取得した電子ファイル、その他の処理結果を表示して利用者に伝える部分であり、具体的にはＣＲＴや液晶ディスプレイなどの表示装置あるいはスピーカーなどの音声出力装置などで構成される。

処理部２４は、ファイルサーバ１から取得した電子ファイルやファイルサーバ１に登録する予定の電子ファイルを編集あるいは数値計算などのために利用する部分である。

被認証部２５は、ファイルサーバ１による認証の要求に応じて、利用者端末２を使用する利用者のＩＤを証明する。前述の通り、本実施形態では公開鍵証明書を用いた認証方式を採用していることから、被認証部２５には、利用者の秘密鍵およびこれに対応する公開鍵証明書が保持される。なお、被認証部２５のうち利用者の秘密鍵の記憶部分あるいは被認証部２５全体を可搬媒体など他の装置に実装して、必要に応じて利用者端末２から切り離せるように構成してもよい。そのような媒体としては、秘密鍵の漏洩によるなりすましなどの被害を予防する観点から、ＩＣカードなどの耐タンパ性を有するものを用いるのが望ましい。

図６は、利用者属性管理装置３の構成を機能ブロックによって示している。利用者属性管理装置３は、送受信部３０、利用者属性格納部３１及びメンテナンス部３２から構成されている。これらの機能ブロックの動作はそれぞれ次のようである。

送受信部３０は、通信ネットワーク４を介して、ファイルサーバ１と通信するものであり、ファイルサーバ１からの利用者属性の取得要求を受け付け、該当する利用者の属性を利用者属性格納部３１から取り出して返却する。利用者属性の取得要求は、利用者の識別子である利用者ＩＤを含むものとする。

利用者属性格納部３１は、情報システム内の正規利用者の各種属性の値を、各利用者のＩＤに対応付けて保持する。図７は、本実施形態において利用者属性格納部３１によって管理される利用者の情報の具体例を示している。「利用者ＩＤ」は、その利用者の識別子を示している。「氏名」、「所属」、「担当名」、「役職」、「職歴」、「担当ロケ」、「内線」は、それぞれ、その利用者の氏名、所属、担当する職務内容、役職名、職歴、担当する地域（ロケーション）を示すものであって、各利用者に割り当てられる属性である。利用者によっては、これらの属性に対応する属性値をもたないこともある。

メンテナンス部３２は、システム管理者あるいは企業における人事担当者などが利用者属性格納部３１において管理される利用者属性の値や利用者のエントリ全体を設定、更新、削除などするために使用する部分である。

ここで、ファイルサーバ１のアクセス制御規則管理部１４において管理されるアクセス制御規則群についてより詳細に説明する。アクセス制御規則管理部１４は、アクセス制御規則として、ロール定義情報、ロール帰属条件情報、及び単位権限集合定義情報の３種類の情報をそれぞれ一ないし複数個保持している。ここでロール定義情報は、ファイルサーバ１内でのアクセス権限の管理に用いられるロールを定義するための主たる制御情報である。ロール帰属条件情報は、利用者すなわちサブジェクトがロールへの所属を許されるために満たすべき条件を定義する情報である。単位権限集合定義情報は、ファイルサーバ１において扱われる権限の集合を定義する情報である。なお、ロール定義情報とロール帰属条件情報と単位権限集合定義情報は互いに多対多の関係にある。

図８は、本実施形態におけるロール定義情報１００、ロール帰属条件情報１１０及び単位権限集合定義情報１２０の定義例をそれぞれ一つずつ示したものである。

ロール定義情報１００は、ロールごとに対応して定義され、それぞれロール名称部１０１、ロール帰属条件指示部１０２、単位権限集合指示部１０３の３つのフィールドから構成されている。ここでは「計画確認」のロールのロール定義情報が示されているが、他のロール定義情報も同様の構成を取る。ここでロール名称１０１は、当該ロールの識別子であり、ファイルサーバ１内のロール定義情報の中でユニークになるように設定される。ロール帰属条件指示部１０２は、そのロールに対応するロール帰属条件、すなわちそのロールに所属が許されるためにサブジェクトが満たすべき条件を構成する１ないし複数のロール帰属条件情報をそれぞれの識別子で表わしている。複数のロール帰属条件情報の識別子が設定されている場合には、サブジェクトがそれぞれに対応するロール帰属条件情報を全て満たした場合にそのロールへの帰属を許可するという意味である（すなわちＡＮＤ結合）。単位権限集合定義指示部１０３は、そのロールに対応する権限集合（すなわち第一の権限集合）、言い換えればそのロールに割り当てられる権限の集合を構成する一ないし複数の単位権限集合定義情報をそれぞれの識別子で表している。複数の単位権限集合定義情報の識別子が設定されている場合には、それぞれに対応する単位権限集合定義情報の和すべてをそのロールの権限として付与しているという意味である（すなわちＯＲ結合）。

ロール帰属条件情報１１０は、そのロール帰属条件情報の識別子を指定する帰属条件識別部１１１のフィールドと、属性指定部１１２、演算子部１１３及び比較値部１１４の３つのフィールドの内容から構成される条件式、あるいはそのような条件式をＡＮＤやＯＲなどの論理演算子である結合子１１５によって複数結合した複合的な条件式との組で構成される。ここではロール帰属条件の識別子が「０００１」である場合が示されているが、他のロール帰属条件情報も同様の構成を取る。属性指定部１１２は、ロールへの帰属を判定する際に評価されるサブジェクトの属性の名称を指定し、演算子部１１３は、その評価の際に用いる演算子を指定し、比較値部１１４は、属性指定部１１２により指定されるサブジェクトの属性の値と演算子部１１３の演算子とを用いて比較される値を指定する。

図８に示すように、ロール定義情報１００とロール帰属条件情報１１０とはロール定義情報１００のロール帰属条件指示部１０２により対応付けられている。両者を総合すると、図８に例示するものは、以下のように解釈される：
「担当名」という名称の属性の値が「予算管理」であるか、もしくは、「職歴」という属性の値が「３」より大きくかつ「所属」という属性の値に「営業」を部分文字列として含むようなサブジェクトは、ロール「予算執行状況確認」に帰属することを認められる。

単位権限集合定義情報１２０は、その単位権限集合定義情報の識別子を指定する単位権限集合識別部１２１と権限定義部１２２と制約条件導出規則定義部１２３との３つのフィールドからなっている。権限定義部１２２は、一ないし複数の総称権限からなり、制約条件導出規則定義部１２３は、一つのオブジェクト制約条件導出規則からなる。図８に示されるもの以外の他の単位権限集合定義情報も同様の構成を取る。ここで総称権限とは、オブジェクト属性に関する条件式によって内包的に定義されたオブジェクト集合と、操作の種別とを対にしたものであって、抽象的な権限集合を表わしている。オブジェクト制約条件とは、オブジェクトの属性に関する条件式であって、総称権限として定義された権限集合に制約を課してその権限集合の部分集合を形成するために用いられる。オブジェクト制約条件導出規則とは、そのようなオブジェクト制約条件を導出するための定義情報であって、サブジェクトの属性をパラメータとするメタレベルの規則である。

権限定義部１２２に含まれる一つの総称権限１３０は、属性指定部１３１と属性値指定部１３２と操作種別部１３３からなる。属性指定部１３１は、アクセス対象のオブジェクトを総称的に指し示すために用いるオブジェクトの属性の名称を指定し、属性値指定部１３２は、属性指定部１３１にて指定した属性の値を指定し、操作種別部１３３は、属性指定部１３１と属性値指定部１３２とにより表されるオブジェクトの集合に対するアクセスの種類を指定する。図８に示す例では、総称権限１３０は、『「種別」という名の属性の値が「計画書」であるようなオブジェクト全般に対するＲＥＡＤ（読み出し）操作権限』を意味する。

制約条件導出規則定義部１２３に含まれるオブジェクト制約条件導出規則１４０は、属性指定部１４１、演算子部１４２、比較値部１４３の３つのフィールドの値から構成される条件式、あるいはそのような構造を持つ条件式を結合子１４４によって複数結合した複合的な条件式の構成を取る。図８に示す例では、オブジェクト制約条件導出規則１４０は、『オブジェクトの「作成部署」という名称の属性の値がサブジェクトの「所属」という名称の属性の値と同一であるか、もしくは、オブジェクトの「対象ロケ」属性の値がサブジェクトの「担当ロケ」属性の値に含まれていること』と解釈される。この式にサブジェクトの「所属」属性ならびに「担当ロケ」属性の具体的な値を当てはめることで、総称権限１３０に対するオブジェクトに関するオブジェクト制約条件が得られる。

次に、図９を参照して、本実施形態における情報システムの全体の動作について説明する。

まず、利用者からの指示に基づいて利用者端末２からファイルサーバ１に対してログイン要求を送信する（Ｍ９１）。ログイン要求には、その利用者の識別子である利用者ＩＤと、そのログイン中におけるアクセスの際に利用者が使用するロールを指定するロール名称とが含まれている。ログイン要求を受信したファイルサーバ１の認証部１３は、利用者端末２の被認証部２５及び送受信部２０とファイルサーバ１の送受信部１０とを介してさらにメッセージを交換して利用者端末２の利用者の認証を行う。そして、ファイルサーバ１の正当な利用者であると判定した場合には、ログイン成功を、それ以外の場合にはログイン失敗を利用者端末２に返却する（Ｍ９２）。認証が成功した場合、ファイルサーバ１は、ログイン要求に含まれていたその利用者の利用者ＩＤと今回のログインの間使用するロールの名称とを認証部１３に記憶しておく。

ログインが成功した場合、利用者端末２の利用者は、ファイルサーバ１において管理されているファイルへのアクセスを繰り返し要求することができる（Ｍ９３）。各アクセスの際には本発明に基づくアクセス制御が行われ、アクセスが許可された場合にはアクセス要求に対応するファイルの内容あるいはファイルサーバ１に管理されるファイルに対して操作が行われた結果が返却され、それ以外の場合にはアクセス不許可を通知する情報が、アクセス応答として利用者端末２に返却される（Ｍ９４）。

必要なファイルへのアクセスを終えた利用者は、利用者端末２に指示し、利用者端末２からログアウトの要求がファイルサーバ１に伝えられ（Ｍ９５）、それを受諾したファイルサーバ１からログアウトの確認が通知される（Ｍ９６）。この時、ファイルサーバ１は、記憶しておいたログイン中の利用者の識別子を消去する。

次に、図１１、図１２及び図１３に示すフローチャートと、図７、図８及び図１０に示した具体的な設定例を用いて、図９に示したアクセス要求（Ｍ９３）を受信したファイルサーバ１におけるアクセス制御処理をより詳細にかつ具体的に説明する。

図１１は、アクセス要求（Ｍ９３）を受信した際のファイルサーバ１におけるアクセス制御処理を示しており、図１２は、図１１における処理ステップＳ０４をより詳細に示しており、図１３は、図１１における処理ステップＳ０５をより詳細に示している。

具体的な例に基づいて処理の流れを説明するに当たって、ある利用者が利用者端末２からファイルサーバにログインを行って成功しており、その際に用いた利用者ＩＤが「５０４」、指定したロールの名称が「計画確認」であったとする。

アクセス要求（図９のＭ９３）を受信したファイルサーバ１は、図１１に示すように、まずアクセス要求を認可判定部１２において解析してアクセス対象のオブジェクトと操作の種別を特定する（Ｓ０１）。これらはオブジェクトの識別子と操作の種別の組の形式で保持される。次に、認可判定部１２は、そのアクセスに用いられるロールを特定する（Ｓ０２）。本例ではアクセスに用いるロールはログイン時に指定して認証部１３に記憶しておくこととしているから、認証部１３からこれを取得する。次に属性取得部１５が利用者属性管理装置３に問い合わせを行い、利用者属性管理装置３において管理されているアクセス要求を行ったサブジェクトの属性を全て取得し、記憶する（Ｓ０３）。この時、ログイン時に記憶してあった利用者ＩＤを問い合わせのキーとして使用する。次に、認可判定部１２は、アクセス要求を行ったサブジェクトが、指定したロールに帰属するか否かを判定する（Ｓ０４）。

この処理（Ｓ０４）について、図１２を用いてより詳細に説明する。まず、認可判定部１２は、使用されるロールの名称に対応するロール定義１０１（図８参照）を参照し、そのロールのロール帰属条件指示部１０２において指定されている全てのロール帰属条件を取得する（Ｓ１０１）。本例では図８に記載の通り唯一つのみ指定されている、ロール帰属条件１１０を取得する。以後、取得されたロール帰属条件それぞれについて順次評価を行うため、まず、未評価のロール帰属条件がないか判定する（Ｓ１０２）。ここでは、先ほど取得されたロール帰属条件１１０が未評価で残っているために判定結果が「はい」となり、次のステップ（Ｓ１０３）に進み、未評価のロール帰属条件のうち先頭のものを取得する。ここでは、ロール帰属条件１１０が取得される。次に、ロール帰属条件１１０に含まれる条件式の属性指定部１１２の各々に、先のステップＳ０３で取得したサブジェクトの属性のうち該当するものを代入してその条件式を評価する（Ｓ１０４）。

今回の例の場合、サブジェクトの利用者ＩＤは「５０４」であり、その属性は図７に示す通りであるから、条件式の「担当名」には「予算管理」が、「職歴」には「２年」が、「所属」には「営業一部」が代入され、その結果得られた式『（「予算管理」＝＝「予算管理」）ＯＲ（（「２」＞「３」）ＡＮＤ（「営業一部」Ｓｕｂｓｔｒｉｎｇ「営業」））』は第一の等値比較式が真であるために真となる。この評価結果が真であるか否かが判定され（Ｓ１０５）、もしも偽であった場合はこの時点でロールへの帰属が不許可と判定される（Ｓ１０７）。これは、先述の通りあるロールに複数の帰属条件が課されていた場合にはそれらはＡＮＤ結合と解釈されるためである。

今回の例の場合、Ｓ１０５の結果が真であったために、評価し終えたロール帰属条件１１０を処理対象から除外した後に（Ｓ１０６）、次のロール帰属条件を評価するため繰り返し処理の先頭に戻る。ただし、今回の例の場合、指定されたロールに対応するロール帰属条件はただ一つであったから、ステップＳ１０２では偽と判定されてステップＳ１０８に進み、当該サブジェクトの指定されたロールへの帰属性は真であるという判定結果と共に処理ステップＳ０４は終了する。

図１１に戻って説明を続ける。ステップＳ０４でのロール帰属の判定結果が偽であった場合には、後述するステップＳ０９に進むが、今回の具体例では判定結果は真となることから、次のステップ（Ｓ０５）に進み、サブジェクト権限集合（すなわち第二の権限集合）の特定を行う。

この処理（Ｓ０５）について、図１３を用いてより詳細に説明する。まず、認可判定部１２は、サブジェクトに許可される権限集合を空集合に初期化する（Ｓ２０１）。

その後、使用されるロールの名称に対応するロール定義１０１（図８参照）を参照し、そのロールの単位権限集合定義指示部１０３において指定されている全ての単位権限集合定義を取得する（Ｓ２０２）。本例では図８に記載の通りただ一つのみ指定されている単位権限集合定義情報１２０を取得する。以降、取得された単位権限集合定義情報それぞれについて順次評価を行うため、まず、未評価の単位権限集合定義情報がないかどうか判定する（Ｓ２０３）。ここでは、先ほど取得された単位権限集合定義情報１２０が未評価で残っているために判定結果が「はい」となり、次のステップ（Ｓ２０４）に進み、未評価の単位権限集合定義情報のうち先頭のものを取得する。ここでは、単位権限集合定義情報１２０が取得される。次に、着目している単位権限集合定義情報１２０の制約条件導出規則定義部１２３に含まれるオブジェクト制約条件導出規則１４０の比較値部１４３の各々に、先のステップＳ０３で取得したサブジェクトの属性のうち該当するものを代入してオブジェクト制約条件を導出する（Ｓ２０５）。今回の例の場合、サブジェクトの利用者ＩＤは「５０４」であり、その属性は図７に示す通りであるから、得られるオブジェクト制約条件は、『「作成部署」属性の値が「営業一部」であるか、「対象ロケ」属性の値が「東京，千葉」に含まれること』となる。

次に、着目している単位権限集合定義情報１２０の権限定義部１２２に含まれる総称権限１３０に対して、先に導出されたオブジェクト制約条件を付加して、これをサブジェクト権限集合に加える（Ｓ２０６）。総称権限１３０は『「種別」属性が「計画書」であるオブジェクトに対する「ＲＥＡＤ」操作』であったから、先に導出されたオブジェクト制約条件を付加して得られる権限集合は、『「作成部署」が「営業一部」であるかもしくは「対象ロケ」が「東京，千葉」に含まれるような、「種別」が「計画書」であるオブジェクトに対する「ＲＥＡＤ」操作』となる。

このような権限集合の抽出について、図１０をもとにして具体的に見てみると、そのロールに割り当てられていた当初の総称権限１３０に該当するオブジェクトは、ＩＤが「１０００２」、「１０００６」、「１０００７」、「１０００９」である４つであったのに対して、オブジェクト制約条件を加えることによって、ＩＤが「１０００２」、「１０００７」である２つのオブジェクトに絞り込まれている。これは、ロールに割り当てられている権限が、サブジェクト個別の属性に応じてサブジェクト個別に絞り込まれているということを示している。このような機構によって、サブジェクト個別に少しずつ異なる権限集合を共通のロールで定義することが可能であり、ロールの定義というアクセス制御情報の設定・修正にかかるコストが少なくてすむ。

さて、上記の通り、サブジェクト権限集合への追加を行った後、処理した単位権限集合定義情報１２０を処理対象から除外した後に（Ｓ２０７）、次の単位権限集合定義情報を評価するため繰り返し処理の先頭（Ｓ２０３）に戻る。今回の例の場合、指定されたロールに対応する単位権限集合定義情報はただ一つであったから、ステップＳ２０３では偽と判定されてステップＳ２０８に進み、これまでに得られている権限集合をそのサブジェクトの権限集合として記録し、処理ステップＳ０５は終了する。

図１１に戻って説明を続ける。ステップＳ０５で取得されたサブジェクト権限集合に、要求されたアクセスに対応するアクセス権限が含まれるか否かを判定する（Ｓ０６）。要求されたアクセスに対応するアクセス権限とは、ステップＳ０１で特定したオブジェクトと操作の組である。判定結果が真であれば、そのアクセス要求は許可され、認可判定部１２からファイル管理部１１にアクセス要求が伝達されてそのアクセス要求に対応する操作が実行される（Ｓ０７）。その後、この操作に対応する操作結果、例えば、ＲＥＡＤならば対応するファイルの内容が利用者端末２に返信され（Ｓ０８）、そのアクセス要求に関わる処理は終了する。ステップＳ０６の判定結果が偽であった場合は、そのアクセス要求は拒絶され、その旨の応答が利用者端末２に返信され（Ｓ０９）、アクセス要求に関わる処理は終了する。

ところで、上記の例において、企業内の人事に異動があり、利用者へのロールの割り当ても変更が迫られるような場合を考えてみる。

通常のロールベース方式であれば、ロールと利用者との対応関係を両者の識別子によって対応付けているため、利用者属性管理装置３において管理される所属などの利用者情報の修正のほかに、対応するロール割当情報の修正も必須となる。しかしながら、本発明に基づくアクセス制御方法によれば、上記の例で示した通り、ロールと利用者との対応付けは利用者の有する属性によって間接的に行われているため、利用者属性管理装置３において管理される利用者情報の修正のみを行えばよい。情報の修正は、アクセス制御の目的に限らず通常行われる作業であるから、本発明に基づくアクセス制御方法では、人事異動などが発生してもアクセス制御のみを目的とした管理的作業（アクセス制御規則群の変更作業）は一切発生しないといえる。

なお、上記の例では、利用者によるロールの指定をログイン時に行うとしていたが、アクセス要求を送信する都度ロールを指定あるいは変更するように処理を構成してもよい。

また、上記の例では、利用者属性管理装置３からのサブジェクトの属性の取得（Ｓ０３）をアクセス要求が発生した後、その都度に行うとしていたが、初回のアクセス要求の発生時にサブジェクトの属性の取得の処理を行い、得られた属性情報を認証部１３あるいは属性取得部１５などに記憶しておき、後続のアクセス要求時には利用者属性管理装置３への問い合わせは行わず、認証部１３あるいは属性取得部１５などに記憶されている情報を参照して再利用するように構成してもよい。あるいは、サブジェクトの属性の取得の処理をログイン時に行って認証部１３あるいは属性取得部１５に記憶し、これらを参照して利用するよう構成してもよい。

上記の例では、利用者属性管理装置３からサブジェクトの属性を取得する際、そのサブジェクトが有する属性を全て取得するとしていたが、これをロールへの帰属の判定（Ｓ０４）あるいは、サブジェクト権限集合の導出（Ｓ０５）に必要なだけの属性のみを取得するように構成してもよい。具体的には、指定されたロールに対応するロール帰属条件の属性指定部に現れるサブジェクトの属性群と、同じく指定されたロールに対応する単位権限集合定義情報の制約条件導出規則定義部に含まれるオブジェクト制約条件導出規則の比較値部に現れるサブジェクトの属性群のみを指定して利用者属性管理装置３に属性を要求するように構成すればよい。

上記の例では、サブジェクト権限集合の導出（Ｓ０５）をアクセス要求が発生した後、その都度に行うとしていたが、初回のアクセス要求の発生時にサブジェクト権限集合の導出の処理を行い、得られたサブジェクト権限集合を認証部１３あるいは認可判定部１２などに記憶しておき、後続のアクセス要求時には認証部１３あるいは認可判定部１２などに記憶されている情報を参照して再利用するように構成してもよい。あるいは、サブジェクト権限集合の導出の処理をログイン時に行って認証部１３あるいは認可判定部１２などに記憶し、これらを参照して利用するよう構成してもよい。

上記の例では、ロール帰属条件に含まれる比較値部に記載される値として、文字列や数値などの定数のみを具体例として記載していたが、例えば、日時や曜日などシステムの動作環境に関する情報（コンテキスト情報）を指定したり、オブジェクトの属性の値を指定したりすることも可能である。同様に、単位権限集合定義情報の制約条件導出規則定義部に含まれるオブジェクト制約条件導出規則の比較値部に記載されるパラメータとして、サブジェクトの属性の値をその名称で指し示すだけでなくコンテキスト情報などを用いることが可能である。

上記の例では、電子化されたファイルに対する操作をアクセス制御される対象としたが、それ以外の各種情報システムにおける処理、例えば、数値演算プログラムの実行なども本発明によるアクセス制御の対象とすることが可能であるのはいうまでもない。

（第二の実施形態）
次に、本発明の他の好適な実施形態について説明する。図１４は、本発明の第二の実施形態のアクセス制御方法が適用される情報システムの全体構成を示している。この情報システムは、情報提供者であるＡ社がインターネット上で特定多数の利用者に対して各種デジタルコンテンツを提供することを目的としたシステムである。

この情報システムは、情報提供サーバ５と複数の利用者端末６と複数の属性証明サーバ７とがインターネット８を介して接続するよう構成されている。

情報提供サーバ５は、インターネット上の特定多数の利用者に対して提供する各種コンテンツを管理する装置であり、本発明に基づくアクセス制御を行いながら利用者にこれら情報サービスへのアクセスを提供する。ここで「特定多数」としているのは、情報サービス、コンテンツの提供対象は、インターネットに接続する任意の利用者端末ならびにその利用者ではなく、利用者が有する属性に関して一定の条件を設けて視聴制限しているためである。

利用者端末６は、利用者が情報提供サーバ５にて管理されるサービス、コンテンツにインターネット８を介してアクセスし、これらに対する閲覧、更新、コメント登録などの操作を行うために用いる端末である。

属性証明サーバ７は、利用者端末６を使用する利用者の何らかの属性を管理している主体が運営している装置であって、利用者が有する属性を証明する属性証明書を発行してその利用者に付与する装置である。本実施形態においては、Ａ社と提携関係にあるＢ社、Ｃ社などがそれぞれ属性証明サーバを運営しているとし、Ｂ社、Ｃ社らは、利用者に対して、その利用者が情報提供サーバ５にアクセスするより先に属性証明書を発行してあるものとする。情報提供サーバ５、利用者端末２、属性証明サーバ７は通信ネットワーク４を介して相互に通信可能な構成となっている。ただし、利用者端末２から情報提供サーバ５に対してアクセスが実施される際、ならびに、情報提供サーバ５によるアクセスの制御が実施される際に、利用者端末２や情報提供サーバ５と属性証明サーバ７とが通信可能であることは必須ではない。

図１５は、情報提供サーバ５の構成を機能ブロックとして示している。情報提供サーバ５は、第一の実施形態で説明したファイルサーバ１と類似した構成を有し、送受信部５０、コンテンツ管理部５１、認可判定部５２、認証部５３、アクセス制御規則管理部５４、属性認証部５５及びメンテナンス部５６から構成されている。これらの機能ブロックのうち第一の実施形態のファイルサーバにおけるものと同名の機能ブロックは、第一の実施形態での対応する機能ブロックと同等の機能、構成及び動作を有する。したがって、以下では、第一の実施形態では示されていない機能ブロックについて、その動作を説明する。

コンテンツ管理部５１は、利用者に対して提供するコンテンツをその属性とともに複数記憶し、さらに、その読み出しや書き込み、作成、消去などの操作機能を提供する。

アクセス制御規則管理部５４は、認可判定部５２が利用者による電子ファイルへのアクセスの可否を判定する際に判定基準として使用するアクセス制御規則群を保持し、認可判定部５２に提供する。この点については、アクセス制御規則管理部５４は、第一の実施形態のファイルサーバ１でのアクセス制御規則管理部１４と同様であるが、管理するアクセス制御規則群の細部の構成が異なる。これについては後に詳述する。

属性認証部５５は、利用者によるコンテンツへのアクセスの可否を判定する際に認可判定部５２が使用する利用者の属性を、属性証明書を用いた属性認証によって取得し、認可判定部５２に提供する。属性証明書とその認証については後に詳述する。

図１６は、利用者端末６の構成を機能ブロックとして示している。利用者端末６は、第一の実施形態で説明した利用者端末２と類似した構成を有し、送受信部６０、指示部６１、記憶部６２、表示部６３、処理部６４、属性管理部６５から構成される。これらの機能ブロックのうち第一の実施形態の利用者端末におけるものと同名の機能ブロックは、第一の実施形態での対応する機能ブロックと同等の機能、構成及び動作を有する。したがって、以下では、第一の実施形態では示されていない機能ブロックについて、その動作を説明する。

属性管理部６５は、利用者端末６を使用する利用者が有する属性証明書とこれに対応する秘密鍵とを、属性に応じて複数組保持し、また、情報提供サーバ５による属性認証の要求に応じてその属性証明書などを用いて利用者の有する属性を情報提供サーバ５に対して証明する。なお、属性管理部６５のうち属性証明書に対応する秘密鍵の記憶部分あるいは属性管理部６５の全体を可搬媒体など他の装置に実装して、必要に応じて利用者端末６から切り離せるように構成してもよい。その媒体としては、秘密鍵の漏洩によるなりすましなどの被害を予防する観点から、ＩＣカードなどの耐タンパ性を有するものを用いるのが望ましい。

本例で用いる属性証明書の構成と、属性証明書を用いた属性認証についてその概略を述べる。

本例で用いる属性証明書は、公開鍵暗号の原理を利用して属性を有することを証明する電子データであって、証明する対象である属性、その属性証明書の所有者が有する秘密鍵に対応する公開鍵、属性を証明する主体の名称、その属性証明書に記載の属性の確認日時、その属性証明書の有効期間、の５つの部位から構成されるデータ全体に、その属性を証明する主体が秘密裏に有する属性証明用の秘密鍵により、公開鍵暗号に基づくデジタル署名を付与したデータである。

属性証明書を用いた属性認証を行う場合、被認証者は、属性証明書に含まれる公開鍵に対応する秘密鍵により、任意のデータ、例えば認証者から送付されたチャレンジデータに対してデジタル署名を行い、そのデジタル署名による結果をレスポンスデータとして属性証明書とともに認証者に送付する。認証者は、受け取ったレスポンスデータに含まれるデジタル署名をその属性証明書に含まれる公開鍵で検証し、被認証者がその属性証明書の正当な所有者であることを確認する。さらに、属性証明書に含まれるデジタル署名を、別途安全な方法で入手した、認証者が信頼する属性の証明主体の公開鍵で署名検証することにより、その属性証明書に記載されている属性が、信頼できるものであることを確認する。さらに、必要に応じて、属性証明書に記載の有効期間に現在日時が含まれるか確認する、属性証明書に記載の属性確認日時から現在日時までの経過時間が属性の最新さの観点から許容可能な範囲か確認する、属性の証明主体が発行する属性証明書の無効化リストを参照してその属性証明書が掲載されていないことを確認する、などを行って、対象とする属性証明書は受け入れるのに十分な有効性を有するか否かを確認する。これらのステップを踏むことによって、認証者は被認証者の有する属性を、属性証明書によって安全（セキュア）に確認することができる。また、属性証明書には被認証者を識別する情報が一切ないことから、被認証者は自身の身元を明かさずに、自身の有する属性を証明することが可能である。

次に、情報提供サーバ５のアクセス制御規則管理部５４において管理されるアクセス制御規則群について、より詳細に説明する。図１７は、本実施形態において用いるアクセス制御規則群の具体例を示している。ここで用いるアクセス制御規則群は第一の実施形態におけるそれとほぼ同一であるが、以下の２点で異なる。

まず、ロール帰属条件情報１６０について、これを構成する個々の原始的な条件式の構成要素として評価対象指定部１６６が追加されている点で、第一の実施形態におけるロール帰属条件情報１１０とは異なる。評価対象指定部１６６は、対応する属性指定部１６２によりその名称で指定されたサブジェクトの属性のどの側面を後続の演算子部１６３と比較値部１６４により評価するかを指定する。つまり、第一の実施形態におけるロール帰属条件情報を構成する条件式では特に明示することもなく属性指定部１１２において指定された属性の「値」を評価の対象としていたが、本実施形態では、属性指定部１６６によって指定された属性について、その値だけでなくその属性の確認日時やその属性の証明者などといった属性の属性を評価対象に指定し、確認することが可能となっている。これは、属性の取得を利用者が提示する属性証明書を用いた属性認証によって行うことに対応するためである。このような条件付けを追加で行わなければ、信頼を置いていない主体が発行した属性証明書を受け入れてしまったり、あるいは、記載内容が既に有効ではないような属性証明書を受け入れてしまったりするといった事態が発生する。

また、一つの属性指定部１６２に対して評価対象指定部１６６と演算子部１６３と比較値部１６４の３つ組が一つ以上対応付けられている。これは、一つの属性について複数の観点からの条件を指定可能であることを示す。複数の記載がある場合には、これらが全て満たされた場合にのみ、その属性に関する評価が真となる（すなわちＡＮＤ結合）。以上より、図１７に示すロール帰属条件式１６１は、以下のように解釈される：
（情報サービス提供者自身である）「Ａ社」が証明主体であって値が「Ｃランク」よりも大きい、「会員種別」という名称の属性を持つか、あるいは、
（情報サービス提供者が提携関係にあり、属性証明主体として信頼する）「Ｂ社」あるいは「Ｃ社」が証明主体であって、その確認日時が現在日時の１日前よりも後であり値が「特別」である「会員区分」という属性を持っているか否か。

第二に、単位権限集合定義情報１７０を構成する制約条件導出規則定義部１２３に含まれるオブジェクト制約条件導出規則１９０について、比較値部１９３においてパラメータとして指定するサブジェクトの属性を、その名称だけでなくその証明者によっても指定し、制約する点で、第一の実施形態におけるオブジェクト制約条件導出規則１４０とは異なっている。このような構成となっているのは、上述したロール帰属条件情報１６０の構成の場合における理由と同一であり、オブジェクト制約条件を導出する際のパラメータとして、信頼できる確かなサブジェクトの属性を使用するためである。図１７に例示するオブジェクト制約条件１９０は、『オブジェクトの「対象性別」属性の値が、サブジェクトの有する「Ｘ社」が証明した「性別」属性の値と同一であり、かつ、オブジェクトの「掲載地域」属性の値がサブジェクトの「居住地域」属性の値が含まれていること』と解釈される。

次に、図１８を参照して、本実施形態において情報提供サーバ５がアクセス要求を受信した際のアクセス制御の動作を説明する。

まず、情報提供サーバ５が利用者端末６からアクセス要求を受信すると、認可判定部５２がこれを解析してアクセス対象のオブジェクトと操作の種別を特定する（Ｓ３０１）。これらはオブジェクトの識別子と操作種別の組の形式で保持される。次に、特定されたオブジェクトの属性をコンテンツ管理部５１に要求して取得する（Ｓ３０２）。次に、ステップＳ３０２で取得した属性群とステップＳ３０１で特定された操作種別とに基づいて、要求されたアクセスに対応する権限を含む総称権限を、アクセス制御規則管理部５４において管理している全ての単位権限集合定義情報の総称権限の中から検索し、最初に発見した総称権限を含む単位権限集合定義情報に対応するロールをそのアクセスに用いられるロールとする（Ｓ３０３）。

次に、認可判定部５２は、ステップＳ３０３で特定されたロールに対応する全てのロール帰属条件情報を取得する（Ｓ３０４）。次に、属性認証部５５に指示し、ステップＳ３０４で取得されたロール帰属条件情報に含まれる条件式それぞれの属性指定部１６２に記載されている属性の名称を取り出し、これらの集合を指定して利用者端末６に対して属性の証明を要求する（Ｓ３０５）。このとき、利用者端末６に対して、さらに各属性指定部１６２に対応する評価対象指定部１６６、演算子部１６３、比較値部１６４の組をも送付し、利用者端末６が証明する属性についての条件を指定してもよい。

このような属性の証明の要求を受け取った利用者端末６は、属性管理部６５において、指定された属性に対応する属性証明書を検索し、見つかった属性証明書を用いて属性の保有の証明を行う。より詳細には、上述の通り、証明する属性を証明する属性証明書に対応する秘密鍵によってデジタル署名を生成し、これと属性証明書群とを情報提供サーバ５に返信する（Ｓ３０６）。

返信を受け取った情報提供サーバ５は、返信データのデジタル署名や、添付されている属性証明書のデジタル署名を検証し、正当性を確認し、確認されたものについては、各属性証明書に記載されている属性の値や、証明者の名称、属性確認日時などの値を取得する（Ｓ３０７）。次に、認可判定部５２により、ステップＳ３０４おいて取得したロール帰属条件情報の該当箇所に、ステップＳ３０７において取得したサブジェクトの属性を代入して評価し、そのサブジェクトの特定されたロールへの帰属を判定する（Ｓ３０８）。この処理の詳細は、第一の実施形態の場合と同様である。

ステップＳ３０８において判定結果が偽であった場合は、ステップＳ３１４に進み、アクセス拒絶の応答を利用者端末６に返信して処理を終了する。ステップＳ３０８おいて判定結果が真であった場合はステップＳ３０９に進む。

ステップＳ３０９では、ステップＳ３０３で特定されたロールに対応する全ての単位権限集合定義情報を取得する。次に、取得された単位権限集合定義情報の該当箇所に、ステップＳ３０７において取得したサブジェクトの属性を代入して評価し、そのロールに割り当てられている権限集合のうち、そのサブジェクトに割り当てられる権限（サブジェクト権限集合）を抽出する（Ｓ３１０）。この処理の詳細は第一の実施形態例と同様である。なお、単位権限集合定義情報の評価に必要なだけのサブジェクト属性が取得できていなかった場合は、属性認証部５５に追加の取得を指示してこれを得て、評価に用いる。

次に、ステップＳ３１０で取得されたサブジェクト権限集合に、要求されたアクセスに対応するアクセス権限が含まれるか否かを判定する（Ｓ３１１）。要求されたアクセスに対応するアクセス権限とは、ステップＳ３０１で特定したオブジェクトと操作の組である。判定結果が真であれば、そのアクセス要求は許可され、認可判定部１２からコンテンツ管理部５１にアクセス要求が伝達されてそのアクセス要求に対応する操作が実行される（Ｓ３１２）。その後、その操作に対応する操作結果、例えば、ＲＥＡＤ（読み出し）ならば対象とするファイルの内容が利用者端末６に返信され（Ｓ３１３）、そのアクセス要求に関わる処理は終了する。ステップＳ３１１の判定結果が偽であった場合には、そのアクセス要求は拒絶され、その旨の応答が利用者端末６に返信され（Ｓ３１４）、アクセス要求に関わる処理は終了する。

本発明に基づく権限割り当てのモデルを示す図である。 従来の技術による権限割り当てのモデルを示すブロック図である。 本発明の第一の実施形態のアクセス制御方法が適用される情報システムの構成を示すブロック図である。 第一の実施形態でのファイルサーバの構成を示すブロック図である。 第一の実施形態での利用者端末の構成を示すブロック図である。 第一の実施形態での利用者属性管理装置の構成を示すブロック図である。 第一の実施形態での利用者属性管理情報の一例を示す図である。 第一の実施形態でのアクセス制御規則群の一例を示す図である。 第一の実施形態における情報システムの処理手順の概要を示すラダー図である。 第一の実施形態でのオブジェクト管理情報の一例を示す図である。 第一の実施形態でのアクセス制御処理を示すフローチャートである。 第一の実施形態でのロール帰属判定を示すフローチャートである。 第一の実施形態でのサブジェクト権限集合取得を示すフローチャートである。 本発明の第二の実施形態のアクセス制御方法が適用される情報システムの構成を示すブロック図である。 第二の実施形態での情報提供サーバの構成を示すブロック図である。 第二の実施形態での利用者端末の構成を示すブロック図である。 第二の実施形態でのアクセス制御規則群の一例を示す図である。 第二の実施形態でのアクセス要求受信時の動作を示すフローチャートである。

符号の説明

１ ファイルサーバ
２，６ 利用者端末
３ 利用者属性管理装置
４ 通信ネットワーク
５ 情報提供サーバ
７ 属性証明サーバ
８ インターネット
１０，２０，３０，５０，６０ 送受信部
１１ ファイル管理部
１２，５２ 認可判定部
１３，５３ 認証部
１４，５４ アクセス制御規則管理部
１５ 属性取得部
１６，３２，５６ メンテナンス部
２１，６１ 指示部
２２，６２ 記憶部
２３，６３ 表示部
２４，６４ 処理部
２５ 被認証部
３１ 利用者属性格納部
５１ コンテンツ管理部
５５ 属性認証部
６５ 属性管理部
１００，１５０ ロール定義情報
１０１，１５１ ロール名称部
１０２，１５２ ロール帰属条件指示部
１０３，１５３ 単位権限集合指示部
１１０，１６０ ロール帰属条件情報
１１１，１６１ 帰属条件識別部
１１２，１３１，１４１，１６２，１８１，１９１ 属性指定部
１１３，１４２，１６３，１９２ 演算子部
１１４，１４３，１６４，１９３ 比較値部
１１５，１４４，１６５，１９４ 結合子
１６６ 評価対象指定部
１２０、１７０ 単位権限集合定義情報
１２１、１７１ 単位権限集合識別部
１２２、１７２ 権限定義部
１２３、１７３ 制約条件導出規則定義部
１３０、１８０ 総称権限
１３２、１８２ 属性値指定部
１３３、１８３ 操作種別部
１４０、１９０ オブジェクト制約条件導出規則

Claims (6)

1. 保護対象となる情報資源をオブジェクトとし、属性を有し前記オブジェクトにアクセスするものをサブジェクトとして、前記サブジェクトによる前記オブジェクトに対するアクセスの要求を受信した場合に、前記サブジェクトが帰属するロールに基づいて前記アクセス要求の認可判定を行う、前記サブジェクトに対して前記オブジェクトへのアクセスを提供するサーバを有する情報システムにおけるアクセス制御方法であって、
   前記サーバは、アクセスの可否を判定する認可判定部と、前記サブジェクトによる前記オブジェクトへのアクセスの可否を判定する際に判定基準として使用するアクセス制御規則群を保持するアクセス制御規則管理部と、を備え、
   前記アクセス制御規則群は、前記ロールを定義するロール定義情報と、サブジェクトが前記ロールへの所属を許されるために満たすべき条件であって前記サブジェクトの属性をパラメータとする一ないし複数の条件式からなるロール帰属条件を定義するロール帰属条件情報と、前記オブジェクトの属性に関する条件式により規定された前記オブジェクトの集合とアクセスの種類を表わす操作種別との組からなる第一の単位権限集合を定義する単位権限集合定義情報と、を含み、
   前記ロール定義情報は、ロールの名称を格納するフィールドと、前記ロール帰属条件に対する識別子を格納するフィールドと、当該ロールに対する第一の単位権限集合を一ないし複数含む第一の権限集合を示すために前記第一の単位権限集合定義情報に対する一ないす複数の識別子を格納するフィールドとを、有し、前記ロール定義情報によって、前記ロールにおいて、サブジェクトの属性の集合と、オブジェクトと操作の種別の組とが、それぞれ独立に対応付けられ、
   前記認可判定部により、前記サブジェクトが前記アクセス要求に使用するロールを特定するロール特定ステップと、
   前記サーバが、前記サブジェクトの属性を取得する属性取得ステップと、
   前記認可判定部が、前記属性取得ステップにおいて取得された前記サブジェクトの属性に基づいて、前記アクセス制御規則管理部を参照して、前記ロール特定ステップにおいて特定したロールに前記サブジェクトが帰属するか否かを判定するロール帰属判定ステップと、
   前記認可判定部が、前記ロール帰属判定ステップにおいて前記サブジェクトが前記ロールに帰属すると判定された場合に、前記ロールに対応付けて定義された前記第一の権限集合を取得し、前記属性取得ステップにおいて取得した前記サブジェクトの属性に基づいて、前記第一の権限集合から第二の権限集合を抽出し、前記第二の権限集合に前記アクセス要求に対応するアクセス権限が含まれるか否かを判定する権限有無確認ステップと、
   前記認可判定部が、前記権限有無確認ステップでの判定結果に基づいて、前記要求されたアクセスの可否を判定するステップと、
   を有し、
   前記権限有無確認ステップは、
   前記特定されたロールに対応付けて定義された前記第一の権限集合を取得するステップと、
   前記第一の権限集合に含まれる前記第一の単位権限集合それぞれについて、前記第一の単位権限集合に対応付けて定義された、サブジェクトの属性をパラメータとしてオブジェクトの属性に関する条件式であるオブジェクト制約条件を出力するオブジェクト制約条件導出規則を取得するステップと、
   前記属性取得ステップで取得した前記サブジェクトの属性を前記オブジェクト制約条件導出規則に適用して前記オブジェクト制約条件を導出するステップと、
   前記第一の単位権限集合に含まれるオブジェクトのうち前記導出されたオブジェクト制約条件を満たすオブジェクトのみからなる集合と前記第一の単位権限集合の操作種別との組を第二の単位権限集合として、前記各第一の単位権限集合から得られた前記第二の単位権限集合を集約して前記第二の権限集合として抽出するステップと、
   を有する、アクセス制御方法。
2. 前記ロール帰属判定ステップは、
   前記特定されたロールに対応付けて定義された前記ロール帰属条件を取得するステップと、
   前記属性取得ステップで取得した前記サブジェクトの属性を前記ロール帰属条件にそれぞれ適用して前記ロール帰属条件についての前記条件式を満たすか否かを判定し、該判定の結果に基づいて前記ロールへの前記サブジェクトの帰属を判定するステップと、
   を有する、請求項１に記載のアクセス制御方法。
3. 前記属性取得ステップは、属性証明書を用いた属性認証によりサブジェクトの属性を取得するステップを有する、請求項１または２に記載のアクセス制御方法。
4. 前記属性取得ステップにおいて、サブジェクトの有する属性のうち、前記ロール帰属判定ステップにおいてロールへの帰属の判定に必要となるサブジェクトの属性、および／または前記権限有無確認ステップにおいて第二の権限集合の抽出に必要となるサブジェクトの属性のみが取得される、請求項１乃至３のいずれか１項に記載のアクセス制御方法。
5. 前記オブジェクトあるいはサブジェクトの属性は、当該属性の値および／または当該属性の属性の値である、請求項１乃至４のいずれか１項に記載のアクセス制御方法。
6. 前記サブジェクトの属性として、サブジェクトの属性の証明者および／もしくはサブジェクトの属性の確認日時を含む、請求項５に記載のアクセス制御方法。

Images