JP2006189925A - 個人情報管理システム、個人情報管理プログラムおよび個人情報保護方法 - Google Patents

Abstract

【課題】 個人情報を機密保持に配慮して保管するとともに、保管された情報の活用を容易にすることを可能とする個人情報管理システム、プログラムおよび個人情報保護方法を提供する。
【解決手段】 個人情報データを秘密分散法によって暗号化し、復号用インデックスキーによって復号化する機能を提供する個人情報データ分散管理サーバ３との接続機能を有する個人情報を扱うための個人情報管理システムであって、前記復号用インデックスキーを格納した検策用キーワード管理データベース５と、個人情報管理装置１を備え、機密保護を必要とする個人情報データの保管要求があれば、該個人情報データを、前記個人情報データ分散管理サーバ３に分割保管させるとともに、前記復号用インデックスキーと対応付けて前記検索用キーワード管理データベース５に格納することを特徴とする。
【選択図】 図１

Description

個人情報を機密保持に配慮して保管するとともに、保管された情報の活用を容易にすることを可能とする個人情報管理システム、個人情報管理プログラムおよび個人情報保護方法に関する。

個人情報を機密保持に配慮しつつ保存するための方法は種々考案されている。例えば、特開２００４−１４５７５５公報に開示されている方法は、重要な秘密データを保管する場合、元データを単に暗号化するのではなく、秘密分散をして保管するとともに、各分散データを一括管理することなく、復元可能とするものである。
特開２００４−１４５７５５

しかし、従来の技術は、秘密情報・個人情報のデータの機密保護に主眼が置かれ、この保護されたデータの活用法及びその利便性には特に注意が払われていない。特開２００４−１４５７５５公報に開示の方法も、厳重に保護されたデータに、ユーザが、どのようにしてアクセスし、自己の業務に活用するかというユーザレベルの利用法については言及がない。
そのため、本発明では、ユーザの欲する情報を自在に検索できるユーザフレンドリーな機能を提供することを課題とした。言い換えれば、情報の機密保護と活用における利便性という相反する目的を両立させることを意図した。

上述の技術的課題を解決するために、本発明は、以下の構成をとる。
請求項１の個人情報管理システムは、個人情報データを秘密分散法によって暗号化し、復号用インデックスキーによって復号化する機能を提供する個人情報データ分散管理サーバとの接続機能を有する個人情報を扱うための個人情報管理システムであって、検策用キーワード管理データベースと、個人情報管理装置を備え、検策用キーワード管理データベースには、個人情報のキーワード群と対応付けられた前記復号用インデックスキーが格納され、前記個人情報管理装置は、個人情報の保護レベルを判定し、それに基づいて保管形態を決定する保管取扱手段と、機密保護を必要とする個人情報データの保管要求があれば、該個人情報データを前記個人情報データ分散管理サーバに送信し、前記個人情報データ分散管理サーバから復号用インデックスキーを取得して、該個人情報データを前記復号用インデックスキーと対応付けて前記検索用キーワード管理データベースに格納するデータ保管手段と、個人情報データの取得要求があれば、前記検索用キーワード管理データベースを参照して復号用インデックスキーを取り出し、前記個人情報データ分散管理サーバに送信して、前記復号用インデックスキーによって復号化された個人情報データを、前記個人情報データ分散管理サーバから受信するデータ取得手段とを備えていることを特徴とする。

請求項２は、請求項１に記載の個人情報管理システムにおいて、前記保管取扱手段は、個人情報のデータ特性を規定したデータモデル属性定義を参照し、個人を一意に特定する情報は高位の保護レベル、複数個によって個人を特定しうる情報は中位の保護レベル、個人を特定しえない情報は低位の保護レベルであると判定し、保護レベルに応じて保管形態を決定することを特徴とする。

請求項３は、請求項２に記載の個人情報管理システムにおいて、前記検策用キーワード管理データベースに格納される個人情報データは、保護レベルが高位の属性はハッシュ化され、中位の属性は暗号化されて格納され、低位の属性は平文のままで格納されることを特徴とする。

請求項４〜６は、請求項１〜３に記載の個人情報管理システムにおける個人情報管理装置に、データの管理（保管、取得）をおこなわせるためのプログラムであることを特徴とする。

