JP6449093B2 - 秘匿化データベースシステム及び秘匿化データ管理方法 - Google Patents

Description

本発明は、データを暗号化して他者に預託する秘匿化データベースシステムに関する。

近年、ストレージの低価格化及び大規模化、及びネットワークの整備などの様々な情報技術の発展に伴い、蓄積される情報量が増大している。このような状況の下、いわゆるビックデータを利活用しようという動きが活発化している。

ところで、多種多様な医療情報、経営情報、個人情報が取り扱われる医療機関においては、機関全体のビックデータの利活用によるグループ全体のリソース及び業務の最適化が有効である。医療機関にとって、高度なビッグデータ分析基盤は本来業務とは異なり過大な投資は難しいため、効果に応じた投資が可能なクラウド上のビッグデータ分析基盤の利用が適する。

ただし、医療情報、個人情報は極めて機微性が高く、クラウド側でのデータの復元やデータ持ち出し等の情報漏えいリスクに対処する必要がある。その対処法の一つとして、病院側のみがデータの秘匿化の鍵を持つことにより、クラウド上でのデータの復元が不可能とし、クラウド側でのデータの持ち出しリスクを低減する秘匿化データベースシステムが有効である。さらに、暗号化したままでのデータの検索を可能とする検索可能暗号技術などを用いることにより、データセンタでデータを復号化することなく、検索及び分析を可能とすることが有効である。

本技術の背景技術として、国際公開２０１３／０６９７７６号公報（特許文献１）、国際公開２０１２／０７７５４１号公報（特許文献２）がある。特許文献１には、データベースシステムにネットワークを介して接続するユーザシステムであって、暗号化と復号化のための鍵情報を管理する手段と、データ及び／又はメタデータの安全性設定情報を記憶する記憶部と、データベース操作命令に対して暗号化の必要の有無を判別し、暗号化が必要な場合、データ及び／又はメタデータに応じた暗号化アルゴリズムを選択して暗号化した上でデータベース制御手段に送信してデータベースの操作を実行し、暗号化が不要な場合、前記データベース操作命令をデータベース制御手段に送信してデータベース操作を実行し、前記データベース制御手段から送信された処理結果を受け取り、前記処理結果のデータ及び／又はメタデータの復号化あるいは変換が必要な場合、必要な復号化あるいは変換を行い、前記データベース操作命令の応答として返すアプリケーション応答手段と、データベースに格納するデータの安全性情報を設定する安全性設定手段を備えるシステムが開示されている。

また、特許文献２には、データを預かるＤＢサーバと、ＤＢサーバにデータを預託する登録クライアントと、ＤＢサーバにデータを検索させる検索クライアントがネットワーク経由で連携する検索可能暗号処理ステムであって、登録クライアントは、ハッシュ値と準同型関数を用いたマスクによる確率的暗号化方式を用いて、暗号化したデータをサーバに預託し、検索クライアントは、検索クエリの暗号化に準同型関数を用いたマスクによる確率的暗号化を用い、ＤＢサーバにマスクを解除させずに、かつ、ＤＢサーバに検索に該当するデータの出現頻度が漏洩しないよう、検索クエリと該当しないデータを検索結果として出力させるシステムが開示されている。

国際公開２０１３／０６９７７６号公報 国際公開２０１２／０７７５４１号公報

ところで、通常のデータベースにおける大容量データの高速検索の手段の一つとして、データベースのインデックス機能がある。インデックス機能は、特定のカラムに対して索引に相当するデータ構造を持つことで、検索対象範囲を絞り込むことにより、高速な検索を可能とする。しかし、ユーザ側のみが鍵を持つシステムの場合、暗号化されているデータの検索においては、通常のデータベースのインデックス機能が有効でない場合がある。その場合、多量のデータの高速検索ができない。従来技術では、通常のインデックス機能が有効でない暗号化状態のデータベースにおいて、多量のデータの高速検索を可能とする手段は開示されていない。

また、通常のデータベースのインデックス機能は、検索対象となる属性値の出現頻度によって有効な場合と有効ではない場合がある。例えば、あるデータベース製品は、検索対象の属性値の頻度が、その属性の属性値数に対して一定の割合を超えているか否かによって、インデックスの使用要否を自動的に判断する。しかし、頻度分布が分からないようにデータが暗号化されている場合、クラウド側では頻度分布によるインデックスの使用要否を判断できない。

本発明は、以上の点を考慮してなされたもので、暗号化された多量のデータの高速検索を可能とする秘匿化データベースシステムを提案するものである。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、ユーザシステムが所有する元データをデータ所有者が管理する暗号鍵によって暗号化した暗号化データが預託されるセンタシステムによって構成される秘匿化データベースシステムであって、前記センタシステムは、前記預託された暗号化データを元データに復号化することなく検索する機能を提供するものであって、前記ユーザシステムは、前記暗号化データを処理するための平文のＳＱＬ文を、前記暗号化データを前記センタシステム上で処理する暗号化ＳＱＬ文に変換し、前記センタシステムから受信した暗号化データの処理結果を復号化するデータベースラッパー部を有し、前記センタシステムは、前記暗号化データを格納する暗号化預託データテーブルと、前記元データのハッシュ値を暗号化した暗号化ハッシュ値を格納し、前記暗号化預託データテーブルの検索範囲を限定するために参照されるハッシュテーブルと、前記暗号化預託データテーブルに格納された暗号化データを検索するデータベース制御部と、前記暗号化データと検索クエリとの一致を判定する暗号文一致比較部と、を有し、前記データベースラッパー部は、前記暗号化データを検索するための平文のＳＱＬ文を、前記暗号化データを前記センタシステム上で処理する暗号化ＳＱＬ文に変換し、前記センタシステムが受信した前記暗号化ＳＱＬ文を実行することによって、前記データベース制御部が前記ハッシュテーブルを検索して前記暗号化データの範囲を限定し、前記暗号文一致比較部が前記限定された範囲の暗号化データについて前記暗号化ＳＱＬ文が指示する一致比較を行い、前記データベース制御部が前記暗号化ＳＱＬ文の実行結果を前記ユーザシステムへ送信し、前記データベースラッパー部は、前記データベース制御部から受信したＳＱＬ文の実行結果を復号化し、前記暗号化データの検索結果を出力する。

本発明の代表的な形態によれば、暗号化した多量のデータを高速で検索することができる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

本発明の第一の実施例の秘匿化データベースシステムのハードウェア及びソフトウェア構成を示すブロック図である。 第一の実施例のデータベースラッパー部の論理構成を示すブロック図である。 第一の実施例のユーザ定義機能部の論理構成を示すブロック図である。 第一の実施例のメインテーブルのデータ構造を示す図である。 第一の実施例の秘匿インデックスマップテーブルのデータ構造を示す図である。 第一の実施例の暗号化メインテーブルのデータ構造を示す図である。 第一の実施例のハッシュテーブルのデータ構造を示す図である。 第一の実施例の秘匿インデックス検索クエリ生成処理を示すフローチャートである。 第一の実施例の秘匿インデックス検索処理を示すフローチャートである。 第一の実施例の検索結果復号処理を示すフローチャートである。 第一の実施例の秘匿インデックス挿入クエリ生成処理を示すフローチャートである。 第一の実施例の秘匿インデックス挿入処理を示すフローチャートである。 第一の実施例の秘匿インデックス更新クエリ生成処理を示すフローチャートである。 第一の実施例の更新対象ＩＤリスト取得処理を示すフローチャートである。 第一の実施例の秘匿インデックス用更新対象ＩＤテーブル取得処理を示すフローチャートである。 第一の実施例の秘匿インデックス更新処理を示すフローチャートである。 第一の実施例の秘匿インデックス削除クエリ生成処理を示すフローチャートである。 第一の実施例の秘匿インデックス削除処理を示すフローチャートである。 第二の実施例の秘匿化データベースシステムのハードウェア及びソフトウェア構成を示すブロック図である。 第二の実施例のデータベースラッパー部の論理構成を示すブロック図である。 第二の実施例のユーザ定義機能部の論理構成を示すブロック図である。 第二の実施例の秘匿インデックスマップテーブルのデータ構造を示す図である。 第二の実施例の暗号化メインテーブルのデータ構造を示す図である。 第二の実施例のマッピングテーブルのデータ構造を示す概念図である。 第二の実施例のハッシュテーブルのデータ構造を示す図である。 第二の実施例の秘匿インデックス検索クエリ生成処理を示すフローチャートである。 第二の実施例の秘匿インデックス検索処理を示すフローチャートである。 第二の実施例の秘匿インデックス挿入クエリ生成処理を示すフローチャートである。 第二の実施例の秘匿インデックス挿入処理を示すフローチャートである。 第二の実施例の秘匿インデックス更新クエリ生成処理を示すフローチャートである。 第二の実施例の秘匿インデックス用更新対象ＩＤテーブル取得処理を示すフローチャートである。 第二の実施例の秘匿インデックス更新処理を示すフローチャートである。 第二の実施例の秘匿インデックス削除クエリ生成処理を示すフローチャートである。 第二の実施例の秘匿インデックス削除処理を示すフローチャートである。 第二の実施例のマッピングテーブルの並べ替えクエリ生成処理を示すフローチャートである。 第二の実施例のマッピングテーブルの並べ替え処理を示すフローチャートである。 第三の実施例のデータベースラッパー部の論理構成を示すブロック図である。 第三の実施例の頻度分布平準化前のマッピングテーブルのデータ構造を示す図である。 第三の実施例の頻度分布平準化後のマッピングテーブルのデータ構造を示す図である。 第三の実施例のマップＩＤ頻度分布平準化クエリ生成処理を示すフローチャートである。 第三の実施例のマップＩＤ頻度分布平準化処理を示すフローチャートである。

以下、図面を参照して本発明の実施の形態を詳述する。

（１）第一の実施例
（１−１）第一の実施例による情報処理システムの構成
図１は、本発明の第一の実施例の秘匿化データベースシステム１のハードウェア及びソフトウェア構成を示すブロック図である。秘匿化データベースシステム１は、ユーザシステム側サーバ３が持つ元データを暗号化して、クラウドシステム側サーバ４に預託し、さらに、クラウドシステム側サーバ４が預託されたデータに対する検索機能及び分析機能をユーザシステム側サーバ３に提供するシステムである。

秘匿化データベースシステム１は、図１に示すように、ユーザ端末２、ユーザシステム側サーバ３、及びクラウドシステム側サーバ４によって構成される。ユーザ端末２とユーザシステム側サーバ３とは、ユーザの事業所内のローカルエリアネットワーク等からなるユーザ内部ネットワーク５を介して接続されている。ユーザシステム側サーバ３とクラウドシステム側サーバ４とは、ユーザ内部ネットワーク５、インターネットやキャリアが提供するワイドエリアネットワーク等からなる外部ネットワーク６及びクラウド事業者のデータセンタ内のローカルエリアネットワーク等からなるクラウド内部ネットワーク７を介して接続される。

ユーザ端末２は、エンドユーザが使用するパーソナルコンピュータ、タブレット端末、スマートフォン等の装置であり、表示装置、入力装置、不揮発性記憶装置（磁気ディスクドライブ、ＳＳＤ）、メモリ、ＣＰＵ及びネットワークインタフェース等を有する。ユーザ端末２は、エンドユーザが入力装置から入力した要求を暗号化していない平文でユーザシステム側サーバ３のアプリケーション部２１１に送信し、当該要求に対する結果を受信し、表示装置に結果を表示し、福発性記憶装置に結果を記憶する。

ユーザシステム側サーバ３は、メモリ２１０、表示装置２２０、入力装置２３０、ＣＰＵ２４０、ネットワークインタフェース装置（ＮＩＣ）２５０及びディスク装置２６０などを有する計算機である。ユーザシステム側サーバ３は、ユーザ端末２から受信した平文の要求から暗号文のＳＱＬを生成し、クラウドシステム側サーバ４へ送信し、ＳＱＬ文に対する暗号文による結果を受信し、受信した暗号文を復号化し、平文の結果をユーザ端末２へ送信する。

アプリケーション部２１１は、ＣＰＵ２４０が、ディスク装置２６０、外部記憶媒体又はユーザ内部ネットワーク５経由でアプリケーションプログラムをメモリ２１０に読み出し、ＣＰＵ２４０が読み出したアプリケーションプログラムを実行することによって構成される。アプリケーション部２１１は、ユーザ端末２から受信した平文の要求を処理し、処理の過程で必要な平文のＳＱＬ文をデータベースラッパー部２１２へ送信し、ＳＱＬ文に対する平文の結果を受信する。

データベースラッパー部２１２は、ＣＰＵ２４０が、ディスク装置２６０、外部媒体又はユーザ内部ネットワーク５経由でプログラムをメモリ２１０に読み出し、ＣＰＵ２４０が読み出したプログラムを実行することによって構成される。データベースラッパー部２１２は、アプリケーション部２１１から受信した平文のＳＱＬを、ディスク装置２６０の秘匿インデックスマップテーブル２６２の情報を利用して暗号文のＳＱＬに変換し、データベースインタフェース部２１３へ送信する。さらに、ＳＱＬ文に対する暗号文による結果をデータベースインタフェース部２１３から受信し、平文に復号化して、平文の結果をアプリケーション部２１１へ送信する。

データベースインタフェース部２１３は、ＣＰＵ２４０が、ディスク装置２６０、外部媒体又はユーザ内部ネットワーク５経由でプログラムをメモリ２１０に読み出し、ＣＰＵ２４０が読み出したプログラムを実行することによって構成される。データベースインタフェース部２１３は、データベースラッパー部２１２から受信した暗号文のＳＱＬをクラウドシステム側サーバ４へ送信し、クラウドシステム側サーバ４から暗号文による結果を受信して、データベースラッパー部２１２へ送信する。

ディスク装置２６０は、ハードディスクドライブ又はソリッドステートドライブなどの不揮発性記憶装置から構成され、メインテーブル２６１及び秘匿インデックスマップテーブル２６２を記憶する。メインテーブル２６１は、クラウドシステム側サーバ４へ預託する前の平文の情報を格納する。秘匿インデックスマップテーブル２６２は、クラウドシステム側サーバ４上の暗号化メインテーブル３６１の情報へ高速にアクセスするための関連情報を格納する。

クラウドシステム側サーバ４は、ユーザシステム側サーバ３と同様に、メモリ３１０、表示装置３２０、入力装置３３０、ＣＰＵ３４０、ネットワークインタフェース装置（ＮＩＣ）３５０及びディスク装置３６０などを備えた計算機等から構成される。クラウドシステム側サーバ４は、ユーザシステム側サーバ３から受信した暗号文のＳＱＬを実行し、得られた暗号文の実行結果をユーザシステム側サーバ３へ送信する。

データベース制御部３１１は、ＣＰＵ３４０が、ディスク装置３６０、外部媒体あるいはクラウド内部ネットワーク７経由でプログラムをメモリ３１０に読み出し、読み出したプログラムをＣＰＵ３４０が実行することによって構成される。データベース制御部３１１は、ユーザシステム側サーバ３から暗号文のＳＱＬを受信し、ハッシュテーブル３６２の情報とユーザ定義機能部３１２の機能を利用して暗号化メインテーブル３６１に対して暗号文のＳＱＬを実行し、得られた暗号文による結果をユーザシステム側サーバ３へ送信する。

ユーザ定義機能部３１２は、ＣＰＵ３４０が、ディスク装置３６０、外部媒体あるいはクラウド内部ネットワーク７経由でプログラムをメモリ３１０に読み出し、読み出したプログラムをＣＰＵ３４０が実行することによって構成される。ユーザ定義機能部３１２は、データベース制御部３１１からユーザ定義機能への入力情報を受け、異なる暗号文の元の平文が一致しているか否かを判定するユーザ定義機能による処理を実行し、処理結果をデータベース制御部３１１へ出力する。

ディスク装置３６０は、ハードディスクドライブ又はソリッドステートドライブなどの不揮発性記憶装置から構成され、暗号化メインテーブル３６１及びハッシュテーブル３６２を記憶する。暗号化メインテーブル３６１は、メインテーブル２６１を暗号化して格納する。ハッシュテーブル３６２は、暗号化メインテーブル３６１に対するアクセスを高速化するための情報を格納する。

図２は、データベースラッパー部２１２の論理構成を示す。データベースラッパー部２１２は、暗号化部２１２１、検索クエリ生成部２１２２、復号化部２１２４、鍵管理部２１２５、ＳＱＬ変換部２１２６、及び秘匿インデックス用ＳＱＬ変換部２１２７で構成される。

暗号化部２１２１は、平文及び鍵管理部２１２５から取得した暗号化鍵を入力とし、入力された平文を暗号文に変換して、暗号文を出力する。

検索クエリ生成部２１２２は、暗号化メインテーブル３６１に格納された暗号化データと検索データとの一致検索に必要な検索クエリを生成する。すなわち、検索クエリ生成部２１２２は、平文の検索データ及び鍵管理部２１２５から取得した暗号化鍵及び検索用鍵を入力とし、検索データと一致する暗号化メインテーブル３６１の暗号化データを識別するための入力情報となる暗号化検索クエリを生成し、暗号化検索クエリを出力する。

ハッシュ値生成部２１２３は、平文データと生成するハッシュ値の種類数を指定するハッシュ長を入力とし、平文データをハッシュ関数で処理した平文のハッシュ値を取得し、平文のハッシュ値を出力する。

復号化部２１２４は、暗号文及び鍵管理部２１２５から取得した暗号化鍵を入力とし、入力された暗号文を平文に変換して、平文を出力する。

鍵管理部２１２５は、暗号化、復号化及び検索クエリ生成に用いられる鍵情報を管理する。すなわち、鍵管理部２１２５は、暗号化鍵データ及び検索用鍵データをメモリ２１０及び／又はディスク装置２６０に格納し、暗号化部２１２１、検索クエリ生成部２１２２又は復号化部２１２４からの鍵の要求に対して、暗号化鍵データ又は検索用鍵データを提供する。なお、暗号化鍵データ及び検索用鍵データの両方を提供してもよい。

ＳＱＬ変換部２１２６は、暗号化メインテーブル３６１のみに対し処理を行うＳＱＬを作成する。すなわち、ＳＱＬ変換部２１２６は、平文のＳＱＬを入力とし、検索データを暗号化検索クエリに置き換え、挿入又は更新する平文データを暗号文データに置き換え、一致比較文をユーザ定義機能部３１２の暗号文一致比較部３１２１を呼び出すユーザ定義関数呼出文に置き換えた暗号化ＳＱＬ文を生成する。そして、暗号化ＳＱＬ文をデータベースインタフェース部２１３へ送信する。

秘匿インデックス用ＳＱＬ変換部２１２７は、暗号化メインテーブル３６１とハッシュテーブル３６２に対する処理を行う。すなわち、秘匿インデックス用ＳＱＬ変換部２１２７は、平文のＳＱＬを入力とし、検索データを暗号化検索クエリに置き換え、検索データからハッシュ値を生成する。そして、生成されたハッシュ値を暗号化検索クエリに置き換え、挿入又は更新する平文データを暗号文データに置き換え、挿入又は更新する平文データから平文ハッシュ値を生成する。そして、生成された平文ハッシュ値を暗号文ハッシュ値に置き換え、ハッシュテーブル３６２及び暗号化メインテーブル３６１に対して参照、挿入、更新及び削除の少なくとも一つの処理を行う暗号化ＳＱＬ文を生成する。そして、暗号化ＳＱＬ文をデータベースインタフェース部２１３へ送信する。

図３は、ユーザ定義機能部３１２の論理構成を示す。ユーザ定義機能部３１２は、暗号文一致比較部３１２１で構成される。暗号文一致比較部３１２１は、検索用鍵データをメモリ３１０及び／又はディスク装置３６０に格納し、データベース制御部３１１から暗号化検索クエリ及び暗号文データの入力を受け、検索用鍵を用いて暗号化検索クエリを暗号文データとの一致比較が可能な一致検索クエリに復号し、一致検索クエリと暗号化データとを一致比較する。そして、一致検索クエリと暗号化データとが一致する場合、一致を示す値（例えば、”１”）を出力し、一致検索クエリと暗号化データとが一致しない場合、不一致を示す値（例えば、”０”）を出力する。

図４は、暗号化して預託される前の平文データを示すメインテーブル２６１のデータ構造を示す。メインテーブル２６１は、ユーザシステム側サーバ３のディスク装置２６０又はメモリ２１０に格納される。メインテーブル２６１は、ディスク装置２６０及びメモリ２１０の両方に格納されてもよい。本実施例では病院のデータであり、スキーマ名が”医療情報”であり、テーブル名が”患者情報”であるテーブルを想定している。メインテーブル２６１は、患者を一意に特定する番号である”患者番号”カラム、患者の名前である”名前”カラム、及び患者の疾病の種類を示す”病名”カラムを含む。例えば、レコード２６１１は、患者番号が”００００００１”の患者の名前は”鈴木”であり、病名は”高血圧症”であることを示す。メインテーブル２６１は患者番号が”００００００１”から”１００００００”まで、１００万件のレコードを格納している。

