(57)【要約】      （修正有）【課題】システム外部からの不正アクセスによるにせよ、システム内部者の不正行為によるにせよ、意味のある形で情報が漏洩した場合に、その漏洩した情報の漏洩元や漏洩経路を特定する方法を提供する。【解決手段】少なくとも一つのデータベースと、そのデータベースへのデータの書き込み、及びそのデータベースからのデータの読み出しを制御する制御部とを有し、ユーザからの要求に応じて前記制御部が前記データベースから該当レコードを取得してユーザに提示する、情報処理装置における情報管理方法であって、前記取得されたレコードに、所定の手順に基づいてそのレコードを要求したユーザに固有のダミーデータを混入して出力する。【選択図】図６
2006053711.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも一つのデータベースと、そのデータベースへのデータの書き込み、及びそのデータベースからのデータの読み出しを制御する制御部とを有し、ユーザからの要求に応じて前記制御部が前記データベースから該当レコードを取得してユーザに提示する、情報処理装置における情報管理方法であって、
前記取得されたレコードに、所定の手順に基づいて、そのレコードを要求したユーザに固有のダミーデータを混入して出力する
ことを特徴とする情報管理方法。
【請求項２】
複数の独立したデータベースに１のレコードを構成する個々の項目データがそれぞれ別個に格納され、
前記１のレコードにおける前記各項目間の連係情報がさらに別のデータベースに格納され、前記各データベースに格納されている項目データにはそれぞれ前記連係情報と対応する固有の管理情報が付与され、
ユーザインターフェイスからの要求に応じて前記連係情報を読み出して、前記対応する管理情報により各項目データをそれぞれのデータベースから読み出して要求されたレコードを構成して提示する、情報処理装置における情報管理方法であって、
前記管理情報と連係情報との組み合わせは、前記ユーザインターフェイスからの所定の要求あるいは定められた条件にしたがって変更することができる機能を具備する
ことを特徴とする情報管理方法。
【請求項３】
複数の独立したデータベースに１のレコードを構成する個々の項目データがそれぞれ別個に格納され、
前記１のレコードにおける前記各項目間の連係情報がさらに別のデータベースに格納され、前記各データベースに格納されている項目データにはそれぞれ前記連係情報と対応する固有の管理情報が付与され、
ユーザインターフェイスからの要求に応じて前記連係情報を読み出して、前記対応する管理情報により各項目データをそれぞれのデータベースから読み出して要求されたレコードを構成して提示する、情報処理装置における情報管理方法であって、
前記管理情報と連係情報との組み合わせは前記ユーザインターフェイスからの所定の要求あるいは定められた条件にしたがって変更することができる機能を具備し、
前記要求されたレコードを構成する際に、所定の手順に基づいてダミーデータを前記要求されたレコード中に混入させ、
前記ダミーデータを、そのダミーデータの生成対象となった操作者の識別符号とともに記録して保持しておく
ことを特徴とする情報管理方法。
【請求項４】
１のレコードを構成する個々の項目データが管理情報を伴ってそれぞれ別個に格納されている複数の独立したデータベースと、
前記１のレコードにおける前記各項目間の対応関係を前記管理情報に基づいて規定する連係情報が格納されているさらに別のデータベースと、
ユーザインターフェイスからの要求に応じて前記連係情報を読み出して、その要求内容に基づいて各項目データをそれぞれのデータベースから読み出して要求されたレコードを構成して提示する制御部と、を備えた情報処理システムであって、前記制御部は、
前記管理情報と連係情報との組み合わせを前記ユーザインターフェイスからの所定の要求あるいは定められた条件にしたがって変更できる機能を具備し、
前記要求されたレコードを構成する際に、所定の手順に基づいてダミーデータを前記要求されたレコード中に混入させ、
前記ダミーデータを、そのダミーデータの生成対象となった操作者の識別符号とともに記録して保持しておく
ことを特徴とする情報処理システム。
【請求項５】
複数の独立したデータベースに１のレコードを構成する個々の項目データが管理情報を伴ってそれぞれ別個に格納され、
前記１のレコードにおける前記各項目間の対応関係を前記管理情報に基づいて規定する連係情報がさらに別のデータベースに格納され、それらのデータベースが通信可能に接続されている情報処理装置において、当該情報処理装置に、
ユーザインターフェイスからの要求に応じて前記連係情報を読み出すステップと、
その要求内容に基づいて各項目データをそれぞれのデータベースから読み出して要求されたレコードを構成して提示するステップと、
前記管理情報と連係情報との組み合わせを前記ユーザインターフェイスからの所定の要求、あるいは定められた条件にしたがって変更するステップと、
前記要求されたレコードを構成する際に、所定の手順に基づいて、前記要求されたレコード中にダミーデータを混入させるステップと、
前記ダミーデータを、そのダミーデータの生成対象となった操作者の識別符号とともに記録して保持しておくステップと
を実行させるコンピュータソフトウェアプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報管理方法、情報処理システム、及びプログラムに係わり、特に氏名、住所、電話番号などといった個人情報を安全に管理することができる情報管理方法、情報処理システム、及びプログラムに関する。
【背景技術】
【０００２】
顧客管理やマーケティング等を目的として、個人の氏名や住所、電話番号等をデータベース化して管理することは、従来さまざまな分野で行われてきている。特に、近年大容量の記憶装置が安価に導入できるようになってきたこと、インターネットをはじめとする高速の通信ネットワークが発達してきたことなどにより、多くの企業や機関において大量の個人情報が蓄積されるようになってきた。いわゆるネットを介した通信販売の利便性が知られて頻繁に利用されるようになっている今日の状況では、前記個人情報の中にクレジットカードの番号や銀行預金口座の番号など、漏洩した場合に重大な被害が発生する恐れがある情報も含まれるようになっており、かかる情報漏洩を確実に防止することが切望されていた。このような背景に基づいて、特許文献１には、ユーザの個人情報を分割によって断片化させた状態でネットワーク上の複数のロケーションに格納しセキュリティの向上を図る個人情報管理システムが提案されている。
【特許文献１】特開２００３−２７１７８２
【発明の開示】
【発明が解決しようとする課題】
【０００３】
前記特許文献１に提案のシステムによっても、システム外部からの不正アクセスによるにせよ、システム内部者の不正行為によるにせよ、万一意味のある形で情報が漏洩した場合に、その漏洩した情報の漏洩元や漏洩経路を特定することははなはだ困難である。また、一部の情報が漏洩した場合に、システムの運用を停止することなく、システムのセキュリティを回復することも難しかった。
【課題を解決するための手段】
【０００４】
上記の問題点を解決することを主たる目的としてなされた本発明の一態様は、
少なくとも一つのデータベースと、そのデータベースへのデータの書き込み、及びそのデータベースからのデータの読み出しを制御する制御部とを有し、ユーザからの要求に応じて前記制御部が前記データベースから該当レコードを取得してユーザに提示する、情報処理装置における情報管理方法であって、
前記取得されたレコードに、所定の手順に基づいて、そのレコードを要求したユーザに固有のダミーデータを混入して出力する
ことを特徴とする情報管理方法である。
【０００５】
また、本発明の他の態様は、
複数の独立したデータベースに１のレコードを構成する個々の項目データがそれぞれ別個に格納され、
前記１のレコードにおける前記各項目間の連係情報がさらに別のデータベースに格納され、前記各データベースに格納されている項目データにはそれぞれ前記連係情報と対応する固有の管理情報が付与され、
ユーザインターフェイスからの要求に応じて前記連係情報を読み出して、前記対応する管理情報により各項目データをそれぞれのデータベースから読み出して要求されたレコードを構成して提示する、情報処理装置における情報管理方法であって、
前記管理情報と連係情報とも組み合わせは前記ユーザインターフェイスからの所定の要求あるいは定められた条件にしたがって変更することができる機能を具備する
ことを特徴とする情報管理方法である。
【０００６】
また、本発明のさらに他の態様は、
複数の独立したデータベースに１のレコードを構成する個々の項目データがそれぞれ別個に格納され、
前記１のレコードにおける前記各項目間の連係情報がさらに別のデータベースに格納され、前記各データベースに格納されている項目データにはそれぞれ前記連係情報と対応する固有の管理情報が付与され、
ユーザインターフェイスからの要求に応じて前記連係情報を読み出して、前記対応する管理情報により各項目データをそれぞれのデータベースから読み出して要求されたレコードを構成して提示する、情報処理装置における情報管理方法であって、
前記管理情報と連係情報との組み合わせは前記ユーザインターフェイスからの所定の要求あるいは定められた条件にしたがって変更することができる機能を具備し、
前記要求されたレコードを構成する際に、所定の手順に基づいて、前記要求されたレコード中にダミーデータを混入させ、
前記ダミーデータを、そのダミーデータの生成対象となった操作者の識別符号とともに記録して保持しておく
ことを特徴とする情報管理方法である。
【０００７】
また、本発明のさらに他の態様は、
１のレコードを構成する個々の項目データが管理情報を伴ってそれぞれ別個に格納されている複数の独立したデータベースと、
前記１のレコードにおける前記各項目間の対応関係を前記管理情報に基づいて規定する連係情報が格納されているさらに別のデータベースと、
ユーザインターフェイスからの要求に応じて前記連係情報を読み出して、その要求内容に基づいて各項目データをそれぞれのデータベースから読み出して要求されたレコードを構成して提示する制御部と、を備えた情報処理システムであって、前記制御部は、
前記管理情報と連係情報との組み合わせを前記ユーザインターフェイスからの所定の要求あるいは定められた条件にしたがって変更できる機能を具備し、
前記要求されたレコードを構成する際に、所定の手順に基づいてダミーデータを前記要求されたレコード中に混入させ、
前記ダミーデータを、そのダミーデータの生成対象となった操作者の識別符号とともに記録して保持しておく
ことを特徴とする情報処理システムである。
【０００８】
本発明のさらなる態様は、
複数の独立したデータベースに１のレコードを構成する個々の項目データが管理情報を伴ってそれぞれ別個に格納され、
前記１のレコードにおける前記各項目間の対応関係を前記管理情報に基づいて規定する連係情報がさらに別のデータベースに格納され、それらのデータベースが通信可能に接続されている情報処理装置において、当該情報処理装置に、
ユーザインターフェイスからの要求に応じて前記連係情報を読み出すステップと、
その要求内容に基づいて各項目データをそれぞれのデータベースから読み出して要求されたレコードを構成して提示するステップと、
前記管理情報と連係情報との組み合わせを前記ユーザインターフェイスからの所定の要求、あるいは定められた条件にしたがって変更するステップと、
前記要求されたレコードを構成する際に、所定の手順に基づいて、前記要求されたレコード中にダミーデータを混入させるステップと、
前記ダミーデータを、そのダミーデータの生成対象となった操作者の識別符号とともに記録して保持しておくステップと
を実行させるコンピュータソフトウェアプログラム
である。
【発明を実施するための最良の形態】
【０００９】
以下、添付図面を参照して本発明の実施形態について説明する。
【００１０】
＝＝＝基本システム構成＝＝＝
図１は、本発明の一実施形態による情報処理システムの基本構成を示す概略ブロック図である。連係データベース（連係ＤＢ）１２０、項目データベース（項目ＤＢ）１３０〜１５０が、データ伝送路Ｌを介して、データベース管理システム（ＤＢＭＳ）１０２を含むデータ制御部１００との間でデータ送受信が可能な態様で接続されている。制御部としてのデータ制御部１００は、ＤＢＭＳ１０２が実装された、通信機能を有するコンピュータであって、使用するＯＳ、ＤＢＭＳアプリケーションの形式・種類、ネットワーク環境などは、導入先の事情に合わせて適宜決定すればよい。データ制御部１００にはさらに、ＤＢＭＳと連携するようにダミーデータ処理部１０４が設けられており、後述する各項目ＤＢ１３０〜１５０に格納されるダミーデータの生成及び各項目ＤＢへの書込みを行うように構成される。
【００１１】
この図１の実施形態のシステムにあっては、データ制御部１００、連係ＤＢ１２０、及び項目ＤＢ１３０〜１５０は一のロケーションに集中して、例えば一のラック、筐体などにまとめて実装されている態様を想定している。しかし、リスク分散の観点から、連係ＤＢ１２０と項目ＤＢ１３０〜１５０の一部あるいは全部を別々のロケーションに物理的に分散させて設けた記憶装置に格納してもよい。その場合、前記データ伝送路Ｌは、専用線、公衆電話回線、ＬＡＮ、インターネット等の伝送路から選択して採用することができる。
【００１２】
図１では、各ＤＢが互いに物理的に独立した記憶装置であるかのように図示されているが、物理的に同一の記憶装置を論理的に分割して各論理ブロックに各ＤＢを格納するようにしてもよい。当然のことながら、記憶装置としては、ＨＤＤ、半導体メモリ等、利用可能な種々の形式の記憶デバイスを採用することができる。
【００１３】
なお、本実施形態にあっては、個人情報を構成する各項目データを、互いに独立した項目ＤＢに分割して格納しているが、必ずしも各項目を分割格納する必要はなく、個人情報全体を１つのレコードとして編成し、１つのデータベースにまとめて格納してもよい。このような構成であっても、後述するダミーデータの効果は、言うまでもなく享受することができる。
【００１４】
ユーザインターフェイス１１０は、データ制御部１００のＤＢＭＳ１０２やダミーデータ処理部１０４に対するユーザからの指令を入力したり、ＤＢＭＳ１０２等からの出力をユーザに伝達したりするためのインターフェイス装置である。入力側デバイスとしては、キーボード、マウス、タッチパネル、タブレット、バーコードスキャナ、音声認識入力装置等の一般的なコンピュータ入力機器が、出力側としては、ＣＲＴ、ＬＣＤ等の各種ディスプレイ、プリンタ、フロッピーディスク、ＣＤ、ＤＶＤ等の記録媒体用ドライブ、音声出力装置などが適宜設けられる。このユーザインターフェイス１１０により、システムのユーザはＤＢＭＳ１０２を介して連係ＤＢ１２０、項目ＤＢ１３０〜１５０に対してクエリーを与えて所望のレコードを呼び出したり、各ＤＢの格納データを操作したりすることができる。
【００１５】
＝＝＝各ＤＢの構成＝＝＝
本システムが管理するＤＢは、例えば病院に来院する患者や通信販売の顧客といった管理対象について、それに含まれる個人情報を管理するものである。図１に示すように、本実施形態では、登録されている各個人について、以下のフィールド（項目）を含むレコードとして記録されている。（表１）
【表１】
2006053711.tif 000003
【００１６】
（１）項目ＤＢ
各項目データである氏名、住所、電話番号のデータは、項目ＤＢ１３０〜１５０に分割してそれぞれ、例えば図１の項目データテーブルＴ１ないしＴ３として格納されている。各項目データテーブルの詳細について、図２〜図４を参照しながら説明する。各項目ＤＢに格納されている項目データには、それぞれ管理情報としての内部キー（本実施形態では、氏名キー、住所キー、電話番号キー）が付与されている。なお、各項目データテーブルに設けられている、ダミーフラグを格納したフィールドについては、ダミーデータとの関連で後述する。
【００１７】
なお、登録する個人情報の種類や性質に応じて、さらに他の登録項目を格納する項目ＤＢを必要に応じて追加して設けることができる。
【００１８】
万一いずれかの項目ＤＢからデータが漏洩した場合には、該当項目ＤＢの管理情報として格納されている内部キーを変更する。例えば、氏名、住所、電話番号が個別の項目ＤＢに記録されており、氏名キーがＮ００１、住所キーがＡ００１、電話番号キーがＴ００１、対応する会員ＩＤが１０１１であるとすると、連係ＤＢの該当レコードは、「１０１１，Ｎ００１，Ａ００１，Ｔ００１」である。ここで、例えば氏名情報が流出した場合には、内部管理用の氏名キーを変更することになる。例えば会員ＩＤが１０１１の会員の内部管理用氏名キーをＮ０１１に変更した場合、連係ＤＢのレコードもあわせて「１０１１，Ｎ０１１，Ａ００１，Ｔ００１」と変更される。この操作は、会員ＩＤ毎に各項目ＤＢのレコードをロックし、当該項目ＤＢと連係ＤＢの内部キーデータを順次差し替えることにより行われる。これと同様の操作を他の項目ＤＢについても繰り返すことにより、さらに氏名キー以外の、他の内部キーをも差し替えてしまってもよく、この場合、漏洩した項目データに限って内部キーデータを差し替えるよりも、セキュリティがよりいっそう高められる。
【００１９】
なお、内部キーの変更は、上述のように、データ漏洩が発覚したことに対応して実施するほか、不測のデータ漏洩を未然に防ぐために、データ漏洩が発生しなくとも、データ制御部１００にあらかじめ設定した一定条件が成立したときにデータ制御部１００で強制的に、いずれかのあるいはすべての項目データに付帯している内部キーを、連係ＤＢの該当内部キーと合わせて変更する構成としてもよい。前記一定条件としては、システムの運用時間が一定値に達した場合、レコードの読み出し回数が所定数に達した場合など、適宜の条件をデータ制御部１００にて設定することができる。
【００２０】
（２）連係ＤＢ
次に、連係ＤＢ１２０について、図５を参照して説明する。連係ＤＢ１２０の連係テーブルＬＴ（図１）に格納されたデータは、本システムに個人情報が登録されている各個人について会員ＩＤを付与して管理している。連係ＤＢ１２０の１レコードは、会員ＩＤ、氏名キー、住所キー、電話番号キー、及びダミーフラグの５つのフィールドから構成されている（ダミーフラグについては後述する。）。したがって、連係ＤＢ１２０に所望の会員ＩＤについてのレコードに関するクエリーを与えれば、データ制御部１００のＤＢＭＳ１０２は、その会員ＩＤに関連付けられたレコードに含まれる当該会員の氏名キー、住所キー、電話番号キーを用いて各項目ＤＢ１３０〜１５０へ問い合わせ、それぞれのキーに対応する項目データを会員ＩＤと関連付けて取得し、ユーザインターフェイス１１０を介してユーザに提示する。
【００２１】
この際、各項目ＤＢ単位に異なるＤＢ管理者を割り当てて、データ制御部１００から各項目ＤＢにデータ読み出しの要求がなされる都度、各ＤＢ管理者の認証がなければ該当する項目データを読み出すことができない構成としておけば、複数のＤＢ管理者の認証がある場合のみに意味のあるレコードを抽出することができることとなり、よりいっそうセキュリティが向上する。また、各項目ＤＢ単位でＤＢ管理者を設けることなく、ユーザがデータ制御部１００に与えたクエリーに基づいて、各項目ＤＢに連係情報が与えられ、データの読み出し要求がされた場合に、データ制御部１００及びユーザインターフェイス１１０を介して認証パスワードなどを要求するダイアログ画面を提示するようにしてもよい。この場合、ユーザが少なくとも２以上の項目ＤＢについてその認証パスワードを知得していない限り、当該ユーザは有意なレコードを読み出すことができないことになる。
【００２２】
なお、以上の各ＤＢに格納されるデータは平文であるものとして構成しているが、例えばデータ制御部１００に各ＤＢへの送信データを暗号化し、また各ＤＢからの受信データを復号化するモジュールを公知の構成を用いて設けることにより、各ＤＢのセキュリティを強化することができる。また、会員ＩＤに関連付けられる内部キーについて、例えば、氏名データについて、
［会員ＩＤ指定］→［第１の氏名キー］→［第２の氏名キー］→［氏名データ］
といった氏名キーの関連付けを、階層を持たせるように設定すれば、よりデータへの不正アクセスがしにくいシステムを構築することができる。
【００２３】
（３）ダミーデータ
次に、本願発明の主たる特徴の一つであるダミーデータについて説明する。図２ないし図５を参照されたい。
【００２４】
本実施例のシステムでは、図示のとおり、各項目ＤＢである氏名ＤＢ、住所ＤＢ、電話番号ＤＢと、連係ＤＢに、ダミーフラグを格納したフィールド（各ＤＢに格納されたテーブルの右端の列）が設けられている。ここで、ダミーフラグとは、特定のユーザが本システムにログインした場合に、そのユーザに固有のダミーデータを生成するためのインデックスとなるデータである。ダミーフラグの値が０であるレコードは、真正のデータが格納されているレコードである。一方、０以外の文字列が格納されているレコードは、そのレコードに関するデータがダミーであることを示す。ダミーフラグに記録されている文字列は、あるユーザがシステムにログインしてレコードを読み出した場合に、個々のユーザについてユニークに割り当てられた符号である。本実施例では、説明を簡単にするために、Ａ，Ｂ，Ｃの３人のユーザがシステムに登録されているものとする。それぞれのユーザがログインしてレコードを読み出した場合に、各ダミーフラグに基づいてダミーデータが生成されて、ユーザの要求にしたがって読み出されたレコードにその割り当てられたダミーデータが混入されることとなる。
【００２５】
いま一例として、ユーザＡが本システムにログインして所望のデータを読み出すプロセスを考える。ユーザＡが与えたクエリーに対して、会員ＩＤ１０１１〜１０１３がヒットしたと仮定する。この場合、ユーザＡのログインに基づいて、データ制御部１００のダミーデータ処理部１０４は、上記のヒットしたレコードに加えて、ユーザＡ固有のダミーデータ（該当する会員ＩＤに＊印を付して示す。この印はあくまでも分かりやすくするために付したもので、このような記号が実際にデータ中に含まれるわけではない。）をダミーフラグＡに基づいて生成する。（表２）
【表２】
2006053711.tif 000004
【００２６】
会員ＩＤ１０１４のレコードは、ユーザＡについて生成されたダミーデータである。したがって、このユーザＡが読み出した情報が外部に漏洩した場合には、必ずその情報に会員ＩＤ１０１４に関するユーザＡ固有のダミーデータが混入されていることとなり、漏洩した情報に含まれるデータを解析すれば、その情報漏洩がユーザＡによるもの（若しくはユーザＡの関与が濃厚に疑われるもの）と判定することができる。
【００２７】
なお、上記のダミーフラグが記録されたフィールドは、各ユーザ固有のダミーデータが不用意に露見しないように、通常のアクセス権限を有する一般ユーザには不可視となるように、データ制御部１００を構成するものとする。そして、特権的なシステム管理者が、システムに設定された特殊な認証コード等を入力した場合にのみダミーフラグフィールドを閲覧することができるようにする。
【００２８】
以上の説明からわかるように、ダミーデータは、本システムユーザが気づかないように、実在の抽出データに混在する形で出力される。したがって、例えばダイレクトメールの送り先リストなどとして抽出されたデータを利用するシステムユーザにしてみれば、知らないうちに無効なデータが混入されていることとなる。この点、抽出データの有用性がある程度損なわれることは確かである。ただ、個人情報の保護がますます重要性を持ってきていることを考慮すれば、多少データの有用性が低下しても許容しうると考えられる。データの有用性をより重視するとすれば、ダミーデータ処理部１０４に生成されたダミーデータを除去するフィルタ機能を実装する、ダミーデータを混入せずにデータの抽出を行うことを許容するような特殊な認証パスワードを別途設けること等が考えられる。
【００２９】
また、ユーザＡとユーザＢが共謀してデータの不正なダウンロードを試みたと仮定すると、本実施形態の例では、ユーザＡのダウンロードしたデータ群とユーザＢがダウンロードしたデータ群とを突き合わせて検証すれば、共通の実在データ以外に、互いに一致しないダミーデータが混入されていることが露見してしまうおそれがある。このような事態を未然に防ぐためには、ダミーフラグフィールドを２以上設けて、複数のユーザが共謀してデータの不正入手を図った場合でも、そのユーザの組み合わせに該当するダミーデータを生成して混入し、ダミーデータの混入を見破られないようにすることが考えられる。
【００３０】
例えば表３の例では、ユーザＡ，Ｂが共謀したとしても、それぞれダミーデータとして会員ＩＤ1014のデータが共通に含まれることになるので、ユーザＡおよびユーザＢが入手したデータをＡＮＤ条件またはＯＲ条件で結合したとしても、完全にダミーデータを排除することはできなくなる。
【表３】
2006053711.tif 000005
【００３１】
＝＝＝本実施形態のシステムの作用＝＝＝
以下、本実施形態のシステムが奏する作用について、より具体的に説明する。
【００３２】
<<通常業務におけるデータの読み出し>>
図６に、通常業務におけるデータ読み出しの概略フローを示す。通常業務とは、特権的なシステム管理者ではない一般のシステムユーザが、自己の認証手段を用いてシステムから所望のデータを読み出す日常的な操作を行うことである。
【００３３】
まず、データを読み出そうとするユーザは、所定の認証手段（パスワード入力等）によって、ユーザインターフェイス１１０を介して本システムにログインする。そして、入力画面などを通じて、クエリーを与える。
【００３４】
入力されたクエリーは、ユーザインターフェイス１１０を介してデータ制御部１００へ渡される（S10,S12）。クエリーが会員ＩＤに基づいて与えられた場合には、データ制御部１００のＤＢＭＳ１０２は、直接連係ＤＢ１２０の連係テーブルＬＴにアクセスし、会員ＩＤに対応する内部キーを入手する（S14,S16）。
【００３５】
連係ＤＢ１２０から必要な内部キー（氏名キー、住所キー、電話番号キー）を取得したＤＢＭＳ１０２は、次いでその各内部キーに基づいて、各項目ＤＢにアクセスし、前記内部キーにより関連する氏名、住所、電話番号のデータを取得する（S18,S20）。ＤＢＭＳ１０２は、会員ＩＤとそれに関連する各項目データを会員ＩＤごとのレコードに編集し、表形式等適宜の形式でユーザインターフェイス１１０に出力する（S22,S24）。例えば、ユーザは、表２のリストの形式でプリンタからプリントアウトすることもできるし、フロッピーディスク等の他の記憶媒体へ種々のファイル形式（CSV形式、SYLK形式等）で出力させることもできる。この場合、表２について前述したように、取り出したデータにはアクセスしたユーザに固有のダミーデータが混入されることとなる。
【００３６】
なお、どのようなダミーデータが、どのユーザについて生成されたかは、ユーザのアクセスログの一部として、データ制御部１００に設ける適宜の記憶装置に格納され、後日追跡できるように構成される。
【００３７】
<<ダミーデータの生成>>
次に、ダミーデータの生成の仕方について、例を挙げて説明する。  
図７は、データ制御部１００に設けられているダミーデータ処理部１０４におけるダミーデータ生成のフローの一例を示す。まず、ユーザがユーザインターフェイス１１０を通じて新規の会員データを追加すると（S700）、ダミーデータ処理部１０４は、登録された会員データ数があらかじめ設定されている所定値を越えたかどうか調べる（S710）。所定値に達していなければ（S710、No）、ダミーデータを生成することなくこのフローは終了する。登録会員データ数が所定値に達していると判定されれば（S710、Yes）、ダミーデータ作成プロセスに移る。
【００３８】
まず、ダミーデータの作成ルールが定義されているかどうかを調べる（S720）。ダミーデータは、前記したように、あらかじめ各項目ＤＢに格納しておいて、読み出し要求があったときにそれらを組み合わせて作成してもよいし、読み出し要求に応じて各項目についてリアルタイムに生成するようにしてもよい。リアルタイムでダミーデータを生成する場合には、ダミーデータ生成ルールを原則として各項目ＤＢについて設定しておく（S720,Yes、S730）。例えば、本実施形態における氏名、住所のような日本語文字列データの場合、ダミーデータであることが容易に露見しないように、あらかじめ実在の氏名や住所に似せて作成した多数のダミーの中からランダムに選択してダミーデータとすることができる。あるいは、電話番号や金融機関の口座番号、クレジットカード番号のような英数文字列であれば、疑似乱数生成プロセスによってダミーデータを作り出すこともできる。
【００３９】
ダミーデータ作成ルールが定義されていない場合には（S720，No）、すでに各項目ＤＢに格納されている実在データから適宜のアルゴリズムによって抽出したデータを組み合わせることで、実在データではありえないダミーデータのレコードを生成する（S740）。なお、実在データの一部の文字列を入れ替えたり、他の文字列と置き換えたりして実在データとは異なるダミーデータを生成するようにしてもよい。
【００４０】
<<アクセス監視機能と組み合わせたデータ読み出し処理>>
次に、ユーザのシステムへのアクセス状況を監視する機能を組み込んだ本発明の一変形例に係るデータ読み出し処理について、図８のフローチャートを参照して説明する。この処理フローは、例えば、ＤＢＭＳ１０２及びダミーデータ処理部１０４を備えたデータ制御部１００に実装されるコンピュータソフトウェアによって実現される。
【００４１】
まず、ユーザが、ユーザインターフェイス１１０の入力デバイスを介して自己のユーザＩＤ及び認証パスワードをシステムに入力すると、データ制御部１００は、その入力されたユーザＩＤ及び認証パスワードがあらかじめシステムに登録されているものと一致するかどうか（正しいかどうか）を調べる（S800、S802）。ユーザＩＤ又は認証パスワードに不備があれば（S802,No）、システムはそのユーザのログインを拒否してフローは終了する。
【００４２】
入力されたユーザＩＤ及び認証パスワードが正規のものであると判定されれば（S802,Yes）、入力されたユーザＩＤに基づいて、混入するダミーデータを作成する（S804）。ダミーデータの作成処理については、すでに説明したフローを参照されたい。ここで、データ制御部１００は、ユーザからの命令入力を待つアイドリング状態となる（S806）。
【００４３】
次いで、ユーザから入力された命令が終了（ログオフ）処理の要求であると判定されれば（S808,Yes）、そのままこのフローは終了する。ユーザから入力された命令が終了（ログオフ）処理でないと判定されれば（S808,No）、データ制御部１００は、ユーザが入力した命令内容を適宜のメモリに記録する（S810）。この処理は、情報漏洩や不正アクセスなどの異常事態が生じた場合に、どのユーザからどのような処理要求があったかをさかのぼって追跡できるようにするために、各ユーザのアクセスログをとるプロセスである。
【００４４】
次に、データ制御部１００は、ユーザからの命令入力があらかじめ設定された第一の処理数設定値（「警告」レベル）に達したか否かを調べる（S812）。命令入力の処理数が前記設定値に達していた場合は（S812,Yes）、その事象をシステム管理者に通知する（S814）。この場合、前記の通知は、通信ネットワークを介してシステム管理者のアドレス宛に電子メールを送信する等、公知の適宜な構成を用いて行うことができる。
【００４５】
そして、さらにデータ制御部１００は、ユーザからの命令入力があらかじめ設定された、前記第一の処理数設定値よりも大きい第二の処理数設定値（「禁止」レベル）に達したか否かを調べる（S816）。命令入力の処理数が前記第二の設定値に達していた場合は（S816,Yes）、データ制御部１００は、ユーザインターフェイス１１０を通じてユーザにそれ以上の命令を受け付けることができなくなった旨を表示し（S818）、フローを終了する。このように「警告」、「禁止」レベルを設定してユーザからの命令入力を監視するのは、一回のログインであらかじめ想定した命令処理数を超えるような大量の命令をシステムに処理させようとしている場合には、なんらかの意図をもって大量の会員データをダウンロードしようとしているなど、不正行為につながる蓋然性が高いと考えられるからである。このように大量の命令処理について警告、又は処理禁止の対応を行うことによって、不正アクセスによる情報漏洩といった事態に対するシステム耐性がいっそう高まる。
【００４６】
なお、命令入力の処理数が前記「警告」レベルに達した場合には、上述のようにシステム管理者にその旨を通知するとともに、各項目データに付された内部キー（管理情報）とそれに対応する連係ＤＢのレコード（連係情報）を自動的に変更する構成としておくことにより、よりいっそうセキュリティの強化を図ることができる。
【００４７】
一方、ユーザからの命令入力処理数が前記第一の処理数設定値に達していないか、前記第二の処理数設定値に達していない場合には（S812,No又はS816,No）、さらにユーザの入力した命令がデータ抽出処理であるかどうかを判定する（S820）。ユーザの入力した命令がデータ抽出処理の要求であれば（S820,Yes）、データ制御部１００は、前述したダミーデータの生成方法によって生成された、アクセスしているユーザに対して一意に対応するダミーデータを、ユーザの要求にしたがって抽出したデータに混入して、ユーザインターフェイス１１０を介してユーザに提示する（S822）。ユーザからの要求がデータ抽出処理でなければ（S820,No）、ダミーデータは生成せずに、ユーザの要求した処理を実行してアイドリング状態に戻り待機する（S824、S806）。
【００４８】
以上、本発明の種々の実施形態によって詳細に説明したように、単一のＤＢ管理者の不正行為により情報が漏洩した場合には、意味のある個人情報の漏洩にならない（仮に、氏名だけが漏洩しても、そこに記載されている氏名が他に付帯的情報を持たなければ、人名辞典程の意味しかない。）ので、セキュリティが保障される。また、各項目ＤＢについて個別の認証を受けなければ、個人についての連係した意味のある情報を得られないようにすることができる。
【００４９】
また、各システムユーザに固有のダミーデータを生成・記録し、実在データに混入して出力するようにしたので、万一情報の漏洩があった場合には、漏洩した情報から、漏洩元、漏洩経路を知ることができる。
【００５０】
さらに、一部の項目ＤＢから情報が漏洩した場合には、システムとしての運用を止めることなく、内部管理情報としての内部キーを差し替えることで、盗難されたデータが外部で連携されることを防ぐことが可能になる。
【００５１】
本発明は、病院情報システム、金融システム等の個人情報を扱うシステムのデータベースといった用途に適用できる。また、未公開の特許出願やシステム開発のノウハウ等が記録された機密情報を扱うデータベースといった用途にも適用可能である。
【図面の簡単な説明】
【００５２】
【図１】本発明の一実施形態による情報処理システムの基本構成を示す概略ブロック図である。
【図２】本発明の一実施形態に係る項目データテーブルである。
【図３】本発明の一実施形態に係る項目データテーブルである。
【図４】本発明の一実施形態に係る項目データテーブルである。
【図５】本発明の一実施形態に係る連係データテーブルである。
【図６】本発明の一実施形態に係る情報処理システムの通常業務におけるデータ読み出し処理の概略フローである。
【図７】本発明の一実施形態に係る情報処理システムのダミーデータ生成フローの一例を示す。
【図８】本発明の他の実施形態に係る情報処理システムのデータ読み出し処理の概略フローである。
【符号の説明】
【００５３】
１００    データ制御部
１１０    ユーザインターフェイス
１０２    データベース管理システム
１０４    ダミーデータ処理部
１２０    連係データベース
１３０，１４０，１５０    項目データベース
Ｌ        データ伝送路
【図１】
2006053711.tif 000006
【図２】
2006053711.tif 000007
【図３】
2006053711.tif 000008
【図４】
2006053711.tif 000009
【図５】
2006053711.tif 000010
【図６】
2006053711.tif 000011
【図７】
2006053711.tif 000012
【図８】
2006053711.tif 000013