JP5830362B2 - 分散アクセス制御方法 - Google Patents

Description

本発明は、所定の処理を分散して実行させる分散システムに用いて好適な分散アクセス制御方法に関する。

所定の処理を１つのノード（コンピュータ）によって実行させるのではなく、複数のノードによって実行させる分散システムがある。分散システムの一例として、ネットワーク上の複数のサーバにリソース（ファイル，ディレクトリ，フォルダ等）を分散させて記憶させる分散ファイルシステムがある。分散ファイルシステムによれば、一部のサーバが災害等で損傷してもリソースが失われてしまう可能性を低減させることができる。近年のクラウドコンピューティングの普及に伴って、分散ファイルシステムが注目を集めている。

分散ファイルシステムによれば、高い可用性（availability）とスケーラビリティ（scalability）を実現することができる。分散ファイルシステムに対するリソースの書き込みや、分散ファイルシステムに記憶されているリソースの読み出し等のアクセスは、アクセス制御機構と称されているソフトウェアによって制御される。分散ファイルシステムに用いる分散管理型のアクセス制御機構を分散アクセス制御機構と称することとする。

分散ファイルシステムに記憶されているリソースを複数のユーザで共有する場合がある。分散ファイルシステムに記憶されているリソースにアクセスする際には、分散アクセス制御機構によって特定のユーザのみがアクセスできるようにユーザの認証が行われる。ユーザがリソースにアクセスする際の権限の範囲を個々のユーザに対して設定することができる。分散アクセス制御機構は、個々のユーザに与えられている権限の範囲に応じてリソースに対するアクセスを制御する。

分散アクセス制御機構は、分散ファイルシステムの可用性やスケーラビリティに大きな影響を及ぼす。そこで、分散ファイルシステムの可用性やスケーラビリティを向上させるためには、分散ファイルシステム単体ではなく、分散アクセス制御機構を含めたシステム全体で可用性やスケーラビリティを考えることが必要となる。高い可用性を実現するには、分散ファイルシステム及び分散アクセス制御機構が単一障害点を持たないことが必要である。高いスケーラビリティを実現するには、性能がスケールアウトすることが必要である。

非特許文献１には、従来の分散アクセス制御機構の一例として、権限証明書を用いた分散アクセス制御機構が記載されている。

Miltchev, S., Prevelakis, V., Ioannidis, J., Keromytis, A. Smith, J., Secure and flexible global file sharing, Proceedings of the Annual USENIX Technical Conference, Freenix Track, pp.165-178, 2003

分散アクセス制御機構を介して分散ファイルシステム等の分散システムにアクセスする際には、権限証明書の有効性が検証される。権限証明書がルート証明書を始端として権限が順次委譲されることによって発行された場合、分散アクセス制御機構に送信された権限証明書自体の有効性を検証するだけでなく、その送信された権限証明書の全ての委譲元の権限証明書の有効性を検証することも必要となる。即ち、分散アクセス制御機構が分散システムに対してアクセスする際には、複数の権限証明書の有効性を検証することが必要となる。

複数の権限証明書の有効性を検証する際に、それぞれの権限証明書の有効性を検証するたびに通信を行うとすれば、通信コストの点で好ましくない。そこで、通信コストを極力少なくした上で、複数の権限証明書の有効性を検証することができる分散アクセス制御方法が望まれる。

本発明はこのような要望に対応するため、複数の権限証明書の有効性を検証する際の通信コストを極力少なくすることができる分散アクセス制御方法を提供することを目的とする。

本発明は、上述した従来の技術の課題を解決するため、クライアントからサーバにアクセスするに際し、複数のノードを備えて構成される分散アクセス制御機構における前記複数のノードのうちのいずれかのノードを介してサーバにアクセスし、前記クライアントから前記サーバに対して操作要求を行う際に、前記操作要求に権限証明書を添えて前記いずれかのノードに送信し、前記権限証明書は、ルート証明書を始端として権限が順次直列的に１または複数の委譲先に委譲されることによって発行され、前記ルート証明書から、最後の委譲先の直前に位置する前記最後の委譲先の委譲元の権限証明書までの全ての委譲元の権限証明書を特定する特定情報を示す連鎖証明書リストを含み、前記複数のノードの全てのノードは、いずれかのルート証明書が無効化された場合、無効化されたルート証明書を登録し、所定のルート証明書を委譲元として発行された権限証明書以降のいずれかの権限証明書が無効化された場合、前記所定のルート証明書を委譲元として発行された権限証明書以降のいずれの権限証明書であっても、無効化された権限証明書を、前記所定のルート証明書を委譲元として発行された権限証明書の特定情報に基づいて決定した特定のノードに登録し、前記クライアントから前記操作要求に前記権限証明書を添えて前記いずれかのノードに送信する際に、前記特定のノードにアクセスさせることを特徴とする分散アクセス制御方法を提供する。

上記の分散アクセス制御方法において、前記複数のノードにはそれぞれ固有のノードＩＤが設定され、それぞれの権限証明書は前記特定情報として証明書ＩＤを有し、前記所定のルート証明書を委譲元として発行された権限証明書の証明書ＩＤをハッシュ化したハッシュ値に基づいて選択したノードＩＤを有するノードを前記特定のノードとして選択することが好ましい。

本発明の分散アクセス制御方法によれば、複数の権限証明書の有効性を検証する際の通信コストを極力少なくすることができる。

一実施形態の分散アクセス制御機構を示す概略構成図である。 分散ファイルシステムを示す概略構成図である。 一実施形態の分散アクセス制御機構を構成するノードの具体的構成例を示すブロック図である。 ケイパビリティを説明するための図である。 権限の委譲を説明するための図である。 権限証明書Ｃの発行手順ＳＡを示すフローチャートである。 パスワードの認証手順ＳＢを示すフローチャートである。 権限証明書Ｃの認証情報を更新する際の更新手順ＳＣを示すフローチャートである。 無効化した権限証明書Ｃのリストである証明書失効リスト１５を説明するための図である。 更新した権限証明書Ｃのリストである証明書更新リスト１６を説明するための図である。 権限証明書Ｃの権限情報を更新する際の更新手順ＳＤを示すフローチャートである。 ノード公開鍵Knpbの取得手順ＳＥを示すフローチャートである。 権限証明書Ｃの検証手順ＳＦを示すフローチャートである。 証明書失効リスト１５及び証明書更新リスト１６の分散の仕方を説明するための図である。 権限証明書Ｃの無効化手順ＳＧを示すフローチャートである。 権限証明書Ｃの無効化確認手順ＳＨを示すフローチャートである。

以下、本発明の分散アクセス制御方法の一実施形態について、添付図面を参照して説明する。以下詳述する一実施形態は、分散アクセス制御方法を分散システムの一例である分散ファイルシステムで実行させる場合を示している。

まず、図２を用いて分散ファイルシステムの概略について説明する。図２において、分散ファイルシステム１０は、互いにネットワークで接続された複数のノード１ｎを備える。それぞれのノード１ｎはサーバとして機能するコンピュータによって構成される。分散ファイルシステム１０の全体も仮想的な１つのサーバとして機能する。ユーザ２が所有するパーソナルコンピュータ等の端末であるクライアント３はインターネット等のネットワークで分散ファイルシステム１０と接続される。複数のノード１ｎのそれぞれは、他の任意のノード１ｎと直接接続することができるフルメッシュなネットワークとなっていることが好ましい。

分散ファイルシステム１０に対してリソースを読み出したり書き込んだりする等のアクセスをリクエストと称し、分散ファイルシステム１０に対してログインしてからログアウトするまでをセッションと称する。クライアント３が分散ファイルシステム１０に対してアクセスすると、リクエスト毎またはセッション毎にロードバランサやDNSラウンドロビン等の仕組みによって、クライアント３からのアクセスは１つのノード１ｎに割り振られてその１つのノード１ｎのみと通信する。

次に、図１を用いて分散アクセス制御機構の概略について説明する。図１において、分散アクセス制御機構１０acは、互いにネットワークで接続された複数のノード１nacによって構成されている。分散アクセス制御機構１０acも分散ファイルシステム１０と同様、フルメッシュなネットワークとなっていることが好ましい。図１に示す例では、分散アクセス制御機構１０acを構成していないノード１ｎと、分散アクセス制御機構１０acを構成しているノード１nacとによって、分散ファイルシステム１０が構成されている。ノード１nacは分散アクセス制御機構であるソフトウェアがインストールされたノードであり、ノード１ｎはそのソフトウェアがインストールされていないノードである。

図１は、分散ファイルシステム１０を構成するノードが分散アクセス制御機構１０acを構成するノード１nacと完全に一致していなくてもよいことを示している。勿論、分散ファイルシステム１０を構成するノードを全て、分散アクセス制御機構１０acを構成するノード１nacとして、分散ファイルシステム１０と分散アクセス制御機構１０acとを完全に一致させてもよい。

