(57)【要約】  【課題】  個人情報等が外部に流出した場合にその流出元を特定できるようにする。  【解決手段】  データベースの検索要求を検索要求者の識別情報と共に取得する検索要求取得部１３１と、この検索要求に基づきデータベースを検索すると共にその検索結果にダミーデータを混在させる検索処理部１３２と、ダミーデータを混在させた検索結果を検索要求者に対して出力する検索結果出力部１３３と、検索要求者の識別情報と検索結果に混在させたダミーデータとの対応関係を示す情報を作成する使用履歴作成部１３４と、検索要求取得部１３１〜使用履歴作成部１３４を制御する制御部１３０とを備える。  【選択図】  図１１
2005222135.tif 000002
【特許請求の範囲】
【請求項１】
データベースの検索要求を検索要求者の識別情報と共に取得する検索要求取得部と、
前記検索要求取得部により取得された前記検索要求に基づき前記データベースを検索すると共に、その検索結果にダミーデータを混在させる検索処理部と、
前記検索要求取得部により取得された前記検索要求者の識別情報と、前記検索処理部が前記検索結果に混在させた前記ダミーデータとの対応関係を示す情報を作成する使用履歴作成部と、
前記検索処理部が前記ダミーデータを混在させた前記検索結果を前記検索要求者に対して出力する検索結果出力部と
を備えたことを特徴とするデータベースアクセス監視装置。
【請求項２】
前記検索処理部は、前記検索結果にその全データ件数の一定の割合で前記ダミーデータを混在させることを特徴とする請求項１記載のデータベースアクセス監視装置。
【請求項３】
前記検索処理部は、前記検索結果の全データ件数が一定数を超える場合に当該検索結果に前記ダミーデータを混在させることを特徴とする請求項１記載のデータベースアクセス監視装置。
【請求項４】
前記検索処理部は、同一の前記検索要求者からの検索要求に基づく検索結果に、同一の前記ダミーデータを混在させることを特徴とする請求項１記載のデータベースアクセス監視装置。
【請求項５】
前記検索処理部は、予め互いの関係が定義された異なる前記検索要求者からの検索要求に基づく検索結果に、同一の前記ダミーデータを混在させることを特徴とする請求項１記載のデータベースアクセス監視装置。
【請求項６】
個人情報データベースの検索要求を検索要求者の識別情報と共に取得する検索要求取得部と、
前記検索要求取得部により取得された前記検索要求に基づき前記個人情報データベースを検索すると共に、その検索結果に対し、ダミーの個人について予め作成された複数のダミーデータのうちの一のダミーデータを追加する検索処理部と、
前記検索要求取得部により取得された前記検索要求者の識別情報と、前記検索処理部により追加された前記一のダミーデータとの対応関係を示す情報を作成する使用履歴作成部と、
前記検索処理部により前記一のダミーデータが追加された前記検索結果を前記検索要求者に対して出力する検索結果出力部と
を備えたことを特徴とするデータベースアクセス監視装置。
【請求項７】
前記検索処理部は、前記ダミーの個人についてその氏名および/または住所の表記を当該個人への郵便の配達に影響を与えない程度に異ならせることで作成された前記複数のダミーデータのうちの一のダミーデータを追加することを特徴とする請求項６記載のデータベースアクセス監視装置。
【請求項８】
前記検索処理部は、前記ダミーの個人についてその電話番号を異ならせることで作成された前記複数のダミーデータのうちの一のダミーデータを追加することを特徴とする請求項６記載のデータベースアクセス監視装置。
【請求項９】
前記検索処理部は、前記ダミーの個人について、その氏名および/または住所の表記を当該個人への郵便の配達に影響を与えない程度に異ならせることで作成されたダミーデータと、その電話番号を異ならせることで作成されたダミーデータとの両方を含む前記複数のダミーデータのうちの一のダミーデータを追加することを特徴とする請求項６記載のデータベースアクセス監視装置。
【請求項１０】
前記検索処理部は、互いにプロファイル情報の異なる複数の前記一のダミーデータを追加することを特徴とする請求項６記載のデータベースアクセス監視装置。
【請求項１１】
データベースの検索結果にダミーデータを混在させると共に、当該ダミーデータが混在した検索結果を検索要求者に対して出力するデータベースアクセス監視部と、
前記検索要求者の識別情報と、前記データベースアクセス監視部が前記検索結果に混在させた前記ダミーデータとの対応関係を示す情報を記憶する使用履歴記憶部と、
前記使用履歴記憶部を参照することにより、特定のダミーデータに対応付けられた前記検索要求者の識別情報を出力する検証部と
を備えたことを特徴とする情報流出元特定システム。
【請求項１２】
コンピュータがデータベースに対するアクセスを監視するデータベースアクセス監視方法であって、
前記コンピュータが、前記データベースの検索要求を検索要求者の識別情報と共に取得するステップと、
前記コンピュータが、前記検索要求に基づき前記データベースを検索するステップと、
前記コンピュータが、前記データベースの検索結果にダミーデータを混在させる処理を行うステップと、
前記コンピュータが、前記検索要求者の識別情報と、前記検索結果に混在させた前記ダミーデータとの対応関係を示す情報を所定の記憶装置に記憶するステップと、
前記コンピュータが、前記ダミーデータを混在させた前記検索結果を前記検索要求者に対して出力するステップと
を含むことを特徴とするデータベースアクセス監視方法。
【請求項１３】
データベースの検索結果にダミーデータを混在させると共に、当該ダミーデータが混在した検索結果を検索要求者に対して出力するステップと、
前記検索要求者の識別情報と、前記検索結果に混在させた前記ダミーデータとの対応関係を示す情報を所定の記憶装置に記憶するステップと、
記憶された前記対応関係を示す情報に基づき、特定のダミーデータに対応付けられた前記検索要求者の識別情報を特定するステップと
を含むことを特徴とする情報流出元特定方法。
【請求項１４】
コンピュータに、
データベースの検索要求を検索要求者の識別情報と共に取得する機能と、
取得された前記検索要求に基づき前記データベースを検索すると共に、その検索結果にダミーデータを混在させる機能と、
前記検索要求者の識別情報と、前記検索結果に混在させた前記ダミーデータとの対応関係を示す情報を作成する機能と
を実現させるためのプログラム。
【請求項１５】
前記混在させる機能において、前記検索結果にその全データ件数の一定の割合で前記ダミーデータを混在させることを特徴とする請求項１４記載のプログラム。
【請求項１６】
前記混在させる機能において、同一の前記検索要求者からの検索要求に基づく検索結果に、同一の前記ダミーデータを混在させることを特徴とする請求項１４記載のプログラム。
【請求項１７】
前記混在させる機能において、予め互いの関係が定義された異なる前記検索要求者からの検索要求に基づく検索結果に、同一の前記ダミーデータを混在させることを特徴とする請求項１４記載のプログラム。
【請求項１８】
前記混在させる機能において、前記検索結果に含まれる特定のデータに予め定義されたルールに従った処理を施して前記ダミーデータを生成することで、当該検索結果に当該ダミーデータを混在させることを特徴とする請求項１４記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、個人情報等が外部に流出した場合にその流出元の特定を行う情報流出元特定システム等に関する。
【背景技術】
【０００２】
今日、多くの企業が、顧客の囲い込み等のため、顧客データ等の個人情報を保有している。企業が個人情報を保有すること自体は、その営業上の必要から致し方ないが、個人情報が企業によって適切に取り扱われなかった場合は問題となる。例えば、企業の個人情報の管理がずさんであったために、個人情報が外部に流出してしまったという事例も多く報告されている。このような事例が報告されるたびに、一般消費者は、企業による個人情報の管理に不安を感じ、昨今では、社会全体として、個人情報の取り扱いに対して敏感に反応するようになってきている。
このような状況等を受けて、平成１５年５月に個人情報保護法が成立した。個人情報保護法においては、本人の同意を得ない第三者への個人情報の提供の原則禁止等が規定されている。これらの規定に違反した企業には罰則も科せられるようになった。即ち、企業側にも個人情報の管理責任が問われることが法文上明記されたのである。
【０００３】
一方で、顧客データを名簿として管理する名簿管理業務については、その名簿を保有する企業内で行うのではなく、外部の業者に委託して行わせるケースが増加している。例えば、国内で収集した個人情報のコンピュータへの入力のみを、人件費の安い海外の業者に委託するといったことがある。こういった名簿管理業務は、その業務内容としては単調なものであるため、かかるアウトソーシングの流れは確定的ではあるが、委託先の委託元に対する忠誠度は希薄であり、委託元が委託先の労働者のモラルまで維持するのは現実的には難しい。
【０００４】
従って、個人情報の流出は今後も頻発することが予想され、しかも社会問題としては、より存在感を増していくと思われる。そこで、このように増え続けるであろう個人情報の流出に対し、解決策も模索され始めている(例えば、特許文献１参照。)。
【０００５】
【特許文献１】特開２００２−１８３３６７号公報(第３、４頁、第１図)
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１の技術では、企業にとって、個人情報が自社から流出したことまでが明らかになるだけであって、自社の内部で何が起こったのかは分からないという問題点があった。即ち、自社の内部で誰によって個人情報が持ち出されたのかというところまでは分からない。
従って、特許文献１のシステムをもって、企業がその保有する個人情報を取り扱う労働者のモラルを引き上げようとするには、存在感が弱い。むしろ、特許文献１のようなシステムは、個人情報を流出した企業が特定されるだけであるので、企業にその技術を使う動機は生まれない。
さらに、特許文献１のシステムでは、個人情報の流出の事実のみが明らかになって、肝心の流出プロセスが判明しない。流出プロセスについては、個人情報保護サービス事業者と流出元企業との間の企業間交渉で分析されることになり、交渉は長引く可能性が高い。従って、流出原因の解明、流出防止のための改善等の事後処理を迅速に行うことができないという問題点もあった。
【０００７】
本発明は、以上のような技術的課題を解決するためになされたものであって、その目的は、個人情報等が外部に流出した場合にその流出元(経路)を特定できるようにすることにある。
また他の目的は、個人情報等の流出元を特定できるようにすることで、労働者のモラルを引き上げ、情報を厳格に管理したいとの企業の要望に応えることができるようにすることにある。
さらに他の目的は、個人情報等の流出元を特定できるようにすることで、情報が流出した後の処理を迅速に行えるようにすることにある。
【課題を解決するための手段】
【０００８】
かかる目的のもと、本発明は、データベースの検索を行った者とその者に提示したダミーデータとの対応を後から追跡できるようにするための情報を残しておくようにした。即ち、本発明の第１のデータベースアクセス監視装置は、データベースの検索要求を検索要求者の識別情報と共に取得する検索要求取得部と、この検索要求取得部により取得された検索要求に基づきデータベースを検索すると共に、その検索結果にダミーデータを混在させる検索処理部と、検索要求取得部により取得された検索要求者の識別情報と、検索処理部が検索結果に混在させたダミーデータとの対応関係を示す情報を作成する使用履歴作成部と、検索処理部がダミーデータを混在させた検索結果を検索要求者に対して出力する検索結果出力部とを備えている。
【０００９】
また、本発明は、データベースを個人情報データベースに特化して捉えることもできる。その場合、本発明の第２のデータベースアクセス監視装置は、個人情報データベースの検索要求を検索要求者の識別情報と共に取得する検索要求取得部と、この検索要求取得部により取得された検索要求に基づき個人情報データベースを検索すると共に、その検索結果に対し、ダミーの個人について予め作成された複数のダミーデータのうちの一のダミーデータを追加する検索処理部と、検索要求取得部により取得された検索要求者の識別情報と、検索処理部により追加された一のダミーデータとの対応関係を示す情報を作成する使用履歴作成部と、検索処理部により一のダミーデータが追加された検索結果を検索要求者に対して出力する検索結果出力部とを備えている。
【００１０】
さらに、本発明は、情報が流出した場合にその流出元を特定するための情報流出元特定システムとして捉えることができる。その場合、本発明の情報流出元特定システムは、データベースの検索結果にダミーデータを混在させると共に、そのダミーデータが混在した検索結果を検索要求者に対して出力するデータベースアクセス監視部と、検索要求者の識別情報と、データベースアクセス監視部が検索結果に混在させたダミーデータとの対応関係を示す情報を記憶する使用履歴記憶部と、この使用履歴記憶部を参照することにより、特定のダミーデータに対応付けられた検索要求者の識別情報を出力する検証部とを備えている。
【００１１】
さらにまた、データベースの検索を行った者とその者に提示したダミーデータとの対応を後から追跡できるようにするための情報を残しておく方法として捉えることできる。その場合、本発明のデータベースアクセス監視方法は、コンピュータがデータベースに対するアクセスを監視するものであり、コンピュータが、データベースの検索要求を検索要求者の識別情報と共に取得するステップと、コンピュータが、検索要求に基づきデータベースを検索するステップと、コンピュータが、データベースの検索結果にダミーデータを混在させる処理を行うステップと、コンピュータが、検索要求者の識別情報と、検索結果に混在させたダミーデータとの対応関係を示す情報を所定の記憶装置に記憶するステップと、コンピュータが、ダミーデータを混在させた検索結果を検索要求者に対して出力するステップとを含んでいる。
【００１２】
また、本発明は、情報が流出した場合にその流出元を特定するための方法として捉えることができる。その場合、本発明の情報流出元特定方法は、データベースの検索結果にダミーデータを混在させると共に、そのダミーデータが混在した検索結果を検索要求者に対して出力するステップと、検索要求者の識別情報と、検索結果に混在させたダミーデータとの対応関係を示す情報を所定の記憶装置に記憶するステップと、記憶された対応関係を示す情報に基づき、特定のダミーデータに対応付けられた検索要求者の識別情報を特定するステップとを含んでいる。
【００１３】
一方、本発明は、コンピュータに所定の機能を実現させるためのプログラムとして捉えることもできる。その場合、本発明のプログラムは、コンピュータに、データベースの検索要求を検索要求者の識別情報と共に取得する機能と、取得された検索要求に基づきデータベースを検索すると共に、その検索結果にダミーデータを混在させる機能と、検索要求者の識別情報と、検索結果に混在させたダミーデータとの対応関係を示す情報を作成する機能とを実現させる。
【発明の効果】
【００１４】
本発明によれば、個人情報等が外部に流出した場合にその流出経路を特定することが可能となる。
【発明を実施するための最良の形態】
【００１５】
以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
本実施の形態は、個人情報等を格納したデータベース(以下、「ＤＢ」という)の検索要求がＤＢ使用者(以下、「エージェント」という)からなされた場合に、その検索結果にダミーの個人情報等を微量混入し、エージェントに対して出力するものである。また、その際、混入したダミーの個人情報等をどのエージェントに対して出力したかを記録しておく。これにより、後日、ダミーの個人情報にて示される連絡先に何らかの連絡があった場合に、個人情報等が流出していることが推認でき、また、その流出に関与したと思われるエージェントを特定することができる。
ここでは、検索対象のＤＢを顧客ＤＢとし、本実施の形態が適用される２つのモデルについて説明する。
【００１６】
第１のモデルは、顧客ＤＢから流出した顧客データに基づきダイレクトメール(以下、「ＤＭ」という)が発送された場合に、顧客データを流出させたであろうエージェントを特定するものである。
図１は、このモデルの全体イメージを示した図である。
図１に示すように、情報流出元特定システム１０に対する入力としては、一般顧客データを格納する一般顧客ＤＢ１１が存在する。ここで、一般顧客データとは、この情報流出元特定システム１０が設置された企業が保有する本物の顧客データである。一般顧客データは、例えば、顧客ＩＤ、氏名、住所、電話番号、その他のプロファイル情報を含んでいる。
【００１７】
また、情報流出元特定システム１０は、ダミー顧客ＤＢ１２と、ＤＢアクセス監視装置１３と、使用履歴記憶部１４と、検証装置１５とを備える。
ダミー顧客ＤＢ１２は、一般顧客データと同じフォーマットを持つダミーデータを格納するＤＢである。図２に、ダミー顧客ＤＢ１２の記憶内容の一例を示す。この例において、ダミーデータは、一般顧客とは別に存在するダミー顧客についてのデータであるとする。即ち、図２における顧客ＩＤ「１００００１」は、ダミー顧客のために確保されたＩＤであり、一般顧客に対しては用いられないものとする。なお、ダミー顧客には、自身で情報流出元特定システム１０を運営する企業であれば、その企業の社員を割り当てればよい。あるいは、顧客名簿全体を預かるデータセンタソリューションを提供するサービス事業者が情報流出元特定システム１０を運営する場合は、そのような事業者が、ダミー顧客も提供するようにすればよい。
【００１８】
また、図２に示すように、ダミーデータとしては、同じ顧客ＩＤに対し、複数のバリエーションを用意する。
具体的には、このモデルでは、ダミー顧客の氏名および/または住所を微妙に変更している(以下、このような微妙な変更を「揺らぎ」と呼ぶ)。それは、このモデルが、ダミー顧客に送付されたＤＭに記載された氏名および/または住所を手がかりとして、そのダミー顧客のデータを含む顧客データを流出させたエージェントを特定するものであるからである。ただし、ＤＭがダミー顧客に間違いなく送付されることが必要なので、氏名および/または住所に対する変更は、郵便の配達に支障を与えない範囲で行うこととする。
【００１９】
例えば、氏名に揺らぎを持たせる場合であれば、姓には変更を加えず、名を平仮名に変更したり、名の中の一字を同じ読みの別の字に変更したりすることが考えられる。なお、図２に示したものは、日本語の名前の例であるが、英語の名前であれば、「alex」を「alexander」とするようなシノニムの使用も考えられる。
また、住所に揺らぎを持たせる場合であれば、住所の屋号、気付等を適宜変更したり、付加したりすることが考えられる。屋号、気付等は、住民票にも登記されない私的なものなので、どのように書いても郵便としては問題なく配達されるからである。
【００２０】
ところで、氏名および/または住所に揺らぎを持たせる作業は、逐一手作業で行うことももちろん可能である。しかしながら、１人のダミー顧客に対して多くのバリエーションを用意することとなると、そのような作業には多大な工数が必要となってしまう。
そこで、図３に示すように氏名、住所のそれぞれについて、幾つかのパターンを用意しておき、それらのパターンを組み合わせることで、多量のダミーデータを作成するようにしてもよい。
【００２１】
例えば、図３(ａ)に示すように、氏名について４つのパターンを用意し、図３(ｂ)に示すように、住所について４つのパターンを用意する。このように氏名、住所それぞれについて４つのパターンを手作業で作成すれば、それらから１６(＝４×４)のダミーデータを自動作成することができる。また、それぞれが１００パターンあれば、１万(＝１００×１００)のダミーデータを作成可能である。
なお、図２における１行目、２行目、３行目、４行目は、それぞれ、図３(ａ)のパターン１と図３(ｂ)のパターン１との組み合わせ、図３(ａ)のパターン２と図３(ｂ)のパターン２との組み合わせ、図３(ａ)のパターン３と図３(ｂ)のパターン３との組み合わせ、図３(ａ)のパターン４と図３(ｂ)のパターン４との組み合わせに相当する。
【００２２】
また、図３(ｂ)に示した住所の屋号等の変更は、手作業で行ってもよいが、屋号等を自動的に作成するソフトウェア(屋号自動ジェネレータ)を用いて行うことも可能である。この場合、図４に示すように、前置、中置、後置に分けて、屋号等として考えられるワードを定義しておき、これらを適宜組み合わせることで屋号等を生成する。この例では、屋号自動ジェネレータにより、「マイレジデンス下北沢」、「グランカーサ三番館」、「クレセントパレス」等の屋号を自動生成することが可能である。
【００２３】
このようにしてダミー顧客ＤＢ１２にダミーデータが用意された状態で、エージェントが、エージェントＩＤおよび使用目的等を入力して顧客データの検索を要求したとする。これにより、ＤＢアクセス監視装置１３は、一般顧客ＤＢ１１から検索された一般顧客データにダミーデータを微量混入してエージェントに対し出力する。具体的には、エージェントが指定した検索条件に合致するプロファイル情報を持つダミー顧客を特定し、そのダミー顧客について作成された複数のバリエーションの中から１つのバリエーションを選択して混入する。つまり、ＳＱＬ文における"SELECT * FROM USERTABLE"のような一括表示コマンドを受けた場合に、検索要求ごとに異なったバリエーションを表示するのである。こうすることにより、各検索結果において、データの総数は変わらず、かつ、データのキー項目においても違いがないが、そのデータの中身は微妙に異なっている、という状況を作り上げることができるのである。
【００２４】
また、これと同時に、ＤＢアクセス監視装置１３は、どのエージェントに対しどのダミーデータを出力したかの履歴を使用履歴記憶部１４に記憶する。図５に、使用履歴記憶部１４の記憶内容の一例を示す。図５は、図２における１行目、２行目、３行目のダミーデータが、それぞれ、エージェントＩＤ「ａｇｅｎｔ１」、「ａｇｅｎｔ２」、「ａｇｅｎｔ３」のエージェントに対し出力された場合の例である。なお、使用履歴記憶部１４には、図５に示すもの以外に、各ダミーデータが出力された日時や、その出力に際して使用された端末のＩＤ等の情報を含むようにしてもよい。
【００２５】
一方、ダミーデータを微量含む顧客データを入手したエージェントが、そのデータを不正に流出し、ＤＭ会社に持ち込んだとする。そして、ＤＭ会社において、持ち込まれた顧客データから顧客の絞込みを行い、各顧客に対しＤＭを発送したとする。その結果、ダミー顧客に対してＤＭが送られてきたとすると、ダミー顧客は、検証者にＤＭが送られてきた旨を報告する。これにより、検証者は、検証装置１５を用いて使用履歴記憶部１４の内容を検証し、顧客データの流出に関与したエージェントのエージェントＩＤを特定する。
【００２６】
また、第２のモデルは、顧客ＤＢから流出した顧客データに基づき勧誘電話がかかってきた場合に、顧客データを流出させたであろうエージェントを特定するものである。近年、マーケティングの主流はＤＭから電話へと移ってきており、勧誘電話をトリガーとした情報流出元の特定は、このような流れにも対応するものである。
図６は、このモデルの全体イメージを示した図である。
図６においても、図１と同様、情報流出元特定システム１０に対する入力として、一般顧客データを格納する一般顧客ＤＢ１１が存在する。ここで、一般顧客データとは、この情報流出元特定システム１０が設置された企業が保有する本物の顧客データである。一般顧客データは、例えば、顧客ＩＤ、氏名、住所、電話番号、その他のプロファイル情報を含んでいる。
【００２７】
また、情報流出元特定システム１０は、ダミー顧客ＤＢ１２と、ＤＢアクセス監視装置１３と、使用履歴記憶部１４と、検証装置１５とを備える。
ダミー顧客ＤＢ１２は、一般顧客データと同じフォーマットを持つダミーデータを格納するＤＢである。図７に、ダミー顧客ＤＢ１２の記憶内容の一例を示す。この例において、ダミーデータは、一般顧客とは別に存在するダミー顧客についてのデータであるとする。即ち、図７における顧客ＩＤ「１００００２」は、ダミー顧客のために確保されたＩＤであり、一般顧客に対しては用いられないものとする。なお、ダミー顧客には、自身で情報流出元特定システム１０を運営する企業であれば、その企業の社員を割り当てればよい。あるいは、顧客名簿全体を預かるデータセンタソリューションを提供するサービス事業者が情報流出元特定システム１０を運営する場合は、そのような事業者が、ダミー顧客も提供するようにすればよい。
【００２８】
また、図７に示すように、ダミーデータとしては、同じ顧客ＩＤに対し、複数のバリエーションを用意する。
具体的には、このモデルでは、ダミー顧客の電話番号を異ならせている。その場合、第１のモデルのように電話番号に揺らぎを持たせるのではなく、それぞれ正規に取得した電話番号を用いるようにする。つまり、第１のモデルでは、住所が高価な資源であり、ダミー顧客１人当たりの運用コストが高くなってしまうため、住所に揺らぎを持たせて再利用することが必要であったが、この第２のモデルでは、電話番号が極めて安価に取得できるため、そのような再利用を行う必要はない。
【００２９】
また、個人と住所との関連性は、１対１の対応が１０年程度は続く密なものであるのに対し、個人と電話番号との関連性は、１対３程度の対応が一般的な疎なものである。例えば、各個人の電話番号には、会社の電話番号もあれば、家庭の電話番号もある。また、近年、多くの人が携帯電話も所有している。携帯電話については、１人で２台以上所有するケースもあるし、２年程度で電話番号を変更することもある。そういった意味でも、ダミー顧客に対し、電話番号を異ならせてバリエーションを作成しておくことは、このシステムのしかけを見破られ難くするための自然な方法とも考えられる。
【００３０】
そして、このモデルでは、ダミーデータに設定した電話番号にかかってきた電話の全てに対し、例えば、東日本電信電話株式会社等が提供する「ダイヤルインサービス」を用いて、一箇所で対応できるような環境を構築しておく。「ダイヤルインサービス」は、平成１６年１月１５日現在、一番号につき月額８００円と安価であり、ダミー顧客を実際に配備するのに比べて、コストを安く抑えることが可能である。
【００３１】
なお、このような全ての電話に対する一括対応は、ダミー顧客を実在の人物と連動させずに、仮想化することを意味する。第１のモデルのようにダミー顧客を実際に配備した場合、そのダミー顧客は、このシステムの構成員であるので、全体を知らないとしても、機密に関与することにはなる。また、ダミー顧客のプライバシーが確実に保護されるのかという点でも問題は残る。これに対し、この第２のモデルのような方法を採れば、そのような問題はなくなる。このモデルは、このようにダミー顧客を仮想化するものであるので、住所としては、現実に存在しないものを記述しておくこととする。
【００３２】
このようにしてダミー顧客ＤＢ１２にダミーデータが用意された状態で、エージェントが、エージェントＩＤおよび使用目的等を入力して顧客データの検索を要求したとする。これにより、ＤＢアクセス監視装置１３は、一般顧客ＤＢ１１から検索された一般顧客データにダミーデータを微量混入してエージェントに対し出力する。具体的には、エージェントが指定した検索条件に合致するプロファイル情報を持つダミー顧客を特定し、そのダミー顧客について作成された複数のバリエーションの中から１つのバリエーションを選択して混入する。つまり、ＳＱＬ文における"SELECT * FROM USERTABLE"のような一括表示コマンドを受けた場合に、検索要求ごとに異なったバリエーションを表示するのである。こうすることにより、各検索結果において、データの総数は変わらず、かつ、データのキー項目においても違いがないが、そのデータの中身は微妙に異なっている、という状況を作り上げることができるのである。
【００３３】
また、これと同時に、ＤＢアクセス監視装置１３は、どのエージェントに対しどのダミーデータを出力したかの履歴を使用履歴記憶部１４に記憶する。図８に、使用履歴記憶部１４の記憶内容の一例を示す。図８は、図７における１行目、２行目、３行目のダミーデータが、それぞれ、エージェントＩＤ「ａｇｅｎｔ１」、「ａｇｅｎｔ２」、「ａｇｅｎｔ３」のエージェントに対し出力された場合の例である。なお、使用履歴記憶部１４には、図８に示すもの以外に、各ダミーデータが出力された日時や、その出力に際して使用された端末のＩＤ等の情報を含むようにしてもよい。
【００３４】
一方、ダミーデータを微量含む顧客データを入手したエージェントが、そのデータを不正に流出し、テレマーケティング会社に持ち込んだとする。そして、テレマーケティング会社において、持ち込まれた顧客データから顧客の絞込みを行い、テレマーケティング員が、各顧客に対しアウトバウンドコールを行ったとする。その結果、ダミー顧客に対する勧誘電話が、「ダイヤルインサービス」によって捕捉され、モニタ室にかかってくる。
【００３５】
モニタ室では、流出検出員として、例えば、男女各一名が待機し、対応にあたる。ここでは、例えば、次のような会話が想定される。
テレマーケティング員：「斉藤さんのお宅でしょうか。」
流出検出員(男性)：「はい、そうです。」
テレマーケティング員：「花子さんお願いします。」
流出検出員(男性)：「はい、代わります。」
ここで、モニタ室では、男性と女性が入れ替わる。
流出検出員(女性)：「代わりました。花子です。」
ここまでで情報収集は完了するが、その後、会話を引き伸ばして、テレマーケティング会社の情報を引き出してもよい。
【００３６】
また、その際、この会話は通話記録に残しておき、どの電話番号に電話がかかってきたかの情報も採取しておくこととする。上記の例では、「０３−１２３４−５６７８」に電話がかかってきたことが記録として残っているとすれば、「０３−１２３４−５６７８の斉藤花子宛て電話があった」ことが、重要な証拠となる。これにより、検証者は、検証装置１５を用いて使用履歴記憶部１４の内容を検証し、顧客データの流出に関与したエージェントのエージェントＩＤを特定する。
なお、コールセンターのエージェントに対しては、一般に、スーパバイザがその応対の品位等をモニタしている。そこで、スーパバイザが、このような流出検出員としての役割も持つようにすることにより、人件費を削減することも可能である。
【００３７】
また、以上では、ＤＭの受け取りを契機に個人情報の流出元を特定するためのダミーデータ(ＤＭタイプのダミーデータ)を用いる第１のモデルと、電話がかかってきたことを契機に個人情報の流出元を特定するためのダミーデータ(電話タイプのダミーデータ)を用いる第２のモデルとを、別々のケースとして説明した。しかしながら、ＤＭタイプのダミーデータと電話タイプのダミーデータとを併用することも可能である。このような態様は、ダミーデータを取り除くことが不可能な最も強力なものである。即ち、その態様では、全ての顧客にＤＭを発送することによりダミー顧客を排除しようとしても、そのＤＭに記載した氏名、住所によって個人情報の流出元が特定されることとなる。一方、全ての顧客に電話をかけることにより該当する顧客が実在するかどうかを確かめようとすれば、その電話がモニタ室にかかり、個人情報の流出元が特定されることとなる。
【００３８】
なお、これらのモデルの実装上の注意点としては、名寄せシステムがある場合に、ダミーデータは、あくまでもその後の工程で混入させなければならないということがある。複数の顧客ＤＢを名寄せすることにより一般顧客ＤＢ１１が生成されるような場合、ダミーデータにおける複数のバリエーションが１つに集約されてしまうからである。名寄せシステムの後工程で混入させることとし、エージェントに対して、あたかも名寄せによって住所等の表記が揺らいだような感じに見せ、このシステムの動作に疑念を抱かせないようにする必要がある。
【００３９】
ところで、これらのモデルで顧客データに混入するダミーデータにおいては、例えば、図９に示すように、意図的にプロファイル(個人の特性を含む)を分散させることが望ましい。これにより、顧客データの流出先の業者が、どの地域をターゲットとしていても、また、どのような業種であっても、絞込み後の顧客データの中に必ずダミーデータが残ることとなる。図９では、住所、収入、結婚、子供、居住形態について、プロファイルを分散させてある。従って、結婚仲介サービス、葬儀屋、消費者金融清算サービス、塾等のどのような業者に使われた場合であっても、いずれかのダミー顧客に連絡が来るようになっている。
【００４０】
次に、本実施の形態の情報流出元特定システム１０における中核部分であるＤＢアクセス監視装置１３について、詳細に説明する。
図１０は、ＤＢアクセス監視装置１３を実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
図１０に示すコンピュータ装置は、演算手段であるＣＰＵ(Central Processing Unit：中央処理装置)２１と、Ｍ/Ｂ(マザーボード)チップセット２２およびＣＰＵバスを介してＣＰＵ２１に接続されたメインメモリ２３と、同じくＭ/Ｂチップセット２２およびＡＧＰ(Accelerated Graphics Port)を介してＣＰＵ２１に接続されたビデオカード２４と、ＰＣＩ(Peripheral Component Interconnect)バスを介してＭ/Ｂチップセット２２に接続された磁気ディスク装置(ＨＤＤ)２５、ネットワークインターフェイス２６、および、他の機器との間で赤外線通信を行うための赤外線ポート３０と、このＰＣＩバスからブリッジ回路２７およびＩＳＡ(Industry Standard Architecture)バス等の低速なバスを介してＭ/Ｂチップセット２２に接続されたフロッピー(登録商標)ディスクドライブ２８およびキーボード/マウス２９とを備える。
【００４１】
なお、図１０は、本実施の形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施の形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード２４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ２１にてイメージデータを処理する構成としても良いし、外部記憶装置として、ＡＴＡ(AT Attachment)やＳＣＳＩ(Small Computer System Interface)等のインターフェイスを介してＣＤ−Ｒ(Compact Disc Recordable)やＤＶＤ−ＲＡＭ(Digital Versatile Disc Random Access Memory)のドライブを設けてもよい。
【００４２】
また、磁気ディスク装置２５には、本実施の形態における各機能を実現するコンピュータプログラムが記憶される。ＣＰＵ２１がこのコンピュータプログラムをメインメモリ２３に読み出して実行することにより、後述する本実施の形態の各機能が実現されることになる。なお、このコンピュータプログラムは、システムの出荷に先立って磁気ディスク装置２５に記憶されたものであってもよいし、システムの出荷後、ユーザが磁気ディスク装置２５にインストールしたものであってもよい。インストールの方法としては、サーバコンピュータから有線通信または無線通信によりダウンロードする方法や、ＣＤ−ＲＯＭ等の記録媒体を用いる方法等が考えられる。
【００４３】
次に、図１１を参照して、本実施の形態におけるＤＢアクセス監視装置１３の機能について説明する。
図１１に示すように、ＤＢアクセス監視装置１３は、制御部１３０と、検索要求取得部１３１と、検索処理部１３２と、検索結果出力部１３３と、使用履歴作成部１３４とを備えている。
【００４４】
制御部１３０は、検索要求取得部１３１、検索処理部１３２、検索結果出力部１３３、使用履歴作成部１３４の各部を制御する部分である。
検索要求取得部１３１は、エージェントＩＤを含むＤＢの検索要求を取得する部分である。
検索処理部１３２は、一般顧客ＤＢ１１、ダミー顧客ＤＢ１２、使用履歴記憶部１４を検索し、ダミーデータを含む検索結果を作成する部分である。
検索結果出力部１３３は、ダミーデータを含む検索結果をエージェントに対して出力する部分である。
使用履歴作成部１３４は、どのダミーデータをどのエージェントに対して出力したかの履歴を作成し、使用履歴記憶部１４に出力する部分である。
【００４５】
次に、図１２を参照して、本実施の形態の動作について、詳細に説明する。
まず、検索要求取得部１３１が、エージェントＩＤ、ＤＢ名、検索条件を含む検索要求を取得し、制御部１３０に受け渡す(ステップ１０１)。これにより、制御部１３０は、エージェントＩＤ、ＤＢ名、検索条件をパラメータとして、検索処理部１３２に顧客データの検索を指示する。
【００４６】
この指示を受けた検索処理部１３２は、まず、一般顧客ＤＢ１１を検索する。そして、その検索結果をメモリ上の検索結果格納領域に格納すると共に、ヒット件数をＮに代入する(ステップ１０２)。
その際、検索処理部１３２は、Ｎが予め設定された基準件数以上かどうかを判定する(ステップ１０３)。ここで、Ｎが基準件数以上でなければ、そのまま検索結果を表示し(ステップ１０８)、Ｎが基準件数以上であれば、ダミーデータを混入させる処理に進む。なお、ここで、基準件数以上であるかどうかを判定するのは、小規模な抽出操作には反応させないことで、ダミーデータの露出度を下げる(混入を目立たせないようにする)ためである。
【００４７】
ダミーデータを混入させる場合、検索処理部１３２は、使用履歴記憶部１４を検索し、その検索結果をメモリ上の検索結果格納領域に追加すると共に、ヒット件数をＭに代入する(ステップ１０２)。
なお、ここでの検索方法としては、次のようなものが考えられる。
第１に、使用履歴記憶部１４に記憶されたダミーデータのうち、制御部１３０から渡されたエージェントＩＤに対応付けられたダミーデータの中から、検索条件に合致するものを検索する方法である。この検索方法の意義について、図１３(ａ)に示す。即ち、この検索方法は、特定のエージェントが時間を違えて同じ検索条件で検索した場合に、同じダミーデータを見せるようにするものである。
【００４８】
また、第２に、使用履歴記憶部１４に記憶されたダミーデータのうち、制御部１３０から渡されたエージェントＩＤ、または、そのエージェントＩＤとの関係が予め定義された他のエージェントＩＤに対応付けられたダミーデータの中から、検索条件に合致するものを検索する方法である。この検索方法の意義について、図１３(ｂ)に示す。
例えば、親会社が保有する名簿の管理業務を、子会社Ａ、Ｂ、Ｃに委託したとする。
この場合、子会社Ａの社員が、同じ検索条件で検索した結果を互いに見せ合うと、ダミーデータが特定されてしまう虞があるので、ダミー顧客Ｘについてのデータを子会社Ａの社員に見せる場合には、同じデータ内容のダミーデータＸとして見せることとする。
また、子会社Ａの電話部門の構成員が、同じ検索条件で検索した結果を互いに見せ合うと、ダミーデータが特定されてしまう虞があるので、ダミー顧客Ｙについてのデータを子会社Ａの電話部門の構成員に見せる場合には、同じデータ内容のダミーデータＹとして見せることとする。ただし、子会社Ａの電話部門の構成員と子会社Ｂの社員が、同じ検索条件で検索した結果を互いに見せ合うことはないと考えられるので、子会社Ｂには、ダミーデータＹ’として見せることを許容する。なお、子会社Ａの発送部門と子会社Ｃについても、同様である。
【００４９】
このような検索処理の際、検索処理部１３２は、(Ｍ/Ｎ)が予め設定された基準混合率を超えているかどうかを判定する(ステップ１０５)。ここで、(Ｍ/Ｎ)が基準混合率以上であれば、そのまま検索結果を表示し(ステップ１０８)、(Ｍ/Ｎ)が基準混合率以上でなければ、さらにダミーデータを混入させる処理に進む。なお、ここで、基準混合率以上であるかどうかを判定するのは、ダミーデータを必要以上に混ぜることなく、目的を達成できるようにするためである。過去の個人情報流出事件では、１０００件が流出の最小単位であるので、基準混合比を(１/１０００)程度に設定しておけば、目的を達成することができる。
【００５０】
さらにダミーデータを混入させる場合、検索処理部１３２は、ダミー顧客ＤＢ１２を検索し、その検索結果をメモリ上の検索結果格納領域に追加する(ステップ１０６)。なお、ここでは、ダミーデータを、その割合が基準混合比に達するまで補えばよいので、(Ｎ×基準混合率−Ｍ)件のダミーデータを検索する。また、ダミーデータとして混入することが決定された顧客ＩＤに対し、予め作成された複数のバリエーションの中からまだ使用されていない１つのバリエーションを選択して検索結果に含めることとする。
そして、検索処理部１３２は、ダミーデータが混入された検索結果を制御部１３０に返却する。
【００５１】
一方、制御部１３０は、エージェントＩＤと、検索結果格納領域に格納された検索結果のうちのダミーデータとを使用履歴作成部１３４に受け渡し、使用履歴作成部１３４が、これらを対応付けた使用履歴を作成し、使用履歴記憶部１４に出力する(ステップ１０７)。
また、制御部１３０は、ダミーデータが混入された検索結果を検索結果出力部１３３に受け渡し、検索結果出力部１３３が、この検索結果をエージェントが使用する端末装置の画面に表示する(ステップ１０８)。
【００５２】
以上により、本実施の形態におけるＤＢアクセス監視装置１３の動作は終了する。
ところで、以上の動作では、ダミーデータを検索結果に混入させる際の工夫として、次の(Ａ)〜(Ｄ)を行っていた。
(Ａ)検索結果中のダミーデータの割合(混合比)を一定にする。
(Ｂ)検索結果に含まれるデータの件数が一定量以上の場合にダミーデータを混合する。
(Ｃ)特定のエージェントが時間を違えて同じ検索条件で検索しても同じダミーデータが見えるようにする。
(Ｄ)特定の組織に属する異なるエージェントが同じ条件で検索した場合に同じダミーデータが見えるようにする。
【００５３】
ただし、これらの工夫は、それぞれ単独でも意味をなすものである。従って、これらの工夫の全てを必ずしも実現しなくてもよい。即ち、図１２に示したものは、ＤＢアクセス監視装置１３の動作の一例であり、ＤＢアクセス監視装置１３は、これらの工夫を実現するための如何なる動作をも行い得る。
また、使用履歴としては、エージェントＩＤとダミーデータそのものとの対応を記録するのではなく、エージェントＩＤとダミーデータの識別情報との対応を記録するようにしてもよい。ここで、ダミーデータの識別情報とは、ダミー顧客を一意に識別する顧客ＩＤではなく、ダミー顧客について作成した複数のバリエーションを一意に識別するバリエーションＩＤのことをいう。
さらに、図１３(ｂ)を参照して説明した考え方に基づき、例えば、子会社Ａの電話部門と子会社Ｂのように結託する可能性のないグループについては、同一電話番号の再利用を許容するようにすることもできる。
【００５４】
また、本実施の形態の情報流出元特定システム１０におけるもう１つの中核部分である検証装置１５を実現するのに好適なコンピュータ装置のハードウェア構成も、図１０に示したものと同様である。
検証装置１５においても、磁気ディスク装置２５には、本実施の形態における各機能を実現するコンピュータプログラムが記憶される。そして、ＣＰＵ２１がこのコンピュータプログラムをメインメモリ２３に読み出して実行することにより、本実施の形態の各機能が実現されることになる。このコンピュータプログラムは、システムの出荷に先立って磁気ディスク装置２５に記憶されたものであってもよいし、システムの出荷後、ユーザが磁気ディスク装置２５にインストールしたものであってもよい。インストールの方法としては、サーバコンピュータから有線通信または無線通信によりダウンロードする方法や、ＣＤ−ＲＯＭ等の記録媒体を用いる方法等が考えられる。
なお、検証装置１５の機能としては、検証者からダミー顧客の氏名、住所、電話番号等の情報を取得する機能と、その取得した情報に基づき使用履歴記憶部１４を検索してエージェントＩＤを特定する機能と、そのエージェントＩＤを検証者に対して出力する機能とがある。
【００５５】
ところで、上述した実施の形態では、一般顧客とは別にダミー顧客を用意した。特に、データセンタソリューションとしてサービスを提供する場合、このような方法は、ユーザ企業に対し秘匿性が高い点をアピールでき、サービスとしての価値を高めることができる。しかしながら、事前に同意のあった一般顧客にダミー顧客としての役割も担ってもらうことも可能である。その場合、ＳＱＬにおけるselect文の後段にstored procedureなりを組み込み、その同意のあった一般顧客のデータが抽出された場合に、予め定義されたルールに従い、氏名および/または住所の表記、あるいは、電話番号を自動変更するようにする。
【００５６】
以上述べたように、本実施の形態では、データベースの検索結果にダミーデータを混入し、その検索を行ったエージェントのエージェントＩＤとそのダミーデータとの対応を記録しておくようにしている。これにより、個人情報等が外部に流出した場合にその流出元を特定することが可能となっている。
【図面の簡単な説明】
【００５７】
【図１】本実施の形態が適用される第１のモデルの全体イメージを示した図である。
【図２】本実施の形態が適用される第１のモデルにおいて用いられるダミー顧客ＤＢの内容の一例を示した図である。
【図３】本実施の形態が適用される第１のモデルにおけるダミー顧客ＤＢを作成する際に使用されるテーブルの内容を示した図である。
【図４】本実施の形態が適用される第１のモデルにおけるダミー顧客ＤＢを作成する際に使用されるテーブルの内容を示した図である。
【図５】本実施の形態が適用される第１のモデルにおいて出力される使用履歴の一例を示した図である。
【図６】本実施の形態が適用される第２のモデルの全体イメージを示した図である。
【図７】本実施の形態が適用される第２のモデルにおいて用いられるダミー顧客ＤＢの内容の一例を示した図である。
【図８】本実施の形態が適用される第２のモデルにおいて出力される使用履歴の一例を示した図である。
【図９】本実施の形態におけるダミーデータのプロファイル分散について説明するための図である。
【図１０】本実施の形態におけるＤＢアクセス監視装置および検証装置のハードウェア構成を示したブロック図である。
【図１１】本実施の形態におけるＤＢアクセス監視装置の機能を示したブロック図である。
【図１２】本実施の形態におけるＤＢアクセス監視装置の処理動作を示すフローチャートである。
【図１３】本実施の形態におけるＤＢアクセス監視装置の動作上の工夫について説明するための図である。
【符号の説明】
【００５８】
１０…情報流出元特定システム、１１…一般顧客ＤＢ、１２…ダミー顧客ＤＢ、１３…ＤＢアクセス監視装置、１３０…制御部、１３１…検索要求取得部、１３２…検索処理部、１３３…検索結果出力部、１３４…使用履歴作成部、１４…使用履歴記憶部、１５…検証装置
【図１】
2005222135.tif 000003
【図２】
2005222135.tif 000004
【図３】
2005222135.tif 000005
【図４】
2005222135.tif 000006
【図５】
2005222135.tif 000007
【図６】
2005222135.tif 000008
【図７】
2005222135.tif 000009
【図８】
2005222135.tif 000010
【図９】
2005222135.tif 000011
【図１０】
2005222135.tif 000012
【図１１】
2005222135.tif 000013
【図１２】
2005222135.tif 000014
【図１３】
2005222135.tif 000015