図５は、検索を高速化するハッシュテーブル３６２と暗号化メインテーブル３６１のマップＩＤカラムとを関連付ける情報を格納する秘匿インデックスマップテーブル２６２のデータ構造を示す。秘匿インデックスマップテーブル２６２は、ユーザシステム側サーバ３のディスク装置２６０又はメモリ２１０に格納される。秘匿インデックスマップテーブル２６２は、ディスク装置２６０及びメモリ２１０の両方に格納されてもよい。本実施例では病院のデータを想定しており、秘匿インデックスマップテーブル２６２は、病院のテーブルの種類を分類する”スキーマ名”カラムは、”医療情報”あるいは”経営情報”などが存在することを示す。個々のテーブルの名前を示す”暗号化メインテーブル名”カラムは”患者情報”テーブル、”薬剤情報”テーブル、”投薬情報”テーブル、”医事会計”テーブルなどが存在することを示す。”カラム名”のカラムは、そのカラムに対応するハッシュテーブル３６２が存在すること、及び暗号化メインテーブル３６１がハッシュテーブル３６２との関連を示す”マップＩＤ名”カラムを含むことを示す。”マップＩＤカラム名”カラム及び”ハッシュテーブル名”は、暗号化メインテーブル３６１が備える”ＭａｐＩＤ−１”カラムなどのマップＩＤカラム名と、ハッシュテーブル３６２（ＨＴ１）などのハッシュテーブル３６２との関連を示す。なお、ハッシュテーブル３６２は、インデックス化しても検索が高速化されないカラムに対しては生成しない。具体的には、同一の属性値が大部分を占めるようなカラムの属性値の分布を持つカラムに対しては生成しなくてよい。例えば、レコード２６２１は、”医療情報”スキーマの”患者情報”テーブルにおいて、関連するマップＩＤカラムとハッシュテーブルを持つ”カラム名”が”病名”であり、関連する”マップＩＤカラム名”が”ＭａｐＩＤ−１”であり、関連する”ハッシュテーブル名”が”ＨＴ１”であることを示す。

図６は、クラウドシステム側サーバ４が預託されたメインテーブル２６１の暗号文データを格納する暗号化メインテーブル３６１のデータ構造を示す。暗号化メインテーブル３６１は、クラウドシステム側サーバ４のディスク装置３６０又はメモリ３１０に格納される。なお、暗号化メインテーブル３６１は、ディスク装置３６０及びメモリ３１０の両方に格納されてもよい。暗号化メインテーブル３６１は、メインテーブル２６１に含まれる”患者番号”カラム、”名前”カラム及び”病名”カラムを含む。更に、暗号化メインテーブル３６１の各レコードを一意に特定する識別子である”ＩＤ”カラム及びハッシュテーブル（ＨＴ１）３６２との関連情報である”ＭａｐＩＤ−１”カラムによって、レコードを構成する。例えば、レコード３６１１は、暗号化された患者番号が”Ｅｎｃ（００００００１）”、暗号化された名前が”Ｅｎｃ（小島）”、暗号化された病名が”Ｅｎｃ（高血圧症）”、レコードの識別子が”１”、及びハッシュテーブル３６２との関連を示すＭａｐＩＤ−１の値が”１”であることを示す。なお、本実施例の説明で、”Ｅｎｃ（ ）”は、”（ ）”内の平文データが、暗号化部２１２１によって暗号化された暗号文であることを示す。また、”ＩＤ”カラム及び”ＭａｐＩＤ−１”カラムには、データベース制御部３１１の通常のインデックス機能を適用する。

図７は、検索を高速化するために用いるハッシュテーブル３６２のデータ構造を示す。ハッシュテーブル３６２は、クラウドシステム側サーバ４のディスク装置３６０又はメモリ３１０に格納される。なお、ハッシュテーブル３６２は、クラウドシステム側サーバ４のディスク装置３６０及びメモリ３１０に格納されてもよい。ハッシュテーブル３６２のレコードは、暗号化メインテーブル３６１の”ＭａｐＩＤ−１”カラムとの対応情報を示す”ＭａｐＩＤ”カラム、及びハッシュ値生成部２１２３が平文データを変換した平文ハッシュ値を暗号化部２１２１が暗号化した値を示す”暗号化ハッシュ値”カラムにより構成される。例えば、レコード３６２１は、暗号化メインテーブル３６１の”ＭａｐＩＤ−１”カラムの値と対応する”ＭａｐＩＤ”の値が”１”であり、ＭａｐＩＤ＝１に対応する”暗号化ハッシュ値”の値が”Ｅｎｃ（０７６５）”であることを示す。”ＭａｐＩＤ”カラムの値は、メインテーブル２６１の一つ以上のレコードの”ＭａｐＩＤ−１”の値と等しい。このため、”ＭａｐＩＤ”を指定することによって、暗号化メインテーブル３６１の全レコードを全件検索することなく、検索範囲を限定することができる。

（１−２）秘匿化データベースの検索に関する処理の流れ
図８、図９及び図１０を用いて、秘匿化データベースシステム１において、ハッシュテーブル３６２を用いた検索である秘匿インデックス検索を行う際の、データベースラッパー部２１２及びデータベース制御部３１１が行う一連の処理の詳細を説明する。

図８は、ユーザシステム側サーバ３において、データベースラッパー部２１２が実行する秘匿インデックス検索クエリ生成処理を示すフローチャートである。秘匿インデックス検索クエリ生成処理は、データベースラッパー部２１２がアプリケーション部２１１から平文の検索のＳＱＬを受信すると、開始する。例えば、秘匿インデックス検索クエリ生成処理の開始時にデータベースラッパー部２１２が受信するＳＱＬは、以下の平文の検索ＳＱＬ（１）である。

SELECT * FROM 医療情報.患者情報 WHERE 病名＝糖尿病 （１）

この検索ＳＱＬは、スキーマ名が”医療情報”であり、テーブル名が”患者情報”であるテーブルから、”病名”カラムの値が”糖尿病”であるレコードを検索し、全てのカラムの値を検索結果として得ることを意味する（ステップ８１０）。

次に、データベースラッパー部２１２は、平文の検索ＳＱＬから、検索対象のカラムの値を取り出し、検索クエリ生成部２１２２を用いて暗号化メインテーブル３６１における一致検索に用いる暗号化検索クエリを取得する。具体的には、データベースラッパー部２１２は、まず、鍵管理部２１２５から暗号化鍵及び検索用鍵を取得し、それらを検索クエリ生成部２１２２に入力し、その出力として暗号化検索クエリを得る。例えば、平文のＳＱＬが（１）である場合、以下の実行文（２）となる（ステップ８２０）。

暗号化検索クエリ（糖尿病）＝検索クエリ生成部（暗号化鍵、検索用鍵、"糖尿病"） （２）

次に、データベースラッパー部２１２は、秘匿インデックスマップテーブル２６２から、検索対象カラムの”マップＩＤカラム名”及び”ハッシュテーブル名”を取得する。具体的には、データベースラッパー部２１２は、平文の検索ＳＱＬが検索対象とするスキーマ名、暗号化メインテーブル名及びカラム名の組をキーとして、秘匿インデックスマップテーブル２６２を検索し、スキーマ名、暗号化メインテーブル名及びカラム名が一致するレコードの”マップＩＤカラム名”及び”ハッシュテーブル名”を取得する。例えば、平文の検索ＳＱＬが（１）である場合、スキーマ名が”医療情報”であり、かつ暗号化メインテーブル名が”患者情報”であり、かつカラム名が”病名”であるレコード２６２１から、マップＩＤカラム名”ＭａｐＩＤ−１”及びハッシュテーブル名”ＨＴ１”を取得する（ステップ８３０）。

次に、データベースラッパー部２１２は、ステップ８３０の結果が存在するか否かを判定する（ステップ８４０）。

ステップ８４０の結果が存在しない場合（ステップ８４０でＮＯ）、データベースラッパー部２１２は、ハッシュテーブル３６２を用いない検索ＳＱＬ変換の処理を行う。具体的には、データベースラッパー部２１２は、平文のＳＱＬの検索対象の値を、ステップ８２０で生成した暗号化検索クエリに置き換え、さらに、WHERE句の一致比較文をユーザ定義機能部３１２の暗号文一致比較部３１２１を呼び出す形式に置き換えた暗号文の検索ＳＱＬを出力する。例えば、平文のＳＱＬが（１）、暗号化検索クエリが（２）である場合、以下の暗号文の検索ＳＱＬ（３）が出力される（ステップ８５０）。

SELECT * FROM 医療情報.患者情報
WHERE 暗号文一致比較部（病名、暗号化検索クエリ（糖尿病）） （３）

一方、ステップ８４０の結果が存在する場合（ステップ８４０でＹＥＳ）、データベースラッパー部２１２は、ハッシュテーブル３６２を用いた高速検索を行うために、ハッシュ値生成から秘匿インデックス用検索ＳＱＬ変換（ステップ８６０〜８８０）の処理を行った暗号文の検索ＳＱＬを出力する。

まず、データベースラッパー部２１２は、検索対象の値をハッシュ値生成部２１２３に入力し、出力されるハッシュ値を取得する。例えば、平文の検索ＳＱＬが（１）である場合、以下のハッシュ値（４）を取得する（ステップ８６０）。

ハッシュ値 ＝ ハッシュ値生成部（糖尿病）＝"1012" （４）

次に、データベースラッパー部２１２は、ハッシュテーブル３６２を検索するために、ステップ８６０で取得したハッシュ値を検索クエリ生成部２１２２に入力し、出力をハッシュテーブル検索クエリとする。例えば、平文のハッシュ値が（４）である場合、以下のハッシュテーブル検索クエリ（５）を取得する（ステップ８７０）。

ハッシュテーブル検索クエリ（1012）＝検索クエリ生成部（暗号鍵、検索用鍵、"1012"） （５）

次に、データベースラッパー部２１２は、まずハッシュテーブル３６２を検索して検索範囲を限定した上で、暗号化メインテーブル３６１を検索するためのＳＱＬを生成する秘匿インデックス用検索ＳＱＬ変換を行う。具体的には、ステップ８２０で得た暗号化検索クエリと、ステップ８３０で得たマップＩＤカラム名及びハッシュテーブル名と、ステップ８７０で得たハッシュテーブル検索クエリとを入力とし、ハッシュテーブル３６２をハッシュテーブル検索クエリで検索して該当したレコードの”ＭａｐＩＤ”カラムの値を取得する。そして、取得した値と等しい”ＭａｐＩＤ−１”カラムの値を持つ暗号化メインテーブル３６１のレコードから、暗号化検索クエリと一致する値を持つレコードを、ユーザ定義機能部３１２の暗号文一致比較部３１２１を用いて判定し、一致するレコードからメインテーブル２６１に存在するカラムのみ（”ＩＤ”カラム及び”ＭａｐＩＤ−１”カラム以外）を選択し、検索結果とする暗号文の検索ＳＱＬを生成し、出力する。例えば、平文の検索ＳＱＬが（１）である場合、以下の暗号文の検索ＳＱＬ（６）を出力する（ステップ８８０）。

SELECT 患者番号, 名前, 病名 FROM 医療情報.患者情報
JOIN
(SELECT MapID FROM ハッシュテーブル（ＨＴ１）
WHERE
暗号文一致比較部（暗号化ハッシュ値、ハッシュテーブル検索クエリ（1012））
) MapResult
ON 医療情報.患者情報.MapID-1 = MapResult.MapID
WHERE 暗号化一致比較部（病名、暗号化検索クエリ（糖尿病）） （６）

最後に、データベースラッパー部２１２は、ステップ８５０又はステップ８８０で出力された暗号文の検索ＳＱＬを、データベースインタフェース部２１３へ送信する。平文の検索ＳＱＬが（１）である場合、ステップ８４０の結果が存在するため、データベースラッパー部２１２はステップ８８０が出力した暗号文の検索ＳＱＬ（６）をデータベースインタフェース部２１３へ送信する（ステップ８９０）。以上によって、データベースラッパー部２１２は、秘匿インデックス検索クエリ生成処理（図８）を終了する。

図９は、クラウドシステム側サーバ４において、データベース制御部３１１が実行する秘匿インデックス検索処理を示すフローチャートである。秘匿インデックス検索処理は、データベース制御部３１１がデータベースインタフェース部２１３から暗号文の検索ＳＱＬを受信すると、開始する。例えば、秘匿インデックス検索処理の開始時にデータベース制御部３１１が受信するＳＱＬは、暗号文の検索ＳＱＬ（６）である。

まず、データベース制御部３１１は、暗号文の検索ＳＱＬから、検索対象となるハッシュテーブル３６２とハッシュテーブル検索クエリとを特定し、ユーザ定義機能部３１２の暗号文一致比較部３１２１によって、当該ハッシュテーブル３６２の”暗号化ハッシュ値”カラムの値と当該ハッシュテーブル検索クエリとが一致するレコードを特定し、特定されたレコードの”ＭａｐＩＤ”カラムの値をＭａｐＩＤ＿ｈｉｔとして取得する。例えば、暗号文の検索ＳＱＬが（６）である場合、ハッシュテーブル３６２はハッシュテーブル３６２（ＨＴ１）であり、ハッシュテーブル検索クエリは（５）の”ハッシュテーブル検索クエリ（１０１２）”である。そして、暗号文一致比較部３１２１による一致比較の結果、検索クエリがハッシュテーブル３６２（ＨＴ１）のレコード３６２２の暗号化ハッシュ値”Ｅｎｃ（１０１２）”と一致すると判定し、当該レコードのＭａｐＩＤ”２”をＭａｐＩＤ＿ｈｉｔとして取得する（ステップ９１０）。

次に、データベース制御部３１１は、暗号化メインテーブル３６１から、ハッシュテーブル３６２と対応するマップＩＤカラムの値がＭａｐＩＤ＿ｈｉｔと一致し、かつ暗号化検索クエリと一致する値を持つことをユーザ定義機能部３１２の暗号文一致比較部３１２１により確認したレコード群ＭａｐＲｅｓｕｌｔを取得する。例えば、暗号文の検索ＳＱＬが（６）である場合、例えば、データベース制御部３１１は、暗号化メインテーブル３６１から、マップＩＤカラム”ＭａｐＩＤ−１”の値がステップ９１０で取得した”２”と一致し、かつ暗号化検索クエリ（糖尿病）の値と一致する”病名”カラムの値であるＥｎｃ（糖尿病）を持つレコード群を暗号文一致比較部３１２１により確認し、その結果レコード３６１３及びレコード３６１５をＭａｐＲｅｓｕｌｔとして取得する（ステップ９２０）。

最後に、データベース制御部３１１は、ＭａｐＲｅｓｕｌｔからＩＤカラム及びマップＩＤカラムを除いたレコード群を検索結果としてユーザシステム側サーバ３のデータベースインタフェース部２１３へ送信する。例えば、暗号文の検索ＳＱＬが（６）である場合、暗号化メインテーブル３６１のレコード３６１３及び３６１５から、”ＩＤ”カラム及び”ＭａｐＩＤ−１”カラムを除いたレコード群を暗号文の検索結果として送信する（ステップ９３０）。以上で、秘匿インデックス検索処理（図９）を終了する。

図１０は、ユーザシステム側サーバ３において、データベースラッパー部２１２が実行する検索結果復号処理を示すフローチャートである。検索結果復号処理は、データベースラッパー部２１２がデータベースインタフェース部２１３から暗号文の検索結果を受信すると、開始する。

まず、データベースラッパー部２１２は、暗号文の検索結果を復号化部２１２４に入力し、平文の検索結果を出力として得る（ステップ１０１０）。最後に、データベースラッパー部２１２は、アプリケーション部２１１へ平文の検索結果を送信する（ステップ１０２０）。以上で、検索結果復号処理（図１０）を終了する。

（１−３）秘匿化データベースへの挿入に関する処理の流れ
図１１及び図１２を用いて、秘匿化データベースシステム１において、ハッシュテーブル３６２を用いた挿入である秘匿インデックス挿入を行う際の、データベースラッパー部２１２及びデータベース制御部３１１が行う一連の処理の詳細を説明する。

図１１は、ユーザシステム側サーバ３において、データベースラッパー部２１２が実行する秘匿インデックス挿入クエリ生成処理を示すフローチャートである。秘匿インデックス挿入クエリ生成処理は、データベースラッパー部２１２がアプリケーション部２１１から平文の挿入のＳＱＬを受信すると、開始する。例えば、秘匿インデックス挿入クエリ生成処理の開始時にデータベースラッパー部２１２が受信するＳＱＬは、以下の平文の挿入ＳＱＬ（７）である。

INSERT INTO 医療情報.患者情報 ( 患者番号, 名前, 病名 )
VALUES ( 1000001, 木下, 胃腸炎 ) （７）

この挿入ＳＱＬは、スキーマ名が”医療情報”であり、テーブル名が”患者情報”であるテーブルに対し、”患者番号”カラムの値が”１０００００１”であり、”名前”カラムの値が”木下”であり、”病名”カラムの値が”胃腸炎”であるレコードを挿入することを意味する（ステップ１１１０）。

次に、データベースラッパー部２１２は、平文の挿入ＳＱＬから、挿入対象の値を取り出し、暗号化部２１２１により暗号化する。例えば、平文の挿入ＳＱＬが（７）である場合、挿入対象の値は”１０００００１”、”木下”及び”胃腸炎”であり、暗号化部２１２１により暗号化した結果の出力の暗号文はそれぞれ”Ｅｎｃ（１０００００１）”、”Ｅｎｃ（木下）”及び”Ｅｎｃ（胃腸炎）”となる（ステップ１１２０）。

次に、データベースラッパー部２１２は、秘匿インデックスマップテーブル２６２から、挿入対象レコードに関連する”マップＩＤカラム名”及び”ハッシュテーブル名”を取得する。具体的には、データベースラッパー部２１２は、平文の挿入ＳＱＬが挿入対象とするスキーマ名及び暗号化メインテーブル名の組をキーとして、秘匿インデックスマップテーブル２６２を検索し、スキーマ及び暗号化メインテーブル名が一致するすべてのレコードから、”カラム名”、”マップＩＤカラム名”及び”ハッシュテーブル名”を取得する。例えば、平文の挿入ＳＱＬが（７）である場合、スキーマ名が”医療情報”でありかつ暗号化メインテーブル名が”患者情報”であるレコード２６２１から、カラム名”病名”、マップＩＤカラム名”ＭａｐＩＤ−１”及びハッシュテーブル名”ＨＴ１”を取得する（ステップ１１３０）。

次に、データベースラッパー部２１２は、ステップ１１３０の結果が存在するか否かを判定する（ステップ１１４０）。

ステップ１１４０の結果が存在しない場合（ＮＯ）、データベースラッパー部２１２は、ハッシュテーブル３６２を用いない挿入ＳＱＬ変換の処理を行う。具体的には、データベースラッパー部２１２は、平文の挿入ＳＱＬの挿入対象の値を、ステップ１１２０で生成した暗号文の値に置き換えた暗号文の挿入ＳＱＬを出力する。例えば、平文のＳＱＬが（７）である場合、暗号文の挿入ＳＱＬは、以下の暗号文の挿入ＳＱＬ（８）を出力する（ステップ１１５０）。

INSERT INTO 医療情報.患者情報 ( 患者番号, 名前, 病名 )
VALUES ( Enc(1000001), Enc(木下), Enc(胃腸炎) ) （８）

一方、ステップ１１４０の結果が存在する場合（ＹＥＳ）、データベースラッパー部２１２は、ハッシュテーブル３６２と一貫性を保持した挿入を行うために、ハッシュ値生成から秘匿インデックス用挿入ＳＱＬ変換（ステップ１１６０〜１１９０）の処理を行い暗号文の挿入ＳＱＬを出力する。

まず、データベースラッパー部２１２は、挿入対象の値のうち、ハッシュテーブル３６２に関連するカラムの値をハッシュ値生成部２１２３に入力し、出力されるハッシュ値を取得する。例えば、平文の挿入ＳＱＬが（７）である場合、以下のハッシュ値（９）を取得する（ステップ１１６０）。

ハッシュ値 ＝ ハッシュ値生成部（胃腸炎） ＝ "0035" （９）

次に、データベースラッパー部２１２は、ハッシュテーブル３６２を検索するために、ステップ１１６０で取得したハッシュ値を検索クエリ生成部２１２２に入力し、出力をハッシュテーブル検索クエリとする。例えば、平文のハッシュ値が（８）である場合、以下のハッシュテーブル検索クエリ（１０）を取得する（ステップ１１７０）。

ハッシュテーブル検索クエリ（0035）＝検索クエリ生成部（暗号鍵、検索用鍵、"0035"） （１０）

次に、データベースラッパー部２１２は、ハッシュ値を暗号化部２１２１に入力し、出力される暗号化ハッシュ値を取得する。例えば、平文のハッシュ値が（８）である場合、暗号化ハッシュ値は”Ｅｎｃ（００３５）”となる（ステップ１１８０）。

次に、データベースラッパー部２１２は、ハッシュテーブル３６２をハッシュテーブル検索クエリで検索する。検索が一致しない場合、新しいＭａｐＩＤと暗号化ハッシュ値からなるレコードを挿入した後、ハッシュテーブル検索クエリに一致するレコードのＭａｐＩＤを取得し、そのＭａｐＩＤとステップ１１２０で取得した暗号文のレコードの値と新しいレコードの識別子であるＩＤとから構成されるレコードを暗号化メインテーブル３６１へ挿入する秘匿インデックス用挿入ＳＱＬ変換を行う。例えば、平文のＳＱＬが（７）である場合、以下の暗号文の挿入ＳＱＬ（１１）及び（１２）を出力する（ステップ１１９０）。

INSERT INTO ハッシュテーブル３６２（ MapID, 暗号化ハッシュ値 ）
SELECT 新MapID，暗号化ハッシュ値"Enc(0035)"
FROM ハッシュテーブル３６２ WHERE ＮＯT EXIST
(
SELECT * FROM ハッシュテーブル３６２
WHERE 暗号化一致比較部（暗号化ハッシュ値、ハッシュテーブル検索クエリ(0035)
) LIMIT 1; （１１）

INSERT INTO 暗号化メインテーブル３６１
（ 患者番号，名前，病名，ＩＤ，MapID-1 ）
VALUES
（ Enc(1000001)，Enc(木下), Enc(胃腸炎), 新ID，
（ SELECT MapID FROM ハッシュテーブル３６２ WHERE
暗号化一致比較部（暗号化ハッシュ値,ハッシュテーブル検索クエリ(0035) ）
); （１２）

