特開 2023-1780 データアクセス制御方法、データアクセス制御装置、データアクセス制御プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023001780

(43)【公開日】2023-01-06

(54)【発明の名称】データアクセス制御方法、データアクセス制御装置、データアクセス制御プログラム

(51)【国際特許分類】

   G06F 16/2457 20190101AFI20221226BHJP

   G06F 21/62 20130101ALI20221226BHJP

【ＦＩ】

G06F16/2457

G06F21/62 318

【審査請求】未請求

【請求項の数】14

【出願形態】ＯＬ

(21)【出願番号】P 2021102711

(22)【出願日】2021-06-21

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110002365

【氏名又は名称】特許業務法人サンネクスト国際特許事務所

(72)【発明者】

【氏名】角井 健太郎

【テーマコード（参考）】

5B175

【Ｆターム（参考）】

5B175BA01

(57)【要約】

【課題】アクセス制御ポリシーの維持管理が容易なデータアクセス制御技術を提供する。
【解決手段】ポリシー判定部４０１は、予め設定されたアクセス制御ポリシー４０２に基づいて、データ５０１へのアクセス要求に対するルールを取得し、データ５０１が格納されたデータベース５００の外部から、データ５０１の各レコードの属性に関する属性情報を取得するか否かを選択する。その結果、属性情報を取得すると選択した場合、属性情報を取得して属性情報に基づくルールの評価を行い、属性情報を取得しないと選択した場合、データベース５００にルールに基づくデータ５０１のフィルタリングを実行させる。そして、ルールの評価結果またはフィルタリングの実行結果に基づいて、アクセス要求に対応するデータ５０１のレコードをデータベース５００から取得する。
【選択図】図３

【特許請求の範囲】

【請求項1】

コンピュータによるデータアクセス制御方法であって、
前記コンピュータにより、予め設定されたアクセス制御ポリシーに基づいて、第１のデータへのアクセス要求に対するルールを取得し、
前記コンピュータにより、前記第１のデータが格納された第１のデータベースの外部から、前記第１のデータの各レコードの属性に関する属性情報を取得するか否かを選択し、
前記属性情報を取得すると選択した場合、前記コンピュータにより、前記属性情報を取得して前記属性情報に基づく前記ルールの評価を行い、
前記属性情報を取得しないと選択した場合、前記コンピュータにより、前記第１のデータベースに前記ルールに基づく前記第１のデータのフィルタリングを実行させる指示を行い、
前記コンピュータにより、前記ルールの評価結果または前記フィルタリングの実行結果に基づいて、前記アクセス要求に対応する前記第１のデータのレコードを前記第１のデータベースから取得する、
データアクセス制御方法。

【請求項2】

前記第１のデータベースに前記属性情報を含む第２のデータが格納されている場合、前記属性情報を取得しないと選択し、
前記第１のデータベースに前記第２のデータが格納されていない場合、前記属性情報を取得すると選択する、
請求項１に記載のデータアクセス制御方法。

【請求項3】

前記属性情報を取得しないと選択した場合、前記第１のデータと前記第２のデータを結合することで、前記第１のデータベースに前記フィルタリングを実行させる、
請求項２に記載のデータアクセス制御方法。

【請求項4】

前記第１のデータベースに前記第２のデータが格納されている場合であっても、前記第１のデータベースにおいて前記第１のデータと前記第２のデータを結合できない場合は、前記属性情報を取得すると選択する、
請求項３に記載のデータアクセス制御方法。

【請求項5】

前記コンピュータにより、前記アクセス要求に応じた第１のクエリを生成するクエリサービスと、前記アクセス要求に対して前記アクセス制御ポリシーに基づく認可処理を行う認可サービスと、を提供し、
前記認可サービスでは、
前記第１のデータベースの外部から前記属性情報を取得するか否かを選択し、
前記属性情報を取得すると選択した場合、前記属性情報の取得および前記ルールの評価を行い、
前記属性情報を取得しないと選択した場合、前記第１のデータベースに前記フィルタリングを実行させるための第２のクエリを前記クエリサービスから出力させる、
請求項１に記載のデータアクセス制御方法。

【請求項6】

前記クエリサービスでは、前記認可サービスからの指示に応じて、生成した前記第１のクエリを前記第２のクエリに変換して前記第１のデータベースに出力する、
請求項５に記載のデータアクセス制御方法。

【請求項7】

前記属性情報の配置場所とその機能を示す属性情報管理テーブルを参照して、前記第１のデータベースの外部から前記属性情報を取得するか否かを選択する、
請求項１に記載のデータアクセス制御方法。

【請求項8】

前記コンピュータにより、前記第１のデータが格納された前記第１のデータベースと、前記属性情報を含む第２のデータが格納された第２のデータベースと、に関するメタデータを取得し、取得した前記メタデータに基づいて前記属性情報管理テーブルを作成する、
請求項７に記載のデータアクセス制御方法。

【請求項9】

前記メタデータは、前記第１のデータベースおよび前記第２のデータベースがそれぞれサポートする機能の情報と、前記第１のデータおよび前記第２のデータの所属先のデータベースの情報と、を含む、
請求項８に記載のデータアクセス制御方法。

【請求項10】

前記第１のデータベースおよび前記第２のデータベースは、仮想化レイヤを介して、前記属性情報管理テーブルを作成する前記コンピュータとそれぞれ接続されており、
前記メタデータは、前記仮想化レイヤの情報をさらに含む、
請求項９に記載のデータアクセス制御方法。

【請求項11】

前記第１のデータと前記第２のデータを前記仮想化レイヤを介して結合することで、前記第１のデータベースに前記フィルタリングを実行させる、
請求項１０に記載のデータアクセス制御方法。

【請求項12】

前記メタデータは、前記仮想化レイヤを介したデータ結合の有効性および優先度の情報をさらに含む、
請求項１１に記載のデータアクセス制御方法。

【請求項13】

予め設定されたアクセス制御ポリシーに基づいて、第１のデータへのアクセス要求に対するルールを取得し、前記第１のデータが格納された第１のデータベースの外部から、前記第１のデータの各レコードの属性に関する属性情報を取得するか否かを選択するポリシー判定部と、
前記属性情報を取得する属性情報取得部と、
前記第１のデータベースに前記ルールに基づく前記第１のデータのフィルタリングを実行させるクエリ部と、
前記アクセス要求に対応する前記第１のデータのレコードを前記第１のデータベースから取得する通信部と、を備え、
前記属性情報取得部は、前記ポリシー判定部が前記属性情報を取得すると選択した場合に前記属性情報を取得し、
前記ポリシー判定部は、前記属性情報取得部が取得した前記属性情報に基づいて前記ルールの評価を行い、
前記クエリ部は、前記ポリシー判定部が前記属性情報を取得しないと選択した場合に前記第１のデータベースに前記フィルタリングを実行させ、
前記通信部は、前記ポリシー判定部による前記ルールの評価結果または前記第１のデータベースにおける前記フィルタリングの実行結果に基づいて、前記アクセス要求に対応する前記第１のデータのレコードを前記第１のデータベースから取得する、
データアクセス制御装置。

【請求項14】

コンピュータに、
予め設定されたアクセス制御ポリシーに基づいて、第１のデータへのアクセス要求に対するルールを取得する第１の処理と、
前記第１のデータが格納された第１のデータベースの外部から、前記第１のデータの各レコードの属性に関する属性情報を取得するか否かを選択する第２の処理と、
前記第２の処理で前記属性情報を取得すると選択された場合、前記属性情報を取得して前記属性情報に基づく前記ルールの評価を行う第３の処理と、
前記第２の処理で前記属性情報を取得しないと選択された場合、前記第１のデータベースに前記ルールに基づく前記第１のデータのフィルタリングを実行させる第４の処理と、
前記第３の処理による前記ルールの評価結果または前記第４の処理による前記フィルタリングの実行結果に基づいて、前記アクセス要求に対応する前記第１のデータのレコードを前記第１のデータベースから取得する第５の処理と、を実行させる、
データアクセス制御プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データアクセスを制御する方法、装置およびプログラムに関する。