図１は、図２で説明したロードバランサやDNSラウンドロビン等の仕組みによって、クライアント３からのアクセスが１つのノード１nacに割り振られてその１つのノード１nacのみと通信している状態を示している。図１において、ユーザ２ａが所有するクライアント３ａと、ユーザ２ｂが所有するクライアント３ｂと、ユーザ２ｃが所有するクライアント３ｃはそれぞれ、分散アクセス制御機構１０acを構成する１つのノード１nacと接続されている。

ユーザ２ａ，２ｂ，２ｃをユーザ２と総称し、クライアント３ａ，３ｂ，３ｃをクライアント３と総称することとする。クライアント３とノード１nacとの通信やノード１nacどうしの通信はSSL/TLS（Secure Sockets Layer/Transport Layer Security）等によって秘匿性が担保されている。クライアント３は、例えばパーソナルコンピュータやＰＤＡ（携帯情報端末）であり、ネットワークに接続する機能を有する任意の端末でよい。端末に搭載されているＯＳ（オペレーティングシステム）も任意である。

ここで、図３を用いて分散アクセス制御機構１０acを構成するノード１nacの具体的構成について説明する。図３に示すように、クライアント３はノード１nacを介して分散ファイルシステム１０にアクセスする。クライアント３はノード１nacを介することなく分散ファイルシステム１０にアクセスすることはできない。ノード１nacは、ソフトウェアによって構成されるアクセス制御部１１を有する。勿論、ノード１nacはソフトウェアであるアクセス制御部１１を動作させるためのハードウェアを有する。それぞれのノード１nacには、分散アクセス制御機構１０acの全体でユニークなノードＩＤ１２が設定されている。

それぞれのノード１nacは、全てのノード１nacのノードＩＤ１２と接続情報とのマップであるノード経路表１３を有する。接続情報とは、例えばＵＲＬ、または、ＩＰアドレスとポート番号との組である。ノード１nacは、ノード秘密鍵Knprとノード公開鍵Knpbとの鍵ペアを有する。ノード秘密鍵Knprとノード公開鍵Knpbとの鍵ペアはノード１nac毎に異なっている。鍵ペアは更新される場合がある。ノード１nacは、全てのノード１nacの過去から現在までのノード公開鍵Knpbのリストであるノード公開鍵リスト１４を有する。また、ノード公開鍵リスト１４は、ノードＩＤ１２毎に、鍵ペアの利用開始日時とノード公開鍵Knpbと漏洩フラグとの３つの組をエントリ情報として有する。

それぞれのノード１nacにおいて、ノード秘密鍵Knprの漏洩が疑われる場合に漏洩フラグが立てられる。即ち、漏洩が疑われる場合に、漏洩フラグは漏洩を示す値に設定される。なお、漏洩フラグが漏洩を示す値に設定されことは、必ずしも実際にノード秘密鍵Knprが漏洩したことを示すとは限らない。それぞれのノード１nacでノード秘密鍵Knprの漏洩が疑われる事態が発生した場合に、漏洩フラグは漏洩を示す値に設定される。管理者が手動にて漏洩フラグを立ててもよいし、漏洩が疑われる事態が発生したことを検出してノード１nacが自動的に漏洩フラグを立ててもよい。

さらに、それぞれのノード１nacは、証明書失効リスト（以下、ＣＲＬ: Certificate Revocation List）１５と、証明書更新リスト（以下、ＣＵＬ: Certificate Update List）１６とを有する。後に詳述するように、ＣＲＬ１５及びＣＵＬ１６は複数のノード１nacに分散されて記憶される。全てのノード１nacが保持するＣＲＬ１５の全体で証明書失効トータルリストとなり、全てのノード１nacが保持するＣＵＬ１６の全体で証明書更新トータルリストとなる。

表１は、それぞれのノード１nacが保持する情報をまとめて示している。

図３に示すように、クライアント３が分散ファイルシステム１０のリソースに対してアクセスする際には、操作要求に権限証明書Ｃを添えてノード１nacに送信する。後述するように、権限証明書Ｃはノード１nacが発行する。

権限証明書Ｃは、大略的には図４に示すケイパビリティ（Capability）にデジタル署名を付加したものである。ケイパビリティとはユーザ単位のアクセス制御情報である。図４に示すユーザＡ，Ｂ，Ｃはユーザ２の例である。図４に示すように、ユーザＢは、リソースＸに対しては読み出しと書き込みのいずれも許可されておらず、リソースＹに対しては読み出しが許可されており、リソースＺに対しては読み出しと書き込みのいずれも許可されている。このように、それぞれのユーザに対してどのようなアクセスを許可／不許可とするかを示す情報がケイパビリティである。

なお、それぞれのリソース単位でどのユーザにどのようなアクセスを許可／不許可とするかを対応させた情報をＡＣＬ（Access Control List）と称している。ＡＣＬを用いたＡＣＬ方式は、集中管理型のアクセス制御機構で利用されている。本実施形態は、ＡＣＬ方式ではなく、権限証明書Ｃを用いた分散管理型のアクセス制御機構である。

ノード１nacは、操作要求に添えられた権限証明書Ｃが有効であり、要求された操作が権限証明書Ｃにおいて許可されており、クライアント３（ユーザ２）が権限証明書Ｃの所有者であることが認証された場合に、分散ファイルシステム１０に対して操作要求を仲介する。権限証明書Ｃが有効であるか否かは、複数のノード１nacに分散されて記憶されたＣＲＬ１５及びＣＵＬ１６を参照することによって検証される。これについては後述する。クライアント３（ユーザ２）の認証は、操作要求のたびに毎回行う必要はなく、認証結果をキャッシュしておいてセッション単位で認証してもよい。

表２は、権限証明書Ｃに含まれている情報を示している。

権限証明書Ｃに含まれる証明書ＩＤは後述する権限証明書Ｃの更新を行っても不変である。証明書ＩＤは権限証明書Ｃを特定する特定情報である。対象リソースは、図４で説明したリソースＸ，Ｙ，Ｚ等であり、許可する操作は図４で説明した読み出しや書き込み、データの複写，印刷，削除等である。本実施形態では、ユーザ２は、所有する権限証明書Ｃに基づいてそのサブセット権限を有する新たな権限証明書Ｃを発行することができる。対象リソースと許可する操作と有効期間は、権限の範囲を示す権限情報である。

連鎖証明書リストは、権限証明書Ｃがどのように連鎖しているかを示す。連鎖証明書リストが空であればルート証明書ということになる。ルート証明書は少なくとも１つ存在しているものとする。なお、ルート証明書を分散アクセス制御機構１０acの管理者が保有していてもよいし、管理者が特定のユーザ２に発行してもよい。ルート証明書がどのように存在しているかは限定されない。なお、認証方式をパスワード認証に限定する場合には、表２に示す認証方式を示す情報は不要である。

権限証明書Ｃの発行日時は、権限証明書Ｃが更新されていない場合には権限証明書Ｃを最初に発行した発行日時であり、後述のように権限証明書Ｃが更新された場合には更新日時となる。更新日時とは権限証明書Ｃの内容を更新した新たな権限証明書Ｃを発行した発行日時であり、発行日時とは更新日時を含むものとする。発行者ノードＩＤは権限証明書Ｃを発行したノード１nacに設定されているノードＩＤであり、署名は権限証明書Ｃを発行したノード１nacが有するノード秘密鍵Knprを用いたデジタル署名である。

図５を用いて、権限証明書Ｃの権限委譲の例について説明する。ユーザ２としてAliceが所有する権限証明書Ｃを権限証明書Ｃ_Ａとする。図５では、表２に示す権限証明書Ｃに含まれる情報の一部のみを示している。図５におけるＣＣＬは連鎖証明書リストである。Aliceが所有する権限証明書Ｃ_Ａの証明書ＩＤはA0001であり、連鎖証明書リストＣＣＬが空である。即ち、権限証明書Ｃ_Ａはルート証明書である。

Aliceが他のユーザ２としてBobに権限を委譲したとする。委譲先（ここではBob）の権限は委譲元（ここではAlice）の権限を越えない範囲である。Bobが所有する権限証明書Ｃを権限証明書Ｃ_Ｂとする。Bobが所有する権限証明書Ｃ_Ｂの証明書ＩＤはB0001であり、権限証明書Ｃ_Ｂの連鎖証明書リストＣＣＬには権限の委譲元の証明書ＩＤであるA0001が記載されている。