請求項７は、個人情報保護方法であって、個人情報を構成するデータ項目について、機密保護の必要があるデータ項目は、秘密分散法によって暗号化して保管するとともに、この暗号化されたデータを復号化するためのインデックスキーを格納するデータベースを設け、このデータベースには、前記インデックスキーと対応付けて、機密保護の必要があるデータ項目はハッシュ化あるいは暗号化し、必要の無い項目は平文のまま格納することを特徴とする。

この発明において、「個人情報」とは、個人情報に代表される秘密にすべき内容を含む情報の意味である。したがって、狭義の個人情報に限るものではない。

「秘密分散法によって暗号化し、復号用インデックスキーによって復号化」とは、データを分割して保管し、分割データの持つ復元のための情報によって元データを復元することをいう。ここで、データを分割して保管する方法の代表として「秘密分散法」と表現したにすぎず、他の方法で分割してもよい。
元データへの復元のための情報は、キーワード等とも呼ばれるが、本発明では、検策用キーワード管理データベース内の検索用キーワード群と区別するために「復号用インデックスキー」と表現する。実施形態では、「文書ID」と「文書件名」とが該当する。

「検策用キーワード管理データベース」とは、復号用インデックスキーを介して、分割保管されたデータを取得するためのキーワード群を格納するデータベースである。このデータベースには、統計情報やアクセスログのようにキーワードとして用いられない情報も含む。しかし、主たる目的はキーワード群の格納であるため、「検策用キーワード管理」データベースと表現した。

「保護レベル」とは、一意の個人を特定しえない情報、一意の個人を特定する情報および複数の属性が組み合わさると一意の個人を特定しうる情報の別を表すものであり、実施形態では、それぞれ非機密情報、個人特定情報、準個人特定情報という。

請求項１〜７に記載の発明によれば、秘密情報を安全に保管でき、かつ、容易に活用するという本来相容れない機能が両立実現できる。
一般に、原本データは、分散管理されることにより非常に強固に保護される。しかし、個人情報データは複数媒体に分散されているので、基本的には復号用インデックスキーによる検索しか行えない。そのため、個人情報の内容（例えば、氏名）による検索ができないのが通常である。しかし、本発明では、検索用キーワードになりうる情報と復号用インデックスキーとを対応付けて別個の記憶媒体で管理している。そこで、本発明では、分散された情報を必要な都度復元して活用することが可能となる。

請求項２、請求項５に記載の発明によれば、データモデル属性定義の記述によって、秘密保護レベルを自由に設定することができ、そのレベルに応じて適切な形態のデータ管理ができる。また、当該ファイルの変更だけで、業務処理の変更に対応でき、ソフトウェアの改造を伴わずにすむ。

請求項３、請求項６に記載の発明によれば、秘密にすべき程度によって、ハッシュ化、暗号化、あるいは平文のままで検策用キーワード管理データベースに格納している。このように、保護の必要の高いものほど、扱いを厳しくするとともに、秘密にする必要がない情報は平文で格納することにより、集計処理等の便宜も図っている。

１．システム構成
図１にこの実施形態のシステム構成を示す。
個人情報管理装置１は、インターネット等の通信ネットワークN1を介してユーザ端末２と接続している。また、個人情報管理装置１は、通信ネットワークN２を介して個人情報データ分散管理サーバ３（以下「分散管理サーバ３」）と接続している。この分散管理サーバ３は、元データをいくつかの部分に分割して保存するための記憶媒体４を複数個備えている。

さらに、個人情報管理装置１は、検策用キーワード管理データベース５（以下「キーワード管理ＤＢ５」）にアクセス可能である。キーワード管理ＤＢ５は、個人情報管理装置１の内蔵記憶装置あるいは外付けの記憶装置に格納されていてもよく、個人情報管理装置１とは別個のコンピュータであるデータベースサーバの記憶装置に格納されていてもよい。
なお、ネットワークＮ１、Ｎ２上を送受信する場合において、通信経路上何らかの暗号化が施されていることが望ましい。