【背景技術】

【0002】

本発明の背景技術を開示する文献として、下記の特許文献１が知られている。特許文献１には、外部のポリシーサービスによって定義されたポリシーに基づいて、特定のコンテクストに従った認証ルールを生成し、この認証ルールをアプリケーション内で評価することにより、各種データベース等のリソースへのアクセスの可否をユーザごとに判定する技術が記載されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】米国特許出願公開第２０２０／０３５８８２３号明細書

【発明の概要】

【発明が解決しようとする課題】

【0004】

従来のデータアクセス制御では、ユーザからのアクセス対象となるデータベースの構造によっては、アクセス制御用のポリシーを定義する際に、アクセスを許可または拒否するユーザとデータの組み合わせをデータごとに列挙して記述する必要がある。このような場合、ポリシーの記述が肥大化するとともに、ポリシーに記述すべきユーザとデータの組み合わせがデータベースの更新に応じて日々更新されるため、ポリシーの維持管理が困難になるという問題が生じる。特許文献１に記載の技術では、こうした問題への対処が不十分である。

【0005】

そこで、本発明では、データアクセス制御におけるアクセス制御ポリシーの維持管理を容易とすることを目的とする。

【課題を解決するための手段】

【0006】

本発明によるデータアクセス制御方法は、コンピュータによるデータアクセス制御方法であって、前記コンピュータにより、予め設定されたアクセス制御ポリシーに基づいて、第１のデータへのアクセス要求に対するルールを取得し、前記コンピュータにより、前記第１のデータが格納された第１のデータベースの外部から、前記第１のデータの各レコードの属性に関する属性情報を取得するか否かを選択し、前記属性情報を取得すると選択した場合、前記コンピュータにより、前記属性情報を取得して前記属性情報に基づく前記ルールの評価を行い、前記属性情報を取得しないと選択した場合、前記コンピュータにより、前記第１のデータベースに前記ルールに基づく前記第１のデータのフィルタリングを実行させる指示を行い、前記コンピュータにより、前記ルールの評価結果または前記フィルタリングの実行結果に基づいて、前記アクセス要求に対応する前記第１のデータのレコードを出力する。
本発明によるデータアクセス制御装置は、予め設定されたアクセス制御ポリシーに基づいて、第１のデータへのアクセス要求に対するルールを取得し、前記第１のデータが格納された第１のデータベースの外部から、前記第１のデータの各レコードの属性に関する属性情報を取得するか否かを選択するポリシー判定部と、前記属性情報を取得する属性情報取得部と、前記第１のデータベースに前記ルールに基づく前記第１のデータのフィルタリングを実行させるクエリ部と、前記アクセス要求に対応する前記第１のデータのレコードを出力する通信部と、を備え、前記属性情報取得部は、前記ポリシー判定部が前記属性情報を取得すると選択した場合に前記属性情報を取得し、前記ポリシー判定部は、前記属性情報取得部が取得した前記属性情報に基づいて前記ルールの評価を行い、前記クエリ部は、前記ポリシー判定部が前記属性情報を取得しないと選択した場合に前記第１のデータベースに前記フィルタリングを実行させ、前記通信部は、前記ポリシー判定部による前記ルールの評価結果または前記第１のデータベースにおける前記フィルタリングの実行結果に基づいて、前記アクセス要求に対応する前記第１のデータのレコードを出力する。
本発明によるデータアクセス制御プログラムは、コンピュータに、予め設定されたアクセス制御ポリシーに基づいて、第１のデータへのアクセス要求に対するルールを取得する第１の処理と、前記第１のデータが格納された第１のデータベースの外部から、前記第１のデータの各レコードの属性に関する属性情報を取得するか否かを選択する第２の処理と前記第２の処理で前記属性情報を取得すると選択された場合、前記属性情報を取得して前記属性情報に基づく前記ルールの評価を行う第３の処理と、前記第２の処理で前記属性情報を取得しないと選択された場合、前記第１のデータベースに前記ルールに基づく前記第１のデータのフィルタリングを実行させる第４の処理と、前記第３の処理による前記ルールの評価結果または前記第４の処理による前記フィルタリングの実行結果に基づいて、前記アクセス要求に対応する前記第１のデータのレコードを出力する第５の処理と、を実行させる。

【発明の効果】

【0007】

本発明によれば、アクセス制御ポリシーの維持管理が容易なデータアクセス制御技術を提供することができる。

【図面の簡単な説明】

【0008】

【図1】本発明の第１の実施形態に係るデータアクセス制御装置を含むサービス提供システムの構成を示すブロック図である。

【図2】データアクセス制御装置のハードウェア構成の一例を示す図である。

【図3】クエリサービスおよび認可サービスの機能構成を示す機能ブロック図である。

【図4】データベースに格納されるデータの例を示す図である。

【図5】本発明の第１の実施形態においてデータカタログに格納されるメタデータテーブルの例を示す図である。

【図6】属性情報管理テーブル作成部により作成される属性情報管理テーブルの例を示す図である。

【図7】クエリサービスによって実行される処理のフローチャートである。

【図8】認可サービスによって実行される処理のフローチャートである。

【図9】認可サービスにおいて属性情報管理テーブルを作成する際に実行する処理のフローチャートである。

【図10】本発明の第２の実施形態に係るデータアクセス制御装置を含むサービス提供システムの構成を示すブロック図である。

【図11】本発明の第２の実施形態においてデータカタログに格納されるメタデータテーブルの例を示す図である。

【発明を実施するための形態】

【0009】

以下、図面を参照して本発明の実施形態を説明する。説明の明確化のため、以下の記載及び図面は、適宜、省略及び簡略化がなされている。本発明が本実施形態に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。特に限定しない限り、各構成要素は複数でも単数でも構わない。

【0010】

以下の説明では、例えば、「ｘｘｘ表」や「ｘｘｘテーブル」の表現にて各種情報を説明することがあるが、各種情報は表やテーブル以外のデータ構造で表現されていてもよい。各種情報がデータ構造に依存しないことを示すために、「ｘｘｘ表」や「ｘｘｘテーブル」を「ｘｘｘ情報」と呼ぶことがある。

【0011】

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号（又は参照符号における共通部分）を使用し、同種の要素を区別して説明する場合は、要素のＩＤ（又は要素の参照符号）を使用することがある。

【0012】

また、以下の説明では、「サービス提供システム」は、１以上の計算機を含むシステムである。このため、「サービス提供システム」は、１つの計算機であってもよいし、複数の計算機であってもよいし、計算機の他に計算機以外のデバイスを含んでいてもよい。その１以上の計算機は、典型的には、少なくとも１つの物理計算機を含む。

【0013】

その１以上の計算機は、少なくとも１つの仮想計算機を含んでもよい。

【0014】

また、以下の説明では、「データアクセス制御装置」や「クライアント」は、一以上の計算機で構成されてよい。

【0015】

以下の説明では、「プログラム」あるいはそのプロセスを主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えば、ＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理を、適宜に記憶資源（例えば、メモリ）及び／又は通信インタフェース装置（例えば、通信ポート）を用いながら行うため、処理の主語がプロセッサであってもよい。プロセッサは、プログラムに従って動作することによって、所定の機能を実現する機能部として動作する。プロセッサを含む装置及びシステムは、これらの機能部を含む装置及びシステムである。

【0016】

また、以下の説明では、「データベース」は、物理的な記憶デバイスを有する計算機を意味し、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）を有する計算機でよい。補助記憶デバイスは、例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）でよい。データベースに異なる種類の記憶デバイスが混在していてもよい。