さらに、Bobが他のユーザ２としてCarolに権限を委譲したとする。同様に、委譲先（ここではCarol）の権限は委譲元（ここではBob）の権限を越えない範囲である。Carolが所有する権限証明書Ｃを権限証明書Ｃ_Ｃとする。権限証明書Ｃ_Ｃの連鎖証明書リストＣＣＬには権限の委譲元全ての証明書ＩＤであるA0001，B0001が記載されている。このように、連鎖証明書リストＣＣＬは、ルート証明書を始端として権限が順に委譲され場合のルート証明書から直前の証明書までの全ての委譲元の証明書ＩＤのリストを示している。権限証明書Ｃに含まれている連鎖証明書リストＣＣＬに記載されている証明書ＩＤによって、どのような権限証明書Ｃの経路で権限が委譲されたかが分かる。

ここで、図６を用いてノード１nacによる権限証明書Ｃの発行手順ＳＡについて説明する。図６に示す権限証明書Ｃの発行手順ＳＡは、一実施形態の分散アクセス制御方法の一部である権限証明書Ｃの発行方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である権限証明書Ｃの発行ステップである。

ユーザ２がクライアント３の端末を操作して、委譲元の権限証明書Ｃ（ユーザ２が所有する権限証明書Ｃ）と、新たに発行する権限証明書Ｃの権限情報と、初期パスワードｐｉを入力して、ノード１nacに対して新たな権限証明書Ｃの発行を指示したとする。委譲元の権限証明書ＣをＣ_Ｐとする。ノード１nacのアクセス制御部１１は、ステップＳＡ１にて、クライアント３から、委譲元の権限証明書Ｃ_Ｐと、新たに発行する権限証明書Ｃの権限情報と、初期パスワードｐｉを受け取る。

図５におけるBobがCarolに権限を委譲する場合を例にすると、アクセス制御部１１は、Bobが所有する権限証明書Ｃ_Ｂと新たに発行してCarolに与えようとする権限証明書Ｃ_Ｃの権限情報と初期パスワードｐｉを受け取る。初期パスワードｐｉはBobが予め定められたパスワードの付与ルールに従って適宜に設定すればよい。以下、理解を容易にするためにBobがCarolに権限を委譲する場合の説明を適宜補足することとする。

アクセス制御部１１は、ステップＳＡ２にて、委譲元の権限証明書Ｃ_Ｐ（権限証明書Ｃ_Ｂ）を検証する。ステップＳＡ２の権限証明書Ｃ_Ｐの検証手順ＳＦの具体的手順については後述する。アクセス制御部１１は、ステップＳＡ３にて、ユーザ２（クライアント３）が委譲元の権限証明書Ｃ_Ｐ（権限証明書Ｃ_Ｂ）の所有者であることを認証する。ステップＳＡ３のユーザ２が委譲元の権限証明書Ｃ_Ｐの所有者であることの認証手順ＳＢの具体的手順については後述する。認証が成立した場合には、アクセス制御部１１は処理をステップＳＡ４に移行させる。

アクセス制御部１１は、ステップＳＡ４にて、委譲元の権限証明書Ｃ_Ｐ（権限証明書Ｃ_Ｂ）と比較して新たに発行する権限証明書Ｃ（権限証明書Ｃ_Ｃ）の権限情報に権限の拡大や期限の延長等の不正がなく正当であるか否かを確認する。正当でなければ（NO）、アクセス制御部１１は、ステップＳＡ１０にて、新しい権限証明書Ｃ（権限証明書Ｃ_Ｃ）の発行を不許可として終了する。この際、特に図示していないが、アクセス制御部１１は、新しい権限証明書Ｃの発行を不許可となったこと及びその理由をユーザ２（Bob）に通知する。

ステップＳＡ４にて正当であれば（YES）、アクセス制御部１１は、ステップＳＡ５にて、新たに発行する権限証明書Ｃ（権限証明書Ｃ_Ｃ）の証明書ＩＤを生成して設定する。アクセス制御部１１は、ステップＳＡ６にて、初期パスワードｐｉを用いて公開認証情報Ｉoauthを生成して設定する。公開認証情報Ｉoauthは次の式（１）によって求める。式（１）において、ｒ₁，ｒ₂は乱数、passwordは初期パスワードｐｉの平文である。また、a‖bはaとbとを連結（ビット結合）することを意味し、H(M)はメッセージMに対して一方向ハッシュ関数を適用することを意味し、E_Knpb(M)はメッセージMをノード公開鍵Knpbを用いて暗号化することを意味する。

Ioauth=r₁‖r₂‖E_Knpb(r₂‖H(r₁‖password)) …（１）

式（１）において、乱数ｒ₁，ｒ₂は公開認証情報Ｉoauthをより不規則とするために用いており、乱数ｒ₁，ｒ₂は擬似乱数であってもよい。公開認証情報Ｉoauthは、パスワードを一方向性ハッシュ関数を用いて一方向化し、ノード１nacが備えるノード公開鍵Knpbを用いて暗号化した値である。

アクセス制御部１１は、ステップＳＡ７にて、新たに発行する権限証明書Ｃ（権限証明書Ｃ_Ｃ）の連鎖証明書リストＣＣＬとして、委譲元の権限証明書Ｃ_Ｐ（権限証明書Ｃ_Ｂ）の連鎖証明書リストＣＣＬに委譲元の権限証明書Ｃ_Ｐ（権限証明書Ｃ_Ｂ）の証明書ＩＤを加えたリストを設定する。図５で説明したように、権限証明書Ｃ_Ｂの連鎖証明書リストＣＣＬには証明書ＩＤとしてA0001が記載されており、この連鎖証明書リストＣＣＬに権限証明書Ｃ_Ｂの証明書ＩＤであるB0001を加えることによって、権限証明書Ｃ_Ｃの連鎖証明書リストＣＣＬとなる。

アクセス制御部１１は、ステップＳＡ８にて、新たに発行する権限証明書Ｃ（権限証明書Ｃ_Ｃ）の発行日時に現在時刻を設定し、発行者ノードＩＤに新たな権限証明書Ｃを発行しようとしているノード１nac自身のノードＩＤを設定する。ここでの現在時刻とは、年月日及び秒までの現在時刻である。そして、アクセス制御部１１は、ステップＳＡ９にて、新たな権限証明書Ｃを発行しようとしているノード１nac自身のノード秘密鍵Knprを用いてデジタル署名し、新しい権限証明書Ｃ（権限証明書Ｃ_Ｃ）を発行して終了する。

以上のようにして、新たに発行する権限証明書Ｃとして、証明書ＩＤ，新たな権限情報，公開認証情報，連鎖証明書リスト，発行日時，発行者ノードＩＤ，デジタル署名が設定された新しい権限証明書Ｃが発行される。

新しい権限証明書Ｃを委譲先のユーザ２（クライアント３）に渡す方法は任意である。例えば、BobがCarolに権限を委譲する場合、新たに発行した権限証明書Ｃ_ＣをCarolに直接送付してもよいし、Bobに送付してBobがCarolに転送してもよい。また、ノード１nacが新たに発行した権限証明書Ｃ_Ｃを保持しておき、Carolが分散アクセス制御機構１０acにログインした時点でCarolに転送するようにしてもよい。

以上の説明より分かるように、本実施形態によれば、ユーザ２は自身が保有する権限の範囲内で、他のユーザ２に対して分散ファイルシステム１０へのアクセスの権限を自由に設定することができる。分散アクセス制御機構１０acの管理者等の特定の者が権限証明書Ｃを発行し、権限証明書Ｃの管理を行う必要がないので、権限証明書Ｃの発行・管理のコストを分散させることが可能となる。

図７を用いて、図６におけるステップＳＡ３のユーザ２が委譲元の権限証明書Ｃ（ここでは権限証明書Ｃ_Ｐ）の所有者であることの認証手順ＳＢの具体的手順について説明する。図７に示す認証手順ＳＢは、一実施形態の分散アクセス制御方法の一部である認証方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である認証ステップである。

図７において、アクセス制御部１１は、ステップＳＢ１にて、権限証明書Ｃ（権限証明書Ｃ_Ｐ）とパスワードｐを受け取る。パスワードｐは権限証明書Ｃ_Ｐを発行した際に設定したパスワードである。パスワードを変更していなければ、パスワードｐは初期パスワードｐｉである。アクセス制御部１１は、ステップＳＢ２にて、権限証明書Ｃから公開認証情報Ｉoauthを取得する。アクセス制御部１１は、ステップＳＢ３にて、ノード公開鍵リストから権限証明書Ｃ（権限証明書Ｃ_Ｐ）の発行時に用いられたノード公開鍵Knpbを取得する。ステップＳＢ３のノード公開鍵Knpbの取得手順ＳＥの具体的手順については後述する。