バックエンドモジュール（コアシステムを含む）の構成
図２に従い、個人情報管理装置１のソフトウェア構成を説明する。
フロントエンドモジュール６（以下「フロントエンド６」）は、ユーザ端末２からの入力を受け付けて、個人情報を扱う業務処理を行うソフトウェアである。このフロントエンド６は、業務要件に応じたビジネスロジックとユーザインタフェースを実装している。狭義のバックエンドモジュール７は、フロントエンド６においてデータの保管やデータの取得をする必要が生じたときに、フロントエンド６に代わって、データ保管・取得処理を担当する。業務要件に応じたデータの特性を記述したデータモデル属性定義１１を参照して、分散管理サーバ３とキーワード管理ＤＢ５のいずれか一方あるいは双方にデータの保管などをする。コアシステム８は、業務要件にまったく依存しない汎用的なソフトウェアであり、分散管理サーバ３とのインタフェース１０とキーワード管理ＤＢ５とのインタフェース９を介してデータの送受信を行う。

このように、バックエンド１２が、機密保護に配慮したデータ管理を行うので、フロントエンド６は、特に情報の保護を意識しなくて済む。
ところで、フロントエンド６からは、狭義のバックエンドモジュール７もコアシステム８もデータの管理（保管、取得）を行うことに変わりはない。そこで、以下の説明では、特に断らない限り、狭義のバックエンドモジュール７とコアシステム８を併せて、（広義の）バックエンドモジュール１２（以下「バックエンド１２」）ということにする。

バックエンド１２は、図３に示すように、保管取扱手段１３と、データ保管手段１４と、データ取得手段１５を備える。各手段の詳細については後に説明する。

データ属性とデータの物理的保管形態との関連
（１）保護レベルの説明
データ保管手段１４が、保管すべきデータを分散管理サーバ３とキーワード管理ＤＢ５とに振り分けるにあたり、対象データの保護レベルを考慮する。
図４に示すように、保護レベルは、データモデルの保護レベルと属性の保護レベルの２種類がある。データモデルとは、１以上の属性の集合であり、業務処理において１つのまとまりある意味を持つ。例えば、アンケート処理において、アンケートへの回答者の個人情報を構成する氏名や性別等が属性に相当し、それらの体系化された結合がデータモデルに相当する。
上記の２種類の保護レベルによって、データの保管場所（分散管理サーバ３か、キーワード管理ＤＢ５か）と保管データの形態（ハッシュ値、暗号文、平文のいずれか）が定まる。

図４のタイプＡのデータモデルは、個人特定情報ａ１を含むので、慎重な取り扱いを要する。そこで、基本的には分散管理サーバ３に保管する。個人特定情報は、分散管理サーバ３の管理下におき、一切の検索や抽出のキーにならないことが望ましい。しかし、業務処理の内容によっては、個人特定情報で検索できなければならないこともある。そのため、分散管理サーバ３とは別にキーワード管理ＤＢ５にその属性値を格納し、一意検索を可能とすることにした。ただし、属性値をそのまま、つまり平文ではセキュリティの観点から問題であるため、非可逆な状態である一方向性ハッシュ値に加工して格納する。

準個人特定情報ａ２は、検索可能としたいのであれば、属性値を暗号化してキーワード管理ＤＢ５に格納する。準個人特定情報ａ２は、単独では、個人を特定しないが、複数集まると特定の個人を示唆しうるので、平文で格納することは危険だからである。
非機密情報ａ３は、検索可能としたいのであれば、キーワード管理ＤＢ５に平文で格納する。平文なので、これをキーとして、一意検索だけでなく範囲検索や前方一致検索も容易にできる。
なお、個人特定情報ａ１、準個人特定情報ａ２、非機密情報ａ３のいずれも検索対象外であれば、キーワード管理ＤＢ５に格納する必要はない。
このように、保護レベルがタイプＡのデータモデルの属性値は、分散管理サーバ３にすべて保管するとともに、その中で検索対象となる属性のみを格納したテーブルをキーワード管理ＤＢ５に設けることにする。

図４のタイプＢのデータモデルは、個人特定情報を含まないので、分散管理サーバ３に保管しない。準個人特定情報ｂ１は、属性値を暗号化し、非機密情報ｂ２は、属性値を平文のままキーワード管理ＤＢ５に格納する。
図４のタイプＣのデータモデルは、個人特定情報も準個人特定情報も含まないので、分散管理サーバ３に保管せず、各属性値を平文のままキーワード管理ＤＢ５に格納する。

