(57)【特許請求の範囲】
【請求項１】
データを記憶するデータ記憶手段と、
前記データ記憶手段に記憶された前記データを用いて所定の処理を行うデータ処理手段と、
前記データ記憶手段に記憶された前記データの読出し要求を前記データ処理手段から受けると、所定の基準を満足していることを条件とすることなく当該データを前記データ記憶手段から読み出し、さらに当該読み出されたデータのうちの特定のデータの受渡し要求を前記データ処理手段から受けると、当該受渡し要求が前記所定の基準を満足していることを条件に当該特定のデータを前記データ処理手段に受け渡すデータ保護手段と
を備えたことを特徴とするデータベースシステム。
【請求項２】
前記データ処理手段は、前記データ保護手段を介してのみ前記データ記憶手段にアクセスし、
前記データ保護手段は、前記データ記憶手段にアクセスするために必要なアクセス情報を保持し、前記データを前記データ記憶手段から読み出す際に、当該アクセス情報を用いて前記データ記憶手段にアクセスすることを特徴とする請求項１記載のデータベースシステム。
【請求項３】
前記データ保護手段は、前記データ記憶手段に記憶された前記データを読み出すための複数のデータベース操作文を保持し、前記データの読出し要求として、当該複数のデータベース操作文のうちの特定のデータベース操作文の選択を受けることに応答して、当該特定のデータベース操作文を用いて、当該データを前記データ記憶手段から読み出すことを特徴とする請求項１又は２に記載のデータベースシステム。
【請求項４】
前記データ保護手段は、前記データ記憶手段に記憶された前記データを読み出すために必要な複数の情報を保持し、前記データの読出し要求として、当該複数の情報のうちの特定の情報の選択およびパラメータの入力を受けることに応答して、当該特定の情報と当該パラメータとに基づきデータベース操作文を組み立て、当該データベース操作文を用いて、当該データを前記データ記憶手段から読み出すことを特徴とする請求項１乃至３のいずれかに記載のデータベースシステム。
【請求項５】
前記データ記憶手段に記憶された前記データは、保護対象であるデータと保護対象でないデータとを含み、
前記データ保護手段は、前記特定のデータの受渡し要求を前記データ処理手段から受けることに応答して、当該特定のデータが保護対象である場合に当該受渡し要求が前記所定の基準を満足しているかどうかを判定することを特徴とする請求項１乃至４のいずれかに記載のデータベースシステム。
【請求項６】
前記データ保護手段は、前記特定のデータの受渡し要求を前記データ処理手段から受けることに応答して、当該特定のデータの所有者を特定し、当該受渡し要求が前記所定の基準を満足しているかどうかを当該所有者の情報を用いて判定することを特徴とする請求項１乃至５のいずれかに記載のデータベースシステム。
【請求項７】
前記データ保護手段は、前記特定のデータの受渡し要求を前記データ処理手段から受けることに応答して、当該特定のデータを前記データ処理手段に受け渡してよいかどうかを判定するための基準を管理する他のコンピュータに対して当該受渡し要求に関する情報を送信し、当該他のコンピュータからの応答に基づき、当該受渡し要求が当該基準を満足しているかどうかを判定することを特徴とする請求項１乃至６のいずれかに記載のデータベースシスム。
【請求項８】
前記データ保護手段は、前記受渡し要求が前記所定の基準を満足していない場合に、前記データ処理手段に対し、その旨の応答を返却することを特徴とする請求項１乃至７のいずれかに記載のデータベースシステム。
【請求項９】
データベースに記憶されたデータを使用する第１のコンピュータと、当該データの使用に関する基準を管理する第２のコンピュータとを備え、
前記第１のコンピュータは、前記基準に基づくことなく前記データベースに記憶された前記データを読み出し、当該読み出されたデータのうちの特定のデータを使用する時点で、当該使用に関する情報を前記第２のコンピュータに送信し、
前記第２のコンピュータは、前記使用に関する情報を受けることに応答して、前記基準に基づき、前記第１のコンピュータが前記特定のデータを使用してよいかどうかを判定し、その結果を前記第１のコンピュータに返信し、
前記第１のコンピュータは、前記特定のデータを使用してよい旨の情報を前記第２のコンピュータから受けることに応答して、当該特定のデータを使用することを特徴とする情報取得可否検査システム。
【請求項１０】
前記第１のコンピュータは、前記データベースに記憶された前記データの読出し要求を所定のアプリケーションプログラムから受けることに応答して、前記基準に基づくことなく当該データを前記データベースから読み出し、当該読み出されたデータのうちの特定のデータの受渡し要求を当該アプリケーションプログラムから受けることに応答して、当該受渡し要求に関する情報を前記第２のコンピュータに送信し、
前記第２のコンピュータは、前記受渡し要求に関する情報を受けることに応答して、前記基準に基づき、前記アプリケーションプログラムに前記特定のデータを受け渡してよいかどうかを判定し、その結果を前記第１のコンピュータに返信し、
前記第１のコンピュータは、前記第２のコンピュータから返信された結果に応じて、前記アプリケーションプログラムに前記特定のデータを受け渡すことを特徴とする請求項９記載の情報取得可否検査システム。
【請求項１１】
中央演算処理装置とデータベースとアプリケーションプログラムとを備えるコンピュータ・システムにより実行される方法であり、
前記中央演算処理装置が、前記データベースに記憶されたデータの読出し要求を前記アプリケーションプログラムから受けることに応答して、所定の基準を満足していることを条件とすることなく当該データを前記データベースから読み出すステップと、
前記中央演算処理装置が、前記読み出されたデータのうちの特定のデータの受渡し要求を前記アプリケーションプログラムから受けることに応答して、当該受渡し要求が前記所定の基準を満足しているかどうかを判定するステップと、
前記中央演算処理装置が、前記受渡し要求が前記所定の基準を満足していると判定された場合に、前記特定のデータを前記アプリケーションプログラムに受け渡すステップと
を含むことを特徴とする情報取得方法。
【請求項１２】
コンピュータに、
データベースに記憶されたデータの読出し要求をアプリケーションプログラムから受けることに応答して、所定の基準を満足していることを条件とすることなく当該データを前記データベースから読み出す機能と、
前記読み出されたデータのうちの特定のデータの受渡し要求を前記アプリケーションプログラムから受けることに応答して、当該受渡し要求が前記所定の基準を満足しているかどうかを判定する機能と、
前記受渡し要求が前記所定の基準を満足していると判定された場合に、前記特定のデータを前記アプリケーションプログラムに受け渡す機能と
を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、データベース（以下、「ＤＢ」という）に格納された情報へのアプリケーションプログラム（以下、「アプリケーション」という）によるアクセスが所定の基準を満足しているかどうかを判定する機能を有するデータベースシステム等に関する。
【背景技術】
【０００２】  個人情報のような機密性の高い情報については、その公開を許可するかどうかについて、個人情報保護ポリシー（例えば、Ｐ３Ｐポリシー、以下、単に「ポリシー」ともいう）のような基準が設けられる場合がある。ＤＢに格納された情報がこのような基準により保護されている場合、その情報に対してアプリケーションからアクセスがあると、情報をアプリケーションに受け渡す前にそのアクセスが基準を満たしているかどうかの判定を行い、基準を満たしている場合にのみ情報を受け渡すように構成することができる。従来、このようなアクセスが基準を満たしているかどうかの判定は、ＤＢに格納された情報に対して物理的にアクセスがあった時点で行っていた（例えば、非特許文献１参照。）。【０００３】  非特許文献１には、個人情報の保護のために、個人情報に対するアクセスが個人情報保護ポリシーに準拠しているかどうかを判定する手法が記載されているが、その具体的な手順は次の通りである。
即ち、まず、アプリケーションは、通常と同じ手順でＤＢコネクションを取得し、ＤＢに対してＳＱＬを発行する。ＤＢにはポリシー準拠のためのロジックが設けられており、ここでＳＱＬはポリシーに準拠したものに書き換えられる。つまり、書き換えられたＳＱＬを実行すると、ポリシーに準拠している情報のみがクエリ結果として取得できるようになる。アプリケーションには、そのクエリ結果がそのまま渡され、ポリシーに準拠しない個人情報はアプリケーションに渡されないようになっている。【０００４】
【非特許文献１】Ｒａｋｅｓｈ  Ａｇｒａｗａｌ，Ｊｅｒｒｙ  Ｋｉｅｒｎａｎ，Ｒａｍａｋｒｉｓｈｎａｎ  Ｓｒｉｋａｎｔ，Ｙｉｒｏｎｇ  Ｘｕ：″Ｈｉｐｐｏｃｒａｔｉｃ  Ｄａｔａｂａｓｅｓ，″ｉｎ  ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｖｅｒｙ  Ｌａｒｇｅ  Ｄａｔａ  Ｂａｓｅｓ（ＶＬＤＢ）２００２：ｐｐ．１４３−１５４，Ｓｐｒｉｎｇｅｒ，２００２．
【発明の開示】
【発明が解決しようとする課題】
【０００５】  しかしながら、非特許文献１の技術では、アプリケーションにクエリ結果を受け渡す前に、アクセスされた全ての個人情報について、そのアクセスがポリシーに準拠しているか判定しなければならない。例えば、１０００人分の個人情報にアクセスがあった場合には、ポリシー準拠チェックを１０００人分行った後、クエリ結果をアプリケーションに受け渡す必要がある。従って、アプリケーションは全ての個人情報に対するポリシー準拠チェックが完了するまで待たされ、ＤＢアクセスのレスポンスが遅くなってしまうという問題点があった。
また、その際、アプリケーションが実際に使用しない個人情報までポリシー準拠チェックを行っている可能性がある。例えば、アプリケーションが１０００人分の個人情報にアクセスしたとしても、実際にアプリケーションが使用するのはそのうちの１００人分かもしれない。このような場合、９００人分の個人情報については、無駄にポリシー準拠チェックを行っていることになる。【０００６】  本発明は、以上のような技術的課題を解決するためになされたものであって、その目的は、ＤＢに格納された情報へのアプリケーションによるアクセスが所定の基準を満足しているかどうかを効率的に判定することにある。
【課題を解決するための手段】
【０００７】  かかる目的のもと、本発明は、データベースに格納された情報にアプリケーションがアクセスする際に、そのアクセスが所定の基準を満足しているかどうかの判定を、物理的にデータベースのレコードにアクセスがあった時点で行うのではなく、アプリケーションからアクセス結果の取得要求があった時点で行うようにしている。即ち、本発明のデータベースシステムは、保護対象のデータを記憶するデータ記憶手段と、このデータ記憶手段に記憶されたデータを用いて所定の処理を行うデータ処理手段と、データ記憶手段に記憶されたデータの読出し要求をデータ処理手段から受けると、そのデータをデータ記憶手段から読み出し、そのデータのうちの特定のデータの受渡し要求をデータ処理手段から受けると、その受渡し要求が所定の基準を満足していればその特定のデータをデータ処理手段に受け渡すデータ保護手段とを備えている。【０００８】  また、本発明は、データベースに格納された情報へのアクセスが所定の基準を満足しているかどうかの判定を、情報を使用する時点で、かつ、ポリシーサーバに問い合わせることで行うようにしている。即ち、本発明の情報取得可否検査システムは、データベースに記憶されたデータを使用する第１のコンピュータと、そのデータの使用に関する基準を管理する第２のコンピュータとを備え、第１のコンピュータは、データベースに記憶されたデータを読み出し、データのうちの特定のデータを使用する時点で、その使用に関する情報を第２のコンピュータに送信し、第２のコンピュータは、使用に関する情報を受けると、基準に基づき、第１のコンピュータがその特定のデータを使用してよいかどうかを判定し、その結果を第１のコンピュータに返信し、第１のコンピュータは、その特定のデータを使用してよい旨の情報を第２のコンピュータから受けると、その特定のデータを使用する。【０００９】  更に、本発明は、データベースからの情報を取得する際の情報取得方法として捉えることもできる。その場合、本発明の情報取得方法は、データベースに記憶されたデータの読出し要求をアプリケーションプログラムから受けると、そのデータをデータベースから読み出すステップと、読み出されたデータのうちの特定のデータの受渡し要求をアプリケーションプログラムから受けると、その受渡し要求が所定の基準を満足しているかどうかを判定するステップと、受渡し要求が所定の基準を満足していると判定された場合に、その特定のデータをアプリケーションプログラムに受け渡すステップとを含む。【００１０】  一方、本発明は、データベースからの情報を取得するための機能を実現するコンピュータプログラムとして捉えることもできる。その場合、本発明のプログラムは、コンピュータに、データベースに記憶されたデータの読出し要求をアプリケーションプログラムから受けると、そのデータをデータベースから読み出す機能と、読み出されたデータのうちの特定のデータの受渡し要求をアプリケーションプログラムから受けると、その受渡し要求が所定の基準を満足しているかどうかを判定する機能と、受渡し要求が所定の基準を満足していると判定された場合に、その特定のデータをアプリケーションプログラムに受け渡す機能とを実現���せるものである。
【発明の効果】
【００１１】  本発明によれば、ＤＢに格納された情報へのアプリケーションによるアクセスが所定の基準を満足しているかどうかを効率的に判定することが可能となる。
【発明を実施するための最良の形態】
【００１２】  以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。なお、本実施の形態では、保護対象の情報として「個人情報」を想定し、アクセスが満足すべき基準として「個人情報保護ポリシー」を想定する。【００１３】  本実施の形態は、「ＤＢの個人情報へのアクセス」と「アプリケーションによる個人情報の使用」とは別のタイミングである点に着目し、ポリシー準拠チェックを後者のタイミングで行う（遅延評価する）ことにより、問題を解決するものである。
具体的には、全ての個人情報に対するポリシー準拠チェックを行った後にクエリ結果をアプリケーションに返すのではなく、ポリシー準拠チェックの機能を持った「チェック機能つきクエリ結果」をアプリケーションに返す。アプリケーションは実際に個人情報を使うタイミングになった時点で、「チェック機能つきクエリ結果」に個人情報を要求し、「チェック機能つきクエリ結果」はこのタイミングでポリシー準拠チェックを行い、その結果に応じてアプリケーションに個人情報を返す。【００１４】  図１は、本実施の形態におけるデータベースシステムの全体構成を示した図である。
図１に示すように、このデータベースシステムは、アプリケーション１０と、個人情報ＤＢ２０と、ポリシーサーバ３０と、プライバシー保護モジュール４０とを備えている。【００１５】  アプリケーション１０は、個人情報ＤＢ２０に格納された個人情報を用いて、各種処理を行うプログラムである。例えば、個人情報ＤＢ２０から個人情報を検索して、その結果を画面に表示するようなプログラムが考えられる。
個人情報ＤＢ２０は、個人情報を格納するＤＢである。個人情報ＤＢ２０には、例えば、図２に示すようなデータが格納される。【００１６】  ポリシーサーバ３０は、個人情報保護ポリシーを管理し、ポリシー準拠のチェック要求があると、個人情報保護ポリシーに基づきポリシー準拠チェックを行い、その結果を返すサーバである。ポリシーサーバ３０では、例えば、図３に示すような個人情報保護ポリシーが管理されている。図３は、Ｐ３Ｐポリシーに基づくポリシー準拠チェックを行うためのものである。具体的には、東京の営業員が、営業活動目的である場合に限り、住所が東京都である者の名前、住所、電話番号にアクセス可能なことを示している。【００１７】  プライバシー保護モジュール４０は、個人情報ＤＢ２０に格納された個人情報の読出し要求をアプリケーション１０から受けた時点で個人情報を読み出し、その読み出した個人情報のうちの特定の個人情報の受渡し要求を受けた時点でポリシーサーバ３０に対してポリシー準拠チェックを依頼し、ポリシーに準拠している旨の応答があった場合にのみ、その特定の個人情報をアプリケーション１０に受け渡すプログラムである。なお、プライバシー保護モジュール４０は、図１では、アプリケーション１０と別個に設けられているが、アプリケーション１０の一部として機能するものであってもよい。
また、プライバシー保護モジュール４０は、制御部４１と、アクセス情報記憶部４２と、ＳＱＬ情報記憶部４３と、ＳＱＬ組立て部４４と、カラム特定部４５と、データベースアクセス部４６と、ポリシー準拠問合せ部４７と、問合せ結果記憶部４８とを含む。【００１８】  制御部４１は、アプリケーション１０に対する窓口となると共に、全体のフローを制御する部分である。例えば、プライバシー保護モジュール４０におけるアプリケーション窓口兼フロー制御のロジックに相当する。なお、アプリケーション１０から個人情報ＤＢ２０へのアクセスは、この部分を通じてのみ可能となっている。【００１９】  アクセス情報記憶部４２は、個人情報ＤＢ２０にアクセスするために必要な情報（以下、「アクセス情報」という）を記憶する部分である。アクセス情報としては、個人情報ＤＢ２０にアクセスするために必要となるユーザＩＤ、パスワードが例示される。これらの情報をプライバシー保護モジュール４０が管理するようにすることで、アプリケーション１０が自由に個人情報ＤＢ２０にアクセスできないようにしている。【００２０】  ＳＱＬ情報記憶部４３は、個人情報ＤＢ２０に発行して問題のないＳＱＬ文に関する情報（以下、「ＳＱＬ情報」という）を記憶する部分である。アプリケーション１０が独自にＳＱＬ文を組み立てて個人情報ＤＢ２０に発行できるようにすると、個人情報ＤＢ２０に記憶された情報を破壊するようなＳＱＬ文が発行されてしまう虞があるので、個人情報ＤＢ２０に発行しても問題のないＳＱＬ文を組み立てるために必要な情報をプライバシー保護モジュール４０が管理するようにしている。また、個人情報ＤＢ２０に発行しても問題のない全てのＳＱＬ文をＳＱＬ情報記憶部４３に用意することにすると、ＳＱＬ文の数が莫大になってしまうので、入力されたパラメータによって置き換え可能な変数を含むＳＱＬの雛型（以下、「ＳＱＬ雛型」という）を管理している。【００２１】  図４に、ＳＱＬ情報記憶部４３に記憶される情報の一例を示す。図４では、ＳＱＬ雛型に対し、そのＳＱＬ雛型を一意に識別するための識別情報であるＳＱＬ−ＩＤが付与されている。
また、図４では、ＳＱＬ雛型に対し、保護対象カラムおよびデータオーナのＩＤカラムの情報も対応付けられている。ここで、保護対象カラムの情報とは、ＳＱＬ雛型から組み立てられるＳＱＬ文を用いて読み出されるカラム（列）のうち保護対象として指定されているカラムを特定するための情報である。更に、データオーナのＩＤカラムの情報とは、ＳＱＬ雛型から組み立てられるＳＱＬ文を用いて読み出されるカラムのうち各データのデータオーナを知るために参照すべきカラムを特定するための情報である。【００２２】  ＳＱＬ組立て部４４は、ＳＱＬ情報記憶部４３に記憶されたＳＱＬ雛型からアプリケーション１０が入力したＳＱＬ−ＩＤに対応するものを取り出し、アプリケーション１０が入力したパラメータを変数に埋め込むことによりＳＱＬ文を組み立てる部分である。例えば、プライバシー保護モジュール４０におけるＳＱＬ組立てロジックに相当する。
カラム特定部４５は、ＳＱＬ情報記憶部４３に記憶された情報に基づき、アプリケーション１０が入力したＳＱＬ−ＩＤに対応する保護対象カラムおよびデータオーナのＩＤカラムを特定する部分である。例えば、プライバシー保護モジュール４０におけるカラム特定ロジックに相当する。【００２３】  データベースアクセス部４６は、ＤＢへのアクセス、および、アクセス結果の保持等を行う部分である。例えば、ＤＢにアクセスするための一般的なＪａｖａ（Ｒ）のクラスであるＤＢコネクションに相当する（Ｊａｖａ（Ｒ）およびすべてのＪａｖａ（Ｒ）関連の商標およびロゴは、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．の米国およびその他の国における商標または登録商標）。【００２４】  ポリシー準拠問合せ部４７は、ポリシーサーバ３０にポリシー準拠の問合せを行い、その問合せの結果を受け取って返却する部分である。具体的には、プライバシー保護モジュール４０におけるポリシー準拠問合せロジックに相当する。
問合せ結果記憶部４８は、ポリシーサーバ３０への通信コスト、ポリシー準拠チェックの負荷を軽減するために設けられるものであり、ポリシーサーバ３０に問い合わせた結果を記憶するキャッシュメモリとしての役割を担う部分である。【００２５】  なお、本実施の形態におけるデータベースシステムのハードウェア構成としては、一般的なコンピュータシステムと同様のものを採用することができる。即ち、アプリケーション１０を実行するコンピュータ、個人情報ＤＢ２０を管理するコンピュータ、ポリシーサーバ３０、プライバシー保護モジュール４０を実行するコンピュータのいずれも、中央処理装置（ＣＰＵ）と、主記憶装置とを含み、これらがバスを介して外部記憶装置と接続されたようなものであればよい。ここで、外部記憶装置としては、ハードディスク、フレキシブルディスク、ＭＯ（Ｍａｇｎｅｔｏ  Ｏｐｔｉｃａｌ  ｄｉｓｋ）、ＣＤ−ＲＯＭ等が例示される。【００２６】  アプリケーション１０を実行するコンピュータでは、外部記憶装置にアプリケーション１０が記憶され、中央処理装置（ＣＰＵ）がアプリケーション１０を主記憶装置に読み込んで実行することにより、図示しないデータ処理手段が実現される。
個人情報ＤＢ２０を管理するコンピュータでは、外部記憶装置により個人情報ＤＢ２０が実現される。なお、個人情報ＤＢ２０は、一般的には、データ記憶手段と捉えることができる。【００２７】  ポリシーサーバ３０では、外部記憶装置にポリシー準拠チェックを行うためのコンピュータプログラムが記憶され、中央処理装置（ＣＰＵ）がこのコンピュータプログラムを主記憶装置に読み込んで実行することにより、ポリシー準拠チェックの機能が実現される。なお、ポリシー準拠チェックの際に参照するポリシーは、このコンピュータプログラムの中に保持するようにしてもよいし、このコンピュータプログラムとは別に外部記憶装置に記憶することとしてもよい。【００２８】  プライバシー保護モジュール４０を実行するコンピュータでは、外部記憶装置にプライバシー保護モジュール４０が記憶され、中央処理装置（ＣＰＵ）がプライバシー保護モジュール４０を主記憶装置に読み込んで実行することにより、図示しないデータ保護手段が実現される。その際、プライバシー保護モジュール４０に含まれるプログラムロジックとしての制御部４１、アクセス情報記憶部４２、ＳＱＬ情報記憶部４３、ＳＱＬ組立て部４４、カラム特定部４５、データベースアクセス部４６、ポリシー準拠問合せ部４７、問合せ結果記憶部４８は、それぞれ、コンピュータにおける機能としての制御部４１、アクセス情報記憶部４２、ＳＱＬ情報記憶部４３、ＳＱＬ組立て部４４、カラム特定部４５、データベースアクセス部４６、ポリシー準拠問合せ部４７、問合せ結果記憶部４８を実現する。【００２９】  また、プライバシー保護モジュール４０を実行するコンピュータが、アプリケーション１０を実行するようにしてもよいし、個人情報ＤＢ２０を管理するようにしてもよい。更に、ポリシーサーバ３０におけるポリシー準拠チェックの機能は、プライバシー保護モジュール４０におけるポリシー準拠問合せ部４７の中に組み込んでもよいし、プライバシー保護モジュール４０を実行するコンピュータで動作する別のプログラムとして組み込んでもよい。但し、図１に示すように、ポリシーサーバ３０という独立したサーバコンピュータにて実現するようにすれば、ポリシーの変更にも柔軟に対応することが可能となる。【００３０】  更にまた、本実施の形態におけるデータベースシステムにおいて、各コンピュータには、キーボードやポインティングデバイス等の入力装置が接続されていてもよいし、ディスプレイ等の出力装置が接続されていてもよい。【００３１】  次に、本実施の形態におけるデータベースシステムの動作について説明する。なお、以下の動作説明において、制御部４１、アクセス情報記憶部４２、ＳＱＬ情報記憶部４３、ＳＱＬ組立て部４４、カラム特定部４５、データベースアクセス部４６、ポリシー準拠問合せ部４７、問合せ結果記憶部４８というときは、コンピュータの機能としての各構成要素を示すものとする。
図５は、アプリケーション１０の要求に応じて個人情報ＤＢ２０からデータを読み出す際のプライバシー保護モジュール４０の動作を示したフローチャートである。【００３２】  まず、プライバシー保護モジュール４０は、以降の処理で用いる各種ファイルの読み込みを行う（ステップ５０１）。具体的には、外部記憶装置に記憶されたアクセス情報を、主記憶装置のアクセス情報記憶部４２が管理する領域に読み込むと共に、外部記憶装置に記憶されたＳＱＬ情報を、主記憶装置のＳＱＬ情報記憶部４３が管理する領域に読み込む。【００３３】  次に、プライバシー保護モジュール４０では、制御部４１が、個人情報ＤＢ２０に発行して問題のないＳＱＬ文を組み立てるため、ステップ５０１で読み込んだＳＱＬ情報をアプリケーション１０に受け渡す（ステップ５０２）。これにより、アプリケーション１０は、例えば、ＳＱＬ−ＩＤとＳＱＬ雛型との対応を画面に表示し、ユーザに対し、個人情報ＤＢ２０に発行するＳＱＬ文の選択を促す。【００３４】  これに応じて、ユーザが、個人情報ＤＢ２０に発行したいＳＱＬ文の元となるＳＱＬ雛型のＳＱＬ−ＩＤ、ＳＱＬ雛型の変数に埋め込むパラメータ、アクセス目的を入力すると、アプリケーション１０は、入力されたＳＱＬ−ＩＤ、パラメータ、アクセス目的をプライバシー保護モジュール４０に伝える。また、アプリケーション１０は、例えば、アプリケーション１０へのログイン時に入力したユーザＩＤを用いる等してアクセス者を特定し、アクセス者ＩＤもプライバシー保護モジュール４０に伝える。
プライバシー保護モジュール４０では、制御部４１が、これらの情報を受け付け（ステップ５０３）、ＳＱＬ−ＩＤおよびパラメータをＳＱＬ組立て部４４に受け渡す。
なお、一般的には、予めＳＱＬ情報をアプリケーション１０の開発者に渡しておき、それをもとにアプリケーション１０が作成されることが多いが、その場合は、ステップ５０２のようなＳＱＬ情報の受け渡しのステップを設けることなく、アプリケーション１０がＳＱＬ−ＩＤを入力することも可能である。そのような一般的な実装に従うとすると、プライバシー保護モジュール４０は、アプリケーション１０からＳＱＬ−ＩＤとパラメータとを受け取り、ＳＱＬ−ＩＤが不正な（例えば、存在しないＳＱＬ−ＩＤが指定されていた）場合、エラーをアプリケーション１０に返し、ＳＱＬ−ＩＤが正常な場合のみ、以降の処理を行う構成となる。【００３５】  ＳＱＬ組立て部４４は、渡されたＳＱＬ−ＩＤに対するＳＱＬ雛型をＳＱＬ情報記憶部４３から取り出し、渡されたパラメータをこのＳＱＬ雛型に埋め込むことにより、個人情報ＤＢ２０に発行するＳＱＬ文を組み立て（ステップ５０４）、制御部４１に返す。
例えば、ＳＱＬ−ＩＤ「Ｓ００１」、パラメータ「ＴＤＬ」が渡されたとすると、ＳＱＬ組立て部４４は、「ＳＥＬＥＣＴ  ｉｄ，ｎａｍｅ，ｔｅｌ，ｈｏｂｂｙ  ＦＲＯＭ  ｐｉｉ＿ｔａｂｌｅ  ＷＨＥＲＥ  ｄｅｐａｒｔｍｅｎｔ＝“ＴＤＬ”」というＳＱＬ文を生成する。【００３６】  また、制御部４１は、ＳＱＬ−ＩＤをカラム特定部４５にも受け渡す。
カラム特定部４５は、ＳＱＬ情報記憶部４３を参照し、渡されたＳＱＬ−ＩＤに対するＳＱＬ文で取り出されるカラムの中で保護対象カラムを特定する（ステップ５０５）。例えば、ＳＱＬ−ＩＤ「Ｓ００１」に対するＳＱＬ文では、戻りのカラムは「ｉｄ」、「ｎａｍｅ」、「ｔｅｌ」、「ｈｏｂｂｙ」であるが、ＳＱＬ情報記憶部４３を参照すると、その中で保護対象カラムが「ｎａｍｅ」、「ｔｅｌ」であることが分かるので、そのことを制御部４１に伝える。
また、カラム特定部４５は、ＳＱＬ情報記憶部４３を参照し、渡されたＳＱＬ−ＩＤに対するＳＱＬ文で取り出されるカラムの中でデータオーナのＩＤを示すカラムを特定する（ステップ５０６）。例えば、ＳＱＬ−ＩＤ「Ｓ００１」に対するＳＱＬ文では、戻りのカラムは「ｉｄ」、「ｎａｍｅ」、「ｔｅｌ」、「ｈｏｂｂｙ」であるが、ＳＱＬ情報記憶部４３を参照すると、その中でデータオーナのＩＤカラムが「ｉｄ」であることが分かるので、そのことを制御部４１に伝える。【００３７】  以上の処理により、制御部４１には、個人情報ＤＢ２０にアクセスするためのアクセス情報と、個人情報ＤＢ２０に発行するＳＱＬ文とに加え、読み出されたデータの受渡し要求が個人情報保護ポリシーに準拠しているかどうかを判定するための情報が保持される。
即ち、個人情報保護のためには、例えば、「誰が」「何の目的で」「誰の」「何の」情報にアクセスするかの情報が必要になるが、これらの情報のうち、「誰が」アクセスするか、「何の目的で」アクセスするかについては、ステップ５０３で制御部４１に渡されている。また、「誰の」情報にアクセスするかについては、図６のフローチャートを参照して後述するようにアプリケーション１０により指定されるが、その者の情報へのアクセスがポリシーに準拠しているかの判定を行う際に用いるデータオーナのＩＤカラムの情報は、ステップ５０６で制御部４１に渡されている。更に、「何の」情報にアクセスするかについても、後述するようにアプリケーション１０により指定されるが、その情報へのアクセスがポリシーに準拠しているかの判定を行う際に用いる保護対象カラムの情報は、ステップ５０５で制御部４１に渡されている。【００３８】  次に、制御部４１は、データベースアクセス部４６（ＤＢコネクション）を生成し（ステップ５０７）、保持しておいたアクセス情報およびＳＱＬ文を受け渡すことにより、個人情報ＤＢ２０へのアクセスを指示する。この指示に応じて、データベースアクセス部４６は、アクセス情報を用いて個人情報ＤＢ２０にアクセスし、ＳＱＬ文を発行する（ステップ５０８）。また、アプリケーション１０から個人情報ＤＢ２０へのアクセスはプライバシー保護モジュール４０を通してのみ行えるようにしておく。こうすることで、ＤＢアクセス関連のクラスがプライバシー保護モジュール４０でラップされ、アプリケーション１０が自由に個人情報ＤＢ２０にアクセスすることを防止している。【００３９】  その後、データベースアクセス部４６は、クエリ結果を取得し、保持する（ステップ５０９）。
例えば、個人情報ＤＢ２０に対し、ＳＱＬ文「ＳＥＬＥＣＴ  ｉｄ，ｎａｍｅ，ｔｅｌ，ｈｏｂｂｙ  ＦＲＯＭ  ｐｉｉ＿ｔａｂｌｅ  ＷＨＥＲＥ  ｄｅｐａｒｔｍｅｎｔ＝“ＴＤＬ”」を発行したとすると、「部門」が「ＴＤＬ」である者の情報における「ＩＤ」「名前」「ＴＥＬ」「趣味」を取得する。即ち、図２の例では、「０００１」「山田  太郎」「０３−ＸＸＸＸ−ＸＸＸＸ」「ＹＹＹ」と、「０００３」「佐藤  花子」「０９０−ＸＸＸＸ−ＸＸＸＸ」「ＹＹＹ」等を読み出す。【００４０】  そして、データベースアクセス部４６は、クエリ結果を取得した旨を制御部４１に通知し、制御部４１が、その旨を更にアプリケーション１０に通知する（ステップ５１０）。【００４１】  ところで、Ｊａｖａ（Ｒ）では、ＤＢの情報を取得する際には、何番目のレコードのどのカラムが欲しいかを指定し、クエリ結果を扱うクラス（ＲｅｓｕｌｔＳｅｔ）から情報が受け取れる仕組みになっている。従って、通知を受けたアプリケーション１０は、実際に使用するレコードおよびカラムを指定することで、プライバシー保護モジュール４０に対しデータの受渡しを要求する。
具体的には、アプリケーション１０が、クエリ結果に含まれる個人情報のうち「名前」の情報を順番に表示するプログラムだとすると、１回目の受渡し要求では、１つ目のレコードの「名前」の情報を要求し、２回目の受渡し要求では、２つ目のレコードの「名前」の情報を要求することになる。以降、同様の要求を、ユーザから情報の表示を中止する旨の入力があるまで繰り返す。なお、このように全ての情報の受渡し要求を行う前に表示を中止する旨の入力を行う場合としては、例えば、画面上に５０人分の個人情報を表示することができる場合において、ユーザが、表示された５０人分の情報の中に目的の情報を発見したような場合に起こり得る。【００４２】  以下、個人情報ＤＢ２０から読み出されたデータをアプリケーション１０の要求に応じて受け渡す際のプライバシー保護モジュール４０の動作について述べる。
図６は、その動作を示したフローチャートである。上述したように、ステップ５１０でクエリ結果の取得が通知された後、アプリケーション１０はプライバシー保護モジュール４０に対し、データの受渡しを１件ずつ要求するが、ここでは、アプリケーション１０からの特定の１件のデータの受渡し要求に対するプライバシー保護モジュール４０の動作について説明する。【００４３】  まず、プライバシー保護モジュール４０では、制御部４１が、アプリケーション１０よりレコードおよびカラムの指定を受け付ける（ステップ６０１）。
これにより、制御部４１は、データベースアクセス部４６が保持するクエリ結果から、指定されたレコードの指定されたカラムの内容を取得する（ステップ６０２）。
例えば、ステップ５０９において取得されたクエリ結果が、「０００１」「山田  太郎」「０３−ＸＸＸＸ−ＸＸＸＸ」「ＹＹＹ」、「０００３」「佐藤  花子」「０９０−ＸＸＸＸ−ＸＸＸＸ」「ＹＹＹ」等である場合、アプリケーション１０から１番目のレコードの２番目のカラム（「名前」）が要求されると、制御部４１は、「山田  太郎」という情報を取り出す。【００４４】  次に、制御部４１は、ステップ５０５で特定した保護カラムの情報に基づき、要求されたカラムが保護対象であるかどうかを判断する（ステップ６０３）。
ここで、要求されたカラムが保護対象でない場合は、得られた情報をそのままアプリケーション１０に返却する（ステップ６１０）。例えば、「名前」と「ＴＥＬ」とが保護対象カラムとして特定されている場合、「趣味」が要求されると、これは保護対象ではないので、取り出した情報はそのままアプリケーション１０に返却する。【００４５】  一方、要求されたカラムが保護対象である場合は、ポリシー準拠問合せ部４７に制御が渡り、ポリシー準拠問合せ部４７が、問合せ結果記憶部４８に問合せ結果が既に格納されているかどうかを判定する（ステップ６０４）。ここで、ポリシー準拠問合せ部４７は、問合せ結果記憶部４８に問合せ結果が格納されていれば、問合せ結果記憶部４８から問合せ結果を取り出す（ステップ６０８）が、問合せ結果記憶部４８に問合せ結果が格納されていなければ、ポリシーサーバ３０に対し、ポリシー準拠の問合せを行う（ステップ６０５）。例えば、「名前」と「ＴＥＬ」とが保護対象カラムとして特定されている場合、「名前」が要求されると、これは保護対象であるので、このようなポリシー準拠チェックの処理を行う。【００４６】  次に、ポリシーサーバ３０は、ポリシー準拠チェックを行い、その結果をポリシー準拠問合せ部４７に返却する。これにより、ポリシー準拠問合せ部４７は、問合せ結果を受け付けて更に制御部４１に返却し（ステップ６０６）、同時に、問合せ結果記憶部４８にキャッシュする（ステップ６０７）。【００４７】  具体的には、以下のような処理を行う。なお、ここでは、制御部４１には、ステップ５０３における処理の結果、アクセス者ＩＤとして「Ｅ０００１」（東京の営業員とする）が、アクセス目的として「営業活動目的」が保持され、ステップ５０５における処理の結果、「ｎａｍｅ」「ｔｅｌ」が保護対象カラムである旨の情報が保持され、ステップ５０６における処理の結果、「ｉｄ」がデータオーナのＩＤカラムである旨の情報が保持されているとする。また、ステップ５０９において、１つ目のレコードが「０００１」「山田  太郎」「０３−ＸＸＸＸ−ＸＸＸＸ」「ＹＹＹ」であり、２つ目のレコードが「０００３」「佐藤  花子」「０９０−ＸＸＸＸ−ＸＸＸＸ」「ＹＹＹ」であるクエリ結果が取得されたとする。更に、ポリシーサーバ３０には、図３に示す個人情報保護ポリシーが格納され、「住所が東京都の場合のみ」というコンディションが定義されているため、ポリシー準拠問合せ部４７は、ポリシー準拠チェックを依頼する際には、住所の情報を送信すべきことを知っているものとする。更にまた、問合せ結果記憶部４８には、このポリシーに基づく準拠結果は格納されていないものとする。【００４８】  この場合において、アプリケーション１０から、クエリ結果に含まれる１つ目のレコードの２番目のカラムの受渡しが要求されたとする。すると、制御部４１は、「誰が」アクセスするかを示す情報として、アクセス者ＩＤ「Ｅ０００１」を、「何の目的で」アクセスするかを示す情報として、アクセス目的「営業活動目的」を、「誰の」情報にアクセスするかを示す情報として、データオーナーＩＤ「Ｓ００１」を、「何の」情報にアクセスするかを示す情報として、カラム「ｎａｍｅ」を、ポリシー準拠問合せ部４７を経由してポリシーサーバ３０に受け渡す。また、データオーナの住所として、「東京都」をポリシーサーバ３０に受け渡す。これに対し、ポリシーサーバ３０は、「東京の営業員」である「Ｅ００１」が、「営業活動目的」で、「住所が東京都」の「Ｓ００１」の、「名前」の受渡し要求であり、図３のポリシーに準拠する要求であるので、準拠結果として「ＯＫ」を返却する。【００４９】  また、アプリケーション１０から、クエリ結果に含まれる２つ目のレコードの２番目のカラムの受渡しが要求されたとする。すると、制御部４１は、「誰が」アクセスするかを示す情報として、アクセス者ＩＤ「Ｅ０００１」を、「何の目的で」アクセスするかを示す情報として、アクセス目的「営業活動目的」を、「誰の」情報にアクセスするかを示す情報として、データオーナーＩＤ「Ｓ００３」を、「何の」情報にアクセスするかを示す情報として、カラム「ｎａｍｅ」を、ポリシー準拠問合せ部４７を経由してポリシーサーバ３０に受け渡す。また、データオーナの住所として、「千葉県」をポリシーサーバ３０に受け渡す。これに対し、ポリシーサーバ３０は、「東京の営業員」である「Ｅ００１」が、「営業活動目的」で、「住所が千葉県」の「Ｓ００３」の、「名前」の受渡し要求であり、図３のポリシーに準拠する要求ではないので、準拠結果として「ＮＧ」を返却する。【００５０】  なお、この具体例では、ポリシー準拠問合せ部４７からポリシーサーバ３０へデータオーナの住所を送るようにしたが、ポリシーサーバ３０において各個人の住所の情報を把握している場合は、データオーナＩＤのみを送ることにより、ポリシー準拠チェックを行うことも可能である。【００５１】  そして、ポリシーに準拠している場合（ステップ６０９でＹＥＳ）、制御部４１は、ステップ６０２で取得した個人情報をアプリケーション１０に返却する（ステップ６１０）。一方、ポリシーに準拠していない場合（ステップ６０９でＮＯ）、制御部４１は、ステップ６０２で取得した個人情報をアプリケーション１０に返却せず、プライバシー準拠例外のエラーメッセージ、例えば、「Ｐｒｉｖａｃｙ  Ｖｉｏｌａｔｉｏｎ！」をアプリケーション１０に返却する（ステップ６１１）。【００５２】  以上により、本実施の形態の動作は終了する。
なお、本実施の形態をＪａｖａ（Ｒ）で実装する場合、クエリ結果を格納するｊａｖａ．ｓｑｌ．ＲｅｓｕｌｔＳｅｔオブジェクトをラップするクラスを作成し、そのラップクラスにポリシー準拠チェックを行うロジックを実装することになる。また、ラップクラスのインタフェースにｊａｖａ．ｓｑｌ．ＲｅｓｕｌｔＳｅｔを使用すれば、アプリケーションは通常のＲｅｓｕｌｔＳｅｔを使用する場合と全く同様にして、プライバシー保護された個人情報にアクセスすることができる。【００５３】  また、上記の説明では、図４に示すように、個人情報ＤＢ２０に発行するＳＱＬ文の元となるＳＱＬ雛型を用意し、入力されたパラメータを埋め込むようにしていたが、ＳＱＬ文のパターンが少ない場合は、ＳＱＬ文そのものを用意しておき、アプリケーション１０を介してＳＱＬ文そのものを提示するようにしてもよい。
更に、本実施の形態では、保護対象カラムの特定、および、データオーナのＩＤカラムの特定を、ステップ５０５、５０６のタイミングで、図４に示すＳＱＬ情報を用いて行うようにしたが、これに限られるものではない。即ち、保護対象カラムの特定は、ステップ６０３よりも前であれば、いかなるタイミングで行ってもよく、また、いかなる情報に基づいて行ってもよい。また、データオーナのＩＤカラムの特定は、ステップ６０５よりも前であれば、いかなるタイミングで行ってもよく、また、いかなる情報に基づいて行ってもよい。【００５４】  このように、本実施の形態では、データベースに格納された情報をアプリケーションが使用するタイミングでポリシー準拠チェックを行うので、データベースへのアクセス時に負荷が集中しない。例えば、アプリケーションが個人情報ＤＢからの検索結果を画面に５０人ずつ表示するものである場合、一度に行うポリシー準拠チェックは５０人分ですむ。
また、データベースに格納された情報をアプリケーションが使用するタイミングでポリシー準拠チェックを行うので、無駄なチェックが発生しないですむ。例えば、１０００人分の個人情報がヒットしても、実際には５０人分の情報を見ただけで処理が完了してしまうような場合もあるが、このような場合には、無駄なポリシー準拠チェックを省ける利点は大きい。【００５５】  また、従来の技術では、受け取ったＳＱＬを、ポリシーに準拠した情報のみをクエリ結果として取得するためのＳＱＬに変換する機構を持った特殊なＤＢを用意する必要があったが、本実施の形態では、そのような特殊なＤＢを用意する必要はない。
更に、ポリシー準拠チェックにおいて、「誰が」アクセスするか、「何の目的で」アクセスするかといった情報を用いる場合、従来の技術では、拡張ＳＱＬを用いる必要があった。ところが、本実施の形態では、プライバシー保護モジュールでそれらの情報を取り扱うようにしているので、拡張ＳＱＬを用いる必要はない。
【図面の簡単な説明】
【００５６】
【図１】本実施の形態におけるデータベースシステムの全体構成を示したブロック図である。
【図２】本実施の形態における個人情報ＤＢに記憶される情報の一例を示した図である。
【図３】本実施の形態におけるポリシーサーバで管理される情報の一例を示した図である。
【図４】本実施の形態におけるＳＱＬ情報記憶部に記憶される情報の一例を示した図である。
【図５】本実施の形態におけるプライバシー保護モジュールが実行される際の動作を示したフローチャートである。
【図６】本実施の形態におけるプライバシー保護モジュールが実行される際の動作を示したフローチャートである。
【符号の説明】
【００５７】１０…アプリケーション、２０…個人情報ＤＢ、３０…ポリシーサーバ、４０…プライバシー保護モジュール、４１…制御部、４２…アクセス情報記憶部、４３…ＳＱＬ情報記憶部、４４…ＳＱＬ組立て部、４５…カラム特定部、４６…データベースアクセス部、４７…ポリシー準拠問合せ部、４８…問合せ結果記憶部
【図１】
0005430819.tif 000002
【図２】
0005430819.tif 000003
【図３】
0005430819.tif 000004
【図４】
0005430819.tif 000005
【図５】
0005430819.tif 000006
【図６】
0005430819.tif 000007