【0017】

［第１の実施形態］
以下、本発明の第１の実施形態について説明する。

【0018】

図１は、本発明の第１の実施形態に係るデータアクセス制御装置を含むサービス提供システムの構成を示すブロック図である。図１に示すサービス提供システム１は、ユーザに対して様々なサービスを提供するシステムであり、データアクセス制御装置１００、クライアント３００、データベース５００および５１０、データカタログ６００を備える。サービス提供システム１において、これらの構成要素は、例えばインターネットやＬＡＮ（Local Area Network）、ＷＡＮ(Wide Area Network)等のネットワークを介して互いに接続されている。

【0019】

データアクセス制御装置１００は、クエリサービス２００および認可サービス４００を有する。クエリサービス２００は、ＰＣ（Personal Computer）等により構成されるクライアント３００をユーザが操作することでクライアント３００から送信されるリクエストを受信し、そのリクエストの内容に応じたサービスを提供する。例えば、リクエストで指定されたデータ５０１の一部またはすべてをデータベース５００から取得し、リクエストに対するレスポンスとしてクライアント３００へ送信する。なお、クエリサービス２００におけるリクエストおよびレスポンスは、典型的にはRESTful APIとして定義される。

【0020】

認可サービス４００は、クライアント３００からリクエストを送信するユーザの属性に応じて、クエリサービス２００によるデータ５０１へのアクセスをユーザごとに制限するための認可処理を提供する。認可サービス４００は、データカタログ６００から取得するメタデータや、データベース５１０に格納されたデータ５１１に基づいて認可処理を実行し、その結果を提供することができる。

【0021】

データベース５００は、データ５０１およびデータ５０２を格納している。データ５０１，５０２は、予め設定された複数のデータ項目からなるレコードを多数まとめてテーブル化した情報であり、それぞれ異なるデータ項目が設定されている。ただし、データ５０２は必ずしもデータベース５００に格納されているとは限らず、サービス提供システム１を実現するためのアプリケーションの設計や運用上の理由により、データ５０２がデータベース５００に格納されていない場合もある。そのため図１のブロック図では、データ５０２を破線で示している。

【0022】

データベース５１０は、データ５１１を格納している。データ５１１は、データベース５００に格納されているデータ５０１，５０２と同様に、予め設定された複数のデータ項目からなるレコードを多数まとめてテーブル化した情報であり、データ５０２と共通のスキーマに基づいてテーブル化されている。典型的にはデータ５１１がマスターであり、データ５０２はその複製である。なお、前述のようにデータ５０２はデータベース５００に格納されていない場合もあるが、その場合であっても、認可サービス４００がデータベース５１０にリクエストを送信することで、データ５０２の代わりにデータ５１１をデータベース５１０から取得し、認可処理において利用することが可能である。

【0023】

サービス提供システム１においてデータベース５００にデータ５０２を格納させるか否かは、例えば、データ５０２とデータ５１１の整合性を確保するために要するコストと、データベース５１０からデータ５１１を取得する際のオーバーヘッドとのトレードオフにより決定される。どちらの設定状態とするかは、サービス提供システム１を実現するためのアプリケーションの設計時または運用開始時に選択されてもよいし、運用中に変更可能としてもよい。

【0024】

データカタログ６００は、データベース５００，５１０とこれらに格納されているデータ５０１，５０２および５１１とに関する情報であるメタデータを収集・蓄積する。認可サービス４００は、データカタログ６００から取得したメタデータを参照することで、データベース５１０からデータ５１１を取得するか否かを決定することができる。

【0025】

図２は、データアクセス制御装置１００のハードウェア構成の一例を示す図である。図２に示すように、データアクセス制御装置１００は、例えばプロセッサ１０１、メモリ１０２、ストレージ１０３、ネットワークＩ／Ｆ（インタフェース）１０４、コンソール１０５を備えたコンピュータにより構成される。

【0026】

プロセッサ１０１は、メモリ１０２を作業領域に用いてストレージ１０３に格納された所定のプログラムやアプリケーションを実行することで、図１のクエリサービス２００および認可サービス４００を実現するための演算処理を行う。ネットワークＩ／Ｆ１０４は、ネットワーク１０６を介して図１のクライアント３００やデータベース５００および５１０、データカタログ６００と接続されており、プロセッサ１０１の制御に応じて、これらとの間で情報通信を行う。コンソール１０５は、サービス提供システム１の管理を行う管理者によって使用される入出力装置であり、例えばディスプレイ、マウス、キーボード等により構成される。

【0027】

なお、図２の例では、クエリサービス２００および認可サービス４００を一つのデータアクセス制御装置１００で実現する場合のハードウェア構成例を示したが、これらのサービスを別々のハードウェアにより実現してもよいし、複数のハードウェアを組み合わせてそれぞれ実現してもよい。任意のハードウェア構成により、クライアント３００に対してクエリサービス２００および認可サービス４００を提供するデータアクセス制御装置１００を実現可能である。

【0028】

図３は、クエリサービス２００および認可サービス４００の機能構成を示す機能ブロック図である。図３において、クエリサービス２００は、ＡＰＩ（Application Programming Interface）通信部２０１、認証部２０２、ポリシー実施部２０３、クエリ生成部２０４、クエリ変換部２０５、ＤＢ通信部２０６の各機能ブロックを備える。また、認可サービス４００は、ポリシー判定部４０１、ポリシー管理部４０３、属性情報取得部４０４、属性情報管理テーブル作成部４０６の各機能ブロックを備える。これらの機能ブロックは、例えば図２のプロセッサ１０１が行う演算処理によってそれぞれ実現される。

【0029】

クエリサービス２００において、ＡＰＩ通信部２０１は、クライアント３００から送信されるリクエストを受信する。認証部２０２は、ＡＰＩ通信部２０１が受信したリクエストの認証を実施し、そのリクエストを行ったユーザを特定することで、リクエストの主体を特定する。ポリシー実施部２０３は、認可サービス４００から提供される認可処理の結果に基づき、リクエストの主体に応じたデータ５０１へのアクセスを許可または拒否するとともに、クエリ変換が必要か否かを判断する。

【0030】

クエリ生成部２０４は、ポリシー実施部２０３によりデータ５０１へのアクセスが許可された場合に、データベース５００に対してデータ５０１の取得を要求するクエリを生成する。クエリ変換部２０５は、ポリシー実施部２０３によりクエリ変換が必要と判断された場合に、クエリ生成部２０４により生成されたクエリの変換を実施する。ＤＢ通信部２０６は、クエリ生成部２０４により生成され、さらに必要に応じてクエリ変換部２０５により変換されたクエリをデータベース５００に送信することで、リクエストに応じたデータ５０１のレコードをデータベース５００から抽出して取得する。ＤＢ通信部２０６が取得したレコードは、ＡＰＩ通信部２０１により、リクエストに対するレスポンスとしてクライアント３００へ送信される。

【0031】

認可サービス４００において、ポリシー管理部４０３は、ポリシー判定部４０１において実行される認可処理に用いられるアクセス制御ポリシー４０２の管理を行う。アクセス制御ポリシー４０２は、クライアント３００を用いてデータ５０１にアクセスする様々なユーザ（主体）に対して、データ５０１に含まれる複数のレコードのうちどのレコードへのアクセスを許可するかを主体ごとに規定するためのルールを示す情報であり、例えばＸＡＣＭＬ（eXtensible Access Control Markup Language）等の所定のファイル形式により予め設定されたものがデータアクセス制御装置１００に記憶されている。ポリシー管理部４０３は、例えば図２のストレージ１０３に記憶保持されているアクセス制御ポリシー４０２を取得し、ポリシー判定部４０１へ出力する。