アクセス制御部１１は、ステップＳＢ４にて、次の式（２）が成立するか否かを判定する。式（２）において、cは公開認証情報Ｉoauthを乱数ｒ₁，ｒ₂と値ｃとに分割したときの値ｃである。逆に言えば、cは乱数ｒ₁，ｒ₂と値ｃとを連結して公開認証情報Ｉoauthとなるような値である。

c=E_Knpb(r₂‖H(r₁‖p)) …（２）

式（２）が成立すれば（YES）、アクセス制御部１１は、ステップＳＢ５にて、パスワード認証は成立したと決定して終了する。式（２）が成立しなければ（NO）、アクセス制御部１１は、ステップＳＢ６にて、パスワード認証は不成立であると決定して終了する。式（２）が成立するということは、ユーザ２によって入力されたパスワードｐを一方向性ハッシュ関数を用いて一方向化し、権限証明書Ｃ（権限証明書Ｃ_Ｐ）の発行時に用いられたノード公開鍵Knpbを用いて暗号化した値が、公開認証情報Ｉoauthと一致するということである。

このように、パスワードｐを一方向性ハッシュ関数を用いて一方向化し、ノード公開鍵リストから取得した権限証明書Ｃの発行時に用いられたノード公開鍵Knpbを用いて暗号化した値と、権限証明書Ｃから取得した公開認証情報とを比較することによって、クライアント３（ユーザ２）が権限証明書Ｃの所有者であることを認証することができる。本実施形態では、ユーザ２（クライアント３）から送信された権限証明書Ｃとパスワードｐのみを用いてパスワード認証を実現することが可能である。

ところで、公開認証情報Ｉoauthは、「条件１：分散アクセス制御機構１０ac（ノード１nac）が公開認証情報Ｉoauthのみを用いて権限証明書Ｃの認証を行うことができる」、「条件２：公開認証情報Ｉoauthが漏洩した場合でも権限証明書Ｃの認証の安全性が担保できる」の２つの条件を満たす情報である。条件２を満たすことにより権限証明書Ｃに公開認証情報Ｉoauthを含めることが可能となる。条件１を満たすことにより、分散アクセス制御機構１０acは認証情報を保持する必要がない。

上記の式（１）によれば公開認証情報Ｉoauthは一方向ハッシュ関数によって一方向化されているため、逆向きにパスワードを求めることは極めて困難である。従って、仮に攻撃者が他人の権限証明書Ｃを入手したとしても、図７の認証手順ＳＢでパスワード認証が成功する可能性は極めて低い。さらには、攻撃者は、通常、ノード秘密鍵Knprとノード公開鍵Knpbとの鍵ペアを知り得ないため、公開認証情報Ｉoauthを計算することも極めて困難である。

なお、パスワード認証の代わりに従来一般的に行われている公開鍵認証を採用する場合には、図７に示すパスワード認証の認証手順ＳＢの代わりに一般的な公開鍵認証の認証手順を用いることが可能である。

本実施形態によれば、図６で説明した権限証明書Ｃの発行方法を採用することによって、パスワード認証が可能な権限証明書Ｃとすることができる。本実施形態によれば、図７で説明した認証方法を採用することによって、ユーザ２が権限証明書Ｃの所有者であることを認証することができる。以上によって、パスワード認証を実現している。

次に、認証情報の更新について説明する。本実施形態によれば、管理者等の第三者によらず、いわゆる自立的に認証情報を更新することが可能である。非特許文献１に記載のような従来の分散アクセス制御機構においては、権限証明書Ｃの署名に権限証明書Ｃの最初の許諾者（図５の例ではルート証明書を所有するAlice）の秘密鍵を必要とする。従って、最初の許諾者からの委譲先以降である権限証明書Ｃの所有者（図５の例ではBob，Carol）は自立的に認証情報を更新することはできない。本実施形態では、図８に示す認証情報の更新手順ＳＣによって自立的な認証情報の更新を実現している。

図８を用いて、権限証明書Ｃの認証情報を更新する際の更新手順ＳＣについて説明する。図８に示す権限証明書Ｃの更新手順ＳＣは、一実施形態の分散アクセス制御方法の一部である更新方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である更新ステップである。

ユーザ２がクライアント３の端末を操作して、更新しようとする権限証明書Ｃと新しい認証情報（パスワードｐ）を入力して、ノード１nacに対して権限証明書Ｃの更新を指示したとする。図８において、アクセス制御部１１は、ステップＳＣ１にて、更新する権限証明書Ｃと新しいパスワードｐを受け取る。アクセス制御部１１は、ステップＳＣ２にて、権限証明書Ｃを検証する。ステップＳＣ２の権限証明書Ｃの検証手順ＳＦの具体的手順については後述する。アクセス制御部１１は、ステップＳＣ３にて、ユーザ２が権限証明書Ｃの所有者であることを認証する。

ステップＳＣ３のユーザ２が権限証明書Ｃの所有者であることの認証手順ＳＢの具体的手順は図７で説明した通りである。但し、ステップＳＣ３では、ユーザ２は認証手順ＳＢにおいて更新しようとしている権限証明書Ｃの発行時に設定したパスワードｐを入力して、ノード１nacが図７のように認証する。

アクセス制御部１１は、ステップＳＣ４にて、権限証明書Ｃの内容を複写して新しい権限証明書Ｃ’を作成する。アクセス制御部１１は、ステップＳＣ５にて、新しいパスワードｐから公開認証情報Ｉoauthを生成して、新しい権限証明書Ｃ’に設定する。アクセス制御部１１は、ステップＳＣ６にて、新しい権限証明書Ｃ’の発行日時に現在時刻を設定し、ステップＳＣ７にて権限証明書Ｃを更新しようとしているノード１nac自身のノード秘密鍵Knprを用いてデジタル署名し、新しい権限証明書Ｃ’を発行する。そして、アクセス制御部１１は、ステップＳＣ８にて、新しい権限証明書Ｃ’をユーザ２に返送し、併せて、新しい権限証明書Ｃ’を複数のノード１nacのＣＵＬ１６に登録する。

前述のように、権限証明書Ｃの内容を更新しても証明書ＩＤが不変である。従って、公開認証情報Ｉoauthを更新した新たな権限証明書Ｃ’は更新前の権限証明書Ｃの証明書ＩＤを維持している。ＣＵＬ１６は、更新前の権限証明書Ｃの証明書ＩＤを有する公開認証情報Ｉoauthを更新した新たな権限証明書Ｃ’を格納する。ＣＵＬ１６については図１０を用いて後に詳述する。また、ステップＳＣ８にて、新しい権限証明書Ｃ’をどの複数のノード１nacに記憶させるかについても後述する。

このように、本実施形態では、分散アクセス制御機構１０ac（ノード１nac）がノード秘密鍵Knprを用いて署名するので、権限証明書Ｃを更新しようとする権限証明書Ｃの所有者は、最初の許諾者によらず自由に認証情報を更新することが可能となる。非特許文献１に記載の従来の分散アクセス制御機構のようにユーザ２が自由に権限証明書Ｃを作成して発行できる場合には、権限証明書Ｃを検証する際に権限の範囲の拡大や期限の延長がないかを確認しなければならない。本実施形態では、分散アクセス制御機構１０ac（ノード１nac）が権限証明書Ｃを発行するので、発行の際に権限の範囲の拡大や期限の延長がないかを確認することができる。よって、検証のコストを低減させることが可能となる。

次に、図９，図１０を用いてＣＲＬ１５，ＣＵＬ１６について説明する。非特許文献１に記載の従来の分散アクセス制御機構では、権限証明書Ｃを更新する手段は明示的に提供されていない。従って、前述のように、権限証明書Ｃを更新しようとすれば、発行済みの権限証明書Ｃを無効化し、新たに権限証明書Ｃを再発行することになる。しかしながら、一旦権限証明書を無効化すると、大きな副作用を起こしてしまう。そこで、本実施形態では、ＣＵＬ１６を用いることによって副作用のない権限変更を実現している。

図９（Ａ）に示すように、権限証明書Ｃ_Ａに基づいて権限証明書Ｃ_Ｂが発行され、権限証明書Ｃ_Ｂに基づいて権限証明書Ｃ_Ｃが発行され、権限証明書Ｃ_Ｃに基づいて権限証明書Ｃ_Ｄが発行されている。権限証明書Ｃ_Ａ〜Ｃ_Ｄにそれぞれの証明書ＩＤを記載している。権限証明書Ｃ_Ｂを無効化すると、図９（Ｂ）に示すように、権限証明書Ｃ_Ｂを無効化することによってＣＲＬ１５には権限証明書Ｃ_Ｂが登録される。図９（Ａ）及び図１０（Ａ）において、×は無効となっていることを示す。