最後に、データベースラッパー部２１２は、ステップ１１５０又はステップ１１９０で出力された暗号文の挿入ＳＱＬを、データベースインタフェース部２１３へ送信する。例えば、平文の挿入ＳＱＬが（７）である場合、ステップ１１４０の結果が存在するため、データベースラッパー部２１２はステップ１１９０が出力した暗号文の挿入ＳＱＬ（１１）及び（１２）をデータベースインタフェース部２１３へ送信する（ステップ１１９５）。以上で、図１１の秘匿インデックス挿入クエリ生成処理を終了する。

図１２は、クラウドシステム側サーバ４において、データベース制御部３１１が実行する秘匿インデックス挿入処理を示すフローチャートである。秘匿インデックス挿入処理は、データベース制御部３１１がデータベースインタフェース部２１３から暗号文の挿入ＳＱＬを受信すると、開始する。例えば、秘匿インデックス挿入処理の開始時にデータベース制御部３１１が受信するＳＱＬは、暗号文の挿入ＳＱＬ（１１）及び（１２）である。

まず、データベース制御部３１１は、暗号文の検索ＳＱＬから、検索対象となるハッシュテーブルとハッシュテーブル検索クエリと暗号化ハッシュ値とを特定する。そして、ユーザ定義機能部３１２の暗号文一致比較部３１２１が、当該ハッシュテーブル３６２の”暗号化ハッシュ値”のカラムの値と当該ハッシュテーブル検索クエリとが一致するレコードが存在するか否かを判定する（ステップ１２１０）。

ステップ１２１０にて、検索クエリと一致するレコードがあると判定された場合（ＹＥＳ）、データベース制御部３１１は、当該レコードのＭａｐＩＤカラムの値をＭａｐＩＤ＿ｈｉｔとして取得する（ステップ１２２０）。

一方、ステップ１２１０にて、検索クエリと一致するレコードがないと判定された場合、データベース制御部３１１は、新しいＭａｐＩＤを生成してＭａｐＩＤ＿ｈｉｔとし、検索ＳＱＬから取得した暗号化ハッシュ値と共に、ハッシュテーブル３６２へレコードとして挿入する（ステップ１２３０）。

次に、データベース制御部３１１は、暗号文の挿入ＳＱＬを実行し、暗号化された値、ＩＤ及びＭａｐＩＤ＿ｈｉｔから構成されるレコードを暗号化メインテーブル３６１へ挿入する。例えば、暗号文の挿入ＳＱＬ（１２）では、データベース制御部３１１は、患者番号が”Ｅｎｃ（１０００００１）”、名前が”Ｅｎｃ（木下）”、病名が”Ｅｎｃ（胃腸炎）”、ＩＤが”１０００００１”及びＭａｐＩＤ−１が”１０”であるレコードを暗号化メインテーブル３６１へ挿入する（ステップ１２４０）。

最後に、データベース制御部３１１は、挿入ＳＱＬの実行結果をユーザシステム側サーバ３のデータベースインタフェース部２１３へ送信する（ステップ１２５０）。以上で、秘匿インデックス挿入処理（図１２）を終了する。

（１−４）秘匿化データベースの更新に関する処理の流れ
図１３、図１４、図１５及び図１６を用いて、秘匿化データベースシステム１において、ハッシュテーブル３６２を用いて秘匿インデックスを更新する際の、データベースラッパー部２１２及びデータベース制御部３１１が行う一連の処理の詳細を説明する。

図１３は、ユーザシステム側サーバ３において、データベースラッパー部２１２が実行する秘匿インデックス更新クエリ生成処理を示すフローチャートである。秘匿インデックス更新クエリ生成処理は、データベースラッパー部２１２がアプリケーション部２１１から平文の更新のＳＱＬを受信すると、開始する。例えば、秘匿インデックス更新クエリ生成処理の開始時にデータベースラッパー部２１２が受信するＳＱＬは、以下の平文の更新ＳＱＬ（１３）である。

UPDATE 医療情報.患者情報 SET "病名"＝"狭心症"
WHERE "病名"＝"糖尿病" （１３）

この更新ＳＱＬ（１３）は、スキーマ名が”医療情報”であり、テーブル名が”患者情報”であるテーブルの”病名”カラムの値が”糖尿病”であるレコードにおいて、”病名”カラムの値を”狭心症”へ更新することを意味する（ステップ１３１０）。

次に、データベースラッパー部２１２は、平文の更新ＳＱＬ（１３）から、更新元カラムの値を取り出し、検索クエリ生成部２１２２を用いて暗号化メインテーブル３６１における一致検索に用いる暗号化検索クエリを取得する。具体的には、データベースラッパー部２１２は、鍵管理部２１２５から暗号化鍵及び検索用鍵を取得し、取得した鍵を検索クエリ生成部２１２２に入力し、その出力として暗号化検索クエリを得る。例えば、平文の更新ＳＱＬが（１３）である場合、暗号化検索クエリ（２）と同様に”暗号化検索クエリ（糖尿病）”を得る（ステップ１３１５）。

次に、データベースラッパー部２１２は、秘匿インデックスマップテーブル２６２から、更新元のカラムの”マップＩＤカラム名”及び”ハッシュテーブル名”を取得する。具体的には、データベースラッパー部２１２は、平文の検索ＳＱＬが検索対象とするスキーマ名、暗号化メインテーブル名及び更新元のカラム名の組をキーとして、秘匿インデックスマップテーブル２６２を検索し、スキーマ名、暗号化メインテーブル名及びカラム名が一致するレコードの”マップＩＤカラム名”及び”ハッシュテーブル名”を取得する。例えば、平文の検索ＳＱＬが（１３）である場合、スキーマ名が”医療情報”であり、かつ暗号化メインテーブル名が”患者情報”であり、かつ更新元のカラム名”病名”を含むレコード２６２１から、マップＩＤカラム名”ＭａｐＩＤ−１”及びハッシュテーブル名”ＨＴ１”を取得する（ステップ１３２０）。

次に、データベースラッパー部２１２は、ステップ１３２０の結果が存在するか否かを判定する（ステップ１３２５）。

ステップ１３２０の結果が存在しない場合（ＮＯ）、データベースラッパー部２１２は、ハッシュテーブル３６２を用いないで更新ＳＱＬを変換する処理を行う。具体的には、データベースラッパー部２１２は、まず、暗号化メインテーブル３６１から更新対象となるレコードのＩＤのリストである更新対象ＩＤリストを取得するＳＱＬを、データベースインタフェース部２１３へ送信し、結果として更新対象ＩＤリストを受信する。例えば、平文の更新ＳＱＬが（１３）である場合、以下のＳＱＬ（１４）で更新対象ＩＤリストを取得する（ステップ１３３０）。

SELECT ID FROM 医療情報.患者情報
WHERE 暗号文一致比較部（病名、暗号化検索クエリ（糖尿病）） （１４）

データベースラッパー部２１２は、ステップ１３３０で得られた更新ＩＤリストから更新対象ＩＤの個数を取得し、取得した更新対象ＩＤの個数分の、更新後の値の暗号文を生成する。例えば、平文の更新ＳＱＬが（１３）である場合、更新対象ＩＤの数は”３”及び”１００００００”の二つであるため、更新後の値の暗号文はＥｎｃ（狭心症）及びＥｎｃ（狭心症）の二つとなり、確率的暗号化を用いる場合、これらは異なる暗号文となる（ステップ１３３５）。

次に、データベースラッパー部２１２は、ステップ１３３５で得られた二つの更新後の値の暗号文を、それぞれの更新対象ＩＤが示すレコードの値として更新する暗号文の更新ＳＱＬを生成する。この更新ＳＱＬは、望ましくは一文のＳＱＬで記述されるが、データベース制御部３１１のＳＱＬ文の最大長を超える場合、分割された複数の更新ＳＱＬを生成するとよい。例えば、平文の更新ＳＱＬが（１３）である場合、以下の更新ＳＱＬ（１５）が出力される（ステップ１３４０）。

UPDATE 医療情報.患者情報
SET "病名"＝
CASE ID
WHEN 3 THEN Enc(狭心症)
WHEN 1000000 THEN Enc(狭心症)
END
WHERE 暗号文一致比較部（病名、暗号化検索クエリ（糖尿病）） （１５）

一方、ステップ１３２０の結果が存在する場合（ＹＥＳ）、データベースラッパー部２１２は、暗号化メインテーブル３６１及びハッシュテーブル３６２を更新するために、ハッシュ値生成から秘匿インデックス用更新ＳＱＬ変換（ステップ１３４５〜１３７０）を行った暗号文の更新ＳＱＬを出力する。

まず、データベースラッパー部２１２は、更新後の値をハッシュ値生成部２１２３に入力し、出力されるハッシュ値を取得する。例えば、平文の更新ＳＱＬが（１３）である場合、ハッシュ値（１６）を取得する（ステップ１３４５）。

ハッシュ値 ＝ ハッシュ値生成部（狭心症）＝"0500" （１６）

次に、データベースラッパー部２１２は、ハッシュテーブル３６２を検索するために、ステップ１３４５で取得したハッシュ値を検索クエリ生成部２１２２に入力し、出力をハッシュテーブル検索クエリとする。例えば、平文のハッシュ値が（１６）である場合、以下のハッシュテーブル検索クエリ（１７）を取得する（ステップ１３５０）。

ハッシュテーブル検索クエリ（0500）
＝検索クエリ生成部（暗号鍵、検索用鍵、"0500"） （１７）

次に、データベースラッパー部２１２は、暗号化部２１２１へステップ１３４５で取得したハッシュ値を入力し、出力としてハッシュテーブル３６２に挿入するための暗号化ハッシュ値を取得する。例えば、平文のハッシュ値（１６）が”０５００”である場合、暗号化ハッシュ値は”Ｅｎｃ（０５００）”となる（ステップ１３６０）。

次に、データベースラッパー部２１２は、ハッシュテーブル３６２を用いて、更新対象となるレコード群のＩＤカラムの値のテーブルを取得する秘匿インデックス用更新対象ＩＤテーブル取得ＳＱＬを実行し、更新対象ＩＤテーブルを得る。具体的には、データベースラッパー部２１２は、ステップ１３１５で取得した更新元の値の暗号化検索クエリ、ステップ１３２０で取得した更新元のカラムに関連するマップＩＤカラム名とハッシュテーブル名、及び更新元の値のハッシュテーブル検索クエリを入力とし、ハッシュテーブル３６２を検索した上で暗号化メインテーブル３６１の検索範囲を限定し、更新対象ＩＤテーブルを取得するＳＱＬを実行し、その結果を更新対象ＩＤテーブルとして出力する。例えば、平文の更新ＳＱＬが（１３）である場合、秘匿インデックス用更新対象ＩＤテーブル取得ＳＱＬは、以下の暗号文の検索ＳＱＬ（１８）を生成し、データベースインタフェース部２１３経由でデータベース制御部３１１へ送信し、その実行結果を更新対象ＩＤテーブルとして取得する（ステップ１３６０）。

SELECT ID FROM 暗号化メインテーブル３６１ X
JOIN
( SELECT MapID FROM ハッシュテーブル３６２
WHERE 暗号化一致比較部（暗号化ハッシュ値，ハッシュテーブル検索クエリ(1012)
) Y
ON X.MapID= Y.MapID
WHERE 暗号化一致比較部（病名，暗号化検索クエリ（糖尿病）） （１８）

次に、データベースラッパー部２１２は、ステップ１３６０で得られた更新ＩＤリストから更新対象ＩＤの個数を取得し、取得した更新対象ＩＤの個数分の、更新後の値の暗号文リストを生成する。例えば、平文の更新ＳＱＬが（１３）である場合、ステップ１３３５と同様に、更新対象ＩＤの数は”３”及び”１００００００”の二つであるため、更新後の値の暗号文リストはＥｎｃ（狭心症）及びＥｎｃ（狭心症）の二つとなる。確率的暗号化を用いる場合、これらは異なる暗号文となる（ステップ１３６５）。

次に、データベースラッパー部２１２は、平文の更新ＳＱＬ、ステップ１３１５、ステップ１３２０、ステップ１３５０、ステップ１３５５、ステップ１３６０及びステップ１３６５で取得した各種情報を入力とし、秘匿インデックス用の暗号文の更新ＳＱＬを出力する。具体的には、第一に、ハッシュテーブル３６２の更新後の値のハッシュテーブル検索クエリで暗号化一致検索し、一致しない場合、更新後の値の暗号化ハッシュ値と新しいＭａｐＩＤの値から成るレコードをハッシュテーブル３６２へ挿入するＳＱＬを生成する。第二に、ハッシュテーブル３６２から更新後の値のＭａｐＩＤを取得するＳＱＬを生成する。第三に、暗号化メインテーブル３６１において、更新対象ＩＤをもつレコードごとに、更新後の値の暗号文を置き換える更新ＳＱＬを生成する。例えば、平文の更新ＳＱＬが（１３）である場合、第一のＳＱＬは以下の更新ＳＱＬ（１９）となり、第二のＳＱＬは以下の更新ＳＱＬ（２０）となり、第三のＳＱＬは以下の更新ＳＱＬ（２１）となる。これら三つのＳＱＬ文を含む暗号文の更新ＳＱＬを出力する（ステップ１３７０）。

INSERT INTO ハッシュテーブル３６２（ MapID, 暗号化ハッシュ値 ）
SELECT 新MapID，暗号化ハッシュ値"Enc(0500)"
FROM ハッシュテーブル３６２ WHERE ＮＯT EXIST
(
SELECT * FROM ハッシュテーブル３６２
WHERE 暗号化一致比較部（暗号化ハッシュ値、ハッシュテーブル検索クエリ(0500)）
) LIMIT 1; （１９）

SELECT MapID FROM ハッシュテーブル３６２ WHERE
暗号化一致比較部（暗号化ハッシュ値、ハッシュテーブル検索クエリ(0500)） （２０）

UPDATE 暗号化メインテーブル３６１ X JOIN 更新対象ＩＤテーブルY
ON X.ID = Y.ID
SET X.病名 ＝
CASE ID
WHEN 3 THEN Enc(狭心症)
WHEN 1000000 THEN Enc(狭心症)
END
，X.MapID ＝(２０)で取得したMapID （２１）

最後に、データベースラッパー部２１２は、ステップ１３４０又はステップ１３７０で出力された暗号文の更新ＳＱＬを、データベースインタフェース部２１３へ送信する。平文の更新ＳＱＬが（１３）である場合、ステップ１３２０の結果が存在するため、データベースラッパー部２１２はステップ１３７０が出力した暗号文のＳＱＬ（１９）、（２０）及び（２１）をデータベースインタフェース部２１３へ送信する（ステップ１３７５）。以上で、データベースラッパー部２１２は、秘匿インデックス更新クエリ生成処理（図１３）を終了する。

図１４は、クラウドシステム側サーバ４において、データベース制御部３１１が実行する更新対象ＩＤリスト取得処理を示すフローチャートである。更新対象ＩＤリスト取得処理は、データベース制御部３１１がデータベースインタフェース部２１３から暗号文の検索ＳＱＬを受信すると、開始する。

まず、更新対象カラムの値が暗号化検索クエリと一致するレコードのＩＤを、暗号化メインテーブル３６１からすべて取得する（ステップ１４１０）。最後に、取得結果をデータベースインタフェース部２１３へ送信し（ステップ１４２０）、更新対象ＩＤリスト取得処理（図１４）を終了する。例えば、暗号文の検索ＳＱＬが（１４）である場合、更新対象ＩＤリストの要素は”３”及び”１００００００”となる。

図１５は、クラウドシステム側サーバ４において、データベース制御部３１１が実行する秘匿インデックス用更新対象ＩＤテーブル取得処理を示すフローチャートである。秘匿インデックス用更新対象ＩＤテーブル取得処理は、データベース制御部３１１がデータベースインタフェース部２１３から暗号文の検索ＳＱＬを受信すると、開始する。

まず、ハッシュテーブル３６２から、ハッシュテーブル検索クエリに一致するレコードのＭａｐＩＤを取得する（ステップ１５１０）。次に、ステップ１５１０で取得したＭａｐＩＤと一致するＭａｐＩＤ−１の値を持ち、かつ更新元カラムである”病名”カラムの値が暗号化検索クエリと一致するレコードのＩＤを、暗号化メインテーブル３６１から全て取得し、更新対象ＩＤテーブルとして格納する（ステップ１５２０）。最後に、取得結果をデータベースインタフェース部２１３へ送信し（１５３０）、秘匿インデックス用更新対象ＩＤテーブル取得処理（図１５）を終了する。例えば、暗号文の検索ＳＱＬが（１８）である場合、更新対象ＩＤテーブルはＩＤカラムの値として”３”及び”１００００００”を格納したテーブルとなる。

図１６は、クラウドシステム側サーバ４において、データベース制御部３１１が実行する秘匿インデックス更新処理を示すフローチャートである。秘匿インデックス更新処理は、データベース制御部３１１がデータベースインタフェース部２１３から暗号文の更新ＳＱＬを受信すると、開始する。例えば、秘匿インデックス更新処理の開始時にデータベース制御部３１１が受信するＳＱＬは、暗号文の更新ＳＱＬ（１９）、（２０）及び（２１）である。

まず、データベース制御部３１１は、暗号文の更新ＳＱＬの第一のＳＱＬである（１９）から、更新対象となるハッシュテーブル３６２とハッシュテーブル検索クエリ（0500）を取得する。そして、ユーザ定義機能部３１２の暗号文一致比較部３１２１は、当該ハッシュテーブルの"暗号化ハッシュ値"カラムの値と当該ハッシュテーブル検索クエリ(0500)とが一致するレコードを検索する（ステップ１６１０）。

ステップ１６１０の結果が存在する場合、データベース制御部３１１は、一致したレコードからＭａｐＩＤを取得する（ステップ１６２０）。

一方、ステップ１６１０の結果が存在しない場合、データベース制御部３１１は、新しいＭａｐＩＤを生成し、暗号化ハッシュ値”Ｅｎｃ（０５００）”と共にハッシュテーブル３６２へ挿入し、新しいＭａｐＩＤを取得する（ステップ１６３０）。

次に、データベース制御部３１１は、暗号化メインテーブル３６１の更新対象ＩＤを持つレコードの更新対象カラムの値に更新後の暗号文を置き換え、マップＩＤカラム”ＭａｐＩＤ−１”の値をステップ１６２０又はステップ１６３０で取得したＭａｐＩＤの値に置き換える（ステップ１６４０）。

次に、データベース制御部３１１は、ハッシュテーブル３６２から、暗号化メインテーブル３６１のマップＩＤカラム”ＭａｐＩＤ−１”に存在しないＭａｐＩＤを持つレコードを削除する（ステップ１６５０）。

最後に、データベース制御部３１１は、データベースインタフェース部２１３へ、更新結果を送信する（１６６０）。以上で、秘匿インデックス更新処理（図１６）を終了する。

（１−５）秘匿化データベースの削除に関する処理の流れ
図１７及び図１８を用いて、秘匿化データベースシステム１において、ハッシュテーブル３６２を用いた削除である秘匿インデックスを削除する際の、データベースラッパー部２１２及びデータベース制御部３１１が行う一連の処理の詳細を説明する。

図１７は、ユーザシステム側サーバ３において、データベースラッパー部２１２が実行する秘匿インデックス削除クエリ生成処理を示すフローチャートである。秘匿インデックス削除クエリ生成処理は、データベースラッパー部２１２がアプリケーション部２１１から平文の削除のＳＱＬを受信すると、開始する。例えば、秘匿インデックス削除クエリ生成処理の開始時にデータベースラッパー部２１２が受信するＳＱＬは、以下に示す平文の削除ＳＱＬ（２２）である。

DELETE FROM 医療情報.患者情報 WHERE 病名=糖尿病 （２２）

この削除ＳＱＬは、スキーマ名が”医療情報”であり、テーブル名が”患者情報”であるテーブルから、”病名”カラムの値が”糖尿病”であるレコードを全て削除することを意味する（ステップ１７１０）。

次に、データベースラッパー部２１２は、平文の削除ＳＱＬから、削除条件の対象カラムの値を取り出し、検索クエリ生成部２１２２を用いて暗号化メインテーブル３６１における削除条件の一致検索に用いる暗号化検索クエリを取得する。具体的には、データベースラッパー部２１２は、鍵管理部２１２５から暗号化鍵及び検索用鍵を取得し、取得した鍵を検索クエリ生成部２１２２に入力し、その出力として暗号化検索クエリを得る。例えば、平文のＳＱＬが（２２）である場合、以下の実行文（２）となる（ステップ１７２０）。

暗号化検索クエリ（糖尿病）＝検索クエリ生成部（暗号化鍵、検索用鍵、"糖尿病"） （２）

次に、データベースラッパー部２１２は、秘匿インデックスマップテーブル２６２から、検索対象カラムの”マップＩＤカラム名”及び”ハッシュテーブル名”を取得する。具体的には、データベースラッパー部２１２は、平文の削除ＳＱＬが削除条件の対象とするスキーマ名、暗号化メインテーブル名及びカラム名の組をキーとして、秘匿インデックスマップテーブル２６２を検索し、スキーマ名、暗号化メインテーブル名及びカラム名が一致するレコードの”マップＩＤカラム名”及び”ハッシュテーブル名”を取得する。例えば、平文の検索ＳＱＬが（２２）である場合、スキーマ名が”医療情報”であり、かつ暗号化メインテーブル名が”患者情報”であり、かつカラム名が”病名”であるレコード２６２１から、マップＩＤカラム名”ＭａｐＩＤ−１”及びハッシュテーブル名”ＨＴ１”を取得する（ステップ１７３０）。