（２）データの物理的保管形態の決定
次に、対象となるデータが、キーワード管理ＤＢ５のテーブルと分散管理サーバ３に、どのように振り分けて保存されるのかを説明する。
なお、分散管理サーバ３の保管データは、実際は、複数の記憶媒体に分割されているが、以下の説明では、復元統合された原本データとする。

保管取扱手段１３が、データモデル属性定義１１を参照し、データの保管形態をどのように決めるかを、図５に従って説明する。
ところで、データモデル属性定義１１は、図４に例示した取り決めをデータモデルの各属性について記述したデータであり、個人情報管理装置１の図示しない記憶部に格納され、必要に応じて読み出される。データモデル属性定義１１には、暗号方式や暗号鍵を記述してもよい。その場合、セキュリティの観点から、分散管理サーバ３に分割保管しておき、必要に応じて取得することが望ましい。要は、機密保護と利便性が両立できればよい。

図５の左側に、データモデル属性定義１１を例示する。
データモデル“回答者情報”は、個人特定情報である”ユーザＩＤ”と”ユーザ名”を属性に持つので、データモデル自体の保護レベルはタイプＡである。そこで、保管取扱手段１３は、属性値を分散管理サーバ３に保管するものと判断する。
”ユーザＩＤ”と”ユーザ名”は保護レベルがａ１であり、検索対象なので、属性値のハッシュ値をキーワード管理ＤＢ５に格納する。
”生年月日”は、保護レベルがａ３であり、検索対象なので、平文のままでキーワード管理ＤＢ５に格納する。
”職種”は、保護レベルがａ２であり、検索対象なので、暗号化してキーワード管理ＤＢ５に格納する。一方、”勤務先名称”は、保護レベルがａ２であるが、検索対象外なのでキーワード管理ＤＢ５には格納しない。

図５の右側は、キーワード管理ＤＢ５のテーブルと分散管理サーバ３の保管データとの対応を示している。両者をリンクするために、文書ＩＤを双方に格納する。この文書ＩＤは、分割されたデータを復元するために使用されるものである。

次に、図６に従い、データモデルの保護レベルがＢの場合の保管形態を説明する。
図６の左にデータモデル属性定義１１を例示する。図６の右上に示したのは、キーワード管理ＤＢ５に格納するテーブルである。
データモデル“回答者別アンケート回答”は保護レベルがＢなので、分散管理サーバ３に保管する必要はない。ただし、分散管理サーバ３に保管されている個人情報と対応付けるために、分散管理サーバ３に格納されている“文書件名”を、キーワード管理ＤＢ５にも格納する。この“文書件名”は特定個人にユニークな情報なので、キーワード管理ＤＢ５には暗号化して格納する。

ところで、保護レベルがタイプＡのデータモデルに対応するテーブルには、特定個人にユニークな情報として“ユーザＩＤ”を付した（図５参照）。この“ユーザＩＤ”と“文書件名”とは異なる情報である。“ユーザＩＤ”と“文書件名”と個人を一意に特定する情報との対応関係は、分散管理サーバ３に分散保管されている情報にのみ存在する。本発明がこのような作りとしたのは、個人情報の保護を万全にするためである。

なお、データモデル属性を、ソフトウェアとは独立に、データモデル属性定義１１に規定したことによって、次のような利点を生ずる。すなわち、業務の変更や新規データモデルへの対応の場合、データモデル属性定義１１の内容を変更するだけで、バックエンド１２の変更を最小限、あるいは変更なしにすることができるという点である。

４．データの保管
次に、図７に従い、フロントエンド６から新規にデータ保管要求があった場合の、バックエンド１２の動作について説明する。

フロントエンド６からバックエンド１２に対し、保管するべき内容とユーザＩＤとを特定し、データ保管要求が送られる（ステップＳ１）。
バックエンド１２は、予め定められたルールに従い文書件名を生成し（ステップＳ２）、保管するべき内容にユーザＩＤと文書件名とを付加して、分散管理サーバ３に所定のフォーマットのデータを生成する（ステップＳ３）。この生成されたデータが、分散管理サーバ３が分割して保管すべき元データとなる。分散管理サーバ３は、保管要求（ステップＳ４）を受け付けると、あらかじめ定められた方法で元データを分割し、複数の記憶媒体に保存する。このとき、分散管理サーバ３は、分割データを復元するための情報である文書ＩＤを生成する。分散管理サーバ３は、分割保存および文書ＩＤの生成を終えると、バックエンド１２に対し、文書ＩＤを送信する（ステップＳ５）。以後、バックエンド１２は、この文書ＩＤを分散管理サーバ３に送信すれば、分割保存されているデータを取得できることになる。

