"クライアントからサーバにアクセスするに際し、複数のノードを備えて構成される分散アクセス制御機構における前記複数のノードのうちのいずれかのノードを介してサーバにアクセスし、前記クライアントから前記サーバに対して操作要求を行う際に、前記操作要求に権限証明書を添えて前記いずれかのノードに送信し、前記権限証明書は、ルート証明書を始端として権限が順次委譲されることによって発行され、ルート証明書から直前の委譲元である権限証明書までの全ての委譲元の権限証明書を特定する特定情報を示す連鎖証明書リストを含み、前記複数のノードの全てのノードは、いずれかのルート証明書が無効化された場合、無効化されたルート証明書を登録し、所定のルート証明書を委譲元として発行された権限証明書以降のいずれかの権限証明書が無効化された場合、前記所定のルート証明書を委譲元として発行された権限証明書以降のいずれの権限証明書であっても、前記所定のルート証明書を委譲元として発行された権限証明書の特定情報に基づいて決定した特定のノードに登録し、前記クライアントから前記操作要求に前記権限証明書を添えて前記いずれかのノードに送信する際に、前記特定のノードにアクセスさせることを特徴とする分散アクセス制御方法。前記複数のノードにはそれぞれ固有のノードIDが設定され、それぞれの権限証明書は前記特定情報として証明書IDを有し、前記所定のルート証明書を委譲元として発行された権限証明書の証明書IDをハッシュ化したハッシュ値に基づいて選択したノードIDを有するノードを前記特定のノードとして選択し、前記所定のルート証明書を委譲元として発行された権限証明書以降の無効化された全ての権限証明書を前記特定のノードに登録することを特徴とする請求項1記載の分散アクセス制御方法。分散アクセス制御機構を介して分散ファイルシステム等の分散システムにアクセスする際には、権限証明書の有効性が検証される。権限証明書がルート証明書を始端として権限が順次委譲されることによって発行された場合、分散アクセス制御機構に送信された権限証明書自体の有効性を検証するだけでなく、その送信された権限証明書の全ての委譲元の権限証明書の有効性を検証することも必要となる。即ち、分散アクセス制御機構が分散システムに対してアクセスする際には、複数の権限証明書の有効性を検証することが必要となる。複数の権限証明書の有効性を検証する際に、それぞれの権限証明書の有効性を検証するたびに通信を行うとすれば、通信コストの点で好ましくない。そこで、通信コストを極力少なくした上で、複数の権限証明書の有効性を検証することができる分散アクセス制御方法が望まれる。本発明はこのような要望に対応するため、複数の権限証明書の有効性を検証する際の通信コストを極力少なくすることができる分散アクセス制御方法を提供することを目的とする。本発明は、上述した従来の技術の課題を解決するため、クライアントからサーバ10にアクセスするに際し、複数のノード1nacを備えて構成される分散アクセス制御機構10acにおける前記複数のノードのうちのいずれかのノードを介してサーバにアクセスし、前記クライアントから前記サーバに対して操作要求を行う際に、前記操作要求に権限証明書Cを添えて前記いずれかのノードに送信し、前記権限証明書は、ルート証明書を始端として権限が順次委譲されることによって発行され、ルート証明書から直前の委譲元である権限証明書までの全ての委譲元の権限証明書を特定する特定情報を示す連鎖証明書リストCCLを含み、前記複数のノードの全てのノードは、いずれかのルート証明書が無効化された場合、無効化されたルート証明書を登録し、所定のルート証明書を委譲元として発行された権限証明書以降のいずれかの権限証明書が無効化された場合、前記所定のルート証明書を委譲元として発行された権限証明書以降のいずれの権限証明書であっても、前記所定のルート証明書を委譲元として発行された権限証明書の特定情報に基づいて決定した特定のノードに登録し、前記クライアントから前記操作要求に前記権限証明書を添えて前記いずれかのノードに送信する際に、前記特定のノードにアクセスさせることを特徴とする分散アクセス制御方法を提供する。上記の分散アクセス制御方法において、前記複数のノードにはそれぞれ固有のノードIDが設定され、それぞれの権限証明書は前記特定情報として証明書IDを有し、前記所定のルート証明書を委譲元として発行された権限証明書の証明書IDをハッシュ化したハッシュ値に基づいて選択したノードIDを有するノードを前記特定のノードとして選択し、前記所定のルート証明書を委譲元として発行された権限証明書以降の無効化された全ての権限証明書を前記特定のノードに登録することが好ましい。本発明の分散アクセス制御方法によれば、複数の権限証明書の有効性を検証する際の通信コストを極力少なくすることができる。以下、本発明の分散アクセス制御方法の一実施形態について、添付図面を参照して説明する。以下詳述する一実施形態は、分散アクセス制御方法を分散システムの一例である分散ファイルシステムで実行させる場合を示している。まず、図2を用いて分散ファイルシステムの概略について説明する。図2において、分散ファイルシステム10は、互いにネットワークで接続された複数のノード1nを備える。それぞれのノード1nはサーバとして機能するコンピュータによって構成される。分散ファイルシステム10の全体も仮想的な1つのサーバとして機能する。ユーザ2が所有するパーソナルコンピュータ等の端末であるクライアント3はインターネット等のネットワークで分散ファイルシステム10と接続される。複数のノード1nのそれぞれは、他の任意のノード1nと直接接続することができるフルメッシュなネットワークとなっていることが好ましい。分散ファイルシステム10に対してリソースを読み出したり書き込んだりする等のアクセスをリクエストと称し、分散ファイルシステム10に対してログインしてからログアウトするまでをセッションと称する。クライアント3が分散ファイルシステム10に対してアクセスすると、リクエスト毎またはセッション毎にロードバランサやDNSラウンドロビン等の仕組みによって、クライアント3からのアクセスは1つのノード1nに割り振られてその1つのノード1nのみと通信する。次に、図1を用いて分散アクセス制御機構の概略について説明する。図1において、分散アクセス制御機構10acは、互いにネットワークで接続された複数のノード1nacによって構成されている。分散アクセス制御機構10acも分散ファイルシステム10と同様、フルメッシュなネットワークとなっていることが好ましい。図1に示す例では、分散アクセス制御機構10acを構成していないノード1nと、分散アクセス制御機構10acを構成しているノード1nacとによって、分散ファイルシステム10が構成されている。ノード1nacは分散アクセス制御機構であるソフトウェアがインストールされたノードであり、ノード1nはそのソフトウェアがインストールされていないノードである。図1は、分散ファイルシステム10を構成するノードが分散アクセス制御機構10acを構成するノード1nacと完全に一致していなくてもよいことを示している。勿論、分散ファイルシステム10を構成するノードを全て、分散アクセス制御機構10acを構成するノード1nacとして、分散ファイルシステム10と分散アクセス制御機構10acとを完全に一致させてもよい。図1は、図2で説明したロードバランサやDNSラウンドロビン等の仕組みによって、クライアント3からのアクセスが1つのノード1nacに割り振られてその1つのノード1nacのみと通信している状態を示している。図1において、ユーザ2aが所有するクライアント3aと、ユーザ2bが所有するクライアント3bと、ユーザ2cが所有するクライアント3cはそれぞれ、分散アクセス制御機構10acを構成する1つのノード1nacと接続されている。ユーザ2a,2b,2cをユーザ2と総称し、クライアント3a,3b,3cをクライアント3と総称することとする。クライアント3とノード1nacとの通信やノード1nacどうしの通信はSSLTLSSecureSocketsLayerTransportLayerSecurity等によって秘匿性が担保されている。クライアント3は、例えばパーソナルコンピュータやPDA携帯情報端末であり、ネットワークに接続する機能を有する任意の端末でよい。端末に搭載されているOSオペレーティングシステムも任意である。ここで、図3を用いて分散アクセス制御機構10acを構成するノード1nacの具体的構成について説明する。図3に示すように、クライアント3はノード1nacを介して分散ファイルシステム10にアクセスする。クライアント3はノード1nacを介することなく分散ファイルシステム10にアクセスすることはできない。ノード1nacは、ソフトウェアによって構成されるアクセス制御部11を有する。勿論、ノード1nacはソフトウェアであるアクセス制御部11を動作させるためのハードウェアを有する。それぞれのノード1nacには、分散アクセス制御機構10acの全体でユニークなノードID12が設定されている。それぞれのノード1nacは、全てのノード1nacのノードID12と接続情報とのマップであるノード経路表13を有する。接続情報とは、例えばURL、または、IPアドレスとポート番号との組である。ノード1nacは、ノード秘密鍵Knprとノード公開鍵Knpbとの鍵ペアを有する。ノード秘密鍵Knprとノード公開鍵Knpbとの鍵ペアはノード1nac毎に異なっている。鍵ペアは更新される場合がある。ノード1nacは、全てのノード1nacの過去から現在までのノード公開鍵Knpbのリストであるノード公開鍵リスト14を有する。また、ノード公開鍵リスト14は、ノードID12毎に、鍵ペアの利用開始日時とノード公開鍵Knpbと漏洩フラグとの3つの組をエントリ情報として有する。それぞれのノード1nacにおいて、ノード秘密鍵Knprの漏洩が疑われる場合に漏洩フラグが立てられる。即ち、漏洩が疑われる場合に、漏洩フラグは漏洩を示す値に設定される。なお、漏洩フラグが漏洩を示す値に設定されことは、必ずしも実際にノード秘密鍵Knprが漏洩したことを示すとは限らない。それぞれのノード1nacでノード秘密鍵Knprの漏洩が疑われる事態が発生した場合に、漏洩フラグは漏洩を示す値に設定される。管理者が手動にて漏洩フラグを立ててもよいし、漏洩が疑われる事態が発生したことを検出してノード1nacが自動的に漏洩フラグを立ててもよい。さらに、それぞれのノード1nacは、証明書失効リスト以下、CRLCertificateRevocationList15と、証明書更新リスト以下、CULCertificateUpdateList16とを有する。後に詳述するように、CRL15及びCUL16は複数のノード1nacに分散されて記憶される。全てのノード1nacが保持するCRL15の全体で証明書失効トータルリストとなり、全てのノード1nacが保持するCUL16の全体で証明書更新トータルリストとなる。表1は、それぞれのノード1nacが保持する情報をまとめて示している。図3に示すように、クライアント3が分散ファイルシステム10のリソースに対してアクセスする際には、操作要求に権限証明書Cを添えてノード1nacに送信する。後述するように、権限証明書Cはノード1nacが発行する。権限証明書Cは、大略的には図4に示すケイパビリティCapabilityにデジタル署名を付加したものである。ケイパビリティとはユーザ単位のアクセス制御情報である。図4に示すユーザA,B,Cはユーザ2の例である。図4に示すように、ユーザBは、リソースXに対しては読み出しと書き込みのいずれも許可されておらず、リソースYに対しては読み出しが許可されており、リソースZに対しては読み出しと書き込みのいずれも許可されている。このように、それぞれのユーザに対してどのようなアクセスを許可/不許可とするかを示す情報がケイパビリティである。なお、それぞれのリソース単位でどのユーザにどのようなアクセスを許可/不許可とするかを対応させた情報をACLAccessControlListと称している。ACLを用いたACL方式は、集中管理型のアクセス制御機構で利用されている。本実施形態は、ACL方式ではなく、権限証明書Cを用いた分散管理型のアクセス制御機構である。ノード1nacは、操作要求に添えられた権限証明書Cが有効であり、要求された操作が権限証明書Cにおいて許可されており、クライアント3ユーザ2が権限証明書Cの所有者であることが認証された場合に、分散ファイルシステム10に対して操作要求を仲介する。権限証明書Cが有効であるか否かは、複数のノード1nacに分散されて記憶されたCRL15及びCUL16を参照する。これについては後述する。クライアント3ユーザ2の認証は、操作要求のたびに毎回行う必要はなく、認証結果をキャッシュしておいてセッション単位で認証してもよい。表2は、権限証明書Cに含まれている情報を示している。権限証明書Cに含まれる証明書IDは後述する権限証明書Cの更新を行っても不変である。証明書IDは権限証明書Cを特定する特定情報である。対象リソースは、図4で説明したリソースX,Y,Z等であり、許可する操作は図4で説明した読み出しや書き込み、データの複写,印刷,削除等である。本実施形態では、ユーザ2は、所有する権限証明書Cに基づいてそのサブセット権限を有する新たな権限証明書Cを発行することができる。対象リソースと許可する操作と有効期間は、権限の範囲を示す権限情報である。連鎖証明書リストは、権限証明書Cがどのように連鎖しているかを示す。連鎖証明書リストが空であればルート証明書ということになる。ルート証明書は少なくとも1つ存在しているものとする。なお、ルート証明書を分散アクセス制御機構10acの管理者が保有していてもよいし、管理者が特定のユーザ2に発行してもよい。ルート証明書がどのように存在しているかは限定されない。なお、認証方式をパスワード認証に限定する場合には、表2に示す認証方式を示す情報は不要である。権限証明書Cの発行日時は、権限証明書Cが更新されていない場合には権限証明書Cを最初に発行した発行日時であり、後述のように権限証明書Cが更新された場合には更新日時となる。更新日時とは権限証明書Cの内容を更新した新たな権限証明書Cを発行した発行日時であり、発行日時とは更新日時を含むものとする。発行者ノードIDは権限証明書Cを発行したノード1nacに設定されているノードIDであり、署名は権限証明書Cを発行したノード1nacが有するノード秘密鍵Knprを用いたデジタル署名である。図5を用いて、権限証明書Cの権限委譲の例について説明する。ユーザ2としてAliceが所有する権限証明書Cを権限証明書CAとする。図5では、表2に示す権限証明書Cに含まれる情報の一部のみを示している。図5におけるCCLは連鎖証明書リストである。Aliceが所有する権限証明書CAの証明書IDはA0001であり、連鎖証明書リストCCLが空である。即ち、権限証明書CAはルート証明書である。Aliceが他のユーザ2としてBobに権限を委譲したとする。委譲先ここではBobの権限は委譲元ここではAliceの権限を越えない範囲である。Bobが所有する権限証明書Cを権限証明書CBとする。Bobが所有する権限証明書CBの証明書IDはB0001であり、権限証明書CBの連鎖証明書リストCCLには権限の委譲元の証明書IDであるA0001が記載されている。さらに、Bobが他のユーザ2としてCarolに権限を委譲したとする。同様に、委譲先ここではCarolの権限は委譲元ここではBobの権限を越えない範囲である。Carolが所有する権限証明書Cを権限証明書CCとする。権限証明書CCの連鎖証明書リストCCLには権限の委譲元全ての証明書IDであるA0001,B0001が記載されている。このように、連鎖証明書リストCCLは、ルート証明書を始端として権限が順に委譲され場合のルート証明書から直前の証明書までの全ての委譲元の証明書IDのリストを示している。権限証明書Cに含まれている連鎖証明書リストCCLに記載されている証明書IDによって、どのような権限証明書Cの経路で権限が委譲されたかが分かる。ここで、図6を用いてノード1nacによる権限証明書Cの発行手順SAについて説明する。図6に示す権限証明書Cの発行手順SAは、一実施形態の分散アクセス制御方法の一部である権限証明書Cの発行方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である権限証明書Cの発行ステップである。ユーザ2がクライアント3の端末を操作して、委譲元の権限証明書Cユーザ2が所有する権限証明書Cと、新たに発行する権限証明書Cの権限情報と、初期パスワードpiを入力して、ノード1nacに対して新たな権限証明書Cの発行を指示したとする。委譲元の権限証明書CをCPとする。ノード1nacのアクセス制御部11は、ステップSA1にて、クライアント3から、委譲元の権限証明書CPと、新たに発行する権限証明書Cの権限情報と、初期パスワードpiを受け取る。図5におけるBobがCarolに権限を委譲する場合を例にすると、アクセス制御部11は、Bobが所有する権限証明書CBと新たに発行してCarolに与えようとする権限証明書CCの権限情報と初期パスワードpiを受け取る。初期パスワードpiはBobが予め定められたパスワードの付与ルールに従って適宜に設定すればよい。以下、理解を容易にするためにBobがCarolに権限を委譲する場合の説明を適宜補足することとする。アクセス制御部11は、ステップSA2にて、委譲元の権限証明書CP権限証明書CBを検証する。ステップSA2の権限証明書CPの検証手順SFの具体的手順については後述する。アクセス制御部11は、ステップSA3にて、ユーザ2クライアント3が委譲元の権限証明書CP権限証明書CBの所有者であることを認証する。ステップSA3のユーザ2が委譲元の権限証明書CPの所有者であることの認証手順SBの具体的手順については後述する。認証が成立した場合には、アクセス制御部11は処理をステップSA4に移行させる。アクセス制御部11は、ステップSA4にて、委譲元の権限証明書CP権限証明書CBと比較して新たに発行する権限証明書C権限証明書CCの権限情報に権限の拡大や期限の延長等の不正がなく正当であるか否かを確認する。正当でなければNO、アクセス制御部11は、ステップSA10にて、新しい権限証明書C権限証明書CCの発行を不許可として終了する。この際、特に図示していないが、アクセス制御部11は、新しい権限証明書Cの発行を不許可となったこと及びその理由をユーザ2Bobに通知する。ステップSA4にて正当であればYES、アクセス制御部11は、ステップSA5にて、新たに発行する権限証明書C権限証明書CCの証明書IDを生成して設定する。アクセス制御部11は、ステップSA6にて、初期パスワードpiを用いて公開認証情報Ioauthを生成して設定する。公開認証情報Ioauthは次の式1によって求める。式1において、r1,r2は乱数、passwordは初期パスワードpiの平文である。また、a∥bはaとbとを連結ビット結合することを意味し、HはメッセージMに対して一方向ハッシュ関数を適用することを意味し、EKnpbはメッセージMをノード公開鍵Knpbを用いて暗号化することを意味する。Ioauthr1∥r2∥EKnpb...1式1において、乱数r1,r2は公開認証情報Ioauthをより不規則とするために用いており、乱数r1,r2は擬似乱数であってもよい。公開認証情報Ioauthは、パスワードを一方向性ハッシュ関数を用いて一方向化し、ノード1nacが備えるノード公開鍵Knpbを用いて暗号化した値である。アクセス制御部11は、ステップSA7にて、新たに発行する権限証明書C権限証明書CCの連鎖証明書リストCCLとして、委譲元の権限証明書CP権限証明書CBの連鎖証明書リストCCLに委譲元の権限証明書CP権限証明書CBの証明書IDを加えたリストを設定する。図5で説明したように、権限証明書CBの連鎖証明書リストCCLには証明書IDとしてA0001が記載されており、この連鎖証明書リストCCLに権限証明書CBの証明書IDであるB0001を加えることによって、権限証明書CCの連鎖証明書リストCCLとなる。アクセス制御部11は、ステップSA8にて、新たに発行する権限証明書C権限証明書CCの発行日時に現在時刻を設定し、発行者ノードIDに新たな権限証明書Cを発行しようとしているノード1nac自身のノードIDを設定する。ここでの現在時刻とは、年月日及び秒までの現在時刻である。そして、アクセス制御部11は、ステップSA9にて、新たな権限証明書Cを発行しようとしているノード1nac自身のノード秘密鍵Knprを用いてデジタル署名し、新しい権限証明書C権限証明書CCを発行して終了する。以上のようにして、新たに発行する権限証明書Cとして、証明書ID,新たな権限情報,公開認証情報,連鎖証明書リスト,発行日時,発行者ノードID,デジタル署名が設定された新しい権限証明書Cが発行される。新しい権限証明書Cを委譲先のユーザ2クライアント3に渡す方法は任意である。例えば、BobがCarolに権限を委譲する場合、新たに発行した権限証明書CCをCarolに直接送付してもよいし、Bobに送付してBobがCarolに転送してもよい。また、ノード1nacが新たに発行した権限証明書CCを保持しておき、Carolが分散アクセス制御機構10acにログインした時点でCarolに転送するようにしてもよい。以上の説明より分かるように、本実施形態によれば、ユーザ2は自身が保有する権限の範囲内で、他のユーザ2に対して分散ファイルシステム10へのアクセスの権限を自由に設定することができる。分散アクセス制御機構10acの管理者等の特定の者が権限証明書Cを発行し、権限証明書Cの管理を行う必要がないので、権限証明書Cの発行管理のコストを分散させることが可能となる。図7を用いて、図6におけるステップSA3のユーザ2が委譲元の権限証明書Cここでは権限証明書CPの所有者であることの認証手順SBの具体的手順について説明する。図7に示す認証手順SBは、一実施形態の分散アクセス制御方法の一部である認証方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である認証ステップである。図7において、アクセス制御部11は、ステップSB1にて、権限証明書C権限証明書CPとパスワードpを受け取る。パスワードpは権限証明書CPを発行した際に設定したパスワードである。パスワードを変更していなければ、パスワードpは初期パスワードpiである。アクセス制御部11は、ステップSB2にて、権限証明書Cから公開認証情報Ioauthを取得する。アクセス制御部11は、ステップSB3にて、ノード公開鍵リストから権限証明書C権限証明書CPの発行時に用いられたノード公開鍵Knpbを取得する。ステップSB3のノード公開鍵Knpbの取得手順SEの具体的手順については後述する。アクセス制御部11は、ステップSB4にて、次の式2が成立するか否かを判定する。式2において、cは公開認証情報Ioauthを乱数r1,r2と値cとに分割したときの値cである。逆に言えば、cは乱数r1,r2と値cとを連結して公開認証情報Ioauthとなるような値である。cEKnpb...2式2が成立すればYES、アクセス制御部11は、ステップSB5にて、パスワード認証は成立したと決定して終了する。式2が成立しなければNO、アクセス制御部11は、ステップSB6にて、パスワード認証は不成立であると決定して終了する。式2が成立するということは、ユーザ2によって入力されたパスワードpを一方向性ハッシュ関数を用いて一方向化し、権限証明書C権限証明書CPの発行時に用いられたノード公開鍵Knpbを用いて暗号化した値が、公開認証情報Ioauthと一致するということである。このように、パスワードpを一方向性ハッシュ関数を用いて一方向化し、ノード公開鍵リストから取得した権限証明書Cの発行時に用いられたノード公開鍵Knpbを用いて暗号化した値と、権限証明書Cから取得した公開認証情報とを比較することによって、クライアント3ユーザ2が権限証明書Cの所有者であることを認証することができる。本実施形態では、ユーザ2クライアント3から送信された権限証明書Cとパスワードpのみを用いてパスワード認証を実現することが可能である。ところで、公開認証情報Ioauthは、条件1:分散アクセス制御機構10acノード1nacが公開認証情報Ioauthのみを用いて権限証明書Cの認証を行うことができる、条件2:公開認証情報Ioauthが漏洩した場合でも権限証明書Cの認証の安全性が担保できるの2つの条件を満たす情報である。条件2を満たすことにより権限証明書Cに公開認証情報Ioauthを含めることが可能となる。条件1を満たすことにより、分散アクセス制御機構10acは認証情報を保持する必要がない。上記の式1によれば公開認証情報Ioauthは一方向ハッシュ関数によって一方向化されているため、逆向きにパスワードを求めることは極めて困難である。従って、仮に攻撃者が他人の権限証明書Cを入手したとしても、図7の認証手順SBでパスワード認証が成功する可能性は極めて低い。さらには、攻撃者は、通常、ノード秘密鍵Knprとノード公開鍵Knpbとの鍵ペアを知り得ないため、公開認証情報Ioauthを計算することも極めて困難である。なお、パスワード認証の代わりに従来一般的に行われている公開鍵認証を採用する場合には、図7に示すパスワード認証の認証手順SBの代わりに一般的な公開鍵認証の認証手順を用いることが可能である。本実施形態によれば、図6で説明した権限証明書Cの発行方法を採用することによって、パスワード認証が可能な権限証明書Cとすることができる。本実施形態によれば、図7で説明した認証方法を採用することによって、ユーザ2が権限証明書Cの所有者であることを認証することができる。以上によって、パスワード認証を実現している。次に、認証情報の更新について説明する。本実施形態によれば、管理者等の第三者によらず、いわゆる自立的に認証情報を更新することが可能である。非特許文献1に記載のような従来の分散アクセス制御機構においては、権限証明書Cの署名に権限証明書Cの最初の許諾者図5の例ではルート証明書を所有するAliceの秘密鍵を必要とする。従って、最初の許諾者からの委譲先以降である権限証明書Cの所有者図5の例ではBob,Carolは自立的に認証情報を更新することはできない。本実施形態では、図8に示す認証情報の更新手順SCによって自立的な認証情報の更新を実現している。図8を用いて、権限証明書Cの認証情報を更新する際の更新手順SCについて説明する。図8に示す権限証明書Cの更新手順SCは、一実施形態の分散アクセス制御方法の一部である更新方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である更新ステップである。ユーザ2がクライアント3の端末を操作して、更新しようとする権限証明書Cと新しい認証情報パスワードpを入力して、ノード1nacに対して権限証明書Cの更新を指示したとする。図8において、アクセス制御部11は、ステップSC1にて、更新する権限証明書Cと新しいパスワードpを受け取る。アクセス制御部11は、ステップSC2にて、権限証明書Cを検証する。ステップSC2の権限証明書Cの検証手順SFの具体的手順については後述する。アクセス制御部11は、ステップSC3にて、ユーザ2が権限証明書Cの所有者であることを認証する。ステップSC3のユーザ2が権限証明書Cの所有者であることの認証手順SBの具体的手順は図7で説明した通りである。但し、ステップSC3では、ユーザ2は認証手順SBにおいて更新しようとしている権限証明書Cの発行時に設定したパスワードpを入力して、ノード1nacが図7のように認証する。アクセス制御部11は、ステップSC4にて、権限証明書Cの内容を複写して新しい権限証明書C’を作成する。アクセス制御部11は、ステップSC5にて、新しいパスワードpから公開認証情報Ioauthを生成して、新しい権限証明書C’に設定する。アクセス制御部11は、ステップSC6にて、新しい権限証明書C’の発行日時に現在時刻を設定し、ステップSC7にて権限証明書Cを更新しようとしているノード1nac自身のノード秘密鍵Knprを用いてデジタル署名し、新しい権限証明書C’を発行する。そして、アクセス制御部11は、ステップSC8にて、新しい権限証明書C’をユーザ2に返送し、併せて、新しい権限証明書C’を複数のノード1nacのCUL16に登録する。前述のように、権限証明書Cの内容を更新しても証明書IDが不変である。従って、公開認証情報Ioauthを更新した新たな権限証明書C’は更新前の権限証明書Cの証明書IDを維持している。CUL16は、更新前の権限証明書Cの証明書IDを有する公開認証情報Ioauthを更新した新たな権限証明書C’を格納する。CUL16については図10を用いて後に詳述する。また、ステップSC8にて、新しい権限証明書C’をどの複数のノード1nacに記憶させるかについても後述する。このように、本実施形態では、分散アクセス制御機構10acノード1nacがノード秘密鍵Knprを用いて署名するので、権限証明書Cを更新しようとする権限証明書Cの所有者は、最初の許諾者によらず自由に認証情報を更新することが可能となる。非特許文献1に記載の従来の分散アクセス制御機構のようにユーザ2が自由に権限証明書Cを作成して発行できる場合には、権限証明書Cを検証する際に権限の範囲の拡大や期限の延長がないかを確認しなければならない。本実施形態では、分散アクセス制御機構10acノード1nacが権限証明書Cを発行するので、発行の際に権限の範囲の拡大や期限の延長がないかを確認することができる。よって、検証のコストを低減させることが可能となる。次に、図9,図10を用いてCRL15,CUL16について説明する。非特許文献1に記載の従来の分散アクセス制御機構では、権限証明書Cを更新する手段は明示的に提供されていない。従って、前述のように、権限証明書Cを更新しようとすれば、発行済みの権限証明書Cを無効化し、新たに権限証明書Cを再発行することになる。しかしながら、一旦権限証明書を無効化すると、大きな副作用を起こしてしまう。そこで、本実施形態では、CUL16を用いることによって副作用のない権限変更を実現している。図9Aに示すように、権限証明書CAに基づいて権限証明書CBが発行され、権限証明書CBに基づいて権限証明書CCが発行され、権限証明書CCに基づいて権限証明書CDが発行されている。権限証明書CA~CDにそれぞれの証明書IDを記載している。権限証明書CBを無効化すると、図9Bに示すように、権限証明書CBを無効化することによってCRL15には権限証明書CBが登録される。図9A及び図10Aにおいて、×は無効となっていることを示す。ある権限証明書Cにおいて、図5で説明した連鎖証明書リストCCLに記載されている証明書IDのいずれか1つでもCRL15に登録されていれば、その権限証明書Cは無効となる。従って、図9Aに示すように、権限証明書CBに基づいて発行された権限証明書CCと、権限証明書CCに基づいて発行された権限証明書CDも無効となる。これに対して、CUL16は権限証明書Cがどのように更新されたかを示す情報を登録している。図10Aは、権限証明書CBが権限証明書CB’に更新された状態を示している。権限証明書CBが権限証明書CB’に更新されても証明書IDは不変である。図10Bに示すように、CUL16に権限証明書CBが権限証明書CB’に更新されたことが登録されている。ここでは概念的に示しており、CUL16には、更新前の権限証明書Cの証明書IDと更新後の権限証明書C’の内容とを対応させた情報が登録される。証明書IDが不変であるので、CUL16には、更新後の権限証明書C’が登録されるということである。図10Aの例では、図10Bに示すCUL16には、更新前の権限証明書CBの証明書IDであるB0001を有する更新後の権限証明書CB’が登録される。図11を用いて権限証明書Cの権限情報を更新する際の更新手順SDについて説明する。図11に示す権限証明書Cの更新手順SDは、一実施形態の分散アクセス制御方法の一部である更新方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である更新ステップである。ユーザ2がクライアント3の端末を操作して、更新しようとする権限証明書Cと、更新しようとする権限証明書Cに新しく設定する権限情報と、更新者であるユーザ2が所有する権限証明書Cを入力して、権限証明書Cの権限変更を指示したとする。更新者が所有する権限証明書CをCUとする。アクセス制御部11は、ステップSD1にて、更新する権限証明書Cと、新しく設定する権限情報と、更新者が所有する権限証明書CUを受け取る。図5におけるBobが更新者であり、Carolが所有する権限証明書CCを更新する場合を例にすると、アクセス制御部11は、更新しようとするCarolの権限証明書CCと、新しく設定する権限情報と、Bobが所有する権限証明書CBを受け取る。以下、理解を容易にするためにBobがCarolの権限証明書CCを更新する場合の説明を適宜補足することとする。アクセス制御部11は、ステップSD2にて、更新する権限証明書C権限証明書CC及び更新者の権限証明書CU権限証明書CBを検証する。ステップSD2の権限証明書Cの検証手順SFの具体的手順については後述する。アクセス制御部11は、ステップSD3にて、更新者が所有する権限証明書CU権限証明書CBが、更新する権限証明書C権限証明書CCの連鎖証明書リストCCLの中に存在するか否かを確認する。更新者が所有する権限証明書CUが、更新する権限証明書Cの連鎖証明書リストCCLの中に存在するということは、更新者が所有する権限証明書CUが更新する権限証明書Cの委譲元であるということである。更新者が所有する権限証明書CUが、更新する権限証明書Cの連鎖証明書リストCCLの中に存在しなければNO、アクセス制御部11は、ステップSD11にて、権限証明書C権限証明書CCの更新を不許可として終了する。更新者が所有する権限証明書CUが、更新する権限証明書Cの連鎖証明書リストCCLの中に存在すればYES、アクセス制御部11は、処理をステップSD4に移行させる。アクセス制御部11は、ステップSD4にて、更新者が所有する権限証明書CUと比較して、新しく設定する権限情報に権限の拡大や期限の延長等の不正がなく正当であるか否かを確認する。正当でなければNO、アクセス制御部11は、ステップSD11にて、権限証明書C権限証明書CCの更新を不許可として終了する。正当であればYES、アクセス制御部11は、処理をステップSD5に移行させる。アクセス制御部11は、ステップSD5にて、更新者が権限証明書CU権限証明書CBの所有者であることを認証する。ステップSD5の更新者が権限証明書CUの所有者であることの認証手順SBの具体的手順は図7で説明した通りである。但し、ステップSD5では、ユーザ2は更新者が所有する権限証明書CUの発行時に設定したパスワードpを入力して、ノード1nacが図7のように認証する。アクセス制御部11は、ステップSD6にて、更新する権限証明書C権限証明書CCの内容を複写して新しい権限証明書C’を作成する。アクセス制御部11は、ステップSD7にて、新しい権限情報を新しい権限証明書C’に設定する。アクセス制御部11は、ステップSD8にて、新しい権限証明書C’の発行日時に現在時刻を設定する。アクセス制御部11は、ステップSD9にて、権限証明書Cを更新しようとしているノード1nac自身のノード秘密鍵Knprを用いてデジタル署名し、新しい権限証明書C’を発行する。そして、アクセス制御部11は、ステップSD10にて、更新する権限証明書C権限証明書CCの証明書IDを有する新しい権限証明書C’を複数のノード1nacのCUL16に格納して終了する。ステップSD10にて、新しい権限証明書C’をどの複数のノード1nacに記憶させるかについては後述する。なお、同じ証明書IDに対してCUL16に権限証明書C’が登録されている場合には、発行日時の新しい方の権限証明書C’で上書きする。ここで、図12を用いて、図7の認証手順SBにおけるステップSB3のノード公開鍵Knpbの取得手順SEの具体的手順について説明する。図12に示すノード公開鍵Knpbの取得手順SEは、一実施形態の分散アクセス制御方法の一部であるノード公開鍵Knpbの取得方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部であるノード公開鍵Knpbの取得ステップである。図12において、アクセス制御部11は、ステップSE1にて、権限証明書Cから発行日時と発行者ノードIDを取得する。アクセス制御部11は、ステップSE2にて、ノード公開鍵リストから発行者ノードIDに対応する鍵ペアの利用開始日時とノード公開鍵Knpbと漏洩フラグとの3つの組であるエントリ情報を検索する。アクセス制御部11は、ステップSE3にて、該当するエントリ情報のうち、鍵ペアの利用開始日時よりも権限証明書Cの発行日時が新しく、利用開始日時が最も新しいエントリ情報を取得する。そして、アクセス制御部11は、ステップSE4にて、取得したエントリ情報からノード公開鍵Knpbと漏洩フラグとを取得する。前述のように、ノード公開鍵リストには、過去から現在までの全てのノード1nacのノード公開鍵Knpbが格納されている。図12に示す取得手順SEによって、権限証明書Cの発行や更新を担当していないノード1nacであっても、権限証明書Cの検証手順SF及び認証手順SBで必要となるノード公開鍵Knpbを取得することができる。次に、図13を用いて、図6の権限証明書Cの発行手順SA、図8の認証情報の更新手順SC、図11の権限証明書Cの更新手順SDのそれぞれで行われる権限証明書Cの検証手順SFの具体的手順について説明する。図13に示す権限証明書Cの検証手順SFは、一実施形態の分散アクセス制御方法の一部である権限証明書Cの検証方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である権限証明書Cの検証ステップである。図13において、アクセス制御部11は、ステップSF1にて、現在時刻が権限証明書Cの有効期限の範囲内であるか否かを確認する。有効期限の範囲内でなければNO、アクセス制御部11は、ステップSF9にて、権限証明書Cを無効と決定して終了する。有効期限の範囲内であればYES、アクセス制御部11は、ステップSF2にて、権限証明書Cとその連鎖証明書リストに含まれる全ての権限証明書Cがいずれも無効でないことを確認する。ステップSF2の確認手順SHの具体的手順については後述する。アクセス制御部11は、ステップSF3にて、ノード公開鍵リストから権限証明書Cの発行時に用いられたノード公開鍵Knpbと漏洩フラグとを取得する。ステップSF3のノード公開鍵Knpbと漏洩フラグの取得手順SEは図12で説明した通りである。アクセス制御部11は、ステップSF4にて、漏洩フラグが漏洩を示す値であるか否かを判定する。前述のように、漏洩フラグが漏洩を示す値であれば、ノード秘密鍵Knprの漏洩が疑われる事態が発生したということである。漏洩フラグが漏洩を示す値であればYES、アクセス制御部11は、ステップSF9にて権限証明書Cを無効と決定して終了する。漏洩フラグが漏洩を示す値でなければNO、アクセス制御部11は、ステップSF5にて、ノード公開鍵Knpbを用いて権限証明書Cの署名を検証する。特に図示していないが、署名の検証を失敗した場合には権限証明書Cを無効と決定して終了する。アクセス制御部11は、ステップSF6にて、権限証明書Cが更新されているか否かを判定する。権限証明書Cが更新されているか否かは、更新されているか否かを確認しようとしている権限証明書Cの証明書IDと同じ証明書IDの権限証明書CがCUL16に登録されているか否かで判定することができる。権限証明書Cが更新されていなければNO、アクセス制御部11は、ステップSF7にて、権限証明書Cを有効と決定して終了する。権限証明書Cが更新されていればYES、アクセス制御部11は、ステップSF8にて、CUL16に登録されている権限証明書C即ち、最新の権限証明書C’に更新して終了する。権限証明書Cは、ユーザ2からの操作要求の可否を判断する場合の他、権限証明書Cの発行や更新等の権限証明書Cが利用される操作の際に必ず検証される。このため、遅くとも図13の検証手順SFによる検証時には、全ての権限証明書CがステップSF2で無効化されているか否かとステップSF6で更新されているか否かが検出されることが保証される。例えば、図5において、Aliceがパスワードを変更するのに伴って権限証明書CAが権限証明書CA’へと更新されたとする。攻撃者がAliceの古い権限証明書CAとそのパスワードを不正に入手して分散アクセス制御機構10acにアクセスを試みた場合を考える。この場合、CUL16にはAliceの古い権限証明書CAの証明書IDを有する新しい権限証明書CA’が登録されているため、権限証明書CAは最新の権限証明書CA’に置換される。従って、図7の認証手順SBによる認証は失敗することになる。他の例として、図5に示すように、BobがCarolに対してリソースとしてbobfoodocの読み出しのみを許可しており、後にそのリソースに対して書き込みも許可する必要が発生した場合を考える。Bobの権限証明書CBは書き込みの権限を含んでいるため、上述した権限証明書Cの更新手順SDによって、Bobは書き込みの権限を加えた新しい権限証明書C’をCarolの新しい権限証明書CC’としてCUL16に登録することができる。CarolはBobによる権限証明書CCの更新を意識する必要はなく、Carolが有していた更新前の古い権限証明書CCを使って書き込み処理を実行すれば、古い権限証明書CCが最新の権限証明書CC’に置換されて書き込み処理が許可されることになる。本実施形態においては、分散ファイルシステム10に対してアクセスする際に分散アクセス制御機構10acがアクセス制御するのに必要な情報は権限証明書Cに含まれている。個々のノード1nacは、ノード経路表13,ノード公開鍵リスト14,CRL15,CUL16を除いて、アクセス制御するのに必要な情報を保持する必要がなく、個々のノード1nacは独立してアクセス制御を実行することができる。従って、本実施形態では、アクセス制御を実行するノード1nacを増やすことによって、容易に単一障害点を排除して性能をスケールアウトすること可能となる。ノード経路表13はノード1nac間での通信で必要となり、ノード公開鍵リスト14は権限証明書Cの検証やパスワード認証等の際に必要となる。従って、ノード経路表13及びノード公開鍵リスト14は、分散アクセス制御機構10acを構成する全てのノード1nacで必要な情報である。ノード1nacの追加離脱や鍵ペアの更新の頻度は、権限証明書Cの無効化や更新の頻度と比較して十分に少ない。ノード経路表13やノード公開鍵リスト14のデータ容量はさほど大きくない。そこで、全てのノード1nacは、ノード経路表13及びノード公開鍵リスト14を共通して保持する。どのノード1nacも、ノード経路表13及びノード公開鍵リスト14として同じ情報を保持する。CRL15及びCUL16はユーザ2クライアント3から送信された権限証明書Cが無効でないか等を確認するために全てのノード1nacで参照できることが必要である。特定のノード1nacにCRL15またはCUL16を保持させると、その特定のノード1nacが単一障害点となり、同時にボトルネックとなって性能のスケールアウトを妨げることになる。そこで、本実施形態では、CRL15及びCUL16を分散させ、さらに冗長化させて複数のノード1nacに保持させる。前述のように、それぞれのノード1nacが保持しているCRL15,CUL16を分散アクセス制御機構10acの全てのノード1nacでまとめると、証明書失効トータルリスト,証明書更新トータルリストとなる。即ち、証明書失効トータルリスト,証明書更新トータルリストは、複数のCRL15,CUL16に分割された形で全てのノード1nacにまたがるようにして保持されていることになる。本実施形態では、コンシステントハッシュ法ConsistentHashingを用いて、CRL15及びCUL16を分散させる。図14を用いて、コンシステントハッシュ法を用いたCRL15及びCUL16の分散の仕方について説明する。図14に示すように、それぞれのノード1nacのノードIDが0,150,300,450,600,750であったとする。図14に示す複数のノード1nacは図2で説明したようにフルメッシュなネットワークとなっており、ノード経路表13を参照することによって直接目的とする他のノード1nacと通信が可能であるとする。無効化しようとする権限証明書Cの内容からハッシュ関数によってハッシュ値を求める。ハッシュ値は400であったとする。ここでのハッシュ関数は一方向性を満たさなくてもよく、一様性が満たされていればよい。図14に示す環状のハッシュ空間に配置されたノード1nacで、ハッシュ値400に順方向で最も近いノード1nacはノードIDが450のノード1nacである。そこで、無効化する権限証明書CをノードIDが450のノード1nacに保存し、その近傍のノード1nacに無効化する権限証明書Cの複製を保存する。冗長数をrとすると、r-1台のノード1nacに無効化する権限証明書Cの複製を保存する。図14は冗長数rが3の場合を示しており、近傍のノード1nacはノードIDが600と750のノード1nacとなる。コンシステントハッシュ法を用いてCRL15及びCUL16を分散させる場合、権限証明書Cのハッシュ値がどのような範囲に分布するかによって、それぞれのノード1nacに付与するノードIDの値を設定すればよい。図15を用いて、権限証明書Cの無効化手順SGCRL15への登録手順について説明する。図15に示す権限証明書Cの無効化手順SGは、一実施形態の分散アクセス制御方法の一部である権限証明書Cの無効化方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である権限証明書Cの無効化ステップである。ユーザ2がクライアント3の端末を操作して、無効化しようとする権限証明書Cと、ユーザ2が所有する権限証明書Cを入力したとする。無効化の手続きをするユーザ2が所有する権限証明書CをCUとする。図15において、ノード1nacのアクセス制御部11は、ステップSG1にて、無効化する権限証明書Cと所有する権限証明書CUを受け取る。権限証明書C,CUを受け取ったノード1nacを処理ノードと称することとする。図14では、処理ノードの図示を省略している。処理ノードのアクセス制御部11は、ステップSG2にて、無効化する権限証明書Cと所有する権限証明書CUを検証する。検証手順SFの具体的手順は図13で説明した通りである。処理ノードのアクセス制御部11は、ステップSG3にて、所有する権限証明書CUが無効化する権限証明書Cと同じか、連鎖証明書リストCCLの中に存在するか否かを確認する。権限証明書CUが権限証明書Cと同じではなく、連鎖証明書リストCCLの中に存在しなければNO、ユーザ2は無効化しようとした権限証明書Cを無効化する権限がないため、ステップSG10にて無効化不成立として終了する。権限証明書CUが権限証明書Cと同じであるか、連鎖証明書リストCCLの中に存在すればYES、処理ノードのアクセス制御部11は、ステップSG4にて、無効化の手続きをしているユーザ2が権限証明書CUの所有者であることを認証する。認証手順SBの具体的手順は図7で説明した通りである。処理ノードのアクセス制御部11は、ステップSG5にて、権限証明書Cのハッシュ値を求め、ステップSG6にて、ハッシュ値に基づいて最も近傍のノード1nacに権限証明書Cを転送する。図14の例では、ノードIDが450のノード1nacが転送先のノードとなる。この転送先のノードを担当ノードと称することとする。担当ノードのアクセス制御部11は、ステップSG7にて、権限証明書Cを自身のCRL15と複製保存用のr-1台のノード1nacのCRL15に登録する。担当ノードのアクセス制御部11は、ステップSG8にて、無効化完了を転送元の処理ノードに通知する。処理ノードのアクセス制御部11は、ステップSG9にて、無効化完了を無効化の手続きを行ったユーザ2に通知する。図15において、ステップSG7で、担当ノードはr-1回の通信を行って近傍のノード1nacのCRL15に権限証明書Cの複製を保存させているため、処理ノードがステップSG9でユーザ2に無効化完了を通知した時点では、r台のノード1nacがCRL15の構成情報権限証明書Cを保持することが保証されている。これによって、同時にr-1台のノード1nacが故障したとしても、CRL15のデータは損失することがない。図16を用いて、検証手順SFのステップSF2である権限証明書Cの無効化の確認手順SHの具体的手順について説明する。図16に示す確認手順SHは、一実施形態の分散アクセス制御方法の一部である権限証明書Cの無効化の確認方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である権限証明書Cの無効化の確認ステップである。ここでも、権限証明書Cの無効化を確認するノード1nacを処理ノードと称することとする。図16において、処理ノードのアクセス制御部11は、ステップSH1にて権限証明書Cのハッシュ値を求める。権限証明書Cのハッシュ値の求め方については後述する。処理ノードのアクセス制御部11は、ステップSH2にて、権限証明書Cのハッシュ値から、複製を含めて対応するCRL15を保持しているノード1nacを求める。CRL15を保持しているノード1nacを保持ノードと称することとする。処理ノードのアクセス制御部11は、ステップSH3にて、保持ノードのうち、接続可能な任意の1台に対して権限証明書Cの証明書IDを送る。保持ノードのアクセス制御部11は、ステップSH4にて、送られてきた証明書IDに一致する権限証明書CがCRL15に登録されているか否かを確認して、確認結果を処理ノードに送る。登録されていればYES、処理ノードのアクセス制御部11は、無効化されていることを処理ノードに通知して終了する。登録されていなければNO、処理ノードのアクセス制御部11は、無効化されていないことを処理ノードに通知して終了する。以上の権限証明書Cの無効化手順SG及び無効化確認手順SHによって、どのノード1nacからであっても任意の権限証明書Cを無効化することができ、無効化されているか否かを確認することができる。権限証明書Cの検証時には、検証の対象である権限証明書Cに加えて、連鎖証明書リストCCLに含まれている証明書IDの権限証明書Cが無効化されているか否かを確認する。従って、図16の確認手順SHは、連鎖する権限証明書Cの数だけ繰り返されることとなる。このとき、同じノード1nacに対してCRL15を参照して複数の権限証明書Cの無効化を確認する際には、複数の権限証明書Cをまとめて確認することにより、通信回数を少なくすることが好ましい。図16のステップSH3では、保持ノードのうち、接続可能な任意の1台に対して権限証明書Cの証明書IDを送ればよい。同時にr-1台のノード1nacが故障したとしても接続可能なノード1nacが1台は存在することになり、ステップSH4で無効化を確認することが可能となる。更新した権限証明書CのCUL16への登録及び分散化の手順については、特に図示しないが、図15で説明した無効化した権限証明書CのCRL15への登録及び分散化の手順とほぼ同様である。但し、次の点で相違する。CUL16への登録及び分散化の手順では、図15のステップSG7にて、図10で説明したように、更新前の権限証明書Cの証明書IDを有する最新の権限証明書C’を登録する。権限証明書Cの更新の確認手順についても、特に図示しないが、図16で説明した権限証明書Cの無効化の確認手順SHとほぼ同様である。但し、次の点で相違する。権限証明書Cの更新の確認手順では、ステップSH4で送られてきた証明書IDに一致する権限証明書CがCUL16に登録されていれば、ステップSH5で最新の権限証明書C’を処理ノードに返送する。ところで、権限証明書Cのハッシュ値を求める方法は種々考えられ、例えば次の方法a,bである。方法a:ハッシュ値を求める対象の権限証明書Cの証明書IDをハッシュ化する。方法b:ハッシュ値を求める対象の権限証明書Cの連鎖証明書リストCCLに記載されている権限証明書Cのルートを順番に並べる。そして、先頭であるルート証明書からL番目の権限証明書Cの証明書IDをハッシュ化する。但し、連鎖証明書リストCCLに記載されている権限証明書Cの長さがLより小さい場合には、ハッシュ値を求める対象の権限証明書Cの証明書IDをハッシュ化する。この場合は方法aと同じとなる。図9のように権限証明書CA,CB,CC,CDと連鎖しており、権限証明書CB,CC,CDをそれぞれ無効化してCRL15に登録する際に、方法bを採用した場合について説明する。Lを例えば2とすると、権限証明書CB~CDは全て同じノード1nacのCRL15に登録されることになる。権限証明書CA~CDの全てを無効化する場合で同様にLを2とすると、権限証明書CB~CDは全て同じノード1nacのCRL15に登録され、権限証明書CAは権限証明書CB~CDとは異なるノード1nacのCRL15に登録されることになる。Lを1とすれば、権限証明書CA~CDは全て同じノード1nacのCRL15に登録される。方法aでは全ての権限証明書Cに対して偏りのないハッシュ値を得ることができるので、無効化した権限証明書Cは分散アクセス制御機構10acを構成する複数のノード1nacのCRL15に偏りなく分散されることになる。方法aは、偏りのない分散を実現しようとする場合には好ましい方法である。一方、方法bでは特定の条件でハッシュ値に偏りが発生する。L回以上の委譲によって発行された権限証明書Cは、L回目の委譲で委譲元の権限証明書Cが同じであれば必ず同じハッシュ値となる。従って、L回目以降の委譲によって発行された権限証明書Cは、無効化された場合、同一のノード1nacのCRL15に登録される。上述した無効化確認手順SHで連鎖した権限証明書Cの無効化を確認する際、方法bでは、権限証明書Cの連鎖がいかなる長さであっても、たかだかL台のノード1nacのCRL15を参照すればよいことになる。方法bは、クライアント3が通信するノード1nac処理ノード以外のノード1nacとの通信回数通信コストを少なくしようとする場合には好ましい方法である。さらに、次のような工夫を施すと、権限証明書Cを検証する際の通信コストをゼロにすることが可能である。方法bを採用し、Lを2とする。図14で説明したように無効化した権限証明書Cを複数のノード1nacに分散させる際に、ルート証明書のみは冗長数rを分散アクセス制御機構10acを構成するノード1nacの数nとする。即ち、ルート証明書を無効化する場合には、ルート証明書を分散アクセス制御機構10acの全てのノード1nacのCRL15に登録しておく。このルート証明書の無効化時にはn-1回の通信が発生する。前述のように、クライアント3が分散アクセス制御機構10acに対してアクセスすると、クライアント3からのアクセスは1つのノード1nacに割り振られることになる。この際に、クライアント3からのアクセスを、クライアント3が利用する権限証明書Cを含む連鎖した権限証明書Cのうち、2番目の権限証明書Cを登録するCRL15を有するノード1nacに割り振るようにする。2番目の権限証明書Cを登録するCRL15とは、2番目の権限証明書Cが無効化されていない時点では、2番目の権限証明書Cが無効化された際に登録することになるCRL15ということである。このような工夫を施すことによって、権限証明書Cの検証手順SFにおいて、連鎖証明書リストCCLに含まれる全ての権限証明書Cが無効化されているか否かを確認する際に、クライアント3からのアクセスが割り振られたノード1nacのみで確認することができる。よって、他のノード1nacと通信する必要がなく、権限証明書Cを検証する際の通信コストはゼロとなる。次に、本実施形態の分散アクセス制御機構10acの安全性をさらに向上させるための対策について説明する。分散アクセス制御機構10acの安全性を向上させるための対策1として、それぞれのノード1nacは、保持するノード秘密鍵Knprとノード公開鍵Knpbとの鍵ペアを定期的に更新することが好ましい。更新前の古いノード秘密鍵Knprは破棄されるので、安全性が向上する。なお、仮に攻撃者がノード1nacに侵入したとすると、進入時期が特定できれば、ノード1nacは、進入した期間のエントリに対してのみ、ノード公開鍵リストの漏洩フラグを立てればよい。これによって、無効化の対象となる権限証明書Cを限定的とすることができ、ノード秘密鍵Knprの漏洩が疑われる事態が発生した場合の影響を最小限にとどめることが可能となる。分散アクセス制御機構10acの安全性を向上させるための対策2として、権限証明書Cを発行時や更新時に、複数であるm台のノード1nacが同様に確認して、権限証明書Cにm個の発行者ノードIDと署名を含ませることが好ましい。それぞれのノード1nacが権限証明書Cを検証する際に、権限証明書Cの検証手順SFにおいて、m個の署名が含まれていて全ての署名が妥当である場合に権限証明書Cを有効とする。このようにすれば、権限証明書Cを発行や更新のコストはm倍になるが、m台のノード1nacからノード秘密鍵Knprが漏洩しない限り、不正なアクセスはできない。m-1台以下のノード1nacからノード秘密鍵Knprの漏洩であれば、漏洩が発覚した後も既存の権限証明書Cを無効化する必要はない。m台以上のノード1nacからノード秘密鍵Knprが漏洩したことが発覚した場合であっても、全て漏洩したノード秘密鍵Knprでm個の署名がされている権限証明書C以外は権限証明書Cを無効化する必要はない。従って、対策2でも、ノード秘密鍵Knprの漏洩が疑われる事態が発生した場合の影響を最小限にとどめることが可能となる。対策1と対策2とを組み合わせることはさらに好ましい。m台のノード1nacの署名はほぼ同時に行われるので、同じ時間帯のノード秘密鍵Knprが用いられる。攻撃者が鍵ペアの更新周期をまたいで少なくとも2つの異なる時間帯でノード秘密鍵Knprを入手したとしても、権限証明書Cの検証が失敗することになる。ノード1nacごとに鍵ペアの更新周期や更新のタイミングをずらすことにより、攻撃を成功しにくくすることが可能となる。本発明は以上説明した本実施形態に限定されることはなく、本発明の要旨を逸脱しない範囲において種々変更可能である。分散アクセス制御機構10acを構成するノード1nacに分散アクセス制御プログラムを搭載するに際し、分散アクセス制御プログラムをノード1nacに対して配信してもよい。分散アクセス制御プログラムを記録媒体に記録して、それぞれのノード1nacにおいて、記録媒体から分散アクセス制御プログラムをインストールしてもよい。ところで、分散ファイルシステム10に、リソースをどのように記憶させるか、リソースをどのように分散させるかは本発明とは直接的には関係せず、リソースの記憶のさせ方及び分散のさせ方は任意である。"