【0032】

属性情報取得部４０４は、データベース５１０に格納されているデータ５１１から、データ５０１の各レコードの属性に関する属性情報を必要に応じて取得する。なお、データ５１１と共通のデータ５０２がデータベース５００に格納されている場合、属性情報取得部４０４はデータ５１１から属性情報を取得しなくてもよい。

【0033】

属性情報管理テーブル作成部４０６は、データカタログ６００に格納されているメタデータテーブル６０１を取得し、これに基づいて属性情報管理テーブル４０５を作成する。メタデータテーブル６０１は、前述のメタデータをテーブル化したものであり、データベース５００，５１０を含む様々なデータベースがサポートする機能の情報や、各データベースが格納しているデータの情報を含んでいる。属性情報管理テーブル作成部４０６は、データ５０１，５０２，５１１に関する情報をメタデータテーブル６０１から抽出して取得することで、これらのデータの格納先を示す属性情報管理テーブル４０５を作成することができる。なお、属性情報管理テーブル４０５の詳細については後述する。

【0034】

ポリシー判定部４０１は、ポリシー管理部４０３から出力されるアクセス制御ポリシー４０２と、属性情報取得部４０４により取得される属性情報と、属性情報管理テーブル作成部４０６により作成される属性情報管理テーブル４０５とに基づき、クライアント３００からのリクエストに対する認可処理を行う。この認可処理では、リクエストに対してデータ５０１のアクセスを許可するか否か、許可する場合にはデータ５０１のうちどのレコードへのアクセスを許可するかなどの判定を行う。ポリシー判定部４０１による認可処理の結果は、クエリサービス２００のポリシー実施部２０３へ送信される。

【0035】

図４は、データベース５００，５１０にそれぞれ格納されるデータ５０１，５０２，５１１の例を示す図である。データベース５００には、例えば図４に示すデータ構造の受注伝票テーブルと顧客テーブルがデータ５０１，５０２としてそれぞれ格納され、データベース５１０には、データ５０２と同一構造の顧客テーブルがデータ５１１として格納される。これらのデータは複数のレコードによりそれぞれ構成されており、各レコードのフィールドには、当該フィールドに対応するカラムごとに設定されたデータ項目の値がそれぞれ格納される。例えばデータ５０１の受注伝票テーブルでは、各レコードを構成する複数のフィールドに対して、「伝票No.」、「受注先」、「受注日」等のデータ項目に対応する値がそれぞれ格納され、データ５０２，５１１の顧客テーブルでは、各レコードを構成する複数のフィールドに対して、「顧客No.」、「顧客名」、「担当者」等のデータ項目に対応する値がそれぞれ格納される。これらのデータ項目のうち、「受注先」と「顧客No.」は対応関係を有しており、この対応関係により、データ５０１の各レコードとデータ５０２，５１１の各レコードとが互いに紐付けられている。

【0036】

属性情報取得部４０４は、上記の紐付けにより、データ５０１の各レコードの属性に関する属性情報として、データ５０２から必要な情報を抽出して取得することができる。例えば、データ５０１において「受注先」の値が「CUS001」であるレコード５２１に対して、「顧客No.」の値が同じ「CUS001」であるレコード５２２をデータ５０２から抽出し、このレコード５２２の各フィールドの値をレコード５２１の属性情報として取得することができる。

【0037】

図５は、本発明の第１の実施形態においてデータカタログ６００に格納されるメタデータテーブル６０１の例を示す図である。前述のとおり、データベース５００，５１０にそれぞれ格納されるデータ５０２およびデータ５１１は、共通のスキーマに基づいてテーブル化されたものであるが、アプリケーションの設計や運用上の理由により、データ５０２がデータベース５００に存在しない場合がある。そのため、メタデータをテーブル化したメタデータテーブル６０１の構成は、データ５０２が存在するか否かに応じて異なるものとなる。図５の例では、データ５０２が存在する場合のメタデータテーブル６０１の例をメタデータテーブル６０１Ａとし、データ５０２が存在しない場合のメタデータテーブル６０１の例をメタデータテーブル６０１Ｂとして、それぞれ示している。

【0038】

メタデータテーブル６０１Ａとメタデータテーブル６０１Ｂとの違いは、データ５０２の特徴や所属先を示すレコード６１１の有無である。すなわち、データ５０２が存在する場合のメタデータテーブル６０１Ａは、データ５０２のメタデータを表すレコード６１１を含んで構成されているが、データ５０２が存在しない場合のメタデータテーブル６０１Ｂは、データ５０２のメタデータを表すレコード６１１を含んでいない。

【0039】

図６は、属性情報管理テーブル作成部４０６により作成される属性情報管理テーブル４０５の例を示す図である。図５で説明したように、メタデータテーブル６０１の構成は、データ５０２が存在するか否かに応じて異なるものとなる。そのため、メタデータテーブル６０１に基づいて作成される属性情報管理テーブル４０５の構成も同様に、データ５０２が存在するか否かに応じて異なるものとなる。図６の例では、データ５０２が存在する場合の属性情報管理テーブル４０５の例を属性情報管理テーブル４０５Ａとし、データ５０２が存在しない場合の属性情報管理テーブル４０５の例を属性情報管理テーブル４０５Ｂとして、それぞれ示している。

【0040】

属性情報管理テーブル４０５Ａと属性情報管理テーブル４０５Ｂでは、データ５０２とデータ５１１にそれぞれ対応するレコード４１１Ａ，４１１Ｂの内容が異なる。すなわち、データ５０２が存在する場合の属性情報管理テーブル４０５Ａでは、データ５０２に基づく属性情報の格納先や取得方法がレコード４１１Ａに記録されており、データ５０２が存在しない場合の属性情報管理テーブル４０５Ｂでは、データ５１１に基づく属性情報の格納先や取得方法がレコード４１１Ｂに記録されている。

【0041】

具体的には、図６の属性情報管理テーブル４０５Ａにおいて、レコード４１１Ａの「配置場所」と「機能」にそれぞれ格納された「DB01」および「SQL」は、当該属性情報を含むデータ５０２がデータベース５００に格納されており、当該属性情報をＳＱＬ命令により取得可能であることを表している。また、属性情報管理テーブル４０５Ｂにおいて、レコード４１１Ｂの「配置場所」と「機能」にそれぞれ格納された「SV02」および「REST」は、当該属性情報をRESTful APIで定義されるサービスにより取得可能であることを表している。

【0042】

さらに、属性情報管理テーブル４０５Ａ，４０５Ｂにおいて、各レコードの「アクセスパス」には、データベース５００，５１０の中で属性情報の取得先を一意に特定するための記述子がそれぞれ格納されている。具体的には、属性情報管理テーブル４０５Ａの各レコードや、属性情報管理テーブル４０５Ｂにおいてレコード４１１Ｂを除く各レコードでは、データ５０１，５０２のテーブル名とカラム名を連結したものが「アクセスパス」に格納され、属性情報管理テーブル４０５Ｂのレコード４１１Ｂでは、RESTful APIのリクエストで指定されるパスパラメータが「アクセスパス」に格納されている。

【0043】

属性情報管理テーブル４０５Ａは、例えばサービス提供システム１の管理者がメタデータテーブル６０１Ａを参照し、データ５０２をアクセス主体の属性情報として選択することにより生成される。一方、属性情報管理テーブル４０５Ｂは、例えばサービス提供システム１の管理者がメタデータテーブル６０１Ｂを参照し、データ５１１をアクセス主体の属性情報として選択することにより生成される。

【0044】

続いて、データアクセス制御装置１００が行う処理の詳細について、フローチャートを参照して以下に説明する。

【0045】