ある権限証明書Ｃにおいて、図５で説明した連鎖証明書リストＣＣＬに記載されている証明書ＩＤのいずれか１つでもＣＲＬ１５に登録されていれば、その権限証明書Ｃは無効となる。従って、図９（Ａ）に示すように、権限証明書Ｃ_Ｂに基づいて発行された権限証明書Ｃ_Ｃと、権限証明書Ｃ_Ｃに基づいて発行された権限証明書Ｃ_Ｄも無効となる。

これに対して、ＣＵＬ１６は権限証明書Ｃがどのように更新されたかを示す情報を登録している。図１０（Ａ）は、権限証明書Ｃ_Ｂが権限証明書Ｃ_Ｂ’に更新された状態を示している。権限証明書Ｃ_Ｂが権限証明書Ｃ_Ｂ’に更新されても証明書ＩＤは不変である。図１０（Ｂ）に示すように、ＣＵＬ１６に権限証明書Ｃ_Ｂが権限証明書Ｃ_Ｂ’に更新されたことが登録されている。ここでは概念的に示しており、ＣＵＬ１６には、更新前の権限証明書Ｃの証明書ＩＤと更新後の権限証明書Ｃ’の内容とを対応させた情報が登録される。証明書ＩＤが不変であるので、ＣＵＬ１６には、更新後の権限証明書Ｃ’が登録されるということである。図１０（Ａ）の例では、図１０（Ｂ）に示すＣＵＬ１６には、更新前の権限証明書Ｃ_Ｂの証明書ＩＤであるB0001を有する更新後の権限証明書Ｃ_Ｂ’が登録される。

図１１を用いて権限証明書Ｃの権限情報を更新する際の更新手順ＳＤについて説明する。図１１に示す権限証明書Ｃの更新手順ＳＤは、一実施形態の分散アクセス制御方法の一部である更新方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である更新ステップである。

ユーザ２がクライアント３の端末を操作して、更新しようとする権限証明書Ｃと、更新しようとする権限証明書Ｃに新しく設定する権限情報と、更新者であるユーザ２が所有する権限証明書Ｃを入力して、権限証明書Ｃの権限変更を指示したとする。更新者が所有する権限証明書ＣをＣ_Ｕとする。アクセス制御部１１は、ステップＳＤ１にて、更新する権限証明書Ｃと、新しく設定する権限情報と、更新者が所有する権限証明書Ｃ_Ｕを受け取る。

図５におけるBobが更新者であり、Carolが所有する権限証明書Ｃ_Ｃを更新する場合を例にすると、アクセス制御部１１は、更新しようとするCarolの権限証明書Ｃ_Ｃと、新しく設定する権限情報と、Bobが所有する権限証明書Ｃ_Ｂを受け取る。以下、理解を容易にするためにBobがCarolの権限証明書Ｃ_Ｃを更新する場合の説明を適宜補足することとする。

アクセス制御部１１は、ステップＳＤ２にて、更新する権限証明書Ｃ（権限証明書Ｃ_Ｃ）及び更新者の権限証明書Ｃ _Ｕ （権限証明書Ｃ_Ｂ）を検証する。ステップＳＤ２の権限証明書Ｃの検証手順ＳＦの具体的手順については後述する。アクセス制御部１１は、ステップＳＤ３にて、更新者が所有する権限証明書Ｃ _Ｕ （権限証明書Ｃ_Ｂ）が、更新する権限証明書Ｃ（権限証明書Ｃ_Ｃ）の連鎖証明書リストＣＣＬの中に存在するか否かを確認する。更新者が所有する権限証明書Ｃ _Ｕ が、更新する権限証明書Ｃの連鎖証明書リストＣＣＬの中に存在するということは、更新者が所有する権限証明書Ｃ _Ｕ が更新する権限証明書Ｃの委譲元であるということである。

更新者が所有する権限証明書Ｃ _Ｕ が、更新する権限証明書Ｃの連鎖証明書リストＣＣＬの中に存在しなければ（NO）、アクセス制御部１１は、ステップＳＤ１１にて、権限証明書Ｃ（権限証明書Ｃ_Ｃ）の更新を不許可として終了する。

更新者が所有する権限証明書Ｃ _Ｕ が、更新する権限証明書Ｃの連鎖証明書リストＣＣＬの中に存在すれば（YES）、アクセス制御部１１は、処理をステップＳＤ４に移行させる。アクセス制御部１１は、ステップＳＤ４にて、更新者が所有する権限証明書Ｃ _Ｕ と比較して、新しく設定する権限情報に権限の拡大や期限の延長等の不正がなく正当であるか否かを確認する。正当でなければ（NO）、アクセス制御部１１は、ステップＳＤ１１にて、権限証明書Ｃ（権限証明書Ｃ_Ｃ）の更新を不許可として終了する。

正当であれば（YES）、アクセス制御部１１は、処理をステップＳＤ５に移行させる。アクセス制御部１１は、ステップＳＤ５にて、更新者が権限証明書Ｃ _Ｕ （権限証明書Ｃ_Ｂ）の所有者であることを認証する。ステップＳＤ５の更新者が権限証明書Ｃ _Ｕ の所有者であることの認証手順ＳＢの具体的手順は図７で説明した通りである。但し、ステップＳＤ５では、ユーザ２は更新者が所有する権限証明書Ｃ _Ｕ の発行時に設定したパスワードｐを入力して、ノード１nacが図７のように認証する。

アクセス制御部１１は、ステップＳＤ６にて、更新する権限証明書Ｃ（権限証明書Ｃ_Ｃ）の内容を複写して新しい権限証明書Ｃ’を作成する。アクセス制御部１１は、ステップＳＤ７にて、新しい権限情報を新しい権限証明書Ｃ’に設定する。アクセス制御部１１は、ステップＳＤ８にて、新しい権限証明書Ｃ’の発行日時に現在時刻を設定する。アクセス制御部１１は、ステップＳＤ９にて、権限証明書Ｃを更新しようとしているノード１nac自身のノード秘密鍵Knprを用いてデジタル署名し、新しい権限証明書Ｃ’を発行する。そして、アクセス制御部１１は、ステップＳＤ１０にて、更新する権限証明書Ｃ（権限証明書Ｃ_Ｃ）の証明書ＩＤを有する新しい権限証明書Ｃ’を複数のノード１nacのＣＵＬ１６に格納して終了する。

ステップＳＤ１０にて、新しい権限証明書Ｃ’をどの複数のノード１nacに記憶させるかについては後述する。なお、同じ証明書ＩＤに対してＣＵＬ１６に権限証明書Ｃ’が登録されている場合には、発行日時の新しい方の権限証明書Ｃ’で上書きする。

ここで、図１２を用いて、図７の認証手順ＳＢにおけるステップＳＢ３のノード公開鍵Knpbの取得手順ＳＥの具体的手順について説明する。図１２に示すノード公開鍵Knpbの取得手順ＳＥは、一実施形態の分散アクセス制御方法の一部であるノード公開鍵Knpbの取得方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部であるノード公開鍵Knpbの取得ステップである。

図１２において、アクセス制御部１１は、ステップＳＥ１にて、権限証明書Ｃから発行日時と発行者ノードＩＤを取得する。アクセス制御部１１は、ステップＳＥ２にて、ノード公開鍵リストから発行者ノードＩＤに対応する鍵ペアの利用開始日時とノード公開鍵Knpbと漏洩フラグとの３つの組であるエントリ情報を検索する。

アクセス制御部１１は、ステップＳＥ３にて、該当するエントリ情報のうち、鍵ペアの利用開始日時よりも権限証明書Ｃの発行日時が新しく、利用開始日時が最も新しいエントリ情報を取得する。そして、アクセス制御部１１は、ステップＳＥ４にて、取得したエントリ情報からノード公開鍵Knpbと漏洩フラグとを取得する。

前述のように、ノード公開鍵リストには、過去から現在までの全てのノード１nacのノード公開鍵Knpbが格納されている。図１２に示す取得手順ＳＥによって、権限証明書Ｃの発行や更新を担当していないノード１nacであっても、権限証明書Ｃの検証手順ＳＦ及び認証手順ＳＢで必要となるノード公開鍵Knpbを取得することができる。

次に、図１３を用いて、図６の権限証明書Ｃの発行手順ＳＡ、図８の認証情報の更新手順ＳＣ、図１１の権限証明書Ｃの更新手順ＳＤのそれぞれで行われる権限証明書Ｃの検証手順ＳＦの具体的手順について説明する。図１３に示す権限証明書Ｃの検証手順ＳＦは、一実施形態の分散アクセス制御方法の一部である権限証明書Ｃの検証方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である権限証明書Ｃの検証ステップである。