次に、データベースラッパー部２１２は、ステップ１７３０の結果が存在するか否かを判定する（ステップ１７４０）。

ステップ１７４０の結果が存在しない場合（ＮＯ）、データベースラッパー部２１２は、ハッシュテーブル３６２を用いないで削除ＳＱＬを変換する処理を行う。具体的には、データベースラッパー部２１２は、平文のＳＱＬの削除条件の対象カラムの値を、ステップ１７２０で生成した暗号化検索クエリに置き換え、さらに、ＷＨＥＲＥ句の一致比較文を、ユーザ定義機能部３１２の暗号文一致比較部３１２１を呼び出す形式に置き換えた、暗号文の削除ＳＱＬを出力する。例えば、平文のＳＱＬが（２２）であり、暗号化検索クエリが（２）である場合、暗号文の削除ＳＱＬは以下の暗号文のＳＱＬ（２３）である（ステップ１７５０）。

DELETE FROM 医療情報.患者情報
WHERE 暗号文一致比較部（病名、暗号化検索クエリ（糖尿病）） （２３）

一方、ステップ１７３０の結果が存在する場合（ＹＥＳ）、データベースラッパー部２１２は、ハッシュテーブル３６２を用いた削除を行うために、ハッシュ値生成から秘匿インデックス用削除ＳＱＬ変換（ステップ１７６０〜１７８０）の処理を行った暗号文の削除ＳＱＬを出力する。

具体的には、まず、データベースラッパー部２１２は、削除条件の対象カラムの値をハッシュ値生成部２１２３に入力し、出力されるハッシュ値を取得する。例えば、平文の削除ＳＱＬが（２２）である場合、ハッシュ値（４）を取得する（ステップ１７６０）。

ハッシュ値 ＝ ハッシュ値生成部（糖尿病）＝"1012" （４）

次に、データベースラッパー部２１２は、ハッシュテーブル３６２を検索するために、ステップ１７６０で取得したハッシュ値を検索クエリ生成部２１２２に入力し、出力をハッシュテーブル検索クエリとする。例えば、平文のハッシュ値が（４）である場合、ハッシュテーブル検索クエリ（５）を取得する（ステップ１７７０）。

ハッシュテーブル検索クエリ（1012）＝検索クエリ生成部（暗号鍵、検索用鍵、"1012"） （５）

次に、データベースラッパー部２１２は、秘匿インデックス用ＳＱＬ変換部２１２７により、ハッシュテーブル３６２を検索して検索範囲を限定した上で、暗号化メインテーブル３６１からの削除を実行するためのＳＱＬを生成する秘匿インデックス用検索ＳＱＬ変換を行う。具体的には、ステップ１７２０で得た暗号化検索クエリと、ステップ１７３０で得たマップＩＤカラム名及びハッシュテーブル名と、ステップ１７７０で得たハッシュテーブル検索クエリを入力とし、ハッシュテーブル３６２をハッシュテーブル検索クエリで検索して該当したレコードの”ＭａｐＩＤ”カラムの値を取得し、その値と等しい”ＭａｐＩＤ−１”カラムの値を持つ暗号化メインテーブル３６１のレコードから、暗号化検索クエリと一致する値を持つレコードを、ユーザ定義機能部３１２の暗号文一致比較部３１２１を用いて判定する。そして、一致したレコードを暗号化メインテーブル３６１から削除するＳＱＬを生成する。さらに、ハッシュテーブル３６２から、暗号化メインテーブル３６１のマップＩＤカラム”ＭａｐＩＤ−１”に存在しないＭａｐＩＤを含むレコードを削除するＳＱＬを生成する。例えば、平文の削除ＳＱＬが（２２）である場合、二つのＳＱＬ文（２３）、（２４）を含む暗号文の削除ＳＱＬを出力する（ステップ１７８０）。

DELETE 医療情報.患者情報FROM 医療情報.患者情報
JOIN
( SELECT MapID FROM ハッシュテーブル（ＨＴ１）
WHERE
暗号文一致比較部（暗号化ハッシュ値、ハッシュテーブル検索クエリ（1012））
) MapResult
ON 医療情報.患者情報.MapID-1 = MapResult.MapID
WHERE 暗号化一致比較部（病名、暗号化検索クエリ（糖尿病）） （２４）

DELETE ハッシュテーブル（ＨＴ１） FROM ハッシュテーブル（ＨＴ１）
WHERE ＮＯT EXIST
( SELECT MapID FROM 医療情報.患者情報
WHERE ハッシュテーブル（ＨＴ１）.MapID = 医療情報.患者情報.MapID
) （２５）

最後に、データベースラッパー部２１２は、ステップ１７５０又はステップ１７８０で出力された暗号文の削除ＳＱＬを、データベースインタフェース部２１３へ送信する。平文の削除ＳＱＬが（２２）である場合、ステップ１７４０の結果が存在するため、データベースラッパー部２１２はステップ１７８０が出力した暗号文の検索ＳＱＬ（２４）及び（２５）をデータベースインタフェース部２１３へ送信する（ステップ１７９０）。以上で、データベースラッパー部２１２は、秘匿インデックス削除クエリ生成処理（図１７）を終了する。

図１８は、クラウドシステム側サーバ４において、データベース制御部３１１が実行する秘匿インデックス削除処理を示すフローチャートである。秘匿インデックス削除処理は、データベース制御部３１１がデータベースインタフェース部２１３から暗号文の削除ＳＱＬを受信すると、開始する。例えば、秘匿インデックス削除処理の開始時にデータベース制御部３１１が受信するＳＱＬは、暗号文の削除ＳＱＬ（２４）及び（２５）である。

まず、データベース制御部３１１は、暗号文の削除ＳＱＬから、削除条件の対象となるハッシュテーブル３６２及びハッシュテーブル検索クエリを特定し、ユーザ定義機能部３１２の暗号文一致比較部３１２１により当該ハッシュテーブル３６２の”暗号化ハッシュ値”カラムの値と当該ハッシュテーブル検索クエリとが一致するレコードを特定し、そのレコードの”ＭａｐＩＤ”カラムの値をＭａｐＩＤ＿ｈｉｔとして取得する。例えば、暗号文の削除ＳＱＬが（２４）及び（２５）である場合、ハッシュテーブル３６２はハッシュテーブル３６２（ＨＴ１）であり、ハッシュテーブル検索クエリは”ハッシュテーブル検索クエリ（１０１２）”である。そして、暗号文一致比較部３１２１による一致比較の結果、ハッシュテーブル３６２（ＨＴ１）のレコード３６２２の暗号化ハッシュ値”Ｅｎｃ（１０１２）”と一致し、当該レコードのＭａｐＩＤ”２”をＭａｐＩＤ＿ｈｉｔとして取得する（ステップ１８１０）。

次に、データベース制御部３１１は、ハッシュテーブル３６２と対応するマップＩＤカラムの値がＭａｐＩＤ＿ｈｉｔと一致し、かつ暗号化検索クエリと一致する値を持つことをユーザ定義機能部３１２の暗号文一致比較部３１２１により確認したレコード群ＭａｐＲｅｓｕｌｔを、暗号化メインテーブル３６１から取得する。例えば、暗号文の削除ＳＱＬが（２４）及び（２５）である場合、データベース制御部３１１は、マップＩＤカラム”ＭａｐＩＤ−１”の値がステップ９１０で取得した”２”と一致し、かつ暗号化検索クエリ（糖尿病）の値と一致する”病名”カラムの値であるＥｎｃ（糖尿病）を持つレコード群を暗号文一致比較部３１２１により確認し、その結果レコード３６１３及びレコード３６１５をＭａｐＲｅｓｕｌｔとして、暗号化メインテーブル３６１から取得する（ステップ１８２０及び１８３０）。

次に、データベース制御部３１１は、暗号化メインテーブル３６１から、ＭａｐＲｅｓｕｌｔに含まれるレコードを削除する（ステップ１８４０）。

次に、データベース制御部３１１は、ハッシュテーブル３６２から、暗号化メインテーブル３６１のマップＩＤカラム”ＭａｐＩＤ−１”に存在しないＭａｐＩＤを含むレコードを削除する（ステップ１８５０）。

最後に、データベース制御部３１１は、暗号文の削除ＳＱＬの結果をデータベースインタフェース部２１３へ送信する（ステップ１８６０）。以上で、秘匿インデックス削除処理（図１８）を終了する。

（１−６）第一の実施例の効果
以上に説明したように、第一の実施例の秘匿化データベースシステム１では、暗号化された大容量の暗号化メインテーブル３６１への検索に際して、ハッシュテーブル３６２を事前に検索することで検索対象とするレコードを少なくするため、高速に検索することができる。

（２）第二の実施例
（２−１）第二の実施例による情報処理システムの構成
図１９は、本発明の第二の実施例の秘匿化データベースシステム１のハードウェア及びソフトウェア構成を示すブロック図である。

秘匿化データベースシステム１は、第一の実施例（図１）と同様に、ユーザシステム側サーバ３が持つ元データを暗号化して、クラウドシステム側サーバ４に預託し、さらに、クラウドシステム側サーバ４が預託されたデータに対する検索機能及び分析機能をユーザシステム側サーバ３に対して提供するシステムである。

第二の実施例の秘匿化データベースシステム１が、第一の実施例と異なる点は、暗号化メインテーブル３６１の代わりに、ハッシュテーブル３６２Ｂとの対応関係を示すＭａｐＩＤ−１カラムを取り除いた暗号化メインテーブル３６１Ｂを有し、さらに、暗号化ハッシュ値の内容が異なる暗号化メインテーブル３６１Ｂとハッシュテーブル３６２Ｂとの対応関係を隠蔽するために暗号化して格納するマッピングテーブル３６３を有することである。

第二の実施例のユーザ端末２は、第一の実施例のユーザ端末２と同じである。

第二の実施例のユーザシステム側サーバ３は、第一の実施例のユーザシステム側サーバ３と同じである。

第二の実施例のアプリケーション部２１１は、第一の実施例のアプリケーション部２１１と同じである。

第二の実施例のデータベースラッパー部２１２が第一の実施例と異なる点は、インデックス用検索クエリ生成部２１２８、ＩＤ暗号化部２１２９、インデックス用暗号化部２１２０及びマッピングテーブル並べ替えクエリ生成部２１２００を有することである。データベースラッパー部２１２の各部については、図２０を参照して後述する。それ以外は、第一の実施例と同じである。

第二の実施例のデータベースインタフェース部２１３は、第一の実施例のデータベースインタフェース部２１３と同じである。

第二の実施例のディスク装置２６０が第一の実施例と異なる点は、秘匿インデックスマップテーブル２６２の”マップＩＤカラム名”カラムの代わりに、”マッピングテーブル名”カラムを備える秘匿インデックスマップテーブル２６２Ｂを有することである。それ以外は、第一の実施例と同じである。

第二の実施例のクラウドシステム側サーバ４は、第一の実施例のクラウドシステム側サーバ４と同様である。

第二の実施例のデータベース制御部３１１が第一の実施例と異なる点は、マッピングテーブル３６３の情報を加えて利用することである。それ以外は、第一の実施例のユーザ定義機能部３１２と同じである。

第二の実施例のユーザ定義機能部３１２が第一の実施例と異なる点は、インデックス用一致比較部３１２２、ＩＤ用鍵取得部３１２３、ＩＤ復号化部３１２４及びＩＤ暗号化部３１２５を有することである。ユーザ定義機能部３１２の各部については、図２１を参照して後述する。それ以外は第一の実施例のユーザ定義機能部３１２と同じである。

第二の実施例のディスク装置３６０が第一の実施例と異なる点は、暗号化メインテーブル３６１に代えて暗号化メインテーブル３６１Ｂを有し、ハッシュテーブル３６２に代えてハッシュテーブル３６２Ｂを有し、さらに、マッピングテーブル３６３を追加で有することである。それ以外は、第一の実施例のディスク装置３６０と同じである。

図２０は、第二の実施例のデータベースラッパー部２１２の論理構成を示す。第二の実施例のデータベースラッパー部２１２が、第一の実施例と異なる点は、図２に示す各部に加えて、インデックス用検索クエリ生成部２１２８、ＩＤ暗号化部２１２９、インデックス用暗号化部２１２０及びマッピングテーブル並べ替えクエリ生成部２１２００を有することである。それ以外は、第一の実施例のデータベースラッパー部２１２（図２）と同じである。

第二の実施例の暗号化部２１２１は、第一の実施例の暗号化部２１２１と同じである。

第二の実施例の検索クエリ生成部２１２２は、第一の実施例の検索クエリ生成部２１２２と同じである。

第二の実施例のハッシュ値生成部２１２３は、第一の実施例のハッシュ値生成部２１２３と同じである。

第二の実施例の復号化部２１２４は、第一の実施例の復号化部２１２４と同じである。

第二の実施例の鍵管理部２１２５が、第一の実施例と異なる点は、インデックス用検索クエリ生成部２１２８、ＩＤ暗号化部２１２９及びインデックス用暗号化部２１２０からの鍵の要求に対しても、暗号化鍵データ又は検索用鍵データを提供することである。なお、暗号化鍵データ及び検索用鍵データを提供してもよい。それ以外は、第一の実施例の鍵管理部２１２５と同じである。

第二の実施例のＳＱＬ変換部２１２６は、第一の実施例のＳＱＬ変換部２１２６と同じである。

第二の実施例の秘匿インデックス用ＳＱＬ変換部２１２７が第一の実施例の秘匿インデックス用ＳＱＬ変換部２１２７と異なる点は、ハッシュテーブル３６２Ｂ、マッピングテーブル３６３及び暗号化メインテーブル３６１Ｂに対して参照、挿入、更新及び削除の少なくとも一つの処理を行う暗号化ＳＱＬ文を生成し、暗号化ＳＱＬ文をデータベースインタフェース部２１３へ送信することである。それ以外は、第一の実施例の秘匿インデックス用ＳＱＬ変換部２１２７と同じである。

第二の実施例のインデックス用検索クエリ生成部２１２８は、ハッシュ値生成部２１２３が出力したインデックスのバイト列を入力とし、ハッシュテーブル３６２Ｂを検索するためのインデックス用ハッシュテーブル検索クエリを出力する。

第二の実施例のＩＤ暗号化部２１２９は、マッピングテーブル３６３に格納するメインテーブル２６１のＩＤカラムの値を暗号化する。具体的には、ＩＤ暗号化部２１２９は、ＩＤを暗号化するＩＤ用鍵を鍵管理部２１２５から取得し、取得した鍵を用いて平文のＩＤを暗号化し、その結果を暗号化ＩＤとして出力する。

第二の実施例のインデックス用暗号化部２１２０は、インデックスの識別子を暗号化する。具体的には、インデックス用暗号化部２１２０は、鍵管理部２１２５から取得するＩＤ用鍵とハッシュ値生成部２１２３が出力する平文のハッシュ値を入力とし、鍵管理部２１２５から取得する暗号化鍵により入力されたハッシュ値を暗号化し、その結果を暗号化ハッシュ値として出力する。

第二の実施例のマッピングテーブル並べ替えクエリ生成部２１２００は、マッピングテーブル３６３の各レコードの順序をランダムに並べ替える。

図２１は、第二の実施例のユーザ定義機能部３１２の論理構成を示す。第二の実施例のユーザ定義機能部３１２が、第一の実施例のユーザ定義機能部３１２（図３）と異なる点は、第一の実施例の構成に加えてインデックス用一致比較部３１２２、ＩＤ用鍵取得部３１２３、ＩＤ復号化部３１２４及びＩＤ暗号化部３１２５を有する点である。それ以外は、第一の実施例のユーザ定義機能部３１２と同じである。

第二の実施例の暗号文一致比較部３１２１は、第一の実施例の暗号文一致比較部３１２１と同じである。

第二の実施例のインデックス用一致比較部３１２２は、検索用鍵データをメモリ３１０及び／又はディスク装置３６０に格納する。また、データベース制御部３１１からインデックス用ハッシュテーブル検索クエリ及び暗号化ハッシュ値の入力を受け、検索用鍵を用いてインデックス用ハッシュテーブル検索クエリを暗号化ハッシュ値との一致比較が可能なインデックス用一致検索クエリに変換する。そして、インデックス用一致検索クエリと暗号化ハッシュ値の一致比較を行い、一致する場合は一致を示す値（例えば”１”）を出力し、一致しない場合は不一致を示す値（例えば”０”）を出力する。

第二の実施例のＩＤ用鍵取得部３１２３は、インデックス用ハッシュテーブル検索クエリ及び暗号化ハッシュ値を入力とし、暗号化ハッシュ値の一部を変換しＩＤ用鍵を出力する。

第二の実施例のＩＤ復号化部３１２４は、暗号化ＩＤとＩＤ用鍵を入力とし、暗号化ＩＤをＩＤ用鍵で復号化し、平文ＩＤを出力する。

第二の実施例のＩＤ暗号化部３１２５は、平文ＩＤとＩＤ用鍵を入力とし、平文ＩＤをＩＤ用鍵で暗号化し、暗号化ＩＤを出力する。

図２２は、第二の実施例の秘匿インデックスマップテーブル２６２Ｂのデータ構造を示す。第二の実施例の秘匿インデックスマップテーブル２６２Ｂが第一の実施例の秘匿インデックスマップテーブル２６２（図５）と異なる点は、”マップＩＤカラム名”カラムがないこと、また、マッピングテーブル３６３との関連を示す”マッピングテーブル名”カラムを有することである。それ以外は第一の実施例の秘匿インデックスマップテーブル２６２（図５）と同じである。例えば、レコード２６２１Ｂは、”医療情報”スキーマの”患者情報”テーブルにおいて、関連するマッピングテーブルとハッシュテーブルを持つ”カラム名”が”病名”であり、関連する”マッピングテーブル名”が”ＭＴ１”であり、関連する”ハッシュテーブル名”が”ＨＴ１”であることを示す。

図２３は、第二の実施例の暗号化メインテーブル３６１Ｂのデータ構造を示す。第二の実施例の暗号化メインテーブル３６１Ｂが第一の実施例の暗号化メインテーブル３６１（図６）と異なる点は、”マップＩＤカラム”がないことである。この違いにより、暗号化メインテーブル３６１Ｂ上で、各レコードが対応するＭａｐＩＤを特定することができない。それ以外は第一の実施例の暗号化メインテーブル３６１（図６）と同じである。

図２４は、第二の実施例のマッピングテーブル３６３（ＭＴ１）のデータ構造を示す。マッピングテーブル３６３は、クラウドシステム側サーバ４のディスク装置３６０又は（及び）メモリ３１０に格納され、暗号化メインテーブル３６１Ｂ上の各レコードとハッシュテーブル３６２Ｂ（ＨＴ１）上の”ＭａｐＩＤ”の対応関係を隠蔽して保持する。なお、マッピングテーブル３６３は、ディスク装置３６０及びメモリ３１０の両方に格納されてもよい。マッピングテーブル３６３は、”ＭＩＤ”カラム、”暗号化ＩＤ”カラム及び”ＭａｐＩＤ”の値を示す”ＭａｐＩＤ”カラムによりレコードを構成する。”ＭＩＤ”カラムは、マッピングテーブル上のレコードを一意に特定する識別子である。”暗号化ＩＤ”カラムは、暗号化メインテーブル３６１Ｂの”ＩＤ”カラムの値をＩＤ暗号化部２１２９又はＩＤ暗号化部３１２５が暗号化した暗号化ＩＤを示す。”ＭａｐＩＤ”カラムは、マッピングテーブル３６３の各レコードと対応するハッシュテーブル３６２の”ＭａｐＩＤ”の値を示す。

例えば、レコード３６３１は、当該レコードを一意に特定する識別子”ＭＩＤ”カラムの値が”１０１”であり、対応する暗号化メインテーブル３６１Ｂのレコードの”ＩＤ”カラムの値を暗号化した値である”暗号化ＩＤ”カラムの値が”ＩＥｎｃ（１）”であり、ハッシュテーブル３６２と対応する”ＭａｐＩＤ”カラムの値が”１”であることを示す。

このマッピングテーブル３６３のデータ構造により、暗号化メインテーブル３６１Ｂ上の各レコードが対応するハッシュテーブル３６２の”ＭａｐＩＤ”の値を隠蔽して保持する。なお、”ＩＥｎｃ（ ）”は、”（ ）”内の平文ＩＤが、ＩＤ暗号化部２１２９あるいはＩＤ暗号化部３１２５により暗号化された暗号化ＩＤであることを示す。また、”ＭＩＤ”カラム及び”ＭａｐＩＤ”カラムには、データベース制御部３１１の通常のインデックス機能を適用する。

図２５は、検索を高速化するために用いるハッシュテーブル３６２Ｂのデータ構造を示す。第二の実施例のハッシュテーブル３６２Ｂが、第一の実施例のハッシュテーブル３６２（図７）と異なる点は、”ＭａｐＩＤ”カラム及び”暗号化ハッシュ値”カラムによりレコードを構成することである。”ＭａｐＩＤ”カラムは、マッピングテーブル３６３との対応情報を示す。”暗号化ハッシュ値”は、ハッシュ値生成部２１２３が生成したハッシュ値とＩＤ用鍵のペアのビット列とを秘匿インデックス用ＳＱＬ変換部２１２７が暗号化した値を示す。