図７は、データアクセス制御装置１００のクエリサービス２００によって実行される処理のフローチャートである。クエリサービス２００は、データ５０１へのアクセスを指示するリクエストがクライアント３００から送信されると、図７のフローチャートに示す処理を開始する（ステップＳ７００）。

【0046】

ＡＰＩ通信部２０１は、クライアント３００からリクエストを受信する（ステップＳ７０２）。このリクエストには、データ５０１を構成する複数のレコードのうちどのレコードを取得するかを表す情報が含まれている。例えば、データ５０１において「伝票No.」の値が「ORD001」であるレコードを取得するリクエストは、「GET /orders/ORD001 HTTP/1.1」のように記載される。

【0047】

認証部２０２は、ステップＳ７０２でＡＰＩ通信部２０１が受信したリクエストに含まれるクレデンシャルまたはトークンを取り出し、これを用いてリクエストの認証を行う（ステップＳ７０４）。例えば、受信したリクエストがＨＴＴＰに基づくＡＰＩであれば、典型的には当該リクエストのヘッダフィールドにクレデンシャルまたはトークンが含まれている。ステップＳ７０４でリクエストの認証に成功すると、クエリサービス２００は、そのリクエストを送信したユーザ（主体）を特定することができる。

【0048】

ステップＳ７０４で行われる認証には、例えばＢａｓｉｃ認証やＪＷＴ認証などを用いることができる。具体的な認証の実行方法としては、例えばＢａｓｉｃ認証であればクレデンシャルが含むパスワードのチェックであり、ＪＷＴ認証であればトークンの署名の検証である。このように、認証方式によってステップＳ７０４の処理内容は異なり得るが、いずれの場合であっても、リクエストの主体を特定できれば認証は成功である。ステップＳ７０４でリクエストの主体を特定できた場合は、認証に成功したと判定し（ステップＳ７０６：Ｙｅｓ）、ステップＳ７０８に進む。一方、ステップＳ７０４でリクエストの主体を特定できなかった場合は、認証に失敗したと判定し（ステップＳ７０６：Ｎｏ）、ステップＳ７１０に進む。

【0049】

認証に成功した場合、ポリシー実施部２０３は、ステップＳ７０４で認証部２０２が特定した主体の情報と、受信したリクエストから取り出した操作および資源の情報とを、認可リクエストとしてポリシー判定部４０１に送信する（ステップＳ７０８）。一方、認証に失敗した場合、ＡＰＩ通信部２０１は、認証が失敗したことをクライアント３００に通知し（ステップＳ７１０）、図７のフローチャートに示す処理を終了する。

【0050】

ステップＳ７０８でポリシー実施部２０３から送信される認可リクエストを受信すると、ポリシー判定部４０１は認可処理を行い、その結果を認可レスポンスとしてポリシー実施部２０３に送信する。ポリシー実施部２０３は、ポリシー判定部４０１から送信される認可レスポンスを受信する（ステップＳ７１２）。

【0051】

ポリシー実施部２０３は、ステップＳ７１２でポリシー判定部４０１から受信した認可レスポンスの内容に基づき、ステップＳ７０２でＡＰＩ通信部２０１がクライアント３００から受信したリクエストに対して、データ５０１へのアクセスを許可するか否かを判断する（ステップＳ７１４）。ポリシー判定部４０１においてデータ５０１へのアクセスを許可すると判定され、その判定結果を示す認可レスポンスをステップＳ７１４で受信した場合は、アクセスを許可すると判定し（ステップＳ７１４：Ｙｅｓ）、ステップＳ７１６に進む。一方、ポリシー判定部４０１においてデータ５０１へのアクセスを拒否すると判定され、その判定結果を示す認可レスポンスをステップＳ７１４で受信した場合は、アクセスを拒否すると判定し（ステップＳ７１４：Ｎｏ）、ステップＳ７１８に進む。

【0052】

データ５０１へのアクセスを許可する旨の認可レスポンスをポリシー判定部４０１から受信した場合、クエリ生成部２０４は、ステップＳ７０２でＡＰＩ通信部２０１がクライアント３００から受信したリクエストに対して、データベース５００に格納されているデータ５０１から所望のレコードを取得するためのクエリを生成する（ステップＳ７１６）。例えば、データベース５００がクエリ言語としてＳＱＬを使用するデータベースであり、データ５０１において「伝票No.」の値が「ORD001」であるレコードを取得するリクエストがクライアント３００から送信された場合、これをデータベース５００に対して指示するクエリは、「select * from orders where 伝票No = 'ORD001';」のように記載される。これにより、クエリサービス２００において、クライアント３００からのデータ５０１へのアクセス要求に応じたクエリが生成される。一方、データ５０１へのアクセスを拒否する旨の認可レスポンスをポリシー判定部４０１が受信した場合、ＡＰＩ通信部２０１は、データ５０１へのアクセスが拒否されたことをクライアント３００に通知し（ステップＳ７１８）、図７のフローチャートに示す処理を終了する。

【0053】

ステップＳ７１６でクエリ生成部２０４によりクエリが生成されると、クエリ変換部２０５は、クエリ変換が必要か否かを判定する（ステップＳ７２０）。ここでは、ステップＳ７１２でポリシー実施部２０３がポリシー判定部４０１から受信した認可レスポンスに基づき、クエリ変換の有無を判定する。すなわち、受信した認可レスポンスがクエリ変換指示を含む場合、クエリ変換部２０５はクエリ変換が必要と判定し（ステップＳ７２０：Ｙｅｓ）、ステップＳ７２２の処理を実行する。一方、受信した認可レスポンスがクエリ変換指示を含まない場合、クエリ変換部２０５はクエリ変換が不要と判定し（ステップＳ７２０：Ｎｏ）、ステップＳ７２２の処理を実行せずにステップＳ７２４へ進む。

【0054】

クエリ変換が必要と判定した場合、クエリ変換部２０５は、ステップＳ７１６でクエリ生成部２０４が生成したクエリを、データベース５００に格納されているデータ５０１とデータ５０２を結合してフィルタリングさせるためのクエリに変換する（ステップＳ７２２）。例えば、ステップＳ７０４の認証で特定されたユーザ（主体）に対応する「担当者」の値が「1001」である場合、前述の例で示したＳＱＬによるクエリを変換したクエリは、「select * from orders inner join customers on (orders.受注先 = customers.顧客No) where customers.担当者 = '1001’ and orders.伝票No = 'ORD001';」のように記載される。これにより、クエリサービス２００において、ステップＳ７１６でリクエストに応じて生成したクエリから、アクセス対象のデータ５０１と、データ５０１の属性情報を含むデータ５０２とを結合し、アクセス制御ポリシー４０２に記載されたルールに基づくフィルタリングをデータベース５００に実行させるためのクエリが生成される。

【0055】

ＤＢ通信部２０６は、ステップＳ７１６でクエリ生成部２０４が生成したクエリ（ステップＳ７２２の処理を実行していない場合）、または、クエリ生成部２０４が生成したクエリをステップＳ７２２でクエリ変換部２０５が変換することにより生成された変換後のクエリを、データベース５００に送信する（ステップＳ７２４）。

【0056】

ＤＢ通信部２０６は、ステップＳ７２４で送信したクエリに応答してデータベース５００が出力するデータ５０１のレコードを取得する（ステップＳ７２６）。ＡＰＩ通信部２０１は、ステップＳ７２６でＤＢ通信部２０６が取得したデータ５０１のレコードを、ステップＳ７０２で受信したリクエストに対するレスポンスとして出力し、クライアント３００に送信する（ステップＳ７２８）。ＡＰＩ通信部２０１がリクエストに対するレスポンスをクライアント３００に送信したら、クエリサービス２００は図７の処理フローを終了する。

【0057】