図１３において、アクセス制御部１１は、ステップＳＦ１にて、現在時刻が権限証明書Ｃの有効期限の範囲内であるか否かを確認する。有効期限の範囲内でなければ（NO）、アクセス制御部１１は、ステップＳＦ９にて、権限証明書Ｃを無効と決定して終了する。有効期限の範囲内であれば（YES）、アクセス制御部１１は、ステップＳＦ２にて、権限証明書Ｃとその連鎖証明書リストに含まれる全ての権限証明書Ｃがいずれも無効でないことを確認する。ステップＳＦ２の確認手順ＳＨの具体的手順については後述する。

アクセス制御部１１は、ステップＳＦ３にて、ノード公開鍵リストから権限証明書Ｃの発行時に用いられたノード公開鍵Knpbと漏洩フラグとを取得する。ステップＳＦ３のノード公開鍵Knpbと漏洩フラグの取得手順ＳＥは図１２で説明した通りである。アクセス制御部１１は、ステップＳＦ４にて、漏洩フラグが漏洩を示す値であるか否かを判定する。前述のように、漏洩フラグが漏洩を示す値であれば、ノード秘密鍵Knprの漏洩が疑われる事態が発生したということである。漏洩フラグが漏洩を示す値であれば（YES）、アクセス制御部１１は、ステップＳＦ９にて権限証明書Ｃを無効と決定して終了する。

漏洩フラグが漏洩を示す値でなければ（NO）、アクセス制御部１１は、ステップＳＦ５にて、ノード公開鍵Knpbを用いて権限証明書Ｃの署名を検証する。特に図示していないが、署名の検証を失敗した場合には権限証明書Ｃを無効と決定して終了する。アクセス制御部１１は、ステップＳＦ６にて、権限証明書Ｃが更新されているか否かを判定する。権限証明書Ｃが更新されているか否かは、更新されているか否かを確認しようとしている権限証明書Ｃの証明書ＩＤと同じ証明書ＩＤの権限証明書ＣがＣＵＬ１６に登録されているか否かで判定することができる。

権限証明書Ｃが更新されていなければ（NO）、アクセス制御部１１は、ステップＳＦ７にて、権限証明書Ｃを有効と決定して終了する。権限証明書Ｃが更新されていれば（YES）、アクセス制御部１１は、ステップＳＦ８にて、ＣＵＬ１６に登録されている権限証明書Ｃ（即ち、最新の権限証明書Ｃ’）に更新して終了する。

権限証明書Ｃは、ユーザ２からの操作要求の可否を判断する場合の他、権限証明書Ｃの発行や更新等の権限証明書Ｃが利用される操作の際に必ず検証される。このため、遅くとも図１３の検証手順ＳＦによる検証時には、全ての権限証明書ＣがステップＳＦ２で無効化されているか否かとステップＳＦ６で更新されているか否かが検出されることが保証される。

例えば、図５において、Aliceがパスワードを変更するのに伴って権限証明書Ｃ_Ａが権限証明書Ｃ_Ａ’へと更新されたとする。攻撃者がAliceの古い権限証明書Ｃ_Ａとそのパスワードを不正に入手して分散アクセス制御機構１０acにアクセスを試みた場合を考える。この場合、ＣＵＬ１６にはAliceの古い権限証明書Ｃ_Ａの証明書ＩＤを有する新しい権限証明書Ｃ_Ａ’が登録されているため、権限証明書Ｃ_Ａは最新の権限証明書Ｃ_Ａ’に置換される。従って、図７の認証手順ＳＢによる認証は失敗することになる。

他の例として、図５に示すように、BobがCarolに対してリソースとして/bob/foo.docの読み出しのみを許可しており、後にそのリソースに対して書き込みも許可する必要が発生した場合を考える。Bobの権限証明書Ｃ_Ｂは書き込みの権限を含んでいるため、上述した権限証明書Ｃの更新手順ＳＤによって、Bobは書き込みの権限を加えた新しい権限証明書Ｃ’をCarolの新しい権限証明書Ｃ_Ｃ’としてＣＵＬ１６に登録することができる。CarolはBobによる権限証明書Ｃ_Ｃの更新を意識する必要はなく、Carolが有していた更新前の古い権限証明書Ｃ_Ｃを使って書き込み処理を実行すれば、古い権限証明書Ｃ_Ｃが最新の権限証明書Ｃ_Ｃ’に置換されて書き込み処理が許可されることになる。

本実施形態においては、分散ファイルシステム１０に対してアクセスする際に分散アクセス制御機構１０acがアクセス制御するのに必要な情報は権限証明書Ｃに含まれている。個々のノード１nacは、ノード経路表１３，ノード公開鍵リスト１４，ＣＲＬ１５，ＣＵＬ１６を除いて、アクセス制御するのに必要な情報を保持する必要がなく、個々のノード１nacは独立してアクセス制御を実行することができる。従って、本実施形態では、アクセス制御を実行するノード１nacを増やすことによって、容易に単一障害点を排除して性能をスケールアウトすること可能となる。

ノード経路表１３はノード１nac間での通信で必要となり、ノード公開鍵リスト１４は権限証明書Ｃの検証やパスワード認証等の際に必要となる。従って、ノード経路表１３及びノード公開鍵リスト１４は、分散アクセス制御機構１０acを構成する全てのノード１nacで必要な情報である。ノード１nacの追加・離脱や鍵ペアの更新の頻度は、権限証明書Ｃの無効化や更新の頻度と比較して十分に少ない。ノード経路表１３やノード公開鍵リスト１４のデータ容量はさほど大きくない。そこで、全てのノード１nacは、ノード経路表１３及びノード公開鍵リスト１４を共通して保持する。どのノード１nacも、ノード経路表１３及びノード公開鍵リスト１４として同じ情報を保持する。

ＣＲＬ１５及びＣＵＬ１６はユーザ２（クライアント３）から送信された権限証明書Ｃが無効でないか等を確認するために全てのノード１nacで参照できることが必要である。特定のノード１nacにＣＲＬ１５またはＣＵＬ１６を保持させると、その特定のノード１nacが単一障害点となり、同時にボトルネックとなって性能のスケールアウトを妨げることになる。そこで、本実施形態では、ＣＲＬ１５及びＣＵＬ１６を分散させ、さらに冗長化させて複数のノード１nacに保持させる。

前述のように、それぞれのノード１nacが保持しているＣＲＬ１５，ＣＵＬ１６を分散アクセス制御機構１０acの全てのノード１nacでまとめると、証明書失効トータルリスト，証明書更新トータルリストとなる。即ち、証明書失効トータルリスト，証明書更新トータルリストは、複数のＣＲＬ１５，ＣＵＬ１６に分割された形で全てのノード１nacにまたがるようにして保持されていることになる。

本実施形態では、コンシステント・ハッシュ法（Consistent Hashing）を用いて、ＣＲＬ１５及びＣＵＬ１６を分散させる。図１４を用いて、コンシステント・ハッシュ法を用いたＣＲＬ１５及びＣＵＬ１６の分散の仕方について説明する。図１４に示すように、それぞれのノード１nacのノードＩＤが0，150，300，450，600，750であったとする。図１４に示す複数のノード１nacは図２で説明したようにフルメッシュなネットワークとなっており、ノード経路表１３を参照することによって直接目的とする他のノード１nacと通信が可能であるとする。

無効化しようとする権限証明書Ｃの内容からハッシュ関数によってハッシュ値を求める。ハッシュ値は400であったとする。ここでのハッシュ関数は一方向性を満たさなくてもよく、一様性が満たされていればよい。図１４に示す環状のハッシュ空間に配置されたノード１nacで、ハッシュ値400に順方向で最も近いノード１nacはノードＩＤが450のノード１nacである。そこで、無効化する権限証明書ＣをノードＩＤが450のノード１nacに保存し、その近傍のノード１nacに無効化する権限証明書Ｃの複製を保存する。冗長数をｒとすると、（ｒ−１）台のノード１nacに無効化する権限証明書Ｃの複製を保存する。図１４は冗長数ｒが３の場合を示しており、近傍のノード１nacはノードＩＤが600と750のノード１nacとなる。

コンシステント・ハッシュ法を用いてＣＲＬ１５及びＣＵＬ１６を分散させる場合、権限証明書Ｃのハッシュ値がどのような範囲に分布するかによって、それぞれのノード１nacに付与するノードＩＤの値を設定すればよい。

図１５を用いて、権限証明書Ｃの無効化手順ＳＧ（ＣＲＬ１５への登録手順）について説明する。図１５に示す権限証明書Ｃの無効化手順ＳＧは、一実施形態の分散アクセス制御方法の一部である権限証明書Ｃの無効化方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である権限証明書Ｃの無効化ステップである。