例えば、レコード３６２１Ｂは、マッピングテーブル３６３の”ＭａｐＩＤ”カラムの値と対応する”ＭａｐＩＤ”の値が”１”であり、それに対応する”暗号化ハッシュ値”の値が”ＩＮＥｎｃ（ＩＤ＿ｋｅｙ＿１，０７６５）”であることを示す。”ＭａｐＩＤ”カラムの値は、マッピングテーブル３６３の一つ以上のレコードの”ＭａｐＩＤ”の値と等しく、”ＭａｐＩＤ”を指定することによりマッピングテーブル３６３及び暗号化メインテーブル３６１Ｂの全レコードを全件検索することなく、検索範囲を限定する。

なお、”ＩＮＥｎｃ（ｘ，ｙ）”は、”（ ）”内のＩＤ用鍵ｘ及びハッシュ値ｙが、インデックス用暗号化部２１２０により暗号化された暗号化ハッシュ値であることを示す。また、”ＭａｐＩＤ”カラムには、データベース制御部３１１の通常のインデックス機能を適用する。

（２−２）秘匿化データベースの検索に関する処理の流れ
図２６、図２７及び図１０を用いて、第二の実施例の秘匿化データベースシステム１において、ハッシュテーブル３６２Ｂ及びマッピングテーブル３６３を用いた検索である秘匿インデックス検索を行う際の、データベースラッパー部２１２及びデータベース制御部３１１が行う一連の処理について、主に第一の実施例との違いを説明する。

図２６は、第二の実施例の秘匿インデックス検索クエリ生成処理を示すフローチャートである。第二の実施例の秘匿インデックス検索クエリ生成処理が、第一の実施例の秘匿インデックス検索クエリ生成処理と異なる点は、マッピングテーブル３６３を用いて暗号化メインテーブル３６１Ｂの”ＩＤ”カラムとハッシュテーブル３６２Ｂの”ＭａｐＩＤ”カラムを対応付けることである。この処理は、データベースラッパー部２１２がアプリケーション部２１１から平文の検索のＳＱＬを受信すると、開始する。例えば、第一の実施例と同様に、データベースラッパー部２１２が受信するＳＱＬは、平文の検索のＳＱＬ（１）である。

SELECT * FROM 医療情報.患者情報 WHERE 病名＝糖尿病 （１）※再掲

この検索ＳＱＬは、スキーマ名が”医療情報”であり、テーブル名が”患者情報”であるテーブルから、”病名”カラムの値が”糖尿病”であるレコードを検索し、条件に一致する全てのカラムの値を検索結果として得ることを意味する（ステップ２５１０）。

次に、データベースラッパー部２１２は、第一の実施例のステップ８２０と同様に、まず鍵管理部２１２５から暗号化鍵及び検索用鍵を取得し、取得した鍵を検索クエリ生成部２１２２に入力し、その出力として暗号化検索クエリを得る。例えば、平文のＳＱＬが（１）である場合、以下の実行式（２）である（ステップ２５２０）。

暗号化検索クエリ（糖尿病）
＝ 検索クエリ生成部（暗号化鍵、検索用鍵、"糖尿病"） （２）※再掲

次に、データベースラッパー部２１２は、第一の実施例のステップ８３０と一部異なり、秘匿インデックスマップテーブル２６２から、検索対象カラムの”マッピングテーブル名”及び”ハッシュテーブル名”を取得する。具体的には、データベースラッパー部２１２は、平文の検索ＳＱＬが検索対象とするスキーマ名、暗号化メインテーブル名及びカラム名の組をキーとして、秘匿インデックスマップテーブル２６２Ｂを検索し、スキーマ名、暗号化メインテーブル名及びカラム名が一致するレコードの”マッピングテーブル名”及び”ハッシュテーブル名”を取得する。例えば、平文の検索ＳＱＬが（１）である場合、スキーマ名が”医療情報”であり、かつ暗号化メインテーブル名が”患者情報”であり、かつカラム名が”病名”であるレコード２６２１Ｂから、マッピングテーブル名”ＭＴ１”及びハッシュテーブル名”ＨＴ１”を取得する（ステップ２５３０）。

次に、データベースラッパー部２１２は、第一の実施例における図８のステップ８３０と同様に、ステップ２５３０の結果が存在するか否かを判定する（ステップ２５４０）。

ステップ２５４０の結果が”存在しない”である場合（ＮＯ）、第一の実施例における図８のステップ８５０と同様に、データベースラッパー部２１２は、平文のＳＱＬの検索対象の値を、ステップ２５２０で生成した暗号化検索クエリに置き換え、さらに、ＷＨＥＲＥ句の一致比較文を、ユーザ定義機能部３１２の暗号文一致比較部３１２１を呼び出す形式に置き換えた、暗号文の検索ＳＱＬを出力する。例えば、平文のＳＱＬが（１）であり、暗号化検索クエリが（２）である場合、暗号文の検索ＳＱＬは、以下の暗号文の検索ＳＱＬ（３）となる（ステップ２５５０）。

SELECT * FROM 医療情報.患者情報
WHERE 暗号文一致比較部（病名、暗号化検索クエリ（糖尿病））（３）※再掲

一方、ステップ２５４０の結果が”存在する”である場合（ＹＥＳ）、データベースラッパー部２１２は、ハッシュテーブル３６２及びマッピングテーブル３６３を用いた高速検索を行うために、ハッシュ値生成から秘匿インデックス用検索ＳＱＬ変換（ステップ２５６０〜２５８０）の処理を行った暗号文の検索ＳＱＬを出力する。

まず、データベースラッパー部２１２は、第一の実施例における図８のステップ８６０と同様に、検索対象の値をハッシュ値生成部２１２３に入力し、出力されるハッシュ値を取得する。例えば、平文の検索ＳＱＬが（１）である場合、以下のハッシュ値（４）を取得する（ステップ２５６０）。

ハッシュ値 ＝ ハッシュ値生成部（糖尿病）＝"1012" （４） ※再掲

次に、データベースラッパー部２１２は、第一の実施例における図８のステップ８７０とは一部異なり、ハッシュテーブル３６２Ｂを検索するために、ステップ２５６０で取得したハッシュ値をインデックス用検索クエリ生成部２１２８に入力し、出力をインデックス用ハッシュテーブル検索クエリとする。例えば、平文のハッシュ値が（４）である場合、以下のインデックス用ハッシュテーブル検索クエリ（５−２）を取得する（ステップ２５７０）。

インデックス用ハッシュテーブル検索クエリ（1012）
＝インデックス用検索クエリ生成部（暗号鍵、検索用鍵、"1012"） （５−２）

次に、データベースラッパー部２１２は、第一の実施例における図８のステップ８８０とは一部異なり、ハッシュテーブル３６２Ｂを検索して検索範囲を限定した上で、検索範囲に相当する暗号化ＩＤをマッピングテーブル３６３から特定して、暗号化ＩＤを復号してＩＤとし、そのＩＤに対応する暗号化メインテーブル３６１Ｂのレコードを検索するためのＳＱＬを生成する秘匿インデックス用検索ＳＱＬ変換を行う。具体的には、ステップ２５２０で得た暗号化検索クエリと、ステップ２５３０で得たマッピングテーブル名及びハッシュテーブル名と、ステップ２５７０で得たインデックス用ハッシュテーブル検索クエリを入力とし、ハッシュテーブル３６２Ｂをインデックス用ハッシュテーブル検索クエリで検索して該当したレコードの”ＭａｐＩＤ”カラムの値及びＩＤ用鍵を取得する。そして、その値と等しい”ＭａｐＩＤ”カラムの値を持つマッピングテーブル３６３のレコードから検索対象の暗号化ＩＤを特定し、暗号化ＩＤをＩＤ用鍵で復号して検索対象のＩＤを取得する。さらに、ユーザ定義機能部３１２の暗号文一致比較部３１２１を用いて、検索対象のＩＤをもつ暗号化メインテーブル３６１Ｂのレコードから、暗号化検索クエリと一致する値を持つレコードを判定し、一致するレコードからメインテーブル２６１に存在するカラムのみ（”ＩＤ”カラム以外）を選択し、検索結果とする暗号文の検索ＳＱＬを生成し、出力する。例えば、平文の検索ＳＱＬが（１）である場合、以下の暗号文の検索ＳＱＬ（６−２）を出力する（ステップ２５８０）。

SELECT 患者番号, 名前, 病名 FROM 医療情報.患者情報
JOIN (
SELECT ( ID復号部( @ID用鍵, 暗号化ＩＤ) ) AS ID
FROM マッピングテーブル MT1
JOIN (
SELECT MapID,
@ID鍵:=ID用鍵取得部(インデックス用ハッシュテーブル検索クエリ、
暗号化ハッシュ値)
FROM ハッシュテーブル HT1
WHERE インデックス用一致比較部（インデックス用ハッシュテーブル検索クエリ、
暗号化ハッシュ値）
) IDResult
ON ( MT1.MapID = IDResult.MapID )
) MapResult
ON 医療情報.患者情報.ID = MapResult.ID
WHERE 暗号化一致比較部（病名、暗号化検索クエリ（糖尿病）） （６−２）

最後に、データベースラッパー部２１２は、ステップ２５５０又はステップ２８８０で出力された暗号文の検索ＳＱＬを、データベースインタフェース部２１３へ送信する。平文の検索ＳＱＬが（１）である場合、ステップ２５４０の結果が存在するため、データベースラッパー部２１２はステップ２５８０が出力した暗号文の検索ＳＱＬ（６−２）をデータベースインタフェース部２１３へ送信する（ステップ２５９０）。以上で、データベースラッパー部２１２は、秘匿インデックス検索クエリ生成処理（図２６）を終了する。

図２７は、第二の実施例の秘匿インデックス検索処理を示すフローチャートである。第二の実施例の秘匿インデックス検索処理が、第一の実施例の秘匿インデックス検索処理（図９）と異なる点は、マッピングテーブル３６３を用いて暗号化メインテーブル３６１Ｂの”ＩＤ”カラムとハッシュテーブル３６２Ｂの”ＭａｐＩＤ”カラムを対応付けることである。秘匿インデックス検索処理は、データベース制御部３１１がデータベースインタフェース部２１３から暗号文の検索ＳＱＬを受信すると、開始する。例えば、
秘匿インデックス検索処理の開始時にデータベース制御部３１１が受信する暗号文の検索ＳＱＬは、ＳＱＬ（６−２）である。

まず、データベース制御部３１１は、暗号文の検索ＳＱＬから、検索対象となるハッシュテーブル３６２Ｂとインデックス用ハッシュテーブル検索クエリを特定し、ユーザ定義機能部３１２のインデックス用一致比較部３１２２により当該ハッシュテーブル３６２Ｂの”暗号化ハッシュ値”カラムの値と当該インデックス用ハッシュテーブル検索クエリが一致するレコードを特定し、そのレコードの”ＭａｐＩＤ”カラムの値をＭａｐＩＤ＿ｈｉｔとして取得する。例えば、暗号文の検索ＳＱＬが（６−２）である場合、ハッシュテーブルはハッシュテーブル３６２Ｂ（ＨＴ１）であり、インデックス用ハッシュテーブル検索クエリは（５−２）の”インデックス用ハッシュテーブル検索クエリ（１０１２）”である。さらに、インデックス用一致比較部３１２２による一致比較の結果、ハッシュテーブル３６２Ｂ（ＨＴ１）のレコード３６２２Ｂの暗号化ハッシュ値”ＩＮＥｎｃ（ＩＤ＿ｋｅｙ＿２， １０１２）”と一致し、当該レコードのＭａｐＩＤ”２”をＭａｐＩＤ＿ｈｉｔとして取得する（ステップ２６１０）。

次に、データベース制御部３１１は、マッピングテーブル３６３から、”ＭａｐＩＤ”カラムの値がＭａｐＩＤ＿ｈｉｔと一致するレコード群をＨａｓｈＲｅｓｕｌｔとして取得する。例えば、暗号文の検索ＳＱＬが（６−２）である場合、ＭａｐＩＤ＿ｈｉｔが”２”であるため、マッピングテーブル３６３の”ＭａｐＩＤ”の値が２であるレコード３６３２及び３６３３をＨａｓｈＲｅｓｕｌｔとして取得する（ステップ２６２０）。

次に、データベース制御部３１１は、インデックス用ハッシュテーブル検索クエリ及びステップ２６１０でヒットした暗号化ハッシュ値をＩＤ用鍵取得部３１２３に入力してＩＤ用鍵を取得する。さらに、そのＩＤ用鍵とＨａｓｈＲｅｓｕｌｔの”暗号化ＩＤ”カラムの値をＩＤ復号化部３１２４に入力して、検索対象のＩＤ群であるＩＤＲｅｓｕｌｔを取得する。例えば、暗号文の検索ＳＱＬが（６−２）である場合、ステップ２６１０でヒットした暗号化ハッシュ値”ＩＮＥｎｃ（ＩＤ＿ｋｅｙ＿２，０１２０）”であり、ＩＤ用鍵取得部３１２３からＩＤ用鍵”ＩＤ＿ｋｅｙ＿２”を得る。取得したＩＤ用鍵で、ステップ３６２０で取得したＨａｓｈＲｅｓｕｌｔ（マッピングテーブル３６３のレコード３６３２及び３６３３）の暗号化ＩＤ”ＩＥｎｃ（３）、ＩＥｎｃ（１００００００）”を復号化し、ＩＤＲｅｓｕｌｔ”３、４”を取得する（ステップ２６３０）。

次に、データベース制御部３１１は、暗号化メインテーブル３６１Ｂから、ＩＤＲｅｓｕｌｔに対応する”ＩＤ”カラムの値を持ち、かつ暗号化検索クエリと一致する値を持つことをユーザ定義機能部３１２の暗号文一致比較部３１２１により確認したレコード群ＭａｐＲｅｓｕｌｔを取得する。例えば、暗号文の検索ＳＱＬが（６−２）である場合、データベース制御部３１１は、暗号文一致比較部３１２１により、”ＩＤ”カラムの値がステップ２６３０で取得した”３、４”と一致し、かつ暗号化検索クエリ（糖尿病）の値と一致する”病名”カラムの値であるＥｎｃ（糖尿病）を持つレコード群を暗号化メインテーブル３６１Ｂで確認し、その結果レコード３６１３Ｂ及びレコード３６１５ＢをＭａｐＲｅｓｕｌｔとして取得する（ステップ２６４０）。

最後に、データベース制御部３１１は、ＭａｐＲｅｓｕｌｔから”ＩＤ”カラムを除いたレコード群を検索結果としてユーザシステム側サーバ３のデータベースインタフェース部２１３へ送信する。例えば、暗号文の検索ＳＱＬが（６−２）である場合、暗号化メインテーブル３６１Ｂのレコード３６１３Ｂ及び３６１５Ｂから、”ＩＤ”カラムを除いたレコード群を暗号文の検索結果として送信する（ステップ２６５０）。以上で、秘匿インデックス検索処理（図２７）を終了する。

第二の実施例において、検索結果復号処理は、第一の実施例の検索結果復号処理（図１０）と同じである。

（２−３）秘匿化データベースへの挿入に関する処理の流れ
図２８及び図２９を用いて、第二の実施例の秘匿化データベースシステム１において、ハッシュテーブル３６２Ｂ及びマッピングテーブル３６３を用いた挿入である秘匿インデックス挿入を行う際の、データベースラッパー部２１２及びデータベース制御部３１１が行う一連の処理について、主に第一の実施例との違いを説明する。

図２８は、第二の実施例の秘匿インデックス挿入クエリ生成処理を示すフローチャートである。第二の実施例の秘匿インデックス挿入クエリ生成処理が、第一の実施例の秘匿インデックス挿入クエリ生成処理（図１１）と異なる点は、マッピングテーブル３６３に対する挿入処理が加わることである。秘匿インデックス挿入クエリ生成処理は、データベースラッパー部２１２がアプリケーション部２１１から平文の挿入のＳＱＬを受信すると、開始する。秘匿インデックス挿入クエリ生成処理の開始時にデータベースラッパー部２１２が受信する平文の挿入ＳＱＬは、第一の実施例と同様に、以下の平文の挿入ＳＱＬ（７）である。

INSERT INTO 医療情報.患者情報 ( 患者番号, 名前, 病名 )
VALUES ( 1000001, 木下, 胃腸炎) （７）※再掲

この挿入ＳＱＬは、スキーマ名が”医療情報”であり、テーブル名が”患者情報”であるテーブルに対し、”患者番号”カラムの値が”１０００００１”であり、”名前”カラムの値が”木下”であり、”病名”カラムの値が”胃腸炎”であるレコードを挿入することを意味する（ステップ２７１０）。

次に、データベースラッパー部２１２は、第一の実施例における図１１のステップ１１２０と同様に、平文の挿入ＳＱＬから挿入対象の値を取り出し、暗号化部２１２１により暗号化する。例えば、平文の挿入ＳＱＬが（７）である場合、挿入対象の値は”１０００００１”、”木下”及び”胃腸炎”であり、暗号化部２１２１により暗号化した結果の出力の暗号文は、それぞれ”Ｅｎｃ（１０００００１）”、”Ｅｎｃ（木下）”及び”Ｅｎｃ（胃腸炎）”となる（ステップ２７２０）。

次に、データベースラッパー部２１２は、図１１のステップ１１３０と同様に、秘匿インデックスマップテーブル２６２Ｂから、挿入対象レコードに関連する”マッピングテーブル名”及び”ハッシュテーブル名”を取得する。具体的には、データベースラッパー部２１２は、平文の挿入ＳＱＬが挿入対象とするスキーマ名及び暗号化メインテーブル名の組をキーとして、秘匿インデックスマップテーブル２６２Ｂを検索し、スキーマ及び暗号化メインテーブル名が一致するすべてのレコードから、”カラム名”、”マッピングテーブル名”及び”ハッシュテーブル名”を取得する。例えば、平文の挿入ＳＱＬが（７）である場合、スキーマ名が”医療情報”でありかつ暗号化メインテーブル名が”患者情報”であるレコード２６２１Ｂから、カラム名”病名”、マッピングテーブル名”ＭＴ１”及びハッシュテーブル名”ＨＴ１”を取得する（ステップ２７３０）。

次に、データベースラッパー部２１２は、第一の実施例における図１１のステップ１１４０と同様に、ステップ２７３０の結果が存在するか否かを判定する（ステップ２７４０）。

ステップ２７４０の結果が存在しない場合（ＮＯ）、第一の実施例における図１１のステップ１１５０と同様に、データベースラッパー部２１２は、平文の挿入ＳＱＬの挿入対象の値を、ステップ２７２０で生成した暗号文の値に置き換えた暗号文の挿入ＳＱＬを出力する。例えば、平文のＳＱＬが（７）である場合、以下の暗号文の挿入ＳＱＬ（８）を出力する（ステップ２７５０）。

INSERT INTO 医療情報.患者情報 ( 患者番号, 名前, 病名 )
VALUES ( Enc(1000001), Enc(木下), Enc(胃腸炎) ) （８）※再掲

一方、ステップ２７４０の結果が存在する場合（ＹＥＳ）、データベースラッパー部２１２は、ハッシュテーブル３６２Ｂと一貫性を保持した挿入を行うために、ハッシュ値生成から秘匿インデックス用挿入ＳＱＬ変換（ステップ２７６０〜２７９０）の処理を行い暗号文の挿入ＳＱＬを出力する。

まず、データベースラッパー部２１２は、第一の実施例における図１１のステップ１１６０と同様に、挿入対象の値のうち、ハッシュテーブル３６２Ｂに関連するカラムの値をハッシュ値生成部２１２３に入力し、出力されるハッシュ値を取得する。例えば、平文の挿入ＳＱＬが（７）である場合、以下のハッシュ値を（８）取得する（ステップ２７６０）。

ハッシュ値 ＝ ハッシュ値生成部（胃腸炎） ＝ "0035" （８）

次に、データベースラッパー部２１２は、第一の実施例における図１１のステップ１１７０と異なり、ハッシュテーブル３６２Ｂを検索するために、ステップ２７６０で取得したハッシュ値をインデックス用検索クエリ生成部２１２８に入力し、出力をインデックス用ハッシュテーブル検索クエリとする。例えば、平文のハッシュ値が（８）である場合、以下のハッシュテーブル検索クエリ（９−２）を取得する（ステップ２７７０）。

インデックス用ハッシュテーブル検索クエリ（0035）
＝インデックス用検索クエリ生成部（暗号鍵、検索用鍵、"0035"） （９−２）

次に、データベースラッパー部２１２は、第一の実施例における図１１のステップ１１８０と異なり、ハッシュ値（８）及び鍵管理部２１２５から取得したＩＤ用鍵をインデックス用暗号化部２１２０に入力し、出力される暗号化ハッシュ値を取得する。例えば、平文のハッシュ値が（８）であり、かつＩＤ用鍵が”ＩＤ＿ｋｅｙ＿３”である場合、暗号化ハッシュ値は”ＩＮＥｎｃ（ＩＤ＿ｋｅｙ＿３，００３５）”となる（ステップ２７８０）。

次に、データベースラッパー部２１２は、第一の実施例における図１１のステップ１１９０と同様に、ハッシュテーブル３６２Ｂをインデックス用ハッシュテーブル検索クエリで検索し、検索で一致しない場合は新しいＭａｐＩＤと暗号化ハッシュ値からなるレコードをハッシュテーブル３６２Ｂへ挿入し、ハッシュテーブル検索クエリに一致するレコードのＭａｐＩＤを取得し、そのＭａｐＩＤとステップ２７２０で取得した暗号文のレコードの値と新しいレコードの識別子であるＩＤとから構成されるレコードを暗号化メインテーブル３６１Ｂへ挿入し、最後に新レコードのＩＤをＩＤ暗号化部３１２５により暗号化した暗号化ＩＤと新ＭａｐＩＤから成るレコードをマッピングテーブル３６３に挿入する秘匿インデックス用挿入ＳＱＬ変換を行う。例えば、平文のＳＱＬが（７）である場合、以下の暗号文の挿入ＳＱＬ（１１−２）、（１２−２）及び（１３−２）を出力する（ステップ２７９０）。