図８は、データアクセス制御装置１００の認可サービス４００によって実行される処理のフローチャートである。認可サービス４００は、図７のステップＳ７０８でポリシー実施部２０３から認可リクエストが送信されると、図８のフローチャートに示す処理を開始する（ステップＳ８００）。

【0058】

ポリシー判定部４０１は、クエリサービス２００のポリシー実施部２０３から認可リクエストを受信する（ステップＳ８０２）。この認可リクエストには前述のように、クエリサービス２００がクライアント３００から受信したリクエストにおける主体、操作、資源の情報が含まれている。

【0059】

ポリシー判定部４０１は、ステップＳ８０２で受信した認可リクエストから、主体、操作、資源の各情報を取り出す。また、ポリシー管理部４０３からアクセス制御ポリシー４０２を取得し、アクセス制御ポリシー４０２に規定されているルールを抽出することで、クライアント３００から行われたデータ５０１へのアクセス要求に対するルールを取得する（ステップＳ８０４）。

【0060】

ポリシー判定部４０１は、ステップＳ８０４で認可リクエストから取り出した主体、操作、資源の各情報と、ステップＳ８０４で抽出したルールとを比較し、当該操作に対するルールの評価に、当該資源に含まれている属性情報とは別の属性情報が必要であるか否かを判定する（ステップＳ８０６）。ここでは例えば以下のようにして、別の属性情報が必要か否かの判定が行われる。

【0061】

前述のように、データ５０１において「伝票No.」の値が「ORD001」であるレコードを取得するリクエストがクライアント３００から送信され、このリクエストに対する認可リクエストをクエリサービス２００から受信したとする。また、アクセス制御ポリシー４０２に規定されているルールが、当該リクエストで指定されたレコードの「受注先」の値と、クライアント３００により当該リクエストを送信したユーザに割り当てられた担当者番号に対応する「顧客No.」の値との一致であるとする。このような場合、当該ルールを評価するためには、資源であるデータ５０１とは別のデータ５０２，５１１に含まれる属性情報である「担当者」の値を用いて、リクエストを送信したユーザの属性を判断する必要がある。そのため、このような場合はステップＳ８０６において別の属性情報が必要であると判定する。一方、別のデータ間でのレコードの比較がルールの評価において必要でない場合は、ステップＳ８０６において別の属性情報が不要であると判定し、ステップＳ８２０に進む。なお、上記の例はあくまで一例であり、様々なルールについて、その評価にあたって資源に含まれている属性情報とは別の属性情報が必要か否かを、ステップＳ８０６において判定することが可能である。

【0062】

ステップＳ８０６の判定の結果、別の属性情報が必要であると判定した場合（ステップＳ８０６：Ｙｅｓ）はステップＳ８０８に進み、不要であると判定した場合（ステップＳ８０６：Ｎｏ）はステップＳ８２０に進む。

【0063】

ステップＳ８０６で別の属性情報が必要であると判定した場合、ポリシー判定部４０１は、属性情報管理テーブル作成部４０６により作成された属性情報管理テーブル４０５を参照し、当該属性情報の配置場所とその機能の情報を属性情報管理テーブル４０５から取得する（ステップＳ８０８）。例えば前述の例では、属性情報管理テーブル４０５Ａのレコード４１１Ａ、または、属性情報管理テーブル４０５Ｂのレコード４１１Ｂを参照することで、ルールの評価に必要な属性情報の配置場所として、データベース５００に格納されているデータ５０２を示す情報、または、データベース５１０に格納されているデータ５１１を示す情報を取得することができる。さらに、この属性情報の配置場所の機能として、データベース５００がサポートする機能の情報、または、データベース５１０がサポートする機能の情報を取得することができる。

【0064】

ポリシー判定部４０１は、ステップＳ８０４で抽出したルールの条件部に示された内容が、属性と属性の比較であるか否かを判定する（ステップＳ８１０）。例えば前述のように、当該リクエストで指定されたレコードの「受注先」の値と、クライアント３００により当該リクエストを送信したユーザに割り当てられた担当者番号に対応する「顧客No.」の値とが一致するというルールの場合、このルールの条件部には、データ５０１の「受注先」の値が示す属性と、データ５０２，５１１の「顧客No.」の値が示す属性とを比較することが記述される。したがってこの場合は、ルールの条件部に示された内容が属性と属性の比較であると判定し（ステップＳ８１０：Ｙｅｓ）、ステップＳ８１２に進む。一方、ルールの条件部に示された内容が属性と属性の比較ではないと判定した場合（ステップＳ８１０：Ｎｏ）は、ステップＳ８１８に進む。

【0065】

ポリシー判定部４０１は、ステップＳ８０８で属性情報管理テーブル４０５から取得した配置場所の情報に基づき、ルールの評価で比較する属性情報の配置場所が同一であるか否かを判定する（ステップＳ８１２）。例えば前述のように、属性情報管理テーブル４０５Ａのレコード４１１Ａを参照することで、ルールの評価に必要な属性情報の配置場所がデータ５０１の格納先と同一のデータベース５００であるという情報を取得した場合は、配置場所が同一であると判定し（ステップＳ８１２：Ｙｅｓ）、ステップＳ８１４に進む。一方、配置場所が同一ではないと判定した場合（ステップＳ８１２：Ｎｏ）は、ステップＳ８１８に進む。

【0066】

ポリシー判定部４０１は、ステップＳ８０８で属性情報管理テーブル４０５から取得した配置場所の機能の情報に基づき、ルールの評価で比較する属性情報の配置場所の機能が複数のデータテーブルを結合する結合クエリをサポートしているか否かを判定する（ステップＳ８１４）。例えば前述のように、属性情報管理テーブル４０５Ａのレコード４１１Ａを参照することで、ルールの評価に必要な属性情報の配置場所であるデータベース５００が、結合クエリを使用可能なＳＱＬによって動作するという情報を取得した場合は、結合クエリをサポートしていると判定し（ステップＳ８１４：Ｙｅｓ）、ステップＳ８１６に進む。一方、結合クエリをサポートしていないと判定した場合（ステップＳ８１４：Ｎｏ）は、ステップＳ８１８に進む。

【0067】

ステップＳ８１０、Ｓ８１２、Ｓ８１４の全ての判定結果が肯定判定である場合、ポリシー判定部４０１は、ステップＳ８０４で抽出したルールから、クエリサービス２００に対するクエリ変換指示を生成する（ステップＳ８１６）。ここでは、図７のステップＳ７１６でクエリ生成部２０４により生成されるクエリを、ルールに応じた結合クエリを含む前述のようなクエリへと変換するように、クエリ変換指示を生成する。これにより、データ５０１とデータ５０２を結合してルールに基づくフィルタリングをデータベース５００に実行させるように、クエリサービス２００に対する指示を行う。ステップＳ８１６でクエリ変換指示を生成したら、ステップＳ８２２に進む。

【0068】

ステップＳ８１０、Ｓ８１２、Ｓ８１４のいずれかの判定結果が否定判定である場合、ポリシー判定部４０１は、ステップＳ８０８で取得した情報に基づき、ルールの評価に必要な属性情報を取得する（ステップＳ８１８）。ここでは例えば、属性情報管理テーブル４０５Ｂのレコード４１１Ｂを参照して得られた情報に基づき、データベース５１０からデータ５１１を読み出して属性情報を取得する。

【0069】

ステップＳ８１８を実行した場合、またはステップＳ８０６の判定結果が否定判定である場合、ポリシー判定部４０１は、ステップＳ８０４で抽出したルールを評価する（ステップＳ８２０）。ここで、ステップＳ８１８を実行した場合は、ステップＳ８０４で認可リクエストから取得した主体、操作、資源の各情報とともに、ステップＳ８１８で取得した属性情報を用いて、ルールの評価を行う。一方、ステップＳ８０６で別の属性情報が不要であると判定した場合は、ステップＳ８０４で認可リクエストから取得した主体、操作、資源の各情報に基づき、ルールの評価を行う。これにより、クエリサービス２００から受信した認可リクエストに対して、データ５０１へのアクセスを許可するか否かの判定を行う。ステップＳ８２０でルールを評価できたら、ステップＳ８２２に進む。