ユーザ２がクライアント３の端末を操作して、無効化しようとする権限証明書Ｃと、ユーザ２が所有する権限証明書Ｃを入力したとする。無効化の手続きをするユーザ２が所有する権限証明書ＣをＣ_Ｕとする。図１５において、ノード１nacのアクセス制御部１１は、ステップＳＧ１にて、無効化する権限証明書Ｃと所有する権限証明書Ｃ_Ｕを受け取る。権限証明書Ｃ，Ｃ_Ｕを受け取ったノード１nacを処理ノードと称することとする。図１４では、処理ノードの図示を省略している。

処理ノードのアクセス制御部１１は、ステップＳＧ２にて、無効化する権限証明書Ｃと所有する権限証明書Ｃ_Ｕを検証する。検証手順ＳＦの具体的手順は図１３で説明した通りである。処理ノードのアクセス制御部１１は、ステップＳＧ３にて、所有する権限証明書Ｃ_Ｕが無効化する権限証明書Ｃと同じか、連鎖証明書リストＣＣＬの中に存在するか否かを確認する。

権限証明書Ｃ_Ｕが権限証明書Ｃと同じではなく、連鎖証明書リストＣＣＬの中に存在しなければ（NO）、ユーザ２は無効化しようとした権限証明書Ｃを無効化する権限がないため、ステップＳＧ１０にて無効化不成立として終了する。権限証明書Ｃ_Ｕが権限証明書Ｃと同じであるか、連鎖証明書リストＣＣＬの中に存在すれば（YES）、処理ノードのアクセス制御部１１は、ステップＳＧ４にて、無効化の手続きをしているユーザ２が権限証明書Ｃ_Ｕの所有者であることを認証する。認証手順ＳＢの具体的手順は図７で説明した通りである。

処理ノードのアクセス制御部１１は、ステップＳＧ５にて、権限証明書Ｃのハッシュ値を求め、ステップＳＧ６にて、ハッシュ値に基づいて最も近傍のノード１nacに権限証明書Ｃを転送する。図１４の例では、ノードＩＤが450のノード１nacが転送先のノードとなる。この転送先のノードを担当ノードと称することとする。

担当ノードのアクセス制御部１１は、ステップＳＧ７にて、権限証明書Ｃを自身のＣＲＬ１５と複製保存用の（ｒ−１）台のノード１nacのＣＲＬ１５に登録する。担当ノードのアクセス制御部１１は、ステップＳＧ８にて、無効化完了を転送元の処理ノードに通知する。処理ノードのアクセス制御部１１は、ステップＳＧ９にて、無効化完了を無効化の手続きを行ったユーザ２に通知する。

図１５において、ステップＳＧ７で、担当ノードは（ｒ−１）回の通信を行って近傍のノード１nacのＣＲＬ１５に権限証明書Ｃの複製を保存させているため、処理ノードがステップＳＧ９でユーザ２に無効化完了を通知した時点では、ｒ台のノード１nacがＣＲＬ１５の構成情報（権限証明書Ｃ）を保持することが保証されている。これによって、同時に（ｒ−１）台のノード１nacが故障したとしても、ＣＲＬ１５のデータは損失することがない。

図１６を用いて、検証手順ＳＦのステップＳＦ２である権限証明書Ｃの無効化の確認手順ＳＨの具体的手順について説明する。図１６に示す確認手順ＳＨは、一実施形態の分散アクセス制御方法の一部である権限証明書Ｃの無効化の確認方法であり、一実施形態の分散アクセス制御プログラムで実行させるステップの一部である権限証明書Ｃの無効化の確認ステップである。ここでも、権限証明書Ｃの無効化を確認するノード１nacを処理ノードと称することとする。

図１６において、処理ノードのアクセス制御部１１は、ステップＳＨ１にて権限証明書Ｃのハッシュ値を求める。権限証明書Ｃのハッシュ値の求め方については後述する。処理ノードのアクセス制御部１１は、ステップＳＨ２にて、権限証明書Ｃのハッシュ値から、複製を含めて対応するＣＲＬ１５を保持しているノード１nacを求める。ＣＲＬ１５を保持しているノード１nacを保持ノードと称することとする。

処理ノードのアクセス制御部１１は、ステップＳＨ３にて、保持ノードのうち、接続可能な任意の１台に対して権限証明書Ｃの証明書ＩＤを送る。保持ノードのアクセス制御部１１は、ステップＳＨ４にて、送られてきた証明書ＩＤに一致する権限証明書ＣがＣＲＬ１５に登録されているか否かを確認して、確認結果を処理ノードに送る。登録されていれば（YES）、処理ノードのアクセス制御部１１は、無効化されていることを処理ノードに通知して終了する。登録されていなければ（NO）、処理ノードのアクセス制御部１１は、無効化されていないことを処理ノードに通知して終了する。

以上の権限証明書Ｃの無効化手順ＳＧ及び無効化確認手順ＳＨによって、どのノード１nacからであっても任意の権限証明書Ｃを無効化することができ、無効化されているか否かを確認することができる。権限証明書Ｃの検証時には、検証の対象である権限証明書Ｃに加えて、連鎖証明書リストＣＣＬに含まれている証明書ＩＤの権限証明書Ｃが無効化されているか否かを確認する。従って、図１６の確認手順ＳＨは、連鎖する権限証明書Ｃの数だけ繰り返されることとなる。このとき、同じノード１nacに対してＣＲＬ１５を参照して複数の権限証明書Ｃの無効化を確認する際には、複数の権限証明書Ｃをまとめて確認することにより、通信回数を少なくすることが好ましい。

図１６のステップＳＨ３では、保持ノードのうち、接続可能な任意の１台に対して権限証明書Ｃの証明書ＩＤを送ればよい。同時に（ｒ−１）台のノード１nacが故障したとしても接続可能なノード１nacが１台は存在することになり、ステップＳＨ４で無効化を確認することが可能となる。

更新した権限証明書ＣのＣＵＬ１６への登録及び分散化の手順については、特に図示しないが、図１５で説明した無効化した権限証明書ＣのＣＲＬ１５への登録及び分散化の手順とほぼ同様である。但し、次の点で相違する。ＣＵＬ１６への登録及び分散化の手順では、図１５のステップＳＧ７にて、図１０で説明したように、更新前の権限証明書Ｃの証明書ＩＤを有する最新の権限証明書Ｃ’を登録する。

権限証明書Ｃの更新の確認手順についても、特に図示しないが、図１６で説明した権限証明書Ｃの無効化の確認手順ＳＨとほぼ同様である。但し、次の点で相違する。権限証明書Ｃの更新の確認手順では、ステップＳＨ４で送られてきた証明書ＩＤに一致する権限証明書ＣがＣＵＬ１６に登録されていれば、ステップＳＨ５で最新の権限証明書Ｃ’を処理ノードに返送する。

ところで、権限証明書Ｃのハッシュ値を求める方法は種々考えられ、例えば次の方法ａ，ｂである。
方法ａ：ハッシュ値を求める対象の権限証明書Ｃの証明書ＩＤをハッシュ化する。
方法ｂ：ハッシュ値を求める対象の権限証明書Ｃの連鎖証明書リストＣＣＬに記載されている権限証明書Ｃのルートを順番に並べる。そして、先頭であるルート証明書からＬ番目の権限証明書Ｃの証明書ＩＤをハッシュ化する。但し、連鎖証明書リストＣＣＬに記載されている権限証明書Ｃの長さがＬより小さい場合には、ハッシュ値を求める対象の権限証明書Ｃの証明書ＩＤをハッシュ化する。この場合は方法ａと同じとなる。

図９のように権限証明書Ｃ_Ａ，Ｃ_Ｂ，Ｃ_Ｃ，Ｃ_Ｄと連鎖しており、権限証明書Ｃ_Ｂ，Ｃ_Ｃ，Ｃ_Ｄをそれぞれ無効化してＣＲＬ１５に登録する際に、方法ｂを採用した場合について説明する。Ｌを例えば２とすると、権限証明書Ｃ_Ｂ〜Ｃ_Ｄは全て同じノード１nacのＣＲＬ１５に登録されることになる。権限証明書Ｃ_Ａ〜Ｃ_Ｄの全てを無効化する場合で同様にＬを２とすると、権限証明書Ｃ_Ｂ〜Ｃ_Ｄは全て同じノード１nacのＣＲＬ１５に登録され、権限証明書Ｃ_Ａは権限証明書Ｃ_Ｂ〜Ｃ_Ｄとは異なるノード１nacのＣＲＬ１５に登録されることになる。Ｌを１とすれば、権限証明書Ｃ_Ａ〜Ｃ_Ｄは全て同じノード１nacのＣＲＬ１５に登録される。

