(57)【要約】      （修正有）【課題】暗号鍵の流出に伴うリスク低減の観点、あるいは、暗号処理に伴う負荷分散の観点から適切な暗号鍵割り当てが可能なデータ管理システムを提供する。【解決手段】データ管理システム６は、データベースにおけるテーブルを構成する特定の列に含まれるデータに基づいて、上記テーブルを複数のパーティションに分割して管理可能なデータ管理部３３０１と、上記パーティションごとに、個別の暗号鍵を関連付けて保持する暗号鍵管理部３３０２と、上記暗号鍵を用いて、前記パーティションに含まれるデータに関する暗号処理を実行する暗号処理部３３０３と、を備える。【選択図】図３３
2017130705.tif 000002
【特許請求の範囲】
【請求項１】
データベースにおけるテーブルを構成する特定の列に含まれるデータに基づいて、前記テーブルを複数のパーティションに分割して管理可能なデータ管理手段と、
前記パーティションごとに、個別の暗号鍵を関連付けて保持する暗号鍵管理手段と、
前記暗号鍵を用いて、前記パーティションに含まれるデータに関する暗号処理を実行する暗号処理手段と、
を備えるデータ管理システム。
【請求項２】
前記データ管理手段は、前記テーブルを構成する特定の列に含まれるデータである第１のデータの値に基づいて、前記第１のデータと、前記第１のデータに関連付けされた１以上の第２のデータと、を含むデータセットが含まれる前記パーティションを特定し、
前記暗号処理手段は、前記データセットが含まれる前記パーティションに関連付けされた前記暗号鍵を用いて、前記第２のデータに関する暗号処理を実行する
請求項１に記載のデータ管理システム。
【請求項３】
前記暗号鍵管理手段は、前記パーティションごとに関連付けされた前記暗号鍵を、それぞれ個別に更新し、
前記暗号処理手段は、前記暗号鍵が更新される際、当該暗号鍵が関連付けされた前記パーティションに含まれる前記データセットを更新前の前記暗号鍵を用いて復号し、当該データセットを更新後の前記暗号鍵を用いて暗号化する、
請求項２に記載のデータ管理システム。
【請求項４】
前記暗号鍵管理手段は、前記パーティションごとに関連付けされた前記暗号鍵に個別に設定された更新期限に基づいて、前記暗号鍵を更新する
請求項３に記載のデータ管理システム。
【請求項５】
前記データ管理手段は、前記パーティションの少なくとも一部を、更に１以上のパーティションに再分割可能であり、
前記暗号鍵管理手段は、再分割前の前記パーティションに対して関連付けされた前記暗号鍵を、前記再分割された１以上のパーティションに関連付けて保持する
請求項２乃至請求項４のいずれかに記載のデータ管理システム。
【請求項６】
前記暗号鍵管理手段は、前記再分割された１以上のパーティションに関連付けされた前記暗号鍵に対して、異なる更新期限を設定し、当該設定された更新期限に基づいて前記暗号鍵を更新する
請求項５に記載のデータ管理システム。
【請求項７】
前記データ管理手段は、前記テーブルに対して新たな前記データセットを登録する要求を表す登録要求と、前記テーブルに登録された前記データセットを取得する要求を表す取得要求と、の少なくとも一方を受け付け可能であり、
前記暗号処理手段は、
前記データ管理手段が、前記登録要求に基づいて前記テーブルに新たな前記データセットを登録する際、当該データセットにおける前記第２のデータの少なくとも一部を、当該データセットが含まれる前記パーティションに関連付けされた前記暗号鍵を用いて暗号化し、
前記データ管理手段が、前記取得要求に基づいて前記テーブルに登録された前記データセットを取得する際、当該データセットにおける前記第２のデータの少なくとも一部を、当該データセットが含まれる前記パーティションに関連付けされた前記暗号鍵を用いて復号する
請求項２乃至請求項６のいずれかに記載のデータ管理システム。
【請求項８】
前記暗号鍵管理手段は、前記パーティションごとに、暗号処理の強度を表す暗号化レベルに応じて１以上の異なる前記暗号鍵を関連付けて保持し、
前記暗号処理手段は、前記データセットが含まれる前記パーティションの関連付けされた前記暗号鍵のうち、前記データセットに関連付けされた前記暗号化レベルに応じた異なる前記暗号鍵を用いて、前記データセットに関する暗号処理を実行する
請求項２乃至請求項７のいずれかに記載のデータ管理システム。
【請求項９】
前記暗号鍵管理手段は、前記パーティションごとに、暗号処理の強度を表す暗号化レベルに応じて１以上の異なる前記暗号鍵を関連付けて保持し、
前記暗号処理手段は、
前記データ管理手段が、前記登録要求に基づいて前記テーブルに新たな前記データセットを登録する際、当該登録される前記データセットに含まれる前記第２のデータの少なくとも一部を、当該データセットが割り当てられる前記パーティションに関連付けされた前記暗号鍵のうち、前記登録要求に含まれる前記暗号化レベルに応じた前記暗号鍵を用いて暗号化し、
前記データ管理手段が、前記取得要求に基づいて前記テーブルに登録された前記データセットを取得する際、当該取得される前記データセットに含まれる前記第２のデータの少なくとも一部を、当該データセットが割り当てられる前記パーティションに関連付けされた前記暗号鍵のうち、当該データセットに含まれる前記暗号化レベルに応じた前記暗号鍵を用いて復号する
請求項７に記載のデータ管理システム。
【請求項１０】
前記データ管理手段は、
前記第１のデータに対して所定の演算を適用することにより求められるデータの値がとり得る範囲を分割した結果に基づいて、前記テーブルを複数の前記パーティションに分割し、
前記テーブルに前記データセットを登録する際、当該登録される前記データセットにおける前記第１のデータに対して前記所定の演算を適用することにより求めたデータの値に基づいて、当該登録される前記データセットが割り当てられる前記パーティションを特定し、
前記テーブルに登録された前記データセットを取得する際、当該登録された前記データセットにおける前記第１のデータに対して前記所定の演算を適用することにより求めたデータの値に基づいて、当該登録された前記データセットが割り当てられた前記パーティションを特定する
請求項７乃至請求項９のいずれかに記載のデータ管理システム。
【請求項１１】
前記所定の演算は、前記第１のデータのハッシュ値を算出する演算であり、
前記データ管理手段は、前記第１のデータのハッシュ値がとり得る範囲を均等又は略均等に分割することにより、当該分割されたハッシュ値の範囲をそれぞれ前記パーティションとして分割し、
前記テーブルに前記データセットを登録する際、当該登録される前記データセットにおける前記第１のデータのハッシュ値を含む前記パーティションに、当該登録される前記データセットを割り当て、
前記テーブルに登録された前記データセットを取得する際、当該登録された前記データセットにおける前記第１のデータのハッシュ値が含まれる前記パーティションから、当該登録された前記データセットを取得する
請求項１０に記載のデータ管理システム。
【請求項１２】
前記データ管理手段は、特定の前記パーティションに設定されたハッシュ値の範囲を、更に、均等又は略均等に分割し、当該分割されたハッシュ値の範囲を当それぞれ新たなパーティションとして設定することにより、特定の前記パーティションを、複数のパーティションに再分割する
請求項１１に記載のデータ管理システム。
【請求項１３】
前記データベースは、前記第１のデータであるキーと、１以上の前記第２のデータであるバリューとが関連付けされたペアを保持するＫＶＳ（Ｋｅｙ  Ｖａｌｕｅ  Ｓｔｏｒｅ）であり、
前記テーブルを構成する特定の列は、前記テーブルにおいて前記キーにより構成される列であり、
前記データ管理手段は、前記キーの値に基づいて、当該キーを含む前記データセットが含まれる前記パーティションを特定する
請求項１０乃至請求項１１のいずれかに記載のデータ管理システム。
【請求項１４】
関係データベースに含まれる関係データベーステーブルごとに個別の前記暗号化レベルを関連付けて保持し、前記関係データベースに対するＳＱＬによるクエリを前記データベースに対する前記登録要求及び前記取得要求の少なくとも一方に変換して前記データ管理手段に提供するＳＱＬ処理手段を更に備え、
前記データ管理手段は、前記ＳＱＬ処理手段により変換された前記登録要求又は前記取得要求に関する前記データセットが含まれる前記パーティションを特定するとともに、前記クエリにより指定された前記関係データベーステーブルを特定し、
前記暗号処理手段は、当該特定された前記パーティションに関連付けされた前記暗号鍵のうち、前記特定された前記関係データベーステーブルに関連付けされた前記暗号化レベルに応じた前記暗号鍵を用いて、当該データセットに関する暗号処理を実行する
請求項９に記載のデータ管理システム。
【請求項１５】
関係データベースに含まれる関係データベーステーブルを構成するカラムごとに個別の前記暗号化レベルを関連付けて保持し、前記関係データベースに対するＳＱＬによるクエリを前記データベースに対する前記登録要求及び前記取得要求の少なくとも一方に変換して前記データ管理手段に提供するＳＱＬ処理手段を更に備え、
前記データ管理手段は、前記ＳＱＬ処理手段により変換された前記登録要求又は前記取得要求に関する前記データセットが含まれる前記パーティションを特定するとともに、当該データセットに含まれる前記第２のデータを構成するデータが配置される、前記関係データベーステーブルにおけるカラムを特定し、
前記暗号処理手段は、当該特定された前記パーティションに関連付けされた前記暗号鍵のうち、前記特定した前記カラムに関連付けされた前記暗号化レベルに応じた前記暗号鍵を用いて、前記第２のデータを構成するデータに関する暗号処理を実行する
請求項９に記載のデータ管理システム。
【請求項１６】
関係データベースに含まれる関係データベーステーブルを論理的に分割したデータベースパーティションごとに個別の前記暗号化レベルを関連付けて保持し、前記関係データベースに対するＳＱＬによるクエリを前記データベースに対する前記登録要求及び前記取得要求の少なくとも一方に変換して前記データ管理手段に提供するＳＱＬ処理手段を更に備え、
前記データ管理手段は、前記ＳＱＬ処理手段により変換された前記登録要求又は前記取得要求に関する前記データセットが含まれる前記パーティションを特定するとともに、当該データセットに含まれる前記第２のデータを構成するデータが含まれるデータベースパーティションを特定し、
前記暗号処理手段は、当該特定された前記パーティションに関連付けされた前記暗号鍵のうち、前記特定した前記データベースパーティションに関連付けされた前記暗号化レベルに応じた前記暗号鍵を用いて、前記第２のデータを構成するデータに関する暗号処理を実行する
請求項９に記載のデータ管理システム。
【請求項１７】
データベースにおけるテーブルを構成する特定の列に含まれるデータに基づいて、前記テーブルを複数のパーティションに分割し、
前記パーティションごとに関連付けされた個別の暗号鍵を用いて、前記パーティションに含まれるデータに関する暗号処理を実行する
データ管理方法。
【請求項１８】
データベースにおけるテーブルを構成する特定の列に含まれるデータに基づいて、前記テーブルを複数のパーティションに分割する処理と、
前記パーティションごとに関連付けされた個別の暗号鍵を用いて、前記パーティションに含まれるデータに関する暗号処理を実行する処理と、をコンピュータに実行させる
コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データを保護可能なデータ管理システム等に関する。
【背景技術】
【０００２】
近年、各種データを管理するデータ管理システム（例えば、各種データベース等）に保持（格納）されるデータが増大するとともに、係るデータの重要性が増している。このような状況において、データ管理システムは、格納されたデータ保護することが求められる。データを保護する方法の一つとして、データ管理システムに格納されるデータを暗号化する方法が知られている。
【０００３】
データ管理システムに格納されるデータを共通の暗号鍵で暗号化すると、当該共通の暗号鍵が漏洩した場合のリスクが高い。また、共通の暗号鍵を変更する際、格納されたデータの再暗号化に要する処理コストが大きい。これに対して、例えば、データベースを構成するテーブルごとに個別の暗号鍵を用いるデータベースシステムが知られている。
【０００４】
なお、データの保護に関連して、以下の技術が開示されている。
【０００５】
特許文献１は、暗号化された情報と、暗号鍵とがともに流出する可能性を低減すべく、情報を管理する情報管理サーバと、当該情報に対する暗号処理を実行する暗号処理サーバとを分離する技術を開示する。
【０００６】
特許文献２は、複数の仮想サーバを稼働するシステムにおいて、ユーザが利用する仮想ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）であるゲストＯＳごとに異なる暗号鍵を用いて、当該ゲストＯＳのデータを暗号化する技術を開示する。
【０００７】
特許文献３は、情報の送信先と当該情報を暗号化する暗号鍵とを関連付けて管理する暗号鍵管理システムを開示する。暗号鍵管理システムは、各送信先に対して、当該送信先に関連付けされた暗号鍵をマスターキーによって暗号化して送出ことにより、それぞれの業務システムごとに個別の暗号鍵を配布する。
【０００８】
特許文献４は、預託されたデータ（預託データ）を二次的に利用する二次的利用者に対して、預託者のポリシーに応じたアクセス制御を実行するデータ管理システムを開示する。当該データ管理システムは、第１の暗号鍵を用いて預託データを暗号化して管理するとともに、預託者のポリシーに応じて、当該データを第２の暗号鍵を用いて再暗号化して、二次利用者に提供する。
【０００９】
特許文献５は、ホームネットワークにおいて、利用者が設定した機器によりグループを形成し、当該グループ内で暗号化通信を実行するネットワーク機器を開示する。ネットワーク機器は、形成されたグループごとに個別の暗号鍵を用いて通信処理を実行することにより、グループ外の機器からの通信を排除する。
【００１０】
特許文献６は、個人情報を、単独では特定の個人を特定できない粒度の情報（部分個人情報）に分解して個人情報管理センタに登録するとともに、当該部分個人情報間の関連を個人情報提供者端末において管理する技術を開示する。
【００１１】
特許文献７は、ＯＳのカーネルと、ファイルシステムとの間に、アクセスコントロール機能を実装したセキュリティファイルシステム層を挿入する技術を開示する。特許文献７に開示された技術においては、ＯＳとは独立したアクセスコントローラが、セキュリティファイルシステム層におけるファイルアクセスを制御するとともに、ファイルに対する透過的な暗号化処理を実行する。
【００１２】
特許文献８は、データベース操作言語に含まれる機密情報を暗号化することで、データベースに格納される機密情報を透過的に暗号化する技術を開示する。特許文献８に開示された技術においては、クライアントとＤＢサーバとの間に介在する暗号処理ゲートウェイが、クライアントから受け付けた機密情報を暗号化してＤＢサーバに格納する。また、係る暗号処理ゲートウェイは、クライアントからの要求に応じて、ＤＢサーバに格納された機密情報を復号してクライアントに送信する。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２０１１−１６４９０７号公報
【特許文献２】特開２０１１−０４８６６１号公報
【特許文献３】特開２０１０−１４８０２２号公報
【特許文献４】特開２０１１−０１９１２９号公報
【特許文献５】特開２００４−２５４２７１号公報
【特許文献６】特開２００１−２６５７７１号公報
【特許文献７】国際公開第２００４／０３６３５０号
【特許文献８】米国特許出願公開第２００７／０２９４５３９号明細書
【発明の概要】
【発明が解決しようとする課題】
【００１４】
例えば、データ管理システムにおいて、データベースを構成するテーブルに格納されるデータのサイズ、量、あるいは機密度は、テーブルごとに異なる。即ち、テーブルごとに、暗号処理に伴うコスト、あるいは暗号鍵が漏洩した場合のリスクが異なる。よって、テーブルを単位（粒度）とした個別の暗号鍵割り当ては、暗号鍵の流出に伴うリスク低減の観点、あるいは、暗号処理に伴う負荷分散の観点から、必ずしも適切ではない場合がある。上記各文献に開示された技術は、いずれもこのような問題を解決可能な技術ではない。
【００１５】
本発明は、上記事情を鑑みてなされたものである。即ち、本発明は、データベースを適切な粒度に分割した部分領域ごとに個別の暗号処理を実行可能なデータ管理システムを提供することを、主たる目的の一つとする。
【課題を解決するための手段】
【００１６】
上記の目的を達成すべく、本発明の一態様に係るデータ管理システムは、以下の構成を備える。即ち、本発明の一態様に係るデータ管理システムは、データベースにおけるテーブルを構成する特定の列に含まれるデータに基づいて、上記テーブルを複数のパーティションに分割して管理可能なデータ管理部と、上記パーティションごとに、個別の暗号鍵を関連付けて保持する暗号鍵管理部と、上記暗号鍵を用いて、上記パーティションに含まれるデータに関する暗号処理を実行する暗号処理部と、を備える。
【００１７】
また、本発明の一態様に係るデータ管理方法は、データベースにおけるテーブルを構成する特定の列に含まれるデータに基づいて、上記テーブルを複数のパーティションに分割し、上記パーティションごとに関連付けされた個別の暗号鍵を用いて、上記パーティションに含まれるデータに関する暗号処理を実行する。
【００１８】
また、同目的は、上記構成を有するデータ管理システム、あるいは、データ管理方法を、コンピュータによって実現するコンピュータ・プログラム、及び、そのコンピュータ・プログラムが格納されている、コンピュータ読み取り可能な記録媒体等によっても達成される。
【発明の効果】
【００１９】
本発明によれば、データベースを適切な粒度に分割した部分領域ごとに個別の暗号処理を実行することが可能である。
【図面の簡単な説明】
【００２０】
【図１】図１は、ＫＶＳ（Ｋｅｙ−Ｖａｌｕｅ  Ｓｔｏｒｅ）とそのパーティション分割の具体例を表す説明図である。
【図２】図２は、本発明の第１の実施形態におけるデータ管理システムの機能的な構成を例示するブロック図である。
【図３】図３は、本発明の第１の実施形態におけるデータ管理システムを構成する構成要素の機能的な構成を例示するブロック図である。
【図４】図４は、本発明の第１の実施形態における、キャッシュされた暗号鍵の管理構造の具体例を示す説明図である。
【図５】図５は、本発明の第１の実施形態における、暗号鍵の管理構造の具体例を示す説明図である。
【図６】図６は、本発明の第１の実施形態における、認証処理の概要を説明する説明図である。
【図７】図７は、本発明の第１の実施形態における、認証処理の過程を示すシーケンス図である。
【図８】図８は、本発明の第１の実施形態における、データ取得（ＧＥＴ）処理の概要を例示する説明図である。
【図９Ａ】図９Ａは、本発明の第１の実施形態における、データ取得（ＧＥＴ）処理の過程（その１）を例示するシーケンス図である。
【図９Ｂ】図９Ｂは、本発明の第１の実施形態における、データ取得（ＧＥＴ）処理の過程（その２）を例示するシーケンス図である。
【図９Ｃ】図９Ｃは、本発明の第１の実施形態における、データ取得（ＧＥＴ）処理の過程（その３）を例示するシーケンス図である。
【図１０】図１０は、本発明の第１の実施形態における、キャッシュされた暗号鍵の有効期限を管理する処理を例示するフローチャートである。
【図１１】図１１は、本発明の第１の実施形態における、データ格納（ＰＵＴ）処理の概要を例示する説明図である。
【図１２】図１２は、本発明の第１の実施形態における、データ格納（ＰＵＴ）処理の過程を例示するシーケンス図である。
【図１３】図１３は、本発明の第１の実施形態における、暗号鍵の更新処理の概要を例示する説明図である。
【図１４】図１４は、本発明の第１の実施形態における、暗号鍵の更新処理の過程を例示するシーケンス図である。
【図１５】図１５は、本発明の第２の実施形態におけるデータ管理システムの機能的な構成を例示するブロック図である。
【図１６】図１６は、本発明の第２に実施形態におけるデータ管理システムに格納されるデータセットの構造を例示する説明図である。
【図１７】図１７は、本発明の第２の実施形態における、暗号鍵の管理構造の具体例を示す説明図である。
【図１８】図１８は、本発明の第２の実施形態における、キャッシュされた暗号鍵の管理構造の具体例を示す説明図である。
【図１９Ａ】図１９は、本発明の第３の実施形態におけるデータ管理システムの機能的な構成を例示するブロック図である。
【図１９Ｂ】図１９は、本発明の第３の実施形態におけるデータ管理システムの他の機能的な構成を例示するブロック図である。
【図２０Ａ】図２０Ａは、本発明の第３の実施形態におけるデータ管理システムに格納されるデータセットの構造の具体例を示す説明図である。
【図２０Ｂ】図２０Ｂは、本発明の第３の実施形態におけるデータ管理システムに格納されるデータセットの構造の他の具体例を示す説明図である。
【図２１】図２１は、本発明の第３の実施形態におけるデータ管理システムが提供するデータベースの具体例を示す説明図である。
【図２２】図２２は、本発明の第３の実施形態におけるデータ管理システムが提供するデータベースのスキーマを表す情報を例示する説明図である。
【図２３Ａ】図２３Ａは、本発明の第３の実施形態におけるデータ管理システムに格納されたデータセットの具体例を示す説明図である。
【図２３Ｂ】図２３Ｂは、本発明の第３の実施形態におけるデータ管理システムに格納されたデータセットの他の具体例を示す説明図である。
【図２４】図２４は、ＳＱＬにより記述されたクエリの具体例を示す説明図である。
【図２５】図２５は、ＳＱＬにより記述されたクエリの他の具体例を示す説明図である。
【図２６】図２６は、本発明の第３の実施形態の変形例におけるデータ管理システムの機能的な構成を例示するブロック図である。
【図２７】図２７は、本発明の第３の実施形態の変形例において、データベースのカラムごとに暗号化レベルが設定された場合のスキーマを表す情報を例示する説明図である。
【図２８】図２８は、本発明の第３の実施形態の変形例において、データベースを分割したパーティションごとに暗号化レベルが設定された場合のスキーマを表す情報を例示する説明図である。
【図２９】図２９は、本発明の第４の実施形態におけるデータ管理システム４の機能的な構成を例示するブロック図である。
【図３０】図３０は、再分割されたＫＶＳのパーティション構成を例示する説明図である。
【図３１】図３１は、再分割されたＫＶＳのパーティションと、暗号鍵との関連付けの具体例を示す説明図である。
【図３２】図３２は、本発明の第５の実施形態におけるデータ管理システムの機能的な構成を例示するブロック図である。
【図３３】図３３は、本発明の第６の実施形態におけるデータ管理システムの機能的な構成を例示するブロック図である。
【図３４】図３４は、本発明の各実施形態を実現可能な情報処理装置のハードウェア構成を例示する図面である。
【発明を実施するための形態】
【００２１】
以下、本発明を実施可能な形態について図面を参照して詳細に説明する。以下の各実施形態に記載されている構成は例示であり、本発明の技術範囲はそれらには限定されない。
【００２２】
以下の各実施形態において説明するデータ管理システムは、単体の装置（物理的あるいは仮想的な装置）を用いて実現されてもよい。また、係るデータ管理システムは、複数の装置（例えば、物理的あるいは仮想的な情報処理装置等）を用いて実現されてもよい。この場合、データ管理システムを構成する各構成要素は、一つ以上の装置を用いて実現されてもよい。また、データ管理システムを構成する複数の構成要素が、一つの装置を用いて実現されてもよい。なお、データ管理システムを構成する構成要素の各装置に対する割り当ては、適宜定められてよい。データ管理システムを構成する複数の装置の間は、有線、無線、又はそれらを適宜組み合わせた通信ネットワーク（通信回線）により通信可能に接続されてもよい。なお、係る通信ネットワークは、物理的な通信ネットワークであってもよく、仮想的な通信ネットワークであってもよい。
【００２３】
＜第１の実施形態＞
本発明の第１の実施形態について、図面を参照して具体的に説明する。
【００２４】
本実施形態においては、具体例として、データ管理システム１（図２）が、ＫＶＳ（Ｋｅｙ−Ｖａｌｕｅ  Ｓｔｏｒｅ）方式のデータストア（以下、単に「ＫＶＳ」と称する）を用いてデータを管理する構成について説明する。この場合、データ管理システム１は、ＫＶＳを用いてデータベースを構築する。ただし、以下の説明は、本実施形態におけるデータ管理システム１を限定するものではなく、データ管理システム１は他のデータストア（例えば、ＲＤＢ（Ｒｅｌａｔｉｏｎａｌ  Ｄａｔａｂａｓｅ）等）を用いて、データを管理してもよい。
【００２５】
まず、データ管理システム１におけるデータ管理方法について概要を説明する。
【００２６】
データ管理システム１は、上記したように、当該データ管理システム１に格納されるデータを、ＫＶＳを用いて管理する。ＫＶＳは、データ（Ｖａｌｕｅ）と、当該データを識別可能な識別情報であるキー（Ｋｅｙ）とを関連付けた（紐づけた）ペアを保持可能な、データの管理方式である。以下において、キーを「第１のデータ」と称する場合がある。また、当該キーに関連付けされた保データを、「第２のデータ」、あるいは、「バリュー」と称する場合がある。また、キーと、バリューとのペアを、「データセット」と称する場合がある。係るＫＶＳは、例えば、キーの列と、バリューの列とを含むテーブル（表）を用いて概念的に表すことも可能である。また、係るＫＶＳは、例えば、キーと、データとが関連付けされた連想配列（マップ）を用いて概念的に表すことも可能である。なお、ＫＶＳを概念的に表すデータ構造は上記に限定されず、適宜選択されてよい。
【００２７】
以下、ＫＶＳに対して、あるデータセットを格納（登録）する操作を、「ＰＵＴ」（あるいは「ＰＵＴ」処理）と称する。また、ＫＶＳから特定のキーを指定して当該キーに関連付けされたバリューを取得する操作を「ＧＥＴ」（あるいは「ＧＥＴ処理」）と称する。例えば、テーブルを用いてＫＶＳを表す場合、ＧＥＴ処理は、キー列を指定して、テーブルに登録されたデータセットを取得する処理に相当し、ＰＵＴ処理は、テーブルに対してデータセットを登録する処理に相当する。例えば、連想配列を用いてＫＶＳを表す場合、ＧＥＴ処理は、あるキーを指定して、連想配列に登録されたデータセットを取得する処理に相当し、ＰＵＴ処理は連想配列にデータセットを登録する処理に相当する。
【００２８】
また、データ管理システム１は、データを保持するＫＶＳを、１以上のデータセットを含む複数の部分的な領域に分割して管理する。以下、係る部分的な領域を、パーティションと称する。この場合、データ管理システム１が管理するＫＶＳは、複数のパーティションから構成され、それぞれのパーティションには、１以上のデータセットが割り当てられる。
【００２９】
具体的には、データ管理システム１は、ＫＶＳに格納されるデータセットのキー（より具体的には、キーから算出される値）に基づいて、ＫＶＳを複数のパーティションに分割する。そして、データ管理システム１は、あるデータセットのキーに基づいて、当該データセットをいずれかのパーティションに割り当てる。例えば、テーブルを用いてＫＶＳを表す場合、データ管理システム１は、ＫＶＳを表すテーブルを、特定の列（この場合はキー列）に含まれるデータ（キー）、あるは、当該データを用いて算出した値に基づいて、複数のパーティションに分割してもよい。例えば、連想配列を用いてＫＶＳを表す場合、データ管理システム１は、係る連想配列を、キーの値、あるいはキーを用いて算出した値を用いて、複数の部分に分割してもよい。
【００３０】
データ管理システム１は、係るパーティションを構成する方法として、例えば、コンシステント・ハッシング（Ｃｏｎｓｉｓｔｅｎｔ  Ｈａｓｈｉｎｇ）法を採用してもよい（例えば、下記参考文献１）。データ管理システム１は、上記に限定されず、他の適当な分割方法を採用してもよい。係る他の分割方法は、例えば、ＫＶＳのキー値の範囲ごとにパーティションを分割する方法であってもよい。また、係る他の分割方法は、例えば、ＫＶＳのキー値が、ある値の集合（例えば、予め定められた地域名、商品名のリスト等）に含まれるか否かに基づいて、パーティションを分割する方法であってもよい。また、係る他の分割方法は、コンシステント・ハッシングとは異なる方法で、キーの値から求めたハッシュ値に基づいてパーティションを分割する方法であってもよい。
【００３１】
［参考文献１］
Ｇｉｕｓｅｐｐｅ  ＤｅＣａｎｄｉａ，  Ｄｅｎｉｚ  Ｈａｓｔｏｒｕｎ，  Ｍａｄａｎ  Ｊａｍｐａｎｉ，  Ｇｕｎａｖａｒｄｈａｎ  Ｋａｋｕｌａｐａｔｉ，Ａｖｉｎａｓｈ  Ｌａｋｓｈｍａｎ，  Ａｌｅｘ  Ｐｉｌｃｈｉｎ，  Ｓｗａｍｉｎａｔｈａｎ  Ｓｉｖａｓｕｂｒａｍａｎｉａｎ，  Ｐｅｔｅｒ  Ｖｏｓｓｈａｌｌ，ａｎｄ  Ｗｅｒｎｅｒ  Ｖｏｇｅｌｓ，  ”Ｄｙｎａｍｏ：  Ａｍａｚｏｎ’ｓ  Ｈｉｇｈｌｙ  Ａｖａｉｌａｂｌｅ  Ｋｅｙ−ｖａｌｕｅ  Ｓｔｏｒｅ”，  Ｐｒｏｃｅｅｄｉｎｇ  ＳＯＳＰ  ’０７  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｗｅｎｔｙ−ｆｉｒｓｔ  ＡＣＭ  ＳＩＧＯＰＳ  ｓｙｍｐｏｓｉｕｍ  ｏｎ  Ｏｐｅｒａｔｉｎｇ  ｓｙｓｔｅｍｓ  ｐｒｉｎｃｉｐｌｅｓ，  ２００７年１０月１４日，  ｐ．ｐ．  ２０５−２２０。
【００３２】
以下、本実施形態においては、データ管理システム１が、コンシステント・ハッシング法を用いてパーティションを構成することを想定する。以下、係るパーティション構成について概要を説明する。図１は、ＫＶＳ及びそのパーティション構成の具体例を概念的に示す説明図である。なお、図１は説明を容易にするための一つの具体例であり、本実施形態はこれには限定されない。
【００３３】
データ管理システム１は、あるハッシュ関数Ｈの出力を、円環（リング）状の配置空間（図１における「配置リング」に相当）として扱う。係る配置空間においては、ハッシュ関数Ｈの最大値と、ハッシュ関数Ｈの最小値とが隣接する。
【００３４】
データ管理システム１は、配置リング上にノード（例えば、図１に例示する「Ｎ１」乃至「Ｎ３」）を配置する。なお、係るノードは、例えば、データを格納（保存）可能な物理的あるいは仮想的な情報処理装置により実現される。
【００３５】
データ管理システム１は、ハッシュ関数Ｈを用いて、ＫＶＳ（例えば、図１に例示する「ＫＶＳデータ」）に保持されるデータセットのキーに関するハッシュ値を計算する。そして、データ管理システム１は、配置リングにおいて、計算したハッシュ値に相当する位置に、当該キーを配置する。
【００３６】
データ管理システム１は、配置リングに配置されたそれぞれのキーから、配置リングにおいて時計回りに最も近い位置に配置されたノードに、当該キーを含むデータセットを割り当てる。即ち、配置リング上において、あるノード（例えば図１における「Ｎ３」）と、当該ノードに統計周りの方向で隣接するノード（例えば図１における「Ｎ１」）との間に配置されたキーは、当該隣接するノードに割り当てられる。図１に示す具体例においては、キー「Ｋ５」、「Ｋ１」、「Ｋ８」がノード「Ｎ１」に割り当てられる。また、キー「Ｋ２」、「Ｋ９」、「Ｋ６」がノード「Ｎ２」に割り当てられる。また、キー「Ｋ３」、「Ｋ４」、「Ｋ７」がノード「Ｎ３」に割り当てられる。データ管理システム１は、このような、隣接するノード間の領域を、一つのパーティション（図１に例示する「Ｐ１」乃至「Ｐ３」）として扱い、それぞれのパーティションがノードに割り当てられる。これにより、ＫＶＳが複数のパーティションに分割され、複数のノードに割り当てられることから、データの管理に伴う負荷が各ノードに分散される。
【００３７】
データ管理システム１は、例えば、各ノードに割り当てられるパーティションに含まれるデータセットの数（あるいはサイズ）が均等（または略均等）になるように、配置リングに対して各ノードを配置してもよい。データ管理システム１は、例えば、配置リングに対して１以上のノードをランダムに配置してもよい。また、データ管理システム１は、例えば、ハッシュ関数Ｈを用いて、ノードを一意に識別可能な識別情報を表す値のハッシュ値を計算し、配置リングにおける当該ハッシュ値に相当する位置に当該ノードを配置してもよい。
【００３８】
なお、上記説明においては一つの実体的なノードに対して一つのパーティションが割り当てられているが、本実施形態はこれには限定されない。例えば、一つのパーティションを管理する仮想的なノードが（仮想ノード）を導入されてもよい。この場合、複数の仮想ノードが、一つの実体的なノード（実体ノード）に割り当てられてもよい。これにより、実質的には、一つの実体ノードが複数のパーティションを管理可能である。
【００３９】
データ管理システム１は、ＫＶＳに格納されるデータセットを、パーティションごとに個別に設定された、暗号処理に用いられる情報（暗号鍵等）等を用いて暗号化する。またデータ管理システム１は、ＫＶＳに格納されたデータにアクセスするクライアントに対して、透過的な暗号処理を提供する。即ち、データ管理システム１を利用するクライアントは、暗号処理に関する詳細を考慮することなく、ＫＶＳに格納されたデータに関するアクセスを要求可能である。
【００４０】
以下、係るデータ管理システム１を実現可能な具体的な構成について、図２、図３を参照して説明する。図２、図３は、本実施形態におけるデータ管理システム１の機能的な構成を例示するブロック図である。なお、図２、及び図３に例示する構成は、データ管理システム１を実現可能な機能的構成の一つの具体例であり、本実施形態はこれには限定されない。図２、及び図３に例示する機能的な構成要素のうち、１以上の要素が統合されてもよく、各要素が更に分割されてもよい。また、同様な機能を実現可能な範囲で、各構成要素の配置が適宜変更されてもよい。
【００４１】
図２に例示するように、本実施形態におけるデータ管理システム１は、少なくとも１以上のデータ管理部１０１と、少なくとも１以上のリクエスト管理部１０２と、鍵管理部１０４と、を備える。データ管理システム１は、複数のデータ管理部１０１を有してもよく、複数のリクエスト管理部１０２を有してもよい。また、データ管理システム１は、認証部１０３を備えてもよい。本実施形態におけるデータ管理システム１は、クライアント１０５と適当な通信ネットワークを介して通信可能に接続されている。係る通信ネットワークは、例えば、Ｉｎｔｅｒｎｅｔ（インターネット）等の広域ネットワークであってもよく、構内ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などの狭域ネットワークであってもよく、それらの組み合わせであってもよい。また、係る通信ネットワークは、有線通信、無線通信、あるいはそれらの適当な組み合わせにより構成されてよい。
【００４２】
データ管理部１０１は、データ管理システム１が管理するＫＶＳにデータを格納し、当該データに対するアクセスを処理する。データ管理部１０１は、永続化されたデータを格納可能である。また、データ管理部１０１は、暗号化されたデータを格納可能である。なお、以下において、係るデータ管理部１０１を、「ＫＶＳ装置」と称する場合がある。係るデータ管理部１０１は、１以上の適切な数の仮想的あるいは物理的な情報処理装置を用いて実現可能である。データ管理部１０１におけるデータ格納部１０１ａ（後述）は、例えば、周知の仮想的なストレージ技術を用いて実現可能である。
【００４３】
データ管理部１０１は、例えば、上記説明したノードを実現可能であり、ＫＶＳを構成する１以上のパーティションを管理する。データ管理部１０１は、当該パーティションに含まれる各データセットに対するアクセスを処理する。なお、データ管理部１０１は、リクエスト管理部１０２（後述）とともに、上記ノードを実現してもよい。
【００４４】
図３に例示するように、データ管理部１０１は、データ格納部１０１ａと、通信部１０１ｂと、全キー検索部１０１ｃとを備える。データ管理部１０１を構成するこれらの構成要素の間は、適切な通信方法（通信バス、通信ネットワーク等）を用いて通信可能に接続されている。
【００４５】
データ格納部１０１ａ（ＫＶＳ格納部）は、ＫＶＳ方式のデータストアを提供し、ＫＶＳを構成する１以上のパーティションを保持する。即ち、データ格納部１０１ａは、ＫＶＳを構成するパーティションに割り当てられる（含まれる）データセットを格納（保存）することができる。データ格納部１０１ａは、適切なデータ保持方法（例えば、ファイル、あるいはデータベース等）を用いて、これらのパーティションを保持してよい。
【００４６】
データ格納部１０１ａには、後述するように、暗号化されたデータセットが格納される。本実施形態においては、データ格納部１０１ａに、暗号化されたバリューを含むデータセットが格納されることを想定する。
【００４７】
通信部１０１ｂは、リクエスト管理部１０２（後述）との間の通信を処理する。具体的には、通信部１０１ｂは、例えば、リクエスト管理部１０２から送信された、あるデータセットに対するアクセス要求を受信し、当該アクセス要求の処理結果を送信する。なお、通信部１０１ｂは上記以外の通信処理を実行してもよい。
【００４８】
全キー検索部１０１ｃは、データ管理部１０１が管理するパーティションごとに、当該パーティションに含まれる全データセットのキーを検索する。具体的には、全キー検索部１０１ｃは、データ管理部１０１が管理するパーティションに含まれる全てのデータセットのキーをスキャンし、その結果を取得可能である。
【００４９】
本実施形態においては、いずれかのデータ管理部１０１が上記配置リングにおけるノード（各データ管理部１０１）の配置と、パーティションの分割とを制御してもよい。ノード配置及びパーティション分割に関する情報は、複数のデータ管理部１０１の間で共有される。また、これらの情報は、複数のリクエスト管理部１０２の間で共有されてもよい。
【００５０】
次に、本実施形態におけるリクエスト管理部１０２の概要を説明する。リクエスト管理部１０２は、クライアント１０５から、ＫＶＳに格納されたデータに対するアクセス要求（ＧＥＴ、ＰＵＴ）を受け付け、当該アクセス要求を処理する。係るリクエスト管理部１０２は、データ管理部１０１とともに、上記ノードを実現してもよい。係るリクエスト管理部は、１以上の適切な数の仮想的あるいは物理的な情報処理装置を用いて実現可能である。
【００５１】
リクエスト管理部１０２は、ホットデータ（参照頻度が高いデータ、あるいは、参照されてからの経過時間が短いデータ）をキャッシュとして格納可能である。これにより、クライアント１０５から要求されたデータがキャッシュに格納されている場合、リクエスト管理部１０２は、データ管理部１０１にデータを要求せず、キャッシュに格納されているデータをクライアントに対して提供することができる。また、リクエスト管理部１０２は、クライアント１０５に対して透過的な暗号処理を提供する。以下、リクエスト管理部１０２の具体的な構成例について説明する。
【００５２】
リクエスト管理部１０２は、図３に例示するように、クライアント通信部１０２ａ、データ管理通信部１０２ｂ、鍵管理通信部１０２ｈを有する。また、リクエスト管理部１０２は、リクエスト処理部１０２ｃ、暗号処理部１０２ｄ、キャッシュデータ保持部１０２ｅ、キャッシュ鍵保持部１０２ｆ、鍵ライフサイクル管理部１０２ｇを有する。また、リクエスト管理部１０２は、再暗号化処理部１０２ｉを有する。リクエスト管理部１０２を構成するこれらの構成要素の間は、適切な通信方法（通信バス、通信ネットワーク等）を用いて通信可能に接続されている。
【００５３】
クライアント通信部１０２ａは、クライアント１０５と通信可能に接続され、クライアント１０５との間の通信処理を実行する。具体的には、クライアント通信部１０２ａは、クライアント１０５から、ＫＶＳに格納されたデータセットに対するアクセス要求（リクエスト）を受信する。クライアント通信部１０２ａは、受信したアクセス要求をリクエスト処理部１０２ｃに提供する。
【００５４】
データ管理通信部１０２ｂは、データ管理部１０１（例えば、通信部１０１ｂ）と通信可能に接続される。データ管理通信部１０２ｂは、リクエスト処理部１０２ｃからの指示に基づいて、データ管理部１０１に対してアクセス要求を送信し、その処理結果を受信する。なお、データ管理通信部１０２ｂは、接続先のデータ管理部１０１との間でセキュリティが確保された安全な通信路を確立してもよい。データ管理通信部１０２ｂは、例えば、ＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ）等の暗号通信プロトコルを用いて、係る通信路を確立してもよい。
【００５５】
リクエスト処理部１０２ｃは、クライアント通信部１０２ａから受信したアクセス要求を処理する。リクエスト処理部１０２ｃは、必要に応じて、暗号処理部１０２ｄ（後述）を用いてアクセス要求の対象であるデータセットに関する暗号処理を実行する。具体的には、リクエスト処理部１０２ｃは、クライアントから受信したＧＥＴ処理のリクエスト（「ＧＥＴリクエスト」）において指定されたキーに関連付けされたバリューをデータ管理部１０１から取得し、当該バリューを復号する。また、リクエスト処理部１０２ｃは、クライアントから受信したＰＵＴ処理の要求（「ＰＵＴリクエスト」）において指定されたバリューを暗号化する。なお、リクエスト処理部１０２ｃは、必要に応じて鍵管理通信部１０２ｈ（後述）に対して、暗号鍵の取得を要求し、取得した暗号鍵をキャッシュ鍵保持部１０２ｆに格納（保存）する。
【００５６】
暗号処理部１０２ｄは、リクエスト処理部１０２ｃにおける上記暗号処理を実行する。暗号処理部１０２ｄは、ＫＶＳに格納するデータセットの少なくとも一部を暗号化する処理を実行可能である。また、暗号処理部１０２ｄは、ＫＶＳに格納された、暗号化されたデータセットを復号可能である。なお、暗号処理部１０２ｄは、パーティションごとに個別に設定された、暗号処理に用いられる秘密情報（暗号鍵等）を用いて、当該暗号処理を実行する。以下、説明の便宜上、係る暗号処理に用いられる秘密情報が暗号鍵であることを想定する。係る秘密情報には、暗号鍵以外のデータが含まれてもよい。暗号処理部１０２ｄは、標準化された暗号アルゴリズムを用いて暗号処理を実行してもよい。係る暗号アルゴリズムとして、例えば、ＡＥＳ（Ａｄｖａｎｃｅｄ  Ｅｎｃｒｙｐｔｉｏｎ  Ｓｔａｎｄａｒｄ）、Ｔｒｉｐｌｅ−ＤＥＳ（Ｄａｔａ  Ｅｃｒｙｐｔｉｏｎ  Ｓｔａｎｄａｒｄ）等を採用可能である。
【００５７】
キャッシュデータ保持部１０２ｅは、ホットデータ（例えば、アクセス頻度が高いデータセット、あるいは、直近でアクセスされたデータセット等）を一時的に保持する。これにより、キャッシュデータ保持部１０２ｅは、データ管理部１０１が管理するＫＶＳに対するキャッシュを提供可能である。係るキャッシュデータ保持部１０２ｅは、仮想的、あるいは、物理的な記憶領域を用いて実現されてもよい。キャッシュデータ保持部１０２ｅは、暗号化されたデータセットを保持してもよく、平文のデータセットを保持してもよい。
【００５８】
キャッシュ鍵保持部１０２ｆは、暗号処理部１０２ｄにおける暗号処理において用いられる暗号鍵を少なくとも一時的に保持する。これにより、キャッシュ鍵保持部１０２ｆは、鍵管理部１０４が管理する暗号鍵に対するキャッシュを提供可能である。具体的には、キャッシュ鍵保持部１０２ｆは、図４に例示するように、パーティションを特定可能な情報（パーティションＩＤ（Ｉｄｅｎｔｉｆｉｅｒ）、図４の４０１）と、当該パーティションに個別に割り当てられた暗号鍵（図４の４０３）とを、関連付けて保持する。また、キャッシュ鍵保持部１０２ｆは、暗号鍵に対する有効期限（ＴＴＬ：Ｔｉｍｅ  Ｔｏ  Ｌｉｖｅ、図４の４０２）を保持してもよい。なお、ＴＴＬの単位は適宜定められてよい（例えば「秒」、「分」、「時間」等）。また、キャッシュ鍵保持部１０２ｆは、上記以外のデータをパーティションＩＤ４０１に関連付けて保持してもよい。
【００５９】
鍵ライフサイクル管理部１０２ｇは、キャッシュ鍵保持部１２０ｆに格納されている暗号鍵のライフサイクルを管理する。具体的には、鍵ライフサイクル管理部１０２ｇは、キャッシュ鍵保持部１２０ｆに格納されている暗号鍵の有効期限を管理し、有効期限が超過した暗号鍵に対して適切な処理を実行する。また、鍵ライフサイクル管理部１０２ｇは、鍵管理部１０４においてあるパーティションに関連付けされた暗号鍵が更新された際、更新前の暗号鍵を廃棄してもよい。
【００６０】
鍵管理通信部１０２ｈは、鍵管理部１０４（例えば、通信部１０４ｄ）と通信可能に接続され、暗号処理部１０２ｄにおける暗号処理に用いられる暗号鍵を送受信する。また、鍵管理通信部１０２ｈは、鍵管理部１０４から、各パーティションに関連付けされた暗号鍵の更新に関する通知を受け付ける。鍵管理通信部１０２ｈは、暗号鍵の更新に関する通知を、再暗号化処理部１０２ｉ（後述）に提供してもよい。また、鍵管理通信部１０２ｈは、暗号鍵の更新に関する通知を、鍵ライフサイクル管理部１０２ｇに通知してもよい。なお、鍵管理通信部１０２ｈは、鍵管理部１０４との間で、安全性が確保された通信路を用いて各種通信を実行する（後述）。
【００６１】
再暗号化処理部１０２ｉは、あるパーティションに関連付けされた暗号鍵の更新通知に基づいて、当該パーティションに含まれるデータセットに関する再暗号化処理を実行する。係る再暗号化処理は、例えば、暗号鍵が更新されたパーティションに含まれるデータセットを、更新前の暗号鍵を用いて復号し、更新後の暗号鍵を用いて再度暗号化する処理である。
【００６２】
上記説明したクライアント通信部１０２ａ、データ管理通信部１０２ｂ、及び、鍵管理通信部１０２ｈは、共通した通信デバイスを用いて実現されてもよく、複数の通信デバイスを用いて実現されてもよい。係る通信デバイスは、例えば、物理的あるいは仮想的な通信インタフェース（例えば、ネットワークインタフェースカード）等であってもよい。
【００６３】
上記説明したキャッシュデータ保持部１０２ｅ、キャッシュ鍵保持部１０２ｆは、共通する記憶デバイスを用いて実現されてもよく、異なる記憶デバイスを用いて実現されてもよい。係る記憶デバイスは、例えば、物理的あるいは仮想的な記憶デバイス（例えば、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等）であってもよい。
【００６４】
なお、本実施形態においては、複数の上記説明したリクエスト管理部１０２を統合することにより、仮想的なキッシュ層が構成されてもよい。
【００６５】
鍵管理部１０４は、ＫＶＳに格納されるデータセットに関する暗号処理に用いられる暗号鍵を管理する。上記したように、係る暗号鍵は、データセットの暗号化処理、又は、復号処理に用いられる暗号鍵である。鍵管理部１０４は、１以上のリクエスト管理部１０２と通信可能に接続されている。
【００６６】
鍵管理部１０４は、図３に例示するように、鍵保持部１０４ａ、鍵検索部１０４ｂ、更新期限管理部１０４ｃ、及び、通信部１０４ｄを含む。鍵管理部１０４を構成するこれらの構成要素の間は、適切な通信方法を用いて通信可能に接続されている。
【００６７】
鍵保持部１０４ａは、ＫＶＳを構成するパーティションと、当該パーティションに含まれるデータセットに関する暗号処理に用いられる暗号鍵とを関連付けて保持する。鍵保持部１０４ａは、図５に例示するように、ＫＶＳを構成するパーティションを特定可能な情報（例えば、パーティションＩＤ（図５の５０１））と、暗号鍵（図５の５０３）と、当該暗号鍵の更新期限を表す情報（図５の更新期限５０２）と、を関連付けて保持してもよい。鍵保持部１０４ａは、上記以外のデータを、パーティションＩＤ５０１に関連付けて保持してもよい。
【００６８】
各パーティションに関連付けされる暗号鍵の初期値は、予め設定されてもよく、当該パーティションが形成された際に、鍵管理部１０４により適宜生成されてもよい。同様に、各パーティションの暗号鍵の更新期限は、予め設定されてもよく、当該パーティションが形成された際に、鍵管理部１０４により適宜設定されてもよい。なお、各パーティションの暗号鍵の更新期限の初期値は、異なる値に設定されてもよい。この場合、各パーティションの再暗号化処理（後述）が実行されるタイミングが異なることから、鍵管理部１０４は、再暗号化に伴う処理負荷を分散可能である。
【００６９】
鍵検索部１０４ｂは、あるデータセットのキーが与えられた際に、当該キーが含まれるパーティションを特定する。そして、鍵検索部１０４ｂは、鍵保持部１０４ａから、当該パーティションＩＤに関連付けされた暗号鍵を取得する。具体的には、鍵検索部１０４ｂは、例えば、与えられたキーのハッシュ値を算出し、算出したハッシュ値に基づいて、当該キーを含むデータセットが含まれるパーティションを特定してもよい。
【００７０】
更新期限管理部１０４ｃは、鍵保持部１０４ａが保持する各パーティションの暗号鍵の更新期限を管理する。更新期限管理部１０４ｃは、あるパーティションに関連付けされた暗号鍵の更新期限が到来した場合、当該暗号鍵を更新し、当該暗号鍵に対して新たな更新期限を設定する。更新期限管理部１０４ｃは、例えば、鍵保持部１０４ａに対して、新たな暗号鍵と、当該暗号鍵の更新期限とを設定する。なお、更新期限管理部１０４ｃは、各暗号鍵の更新期限に、異なる値を設定してもよい。これにより、パーティションごとに再暗号化処理（後述）が実行されるタイミングが異なることから、鍵管理部１０４は、再暗号化に伴う処理負荷を分散可能である。
【００７１】
更新期限管理部１０４ｃは、暗号鍵の更新に関する情報を、リクエスト管理部１０２に通知する。更新期限管理部１０４ｃは、例えば、暗号鍵が更新されたパーティションを特定可能な情報（例えば、パーティションＩＤ）と、更新前の暗号鍵と、更新後の暗号鍵と、をリクエスト管理部１０２に通知する。
【００７２】
通信部１０４ｄは、リクエスト管理部１０２（例えば、鍵管理通信部１０２ｈ）との間の通信処理を実行する。通信部１０４ｄは、暗号鍵の漏洩を防止するため、リクエスト管理部１０２との間で安全な通信路を確立する。具体的には、通信部１０４ｄは、例えば、リクエスト管理部１０２が発行する公開鍵を用いて暗号化されたデータを、リクエスト管理部１０２に対して送信してもよい。上記に限定されず、通信部１０４ｄは、周知のＰＫＩ（Ｐｕｂｌｉｋ  Ｋｅｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）技術を用いて、リクエスト管理部１０２の正当性を認証してもよく、リクエスト管理部１０２との間の通信を暗号化してもよい。通信部１０４ｄは、安全な通信路を確立するため、例えば、ＳＳＬあるいはＴＬＳなどの暗号通信プロトコルを採用してもよい。
【００７３】
認証部１０３は、クライアント１０５からの認証要求を処理する。具体的には、認証部１０３は、クライアント１０５から認証要求に応じて、当該クライアント１０５がリクエスト管理部１０２に接続可能な資格を有するか否かを確認する。そして、認証部１０３は、認証処理の結果に基づいて、正しい資格を持つクライアントに対して、リクエスト管理部１０２への接続を許可する。具体的には、認証部１０３は、リクエスト管理部１０２に接続する際に用いるチケットを発行する。なお、認証部１０３と、クライアント１０５との間の認証処理は、例えば、Ｋｅｒｂｅｒｏｓ認証等の認証技術を用いて実現されてもよい。
【００７４】
クライアント１０５は、例えば、データ管理システム１に格納されたデータに対するアクセスを要求するコンピュータ等の情報通信装置である。
【００７５】
次に、上記のように構成された本実施形態におけるデータ管理システム１の動作について図面を参照して説明する。
【００７６】
まず、図６及び図７を参照して、クライアント１０５に対する認証処理について説明する。図６は、クライアント１０５がリクエスト管理部１０２に接続するまでの処理の概要を表した説明図であり、図７は係る処理の過程を表すシーケンス図である。
【００７７】
図６に例示するように、クライアント１０５は、認証要求を認証部１０３に送信し（図６の（Ａ））、認証結果としてチケットを受信する（図６の（Ｂ））。そしてクライアント１０５は、係るチケットを用いてリクエスト管理部１０２にアクセス要求を送信し（図６の（Ｃ））、セッション確立結果を受信する（図６の（Ｄ））。
【００７８】
より具体的には、クライアント１０５は、例えば、クライアント１０５自身の認証パスワードを含む認証要求を、認証部１０３に送信する（ステップＳ７０１）。
【００７９】
認証部１０３は、認証処理を実行する（図７のステップＳ７０２）。具体的には、認証部１０３は、クライアント１０５から受信したパスワードが正しいか否かを判定する。パスワードが正しい場合、認証部１０３は、クライアント１０５に対して、リクエスト管理部に接続する際に用いられる認証情報（チケット）を発行する（図７のステップＳ７０３）。
【００８０】
クライアント１０５は、リクエスト管理部１０２に対して、発行されたチケットを送信することにより、リクエスト管理部１０２に対する接続（アクセス）を要求する（ステップＳ７０４）。
【００８１】
リクエスト管理部１０２は、受信したチケットを確認し（ステップＳ７０５）、当該チケットが正しい場合には、クライアント１０５の接続を許可し、通信セッションを確立する（ステップＳ７０６）。リクエスト管理部１０２は、クライアント１０５に対して、セッション情報を送信してもよい。
【００８２】
次に、通信セッションが確立した後、クライアント１０５が、データ管理システム１に対して、ＧＥＴリクエストを送信した場合の処理について、図８並びに図９Ａ乃至図９Ｃを参照して説明する。図８は、ＧＥＴ処理の概要を表す説明図であり、図９Ａ乃至図９Ｃは、係る処理の過程を表すシーケンス図である。図９Ａ乃至図９Ｃに例示するシーケンス図に例示された各処理は、結果に影響を与えない範囲において順番が入れ替えられてもよく、並行して実行されてもよい。
【００８３】
図８に例示するように、クライアント１０５は、リクエスト管理部１０２に対してＧＥＴ処理を要求する（図８の（Ａ））。リクエスト管理部１０２は、データ管理部１０１に対してＧＥＴリクエストを送信（図８の（Ｂ１））し、暗号化されたデータ（バリュー）を取得する（図８の（Ｃ１））。また、リクエスト管理部１０２は、鍵管理部１０４から適切な暗号鍵を取得し（図８の（Ｂ２）、（Ｃ２））、データ管理部１０１から取得したデータを復号して、クライアントに返信する（図８の（Ｄ））。
【００８４】
具体的には、クライアント１０５は、あるキーを指定して、リクエスト管理部１０２にＧＥＴ処理をリクエストする（図９ＡのステップＳ９０１）。以下、ＧＥＴリクエストにおいて指定されたキーを「リクエストされたキー」と称する場合がある。
【００８５】
リクエスト管理部１０２（リクエスト処理部１０２ｃ）は、リクエストされたキーを用いて、キャッシュデータ保持部１０２ｅを検索する（ステップＳ９０２）。
【００８６】
リクエストされたキーに関連付けされたバリューが、キャッシュデータ保持部１０２ｅに保持されていない場合、リクエスト処理部１０２ｃは、データ管理部１０１に対して、リクエストされたキーを指定してＧＥＴリクエストを送信する（ステップＳ９０３）。リクエストされたキーを含むデータセットが格納されるパーティションを特定する具体的な方法については、後述する。
【００８７】
係るＧＥＴリクエストを受信したデータ管理部１０１は、データ格納部１０１ａに格納されたＫＶＳのパーティションにおいて、リクエストされたキーに関連付けされたバリューを検索（ステップＳ９０４）する。データ管理部１０１は、取得したバリューをリクエスト管理部１０２に送信する（ステップＳ９０５）。なお、係るバリューは、パーティションごとに個別に設定された暗号鍵を用いて暗号化されている（例えば、後述するＰＵＴ処理の際に暗号化されて、ＫＶＳに格納されている）。
【００８８】
また、リクエスト管理部１０２（リクエスト処理部１０２ｃ）は、キャッシュ鍵保持部１０２ｆに、リクエストされたキーを含むパーティションに関連付けされた暗号鍵が格納（保持）されているか否かを確認する（ステップＳ９０６）。
【００８９】
キャッシュ鍵保持部１０２ｆに暗号鍵が保持されていない場合、リクエスト管理部１０２は、鍵管理部１０４に対して、暗号鍵の取得を要求する（ステップＳ９０７）。具体的には、リクエスト処理部１０２ｃが、鍵管理通信部１０２ｈを介して、鍵管理部１０４（通信部１０４ｄ）にリクエストされたキーを送信する。
【００９０】
鍵管理部１０４（鍵検索部１０４ｂ）は、リクエストされたキーから算出したハッシュ値を用いて、当該キーを含むパーティションを特定する。そして、鍵管理部１０４は、特定したパーティションに関連付けて格納されている暗号鍵を鍵保持部１０４ａから取得し（ステップＳ９０８）、通信部１０４ｄを介してリクエスト管理部１０２に送信する（ステップＳ９０９）。
【００９１】
上記ステップＳ９０３乃至ステップＳ９０５の処理と、上記ステップＳ９０６乃至Ｓ９０９の処理とは、並行して実行されてもよい。
【００９２】
次に、リクエスト管理部１０２（暗号処理部１０２ｄ）は、ステップＳ９０５において取得した暗号化されたバリューを、ステップＳ９０９において取得した暗号鍵を用いて復号する（ステップＳ９１０）。
【００９３】
リクエスト管理部１０２（リクエスト処理部１０２ｃ）は、ステップＳ９１０において復号されたバリューと、リクエストされたキーとを関連付けて、キャッシュデータ保持部１０２ｅに格納する（ステップＳ９１１）。以降、リクエスト処理部１０２ｃは、クライアントから同じキーでＧＥＴ処理を要求された場合には、キャッシュデータ保持部１０２ｅに格納されたバリューを返すことが可能である。これにより、リクエスト管理部１０２は、データ管理部１０１との間の通信、及び、データ管理部１０１におけるデータの検索に伴う負荷あるいは遅延を低減可能である。
【００９４】
また、リクエスト管理部１０２（リクエスト処理部１０２ｃ）は、ステップＳ９０９において取得した暗号鍵を、パーティションＩＤと関連付けてキャッシュ鍵保持部１０２ｆに格納する（ステップＳ９１２）。一つの具体例として、図８に示すように、リクエスト管理部１０２が、鍵管理部１０４からパーティションＩＤ「Ｐ２」に関連付けされた暗号鍵（「ｂ１」）を取得した場合を想定する。この場合、リクエスト管理部は、当該暗号鍵をキャッシュ鍵保持部１０２ｆに、パーティションＩＤ「Ｐ２」と関連付けて格納する。これにより、リクエスト管理部は、鍵管理部１０４との間の通信、及び、鍵管理部１０４における鍵の検索に伴う負荷あるいは遅延を低減可能である。なお、この際、キャッシュ鍵保持部１０２ｆに格納される暗号鍵について、有効期限（図４の４０２）が設定される。
【００９５】
リクエスト管理部１０２は、ステップＳ９１０において復号したデータを、クライアント１０５に送信する（ステップＳ９１３）。具体的には、リクエスト処理部１０２ｃは、暗号処理部１０２ｄが復号したバリューをクライアント通信部１０２ａに提供し、クライアント通信部１０２ａがクライアント１０５に対してそのバリューを送信する。
【００９６】
上記説明したＧＥＴ処理において、リクエストされたキーを含むパーティションに関連付けされた暗号鍵がキャッシュ鍵保持部１０２ｆに保持されている場合を想定する。この場合、図９Ｂに例示するように、リクエスト管理部１０２は、ステップＳ９０７を実行せず、ステップＳ９１０、ステップＳ９１１、ステップＳ９１３を実行すればよい。
【００９７】
上記説明したＧＥＴ処理において、リクエストされたキーに関連付けされたバリューがキャッシュデータ保持部１０２ｅに保持されている場合を想定する。この場合、図９Ｃに例示するように、リクエスト管理部１０２は、ステップＳ９０２、及びステップＳ９１３を実行すればよい。
【００９８】
なお、上記説明したＧＥＴ処理において、クライアント１０５は、当該キーのハッシュ値を算出して当該ハッシュ値が割り当てられたパーティションを特定してもよい。そして、クライアント１０５は、当該特定したパーティションに関するリクエストを処理するリクエスト管理部１０２にＧＥＴリクエストを送信してもよい。
【００９９】
あるいは、クライアント１０５は、特定のリクエスト管理部１０２にＧＥＴリクエストを送信してもよい。そして、クライアント１０５からＧＥＴリクエストを受信したリクエスト管理部１０２が、指定されたキーのハッシュ値を算出し、当該ハッシュ値が割り当てられたパーティションを特定してもよい。この場合、リクエスト管理部１０２は、ステップＳ９０３において、当該特定したパーティションを管理するデータ管理部１０１に対して、ＧＥＴリクエストを送信してもよい。
【０１００】
上記のようなＧＥＴ処理により、データ管理システム１は、クライアント１０５に対して、透過的な暗号処理を提供可能である。即ち、クライアント１０５は、あるキーに関連付けされたバリューが暗号化されているか否かを意識する必要がなく、復号されたバリューを取得可能である。なぜならば、リクエスト管理部１０２が、リクエストされたキーが含まれるパーティションに関連付けされた暗号鍵を鍵管理部１０４から取得し、データ管理部１０１から取得したバリューを当該暗号鍵を用いて復号するからである。また、鍵管理部１０４は、ＫＶＳを構成するパーティションごとに、個別に暗号鍵を関連付けて管理することから、データ管理システム１は、パーティションごとに異なる暗号鍵を用いた暗号処理を実行可能である。
【０１０１】
次に、キャッシュ鍵保持部１０２ｆに格納された暗号鍵の管理について図１０に例示するフローチャートを参照して説明する。図１０に例示するように、鍵ライフサイクル管理部１０２ｇは、キャッシュ鍵保持部１０２ｆに格納された暗号鍵の有効期限（図４の４０２）を確認する（ステップＳ１００１）。具体的には、鍵ライフサイクル管理部１０２ｇは、例えば、暗号鍵の有効期限を定期的に減少させ、有効期限が”０”になったか否かを確認してもよい。
【０１０２】
鍵ライフサイクル管理部１０２ｇは、有効期限が切れた場合（ステップＳ１００２においてＹＥＳ）、当該暗号鍵をキャッシュ鍵保持部１０２ｆから削除する（ステップＳ１００３）。
【０１０３】
鍵ライフサイクル管理部１０２ｇは、有効期限が切れていない場合、ステップＳ１００１から処理を続行してもよい。
【０１０４】
上記ステップＳ１００１乃至ステップＳ１００３の処理により、リクエスト管理部１０２（鍵ライフサイクル管理部１０２ｇ）は、暗号鍵がリクエスト管理部１０２に長期間保存されることを防止することができる。これにより、リクエスト管理部１０２から暗号鍵が漏洩するリスクが低減される。
【０１０５】
次に、クライアント１０５が、データ管理システム１に対して、ＰＵＴリクエストを送信した場合の処理について、図１１、図１２を参照して説明する。図１１は、ＰＵＴ処理の概要を表す説明図であり、図１２は、係る処理の過程を表すシーケンス図である。
【０１０６】
図１１に例示するように、クライアント１０５は、リクエスト管理部１０２に対してＰＵＴ処理を要求する（図１１の（Ａ））。リクエスト管理部１０２は、鍵管理部１０４から適切な暗号鍵を取得する（図１２の（Ｂ）、（Ｃ））。リクエスト管理部１０２は、クライアント１０５から受信したデータセット（ＰＵＴ処理の対象）を、鍵管理部１０４から取得した暗号鍵を用いて暗号化する。リクエスト管理部１０２は、暗号化したデータをデータ管理部１０１に送信し、ＰＵＴ処理を要求する（図１１の（Ｄ））。
【０１０７】
具体的には、クライアント１０５は、あるキーとバリューのペア（データセット）を指定して、リクエスト管理部１０２にＰＵＴ処理をリクエストする（図１２のステップＳ１２０１）。以下、ＰＵＴリクエストにおいて指定されたデータセットを、「リクエストされたデータセット」と称し、ＰＵＴリクエストにおいて指定されたキーを、「リクエストされたキー」と称する場合がある。
【０１０８】
ＰＵＴリクエストを受信したリクエスト管理部１０２（リクエスト処理部１０２ｃ）は、キャッシュ鍵保持部１０２ｆに、適切な暗号鍵が格納（保存）されているか確認する（ステップＳ１２０２）。係る処理は、上記説明したステップＳ９０６と同様としてよいので、詳細な説明を省略する。
【０１０９】
キャッシュ鍵保持部１０２ｆに暗号鍵が保持されていない場合、リクエスト管理部１０２は、鍵管理部１０４に対して、暗号鍵の取得を要求する（ステップＳ１２０３）。具体的には、リクエスト処理部１０２ｃが、鍵管理通信部１０２ｈを介して、鍵管理部１０４（通信部１０４ｄ）にリクエストされたキーを送信する。
【０１１０】
鍵管理部１０４（鍵検索部１０４ｂ）は、リクエストされたキーを含むパーティションに関連付けされた暗号鍵を取得し（ステップＳ１２０４）、取得した暗号鍵を通信部１０４ｄを介してリクエスト管理部１０２に送信する（ステップＳ１２０５）。ステップＳ１２０４、Ｓ１２０５における処理は、それぞれ、上記ステップＳ９０８、Ｓ９０９と同様としてよいので、詳細な説明を省略する。
【０１１１】
リクエスト管理部１０２（暗号処理部１０２ｄ）は、ステップＳ１２０５において取得した暗号鍵を用いて、リクエストされたデータセットに含まれるバリューを暗号化する（ステップＳ１２０６）。
【０１１２】
リクエスト管理部１０２（リクエスト処理部１０２ｃ）は、暗号化されたバリューと、リクエストされたキーとを関連付けた新たなデータセットを指定して、データ管理部１０１にＰＵＴリクエストを送信する（ステップＳ１２０７）。
【０１１３】
データ管理部１０１は、受信したＰＵＴリクエストにおいて指定されたデータセットを、データ格納部１０１ａに格納されたＫＶＳのパーティションに格納（保存）する（ステップＳ１２０８）。なお、データ管理部１０１は、ＰＵＴリクエストにおいて指定されたデータセットを用いて、ＫＶＳに格納されているデータセットを更新してもよい。
【０１１４】
データ管理部１０１は、リクエスト管理部１０２に、ＰＵＴリクエストの処理結果を送信してもよい。また、リクエスト管理部１０２は、クライアント１０５に対してＰＵＴリクエストの処理結果を送信してもよい。
【０１１５】
リクエスト管理部１０２は、ステップＳ１２０５において取得した暗号鍵を、パーティションＩＤと関連付けてキャッシュ鍵保持部１０２ｆに格納してもよい（ステップＳ１２０９）。ステップＳ１２０９における処理は、上記ステップＳ９１２における処理と同様としてよいので、詳細な説明を省略する。
【０１１６】
上記説明したＰＵＴ処理において、リクエストされたキーを含むパーティションに関連付けされた暗号鍵がキャッシュ鍵保持部１０２ｆに保持されている場合を想定する。この場合、リクエスト管理部１０２は、ステップＳ１２０３を実行せず、ステップＳ１２０６、ステップＳ１２０７を実行すればよい。
【０１１７】
上記説明したＰＵＴ処理において、クライアント１０５は、ＫＶＳに格納するキーのハッシュ値を算出して当該キーが含まれるパーティションを特定してもよい。そして、クライアント１０５は、当該特定したパーティションを管理するノード（例えば、リクエスト管理部１０２あるいはデータ管理部１０１）に直接ＰＵＴリクエストを送信してもよい。
【０１１８】
あるいは、クライアント１０５は、特定のリクエスト管理部にＰＵＴリクエストを送信してもよい。そして、クライアント１０５からＰＵＴリクエストを受信したリクエスト管理部１０２が、指定されたキーのハッシュ値を算出し、当該キーが含まれるパーティションを特定してもよい。この場合、リクエスト管理部１０２は、ステップＳ１２０７において、当該特定したパーティションを管理するデータ管理部１０１に対して、ＰＵＴリクエストを送信してもよい。
【０１１９】
上記のようなＰＵＴ処理により、データ管理システム１は、クライアント１０５に対して、透過的な暗号処理を提供可能である。即ち、クライアント１０５は、ＰＵＴリクエストを用いてＫＶＳに格納するデータセットを明示的に暗号化する必要がなく、平文のデータセットをリクエスト管理部１０２に送信すればよい。なぜならば、リクエスト管理部１０２が、ＰＵＴリクエストにおいて指定されたデータセットを、鍵管理部１０４から取得した適切な暗号鍵を用いて暗号化するからである。また、鍵管理部１０４は、ＫＶＳを構成するパーティションごとに、個別に暗号鍵を関連付けて管理することから、データ管理システム１は、パーティションごとに異なる暗号鍵を用いた暗号処理を実行可能である。
【０１２０】
なお、リクエスト管理部１０２は、上記説明したＧＥＴリクエスト、ＰＵＴリクエスト以外のリクエスト（例えばＤＥＬＥＴＥリクエスト等）についても、同様の方法で処理可能である。即ち、リクエスト管理部１０２は、リクエストにおいて指定されたキーに基づいて、当該キーを含むデータセットが格納されるパーティションを特定する。そして、リクエスト管理部１０２は、当該特定したパーティションに含まれるデータセットに対して、受信しリクエストに応じた適切な処理を実行する。
【０１２１】
次に、鍵管理部１０４に格納された暗号鍵の更新処理について図１３及び図１４を参照して説明する。図１３は、暗号鍵の更新処理の概要を表す説明図であり、図１４は係る処理の過程を表すシーケンス図である。
【０１２２】
図１３に例示するように、鍵管理部１０４（更新期限管理部１０４ｃ）は、鍵保持部１０４ａに格納された暗号鍵の更新期限を確認する。ある暗号鍵に関する更新期限が到来した場合には、リクエスト管理部１０２に対して、暗号鍵の更新を通知する（図１３の（Ａ））。係る通知を受け付けたリクエスト管理部１０２は、データ管理部１０１に対して、更新される暗号鍵が関連付けされたパーティションのロックを要求し（図１３の（Ｂ））、当該パーティションに含まれる全てのデータセットを取得する（図１３の（Ｃ）、（Ｄ））。そして、リクエスト管理部１０２は、取得したデータを更新前後の暗号鍵を用いて再暗号化したデータセットを、データ管理部１０１に格納する（図１３の（Ｅ））。
【０１２３】
具体的には、鍵管理部１０４（更新期限管理部１０４ｃ）は、鍵保持部１０４ａに格納されている暗号鍵の更新期限（例えば、図５の５０２）を確認する（ステップＳ１４０１）。以下においては、具体例として、図５に例示するパーティションＩＤ「Ｐ３」に関連付けされた暗号鍵の更新期限（「２０１５−０５−３０」）到来したことを想定する。以下、更新対象の暗号鍵が関連付けされたパーティションを、「更新パーティション」と称する場合がある。
【０１２４】
鍵管理部１０４（更新期限管理部１０４ｃ）は、更新期限が到来した暗号鍵（この場合は、パーティションＩＤ「Ｐ３」に関連付けされた暗号鍵「ｃ１」）を更新する（ステップＳ１４０２）。また、鍵管理部１０４は、更新された暗号鍵に関連付けされた更新期限を変更する。更新期限管理部１０４ｃは、例えば、暗号鍵「ｃ１」を、暗号鍵「ｃ２」に更新し、その更新期限を「２０１５−０５−３０」から「２０１５−０８−３０」に変更する。
【０１２５】
鍵管理部１０４は、リクエスト管理部１０２に対して、暗号鍵の更新を通知する（ステップＳ１４０３）。具体的には、更新期限管理部１０４ｃは、通信部１０４ｄを介して、リクエスト管理部１０２に対して、更新前の暗号鍵と、更新後の暗号鍵と、更新パーティションを特定可能な情報と、を送信する。更新期限管理部１０４ｃは、例えば、暗号鍵「ｃ１」と、暗号鍵「ｃ２」と、パーティションＩＤ「Ｐ３」と、をリクエスト管理部１０２に送信する。
【０１２６】
リクエスト管理部１０２は、データ管理部１０１に対して、更新パーティション（例えば、パーティションＩＤ「Ｐ３」）のロックを要求する（ステップＳ１４０４）。パーティションがロックされた場合、例えば、当該パーティションに関するＧＥＴ処理、ＰＵＴ処理の実行が抑制される。リクエスト管理部１０２における鍵管理通信部１０２ｈは、暗号鍵の更新に関する通知を受信し、再暗号化処理部１０２ｉに通知する。
【０１２７】
次に、リクエスト管理部１０２は、データ管理部１０１に対して、更新パーティションに含まれる全キーの取得を要求する（ステップＳ１４０５）。具体的には、再暗号化処理部１０２ｉが、データ管理部１０１に対して、更新パーティションのパーティションＩＤを送信し、当該パーティションに含まれる全キーの取得を要求する。
【０１２８】
なお、上記説明におけるステップＳ１４０４、及びステップＳ１４０５は統合されてもよい。即ち、リクエスト管理部１０２が、データ管理部１０１に対して更新パーティションの全キーの取得を要求した際に、データ管理部１０１が、更新パーティションをロックしてもよい。
【０１２９】
更新パーティションの全キー取得要求を受信したデータ管理部１０１（全キー検索部１０１ｃ）は、データ格納部１０１ａが保持する更新パーティションに含まれる全てのデータセットのキーを検索する（ステップＳ１４０６）。データ管理部１０１は、その結果をリクエスト管理部１０２に送信する（ステップＳ１４０７）。
【０１３０】
リクエスト管理部１０２は、更新パーティションに含まれる全てのデータセットのキーについてＧＥＴリクエストを送信する（ステップＳ１４０８）。具体的には、再暗号化処理部１０２ｉが、データ管理部１０１に対して、更新パーティションに含まれるキーを指定して、ＧＥＴリクエストを送信する。
【０１３１】
データ管理部１０１は、ＧＥＴリクエストを処理し（ステップＳ１４０９）、バリューを返す（ステップＳ１４１０）。なお、ステップＳ１４０９及びステップＳ１４１０の処理は、それぞれステップＳ９０４及びステップＳ９０５と同様としてよい。
【０１３２】
次に、リクエスト管理部１０２（再暗号化処理部１０２ｉ）は、ステップＳ１４１０において受信したバリューを、ステップＳ１４０３において取得した更新前の暗号鍵を用いて復号する。そして、リクエスト管理部１０２（再暗号化処理部１０２ｉ）は、復号したバリューを、更新後の暗号鍵を用いて再度暗号化する（ステップＳ１４１１）。
【０１３３】
リクエスト管理部１０２は、データ管理部１０１に対して、キーと、上記ステップＳ１４１１において再暗号化されたバリューと、を指定してＰＵＴリクエストを送信する（ステップＳ１４１２）。ステップＳ１４１２は、上記ステップＳ１２０７と同様としてよい。
【０１３４】
ＰＵＴリクエストを受信したデータ管理部１０１は、指定されたデータセットをＫＶＳに格納する。具体的には、データ管理部１０１は、指定されたデータセットをデータ格納部１０１ａに格納する（ステップＳ１４１３）。ステップＳ１４１３は、上記ステップＳ１２０８と同様としてよい。なお、データ管理部１０１は、ＰＵＴリクエストの処理結果をリクエスト管理部１０２に送信してもよい。
【０１３５】
更新パーティションに含まれる全てのキーについて、上記ステップＳ１４０８乃至ステップＳ１４１３の処理が実行された際、リクエスト管理部１０２は、データ管理部１０１に対して、更新パーティションのロック解除を要求してもよい（ステップＳ１４１４）。
【０１３６】
リクエスト管理部１０２は、例えば、上記ステップＳ１４０８乃至ステップＳ１４１２の処理を、ステップＳ１４０７において取得した全てのキーについて繰り返し実行することで、更新対象パーティションに登録されたデータセットを再暗号化することができる。
【０１３７】
また、上記ステップＳ１４０３における通知を受信した際、リクエスト管理部１０２（鍵ライフサイクル管理部１０２ｇ）は、係る通知に含まれる更新前の暗号鍵がキャッシュ鍵保持部１０２ｆに格納されているか確認してもよい。更新前の暗号鍵がキャッシュ鍵保持部１０２ｆに格納されている場合、鍵ライフサイクル管理部１０２ｇは、キャッシュ鍵保持部１０２ｆから更新前の暗号鍵を削除してもよい。なお、この際、鍵ライフサイクル管理部１０２ｇは、キャッシュ鍵保持部１０２ｆに、更新後の暗号鍵及びその有効期限を格納してもよい。これにより、鍵ライフサイクル管理部１０２ｇは、鍵管理部１０４に格納されている暗号鍵と、キャッシュ鍵保持部１０２ｆに格納されている暗号鍵との間に不整合が生じることを防止する。
【０１３８】
上記のように構成されたデータ管理システム１によれば、ＫＶＳを分割したパーティションごとに、当該パーティションに含まれるデータセットを暗号化する暗号鍵が、個別に割り当てられる（鍵保持部１０４ａ）。それぞれのパーティションに含まれるデータセット（特にはバリュー）は、それぞれのパーティションごとに関連付けされた個別の暗号鍵を用いて暗号化される。これにより、一つの暗号鍵を用いて暗号化されるデータの範囲がパーティションの単位で分割されることから、一つの暗号鍵が漏洩した場合の影響範囲が限定される。従って、データ管理システム１は、単一の暗号鍵を用いて全てのデータを暗号化する場合に比して、暗号鍵が漏洩した場合のリスクを低減可能である。
【０１３９】
また、上記のように構成されたデータ管理システム１によれば、パーティションごとの暗号鍵を更新する際の負荷が平準化される。例えば、データベースに含まれる全てのデータが単一の暗号鍵を用いて暗号化される場合、係る暗号鍵が更新されると、全てのデータが再度暗号化される必要がある。これに対して、データ管理システム１は、パーティションごとに個別の暗号鍵を関連付けることから、暗号鍵の更新に伴い再暗号化されるデータの範囲がパーティションの単位で分割される。これにより、暗号鍵の更新に伴う再暗号化の負荷が分散される。なお、各パーティションに含まれるデータセットのサイズが均等あるいは略均等であれば、再暗号化処理の負荷も均等あるいは略均等に分散される。また、データ管理システム１（特には更新期限管理部１０４ｃ）は、パーティションごとの暗号鍵の更新期限に、異なる値を設定できる。これにより、パーティションごとに暗号鍵の更新タイミングが異なることから、データ管理システム１は、再暗号化処理の負荷を時間的に分散することが可能である。
【０１４０】
また、上記のように構成されたデータ管理システム１においては、ＫＶＳに格納されるデータセットのキーを用いて、当該データセットが含まれるパーティションが特定される。なぜならば、コンシステント・ハッシング法を用いてＫＶＳがパーティションが分割され、キーのハッシュ値に基づいて、当該キーが含まれるパーティションが特定されるからである。これにより、ＫＶＳに格納されるデータセットのキーを用いて、当該データセットに関する暗号処理に用いられる暗号鍵を特定することが可能である。
【０１４１】
また、上記のように構成されたデータ管理システム１は、クライアント（例えばクライアント１０５）に対して、透過的な暗号処理を提供可能である。即ち、クライアントは、データ管理システム１に格納されるデータに関して、具体的な暗号処理を実行する必要がない。なぜならば、クライアントからのリクエスト（例えば、ＰＵＴリクエスト）を受け付けたリクエスト管理部が、当該リクエストで指定されたデータセットを、適切に暗号化してＫＶＳに格納するからである。また、クライアントからのリクエスト（例えば、ＧＥＴリクエスト）を受け付けたリクエスト管理部が、ＫＶＳに格納されたデータを適切に復号して、クライアントに通知するからである。
【０１４２】
以上より、本実施形態におけるデータ管理システム１は、データベースを適切な粒度の部分的な領域（例えば、パーティション）に分割し、分割された領域ごとに個別の暗号処理を実行することが可能である。
【０１４３】
＜第１の実施形態の変形例＞
次に、上記第１の実施形態の変形例について説明する。本変形例におけるデータ管理システム１は、上記第１の実施形態と同様としてよい。
【０１４４】
本変形例においては、暗号鍵の更新の際、更新される暗号鍵が関連付けされたパーティションをロックせずに、暗号鍵を更新する。
【０１４５】
この場合、リクエスト管理部１０２は、パーティションをロックせずに、データ管理部１０１に対して、当該パーティションに登録されている全てのキーの取得を要求する。この際、リクエスト管理部１０２は、再暗号化処理中であることを表すフラグ等を設定してもよい。係るフラグにより、クライアント１０５あるいは、他のリクエスト管理部１０２は、再暗号化処理を実行しているリクエスト管理部１０２を特定することができる。
【０１４６】
以降、データ管理部１０１は、上記第１の実施形態と同様の処理を実行する。即ち、リクエスト管理部１０２は、データ管理部１０１に対して全てのキーを用いてＧＥＴリクエストを送信し、キーとバリューとのペアを取得する。リクエスト管理部１０２は、更新前の暗号鍵を用いてバリューを復号し、更新後の暗号鍵を用いて当該バリューを再度暗号化する。そして、リクエスト管理部１０２は、データ管理部１０１に対して、キーと、再暗号化されたバリューとを指定してＰＵＴリクエストを送信する。
【０１４７】
あるリクエスト管理部１０２が再暗号化処理を実行している間に、クライアント１０５からＧＥＴリクエストを受信した場合について説明する。この場合、リクエスト管理部は、ＧＥＴリクエストに設定されたキーを確認し、当該キーに関連付けされたバリューが再暗号化済であるか否かを確認する。リクエスト管理部１０２は、例えば、あるパーティションに登録されたキーとバリューとのペアのうち、再暗号化が完了したペアを区別して管理することにより、あるキーに関連付けされたバリューが再暗号化済であるか否かを確認してもよい。リクエスト管理部１０２は、例えば、再暗号化対象のパーティションに登録されているキーについて、再暗号化済か否かを表すフラグを保持してもよい。また、リクエスト管理部１０２は、例えば、再暗号化済のキーを、再暗号化済リスト等に保持してもよい。リクエスト管理部１０２が再暗号化済か否かを判定する方法は、上記に限定されず、他の適切な方法を適宜選択可能である。
【０１４８】
ＧＥＴリクエストに設定されたキーに関連付けされたバリューが再暗号化済である場合、リクエスト管理部１０２は、更新後の暗号鍵を用いて当該バリューを復号する。そして、キーと、復号されたバリューとのペアをクライアント１０５に送信する。ＧＥＴリクエストに設定されたキーに関連付けされたバリューが再暗号化されていない場合、リクエスト管理部１０２は、更新前の暗号鍵を用いて当該バリューを復号する。そして、キーと、復号されたバリューとのペアをクライアント１０５に送信する。
【０１４９】
次に、リクエスト管理部１０２が再暗号化処理を実行している間に、クライアント１０５からＰＵＴリクエストを受信した場合について説明する。この場合、リクエスト管理部１０２は、当該ＰＵＴリクエストに設定さればバリューを、更新後の暗号鍵で暗号化する。そして、ＰＵＴリクエストに設定されたキーと、暗号化されたバリューとのペアを用いて、データ管理部１０１にＰＵＴリクエストを送信する。
【０１５０】
例えば、クライアント１０５から、再暗号化対象のパーティションに登録されたキーに対するＧＥＴ（あるいはＰＵＴ）リクエストを受信した場合、リクエスト管理部１０２は、当該パーティションの再暗号化処理を実行しているリクエスト管理部１０２に、当該リクエストを転送してもよい。あるいは、クライアント１０５からリクエストを受信した各リクエスト管理部１０２が、再暗号化対象のパーティションに関連付けされた更新前後の暗号鍵を用いて、バリューの復号と、暗号化とを実行してもよい。この場合、再暗号化処理を実行しているリクエスト管理部１０２は、他のリクエスト管理部１０２により既に更新された（即ち再暗号化された）キーとバリューとのペアを再暗号化の対象から除外する。係るリクエスト管理部１０２は、例えば、ＣＡＳ（Ｃｈｅｃｋ  Ａｎｄ  Ｓｅｔ）操作を行うことにより、あるキーとバリューとのペアが更新されたか否かを確認可能である。
【０１５１】
上記のように構成された本変形例におけるデータ管理システム１によれば、例えば、暗号鍵を更新する際、パーティションをロックせずに再暗号化処理を実行可能である。また、本変形例におけるデータ管理システム１は、上記第１の実施形態と同様の構成を備えることから、上記第１の実施形態と同様の効果を奏する。
【０１５２】
＜第２の実施形態＞
本発明の第２の実施形態について図面を参照して説明する。図１５は、本実施形態におけるデータ管理システム２の機能的な構成を例示するブロック図である。なお、図１５に例示する機能的な構成は一つの具体例であり、１以上の構成要素が統合されてもよく、各構成要素が更に分割されてもよい。また、同様を機能を実現可能な範囲で、各構成要素の配置が適宜変更されてもよい。なお、本実施形態は、上記第１の実施形態と適宜組み合わせれてもよい。
【０１５３】
本実施形態におけるデータ管理システム２（図１５）は、キーとバリューとのペア（データセット）ごとに異なるレベルの暗号化処理を実行するよう、上記第１の実施形態におけるデータ管理システム１を拡張したシステムである。以下、係る拡張点を中心に説明するとともに、上記第１の実施形態と同じ構成については同様の符号を付すことにより、詳細な説明を省略する。
【０１５４】
図１６は、データ管理システム２におけるＫＶＳ格納されるデータセットの概念的な構成を例示する説明図である。本実施形態におけるデータ管理システム２は、図１６に例示するように、キー（図１６の１６０１）と、バリュー（図１６の１６０２）と、を関連付けたデータセットを、ＫＶＳに格納する。バリュー１６０２には、暗号化レベルを表すデータ（図１６の１６０２ａ）と、暗号化されたデータ（図１６の１６０２ｂ）とが含まれる。
【０１５５】
暗号化レベル１６０２ａは、バリュー１６０２（具体的には、ＫＶＳに格納される暗号化されたバリュー１６０２ｂ）に関する暗号処理に関する安全性のレベル、あるいは、種類等を表す。バリュー１６０２ｂは、暗号化レベル１６０２ａの設定に基づいて、暗号化（あるいは復号）される。これより、同じパーティションに格納されるデータであっても、暗号化レベル１６０２ａの設定に応じて、それぞれのデータに対して実行される暗号処理が異なる。
【０１５６】
暗号化レベルは、数値、符号、文字列等により表される。以下においては、説明のための具体例として、暗号化レベルが数値を用いて表されることを想定する。この場合、例えば、暗号化レベル「０」は、暗号処理を実行しないことを表し、「１」は、標準的な暗号鍵の使用を表し、「２」は安全性が高い暗号鍵の使用を表してもよい。
【０１５７】
他の具体例として、暗号化レベル１６０２ａの設定に応じて、暗号処理において使用される暗号アルゴリズムが切り替えられてもよい。この場合、例えば、暗号化レベル「０」は、暗号処理を実行しないことを表し、「１」は、標準的な暗号アルゴリズムの使用を表し、「２」は安全性が高い暗号アルゴリズムの使用を表してもよい。なお、データ管理システム２は、安全性が確認された周知の暗号アルゴリズムを採用してよい。データ管理システム２が処理可能な暗号化レベルの初期値は、予め定められてもよいが、システムの運用段階等において変更されてもよい。
【０１５８】
暗号化レベル１６０２ａは、バリュー１６０２の先頭に配置されてもよく、末尾に配置されてもよく、先頭あるいは末尾から適宜オフセットされた位置に配置されてもよい。また、暗号化レベル１６０２ａのサイズは、予め定められていてもよい。なお、以下においては、具体例として、暗号化レベル１６０２ａがバリュー１６０２の先頭に配置されることを想定する。
【０１５９】
このようなデータセットを扱うデータ管理システム２においては、リクエスト管理部１５０２と、鍵管理部１５０４とが、それぞれ上記第１の実施形態におけるデータ管理システム１から拡張されている。なお、リクエスト管理部１５０２、及び、鍵管理部１５０４の具体的な構成は、図３に例示する構成と同様としてよい。以下、上記構成要素について説明する。
【０１６０】
鍵管理部１５０４は、図１７に例示するように、パーティションＩＤ（図１７の１７０１）と、更新期限（図１７の１７０２）と、暗号化レベル（図１７の１７０３）と、暗号鍵（図１７の１７０４）とを、関連付けて保持する。鍵管理部１５０４は、これらのデータを、鍵保持部１０４ａに保持してもよい。なお、パーティションごとの暗号鍵の初期値は、各暗号化レベルに応じて予め設定されてもよく、パーティションが形成された際に、鍵管理部１０４により適宜生成されてもよい。
【０１６１】
鍵管理部１５０４は、上記第１の実施形態と同様、リクエスト管理部１５０２からあるデータセットのキーが指定された際に、当該キーが含まれるパーティションを特定する。鍵管理部１５０４は、当該特定したパーティションＩＤに関連付けされた暗号鍵をリクエスト管理部１５０２に提供する。鍵管理部１５０４は、キーのみが指定された場合には、当該キーを含むパーティションに関連付けされた全ての暗号鍵１７０４と、その暗号化レベル１７０３と、のペアをリクエスト管理部１５０２に通知してもよい。また、鍵管理部１５０４は、キーと、暗号化レベルとが指定された場合には、当該キーを含むパーティションに関連付けされた暗号鍵１７０４のうち、与えられた暗号化レベルに関連付けされた暗号鍵１７０４を、リクエスト管理部１５０２に通知してもよい。
【０１６２】
リクエスト管理部１５０２は、図１８に例示するように、パーティションＩＤ（図１８の１８０１）と、有効期限（図１８の１８０２）と、暗号化レベル（図１８の１８０３）と、暗号鍵（図１８の１８０４）とを、関連付けて保持する。リクエスト管理部１５０２は、例えば、鍵管理部１０４から取得した暗号鍵と、その暗号化レベルとを関連付けて、キャッシュ鍵保持部１０２ｆに格納してもよい。なお、リクエスト管理部１５０２の具体的な構成は、上記第１の実施形態と同様としてよい。
【０１６３】
リクエスト管理部１５０２は、クライアントからＧＥＴリクエストにより指定されたキーに関連付けされたバリューを、当該バリューに設定された暗号化レベルに応じた適切な暗号鍵を用いて復号する。リクエスト管理部１５０２は、クライアントからＰＵＴリクエストにより指定されたデータセットに含まれるバリューを、当該バリューに設定された暗号化レベルに応じた適切な暗号鍵を用いて暗号化する。
【０１６４】
以下、本実施形態におけるデータ管理システム２の動作について説明する。
【０１６５】
まず、リクエスト管理部１５０２がクライアント１０５からＰＵＴリクエストを受信した場合について説明する。なお、以下の説明においては、具体例として、クライアント１０５から送信されるＰＵＴリクエストには、図１６に例示する形式のキー１６０１と、バリュー１６０２とのペア（データセット）が含まれることを想定する。
【０１６６】
リクエスト管理部１５０２は、ＰＵＴリクエストにおいて指定されたデータセットから、キーと、暗号化レベルとを抽出する。リクエスト管理部１５０２は、リクエストされたキー（あるいは、キー及び暗号化レベル）を鍵管理部１５０４に通知し、暗号鍵を取得する。係る暗号鍵は、ＰＵＴリクエストにおいて指定されたデータセットが含まれるパーティションに関連付けられた暗号鍵のうち、指定された暗号化レベルに対応する暗号鍵である。
【０１６７】
具体例として、ＰＵＴリクエストにおいて指定されたデータセット（例えば「データセットＤ」とする）が、図１７、図１８に例示するパーティションＩＤ「Ｐ１」のパーティション（以下、単に「パーティションＰ１」と称する）に含まれることを想定する。リクエスト管理部１５０２は、データセットＤに設定された暗号化レベルが「１」の場合、リクエスト管理部１５０２は、暗号鍵「ａ１」（鍵長１２８ｂｉｔ）を用いて、データセットＤに含まれるバリューを暗号化する。リクエスト管理部１５０２は、データセットＤに暗号化レベルが設定されていない場合、デフォルトの暗号化レベル（例えば「１」）に対応する暗号鍵（例えば、暗号鍵「ａ１」）を用いて、データセットＤに含まれるバリューを暗号化してもよい。デフォルトの暗号化レベルは、適宜設定されてよい。また、リクエスト管理部１５０２は、データセットＤに設定された暗号化レベルが「２」の場合、リクエスト管理部１５０２は、暗号鍵「ａ２」（鍵長２５６ｂｉｔ）を用いて、データセットＤに含まれるバリューを暗号化する。また、リクエスト管理部１５０２は、データセットＤに設定された暗号化レベルが「０」の場合、リクエスト管理部１５０２は、データセットＤに含まれるバリューを暗号化しない。上記のように、リクエスト管理部１５０２は、データセットＤに設定された暗号化レベルに応じて当該データセットＤに含まれるバリューに対して実行する暗号処理を切り替えることが可能である。
【０１６８】
リクエスト管理部１５０２は、上記暗号処理が実行されたバリューの先頭に、データセットＤに設定された暗号化レベルを配置することで、新たなバリューを作成する。データセットＤに含まれるバリューが暗号化されない場合（暗号化レベル「０」の場合）も同様に、リクエスト管理部は、当該暗号化されないバリューの先頭に、暗号化レベルを配置することで、新たなバリューを作成する。リクエスト管理部１５０２は、データセットＤのキーと、上記作成された、暗号化レベルを含むバリューとを関連付けたデータセットを指定して、データ管理部１０１にＰＵＴリクエストを送信する。
【０１６９】
係るＰＵＴリクエストを受信したデータ管理部１０１は、上記第１の実施形態と同様、当該リクエストにおいて指定されたデータセットを、ＫＶＳのパーティションに格納する。
【０１７０】
なお、リクエスト管理部１５０２は、データセットＤに含まれるバリューの暗号化に用いられる暗号鍵が、キャッシュ鍵保持部１０２ｆに格納されているか否かを確認してもよい。係る暗号鍵がキャッシュ鍵保持部１０２ｆに格納されている場合、リクエスト管理部１５０２は、係る暗号鍵を用いてデータセットＤに含まれるバリューを暗号化してよい。
【０１７１】
次に、リクエスト管理部１５０２がクライアント１０５からＧＥＴリクエストを受信した場合について説明する。
【０１７２】
クライアント１０５は、上記第１の実施形態と同様、あるキーを指定して、リクエスト管理部１５０２に対してＧＥＴリクエストを送信する。クライアント１０５は、ＧＥＴリクエストに暗号化レベルを含めずともよい。
【０１７３】
リクエスト管理部１５０２は、リクエストされたキーを指定して、データ管理部１０１にＧＥＴリクエストを送信する。リクエスト管理部１５０２は、データ管理部１０１から取得したバリューに含まれる、暗号化レベルを確認する。リクエスト管理部１５０２は、リクエストされたキー（あるいは、リクエストされたキー及び暗号化レベル）を指定して、鍵管理部１５０４から暗号鍵を取得する。係る暗号鍵は、ＧＥＴリクエストにおいて指定されたキーが含まれるパーティションに関連付けられた暗号鍵のうち、データ管理部１０１から取得したバリューに含まれる暗号化レベルに対応する暗号鍵である。リクエスト管理部１５０２は、係る暗号鍵を用いてデータ管理部１０１から取得したバリューを復号し、復号したバリューをクライアント１０５に送信する。
【０１７４】
なお、リクエスト管理部１５０２は、上記ＰＵＴリクエストの場合と同様、キャッシュ鍵保持部１０２ｆに適切な暗号鍵が格納されている場合には、係る暗号鍵を用いて、データ管理部１０１から取得したバリューを復号してもよい。
【０１７５】
本実施形態におけるデータ管理システム２のその他の処理は、上記第１の実施形態におけるデータ管理システム１と同様としてよい。
【０１７６】
上記のように構成されたデータ管理システム２は、パーティションよりも細かい粒度であるデータセットごとに、当該データセットに含まれるバリューに対して実行される暗号処理を変更可能である。なぜならば、データ管理システム２は、データセット（特にはバリュー）に設定された暗号化レベルに基づいて、当該データセットに含まれるバリューに対して実行される暗号処理を切り替えるからである。
【０１７７】
より具体的には、データ管理システム２は、例えば、データセットごとに設定された暗号化レベルに応じて、異なる強度（例えば鍵長）の暗号鍵を用いて、データセットに含まれるバリューを暗号化、または復号することが可能である。また、データ管理システム２は、例えば、データセットごとに設定された暗号化レベルに応じて、異なる暗号アルゴリズムを用いて、データセットに含まれるバリューを暗号化、または復号することが可能である。
【０１７８】
これにより、データ管理システム２は、ＫＶＳに格納されるデータセットの重要度（機密度）に応じて、データセットごとに適切なセキュリティを提供可能である。また、暗号化レベルごとに異なる暗号鍵が設定される場合、一つの暗号鍵が漏洩した場合のリスクを低減可能である。また、データ管理システム２は、上記第１の実施形態におけるデータ管理システム１と同様の構成を有することから、上記第１の実施形態と同様の効果を奏する。
【０１７９】
＜第３の実施形態＞
次に、本発明の第３の実施形態について図面を参照して説明する。図１９Ａは、本実施形態におけるデータ管理システム３の機能的な構成を例示するブロック図である。図１９Ａに例示する機能的な構成は一つの具体例であり、１以上の構成要素が統合されてもよく、各構成要素が更に分割されてもよい。また、同様を機能を実現可能な範囲で、各構成要素の配置が適宜変更されてもよい。なお、本実施形態は、上記各実施形態と適宜組み合わせれてもよい。
【０１８０】
本実施形態におけるデータ管理システム３（図１９Ａ）は、クライアント１０５に対してＤＢＭＳ（Ｄａｔａｂａｓｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）として機能するよう、上記各実施形態を拡張したシステムである。以下、説明のための具体例として、データ管理システム３が、クライアント１０５に対して関係データベース（ＲＤＢ：Ｒｅｌａｔｉｏｎａｌ  Ｄａｔａｂａｓｅ）を提供し、クライアント１０５からのＳＱＬによるクエリを処理する場合を想定する。なお、本実施形態はこれには限定されず、データ管理システム３は、ＲＤＢとは異なるスキーマによるデータベースを提供してもよい。
【０１８１】
関係データベースにおいては、格納される情報の重要性がテーブルごとに大きく異なる場合がある。本実施形態におけるデータ管理システム３は、例えば、テーブルごとに異なる暗号化レベルの暗号処理を適用可能である。以下、説明の便宜上、関係データベースに含まれるテーブルを、「ＲＤＢテーブル」と称する場合がある。
【０１８２】
まず、データ管理システム３が管理するＫＶＳに格納されるデータセットについて説明する。図２０Ａは、データ管理システム３がＫＶＳに格納するデータセットの概念的な構成を例示する説明図である。図２０Ａに例示するデータセットの構成は、関係データベースのＲＤＢテーブル格納されるデータ（テーブル形式で格納されるデータ）を、ＫＶＳに格納する一つの具体例を示す。なお、関係データベースのスキーマをＫＶＳ方式にマッピングする具体的な方法は、周知技術を用いて実現可能であることから、詳細な説明を省略する。
【０１８３】
図２０Ａに例示するように、本実施形態におけるＫＶＳに格納されるデータセットのキー（図２０Ａの２００１）は、データベースＩＤ（図２０Ａの２００１ａ）と、テーブルＩＤ（図２０Ａの２００１ｂ）と、主キー情報（図２０Ａの２００１ｃ）と、を含む。データベースＩＤ２００１ａは、関係データベースを特定可能な情報である。テーブルＩＤ２００１ｂは、関係データベースを構成するＲＤＢテーブルを特定可能な情報である。主キー情報は、あるＲＤＢテーブルに含まれる主キーを特定可能な情報である。即ち、キー２００１は、ある関係データベースを構成するＲＤＢテーブルに含まれる主キー（特定の列の値）を特定可能な情報である。キー２００１におけるデータベースＩＤ２００１ａ、テーブルＩＤ２００１ｂ、及び、主キー情報２００１ｃの具体的な配置は、適宜選択されてよい。キー２００１に関連付けされるバリュー２００２には、例えば、関係データベースにおいて、キー２００１により特定されるキーを含む行のデータが設定される。なお、バリュー２００２には、図２０Ｂに例示するように、暗号化レベル（図２０Ｂの２００１ｄ）が含まれてもよい。
【０１８４】
次に、データ管理システム３の各構成要素について説明する。上記各実施形態と同様の構成については、同様の符号を付すことにより、説明を省略する。
【０１８５】
本実施形態におけるデータ管理システム３は、上記第２の実施形態に対して、更にＳＱＬ処理部１９０１と、メタデータ管理部１９０２と、を有する。また、本実施形態におけるデータ管理システム３は、第２の実施形態におけるリクエスト管理部１５０２に対して、ＧＥＴリクエスト、及び、ＰＵＴリクエストの処理方法が拡張されたリクエスト管理部１９０３を有する。
【０１８６】
データ管理システム３は、複数のＳＱＬ処理部１９０１を用いて、仮想的なＳＱＬ層を構成してもよい。なお、図１９Ａに示す具体例では、ＳＱＬ処理部１９０１と、メタデータ管理部１９０２とが、個別の構成要素として表されているが、本実施形態はこれには限定されない。例えば、データ管理システム３においては、ＳＱＬ処理部１９０１がメタデータ管理部１９０２を含んでもよい。更に、データ管理システム３は、図１９Ｂに例示するように、リクエスト管理部１９０３が、ＳＱＬ処理部１９０１の機能を含むように構成されてもよい。
【０１８７】
ＳＱＬ処理部１９０１は、クライアント１０５から送信されたクエリ処理の要求を処理する。ＳＱＬ処理部１９０１は、クライアント１０５から送信されたＳＱＬを解析し、ＫＶＳにおけるデータ操作であるＧＥＴ処理、ＰＵＴ処理のリクエストを作成するＳＱＬ解析部１９０１ａを有する。ＳＱＬ解析部１９０１ａは、係るリクエストの作成に必要な情報を、メタデータ管理部１９０２（後述）から取得する。なお、ＳＱＬ解析部１９０１ａは、クライアント１０５から受信したクエリをメタデータ管理部１９０２に転送し、メタデータ管理部１９０２が、係るクエリに基づいて、ＫＶＳにおけるデータ操作のリクエストに作成してもよい。
【０１８８】
ＳＱＬ処理部１９０１は、リクエスト転送部１９０１ｂを有する。リクエスト転送部１９０１ｂは、クエリに基づいて作成されたＫＶＳにおけるデータ操作のリクエストを、リクエスト管理部１５０２に転送する。以上より、ＳＱＬ処理部１９０１は、ＳＱＬによるクエリをＫＶＳにおけるデータ操作に変換する機能を有する。
【０１８９】
メタデータ管理部１９０２は、メタデータ保持部１９０２ａを有する。メタデータ保持部１９０２ａは、ＳＱＬによるクエリを、ＫＶＳにおけるデータ操作のリクエストを変換する際に用いられる情報を保持する。具体的には、メタデータ保持部１９０２ａは、ＳＱＬにより操作される関係データベースのスキーマ（ＲＤＢテーブルの構造等）を表すスキーマ管理情報（後述）を保持する。スキーマ管理情報においては、関係データベースを構成する特定の要素（関係データベースのスキーマにおいて規定された要素）に対して、暗号化レベルが関連付けられる。具板的には、係る特定の要素は、例えば、関係データベースを構成するＲＤＢテーブル、ＲＤＢテーブルを構成する属性列及びレコード行、属性列あるいはレコード行を構成するデータ要素、等であってよい。メタデータ管理部１９０２は、スキーマ管理情報を、ＳＱＬ処理部１９０１に提供可能である。
【０１９０】
以下、説明のための具体例として、データ管理システム３が、図２１に例示するようなスキーマの関係データベース２１００をクライアント１０５に仮想的に提供することを想定する。なお、図２１は説明のための一つの具体例であり、本実施形態はこれには限定されない。
【０１９１】
図２１に例示する関係データベース２１００は、複数のＲＤＢテーブル（支店リスト、決済情報、イベント情報、会員情報、等）を含む。また、会員情報テーブルは、複数の属性列（顧客番号、顧客名、性別、住所、生年月日、等）と、レコード行と、により構成される。クライアント１０５は、ＳＱＬを用いて、図２１に例示する関係データベースに格納されたデータに対するアクセスを要求する。
【０１９２】
メタデータ管理部１９０２（メタデータ保持部１９０２ａ）は、図２２に例示するようなスキーマ管理情報２２００を用いて、関係データベース２１００のスキーマを表す情報を保持する。図２２に示す具体例においては、スキーマ管理情報は、関係データベース２１００を構成するＲＤＢテーブルを特定可能な情報を保持する第１スキーマ管理情報２２０１を含む。また、スキーマ管理情報２２００は、第１スキーマ管理情報２２０１において特定されたＲＤＢテーブルの構成を保持する第２スキーマ管理情報２２０２を含む。なお、図２２に例示する構成は、一つの具体例であり、本実施形態はこれには限定されない。例えば、第１スキーマ管理情報２２０１と、第２スキーマ管理情報２２０２とは統合されてもよく、より小さな単位に分解されてもよい。
【０１９３】
第１スキーマ管理情報２２０１には、以下の項目が登録される。即ち、第１スキーマ管理情報２２０１には、関係データベース２１００を特定可能な情報である「データベースＩＤ」と、当該データベースを構成するＲＤＢテーブルを特定可能な情報である「テーブルＩＤ」とが関連付けて登録される。また、第１スキーマ管理情報２２０１には、テーブルＩＤに対して、ＲＤＢテーブルの名称を表す「テーブル名」と、ＲＤＢテーブルごとに設定された「暗号化レベル」とが関連付けて登録される。データ管理システム３は、係る暗号化レベルに応じて、ＲＤＢテーブルごとに異なる暗号化処理を実行する。第１スキーマ管理情報２２０１には、上記以外のデータが更に登録されてもよい。
【０１９４】
第２スキーマ管理情報２２０２には、以下の項目が登録される。即ち、第２スキーマ管理情報２２０２には、データベースＩＤと、テーブルＩＤとが関連付けて登録される。また、第２スキーマ管理情報２２０２には、テーブルＩＤに対して、当該ＲＤＢテーブルに含まれるカラムを特定するカラム番号が関連付けて登録される。また、第２スキーマ管理情報２２０２には、カラム番号に対して、カラムの名称を表すカラム名と、カラムに設定されるデータの種類を表すデータ・タイプと、カラムが主キーであるか否かを表す主キー判定情報と、が関連付けて登録される。第２スキーマ管理情報２２０２には、上記以外のデータが更に登録されてもよい。
【０１９５】
なお、上記スキーマ管理情報２２００は、クライアント１０５に対して提供する関係データベース２１００のスキーマに応じて予め作成されてもよい。
【０１９６】
上記のような具体例において、データ管理部１０１が管理するＫＶＳに格納されるデータの一例を、図２３Ａに例示する。図２３Ａに例示するデータは、関係データベース２１００における「顧客情報テーブル」に格納されるデータに相当する。例えば、図２３Ａに示すデータセット２３０１は、図２１に示す関係データベース２１００における顧客情報テーブルの行２１０１に相当する。データセット２３０１のキーは、｛１（データベースＩＤ）、４（テーブルＩＤ）、１（主キーのカラム番号）｝である。また、データセット２３０１のバリューは、行２１０１に含まれる各属性列のデータを含む。具体的には、データセット２３０１のバリューには、行２１０１における各属性列に配置されるデータが、各属性列のカラム番号の順に配置されてもよい。この場合、各属性列のカラム番号を用いて、データセット２３０１のバリューに含まれる各データが顧客情報テーブルにおいて格納される属性列を特定可能である。なお、本実施形態におけるＫＶＳに格納されるデータセットのバリューには、上記第２の実施形態と同様、図２３Ｂに例示するように、暗号化レベルが含まれてもよい。
【０１９７】
次に、リクエスト管理部１９０３におけるＧＥＴリクエスト、及び、ＰＵＴリクエストの処理について説明する。なお、リクエスト管理部１９０３は、上記各実施形態におけるリクエスト管理部（１０２、１５０２）と同様の処理を実行可能である。
【０１９８】
上記のような前提のもと、例えば、ＳＱＬ処理部１９０１が、図２４に例示するＳＱＬによるクエリ２４０１をクライアント１０５から受信した場合を想定する。なお、クライアント１０５がＩＤ「１」のデータベースを選択して接続してることを想定し、図２４に例示するクエリではデータベースＩＤが省略されている。
【０１９９】
ＳＱＬ処理部１９０１（ＳＱＬ解析部１９０１ａ）は、係るクエリを解析し、ＫＶＳに対するＧＥＴリクエストの作成に用いられる情報を抽出する。図２４に示す具体例の場合、ＳＱＬ処理部１９０１は、例えば、テーブル名「顧客情報」（図２４の２４０１ａ）と、条件「顧客番号＝１」（図２４の２４０１ｂ）とを抽出する。ＳＱＬ処理部１９０１は、例えば、予め規定された解析ルールに基づいて、ＳＱＬによるクエリから、これらの情報を抽出してもよい。なお、ＳＱＬによるクエリを解析する方法は、周知の技術（ＳＱＬパーサ等）を用いて実現可能であることから、詳細な説明を省略する。
【０２００】
ＳＱＬ処理部１９０１は、メタデータ管理部１９０２が提供するスキーマ管理情報２２００を参照し、ＫＶＳに対するＧＥＴリクエストにおいて指定するキーを作成する。図２０Ａに例示するように、キーは、データベースＩＤ２００１ａと、テーブルＩＤ２００１ｂと、主キー情報２００１ｃとを含む。
【０２０１】
例えば、ＳＱＬ処理部１９０１は、第１スキーマ管理情報２２０１から、テーブル名「顧客情報」に対応するテーブルＩＤ「４」を特定する。また、ＳＱＬ処理部１９０１は、テーブル名「顧客情報」に関連付けされた暗号化レベルが「１」であることを特定する。ＳＱＬ処理部１９０１は、第２スキーマ管理情報２２０２から、テーブルＩＤ「４」のテーブルにおける主キーが「顧客情報」であることを特定する。これにより、ＳＱＬ処理部１９０１は、ＫＶＳのキーとして「｛１、４、１｝」を作成する。
【０２０２】
ＳＱＬ処理部１９０１は、係るキーを用いてＫＶＳに対するＧＥＴリクエストを作成し、リクエスト管理部１９０３に送信する。リクエスト管理部１９０３は、ＳＱＬ処理部から受信したＧＥＴリクエストに基づいて、上記第２の実施形態と同様の処理を実行する。即ち、リクエスト管理部１９０３は、リクエストされたキーを含むデータセットをデータ管理部１０１から取得する。リクエスト管理部１９０３は、取得したデータセットのバリューに含まれる暗号化レベルに関連付けされた暗号鍵を鍵管理部１５０４から取得し、当該バリューを復号する。
【０２０３】
なお、ＫＶＳに格納されるデータセットに暗号化レベルを含まない場合（図２０Ａ）、ＳＱＬ処理部１９０１は、作成したキーに加え、特定した暗号化レベルを指定して、リクエスト管理部１９０３にＧＥＴリクエストを送信してもよい。この場合、リクエスト管理部１９０３は、当該ＧＥＴリクエストで指定された暗号化レベルに関連付けされた暗号鍵を鍵管理部１５０４から取得し、当該バリューを復号する。
【０２０４】
ＳＱＬ処理部１９０１は、リクエスト管理部１５０２からＧＥＴリクエストの処理結果を受信する。ＳＱＬ処理部１９０１は、第２スキーマ管理情報を参照して、「顧客名」のカラム番号（この場合は「２」）を特定し、バリューに含まれる顧客名（この場合はバリューの先頭から二つ目に配置された「ＡＡＡＡＡ」）を抽出する。ＳＱＬ処理部は、抽出した顧客名を、クエリに対する処理結果として、クライアント１０５に送信する。
【０２０５】
例えば、ＳＱＬ処理部１９０１が、ＳＱＬによるクエリ２５０１（図２５）をクライアント１０５から受信した場合を想定する。クエリ２５０１においてもデータベースＩＤが省略されており、この場合のデータベースＩＤは「１」であることを想定する。
【０２０６】
ＳＱＬ処理部１９０１（ＳＱＬ解析部１９０１ａ）は、係るクエリを解析し、ＫＶＳに対するＰＵＴリクエストの作成に用いられる情報を抽出する。図２５に示す具体例の場合、ＳＱＬ処理部１９０１は、テーブル名「顧客情報」（図２５の２５０１ａ）と、「生年月日＝１９８０−１１−１４」（図２５の２５０１ｂ）と、「顧客番号＝２」（図２５の２５０１ｃ）とを抽出する。
【０２０７】
ＳＱＬ処理部１９０１は、メタデータ管理部１９０２から提供されたスキーマ管理情報２２００を参照し、ＫＶＳに対するＰＵＴリクエストにおいて指定するキーを作成する。
【０２０８】
例えば、ＳＱＬ処理部１９０１は、第１スキーマ管理情報２２０１から、データベース名「顧客情報」に対応するテーブルＩＤ「４」を特定する。また、ＳＱＬ処理部１９０１は、テーブル名「顧客情報」に関連付けされた暗号化レベルが「１」であることを特定する。メタデータ管理部１９０２は、第２スキーマ管理情報２２０２から、テーブルＩＤ「４」のテーブルにおける主キーが「顧客情報」であることを特定する。これにより、ＳＱＬ処理部１９０１は、ＫＶＳのキーとして「｛１、４、２｝」を作成する。
【０２０９】
ＳＱＬ処理部１９０１は、顧客番号が「２」に相当するデータの「生年月日」を「１９８０−１１−１４」に設定したバリューを作成する。例えば、ＳＱＬ処理部１９０１は、上記作成したキーを用いて、リクエスト管理部１９０３にＧＥＴリクエストを送信して、当該キーに関連付けされたバリューを取得する。この場合、例えば、係るバリューとして「｛２、ＢＢＢＢＢ、女、神奈川県川崎市中原区、１９８１−１１−１１、・・・｝」が得られる。ＳＱＬ処理部１９０１は、係るバリューに含まれる「生年月日」に相当するフィールドを、「１９８０−１１−１４」により更新する。ＳＱＬ処理部１９０１は、例えば、第２スキーマ管理情報に「生年月日」のカラム番号「５」を参照して、上記フィールドを特定してもよい。なお、バリューを作成する方法は上記に限定されず、ＳＱＬ処理部１９０１は、他の適切な方法を採用してもよい。ＳＱＬ処理部１９０１上記作成したバリューに、上記特定した暗号化レベル（この場合は、「１」）を挿入する。
【０２１０】
ＳＱＬ処理部１９０１は、上記作成したキーと、バリューとを用いてＫＶＳに対するＧＥＴリクエストを作成し、リクエスト管理部１９０３に送信する。リクエスト管理部１９０３は、ＳＱＬ処理部から受信したＰＵＴリクエストに基づいて、上記第２の実施形態と同様の処理を実行する。即ち、リクエスト管理部１９０３は、ＰＵＴリクエストにおいて指定されたバリューに含まれる暗号化レベルに関連付けされた暗号鍵を鍵管理部１５０４から取得し、バリューを暗号化する。そして、リクエスト管理部１９０３は、キーと、暗号化されたバリューと指定して、データ管理部１０１にＰＵＴリクエストを送信する。ＳＱＬ処理部１９０１は、暗号化されたバリューに対して暗号化レベルを挿入してもよい。この場合、データ管理部１０１が管理するＫＶＳには、例えば、図２３Ｂに例示するようなデータが格納される。暗号化されたバリューに対して暗号化レベルが挿入されない場合、図２３Ａに例示するようなデータが、データ管理部１０１が管理するＫＶＳに格納される。
【０２１１】
上記処理により、データ管理システム３は、ＲＤＢテーブルごとに異なった暗号化レベルの暗号処理を実行可能である。なぜならば、データ管理システム３においては、ＲＤＢテーブルごとに個別の暗号化レベルが設定され、ＳＱＬによるクエリに基づいて作成されたＧＥＴリクエスト、ＰＵＴリクエストを処理する際、係る暗号化レベルに応じた暗号処理が実行されるからである。
【０２１２】
データ管理システム３は、上記各実施形態と同様、ＫＶＳを分割したパーティションごとに関連付けされた個別の暗号鍵を用いて、当該パーティションに含まれるデータセットを暗号化する。また、データ管理システム３は、ＲＤＢテーブルに含まれるデータが多い場合であっても、それらのデータを、ＫＶＳにおける複数のパーティションに分散して格納することが可能である。
【０２１３】
上記暗号化レベルは、パーティションごとに設定される。関係データベースを構成するテーブルに高いセキュリティレベルが求められる場合、データ管理システム３は、パーティションごとに関連付けされた、暗号化レベルが高い暗号鍵を用いればよい。これにより、データ管理システム３は、高いセキュリティレベルを要求されるテーブルに多くのデータが含まれる場合であっても、それらのデータに関する暗号処理に要する負荷を分散可能である。具体的には、データ管理システム３は、係るデータの再暗号化に要する負荷を分散可能である。よって、データ管理システム３は、暗号処理に関する負荷の分散と、セキュリティレベルの向上とをともに実現することが可能である。
【０２１４】
また、データ管理システム３は、ＳＱＬによるクエリを発行するクライアント１０５に対して、上記各実施形態と同様の透過的な暗号処理を提供可能である。
【０２１５】
＜第３の実施形態の変形例＞
上記第３の実施形態の一部を変更した変形例について説明する。上記第３の実施形態においては、スキーマ管理情報２２００において、ＲＤＢテーブルごとに個別の暗号化レベルが設定される。本変形例におけるデータ管理システム３は、関係データベースにおけるＲＤＢテーブルを構成する列（カラム）ごとに、個別に暗号化レベルを設定可能である。
【０２１６】
図２６は、本変形例におけるデータ管理システム３の機能的な構成を例示するブロック図である。本変形例においては、リクエスト管理部２６０１が、第３の実施形態におけるＳＱＬ処理部１９０１に相当する機能を備えることを想定する。なお、本変形例は上記に限定されず、上記第３の実施形態と同様、リクエスト管理部２６０１と、ＳＱＬ処理部とが分離されてもよい。
【０２１７】
以下、具体例を用いて説明する。本変形例におけるデータ管理システム３は、図２７に例示するように、スキーマ管理情報２７００において、ＲＤＢテーブル（例えば「顧客情報テーブル」）を構成するカラムごとに個別の暗号化レベルが設定される。
【０２１８】
この場合、リクエスト管理部２６０１は、データセットのバリューに含まれる各データについて、当該データが関係データベースのＲＤＢテーブルにおいて配置されるカラム（カラム番号）を特定する。リクエスト管理部２６０１は、当該特定したカラム番号に関連付けされた暗号化レベルを参照し、当該暗号化レベルに応じた暗号鍵を鍵管理部１５０４から取得する。そして、リクエスト管理部２６０１は、取得した暗号鍵を用いて、バリューに含まれるデータごとに、個別の暗号鍵を用いて暗号処理（暗号化、あるいは復号）を実行する。
【０２１９】
これにより、本変形例におけるデータ管理システム３は、関係データベースのカラムごとに異なる暗号レベルを提供することが可能である。即ち、本変形例におけるデータ管理システム３によれば、関係データベースのカラムごとに、当該カラムに格納されるデータの重要度が異なる場合、それぞれのデータの重要度に応じて、暗号化レベルを変更することが可能である。
【０２２０】
また、本変形例におけるデータ管理システム３は、例えば、ＲＤＢテーブルを論理的に分割した部分領域ごとに、個別の暗号化レベルを設定可能である。具体的には、データ管理システム３は、ＲＤＢテーブルの特定の列に格納されたデータに基づいて、当該ＲＤＢテーブルを複数の論理的な部分領域に分割（パーティショニング）し、分割された部分領域ごとに、異なる暗号化レベルを設定する。以下、ＫＶＳにおけるパーティションと区別するため、係るテーブルをパーティショニングした部分領域を、「データベースパーティション」と称する。
【０２２１】
具体的には、データ管理システム３は、例えば、ＲＤＢテーブルにおける特定の列に格納されたデータが、定められた条件を満たすか否かに基づいて、当該ＲＤＢテーブルをパーティショニングしてもよい。係る条件は、例えば、ＲＤＢテーブルにおける特定の列に格納されたデータがとり得る値の範囲に関する条件であってもよい。また、係る条件は、例えば、特定の列に格納されたデータが、あるデータ集合（例えば、ある条件を満たすデータのリスト）に含まれるか否かを表す条件であってもよい。
【０２２２】
以下、具体例として、関係データベース２１００に含まれる顧客情報テーブルが、「顧客番号」の値に基づいて複数のデータベースパーティションに分割されることを想定する。図２８に示す具体例においては、第１スキーマ管理情報２８０１における分割カラム（図２８の２８０１ａ）に、パーティショニングに用いられるカラムの番号（この場合は「顧客番号」に相当する「１」）が設定される。また、第１スキーマ管理情報２８０１のデータ範囲（図２８の２８０１ｂ）には、一つのデータベースパーティションに割り当てられる、分割カラムのデータの範囲が設定される。図２８に示す具体例では、顧客番号の範囲に基づいて、顧客情報テーブルがデータベースパーティションに分割される。上記に限定されず、データ管理システム３は、例えば、顧客番号があるデータ集合（例えば、別途定義された重要度が高い顧客番号のリスト等）に含まれるか否かに基づいて、顧客情報テーブルをデータベースパーティションに分割してもよい。そして、図２８に示す具体例においては、データベースパーティションの範囲ごと（即ち、ＲＤＢテーブルを論理的に分割した部分領域ごと）に、暗号化レベルが設定される。
【０２２３】
この場合、リクエスト管理部２６０１は、第１スキーマ管理情報２８０１を参照して、データセットのバリューに含まれる各データについて、当該データがＲＤＢテーブルにおいて配置されるカラム（カラム番号）を特定する。これにより、リクエスト管理部２６０１は、当該バリューに含まれる、分割カラムのデータを特定する。そして、リクエスト管理部２６０１は、第１スキーマ管理情報２８０１を参照して、当該バリューに含まれる分割データの範囲に関連付けされた暗号化レベルを特定する。リクエスト管理部２６０１は、特定した暗号化レベルに応じた暗号鍵を鍵管理部１５０４から取得する。そして、リクエスト管理部２６０１は、取得した暗号鍵を用いて、バリューに関する暗号処理（暗号化、あるいは復号）を実行する。これにより、本変形例におけるデータ管理システム３は、データベースを論理的に分割したデータベースパーティションごとに異なる暗号レベルを提供することが可能である。即ち、本変形例におけるデータ管理システム３によれば、データベースパーティションごとに、格納されるデータの重要度が異なる場合、それぞれのデータベースパーティションの重要度に応じて、暗号化レベルを変更することが可能である。
【０２２４】
＜第４の実施形態＞
次に、本発明の第４の実施形態について説明する。図２９は、本実施形態におけるデータ管理システム４の機能的な構成を例示するブロック図である。なお、図２９に例示する機能的な構成は一つの具体例であり、１以上の構成要素が統合されてもよく、各構成要素が更に分割されてもよい。また、同様を機能を実現可能な範囲で、各構成要素の配置が適宜変更されてもよい。なお、本実施形態は、上記各実施形態と適宜組み合わせれてもよい。
【０２２５】
データ管理システム４は、上記各実施形態におけるデータ管理システム１乃至データ管理システム３のうちのいずれかと同様の機能を実現可能である。また、データ管理システム４におけるデータ管理部２９０１、リクエスト管理部２９０２、及び、鍵管理部２９０４は、上記実施形態におけるデータ管理システム１乃至データ管理システム４のいずれかの構成要素と、同様の機能を実現可能である。
【０２２６】
上記説明したように、ＫＶＳのパーティションは、配置リングを複数の領域に分割した場合の、一つの領域に相当する。本実施形態におけるデータ管理システム４は、複数のパーティションに分割された配置リングを、更に複数に分割する。具体的には、本実施形態におけるデータ管理システム４は、ＫＶＳのパーティションを、当該パーティションに含まれるデータセットに関する再暗号化処理を実行することなく、動的に再分割することができる。
【０２２７】
以下、図３０に示す具体例を用いて、データ管理システム４が実行するパーティションの再分割について説明する。なお、図３０は、説明のための一つの具体例であり、本実施形態はこれには限定されない。
【０２２８】
データ管理システム４は、分割前の配置リング（図３０の（Ａ）部分）を、更に複数の領域に分割する（図３０の（Ｂ））。これにより、図３０に示す具体例においては、３個のパーティション（「Ｐ１」乃至「Ｐ３」）が、６個のパーティション（「Ｐ１−１］乃至「Ｐ３−２］）に分割される。
【０２２９】
例えば、データ管理システム４におけるリクエスト管理部２９０２が、適切な契機（例えば、ＫＶＳに格納される総データ数が基準を超えた場合等）を判定し、パーティションの再分割を実行する。この場合、リクエスト管理部２９０２は、例えば、再分割後のパーティションの数と、各パーティションが割り当てられるデータ管理部２９０１とを設定あるいは所定の判断基準等に基づいて適宜決定する。
【０２３０】
再分割前のパーティションを管理するノード（データ管理部１０１）と、再分割後のパーティションを管理するノードとが異なる場合、分割前のパーティションを管理するノードから、分割後のパーティションを管理するノードに、一部のデータが転送される。なお、パーティションの分割と、ノードの再割り当ては、周知のＫＶＳにおけるノードの追加処理と同様に処理可能である。
【０２３１】
パーティションが再分割される際、本実施形態における鍵管理部２９０４は、分割前のあるパーティションに関連付けられた暗号鍵を、当該パーティションを分割した分割後の新たなパーティションに関連付ける。そして、鍵管理部２９０４は、分割後の新たなパーティションに割り当てられた各暗号鍵について、異なる更新期限を設定する。
【０２３２】
例えば、鍵管理部２９０４は、図３１に示す具体例の場合、分割前のパーティション「Ｐ１」に関連付けされた暗号鍵（「ａ１」）を、分割後のパーティション「Ｐ１−１」、「Ｐ１−２」に関連付ける。また、鍵管理部２９０４は、分割後のパーティション「Ｐ１−１」、「Ｐ１−２」に関連付けされた暗号鍵について、異なる更新期限（「２０１５−０７−１５」、「２０１５−０７−２２」）を設定する。鍵管理部２９０４は、他のパーティション（「Ｐ２」、「Ｐ３」）についても同様に処理する。
【０２３３】
以上より、パーティションが再分割された際、暗号鍵を更新する必要がないことから、リクエスト管理部２９０２は、分割前のパーティションに含まれるデータセットに関する再暗号化処理を実行する必要がない。即ち、本実施形態におけるデータ管理システム４は、パーティションに含まれるデータセットの再暗号化処理に要する処理負荷を発生させずに、パーティションを再分割することができる。
【０２３４】
また、分割後の新たなパーティションに関連付けされた暗号鍵には、それぞれ個別の更新期限が設定されることから、異なるタイミングで係る暗号鍵が更新される。即ち、分割後の新たなパーティションごとに関連付けされた暗号鍵は、異なるタイミングで更新され、それぞれが異なる暗号鍵になる。よって、本実施形態におけるデータ管理システム４は、パーティションを再分割した後、パーティションごとに異なる暗号鍵を用いて、当該パーティションに含まれるデータセットを暗号化することが可能である。
【０２３５】
以上より、データ管理システム４は、システムの運用中にＫＶＳに格納されるデータセットの増加に応じて、パーティションの数を変更（再分割）することにより、係るデータセットを暗号化する暗号鍵の数を変更可能である。このため、データ管理システム４は、例えば、ＫＶＳに格納されるデータセット数の予測値等に基づいて予め暗号鍵の数を設計する必要がなく、データセットの増加に応じて、適宜暗号鍵の数を変更可能である。
【０２３６】
＜第５の実施形態＞
次に、本発明の第５の実施形態について説明する。図３２は、本実施形態におけるデータ管理システム５の機能的な構成を例示するブロック図である。なお、図３２に例示する機能的な構成は一つの具体例であり、１以上の構成要素が統合されてもよく、各構成要素が更に分割されてもよい。また、同様を機能を実現可能な範囲で、各構成要素の配置が適宜変更されてもよい。なお、本実施形態は、上記各実施形態と適宜組み合わせれてもよい。
【０２３７】
データ管理システム５は、上記実施形態におけるデータ管理システム１乃至データ管理システム４のいずれかと同様の機能を実現可能である。また、データ管理システム５におけるデータ管理部３２０１、リクエスト管理部３２０２、及び、鍵管理部３２０４は、上記実施形態におけるデータ管理システム１乃至データ管理システム４のいずれかの構成要素と、同様の機能を実現可能である。
【０２３８】
上記各実施形態におけるデータ管理システム１乃至データ管理システム４は、主に、ＫＶＳの格納されるデータセットのバリューを暗号化する。本実施形態におけるデータ管理システム５は、上記に加え、ＫＶＳに格納されるデータセットのキーを暗号化することが可能である。
【０２３９】
データセットに含まれるキーを単純に暗号化する場合、以下のような問題を生じる可能性がある。具体的には、暗号鍵を用いてキーを暗号化した場合、暗号化される前のキーを用いて算出したハッシュ値と、暗号化後のキーを用いて算出したハッシュ値とは、値が異なる可能性がある。即ち、暗号化される前のキーを含むデータセットと、暗号化されたキーを含むデータセットとが異なるパーティションに含まれる可能性がある。
【０２４０】
また、キーの暗号化に用いられる暗号鍵が更新された場合、更新前の暗号鍵により暗号化されたキーと、更新後の暗号鍵により暗号化されたキーとは、値が異なる。よって、これらを用いて算出されるハッシュ値も異なる可能性がある。即ち、更新前の暗号鍵を用いて暗号化されたキーを含むデータセットと、更新後の暗号鍵を用いて暗号されたキーを含むデータセットとが、異なるパーティションに含まれる可能性がある。
【０２４１】
上記のように、データセットに含まれるキーを単純に暗号化した場合、暗号鍵の変更に応じて、当該キーを含むデータセットが含まれるパーティションが変更されてしまう。これにより、例えば、ある同じキーを含むデータセットが、異なるパーティションに含まれてしまう可能性がある。また、例えば、あるパーティションにデータセットが格納された後、当該データセットのキーの暗号化に用いられる暗号鍵が更新されると、当該パーティションに格納されたデータセットにアクセスできない可能性がある。
【０２４２】
係る問題を解消すべく、本実施形態におけるデータ管理システム５は、ＫＶＳに格納されるデータセットについて、暗号化される前のキーを用いてハッシュ値を算出する。これにより、データ管理システム５は、当該データセットが含まれるパーティションを特定する。更に、本実施形態におけるデータ管理システム５は、当該データセットを、特定したパーティションに格納する際に、キーと、バリューとを暗号化する。即ち、本実施形態におけるデータ管理システム５は、暗号化される前のキーを用いて、当該キーを含むデータセットが格納されるＫＶＳのパーティションを特定する。そして、データ管理システム５は、実際にＫＶＳのパーティションにデータセットを格納する際には、キーとバリューとを暗号化して格納する。
【０２４３】
以下、データ管理システム５における処理について具体的に説明する。クライアント１０５からＧＥＴリクエストを受信した場合、リクエスト管理部３２０２は、上記第１の実施形態と同様、リクエストされたキーを含むデータセットが格納されているパーティションを特定する。具体的には、リクエスト管理部３２０２には、例えば、リクエストされたキーのハッシュ値を算出し、当該ハッシュ値が割り当てられるパーティションを特定する。この際、リクエスト管理部３２０２は、暗号化される前のキーのハッシュ値を算出する。また、リクエスト管理部３２０２は、上記特定したパーティションを管理するデータ管理部３２０１を特定する。
【０２４４】
リクエスト管理部３２０２は、鍵管理部３２０４から、リクエストされたキーを鍵管理部３２０４に送信し、暗号鍵を取得する。この際、鍵管理部３２０４は、暗号化される前のキーのハッシュ値に基づいて、当該キーを含むデータセットが格納されるパーティションを特定する。そして、鍵管理部３２０４は、係るパーティションに関連付けされた暗号鍵を、リクエスト管理部３２０２に送信する。
【０２４５】
リクエスト管理部３２０２は、鍵管理部３２０４から取得した暗号鍵を用いて、リクエストされたキーを暗号化する。そして、リクエスト管理部３２０２は、暗号化したキーを指定して、上記特定したデータ管理部３２０１にＧＥＴリクエストを送信する。
【０２４６】
データ管理部３２０１は、リクエストされたキー（暗号化済）に関連付けされたバリューを検索する。データ管理部３２０１は、取得したバリューをリクエスト管理部３２０２に送信する。ＧＥＴリクエストに関するその他の処理は、上記第１の実施形態と同様としてよいので、詳細な説明を省略する。
【０２４７】
また、クライアント１０５からＰＵＴリクエストを受信した場合、リクエスト管理部３２０２は、上記第１の実施形態と同様、リクエストされたキーを含むデータセットが格納されるパーティションを特定する。具体的には、リクエスト管理部３２０２には、例えば、リクエストされたキーのハッシュ値を算出し、当該ハッシュ値が割り当てられるパーティションを特定する。この際、リクエスト管理部３２０２は、暗号化される前のキーのハッシュ値を算出する。また、リクエスト管理部３２０２は、上記特定したパーティションを管理するデータ管理部３２０１を特定する。
【０２４８】
リクエスト管理部３２０２は、鍵管理部３２０４から、リクエストされたキーを鍵管理部３２０４に送信し、暗号鍵を取得する。この際、鍵管理部３２０４は、暗号化される前のキーのハッシュ値に基づいて、当該キーを含むデータセットが格納されるパーティションを特定する。そして、鍵管理部３２０４は、係るパーティションに関連付けされた暗号鍵を、リクエスト管理部３２０２に送信する。
【０２４９】
リクエスト管理部３２０２は、鍵管理部３２０４から取得した暗号鍵を用いて、リクエストされたキーとバリューとを暗号化する。そして、リクエスト管理部３２０２は、暗号化したキーとバリューとを指定して、上記特定したデータ管理部３２０１にＰＵＴリクエストを送信する。ＰＵＴリクエストに関するその他の処理は、上記第１の実施形態と同様としてよいので、詳細な説明を省略する。
【０２５０】
上記のように構成されたデータ管理システム５は、データセットに含まれるバリューだけではなく、キーを暗号化して、ＫＶＳに格納することが可能である。更にデータ管理システム５によれば、キーの暗号化する暗号鍵が変更された場合であっても、当該キーを含むデータセットが格納されるパーティションは変更されない。なぜならば、データ管理システム５あるキーを含むデータセットが格納されるパーティションを、暗号化する前のキーを用いて算出したハッシュ値に基づいて特定するからである。
【０２５１】
＜第６の実施形態＞
次に、上記各実施形態において説明した本発明に関する基本的な実施形態である、第６の実施形態について説明する。図３３は、本実施形態におけるデータ管理システム６の機能的な構成を例示するブロック図である。
【０２５２】
本実施形態におけるデータ管理システム６は、データ管理部３３０１と、暗号鍵管理部３３０２と、暗号処理部３３０３とを備える。本実施形態におけるこれらの構成要素の間は、適切な通信方法により通信可能に接続されている。
【０２５３】
データ管理部（データ管理手段）３３０１は、データベースにおけるテーブルを構成する特定の列に含まれるデータに基づいて、当該テーブルを複数のパーティションに分割して管理する。係るデータベースは、例えば、上記説明したＫＶＳにより実現されてもよく、関係データベースにより実現されてもよい。データ管理部３３０１は、例えば、上記各実施形態におけるリクエスト管理部（１０１、１５０２、１９０３、１６０１、２９０１、及び、３２０１）、あるいは、データ管理部（１０１、２９０１、３２０１）の少なくとも一部の機能を実現可能である。以下、上記各実施形態におけるリクエスト管理部（１０１、１５０２、１９０３、１６０１、２９０１、及び、３２０１）をまとめて「リクエスト管理部」と称する。また、上記各実施形態におけるデータ管理部（１０１、２９０１、３２０１）をまとめて「データ管理部」と称する。データ管理部３３０１は、例えば、上記各実施形態におけるリクエスト管理部、あるいは、データ管理部を構成する少なくとも一部の構成要素と同様の機能を実現する構成要素を含んでもよい。
【０２５４】
暗号鍵管理部（暗号鍵管理手段）３３０２は、上記パーティションごとに、個別の暗号鍵を関連付けて保持する。係る暗号鍵管理部３３０２は、例えば、上記各実施形態における鍵管理部（１０４、１５０４、２９０４、３２０４、以下まとめて「鍵管理部」）の少なくとも一部の機能を実現可能である。係る暗号鍵管理部３３０２は、例えば、上記各実施形態における鍵管理部を構成する少なくとも一部の構成要素と同様の機能を実現する構成要素を含んでもよい。
【０２５５】
暗号処理部（暗号処理手段）３３０３は、パーティションごとに関連付けられた暗号鍵を用いて、当該パーティションに含まれるデータに関する暗号処理を実行する。係る暗号処理は、例えば、あるパーティションに含まれるデータを暗号化する処理と、暗号化されたデータを復号する処理と、を含む。係る暗号処理部３３０３は、例えば、上記各実施形態におけるリクエスト管理部、あるいは、鍵管理部の少なくとも一部の機能を実現可能である。係る暗号処理部３３０３は、例えば、上記各実施形態におけるデータ管理部あるいは鍵管理部を構成する少なくとも一部の構成要素と同様の機能を実現する構成要素を含んでもよい。
【０２５６】
本実施形態におけるデータ管理システム６は、データベースにおけるテーブルを構成する特定の列に含まれるデータに基づいて、当該テーブルを複数のパーティションに分割する。これにより、本実施形態におけるデータ管理システム６は、データベースを適切な粒度の部分的な領域（例えば、パーティション）に分割することが可能である。更に、本実施形態におけるデータ管理システム６は、分割されたパーティションごとに個別の暗号鍵を関連付けて保持する。これにより、本実施形態におけるデータ管理システム６は、分割されたパーティションごとに個別の暗号処理を実行することが可能である。以上より、本実施形態におけるデータ管理システム６は、データベースを適切な粒度の部分的な領域（例えば、パーティション）に分割し、分割された領域ごとに個別の暗号処理を実行することが可能である。
【０２５７】
＜ハードウェア及びソフトウェア・プログラム（コンピュータ・プログラム）の構成＞
以下、上記説明した各実施形態を実現可能なハードウェア構成について説明する。
【０２５８】
以下の説明においては、上記各実施形態において説明したデータ管理システム（１乃至６）をまとめて、単に「データ管理システム」と称する。また、データ管理システムに含まれる各構成要素を、単に「データ管理システムの構成要素」と称する。
【０２５９】
上記各実施形態において説明したデータ管理システムは、一つ又は複数の専用のハードウェア装置により構成されてもよい。その場合、上記各図（図２、図３、図１５、図１９Ａ、図１９Ｂ、図２６、図２９、図３２、及び図３３）に示した各構成要素は、その一部又は全部を統合したハードウェア（処理ロジックを実装した集積回路あるいは記憶デバイス等）を用いて実現されてもよい。
【０２６０】
データ管理システムが専用のハードウェアにより実現される場合、係るデータ管理システムの構成要素は、例えば、それぞれの機能を提供可能な回路機構（例えば、ＳｏＣ（Ｓｙｓｔｅｍ  ｏｎ  ａ  Ｃｈｉｐ）等の集積回路）を用いて実装されてもよい。この場合、データ管理システムの構成要素が保持するデータは、例えば、ＳｏＣとして統合されたＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）領域やフラッシュメモリ領域、あるいは、当該ＳｏＣに接続された記憶デバイス（半導体記憶装置等）に記憶されてもよい。また、この場合、データ管理システムの各構成要素を接続する通信回線としては、周知の通信バスを採用してもよい。また、各構成要素を接続する通信回線はバス接続に限らず、それぞれの構成要素間をピアツーピアで接続してもよい。データ管理システムを複数のハードウェア装置により構成する場合、それぞれのハードウェア装置の間は、適切な通信手段（有線、無線、またはそれらの組み合わせ）により通信可能に接続されていてもよい。
【０２６１】
また、上述したデータ管理システム又はその構成要素は、図３４に例示するような汎用のハードウェアと、係るハードウェアによって実行される各種ソフトウェア・プログラム（コンピュータ・プログラム）とによって構成されてもよい。この場合、データ管理システムは、一以上の適切な数の、汎用のハードウェア装置及びソフトウェア・プログラムにより構成されてもよい。即ち、データ管理システムを構成する構成要素ごとに、個別のハードウェア装置が割り当てられてもよく、複数の構成要素が、一つのハードウェア装置を用いて実現されてもよい。
【０２６２】
図３４における演算装置３４０１は、汎用のＣＰＵ（中央処理装置：Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）やマイクロプロセッサ等の演算処理装置である。演算装置３４０１は、例えば後述する不揮発性記憶装置３４０３に記憶された各種ソフトウェア・プログラムを記憶装置３４０２に読み出し、係るソフトウェア・プログラムに従って処理を実行してもよい。例えば、上記各実施形態におけるデータ管理システムの構成要素は、演算装置３４０１により実行されるソフトウェア・プログラムとして実現されてもよい。
【０２６３】
記憶装置３４０２は、演算装置３４０１から参照可能な、ＲＡＭ等のメモリ装置であり、ソフトウェア・プログラムや各種データ等を記憶する。なお、記憶装置３４０２は、揮発性のメモリ装置であってもよい。
【０２６４】
不揮発性記憶装置３４０３は、例えば磁気ディスクドライブや、フラッシュメモリによる半導体記憶装置のような、不揮発性の記憶装置である。不揮発性記憶装置３４０３は、各種ソフトウェア・プログラムやデータ等を記憶可能である。
【０２６５】
ネットワークインタフェース３４０６は、通信ネットワークに接続するインタフェース装置であり、例えば有線及び無線のＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）接続用インタフェース装置や、ＳＡＮ接続用インタフェース装置等を採用してもよい。
【０２６６】
ドライブ装置３４０４は、例えば、後述する記録媒体３４０５に対するデータの読み込みや書き込みを処理する装置である。
【０２６７】
記録媒体３４０５は、例えば光ディスク、光磁気ディスク、半導体フラッシュメモリ等、データを記録可能な記録媒体である。
【０２６８】
入出力インタフェース３４０７は、外部装置との間の入出力を制御する装置である。
【０２６９】
上述した各実施形態を例に説明した本発明におけるデータ管理システム（あるいはその構成要素）は、例えば、図３４に例示するハードウェア装置に対して、上記各実施形態において説明した機能を実現可能なソフトウェア・プログラムを供給することにより、実現されてもよい。より具体的には、係る装置に対して供給したソフトウェア・プログラムを、演算装置３４０１が実行することによって、本発明が実現されてもよい。この場合、係るハードウェア装置で稼働しているオペレーティングシステムや、データベース管理ソフト、ネットワークソフト、仮想環境基盤等のミドルウェアなどが各処理の一部を実行してもよい。
【０２７０】
上述した各実施形態において、上記各図に示した各部は、上述したハードウェアにより実行されるソフトウェア・プログラムの機能（処理）単位である、ソフトウェアモジュールとして実現することができる。ただし、これらの図面に示した各ソフトウェアモジュールの区分けは、説明の便宜上の構成であり、実装に際しては、様々な構成が想定され得る。
【０２７１】
図２、図３、図１５、図１９Ａ、図１９Ｂ、図２６、図２９、図３２、及び図３３に例示したデータ管理システムの各構成要素をソフトウェアモジュールとして実現する場合、例えば、これらのソフトウェアモジュールが不揮発性記憶装置３４０３に記憶される。そして、演算装置３４０１がそれぞれの処理を実行する際に、これらのソフトウェアモジュールを記憶装置３４０２に読み出す。
【０２７２】
また、これらのソフトウェアモジュールは、共有メモリやプロセス間通信等の適宜の方法により、相互に各種データを伝達できるように構成されてもよい。このような構成により、これらのソフトウェアモジュールは、相互に通信可能に接続可能である。
【０２７３】
更に、上記ソフトウェア・プログラムは、記録媒体３４０５に記録されてもよい。この場合、上記ソフトウェア・プログラムは、上記データ管理システム等の出荷段階、あるいは運用段階等において、適宜ドライブ装置３４０４を通じて不揮発性記憶装置３４０３に格納されるよう構成されてもよい。
【０２７４】
なお、上記の場合において、上記ハードウェアへの各種ソフトウェア・プログラムの供給方法は、出荷前の製造段階、あるいは出荷後のメンテナンス段階等において、適当な治具を利用して当該装置内にインストールする方法を採用してもよい。また、各種ソフトウェア・プログラムの供給方法は、インターネット等の通信回線を介して外部からダウンロードする方法等のように、現在では一般的な手順を採用してもよい。
【０２７５】
そして、このような場合において、本発明は、係るソフトウェア・プログラムを構成するコード、あるいは係るコードが記録されたところの、コンピュータ読み取り可能な記録媒体によって構成されると捉えることができる。この場合、係る記録媒体は、ハードウェア装置と独立した媒体に限らず、ＬＡＮやインターネットなどにより伝送されたソフトウェア・プログラムをダウンロードして記憶又は一時記憶した記憶媒体を含む。
【０２７６】
また、上述したデータ管理システムは、図３４に例示するハードウェア装置を仮想化した仮想化環境と、当該仮想化環境において実行される各種ソフトウェア・プログラム（コンピュータ・プログラム）とによって構成されてもよい。この場合、図３４に例示するハードウェア装置の構成要素は、当該仮想化環境における仮想デバイスとして提供される。なお、この場合も、図３４に例示するハードウェア装置を物理的な装置として構成した場合と同様の構成にて、本発明を実現可能である。
【０２７７】
以上、本発明を、上述した模範的な実施形態に適用した例として説明した。しかしながら、本発明の技術的範囲は、上述した各実施形態に記載した範囲には限定されない。当業者には、係る実施形態に対して多様な変更又は改良を加えることが可能であることは明らかである。そのような場合、係る変更又は改良を加えた新たな実施形態も、本発明の技術的範囲に含まれ得る。更に、上述した各実施形態、あるいは、係る変更又は改良を加えた新たな実施形態を組み合わせた実施形態も、本発明の技術的範囲に含まれ得る。そしてこのことは、特許請求の範囲に記載した事項から明らかである。
【符号の説明】
【０２７８】
１  データ管理システム
１０１  データ管理部
１０１ａ  データ格納部
１０１ｂ  通信部
１０１ｃ  全キー検索部
１０２  リクエスト管理部
１０２ａ  クライアント通信部
１０２ｂ  データ管理通信部
１０２ｃ  リクエスト処理部
１０２ｄ  暗号処理部
１０２ｅ  キャッシュデータ保持部
１０２ｆ  キャッシュ鍵保持部
１０２ｇ  鍵ライフサイクル管理部
１０２ｈ  鍵管理通信部
１０２ｉ  再暗号化処理部
１０３  認証部
１０４  鍵管理部
１０４ａ  鍵保持部
１０４ｂ  鍵検索部
１０４ｃ  更新期限管理部
１０４ｄ  通信部
１０５  クライアント
１５０２  リクエスト管理部
１５０４  鍵管理部
１９０１  ＳＱＬ処理部
１９０２  メタデータ管理部
１９０３  リクエスト管理部
２６０１  リクエスト管理部
２９０１  データ管理部
２９０２  リクエスト管理部
２９０４  鍵管理部
３２０１  データ管理部
３２０２  リクエスト管理部
３２０４  鍵管理部
３３０１  データ管理部
３３０２  暗号鍵管理部
３３０３  暗号処理部
【図１】
2017130705.tif 000003
【図２】
2017130705.tif 000004
【図３】
2017130705.tif 000005
【図４】
2017130705.tif 000006
【図５】
2017130705.tif 000007
【図６】
2017130705.tif 000008
【図７】
2017130705.tif 000009
【図８】
2017130705.tif 000010
【図９Ａ】
2017130705.tif 000011
【図９Ｂ】
2017130705.tif 000012
【図９Ｃ】
2017130705.tif 000013
【図１０】
2017130705.tif 000014
【図１１】
2017130705.tif 000015
【図１２】
2017130705.tif 000016
【図１３】
2017130705.tif 000017
【図１４】
2017130705.tif 000018
【図１５】
2017130705.tif 000019
【図１６】
2017130705.tif 000020
【図１７】
2017130705.tif 000021
【図１８】
2017130705.tif 000022
【図１９Ａ】
2017130705.tif 000023
【図１９Ｂ】
2017130705.tif 000024
【図２０Ａ】
2017130705.tif 000025
【図２０Ｂ】
2017130705.tif 000026
【図２１】
2017130705.tif 000027
【図２２】
2017130705.tif 000028
【図２３Ａ】
2017130705.tif 000029
【図２３Ｂ】
2017130705.tif 000030
【図２４】
2017130705.tif 000031
【図２５】
2017130705.tif 000032
【図２６】
2017130705.tif 000033
【図２７】
2017130705.tif 000034
【図２８】
2017130705.tif 000035
【図２９】
2017130705.tif 000036
【図３０】
2017130705.tif 000037
【図３１】
2017130705.tif 000038
【図３２】
2017130705.tif 000039
【図３３】
2017130705.tif 000040
【図３４】
2017130705.tif 000041