【0070】

ポリシー判定部４０１は、ステップＳ８０２で受信した認可リクエストに対する認可レスポンスをクエリサービス２００に送信する（ステップＳ８２２）。この認可レスポンスには、ステップＳ８１６で生成したクエリ変換指示、またはステップＳ８２０で行ったルールの評価結果のいずれかが含まれる。ポリシー判定部４０１が認可レスポンスを送信したら、認可サービス４００は図８の処理フローを終了する。

【0071】

なお、クエリサービス２００において、ポリシー実施部２０３は、図８のステップＳ８２２でポリシー判定部４０１から送信される認可レスポンスを、図７のステップＳ７１２で受信する。これにより、クエリサービス２００はステップＳ７１４以降の処理に進むことができる。

【0072】

図９は、データアクセス制御装置１００の認可サービス４００において、属性情報管理テーブル作成部４０６が属性情報管理テーブル４０５を作成する際に実行する処理のフローチャートである。属性情報管理テーブル作成部４０６は、認可サービス４００において図８の処理が実行されるよりも前に、所定のタイミングで図９のフローチャートに示す処理を開始する（ステップＳ９００）。

【0073】

属性情報管理テーブル作成部４０６は、データカタログ６００からメタデータを取得する（ステップＳ９０２）。ここでは、図５に例示したメタデータテーブル６０１Ａまたはメタデータテーブル６０１Ｂをデータカタログ６００から読み出すことにより、メタデータを取得する。

【0074】

属性情報管理テーブル作成部４０６は、ステップＳ９０２で取得したメタデータのいずれかを選択する（ステップＳ９０４）。ここでは、メタデータテーブル６０１Ａ，６０１Ｂのいずれかのレコードを選択することで、メタデータの選択を行う。

【0075】

属性情報管理テーブル作成部４０６は、ステップＳ９０４で選択したメタデータに含まれる属性情報の格納先および取得方法を特定する（ステップＳ９０６）。ここでは例えば、選択したレコードに含まれる各項目の内容から、当該メタデータが表す属性情報を含むデータの識別名や、そのデータが格納されているデータベースや、そのデータベースの機能などを特定することで、属性情報の格納先と取得方法を特定することができる。あるいは、サービス提供システム１の管理者によって入力された情報から、属性情報の格納先と取得方法を特定してもよいし、これらの特定方法を組み合わせてもよい。これ以外にも、任意の方法で属性情報の格納先および取得方法を特定することが可能である。

【0076】

属性情報管理テーブル作成部４０６は、ステップＳ９０６で取得した属性情報の格納先および取得方法に基づき、当該属性情報に関する情報を表すレコードである属性情報レコードを作成し、属性情報管理テーブル４０５Ａまたは属性情報管理テーブル４０５Ｂに格納する（ステップＳ９０８）。

【0077】

ステップＳ９０８で属性情報レコードを属性情報管理テーブル４０５Ａ，４０５Ｂに格納したら、属性情報管理テーブル作成部４０６は、ステップＳ９０４において全てのメタデータを選択済みであるか否かを判定する（ステップＳ９１０）。メタデータテーブル６０１Ａ，６０１Ｂにおいて全てのレコードを選択済みである場合は、全てのメタデータを選択済みであると判定し（ステップＳ９１０：Ｙｅｓ）、図９の処理フローを終了する。一方、メタデータテーブル６０１Ａ，６０１Ｂにおいて未選択のレコードが存在する場合は、全てのメタデータを選択済みではないと判定し（ステップＳ９１０：Ｎｏ）、ステップＳ９０４に戻ってメタデータの選択を継続する。

【0078】

属性情報管理テーブル作成部４０６は、以上説明した処理を実行することにより、メタデータテーブル６０１Ａから属性情報管理テーブル４０５Ａ、またはメタデータテーブル６０１Ｂから属性情報管理テーブル４０５Ｂを作成することができる。

【0079】

以上説明した本発明の第１の実施形態によれば、以下の作用効果を奏する。

【0080】

（１）データアクセス制御装置１００は、予め設定されたアクセス制御ポリシー４０２に基づいて、データ５０１へのアクセス要求に対するルールを取得し（ステップＳ８０４）、データ５０１が格納されたデータベース５００の外部から、データ５０１の各レコードの属性に関する属性情報を取得するか否かを選択する（ステップＳ８１０～Ｓ８１４）。その結果、属性情報を取得すると選択した場合（ステップＳ８１０：Ｎｏ、ステップＳ８１２：Ｎｏ、またはステップＳ８１４：Ｎｏ）、属性情報を取得して（ステップＳ８１８）属性情報に基づくルールの評価を行い（ステップＳ８２０）、属性情報を取得しないと選択した場合（ステップＳ８１０，Ｓ８１２，Ｓ８１４：Ｙｅｓ）、データベース５００にルールに基づくデータ５０１のフィルタリングを実行させる（ステップＳ８１６，Ｓ７２２，Ｓ７２４）。そして、ステップＳ８２０で行ったルールの評価結果、またはデータベース５００によるフィルタリングの実行結果に基づいて、アクセス要求に対応するデータ５０１のレコードをデータベース５００から取得する（ステップＳ７２６）。このようにしたので、アクセス制御ポリシー４０２で規定されたルールの評価に必要な情報がデータベース５００に格納されているか否かに関わらず、ルールの評価を確実に行うことができる。したがって、アクセス制御ポリシーの維持管理が容易なデータアクセス制御技術を提供することが可能となる。

【0081】

（２）データアクセス制御装置１００は、データベース５００に属性情報を含むデータ５０２が格納されている場合（ステップＳ８１２：Ｙｅｓ）、データベース５００の外部から属性情報を取得しないと選択し、データベース５００にデータ５０２が格納されていない場合（ステップＳ８１２：Ｎｏ）、データベース５００の外部から属性情報を取得すると選択する。このようにしたので、データ５０２の有無に応じて、データベース５００の外部から属性情報を取得するか否かを適切に選択することができる。

【0082】

（３）データアクセス制御装置１００は、データベース５００の外部から属性情報を取得しないと選択した場合、データ５０１とデータ５０２を結合することで、データベース５００にフィルタリングを実行させる（ステップＳ８１６，Ｓ７２２，Ｓ７２４）。このようにしたので、データアクセス制御装置１００においてルールの評価を行う必要がないため、データ５０１へのアクセス時のオーバーヘッドを低減し、高速なアクセス制御を実現することが可能となる。

【0083】

（４）ただし、データベース５００にデータ５０２が格納されている場合であっても、データベース５００においてデータ５０１とデータ５０２を結合できない場合（ステップＳ８１４：Ｎｏ）は、データベース５００の外部から属性情報を取得すると選択する。このようにしたので、データベース５００が複数のデータテーブルを結合する機能を有していない場合でも、ルールの評価を確実に行うことができる。

【0084】

（５）データアクセス制御装置１００は、例えばコンピュータであるプロセッサ１０１により、アクセス要求に応じたクエリを生成するクエリサービス２００と、アクセス要求に対してアクセス制御ポリシー４０２に基づく認可処理を行う認可サービス４００とを提供する。認可サービス４００では、ポリシー判定部４０１により、データベース５００の外部から属性情報を取得するか否かを選択する（ステップＳ８１０～Ｓ８１４）。そして、属性情報を取得すると選択した場合、属性情報の取得およびルールの評価を行い（ステップＳ８１８，Ｓ８２０）、属性情報を取得しないと選択した場合、データベース５００にフィルタリングを実行させるためのクエリをクエリサービス２００から出力させるようにする（ステップＳ８１６，Ｓ７２２，Ｓ７２４）。このようにしたので、コンピュータを用いてデータアクセス制御装置１００を実現することができる。