方法ａでは全ての権限証明書Ｃに対して偏りのないハッシュ値を得ることができるので、無効化した権限証明書Ｃは分散アクセス制御機構１０acを構成する複数のノード１nacのＣＲＬ１５に偏りなく分散されることになる。方法ａは、偏りのない分散を実現しようとする場合には好ましい方法である。

一方、方法ｂでは特定の条件でハッシュ値に偏りが発生する。Ｌ回以上の委譲によって発行された権限証明書Ｃは、Ｌ回目の委譲で委譲元の権限証明書Ｃが同じであれば必ず同じハッシュ値となる。従って、Ｌ回目以降の委譲によって発行された権限証明書Ｃは、無効化された場合、同一のノード１nacのＣＲＬ１５に登録される。上述した無効化確認手順ＳＨで連鎖した権限証明書Ｃの無効化を確認する際、方法ｂでは、権限証明書Ｃの連鎖がいかなる長さであっても、たかだかＬ台のノード１nacのＣＲＬ１５を参照すればよいことになる。方法ｂは、クライアント３が通信するノード１nac（処理ノード）以外のノード１nacとの通信回数（通信コスト）を少なくしようとする場合には好ましい方法である。

さらに、次のような工夫を施すと、権限証明書Ｃを検証する際の通信コストをゼロにすることが可能である。方法ｂを採用し、Ｌを２とする。図１４で説明したように無効化した権限証明書Ｃを複数のノード１nacに分散させる際に、ルート証明書のみは冗長数ｒを分散アクセス制御機構１０acを構成するノード１nacの数ｎとする。即ち、ルート証明書を無効化する場合には、ルート証明書を分散アクセス制御機構１０acの全てのノード１nacのＣＲＬ１５に登録しておく。このルート証明書の無効化時には（ｎ−１）回の通信が発生する。

前述のように、クライアント３が分散アクセス制御機構１０acに対してアクセスすると、クライアント３からのアクセスは１つのノード１nacに割り振られることになる。この際に、クライアント３からのアクセスを、クライアント３が利用する権限証明書Ｃを含む連鎖した権限証明書Ｃのうち、２番目の権限証明書Ｃを登録するＣＲＬ１５を有するノード１nacに割り振るようにする。２番目の権限証明書Ｃを登録するＣＲＬ１５とは、２番目の権限証明書Ｃが無効化されていない時点では、２番目の権限証明書Ｃが無効化された際に登録することになるＣＲＬ１５ということである。

このような工夫を施すことによって、権限証明書Ｃの検証手順ＳＦにおいて、連鎖証明書リストＣＣＬに含まれる全ての権限証明書Ｃが無効化されているか否かを確認する際に、クライアント３からのアクセスが割り振られたノード１nacのみで確認することができる。よって、他のノード１nacと通信する必要がなく、権限証明書Ｃを検証する際の通信コストはゼロとなる。

次に、本実施形態の分散アクセス制御機構１０acの安全性をさらに向上させるための対策について説明する。分散アクセス制御機構１０acの安全性を向上させるための対策１として、それぞれのノード１nacは、保持するノード秘密鍵Knprとノード公開鍵Knpbとの鍵ペアを定期的に更新することが好ましい。更新前の古いノード秘密鍵Knprは破棄されるので、安全性が向上する。

なお、仮に攻撃者がノード１nacに侵入したとすると、進入時期が特定できれば、ノード１nacは、進入した期間のエントリに対してのみ、ノード公開鍵リストの漏洩フラグを立てればよい。これによって、無効化の対象となる権限証明書Ｃを限定的とすることができ、ノード秘密鍵Knprの漏洩が疑われる事態が発生した場合の影響を最小限にとどめることが可能となる。

分散アクセス制御機構１０acの安全性を向上させるための対策２として、権限証明書Ｃを発行時や更新時に、複数であるｍ台のノード１nacが同様に確認して、権限証明書Ｃにｍ個の発行者ノードＩＤと署名を含ませることが好ましい。それぞれのノード１nacが権限証明書Ｃを検証する際に、権限証明書Ｃの検証手順ＳＦにおいて、ｍ個の署名が含まれていて全ての署名が妥当である場合に権限証明書Ｃを有効とする。このようにすれば、権限証明書Ｃを発行や更新のコストはｍ倍になるが、ｍ台のノード１nacからノード秘密鍵Knprが漏洩しない限り、不正なアクセスはできない。

（ｍ−１）台以下のノード１nacからノード秘密鍵Knprの漏洩であれば、漏洩が発覚した後も既存の権限証明書Ｃを無効化する必要はない。ｍ台以上のノード１nacからノード秘密鍵Knprが漏洩したことが発覚した場合であっても、全て漏洩したノード秘密鍵Knprでｍ個の署名がされている権限証明書Ｃ以外は権限証明書Ｃを無効化する必要はない。従って、対策２でも、ノード秘密鍵Knprの漏洩が疑われる事態が発生した場合の影響を最小限にとどめることが可能となる。

対策１と対策２とを組み合わせることはさらに好ましい。ｍ台のノード１nacの署名はほぼ同時に行われるので、同じ時間帯のノード秘密鍵Knprが用いられる。攻撃者が鍵ペアの更新周期をまたいで少なくとも２つの異なる時間帯でノード秘密鍵Knprを入手したとしても、権限証明書Ｃの検証が失敗することになる。ノード１nacごとに鍵ペアの更新周期や更新のタイミングをずらすことにより、攻撃を成功しにくくすることが可能となる。

本発明は以上説明した本実施形態に限定されることはなく、本発明の要旨を逸脱しない範囲において種々変更可能である。分散アクセス制御機構１０acを構成するノード１nacに分散アクセス制御プログラムを搭載するに際し、分散アクセス制御プログラムをノード１nacに対して配信してもよい。分散アクセス制御プログラムを記録媒体に記録して、それぞれのノード１nacにおいて、記録媒体から分散アクセス制御プログラムをインストールしてもよい。

ところで、分散ファイルシステム１０に、リソースをどのように記憶させるか、リソースをどのように分散させるかは本発明とは直接的には関係せず、リソースの記憶のさせ方及び分散のさせ方は任意である。

本発明は、分散ファイルシステム１０に限定されず、所定の処理を分散して実行させる任意の分散システムに用いることができる。

１ｎ，１nac ノード
２，２ａ，２ｂ，２ｃ ユーザ
３，３ａ，３ｂ，３ｃ クライアント
１０ 分散ファイルシステム（分散システム，サーバ）
１０ac 分散アクセス制御機構
１１ アクセス制御部
１２ ノードＩＤ
１３ ノード経路表
１４ ノード公開鍵リスト
１５ 証明書失効リスト（ＣＲＬ）
１６ 証明書更新リスト（ＣＵＬ）
Ｃ，Ｃ_Ａ，Ｃ_Ｂ，Ｃ_Ｃ 権限証明書
ＣＣＬ 連鎖証明書リスト
Knpr ノード秘密鍵
Knpb ノード公開鍵

Claims (2)

1. クライアントからサーバにアクセスするに際し、複数のノードを備えて構成される分散アクセス制御機構における前記複数のノードのうちのいずれかのノードを介してサーバにアクセスし、
   前記クライアントから前記サーバに対して操作要求を行う際に、前記操作要求に権限証明書を添えて前記いずれかのノードに送信し、
   前記権限証明書は、ルート証明書を始端として権限が順次直列的に１または複数の委譲先に委譲されることによって発行され、前記ルート証明書から、最後の委譲先の直前に位置する前記最後の委譲先の委譲元の権限証明書までの全ての委譲元の権限証明書を特定する特定情報を示す連鎖証明書リストを含み、
   前記複数のノードの全てのノードは、いずれかのルート証明書が無効化された場合、無効化されたルート証明書を登録し、
   所定のルート証明書を委譲元として発行された権限証明書以降のいずれかの権限証明書が無効化された場合、前記所定のルート証明書を委譲元として発行された権限証明書以降のいずれの権限証明書であっても、無効化された権限証明書を、前記所定のルート証明書を委譲元として発行された権限証明書の特定情報に基づいて決定した特定のノードに登録し、
   前記クライアントから前記操作要求に前記権限証明書を添えて前記いずれかのノードに送信する際に、前記特定のノードにアクセスさせる
   ことを特徴とする分散アクセス制御方法。
2. 前記複数のノードにはそれぞれ固有のノードＩＤが設定され、
   それぞれの権限証明書は前記特定情報として証明書ＩＤを有し、
   前記所定のルート証明書を委譲元として発行された権限証明書の証明書ＩＤをハッシュ化したハッシュ値に基づいて選択したノードＩＤを有するノードを前記特定のノードとして選択する
   ことを特徴とする請求項１記載の分散アクセス制御方法。

Images