INSERT INTO ハッシュテーブルHT1（ MapID, 暗号化ハッシュ値 ）
SELECT 新MapID，暗号化ハッシュ値"INEnc(ID_key_3, 0035)"
FROM ハッシュテーブルHT1 WHERE ＮＯT EXIST
(
SELECT * FROM ハッシュテーブルHT1
WHERE インデックス用暗号化一致比較部（暗号化ハッシュ値、
インデックス用ハッシュテーブル検索クエリ(0035) ）
) LIMIT 1; （１１）

INSERT INTO 暗号化メインテーブル
（ 患者番号，名前，病名，ＩＤ ）
VALUES
（ Enc(1000001)，Enc(木下), Enc(胃腸炎), 新ID，
（ SELECT MapID FROM ハッシュテーブルHT1
WHERE暗号化一致比較部（暗号化ハッシュ値,
インデックス用ハッシュテーブル検索クエリ(0035) ）
); （１２−２）

INSERT INTO マッピングテーブルMT1 ( 暗号化ID, MapID )
VALUES (
( SELECT ID用暗号化部（@ID用鍵, 新ID
FROM (
( SELECT @ID用鍵:=ID用鍵取得部（インデックス用ハッシュテーブル検索クエリ、
暗号化ハッシュ値）
FROM ハッシュテーブルHT1
WHERE インデックス用一致比較部（
インデックス用ハッシュテーブル検索クエリ、暗号化ハッシュ値）
) keytemp
, ( SELECT @新ＩＤ:= MAX(ID) FROM 医療情報.病院情報 ) IDtemp
)
, ( SELECT MapID FROM ハッシュテーブルHT1
WHERE インデックス用一致比較部（
インデックス用ハッシュテーブル検索クエリ、暗号化ハッシュ値)
)
); （１３−２）

最後に、データベースラッパー部２１２は、第一の実施例における図１１のステップ２７９５と同様に、ステップ２７５０又はステップ２７９０で出力された暗号文の挿入ＳＱＬを、データベースインタフェース部２１３へ送信する。例えば、平文の挿入ＳＱＬが（７）である場合、ステップ２７４０の結果が存在するため、データベースラッパー部２１２はステップ２７９０が出力した暗号文の挿入ＳＱＬ（１１−２）、（１２−２）及び（１３−２）をデータベースインタフェース部２１３へ送信する（ステップ２７９５）。以上で、秘匿インデックス挿入クエリ生成処理（図２８）を終了する。

図２９は、第二の実施例の秘匿インデックス挿入処理を示すフローチャートである。第二の実施例の秘匿インデックス挿入処理が、第一の実施例の秘匿インデックス挿入処理（図１２）と異なる点は、マッピングテーブル３６３に対する挿入処理が加わることである。秘匿インデックス挿入処理は、データベース制御部３１１がデータベースインタフェース部２１３から暗号文の挿入ＳＱＬを受信すると、開始する。例えば、秘匿インデックス挿入処理の開始時にデータベース制御部３１１が受信する暗号文の挿入ＳＱＬは、ＳＱＬ（１１−２）、（１２−２）及び（１３−２）である。

まず、データベース制御部３１１は、暗号文の検索ＳＱＬから、検索対象となるハッシュテーブル３６２Ｂとインデックス用ハッシュテーブル検索クエリと暗号化ハッシュ値とを特定し、ユーザ定義機能部３１２のインデックス用一致比較部３１２２により当該ハッシュテーブル３６２Ｂの”暗号化ハッシュ値”のカラムの値と当該インデックス用ハッシュテーブル検索クエリが一致するレコードが存在するか否かを判定する（ステップ２８１０）。

ステップ２８１０にて一致するレコードがある場合（ＹＥＳ）、データベース制御部３１１はそのレコードのＭａｐＩＤカラムの値をＭａｐＩＤ＿ｈｉｔとして取得する（ステップ２８２０）。例えば、挿入ＳＱＬが（１１−２）である場合、ＭａｐＩＤ＿ｈｉｔは”１０”となる。

一方、ステップ２８１０にて一致するレコードがない場合、データベース制御部３１１は、新しいＭａｐＩＤを生成してＭａｐＩＤ＿ｈｉｔとし、検索ＳＱＬから取得した暗号化ハッシュ値と共に、ハッシュテーブル３６２Ｂへレコードとして挿入する（ステップ２８３０）。

次に、データベース制御部３１１は、暗号文の挿入ＳＱＬを実行し、暗号化された値及びＩＤから構成されるレコードを暗号化メインテーブル３６１Ｂへ挿入する。例えば、暗号文の挿入ＳＱＬが（１２−２）である場合、データベース制御部３１１は、患者番号が”Ｅｎｃ（１０００００１）”、名前が”Ｅｎｃ（木下）”、 病名が”Ｅｎｃ（胃腸炎）”及びＩＤが”１０００００１”であるレコードを暗号化メインテーブル３６１Ｂへ挿入する（ステップ２８４０）。

次に、データベース制御部３１１は、インデックス用ハッシュテーブル検索クエリ及び暗号化ハッシュ値をＩＤ用鍵取得部３１２３へ入力し、出力としてＩＤ用鍵を取得する。例えば、暗号化ハッシュ値が（１１−２）の ”ＩＮＥｎｃ（ＩＤ＿ｋｅｙ＿３， ００３５）”であったとすると、ＩＤ用鍵としてＩＤ＿ｋｅｙ＿３を取得する（ステップ２８５０）。

次に、データベース制御部３１１は、新ＩＤとステップ２８５０で取得したＩＤ用鍵をＩＤ暗号化部３１２５に入力し、出力として暗号化ＩＤを取得する。例えば、新ＩＤが”１０００００１”である場合、暗号化ＩＤは”ＩＥｎｃ（１０００００１）”となる（ステップ２８６０）。

次に、データベース制御部３１１は、マッピングテーブル３６３へ、ステップ２８６０で取得した暗号化ＩＤとステップ２８２０又はステップ２８３０で取得したＭａｐＩＤ＿ｈｉｔからなるレコードを挿入する。例えば、挿入ＳＱＬが（１１−２）、（１２−２）及び（１３−２）である場合、暗号化ＩＤ”ＩＥｎｃ（１０００００１）”及びＭａｐＩＤ＿ｈｉｔ”１０”からなるレコードをマッピングテーブル３６３へ挿入する。なお、”ＭＩＤ”カラムの値は、データベース制御部３１１が通常の自動採番機能にて付与する（ステップ２８７０）。

最後に、データベース制御部３１１は、挿入ＳＱＬの実行結果をユーザシステム側サーバ３のデータベースインタフェース部２１３へ送信する（ステップ２８８０）。以上で、秘匿インデックス挿入処理（図２８）を終了する。

（２−４）秘匿化データベースの更新に関する処理の流れ
図３０、図１４、図３１及び図３２を用いて、第二の実施例の秘匿化データベースシステム１において、ハッシュテーブル３６２Ｂ及びマッピングテーブル３６３を用いた更新である秘匿インデックス更新を行う際の、データベースラッパー部２１２及びデータベース制御部３１１が行う一連の処理について、主に第一の実施例との違いを説明する。

図３０は、第二の実施例のユーザシステム側サーバ３のデータベースラッパー部２１２が実行する秘匿インデックス更新クエリ生成処理を示すフローチャートである。秘匿インデックス更新クエリ生成処理は、データベースラッパー部２１２がアプリケーション部２１１から平文の更新のＳＱＬを受信すると、開始する。例えば、秘匿インデックス更新クエリ生成処理の開始時にデータベースラッパー部２１２が受信する平文の更新ＳＱＬは、第一の実施例と同様に、平文の更新ＳＱＬ（１３）である。

UPDATE 医療情報.患者情報 SET "病名"＝"狭心症"
WHERE "病名"＝"糖尿病" （１３）※再掲

この更新ＳＱＬ（１３）は、スキーマ名が”医療情報”であり、テーブル名が”患者情報”であるテーブルの”病名”カラムの値が”糖尿病”であるレコードにおいて、”病名”カラムの値を”狭心症”へ更新することを意味する（ステップ２９０５）。

次に、データベースラッパー部２１２は、平文の更新ＳＱＬから、更新元カラムの値を取り出し、検索クエリ生成部２１２２を用いて暗号化メインテーブル３６１Ｂにおける一致検索に用いる暗号化検索クエリを取得する。具体的には、データベースラッパー部２１２は、鍵管理部２１２５から暗号化鍵及び検索用鍵を取得し、それらを検索クエリ生成部２１２２に入力し、その出力として暗号化検索クエリを得る。例えば、平文の更新ＳＱＬが（１３）である場合の例としては、（２）と同様に”暗号化検索クエリ（糖尿病）”を得る（ステップ２９１０）。

次に、データベースラッパー部２１２は、秘匿インデックスマップテーブル２６２から、更新元のカラムの”マッピングテーブル名”及び”ハッシュテーブル名”を取得する。具体的には、データベースラッパー部２１２は、平文の検索ＳＱＬが検索対象とするスキーマ名、暗号化メインテーブル名及び更新元のカラム名の組をキーとして、秘匿インデックスマップテーブル２６２Ｂを検索し、スキーマ名、暗号化メインテーブル名及びカラム名が一致するレコードの”マッピングテーブル名”及び”ハッシュテーブル名”を取得する。例えば、平文の検索ＳＱＬが（１３）である場合、スキーマ名が”医療情報”であり、かつ暗号化メインテーブル名が”患者情報”であり、かつ更新元のカラム名”病名”を含むレコード２６２１Ｂから、マッピングテーブル名”ＭＴ１”及びハッシュテーブル名”ＨＴ１”を取得する（ステップ２９１５）。

次に、データベースラッパー部２１２は、ステップ２９１５の結果が存在するか否かを判定する（ステップ２９２０）。

ステップ２９１５の結果が存在しない場合（ＮＯ）、第一の実施例における図１３のステップ１３３０と同様に、データベースラッパー部２１２は、暗号化メインテーブル３６１Ｂから更新対象となるレコードのＩＤのリストである更新対象ＩＤリストを取得するＳＱＬを、データベースインタフェース部２１３へ送信し、結果として更新対象ＩＤリストを受信する。例えば、平文の更新ＳＱＬが（１３）である場合、以下のＳＱＬ（１４）で更新対象ＩＤリストを取得する（ステップ２９２５）。

SELECT ID FROM 医療情報.患者情報
WHERE 暗号文一致比較部（病名、暗号化検索クエリ（糖尿病）） （１４）※再掲

データベースラッパー部２１２は、第一の実施例における図１３のステップ１３３５と同様に、ステップ２９２５で得られた更新ＩＤリストから更新対象ＩＤの個数を取得し、更新対象ＩＤの個数分の、更新後の値の暗号文を生成する。例えば、平文の更新ＳＱＬが（１３）である場合、更新対象ＩＤの数は”３”及び”１００００００”の二つであるため、更新後の値の暗号文はＥｎｃ（狭心症）及びＥｎｃ（狭心症）の二つとなる。確率的暗号化を用いる場合、これらは異なる暗号文となる（ステップ２９３０）。

次に、データベースラッパー部２１２は、第一の実施例における図１３のステップ１３３５で得られた二つの更新後の値の暗号文を、それぞれの更新対象ＩＤの示すレコードの値として更新する暗号文の更新ＳＱＬを生成する。例えば、平文の更新ＳＱＬが（１３）である場合、以下の暗号文の更新ＳＱＬ（１５）が出力される（ステップ２９３５）。

UPDATE 医療情報.患者情報
SET "病名"＝
CASE ID
WHEN 3 THEN Enc(狭心症)
WHEN 1000000 THEN Enc(狭心症)
END
WHERE 暗号文一致比較部（病名、暗号化検索クエリ（糖尿病）） （１５）※再掲

一方、ステップ２９１５の結果が存在する場合（ＹＥＳ）、データベースラッパー部２１２は、暗号化メインテーブル３６１Ｂ、ハッシュテーブル３６２Ｂ及びマッピングテーブル３６３を更新するために、ハッシュ値生成から秘匿インデックス用更新ＳＱＬ変換（ステップ２９４０〜２９７０）を行った暗号文の更新ＳＱＬを出力する。

まず、データベースラッパー部２１２は、第一の実施例における図１３のステップ１３４５と同様に、更新後の値をハッシュ値生成部２１２３に入力し、出力されるハッシュ値を取得する。例えば、平文の更新ＳＱＬが（１３）である場合、ハッシュ値（１６）を取得する（ステップ２９４０）。

ハッシュ値 ＝ ハッシュ値生成部（狭心症）＝"0500" （１６）※再掲

次に、データベースラッパー部２１２は、ハッシュテーブル３６２Ｂを検索するために、ステップ２９４５で取得したハッシュ値をインデックス用検索クエリ生成部２１２８に入力し、出力をインデックス用ハッシュテーブル検索クエリとする。例えば、平文のハッシュ値が（１６）である場合、以下のハッシュテーブル検索クエリ（１７−２）を取得する（ステップ２９４５）。

インデックス用ハッシュテーブル検索クエリ（0500）
＝インデックス用検索クエリ生成部（暗号鍵、検索用鍵、"0500"） （１７−２）

次に、データベースラッパー部２１２は、ステップ２９４０で取得したハッシュ値及び鍵管理部２１２５から取得したＩＤ用鍵をインデックス用暗号化部２１２０へ入力し、出力としてハッシュテーブル３６２Ｂに挿入するための暗号化ハッシュ値を取得する。例えば、平文のハッシュ値（１６）が”０５００”であり、ＩＤ用鍵が”ＩＤ＿ｋｅｙ＿４”である場合、暗号化ハッシュ値は”ＩＮＥｎｃ（ＩＤ＿ｋｅｙ＿４，０５００）”となる（ステップ２９５０）。

次に、データベースラッパー部２１２は、ハッシュテーブル３６２Ｂ及びマッピングテーブル３６３を用いて更新対象となるレコード群のＩＤカラムの値のテーブルを取得する秘匿インデックス用更新対象ＩＤテーブル取得ＳＱＬを実行し、更新対象ＩＤテーブルを得る。具体的には、データベースラッパー部２１２は、ステップ２９１０で取得した更新元の値の暗号化検索クエリ、ステップ２９１５で取得した更新元のカラムに関連するマッピングテーブル名とハッシュテーブル名、更新元の値のインデックス用ハッシュテーブル検索クエリを入力とし、ハッシュテーブル３６２Ｂとマッピングテーブル３６３を検索した上で暗号化メインテーブル３６１Ｂの検索範囲を限定し、更新対象ＩＤテーブルを取得するＳＱＬを実行し、その結果を更新対象ＩＤテーブルとして出力する。例えば、平文の更新ＳＱＬが（１３）である場合、暗号文の秘匿インデックス用更新対象ＩＤテーブル取得ＳＱＬ（１８−２）を生成し、データベースインタフェース部２１３経由でデータベース制御部３１１へ送信し、その実行結果を更新対象ＩＤテーブルとして取得する（ステップ２９５５）。

SELECT ID FROM 暗号化メインテーブル３６１ＢX
JOIN
( SELECT ＩＤ復号化部（＠ID用鍵、暗号化ＩＤ） AS TempID
FROM マッピングテーブルMT1 JOIN
( SELECT MapID, @ID用鍵:=ID用鍵取得部（
インデックス用ハッシュテーブル検索クエリ、暗号化ハッシュ値）
FROM ハッシュテーブルHT1
WHERE インデックス用一致比較部（
インデックス用ハッシュテーブル検索クエリ、暗号化ハッシュ値）
) HitHash ON ( MT1.MapID = HitHash.MapID )
) MapResult
ON X.ID= MapResult.TempID
WHERE インデックス用一致比較部（病名，暗号化検索クエリ(糖尿病)）（１８−２）

次に、データベースラッパー部２１２は、ステップ２９５５で得られた更新対象ＩＤテーブルから更新対象ＩＤの個数を取得し、その個数分の、更新後の値の暗号文リストを生成する。例えば、平文の更新ＳＱＬが（１３）である場合、第一の実施例における図１３のステップ１３３５と同様に、更新対象ＩＤの数は”３”及び”１００００００”の二つであるため、更新後の値の暗号文リストはＥｎｃ（狭心症）及びＥｎｃ（狭心症）の二つとなる。確率的暗号化を用いる場合、これらは異なる暗号文となる（ステップ２９６０）。

次に、データベースラッパー部２１２は、平文の更新ＳＱＬ、ステップ２９１０、ステップ２９１５、ステップ２９４５、ステップ２９５０、ステップ２９５５及びステップ２９６０で取得した各種情報を入力とし、秘匿インデックス用の暗号文の更新ＳＱＬを出力する。具体的には、第一に、ハッシュテーブル３６２Ｂを更新後の値のインデックス用ハッシュテーブル検索クエリでインデックス用一致検索をし、一致しない場合、更新後の値の暗号化ハッシュ値と新しいＭａｐＩＤの値から成るレコードをハッシュテーブル３６２Ｂへ挿入するＳＱＬを生成する。第二に、ハッシュテーブル３６２Ｂから更新後の値のＭａｐＩＤを取得するＳＱＬを生成する。第三に、暗号化メインテーブル３６１Ｂにおいて、更新対象ＩＤをもつレコードごとに、更新後の値の暗号文を置き換える更新ＳＱＬを生成する。第四に、マッピングテーブル３６３において、更新対象ＩＤを持つレコードの”ＭａｐＩＤ”カラムの値を第二のＳＱＬで得られたＭａｐＩＤに置き換えるＳＱＬを生成する。例えば、平文の更新ＳＱＬが（１３）である場合、第一のＳＱＬは以下の更新ＳＱＬ（１９−２）となり、第二のＳＱＬは以下の更新ＳＱＬ（２０−２）となり、第三のＳＱＬは更新ＳＱＬ（２１−２）となり、第四のＳＱＬは以下の更新ＳＱＬ（２２−２）及び（２３−２）となる。これら四つのＳＱＬ文からなる暗号文の更新ＳＱＬを出力する（ステップ２９６５）。

INSERT INTO ハッシュテーブルHT1（ MapID, 暗号化ハッシュ値 ）
SELECT 新MapID，暗号化ハッシュ値"INEnc(ID_key_4, 0500)"
FROM ハッシュテーブルHT1 WHERE ＮＯT EXIST
(
SELECT * FROM ハッシュテーブルHT1
WHERE インデックス用一致比較部（
インデックス用ハッシュテーブル検索クエリ、暗号化ハッシュ値）
) LIMIT 1; （１９−２）

SELECT MapID FROM ハッシュテーブルHT1
WHERE インデックス用一致比較部（
インデックス用ハッシュテーブル検索クエリ、暗号化ハッシュ値）） （２０−２）

UPDATE 暗号化メインテーブル X JOIN 更新対象ＩＤテーブルY
ON X.ID = Y.ID
SET X.病名 ＝
CASE ID
WHEN 3 THEN Enc(狭心症)
WHEN 1000000 THEN Enc(狭心症)
END （２１−２）

DELETE マッピングテーブルMT1 FROM MT1 JOIN
( SELECT MID FROM UpID JOIN
( SELECT MID, ID復号化部(@ID用鍵, 暗号化ID) AS TempID
FROM MT1
JOIN
( SELECT MapID,@ID用鍵:=ID用鍵取得部(
インデックス用ハッシュテーブル検索クエリ、暗号化ハッシュ値 )
FROM HT1
WHERE インデックス用一致比較部（
インデックス用ハッシューテーブル検索クエリ、暗号化ハッシュ値 ）
) HitHash
ON MT1.MapID=HitHash.MapID
) Temp
ON UpID.ID=Temp.TempID
) MapResult
ON MT1.MID = MapResult.MID; （２２−２）