次に、バックエンド１２は、分割保存したデータと関連付けられたテーブルをキーワード管理ＤＢ５に登録しなければならない。そのため、保管取扱手段１３によるデータ属性定義１１の参照結果に基づき、適宜属性値を予め定められたハッシュ関数に代入してハッシュ値を計算したり、暗号化したりする（ステップＳ６）。このハッシュ化等をした各属性値に、文書ＩＤ、ユーザＩＤを付加して、キーワード管理ＤＢ５に登録をする（ステップＳ７）。

５．データの取得
次に、図８に従い、フロントエンド６からデータ取得要求があった場合の、バックエンド１２の動作について説明する。
フロントエンド６からバックエンド１２に対し、ユーザ名を指定して、データ取得要求が送られる（ステップＳ１１）。
バックエンド１２は、データ属性定義を参照し、ユーザ名の保護レベルを取り出す。保護レベルがａ１なので、キーワード管理ＤＢ５には、ユーザ名が平文ではなくハッシュ値で格納されていることがわかる。そこで、指定されたユーザ名をハッシュ計算し（ステップＳ１２）、このハッシュ値でキーワード管理ＤＢ５を検索する（ステップＳ１３）。ハッシュ値が一致した場合、文書ＩＤを抽出する（ステップＳ１４）。次に、バックエンド１２が、この文書ＩＤを分散管理サーバ３に送信し、該当文書の復元と送信を要求する（ステップＳ１５）と、分散管理サーバ３は、復元データを送信する（ステップＳ１６）。

バックエンド１２は、送信された復元データに含まれるユーザ名と、フロントエンド６によって特定されたユーザ名とを照合し（ステップＳ１７）、一致すれば、フロントエンド６にデータを送る（ステップＳ１８）。
なお、ユーザ名が異なる場合でも、ハッシュ計算の結果、同一のハッシュ値を持つことがある。その場合は、ステップＳ１４で複数の文書ＩＤが返されるので、ユーザ名同士が一致するものが見つかるまで、ステップＳ１５〜Ｓ１７の処理を繰り返す。

以上の説明では、“ユーザ名”によって検索・抽出する場合を例にとったが、他の属性による場合も、考え方は同様である。ただし、保護レベルがａ２の場合は、ステップＳ１２で暗号化する必要がある。保護レベルがａ３の場合は、ステップＳ１２は省略し、ステップＳ１３において、平文のままで検索すればよい。

その他
上記の実施形態では、フロントエンド６とバックエンド１２は、同一のコンピュータにインストールされて、動作しているが、異なるコンピュータにインストールしてもよい。
また、業務処理をユーザ端末をクライアントとし、フロントエンドをサーバとする構成で実行しているが、これは例示であり、このようなシステム構成に限るものではない。

上記の実施形態では、保護レベルを３段階に分けているが、あくまでも例示であり、これに限るものではない。
また、準個人特定情報の暗号鍵は、１つに限らず、属性ごとに異なる暗号鍵を持たせても良い。

要するに、上記のように開示された実施の形態はすべての点で例示であって、制限的なものではない。したがって、種々の変形が可能である。しかし、その変形が特許請求の範囲に記載された技術思想に基づくものである限り、その変形は本発明の技術的範囲に含まれる。

実施形態のシステム構成を示す図である。 実施形態の個人情報管理装置のソフトウェア構成を示す図である。 実施形態の（広義の）バックエンドモジュールの機能ブロックを示す図である。 データの保護レベルの種類を示す図である。 実施形態のデータモデル属性定義と保管形態との関連を説明する図である。 実施形態のデータモデル属性定義と保管形態との関連を説明する図である。 実施形態のデータ保管処理のシーケンス図である。 実施形態のデータ取得処理のシーケンス図である。

符号の説明

１ 個人情報管理装置
３ 個人情報データ分散管理サーバ
５ 検索用キーワード管理データベース
１１ データモデル属性定義（ファイル）
１３ 保管取扱手段
１４ データ保管手段
１５ データ取得手段