【0085】

（６）クエリサービス２００では、クエリ変換部２０５により、認可サービス４００からの指示に応じて、クエリ生成部２０４が生成したクエリをデータベース５００にフィルタリングを実行させるためのクエリに変換する（ステップＳ７２２）。そして、ＤＢ通信部２０６により、データベース５００に出力する（ステップＳ７２４）。このようにしたので、ルールに基づくデータ５０１のフィルタリングを、データベース５００に確実に実行させることができる。

【0086】

（７）データアクセス制御装置１００は、属性情報の配置場所とその機能を示す属性情報管理テーブル４０５を参照して（ステップＳ８０８）、データベース５００の外部から属性情報を取得するか否かを選択する。このようにしたので、データベース５００の外部から属性情報を取得するか否かの選択を、確実かつ容易に行うことができる。

【0087】

（８）データアクセス制御装置１００は、属性情報管理テーブル作成部４０６により、データ５０１が格納されたデータベース５００と、属性情報を含むデータ５０２，５１１が格納されたデータベース５００，５１０とに関するメタデータを、メタデータテーブル６０１Ａ，６０１Ｂから取得する（ステップＳ９０２，Ｓ９０４）。そして、取得したメタデータに基づいて属性情報管理テーブル４０５Ａ，４０５Ｂを作成する（ステップＳ９０６，Ｓ９０８）。このようにしたので、属性情報の配置場所とその機能を示す属性情報管理テーブルを、確実かつ容易に作成することができる。

【0088】

（９）属性情報管理テーブル４０５Ａ，４０５Ｂの作成に用いられるメタデータは、図５のメタデータテーブル６０１Ａ，６０１Ｂの各レコードに例示するように、データベース５００およびデータベース５１０がそれぞれサポートする機能の情報と、データ５０１およびデータ５１１の所属先のデータベースの情報とを含む。このようにしたので、属性情報管理テーブル４０５Ａ，４０５Ｂを作成するのに必要な情報を、メタデータから確実に取得することができる。

【0089】

［第２の実施形態］
次に、本発明の第２の実施形態について説明する。以下では、第１の実施形態との相違点を主に説明し、第１の実施形態との共通点については、特に必要のない限りは、その説明を省略または簡略する。

【0090】

本実施形態では、データベース５００とデータベース５１０が仮想化レイヤを介してデータアクセス制御装置１００にそれぞれ接続されている例を説明する。

【0091】

図１０は、本発明の第２の実施形態に係るデータアクセス制御装置を含むサービス提供システムの構成を示すブロック図である。図１０に示すサービス提供システム１Ａは、第１の実施形態で説明した図１のサービス提供システム１と同様に、データアクセス制御装置１００、クライアント３００、データベース５００および５１０、データカタログ６００を備える。本実施形態では、データベース５００，５１０が仮想化レイヤ７００を介してデータアクセス制御装置１００にそれぞれ接続されている点と、データカタログ６００にメタデータテーブル６０２が格納されている点が、第１の実施形態と異なっている。仮想化レイヤ７００は、別々のデータベース５００，５１０に格納されているデータ５０１，５０２，５１１が、あたかも単一のデータベースに格納されているかのように、データアクセス制御装置１００がデータベース５００，５１０に対してクエリを発行できるインタフェースを提供する。

【0092】

図１１は、本発明の第２の実施形態においてデータカタログ６００に格納されるメタデータテーブル６０２の例を示す図である。図１１に示すメタデータテーブル６０２は、第１の実施形態で説明した図５のメタデータテーブル６０１Ａ，６０１Ｂと比べて、仮想化レイヤ７００の情報を示すレコード６１２が追加されている。また、メタデータテーブル６０２の各レコードのうち、データ５０１，５０２，５１１のレコードでは、接続先が仮想化レイヤ７００であることを示す情報がカラム６１３に追加されている。

【0093】

本実施形態では、属性情報管理テーブル作成部４０６において、メタデータテーブル６０２に基づいて属性情報管理テーブル４０５を作成する。このとき、データ５１１に基づく属性情報の格納先や取得方法を示すレコードにおいて、仮想化レイヤ７００の情報を含めるように、属性情報管理テーブル４０５が作成される。

【0094】

また本実施形態では、クエリサービス２００は、図７のステップＳ７２２において、ステップＳ７１６でクエリ生成部２０４が生成したクエリを、データ５０１とデータ５１１を仮想化レイヤ７００を介して結合することで、アクセス制御ポリシー４０２に記載されたルールに基づくフィルタリングをデータベース５００に実行させるためのクエリに変換する。これにより、データ５０１とデータ５１１が異なるデータベース５００，５１０に格納されていても、これらのデータを結合し、ルールに基づくフィルタリングを実行することが可能となる。

【0095】

以上説明したように、本実施形態のサービス提供システム１Ａにおいて、データベース５００およびデータベース５１０は、仮想化レイヤ７００を介して、属性情報管理テーブル４０５を作成するコンピュータであるデータアクセス制御装置１００とそれぞれ接続されている。また、データカタログ６００に格納されたメタデータテーブル６０２は、仮想化レイヤ７００の情報をさらに含む。データアクセス制御装置１００は、データ５０１とデータ５１１を仮想化レイヤ７００を介して結合することで、データベース５００にフィルタリングを実行させる。このようにしたので、データ５０１とデータ５１１が異なるデータベース５００，５１０に格納されていても、これらのデータを結合し、ルールに基づくフィルタリングを実行することができる。

【0096】

なお、メタデータテーブル６０２の各レコードにおいて、仮想化レイヤ７００を介したデータ結合の有効性を示す情報や、データ結合の優先度の情報をさらに含めるようにしてもよい。このようにすれば、異なるデータベース間での仮想化レイヤ７００を介したデータ結合によるフィルタリングを実行するか否かを、データごとにさらに適切に判断することが可能となる。

【0097】

本発明は上記実施形態に限定されるものではなく、その要旨を逸脱しない範囲内で、任意の構成要素を用いて実施可能である。例えば、図３に示したクエリサービス２００や認可サービス４００の各機能ブロックを、それぞれ異なるハードウェアにより実現してもよい。あるいは、いずれかの機能ブロックをクライアント３００に含めてもよいし、データベース５００やデータベース５１０に含めてもよい。さらに、図３の各機能ブロックの一部または全部を、ＦＰＧＡ（Field-Programmable Gate Array）等のハードウェアにより実現してもよい。

【0098】

以上説明した実施形態や変形例はあくまで一例であり、発明の特徴が損なわれない限り、本発明はこれらの内容に限定されるものではない。また、上記では種々の実施形態や変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

【符号の説明】

【0099】

１，１Ａ…サービス提供システム、１００…データアクセス制御装置、１０１…プロセッサ、１０２…メモリ、１０３…ストレージ、１０４…ネットワークＩ／Ｆ、１０５…コンソール、１０６…ネットワーク、２００…クエリサービス、２０１…ＡＰＩ通信部、２０２…認証部、２０３…ポリシー実施部、２０４…クエリ生成部、２０５…クエリ変換部、２０６…ＤＢ通信部、３００…クライアント、４００…認可サービス、４０１…ポリシー判定部、４０２…アクセス制御ポリシー、４０３…ポリシー管理部、４０４…属性情報取得部、４０５…属性情報管理テーブル、４０６…属性情報管理テーブル作成部、５００…データベース、５０１，５０２…データ、５１０…データベース、５１１…データ、６００…データカタログ、６０１，６０２…メタデータテーブル、７００…仮想化レイヤ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】