INSERT INTO MT1 ( 暗号化ID, MapID )
SELECT ID用暗号化部（@ID用鍵、ID ） AS EncID, MapID
FROM UpID JOIN
( SELECT MapID, @ID用鍵:=ID用鍵取得部(
インデックス用ハッシュテーブル検索クエリ，暗号化ハッシュ値）
FROM ハッシュテーブルHT1
WHERE インデックス用一致検索部（
インデックス用ハッシュテーブル検索クエリ，暗号化ハッシュ値）
) temp ; （２３−２）

最後に、データベースラッパー部２１２は、ステップ２９３５又はステップ２９６５で出力された暗号文の更新ＳＱＬを、データベースインタフェース部２１３へ送信する。平文の更新ＳＱＬが（１３）である場合、ステップ２９１５の結果が存在するため、データベースラッパー部２１２はステップが出力した暗号化されたＳＱＬ文（１９−２）、（２０−２）、（２１−２）、（２２−２）及び（２３−２）をデータベースインタフェース部２１３へ送信する（ステップ２９７０）。以上で、データベースラッパー部２１２は、秘匿インデックス更新クエリ生成処理（図３０）を終了する。

図１４は、クラウドシステム側サーバ４において、データベース制御部３１１が実行する更新対象ＩＤリスト取得処理の流れを示しており、第二の実施例でも、データベース制御部３１１は図１４と同様の処理を行う。更新対象ＩＤリスト取得処理は、データベース制御部３１１がデータベースインタフェース部２１３から暗号文の検索ＳＱＬを受信すると、開始する。まず、更新対象カラムの値が暗号化検索クエリと一致するレコードのＩＤを、暗号化メインテーブル３６１Ｂからすべて取得する（ステップ１４１０）。最後に、取得結果をデータベースインタフェース部２１３へ送信し（ステップ１４２０）、図１４の処理を終了する。例えば、暗号文の検索ＳＱＬが（１８−２）である場合、更新対象ＩＤリストの要素は”３”及び”１００００００”となる。

図３１は、第二の実施例のクラウドシステム側サーバ４において、データベース制御部３１１が実行する秘匿インデックス用更新対象ＩＤテーブル取得処理を示すフローチャートである。秘匿インデックス用更新対象ＩＤテーブル取得処理は、データベース制御部３１１がデータベースインタフェース部２１３から暗号文の検索ＳＱＬを受信すると、開始する。

まず、データベース制御部３１１は、ハッシュテーブル３６２Ｂから、インデックス用ハッシュテーブル検索クエリに一致するレコードのＭａｐＩＤを取得する（ステップ３０１０）。次に、データベース制御部３１１は、マッピングテーブル３６３から、ステップ３０１０で取得したＭａｐＩＤと一致するＭａｐＩＤを持つレコード群ＨａｓｈＲｅｓｕｌｔを取得する（ステップ３０２０）。次に、データベース制御部３１１は、ステップ３０１０で一致したハッシュテーブル３６２Ｂのレコードの暗号化ハッシュ値と、インデックス用アッシュテーブル検索クエリをＩＤ用鍵取得部３１２３に入力し、出力としてＩＤ用鍵を取得し、取得したＩＤ用鍵及びＨａｓｈＲｅｓｕｌｔの暗号化ＩＤをＩＤ復号化部３１２４に入力し、出力として得たＩＤ群をＩＤＲｅｓｕｌｔとする（３０３０）。

次に、データベース制御部３１１は、暗号化メインテーブル３６１Ｂから、ステップ３０３０で取得したＩＤＲｅｓｕｌｔが含むＩＤ群に含まれるＩＤを持ち、かつ更新元カラムである”病名”カラムの値が暗号化検索クエリと一致するレコードのＩＤをすべて取得し、更新対象ＩＤテーブルとして格納する（ステップ３０４０）。最後に、データベース制御部３１１は、取得結果をデータベースインタフェース部２１３へ送信し（３０５０）、秘匿インデックス用更新対象ＩＤテーブル取得処理（図３１）を終了する。例えば、暗号文の検索ＳＱＬが（１８−２）である場合、更新対象ＩＤテーブルはＩＤカラムの値として”３”及び”１００００００”を格納したテーブルとなる。

図３２は、第二の実施例のクラウドシステム側サーバ４において、データベース制御部３１１が実行する秘匿インデックス更新処理を示すフローチャートである。秘匿インデックス更新処理は、データベース制御部３１１がデータベースインタフェース部２１３から暗号文の更新ＳＱＬを受信すると、開始する。例えば、秘匿インデックス更新処理の開始時にデータベース制御部３１１が受信する暗号文の更新ＳＱＬは、ＳＱＬ（１９−２）、（２０−２）、（２１−２）、（２２−２）及び（２３−２）である。

まず、データベース制御部３１１は、暗号文の更新ＳＱＬの第一のＳＱＬである（１９−２）から、更新対象となるハッシュテーブル３６２Ｂ及びインデックス用ハッシュテーブル検索クエリを取得し、ユーザ定義機能部３１２のインデックス用一致比較部３１２２により当該ハッシュテーブルの”暗号化ハッシュ値”カラムの値と当該インデックス用ハッシュテーブル検索クエリが一致するレコードを検索する（ステップ３１１０）。

ステップ３１１０の結果が存在する場合（ＹＥＳ）、データベース制御部３１１は、一致したレコードからＭａｐＩＤを取得し、取得したＭａｐＩＤをＭａｐＩＤ＿Ｎｅｗとする（ステップ３１２０）。

一方、ステップ３１１０の結果が存在しない場合、データベース制御部３１１は、新しいＭａｐＩＤを生成して、生成したＭａｐＩＤをＭａｐＩＤ＿ｎｅｗとし、暗号化ハッシュ値”ＩＮＥｎｃ（ＩＤ＿ｋｅｙ＿４，０５００）”と共にハッシュテーブル３６２Ｂへ挿入する（ステップ３１３０）。

次に、データベース制御部３１１は、暗号化メインテーブル３６１Ｂのうち、更新対象ＩＤを持つレコードについて、当該レコードの更新対象カラムの値を更新し、さらに、当該レコードのＩＤと一致する暗号化ＩＤを持つマッピングテーブル３６３のレコードの”ＭａｐＩＤ”カラムの値をＭａｐＩＤ＿Ｎｅｗとする（ステップ３１４０）。

次に、データベース制御部３１１は、ハッシュテーブル３６２Ｂから、マッピングテーブル３６３の”ＭａｐＩＤ”カラムに存在しないＭａｐＩＤを持つレコードを削除する（ステップ３１５０）。

最後に、データベース制御部３１１は、更新結果をデータベースインタフェース部２１３へ送信する（３１６０）。以上で、秘匿インデックス更新処理（図３２）を終了する。

（２−５）秘匿化データベースの削除に関する処理の流れ
図３３及び図３４を用いて、第二の実施例の秘匿化データベースシステム１において、ハッシュテーブル３６２Ｂ及びマッピングテーブル３６３を用いた削除である秘匿インデックス削除を行う際の、データベースラッパー部２１２及びデータベース制御部３１１が行う一連の処理の流れを示す。

図３３は、第二の実施例のユーザシステム側サーバ３において、データベースラッパー部２１２が実行する秘匿インデックス削除クエリ生成処理を示すフローチャートである。秘匿インデックス削除クエリ生成処理は、データベースラッパー部２１２がアプリケーション部２１１から平文の削除のＳＱＬを受信すると、開始する。例えば、秘匿インデックス削除クエリ生成処理の開始時にデータベースラッパー部２１２が受信する平文の削除のＳＱＬは、以下のＳＱＬ（２２）である。この削除ＳＱＬ（２２）は、スキーマ名が”医療情報”であり、テーブル名が”患者情報”であるテーブルから、”病名”カラムの値が”糖尿病”であるレコードをすべて削除することを意味する（ステップ３２１０）。

DELETE FROM 医療情報.患者情報 WHERE 病名=糖尿病 （２２）

次に、データベースラッパー部２１２は、平文の削除ＳＱＬから、削除条件の対象カラムの値を取り出し、鍵管理部２１２５から暗号化鍵及び検索用鍵を取得し、それらを検索クエリ生成部２１２２に入力し、その出力として暗号化検索クエリを得る。例えば、平文のＳＱＬが（２１）である場合、暗号化検索クエリは以下の実行式（２）である（ステップ３２２０）。

暗号化検索クエリ（糖尿病） ＝ 検索クエリ生成部（暗号化鍵、検索用鍵、"糖尿病"） （２）

次に、データベースラッパー部２１２は、秘匿インデックスマップテーブル２６２Ｂから、検索対象カラムの”マッピングテーブル名”及び”ハッシュテーブル名”を取得する。具体的には、データベースラッパー部２１２は、平文の削除ＳＱＬが削除条件の対象とするスキーマ名、暗号化メインテーブル名及びカラム名の組をキーとして、秘匿インデックスマップテーブル２６２Ｂを検索し、スキーマ名、暗号化メインテーブル名及びカラム名が一致するレコードの”マッピングテーブル名”及び”ハッシュテーブル名”を取得する。例えば、平文の検索ＳＱＬが（２２）である場合、スキーマ名が”医療情報”であり、かつ暗号化メインテーブル名が”患者情報”であり、かつカラム名が”病名”であるレコード２６２１から、マッピングテーブル名”ＭＴ１”及びハッシュテーブル名”ＨＴ１”を取得する（ステップ３２３０）。

次に、データベースラッパー部２１２は、ステップ３２３０の結果が存在するか否かを判定する（ステップ３２４０）。

ステップ３２４０の結果が存在しない場合（ＮＯ）、データベースラッパー部２１２は、ハッシュテーブル３６２Ｂを用いない削除ＳＱＬ変換の処理を行う。具体的には、データベースラッパー部２１２は、平文のＳＱＬの削除条件の対象カラムの値を、ステップ３２２０で生成した暗号化検索クエリに置き換え、さらに、ＷＨＥＲＥ句の一致比較文を、ユーザ定義機能部３１２の暗号文一致比較部３１２１を呼び出す形式に置き換えた、暗号文の削除ＳＱＬを出力する。例えば、平文のＳＱＬが（２２）であり、暗号化検索クエリが（２）である場合、暗号文の削除ＳＱＬは以下の暗号文のＳＱＬ（２３）である（ステップ３２５０）。

DELETE FROM 医療情報.患者情報
WHERE 暗号文一致比較部（病名、暗号化検索クエリ（糖尿病）） （２３）

一方、ステップ３２３０の結果が存在する場合（ＹＥＳ）、データベースラッパー部２１２は、ハッシュテーブル３６２Ｂを用いた削除を行うために、ハッシュ値生成から秘匿インデックス用削除ＳＱＬ変換（ステップ３２６０〜３２８０）の処理を行った暗号文の削除ＳＱＬを出力する。

まず、データベースラッパー部２１２は、削除条件の対象カラムの値をハッシュ値生成部２１２３に入力し、出力されるハッシュ値を取得する。例えば、平文の削除ＳＱＬが（２２）である場合、ハッシュ値（４）を取得する（ステップ３２６０）。

ハッシュ値 ＝ ハッシュ値生成部（糖尿病）＝"1012" （４）

次に、データベースラッパー部２１２は、ハッシュテーブル３６２Ｂを検索するために、ステップ３２６０で取得したハッシュ値をインデックス用検索クエリ生成部２１２８に入力し、出力をインデックス用ハッシュテーブル検索クエリとする。例えば、平文のハッシュ値が（４）である場合、以下のインデックス用ハッシュテーブル検索クエリ（５−２）を取得する（ステップ３７７０）。

インデックス用ハッシュテーブル検索クエリ（1012）＝インデックス用検索クエリ生成部（暗号鍵、検索用鍵、"1012"） （５−２）

次に、データベースラッパー部２１２は、秘匿インデックス用ＳＱＬ変換部２１２７により、まずハッシュテーブル３６２Ｂを検索して検索範囲を限定した上で、暗号化メインテーブル３６１Ｂからの削除を実行するためのＳＱＬを生成する秘匿インデックス用検索ＳＱＬ変換を行う。具体的には、ステップ３２２０で得た暗号化検索クエリと、ステップ３２３０で得たマッピングテーブル名及びハッシュテーブル名と、ステップ３７７０で得たインデックス用ハッシュテーブル検索クエリを入力とし、ハッシュテーブル３６２Ｂをインデックス用ハッシュテーブル検索クエリで検索して該当したレコードの”ＭａｐＩＤ”カラムの値を取得し、その値と等しい”ＭａｐＩＤ”カラムの値を持つマッピングテーブル３６３のレコードについて、暗号化ＩＤを復号化してＩＤを取得し、そのＩＤを持つ暗号化メインテーブル３６１Ｂのレコードから、暗号化検索クエリと一致する値を持つレコードをユーザ定義機能部３１２の暗号文一致比較部３１２１を用いて判定し、一致したレコードを暗号化メインテーブル３６１Ｂから削除するＳＱＬを生成する。さらに、ハッシュテーブル３６２Ｂから、マッピングテーブル３６３のマップＩＤカラム”ＭａｐＩＤ”に存在しないＭａｐＩＤを含むレコードを削除するＳＱＬを生成する。例えば、平文の削除ＳＱＬが（２２）である場合、三つのＳＱＬ文からなる暗号文の削除ＳＱＬ（２４−２）（２５−２）及び（２６−２）を出力する（ステップ３２８０）。

CREATE TABLE UpID ( ID INT, INDEX(ID )
SELECT ID FROM 暗号化メインテーブル X JOIN
( SELECT ID用復号化部(@ID用鍵、暗号化ID) AS TempID FROM MT1 JOIN
( SELECT MapID, @ID用鍵:=ID用鍵取得部（
インデックス用ハッシュテーブル検索クエリ、暗号化ハッシュ値）
FROM HT1 WHERE インデックス用一致比較部（
インデックス用ハッシュテーブル検索クエリ、暗号化ハッシュ値）
) HitHash
ON MT1.MapID = HitHash.MapID
) MapResult
ON X.ID = MapResult.TempID
WHERE 暗号化一致比較部（暗号化検索クエリ、病名）; （２４−２）

DELETE 暗号化メインテーブルX FROM 暗号化メインテーブル
JOIN UpID ON X.ID = UpID.ID ; （２５−２）

DELETE MT1 FROM MT1 JOIN
( SELECT MID FROM UpID JOIN
( SELECT MID, ID用復号化部（@ID用鍵、暗号化ID） AS TempID
FROM MT1 JOIN
( SELECT MapID, @ID用鍵:=ID用鍵取得部(
インデックス用ハッシュテーブル検索クエリ、暗号化ハッシュ値）
FROM HT1 WHERE インデックス用一致比較部（
インデックス用ハッシュテーブル検索クエリ、暗号化ハッシュ値）
) HitHash ON MT1.MapID = temp.TempID
) MapResult ON MT1.MID = MapResult.MID; （２６−２）

最後に、データベースラッパー部２１２は、ステップ３２５０又はステップ３２８０で出力された暗号文の削除ＳＱＬを、データベースインタフェース部２１３へ送信する。平文の削除ＳＱＬが（２２）である場合、ステップ３２４０の結果が存在するため、データベースラッパー部２１２はステップ３２８０が出力した暗号文の検索ＳＱＬ（２４−２）、（２５−２）及び（２６−２）をデータベースインタフェース部２１３へ送信する（ステップ３２９０）。以上で、データベースラッパー部２１２は、秘匿インデックス削除クエリ生成処理（図３２）を終了する。

図３４は、第二の実施例のクラウドシステム側サーバ４において、データベース制御部３１１が実行する秘匿インデックス削除処理を示すフローチャートである。秘匿インデックス削除処理は、データベース制御部３１１がデータベースインタフェース部２１３から暗号文の削除ＳＱＬを受信すると、開始する。例えば、秘匿インデックス削除処理の開始時にデータベース制御部３１１が受信する暗号文の削除ＳＱＬは、ＳＱＬ（２４−２）（２５−２）及び（２６−２）である。

まず、データベース制御部３１１は、暗号文の削除ＳＱＬから、削除条件の対象となるハッシュテーブル３６２Ｂとインデックス用ハッシュテーブル検索クエリを特定し、ユーザ定義機能部３１２のインデックス用一致比較部３１２２により当該ハッシュテーブル３６２Ｂの”暗号化ハッシュ値”カラムの値と当該インデックス用ハッシュテーブル検索クエリが一致するレコードを特定し、そのレコードの”ＭａｐＩＤ”カラムの値をＭａｐＩＤ＿ｈｉｔとして取得する。例えば、暗号文の削除ＳＱＬが（２４−２）（２５−２）及び（２６−２）である場合、ハッシュテーブル３６２Ｂはハッシュテーブル３６２Ｂであり、インデックス用一致比較部３１２２による一致比較の結果、ハッシュテーブル３６２Ｂのレコード３６２２Ｂの暗号化ハッシュ値”ＩＮＥｎｃ（ＩＤ＿ｋｅｙ＿２，１０１２）”と一致し、当該レコードのＭａｐＩＤ”２”をＭａｐＩＤ＿ｈｉｔとして取得する（ステップ３３１０）。

次に、データベース制御部３１１は、マッピングテーブル３６３から、”ＭａｐＩＤ”カラムの値がＭａｐＩＤ＿ｈｉｔと一致するレコード群ＨａｓｈＲｅｓｕｌｔを特定する。例えば、暗号文の削除ＳＱＬが（２４−２）（２５−２）及び（２６−２）である場合、ＭａｐＩＤ＿ｈｉｔが”２”であるレコード３６３２及び３６３３がＨａｓｈＲｅｓｕｌｔとなる（ステップ３３２０）。

次に、データベース制御部３１１は、インデックス用ハッシュテーブル検索クエリとステップ３３１０でヒットしたレコードの暗号化ハッシュ値をＩＤ用鍵取得部３１２３に入力し、出力としてＩＤ用鍵を取得し、そのＩＤ用鍵とＨａｓｈＲｅｓｕｌｔの暗号化ＩＤをＩＤ復号化部３１２４に入力し、出力として取得したＩＤ群をＩＤＲｅｓｕｌｔとする。ここで、暗号文の削除ＳＱＬが（２４−２）（２５−２）及び（２６−２）である場合の例としては、ＩＤＲｅｓｕｌｔは”３、１００００００”となる（ステップ３３３０）。

次に、データベース制御部３１１は、暗号化メインテーブル３６１Ｂから、ＩＤＲｅｓｕｌｔが含むＩＤを持ちかつ暗号化検索クエリと一致する値を持つレコードを削除し、さらに当該レコードと一致する暗号化ＩＤを持つマッピングテーブル３６３のレコードを削除する（ステップ３３４０）。

次に、データベース制御部３１１は、ハッシュテーブル３６２Ｂから、マッピングテーブル３６３に存在しないＭａｐＩＤを含むレコードを削除する（ステップ３３５０）。

最後に、データベース制御部３１１は、暗号文の削除ＳＱＬの結果をデータベースインタフェース部２１３へ送信する（ステップ３３６０）。以上で、秘匿インデックス削除処理（図３４）を終了する。

（２−６）マッピングテーブルの並べ替えに関する処理の流れ
図３５は、第二の実施例のマッピングテーブルの並べ替えクエリ生成処理を示すフローチャートである。データベースラッパー部２１２は、マッピングテーブル３６３のレコードの順序が、と暗号化メインテーブル３６１Ｂの対応するレコードのＩＤの順序と一致しないように、マッピングテーブル３６３の生成時又は任意のタイミングで、マッピングテーブル３６３のレコードの順序をランダムに並べ替える並べ替えＳＱＬを生成し（ステップ３４１０）、データベース制御部３１１へ送信する（ステップ３４２０）。

図３６は、第二の実施例のマッピングテーブルの並べ替え処理を示すフローチャートである。データベース制御部３１１は、データベースラッパー部２１２から並べ替えＳＱＬを受信すると、マッピングテーブル３６３のレコードをランダムに並べ替え（ステップ３５１０）、その結果をデータベースラッパー部２１２へ送信する（ステップ３５２０）。

（２−７）第二の実施例の効果
以上に説明したように、第二の実施例の秘匿化データベースシステム１では、暗号化メインテーブル３６１Ｂから検索を高速化するハッシュテーブル３６２Ｂとの対応関係を示すＭａｐＩＤカラムを取り除き、対応関係を暗号化したままマッピングテーブル３６３に保持することによって、暗号化メインテーブル３６１ＢのレコードとＭａｐＩＤの対応関係を隠蔽するため、第一の実施例より安全な検索を行うことができる。

（３）第三の実施例
（３−１）第三の実施例による情報処理システムの構成
本発明の第三の実施例による秘匿化データベースシステム１のハードウェア及びソフトウェア構成は、第二の実施例（図１９）で前述した構成と同じである。第三の実施例が、第二の実施例と異なる点は、マッピングテーブル３６３ＢのマップＩＤの頻度の偏りを平準化し、出現頻度を隠蔽することである。

図３７は、第三の実施例のデータベースラッパー部２１２の論理構成を示す。第三の実施例のデータベースラッパー部２１２が第二の実施例（図２０）と異なる点は、マッピングテーブル３６３ＢのマップＩＤの出現頻度を平準化するマップＩＤ頻度分布平準化クエリ生成部２１２０１を有することである。

図３８は、第三の実施例の頻度分布平準化前のマッピングテーブル３６３Ｂのデータ構造を示す。第三の実施例のマッピングテーブル３６３Ｂが、第二の実施例（図２４）のマッピングテーブル３６３と異なる点は、ＭａｐＩＤの頻度の偏りを示すためにサンプルレコードを追加していることである。例えば、第三の実施例のマッピングテーブル３６３Ｂでは、ＭａｐＩＤ”１”の頻度が２であり、ＭａｐＩＤ”２”の頻度が３でありＭａｐＩＤ”３”及び”１０”の頻度が１である。それ以外は、第二の実施例と同じである。

図３９は、第三の実施例の頻度分布平準化後のマッピングテーブル３６３Ｃのデータ構造を示す。平準化後のマッピングテーブル３６３Ｃが、平準化前のマッピングテーブル３６３Ｂと異なる点は、ＭａｐＩＤの頻度を平準化するための模擬レコードを備えることである。模擬レコードは、暗号化ＩＤの代わりに、暗号化ＩＤと同じ型のビット列を乱数で生成した値を持つ。例えば、図３９では、模擬レコード３６３１Ｃ〜３６３５Ｃを加えた結果、全てのＭａｐＩＤの頻度が３となっている。

図３７、図３８及び図３９以外の第三の実施例による情報処理システムの構成は、２−１項で説明した第二の実施例と同じである。

（３−２）秘匿化データベースの検索に関する処理の流れ
第三の実施例の秘匿化データベースの検索に関する処理は、２−２項で説明した第二の実施例と同じである。

（３−３）秘匿化データベースへの挿入に関する処理の流れ
第三の実施例の秘匿化データベースへの挿入に関する処理は、２−３項で説明した第二の実施例と同様である。

（３−４）秘匿化データベースの更新に関する処理の流れ
第三の実施例の秘匿化データベースの更新に関する処理は、２−４項で説明した第二の実施例と同じである。

（３−５）秘匿化データベースの削除に関する処理の流れ
第三の実施例の秘匿化データベースの削除に関する処理は、２−５項で説明した第二の実施例と同じである。

（３−６）マッピングテーブルの並べ替えに関する処理の流れ
第三の実施例のマッピングテーブル３６３Ｂの並べ替えに関する処理は、２−６項で説明した第二の実施例と同じである。

（３−７）マッピングテーブルの頻度分布の平準化に関する処理の流れ
図４０及び図４１を用いて、第三の実施例の秘匿化データベースシステム１において、マッピングテーブル３６３Ｂの平準化を行う際の処理を説明する。

図４０は、第三の実施例のユーザシステム側サーバ３において、データベースラッパー部２１２が実行するマップＩＤ頻度分布平準化クエリ生成処理を示すフローチャートである。マップＩＤ頻度分布平準化クエリ生成処理は、データベースラッパー部２１２がアプリケーション部２１１等からの平準化要求を受けると、開始する。

まず、データベースラッパー部２１２は、平準化前のマッピングテーブル３６３Ｂから”ＭａｐＩＤ”カラムの各値毎の頻度を取得する。例えば、図３８に示す平準化前のマッピングテーブル３６３Ｂの場合、ＭａｐＩＤ”１”の頻度が２であり、ＭａｐＩＤ”２”の頻度が３でありＭａｐＩＤ”３”及び”１０”の頻度が１である。

次に、データベースラッパー部２１２は、ＭａｐＩＤの各値の頻度が同一かを判定し、同一の場合（ＹＥＳ）、処理を終了する。

一方、ステップ３９２０の結果が（ＮＯ）である場合、データベースラッパー部２１２は、ステップ３９１０で取得した頻度のうち最大頻度をＮｍａｘとする。例えば、平準化前のマッピングテーブル３６３Ｂの場合、ＮｍａｘはＭａｐＩＤ”２”の頻度である３となる（ステップ３９３０）。

次に、データベースラッパー部２１２は、最大頻度以外のＭａｐＩＤの各値について、Ｎｍａｘと各値の頻度との差分の数だけ乱数を生成し、その乱数の各値のペアから構成されるレコードをマッピングテーブル３６３Ｂに挿入する頻度分布平準化ＳＱＬを生成する。例えば、平準化前のマッピングテーブル３６３Ｂの場合、図３９に示す模擬レコード３６３１Ｃ〜３６３５Ｃを挿入するＳＱＬを生成する（ステップ３９４０）。

最後に、データベースラッパー部２１２は、ステップ３９４０で生成した頻度分布平準化ＳＱＬをデータベースインタフェース部２１３へ送信し、マップＩＤ頻度分布平準化クエリ生成処理（図４０）を終了する。

図４１は、第三の実施例のクラウドシステム側サーバ４において、データベース制御部３１１が実行するマップＩＤ頻度分布平準化処理を示すフローチャートである。この処理は、データベース制御部３１１が、データベースラッパー部２１２からの頻度分布平準化ＳＱＬを受信すると、ＳＱＬに指定されたレコードをマッピングテーブル３６３Ｂに挿入する（ステップ４０１０）。そして、挿入結果をデータベースラッパーへ送信する（ステップ４０２０）。

（３−８）第三の実施例の効果
以上のように、第三の実施例の秘匿化データベースシステム１では、マッピングテーブル３６３のＭａｐＩＤの出現頻度の分布を平準化することにより、ＭａｐＩＤの出現頻度を隠蔽するため、第二の実施例より安全な検索を行うことができる。

以上に説明したように、本発明の実施例によると、データベースラッパー部２１２は、暗号化データを検索するための平文のＳＱＬ文を受信すると、前記暗号化データをクラウドシステム側サーバ４上で処理する暗号化ＳＱＬ文に変換し、クラウドシステム側サーバ４が前記暗号化ＳＱＬ文を受信すると、受信した暗号化ＳＱＬ文を実行することによって、データベース制御部３１１が前記ハッシュテーブルを検索して前記暗号化データの範囲を限定し、ユーザ定義機能部３１２（暗号文一致比較部３１２１）が前記限定された範囲の暗号化データについて前記暗号化ＳＱＬ文が指示する一致比較を行い、データベース制御部３１１が前記暗号化ＳＱＬ文の実行結果をユーザシステム側サーバ３へ送信するので、暗号化された大容量の暗号化メインテーブル３６１への検索に際して、ハッシュテーブル３６２を事前に検索することで検索対象とするレコードを少なくして、高速に検索することができる。

また、ユーザシステム側サーバ３は、前記暗号化データを処理するＳＱＬ文を、データ所有者が使用するユーザ端末２から、ユーザシステム側サーバ３が設けられた設備のユーザ内部ネットワーク５を経由して受信し、ユーザシステム側サーバ３は、前記暗号化データを処理するＳＱＬ文を、外部ネットワーク６を介してクラウドシステム側サーバ４に送信するので、クラウド構成の秘匿化データベースシステムにおいて、大容量の暗号化データを高速に検索することができる。

また、ハッシュテーブル３６２は、暗号化メインテーブル３６１の各レコードの識別子であるマップＩＤ及び前記ハッシュ値を含み、暗号化メインテーブル３６１は、ハッシュテーブル３６２に格納されたハッシュ値に対応する識別子であるマップＩＤを含み、データベース制御部３１１は、前記ハッシュ値をキーワードとしてハッシュテーブル３６２を検索し、一致したハッシュ値を持つレコードのマップＩＤを取得し、前記取得したマップＩＤを持つ暗号化メインテーブル３６１のレコードを検索対象とするので、ハッシュテーブル３６２に記録されたマップＩＤを用いて検索対象を絞り込むことができる。

また、データベース制御部３１１は、暗号化メインテーブル３６１のマップＩＤと前記ハッシュテーブルのマップＩＤとを対応付け、暗号化メインテーブル３６１に存在しないがハッシュテーブル３６２に存在するマップＩＤを含むレコードをハッシュテーブル３６２から削除するので、不要なデータを削除して、検索を高速化し、使用リソースを削減することができる。

また、データベースラッパー部２１２は、検索するデータのハッシュ値とハッシュテーブル３６２に格納された暗号化ハッシュ値との一致検索を行うハッシュテーブル検索クエリを生成し、データベース制御部３１１は、前記生成されたハッシュテーブル検索クエリと前記暗号化ハッシュ値との一致判定を暗号文一致比較部３１２１に行わせるので、ハッシュテーブル３６２の肥大化を防止することができる。

また、ユーザシステム側サーバ３は、元データに対応する暗号化ハッシュ値を格納するハッシュテーブルとの関係を示す情報を格納する秘匿インデックスマップテーブル２６２を有し、データベースラッパー部２１２は、秘匿インデックスマップテーブル２６２を検索した結果、検索対象のデータに対応する暗号化ハッシュ値を格納するハッシュテーブル３６２が存在しない場合、ハッシュテーブル３６２を検索するＳＱＬ文を生成せず、暗号化メインテーブル３６１を検索するＳＱＬ文を生成するので、ハッシュ値によるインデックスを使用できない場合でも、高速に検索することができる。

また、データベースラッパー部２１２は、確率的暗号化を行った暗号化データで暗号化メインテーブル３６１を更新する場合、暗号化メインテーブル３６１の更新対象レコードの識別子を全て取得し、前記取得した識別子の個数分の更新後のデータの暗号文を生成し、当該識別子の個数分の複数のレコードを更新するＳＱＬ文を生成するので、暗号の強度を低下させずに、高速に検索することができる。

また、データベースラッパー部２１２は、ＳＱＬ文の最大長の制限により前記識別子の個数分の複数のレコードの更新を一文で記述できない場合、ＳＱＬ文の最大長の制限を超えない長さの複数のＳＱＬ文を生成するので、複数の書込処理を並列して実行して、処理を高速化することができる。

また、暗号化メインテーブル３６１Ｂは、ハッシュテーブル３６２Ｂに格納された暗号化ハッシュ値に対応する識別子マップＩＤを含まず、クラウドシステム側サーバ４は、暗号化メインテーブル３６１Ｂの各レコードに対応する識別子を暗号化した暗号化ＩＤと、当該暗号化ＩＤに対応するハッシュテーブル３６２に格納されたハッシュ値に対応する識別子であるマップＩＤとを含むマッピングテーブル３６３を有し、データベースラッパー部２１２は、ハッシュテーブル３６２Ｂから取得したマップＩＤに対応するマッピングテーブルの暗号化ＩＤを取得し、前記取得した暗号化ＩＤを一時的に復号化し、前記暗号化ＩＤを復号化した識別子によって、前記暗号化データの検索範囲を限定するので、暗号化メインテーブル３６１ＢのレコードとマップＩＤとの対応関係を隠蔽して、より安全な検索を行うことができる。

また、データベースラッパー部２１２は、前記マッピングテーブルのレコードを並べ替えるためのクエリを生成するマッピングテーブル並べ替えクエリ生成部を有し、データベース制御部３１１は、マッピングテーブル並べ替えクエリ生成部が生成したＳＱＬ文に従って、前記マッピングテーブルのレコードを並び替えるので、暗号化メインテーブル３６１Ｂとマッピングテーブル３６３のレコード順序が同一にならないようにして、暗号化メインテーブル３６１Ｂとマッピングテーブル３６３の各レコードの対応関係を隠蔽し、より安全に検索することができる。

また、データベースラッパー部２１２は、前記マッピングテーブルのマップＩＤの頻度を取得し、前記取得した頻度を等しくするための擬似レコードを前記マッピングテーブルに挿入するためのクエリを生成するマップＩＤ頻度分布平準化クエリ生成部を有し、データベース制御部３１１は、マップＩＤ頻度分布平準化クエリ生成部が生成したＳＱＬ文に従って、前記マッピングテーブルへ前記擬似レコードを挿入するので、マッピングテーブル３６３のマップＩＤの出現頻度の分布を平準化して、マップＩＤの出現頻度を隠蔽して、より安全な検索を行うことができる。

なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。

また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Solid State Drive）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

本発明は、ユーザシステム側が鍵を持ち暗号化したデータをクラウド事業者に預託し、クラウド事業者が預託された多量の暗号化データを暗号化したまま検索し、分析する機能を顧客に提供する情報処理システムに広く適用することができる。

１…秘匿化データベースシステム、２…ユーザ端末、３…ユーザシステム側サーバ、４…クラウドシステム側サーバ、５…ユーザ内部ネットワーク、６…外部ネットワーク、７…クラウド内部ネットワーク、２１１…アプリケーション部、２１２…データベースラッパー部、２１３…データベースインタフェース部、２６２、２６２Ｂ…秘匿インデックスマップテーブル、３１１…データベース制御部、３１２…ユーザ定義機能部、３６１、３６１Ｂ…暗号化メインテーブル、３６２、３６２Ｂ…ハッシュテーブル、３６３…マッピングテーブル

Claims (15)

1. ユーザシステムが所有する元データをデータ所有者が管理する暗号鍵によって暗号化した暗号化データが預託されるセンタシステムによって構成される秘匿化データベースシステムであって、
   前記センタシステムは、前記預託された暗号化データを元データに復号化することなく検索する機能を提供するものであって、
   前記ユーザシステムは、前記暗号化データを処理するための平文のＳＱＬ文を、前記暗号化データを前記センタシステム上で処理する暗号化ＳＱＬ文に変換し、前記センタシステムから受信した暗号化データの処理結果を復号化するデータベースラッパー部を有し、
   前記センタシステムは、
   前記暗号化データを格納する暗号化預託データテーブルと、
   前記元データのハッシュ値を暗号化した暗号化ハッシュ値を格納し、前記暗号化預託データテーブルの検索範囲を限定するために参照されるハッシュテーブルと、
   前記暗号化預託データテーブルに格納された暗号化データを検索するデータベース制御部と、
   前記暗号化データと検索クエリとの一致を判定する暗号文一致比較部と、を有し、
   前記データベースラッパー部は、前記暗号化データを検索するための平文のＳＱＬ文を、前記暗号化データを前記センタシステム上で処理する暗号化ＳＱＬ文に変換し、
   前記センタシステムが受信した前記暗号化ＳＱＬ文を実行することによって、前記データベース制御部が前記ハッシュテーブルを検索して前記暗号化データの範囲を限定し、前記暗号文一致比較部が前記限定された範囲の暗号化データについて前記暗号化ＳＱＬ文が指示する一致比較を行い、前記データベース制御部が前記暗号化ＳＱＬ文の実行結果を前記ユーザシステムへ送信し、
   前記データベースラッパー部は、前記データベース制御部から受信したＳＱＬ文の実行結果を復号化し、前記暗号化データの検索結果を出力することを特徴とする秘匿化データベースシステム。
2. 請求項１に記載の秘匿化データベースシステムであって、
   前記ユーザシステムは、前記暗号化データを処理するための平文のＳＱＬ文を、前記データ所有者が使用するユーザ端末から、前記ユーザシステムが設けられた設備の内部ネットワークを経由して受信し、
   前記ユーザシステムは、前記暗号化データを処理する暗号化ＳＱＬ文を、外部ネットワークを介して前記センタシステムに送信することを特徴とする秘匿化データベースシステム。
3. 請求項１に記載の秘匿化データベースシステムであって、
   前記ユーザシステムは、
   前記データ所有者が使用するユーザ端末からの要求を受け、前記要求に対する処理の結果を返信するアプリケーション部と、
   前記データベースラッパー部から暗号化ＳＱＬ文を受信して前記センタシステムの前記データベース制御部へ送信し、また、前記データベース制御部から前記暗号化ＳＱＬ文の実行結果を受信して前記データベースラッパー部へ送信するデータベースインタフェース部と、を有し、
   前記データベースラッパー部は、
   前記元データを暗号化する暗号化部と、
   前記センタシステムから受信した暗号化データを元データに復号化する復号化部と、
   前記暗号化データを検索するための検索クエリを生成する検索クエリ生成部と、
   前記元データのハッシュ値を生成するハッシュ値生成部と、
   暗号化処理を実行するための暗号鍵及び検索用鍵を管理する鍵管理部と、
   前記暗号化データを検索するための平文のＳＱＬ文を、前記暗号化データを検索して結果を得るための暗号化ＳＱＬ文に変換するＳＱＬ変換部と、を有することを特徴とする秘匿化データベースシステム。
4. 請求項１に記載の秘匿化データベースシステムであって、
   前記ハッシュテーブルは、前記暗号化預託データテーブルの各レコードの識別子であるマップＩＤ及び前記暗号化ハッシュ値を含み、
   前記暗号化預託データテーブルは、前記ハッシュテーブルに格納された暗号化ハッシュ値に対応する識別子であるマップＩＤを含み、
   前記データベース制御部は、暗号化ハッシュ値をキーワードとして前記ハッシュテーブルを検索し、一致した暗号化ハッシュ値を持つレコードのマップＩＤを取得し、前記取得したマップＩＤを持つ前記暗号化預託データテーブルのレコードを検索対象とすることを特徴とする秘匿化データベースシステム。
5. 請求項４に記載の秘匿化データベースシステムであって、
   前記データベース制御部は、
   前記暗号化預託データテーブルのマップＩＤと前記ハッシュテーブルのマップＩＤとを対応付け、
   前記暗号化預託データテーブルに存在しないが前記ハッシュテーブルに存在するマップＩＤを含むレコードを前記ハッシュテーブルから削除することを特徴とする秘匿化データベースシステム。
6. 請求項１に記載の秘匿化データベースシステムであって、
   前記データベースラッパー部は、検索するデータの暗号化ハッシュ値と前記ハッシュテーブルに格納された暗号化ハッシュ値との一致検索を行うハッシュテーブル検索クエリを生成し、
   前記データベース制御部は、前記生成されたハッシュテーブル検索クエリと前記暗号化ハッシュ値との一致判定を前記暗号文一致比較部に行わせることを特徴とする秘匿化データベースシステム。
7. 請求項１に記載の秘匿化データベースシステムであって、
   前記ユーザシステムは、前記元データに対応する暗号化ハッシュ値を格納するハッシュテーブルと、前記暗号化データの格納場所との関係を示す情報を格納する秘匿インデックスマップテーブルを有し、
   前記データベースラッパー部は、前記秘匿インデックスマップテーブルを検索した結果、検索対象のデータに対応する暗号化ハッシュ値を格納するハッシュテーブルが存在しない場合、前記ハッシュテーブルを検索するＳＱＬ文を生成せず、前記暗号化預託データテーブルを検索するＳＱＬ文を生成することを特徴とする秘匿化データベースシステム。
8. 請求項１に記載の秘匿化データベースシステムであって、
   前記データベースラッパー部は、確率的暗号化を行った暗号化データで前記暗号化預託データテーブルを更新する場合、前記暗号化預託データテーブルの更新対象レコードの識別子を全て取得し、前記取得した識別子の個数分の更新後の暗号化データを生成し、当該識別子の個数分の複数のレコードを更新するＳＱＬ文を生成することを特徴とする秘匿化データベースシステム。
9. 請求項８に記載の秘匿化データベースシステムであって、
   前記データベースラッパー部は、ＳＱＬ文の最大長の制限により前記識別子の個数分の複数のレコードの更新を一文で記述できない場合、ＳＱＬ文の最大長の制限を超えない長さの複数のＳＱＬ文を生成することを特徴とする秘匿化データベースシステム。
10. 請求項１に記載の秘匿化データベースシステムであって、
    前記暗号化預託データテーブルは、前記ハッシュテーブルに格納された暗号化ハッシュ値に対応する識別子マップＩＤを含まず、
    前記センタシステムは、前記暗号化預託データテーブルの各レコードに対応する識別子を暗号化した暗号化ＩＤと、当該暗号化ＩＤに対応して前記ハッシュテーブルに格納されたハッシュ値に対応する識別子であるマップＩＤとを含むマッピングテーブルを有し、
    前記データベースラッパー部は、
    前記ハッシュテーブルから取得したマップＩＤに対応するマッピングテーブルの暗号化ＩＤを取得し、
    前記取得した暗号化ＩＤを一時的に復号化し、
    前記暗号化ＩＤを復号化した識別子によって、前記暗号化データの検索範囲を限定することを特徴とする秘匿化データベースシステム。
11. 請求項１０に記載の秘匿化データベースシステムであって、
    前記データベースラッパー部は、前記マッピングテーブルのレコードを並べ替えるためのクエリを生成するマッピングテーブル並べ替えクエリ生成部を有し、
    前記データベース制御部は、マッピングテーブル並べ替えクエリ生成部が生成したクエリに従って、前記マッピングテーブルのレコードを並び替えることを特徴とする秘匿化データベースシステム。
12. 請求項１０に記載の秘匿化データベースシステムであって、
    前記データベースラッパー部は、前記マッピングテーブルのマップＩＤの頻度を取得し、前記取得した頻度を等しくするための擬似レコードを前記マッピングテーブルに挿入するためのクエリを生成するマップＩＤ頻度分布平準化クエリ生成部を有し、
    前記データベース制御部は、マップＩＤ頻度分布平準化クエリ生成部が生成したクエリに従って、前記マッピングテーブルへ前記擬似レコードを挿入することを特徴とする秘匿化データベースシステム。
13. 秘匿化データベースシステムにおける秘匿化データ管理方法であって、
    前記秘匿化データベースシステムは、ユーザシステムが所有する元データをデータ所有者が管理する暗号鍵によって暗号化した暗号化データが預託されるセンタシステムによって構成され、
    前記センタシステムは、前記預託された暗号化データを元データに復号化することなく検索する機能を提供するものであって、
    前記ユーザシステムは、前記暗号化データを処理するための平文のＳＱＬ文を、前記暗号化データを前記センタシステム上で処理する暗号化ＳＱＬ文に変換し、前記センタシステムから受信した暗号化データの処理結果を復号化するデータベースラッパー部を有し、
    前記センタシステムは、
    前記暗号化データを格納する暗号化預託データテーブルと、
    前記元データのハッシュ値を暗号化した暗号化ハッシュ値を格納し、前記暗号化預託データテーブルの検索範囲を限定するために参照されるハッシュテーブルと、
    前記暗号化預託データテーブルに格納された暗号化データを検索するデータベース制御部と、
    前記暗号化データと検索クエリとの一致を判定する暗号文一致比較部と、を有し、
    前記方法は、
    前記データベースラッパー部が、前記暗号化データを検索するための平文のＳＱＬ文を、前記暗号化データを前記センタシステム上で処理する暗号化ＳＱＬ文に変換し、
    前記センタシステムが受信した前記暗号化ＳＱＬ文を実行することによって、前記データベース制御部が前記ハッシュテーブルを検索して前記暗号化データの範囲を限定し、前記暗号文一致比較部が前記限定された範囲の暗号化データについて前記暗号化ＳＱＬ文が指示する一致比較を行い、前記データベース制御部が前記暗号化ＳＱＬ文の実行結果を前記ユーザシステムへ送信し、
    前記データベースラッパー部が、前記データベース制御部から受信したＳＱＬ文の実行結果を復号化し、前記暗号化データの検索結果を出力することを特徴とする秘匿化データ管理方法。
14. 請求項１３に記載の秘匿化データ管理方法であって、
    前記ハッシュテーブルは、前記暗号化預託データテーブルの各レコードの識別子であるマップＩＤ及び前記ハッシュ値を含み、
    前記暗号化預託データテーブルは、前記ハッシュテーブルに格納された暗号化ハッシュ値に対応する識別子マップＩＤを含み、
    前記方法は、前記データベース制御部が、暗号化ハッシュ値をキーワードとして前記ハッシュテーブルを検索し、一致した暗号化ハッシュ値を持つレコードのマップＩＤを取得し、前記取得したマップＩＤを持つ前記暗号化預託データテーブルのレコードを検索対象とすることを特徴とする秘匿化データ管理方法。
15. 請求項１４に記載の秘匿化データ管理方法であって、
    前記データベース制御部が、前記暗号化預託データテーブルのマップＩＤと前記ハッシュテーブルのマップＩＤとを対応付け、
    前記データベース制御部が、前記暗号化預託データテーブルに存在しないが前記ハッシュテーブルに存在するマップＩＤを含むレコードを前記ハッシュテーブルから削除することを特徴とする秘匿化データ管理方法。

Images