Claims (7)

1. 個人情報データを秘密分散法によって暗号化し、復号用インデックスキーによって復号化する機能を提供する個人情報データ分散管理サーバとの接続機能を有する個人情報を扱うための個人情報管理システムであって、
   検策用キーワード管理データベースと、個人情報管理装置を備え、
   検策用キーワード管理データベースには、
   個人情報のキーワード群と対応付けられた前記復号用インデックスキーが格納され、
   前記個人情報管理装置は、
   個人情報の保護レベルを判定し、それに基づいて保管形態を決定する保管取扱手段と、
   機密保護を必要とする個人情報データの保管要求があれば、該個人情報データを前記個人情報データ分散管理サーバに送信し、前記個人情報データ分散管理サーバから復号用インデックスキーを取得して、該個人情報データを前記復号用インデックスキーと対応付けて前記検索用キーワード管理データベースに格納するデータ保管手段と、
   個人情報データの取得要求があれば、前記検索用キーワード管理データベースを参照して復号用インデックスキーを取り出し、前記個人情報データ分散管理サーバに送信して、前記復号用インデックスキーによって復号化された個人情報データを、前記個人情報データ分散管理サーバから受信するデータ取得手段とを備えていることを特徴とする個人情報管理システム。
2. 前記保管取扱手段は、個人情報のデータ特性を規定したデータモデル属性定義を参照し、個人を一意に特定する情報は高位の保護レベル、複数個によって個人を特定しうる情報は中位の保護レベル、個人を特定しえない情報は低位の保護レベルであると判定し、保護レベルに応じて保管形態を決定することを特徴とする、請求項１に記載の個人情報管理システム。
3. 前記検策用キーワード管理データベースに格納される個人情報データは、保護レベルが高位の属性はハッシュ化され、中位の属性は暗号化されて格納され、低位の属性は平文のままで格納されることを特徴とする、請求項２に記載の個人情報管理システム。
4. 個人情報データを秘密分散法によって暗号化し、復号用インデックスキーによって復号化する機能を提供する個人情報データ分散管理サーバとの接続機能を有し、前記復号用インデックスキーと個人情報とを格納する検策用キーワード管理データベースにアクセス可能であり、かつ、個人情報を扱う業務処理を実行するコンピュータに、個人情報の保管処理および取得処理を行わせるための個人情報管理プログラムであって、
   個人情報の保護レベルを判定し、それに基づいて保管形態を決定し、
   機密保護を必要とする個人情報データの保管要求があれば、該個人情報データを前記個人情報データ分散管理サーバに送信し、前記個人情報データ分散管理サーバから復号用インデックスキーを取得して、該個人情報データを前記復号用インデックスキーと対応付けて前記検索用キーワード管理データベースに格納し、
   個人情報データの取得要求があれば、前記検索用キーワード管理データベースを参照して復号用インデックスキーを取り出し、前記個人情報データ分散管理サーバに送信して、前記復号用インデックスキーによって復号化された個人情報データを、前記個人情報データ分散管理サーバから受信する処理をコンピュータに行わせることを特徴とする個人情報管理プログラム。
5. 個人情報のデータ特性を規定したデータモデル属性定義を参照し、個人を一意に特定する情報は高位の保護レベル、複数あつまれば個人を特定しうる情報は中位の保護レベル、個人を特定しえない情報は低位の保護レベルであると判定し、保護レベルに応じて保管形態を決定することを特徴とする、請求項４に記載の個人情報管理プログラム。
6. 前記検策用キーワード管理データベースに格納される個人情報データは、保護レベルが高位の属性はハッシュ化され、中位の属性は暗号化されて格納され、低位の属性は平文のままで格納されることを特徴とする、請求項５に記載の個人情報管理プログラム。
7. 個人情報を構成するデータ項目について、機密保護の必要があるデータ項目は、秘密分散法によって暗号化して保管するとともに、この暗号化されたデータを復号化するためのインデックスキーを格納するデータベースを設け、このデータベースには、前記インデックスキーと対応付けて、機密保護の必要があるデータ項目はハッシュ化あるいは暗号化し、必要の無い項目は平文のまま格納することを特徴とする個人情報保護方法。