JP2021157738A - データアクセス制御システム及びデータアクセス制御方法 - Google Patents

Abstract

【課題】アクセス制御の設定に要する工数を減ずるデータアクセス制御システム及びデータアクセス制御方法を提供する。【解決手段】データアクセス制御システムにおいて、データレイク管理部は、データファイルのメタデータをメタデータテーブルに格納し、データファイルを加工した加工データの識別子と加工元のデータファイルの識別子とをリニエージテーブルに格納する。次に、データアクセス制御システムは、リニエージテーブル及びメタデータテーブルを参照して所定のアクセス制御ポリシーを生成してポリシーテーブルに格納し、ポリシーテーブルを参照して加工データに適用又は推薦すべきアクセス制御ポリシーを提供する。【選択図】図３

Description

本発明は、データアクセス制御システム及びデータアクセス制御方法に関する。

近年、企業内の多様なデータを共有し利活用を推進することを目的としたデータレイクが構築されている。しかし、その規模が拡大するにつれ、データへのアクセス可否を定義するアクセス制御ポリシーを個々のデータに適用する運用が複雑化している。

これに関連する技術として、例えば、特許文献１、特許文献２がある。特許文献１は、ファイルを共有する相手を推薦する。その相手への共有がアクセス制御ポリシーに違反しないかをチェックする。特許文献２は、リソースが木構造の階層関係を持つことを前提として、親となるリソースへのアクセス許可を子リソースに引き継ぐ。

米国特許公開ＵＳ２０１２／０３１７１３５号公報 米国特許公開ＵＳ２０１５／０１８０８７２号公報

特許文献１は、組織内の階層に基づくアクセス制御ポリシーが既に定義されており、そのポリシーが許す範囲内でファイルを共有することを目的としている。しかし、共有すべき相手が既定のポリシーの許可範囲内に限定されるとは限らない。

また、特許文献２は，アクセス制御の対象となるリソース（データ）群に、自明な階層関係が存在することを前提としている。しかし、データレイクに格納されるデータは必ずしもそのように整理整頓された状態にあるわけではない。

このように、特許文献１及び特許文献２は、アクセス制御の要件が組織又はデータの階層関係により規定されるという前提に基づいてポリシー定義の複雑さを解消する技術である。しかし、特許文献１及び特許文献２では、多様なデータを組織横断的に共有することを目的とするデータレイクにおいて、アクセス制御の設定に要する工数を減ずるには不十分である。

本発明の目的は、データアクセス制御システムにおいて、アクセス制御の設定に要する工数を減ずることにある。

本発明の一態様のデータアクセス制御システムは、データレイクを有するデータアクセス制御システムであって、前記データレイクは、データファイルを有するデータストアと、前記データファイルに格納されている処理元のデータを処理して処理先の処理データを生成するデータ処理部と、メタデータ管理部とポリシー管理部とを有するデータレイク管理部と、を有し、前記メタデータ管理部は、メタデータ収集部とリニエージ収集部とメタデータテーブルとリニエージテーブルを有し、前記ポリシー管理部は、ポリシー設定部とポリシーテーブルとポリシー提供部を有し、前記リニエージテーブルは、前記データファイルのデータリニエージ情報を格納し、前記データ処理部は前記データファイルの前記データリニエージ情報を、前記リニエージ収集部に送信し、前記リニエージ収集部は、前記データリニエージ情報を収集して、前記リニエージテーブルに格納し、前記データファイルのメタデータは、前記メタデータ収集部に送られ、前記メタデータ収集部は、前記メタデータを収集して前記メタデータテーブルに格納し、前記ポリシー設定部は、前記リニエージテーブル及び前記メタデータテーブルを参照して、所定のアクセス制御ポリシーを生成して前記ポリシーテーブルに格納し、前記ポリシー提供部は、前記ポリシーテーブルを参照して、前記処理データに適用又は推薦すべきアクセス制御ポリシーを提供することを特徴とする。

本発明の一態様のデータアクセス制御方法は、データリニエージの途中にあるプログラムの処理内容に応じてアクセス制御ポリシーを適用するデータアクセス制御方法であって、データの処理によって生成された処理先のデータに、処理元のデータのアクセス制御ポリシーを適用することを特徴とする。

本発明の一態様のデータアクセス制御方法は、データリニエージの途中にあるプログラムの処理内容に応じてアクセス制御ポリシーを変更するデータアクセス制御方法であって、データの処理によるデータリニエージに基づいて、新たなデータに適用すべきアクセス制御ポリシーとして、変更後の前記アクセス制御ポリシーを推薦することを特徴とする。

本発明の一態様によれば、データアクセス制御システムにおいて、アクセス制御の設定に要する工数を減ずることができる。

実施例１の情報処理装置の構成を示す図である。 実施例１のデータアクセス制御システムの構成を示す図である。 データレイク管理部２０４の構成を示す図である。 メタデータテーブル２０６１Ａの構成を示す図である。 データ加工部２０３Ａを用いたリニエージテーブル２０６２Ａの構成を示す図である。 タグテーブル２０６３の構成を示す図である。 ポリシーテーブル２０７１Ａの構成を示す図である。 単純伝播によるポリシー適用の動作を示す図である。 ポリシーテーブル２０７１Ｂの構成を示す図である。 履歴に基づくアクセス制御ポリシーの推薦の動作を示す図である。 実施例３のデータアクセス制御システムの構成を示す図である。 メタデータテーブル２０６１Ｂの構成を示す図である。 データ複製部２１０を用いたリニエージテーブル２０６２Ｂの構成を示す図である。 ポリシーテーブル２０７１Ｃの構成を示す図である。 履歴に基づくアクセス制御ポリシーの推薦の動作を示す図である。 メタデータテーブル２０６１Ｃの構成を示す図である。 データ加工部２０３Ｂを用いたリニエージテーブル２０６２Ｃの構成を示す図である。 ポリシーテーブル２０７１Ｄの構成を示す図である。 アクセス制御ポリシー適用の動作を示す図である。 ポリシーテーブル２０７１Ｅの構成を示す図である。

以下、図面を用いて、実施例について説明する。なお、以下に説明する実施例は特許請求の範囲に係る発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

以下の説明では、「ａａａテーブル」といった表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ａａａテーブル」を「ａａａ情報」と言うことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。

図１を参照して、実施例１の情報処理装置の構成について説明する。
情報処理装置１００は、プロセッサ１０１、メモリ１０２、ストレージ１０３、ネットワークＩ／Ｆ１０４及びコンソール１０５を有する。プロセッサ１０１は、内部バス等を介して、メモリ１０２、ストレージ１０３、ネットワークＩ／Ｆ１０４、及びコンソール１０５と接続されている。なお、情報処理装置１００は、処理負荷の分散や可用性の向上等を目的として、プロセッサ１０１、メモリ１０２、ストレージ１０３、ネットワークＩ／Ｆ１０４、及びコンソール１０５の一部又は全部を複数有してもよい。情報処理装置１００は、ネットワークＩ／Ｆ１０４を介してネットワーク１０６に接続されている。

プロセッサ１０１は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）等のハードウェアによる演算装置であり、メモリ１０２に格納されたプログラムを実行する。メモリ１０２は、例えば、揮発性の半導体メモリから構成され、プログラムやデータを一時的に記憶する。

ストレージ１０３は、例えば、ハードディスクドライブ（ＨＤＤ：Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ソリッドステートドライブ（ＳＳＤ：Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、又はこれらを複数台組み合わせた不揮発性の記憶デバイスであり、プログラムやデータを長期間記憶する。ストレージ１０３は、例えば、オペレーティングシステム（ＯＳ：Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やユーザプログラムを記憶する。ストレージ１０３に格納されたオペレーティングシステムや、ユーザプログラムは、情報処理装置１００の起動時や、処理の実行時にメモリ１０２に読み出される。なお、メモリ１０２に読み出されたオペレーティングシステム及びユーザプログラムは、プロセッサ１０１によって実行され、各種機構が実現される。

ネットワークＩ／Ｆ１０４は、例えば、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ）等の通信デバイスで構成され、ネットワーク１０６と接続される。ネットワークＩ／Ｆ１０４は、ネットワーク１０６を介しての他の装置との通信時のプロトコル制御を行う。

コンソール１０５は、例えば、キーボード及びマウス等の入力装置と、液晶表示パネル等のディスプレイ装置とを備える。コンソール１０５は、入力装置による各種操作入力に応じた操作信号を受信して操作入力の内容をプロセッサ１０１に通知する。また、コンソール１０５は、プロセッサ１０１から出力されるテキスト情報やグラフィカル情報に基づくテキストや画像等をディスプレイ装置に表示する。

図２を参照して、実施例１のデータアクセス制御システムの構成について説明する。
データアクセス制御システムは、データレイク２００、ユーザプログラム３００、ＩＤプロバイダ４００を有する。ＩＤプロバイダ４００は、ユーザＩＤを提供する。データレイク２００は、データストア２０１、データ加工部２０３、データレイク管理部２０４及びアクセス制御部２０５を有する。データストア２０１は、データファイル２０２を有する。データレイク管理部２０４は、メタデータ管理部２０６及びポリシー管理部２０７を有する。アクセス制御部２０５は、ポリシー決定部２０８及びポリシー実施部２０９を有する。

データアクセス制御システムは、ユーザプログラム３００によるデータファイル２０２へのアクセスを制御することを目的とする。

アクセスの制御は、アクセス制御ポリシーに従って実施される。アクセス制御ポリシーは、操作主体に対応する権限のリストである。ポリシーによって、操作主体と権限との関係を管理する。すなわち、アクセス制御ポリシーは、操作主体と権限との関係を定義する。ここで、「操作主体」は、ユーザが所属することで同じ権限集合が付与される役割に対して付与される識別子である。一般的には、所属部署や役職、担当するプロジェクト・業務内容・作業項目などの識別子が使用される。こうしたアクセス制御ポリシーは、企業の内部統制の実現手段として、また法規制や企業間の契約を遵守するための手段として適用される。

データアクセス制御システムでは、ユーザプログラム３００によるデータファイル２０２へのアクセス要求をポリシー実施部２０９が検知すると、ポリシー決定部２０８がアクセス制御ポリシーに基づいて、ユーザプログラム３００の操作主体によるデータファイル２０２へのアクセスの可否を判定する。ポリシー決定部２０８は可否判定の結果をポリシー実施部２０９に通知し、ポリシー実施部２０９はユーザプログラム３００によるデータファイル２０２へのアクセスを許可ないし拒否する。

データアクセス制御システムは、物理的に一つ、又は複数の情報処理装置１００で構成してもよい。データアクセス制御システムが有する各要素は、メモリ１０２にプログラムまたはデータとして格納され、またストレージ１０３にプログラムまたはデータとして格納される。なお、データアクセス制御システムを物理的に複数の情報処理装置で構成する場合には、各情報処理装置１００のプロセッサ１０１はネットワーク１０６を介してデータ通信を行うようにすればよい。

図３を参照して、データレイク管理部２０４の詳細な構成について説明する。
データレイク管理部２０４は、メタデータ管理部２０６及びポリシー管理部２０７を有する。メタデータ管理部２０６は、メタデータ収集部２０６４、リニエージ収集部２０６５、メタデータテーブル２０６１、リニエージテーブル２０６２、タグテーブル２０６３及びタグ登録部２０６６を有する。ポリシー管理部２０７は、ポリシー提供部２０７３、ポリシーテーブル２０７１及びポリシー設定部２０７２を有する。

図３を参照して、データレイク管理部２０４の動作について説明する。
データ加工部２０３で加工された加工データの識別子（ｉｄ）と、その加工元データの識別子は、リニエージ収集部２０６５に送られてリニエージテーブル２０６２に格納される。データファイル２０２のメタデータは、メタデータ収集部２０６４で収集されてメタデータテーブル２０６１に格納される。タグ登録部２０６６は、タグテーブル２０６３にタグを格納する。ここで、メタデータとは、あるデータそのものではなく、そのデータを表す属性や関連する情報を記述したデータのことである。データを効率的に管理したり検索したりするためには、メタデータの適切な付与と維持が重要となる。

リニエージテーブル２０６２、メタデータテーブル２０６１及びタグテーブル２０６３に格納されたデータは、ポリシー設定部２０７２に送られる。ポリシー設定部２０７２は、リニエージテーブル２０６２、メタデータテーブル２０６１及びタグテーブル２０６３に格納されたデータに基づいて、アクセス制御ポリシーを設定してポリシーテーブル２０７１に格納する。

ポリシーテーブル２０７１に格納されたデータは、ポリシー提供部２０７３に送られる。ポリシー提供部２０７３は、ポリシーテーブル２０７１に格納されたデータに基づいてアクセス制御ポリシーをポリシー決定部２０８に提供する。

図４を参照して、メタデータテーブル２０６１Ａの構成について説明する。
メタデータテーブル２０６１Ａは、ｉｄ、型（ｔｙｐｅ）、識別名（ｎａｍｅ）、所属（ｂｅｌｏｎｇｓＴｏ）の項目を有する。例えば、ｉｄ“Ｄ００１”には、型“Ｔａｂｌｅ”、識別名“ｓｏｕｒｃｅ．ｃｓｖ”が格納されている。また、ｉｄ“Ｄ００２”には、型“Ｔａｂｌｅ”、識別名“ｔａｒｇｅｔ．ｃｓｖ”が格納されている。

例えば、メタデータテーブル２０６１Ａのｉｄ“Ｄ００１”で特定されるデータは、“Ｔａｂｌｅ”型であり、顧客情報を格納する。“Ｄ００１”は複数の“Ｃｏｌｕｍｎ”型データから構成され、“ｃｕｓｔｏｍｅｒ＿ｎａｍｅ”は顧客の“名前”を表し、“ｐｒｅｆｅｃｕｔｕｒｅ”は“県”を表し、“ｆｕｌｌ＿ａｄｄｒｅｓｓ”は“住所”を表す。

図５を参照して、データ加工部２０３Ａを用いて、リニエージテーブル２０６２Ａの構成について説明する。
図５（ｂ）に示すように、リニエージテーブル２０６２Ａは、ｉｄ、識別名（ｎａｍｅ）、加工元（ｉｎｐｕｔ）、加工先（ｏｕｔｐｕｔ）の項目を有する。例えば、ｉｄ“Ｌ００１”の識別名には、“ｒｅｍｏｖｅ＿ｐｉｉ”が格納され、加工元には“Ｄ００１”が格納され、加工先には“Ｄ００２”が格納されている。

図５（ａ）に示すように、データファイル２０２Ａのデータ“ｓｏｕｒｃｅ．ｃｓｖ”がデータ加工部２０３Ａで加工されてデータファイル２０２Ｂのデータ“ｔａｒｇｅｔ．ｃｓｖ”が加工データとして生成されたとする。この場合、データ加工部２０３Ａは、“ｒｅｍｏｖｅ＿ｐｉｉ”という識別名で特定される。“ｒｅｍｏｖｅ＿ｐｉｉ”で特定されるデータ加工部２０３Ａの加工内容は、データから“ＰＩＩ（個人情報）”というタグが付与されたカラムを削除する加工である。

この加工により、図５（ｂ）に示すように、リニエージテーブル２０６２Ａのｉｄには“Ｌ００１”が格納され、識別名には“ｒｅｍｏｖｅ＿ｐｉｉ”が格納され、加工元には“Ｄ００１”が格納され、加工先には“Ｄ００２”がそれぞれ格納される。つまり、データ加工部２０３Ａで、“ｒｅｍｏｖｅ＿ｐｉｉ”という加工が行われた場合、リニエージテーブル２０６２Ａには、そのデータの加工による来歴情報（データリニエージ）として、“ｒｅｍｏｖｅ＿ｐｉｉ”、“Ｄ００１”“Ｄ００２”がそれぞれ格納される。

このように、データリニエージの途中にあるデータ加工部２０３の加工内容によっては、加工後（加工先）のデータに対して、加工内容に応じてアクセス制御ポリシーを変更して適用することがある。例えば、データから“ＰＩＩ（個人情報）“というタグが付与されたカラムが削除されれば、全てのユーザが読み取り可能であるという内容のアクセス制御ポリシーが適用される。また、カラムの削除に代えて、カラムのマスク処理であっても同様にアクセス制御ポリシーを変更して適用することがある。

図６を参照して、タグテーブル２０６３の構成について説明する。
タグテーブル２０６３は、ｉｄ、タグ１（ｔａｇ１）、タグ２（ｔａｇ２）及びタグ３（ｔａｇ３）の項目を有する。例えば、ｉｄ“Ｄ００１”にはタグ１に“ＰＩＩ”が格納されている。また、ｉｄ“Ｄ００２”にはタグ１に“ＰＩＩ−ｆｒｅｅ”が格納されている。ここで、“ＰＩＩ“は個人情報を表し、”ＰＩＩ−ｆｒｅｅ“は個人情報がないことを表す。“ｒｅｍｏｖｅ−ＰＩＩ”は個人情報の削除を表す。

このようにタグテーブル２０６３は、任意の識別子（ｉｄ）について、それに対応する任意の文字列情報としてタグを格納することができる。また識別子に対応するタグの数は３を上限とするものではなく、任意数を格納することができる。例えばタグとして、ある識別子（ｉｄ）が対応するところのデータが、企業の内部統制上、あるいは法規制や企業間の契約において定義される特定のステータスにあることを示す文字列を格納してもよい。また、ある識別子（ｉｄ）が対応するところのリニエージが、加工元／加工先データの前記ステータスを変更するものであることを示す文字列を格納してもよい。

図７を参照して、ポリシーテーブル２０７１Ａの構成について説明する。
ポリシーテーブル２０７１Ａは、ｉｄ、操作主体（ｓｕｂｊｅｃｔ）、資源（ｒｅｓｏｕｒｃｅ）、操作（ａｃｔｉｏｎ）、結果（ｅｆｆｅｃｔ）、状態（ｓｔａｔｕｓ）の項目を有する。

例えば、ｉｄ“Ｒ００１”には、操作主体“ＰｒｉｖｉｌｅｇｅｄＵｓｅｒ（特権ユーザ）”、資源“Ｄ００１”、操作“ｒｅａｄ”、結果“Ｐｅｒｍｉｔ”、状態“ｅｎｄｏｒｓｅｄ”が格納されている。

また、ｉｄ“Ｒ００２”には、操作主体“ＡｎｙＳｕｂｊｅｃｔ（全てのユーザ）”、資源“Ｄ００１”、操作“ＡｎｙＡｃｔｉｏｎ”、結果“Ｄｅｎｙ”、状態“ｅｎｄｏｒｓｅｄ”が格納されている。

また、ｉｄ“Ｒ００３”には、操作主体“ＰｒｉｖｉｌｅｇｅｄＵｓｅｒ（特権ユーザ）”、資源“Ｄ００２”、操作“ｒｅａｄ”、結果“Ｐｅｒｍｉｔ”、状態“ｃａｎｄｉｄａｔｅ”が格納されている。

また、ｉｄ“Ｒ００４”には、操作主体“ＡｎｙＳｕｂｊｅｃｔ（全てのユーザ）”、資源“Ｄ００２”、操作“ＡｎｙＡｃｔｉｏｎ”、結果“Ｄｅｎｙ”、状態“ｃａｎｄｉｄａｔｅ”が格納されている。

ポリシーは複数のルールからなる。各ルールは、操作主体（ｓｕｂｊｅｃｔ）、資源（ｒｅｓｏｕｒｃｅ）、操作（ａｃｔｉｏｎ）の３つの条件と、これらの３つの条件が成立したときに決定するアクセス可否判定の結果（ｅｆｆｅｃｔ）からなる。ルール群は上から下へと順に評価され、全ての条件が成立し結果が導かれると評価は終了する。どのルールによっても条件が成立しなかった場合は、デフォルトの判定結果（例えば“Ｄｅｎｙ“）を採用する。

操作主体の識別子として、ユーザのＩＤをそのまま識別子としてもよいし、ロール名を識別子としてもよい。例えば“ＰｒｉｖｉｌｅｇｅｄＵｓｅｒ“はロール名であり、特権ユーザを意味する。あるユーザが“ＰｒｉｖｉｌｅｇｅｄＵｓｅｒ”のロールを持つかどうかは、ＩＤプロバイダ４００から得られるユーザの属性情報により判定できる。

状態（ｓｔａｔｕｓ）は、ルールが実際にポリシー決定部２０８によるアクセス制御に供されるべく管理者によって承認された（ｅｎｄｏｒｓｅｄ）実効性のあるものであるか、それともその候補（ｃａｎｄｉｄａｔｅ）として管理者による承認を待つ状態にあるであるものかを示す情報である。

次に、図８のフローチャートを参照して、単純伝播によるポリシー適用の動作について説明する。このポリシー設定部２０７２によるポリシーテーブル２０７１Ａの作成手順である。

新規に追加されたデータファイルＤ００２に付与するアクセス制御ポリシー（複数のルール）の候補を追加する。リニエージテーブル２０６２Ａを走査してＤ００２の加工元のデータファイルであるＤ００１を抽出し、Ｄ００１のアクセス制御ポリシーであるＲ００１、Ｒ００２を複製して（ただし、資源（ｒｅｓｏｕｒｃｅ）の列をＤ００２に変える）、Ｒ００３、Ｒ００４を追加する。状態（ｓｔａｔｕｓ）の列は“ｃａｎｄｉｄａｔｅ”として、管理者による承認を待つ。

図８のフローチャートを参照すると、最初に、メタデータテーブル２０６１Ａを走査する（Ｓ８０２）。
次に、新規追加データファイル（Ｄ００２）を検知する（Ｓ８０４）。
次に、ポリシーテーブル２０７１Ａを参照して、新規追加データファイル（Ｄ００２）にアクセス制御ポリシーはあるかを判定する（Ｓ８０６）。

判定の結果、新規追加データファイル（Ｄ００２）に対するアクセス制御ポリシーがある場合は、処理は終了する。
判定の結果、新規追加データファイル（Ｄ００２）に対するアクセス制御ポリシーがない場合には、リニエージテーブル２０６２Ａを走査する（Ｓ８０８）。

次に、リニエージテーブル２０６２Ａの走査により、リニエージテーブル２０６２Ａに加工元のデータファイルがあるかを判定する（Ｓ８１０）。

判定の結果、リニエージテーブル２０６２Ａに加工元のデータファイル（Ｄ００１）がある場合は、ポリシーテーブル２０７１Ａから加工元のデータファイル（Ｄ００１）のアクセス制御ポリシーＲ００１、Ｒ００２を検知する。そして、加工元のデータファイル（Ｄ００１）のアクセス制御ポリシーＲ００１、Ｒ００２を複製して、ポリシーテーブル２０７１Ａに新規追加データファイル（Ｄ００２）に対するアクセス制御ポリシーＲ００３、Ｒ００４として追加する（Ｓ８１２）。

判定の結果、リニエージテーブル２０６２Ａに加工元のデータファイルがない場合には、デフォルトのアクセス制御ポリシーを追加する（Ｓ８１４）。

このようにして、新規追加データファイル（Ｄ００２）には、加工元のデータファイル（Ｄ００１）と同じアクセス制御ポリシーＲ００３、Ｒ００４が適用される。これを単純伝播によるアクセス制御ポリシーの適用という。

次に、図１０のフローチャートを参照して、履歴に基づくアクセス制御ポリシーの推薦の動作について説明する。ポリシー設定部２０７２による図９に示すポリシーテーブル２０７１Ｂの作成手順である。
新規に追加されたデータファイルＤ０１０に付与するポリシーの候補を追加する。図５（ｂ）のリニエージテーブル２０６２Ａを走査してＤ０１０の加工元のデータファイルであるＤ００９を抽出する。

さらに、Ｄ００９を元にＤ０１０を生成したリニエージＬ００４について、その識別名（＝ｒｅｍｏｖｅ＿ｐｉｉ）、加工元／加工先データファイルの型（“Ｔａｂｌｅ／Ｔａｂｌｅ”）が一致する他のリニエージを探す（ステップＳ１０１２）。

ここで、メタデータテーブル２０６１Ａを走査すると、加工元のデータファイル（Ｄ００９）の型は“Ｔａｂｌｅ”であり、加工先のデータファイル（Ｄ０１０）の型も“Ｔａｂｌｅ”である。一方、メタデータテーブル２０６１Ａを走査すると、加工元のデータファイル（Ｄ００１）の型は“Ｔａｂｌｅ”であり、加工先のデータファイル（Ｄ００２）の型も“Ｔａｂｌｅ”である。よって、リニエージＬ００４の加工元と加工先の型（＝Ｔａｂｌｅ／Ｔａｂｌｅ）は、リニエージＬ００１の加工元と加工先の型（“Ｔａｂｌｅ／Ｔａｂｌｅ”）と一致する。

このように型が一致するリニエージＬ００１が見つかるので、その加工先のデータファイルＤ００２のアクセス制御ポリシーであるＲ００３を複製して（ただし資源（ｒｅｓｏｕｒｃｅ）の列をＤ０１０に変える）、Ｒ００６を追加する。状態（ｓｔａｔｕｓ）の列はｃａｎｄｉｄａｔｅとして、管理者による承認を待つ。

図１０を参照すると、最初に、メタデータテーブル２０６１Ａを走査する（Ｓ１００２）。
次に、新規追加データファイル（Ｄ０１０）を検知する（Ｓ１００４）。
次に、新規追加データファイル（Ｄ０１０）にアクセス制御ポリシーはあるかを判定する（Ｓ１００６）。

判定の結果、新規追加データファイル（Ｄ０１０）にアクセス制御ポリシーがある場合は、処理は終了する。

判定の結果、新規追加データファイル（Ｄ０１０）にアクセス制御ポリシーがない場合には、リニエージテーブル２０６２Ａを走査する（Ｓ１００８）。

次に、リニエージテーブル２０６２Ａの走査により、リニエージテーブル２０６２Ａに加工元データファイルがあるかを判定する（Ｓ１０１０）。

判定の結果、リニエージテーブル２０６２Ａに加工元のデータファイル（Ｄ００９）がある場合は、リニエージの識別名及び加工元／加工先の型が一致する他のリニエージはあるかを判定する（Ｓ１０１２）。

次に、一致する他のリニエージはあると判定された場合は、他のリニエージ（Ｌ００１）の加工先（Ｄ００２）のアクセス制御ポリシー（Ｒ００３）を複製して（ただし資源（ｒｅｓｏｕｒｃｅ）の列をＤ０１０に変えて）Ｒ００６として追加する（Ｓ１０１４）。

判定の結果、一致する他のリニエージはないと判定された場合は、デフォルトのアクセス制御ポリシーを追加する（Ｓ１０１６）。

このようにして、新規追加データファイル（Ｄ０１０）には、加工先のデータファイル（Ｄ００２）のアクセス制御ポリシー（Ｒ００３）と同じアクセス制御ポリシー（Ｒ００６）を適用することを推薦する。これを履歴に基づくアクセス制御ポリシーの推薦という。

なお、ステップＳ１０１２にてリニエージの識別名の一致を判定するが、識別名の代わりにタグテーブル２０６３が格納するタグによって一致を判定してもよい。

また同様に、ステップＳ１０１２にて加工元／加工先データファイルの型の一致を判定するが、型の代わりにタグテーブル２０６３が格納するタグによって一致を判定してもよい。

図１１を参照して、実施例３のデータアクセス制御システムの構成について説明する。
実施例３は、データ格納場所の移動に伴うアクセス制御ポリシーの適用に関する。

図２に示す実施例１のデータアクセス制御システムの構成と異なる点は、データストア２０１Ａ及びデータストア２０１Ｂを有する点と、データ加工部２０３に代えてデータ複製部２１０を有する点である。その他の構成は、図２に示す実施例１のデータアクセス制御システムの構成と同じなのでその詳細な説明は省略する。

図１１に示すように、データレイク２００は、データストア２０１Ａ、２０２Ｂを有する。データ複製部２１０は、データファイル２０２Ｃを複製しデータファイル２０２Ｄを生成する。複製後に、データファイル２０２Ｃは残置してもよいし削除してもよい。このとき、新しく生成されたデータファイル２０２Ｄに適用すべきアクセス制御ポリシーの候補を管理者に示す。

図１２を参照して、メタデータテーブル２０６１Ｂの構成について説明する。
メタデータテーブル２０６１Ｂは、ｉｄ、型（ｔｙｐｅ）、識別名（ｎａｍｅ）、所属（ｂｅｌｏｎｇｓＴｏ）の項目を有する。ｉｄ“Ｄ０１１”には、型“Ｔａｂｌｅ”、識別名“ｓｏｕｒｃｅ．ｃｓｖ”が格納されている。また、ｉｄ“Ｄ０１２”には、型“Ｔａｂｌｅ”、識別名“ｔａｒｇｅｔ．ｃｓｖ”が格納されている。ｉｄ“Ｄ００１３”には、型“Ｔａｂｌｅ”、識別名“ｓｏｕｒｃｅ２．ｃｓｖ”が格納されている。また、ｉｄ“Ｄ０１４”には、型“Ｔａｂｌｅ”、識別名“ｔａｒｇｅｔ２．ｃｓｖ”が格納されている。

図１３を参照して、データ複製部２１０を用いて、リニエージテーブル２０６２Ｂの構成について説明する。
図１３（ｂ）に示すように、リニエージテーブル２０６２Ｂは、ｉｄ、識別名（ｎａｍｅ）、加工元（ｉｎｐｕｔ）、加工先（ｏｕｔｐｕｔ）の項目を有する。例えば、ｉｄ“Ｌ００５”の識別名には、“ａｒｃｈｉｖｅ”が格納され、加工元には“Ｄ０１１”が格納され、加工先には“Ｄ０１２”が格納されている。また、ｉｄ“Ｌ００６”の識別名には、“ａｒｃｈｉｖｅ”が格納され、加工元には“Ｄ０１３”が格納され、加工先には“Ｄ０１４”が格納されている。

図１３（ａ）に示すように、データファイル２０２Ｃのデータ“ｓｏｕｒｃｅ．ｃｓｖ”が識別名“ａｒｃｈｉｖｅ”を持つデータ複製部２１０で複製されてデータファイル２０２Ｄのデータ“ｔａｒｇｅｔ．ｃｓｖ”が複製データとして生成されたとする。

この複製により、図１３（ｂ）に示すように、リニエージテーブル２０６２Ｂのｉｄには“Ｌ００５”が格納され、識別名には“ａｒｃｈｉｖｅ”が格納され、加工元には“Ｄ０１１”が格納され、加工先には“Ｄ０１２”がそれぞれ格納される。つまり、データ複製部２１０で複製が行われた場合、リニエージテーブル２０６２Ｂには、そのデータの複製による来歴情報（データリニエージ）として、“ａｒｃｈｉｖｅ”、“Ｄ０１１”“Ｄ０１２”がそれぞれ格納される。

データ複製部２１０は、データファイル２０２Ｃを複製しデータファイル２０２Ｄを生成する。リニエージ収集部２０６５は、この処理の履歴として、リニエージテーブル２０６２Ｂにリニエージを記録する。

図１４を参照して、ポリシーテーブル２０７１Ｃの構成について説明する。
ポリシーテーブル２０７１Ｃは、ｉｄ、操作主体（ｓｕｂｊｅｃｔ）、資源（ｒｅｓｏｕｒｃｅ）、操作（ａｃｔｉｏｎ）、結果（ｅｆｆｅｃｔ）、状態（ｓｔａｔｕｓ）の項目を有する。

例えば、ｉｄ“Ｒ００７”には、操作主体“ＰｒｉｖｉｌｅｇｅｄＵｓｅｒ（特権ユーザ）”、資源“Ｄ０１１”、操作“ＡｎｙＡｃｔｉｏｎ”、結果“Ｐｅｒｍｉｔ”、状態“ｅｎｄｏｒｓｅｄ”が格納されている。

また、ｉｄ“Ｒ００８”には、操作主体“ＡｎｙＳｕｂｊｅｃｔ（全てのユーザ）”、資源“Ｄ０１１”、操作“ｒｅａｄ”、結果“Ｐｅｒｍｉｔ”、状態“ｅｎｄｏｒｓｅｄ”が格納されている。

また、ｉｄ“Ｒ００９”には、操作主体“ＡｎｙＳｕｂｊｅｃｔ（全てのユーザ）”、資源“Ｄ０１２”、操作“ｒｅａｄ”、結果“Ｐｅｒｍｉｔ”、状態“ｅｎｄｏｒｓｅｄ”が格納されている。

データファイル“Ｄ０１１”はデータストア２０１Ａにある。データファイル“Ｄ０１２”はデータストア２０１Ｂにある。データストア２０１Ｂはアーカイブを目的としたデータストアであり、データファイルを改変することは許可されない。このアクセス制御ポリシーをポリシーテーブル２０７１Ｃのルールで表現する。

すなわち、データファイル“Ｄ０１１”について、操作主体が“ＰｒｉｖｉｌｅｇｅｄＵｓｅｒ“のロールであるとき、あらゆる操作“ＡｎｙＡｃｔｉｏｎ”を許可する（Ｒ００７）。また、データファイル“Ｄ０１１”について全ての操作主体“ＡｎｙＳｕｂｊｅｃｔ”は、“ｒｅａｄ“操作のみが許可される（Ｒ００８）。それ以外の操作は拒否される（デフォルト）。

一方、データファイルＤ０１２については、全ての操作主体“ＡｎｙＳｕｂｊｅｃｔ”による“ｒｅａｄ“操作は許可される（Ｒ００９）。それ以外のあらゆる操作は拒否される（デフォルト）。

図１５のフローチャートを参照して、履歴に基づくアクセス制御ポリシーの推薦の動作について説明する。
最初に、メタデータテーブル２０６１Ｂを走査する（Ｓ１５０２）。
次に、新規追加データファイル“Ｄ０１４”を検知する（Ｓ１５０４）。
次に、新規追加データファイル“Ｄ０１４”にアクセス制御ポリシーはあるかを判定する（Ｓ１５０６）。

判定の結果、新規追加データファイル“Ｄ０１４”にアクセス制御ポリシーがある場合は、処理は終了する。
判定の結果、新規追加データファイル“Ｄ０１４”にアクセス制御ポリシーがない場合には、リニエージテーブル２０６２Ｂを走査する（Ｓ１５０８）。

次に、リニエージテーブル２０６２Ｂの走査により、リニエージテーブル２０６２Ｂに加工元データファイルがあるかを判定する（Ｓ１５１０）。
判定の結果、リニエージテーブル２０６２Ｂに加工元データファイル“Ｄ０１３”がある場合は、リニエージの識別名、および加工元／加工先の型が一致する他のリニエージはあるかを判定する（Ｓ１５１２）。

次に、一致する他のリニエージはあると判定された場合は、他のリニエージ“Ｌ００５”の加工先“Ｄ０１２”のアクセス制御ポリシー“Ｒ００９”を複製して（ただし資源（ｒｅｓｏｕｒｃｅ）の列をＤ０１４に変えて）Ｒ０１２として追加する（Ｓ１５１４）。
判定の結果、一致する他のリニエージはないと判定された場合は、デフォルトのアクセス制御ポリシーを追加する（Ｓ１５１６）。

このようにして、新規追加データファイル“Ｄ０１４”には、加工先のデータファイル“Ｄ０１２”のアクセス制御ポリシー“Ｒ００９”と同じアクセス制御ポリシー“Ｒ０１２”を適用する。

具体的には、データ格納場所の移動に伴うアクセス制御ポリシーの適用は、以下のように行われる。ポリシー設定部２０７２によるポリシーテーブル２０７１Ｃの作成手順である。

新規に追加されたデータファイル“Ｄ０１４”に付与するアクセス制御ポリシーの候補を追加する。リニエージテーブル２０６２Ｂを走査して“Ｄ０１４”の加工元のデータファイルである“Ｄ０１３”を抽出する。

さらに、Ｄ０１３を元にＤ０１４を生成したリニエージ“Ｌ００６”について、メタデータテーブル２０６１Ｂを参照して、その識別名（“ａｒｃｈｉｖｅ”）、加工元／加工先データファイルの型（“Ｔａｂｌｅ／Ｔａｂｌｅ”）が一致する他のリニエージを探す（ステップＳ１５１２）。

すると、リニエージ“Ｌ００５”が見つかるので、その加工先のデータファイル“Ｄ０１２”のアクセス制御ポリシーである“Ｒ００９”を複製して、“Ｒ０１２”を追加する。ただし、資源“ｒｅｓｏｕｒｃｅ”の列を“Ｄ０１４”に変える。状態（ｓｔａｔｕｓ）の列は“ｃａｎｄｉｄａｔｅ”として管理者による承認を待つ。

なお、ステップＳ１５１２にてリニエージの識別名の一致を判定するが、識別名の代わりにタグテーブル２０６３が格納するタグによって一致を判定してもよい。

また同様に、ステップＳ１５１２にて加工元／加工先データファイルの型の一致を判定するが、型の代わりにタグテーブル２０６３が格納するタグによって一致を判定してもよい。

実施例４のデータアクセス制御システムついて説明する。実施例３は、複数の加工元データがある場合のアクセス制御ポリシーの適用に関する。実施例４のデータアクセス制御システムの構成は、図２に示す実施例１のデータアクセス制御システムの構成と同じなのでその説明は省略する。

図１６を参照して、メタデータテーブル２０６１Ｃの構成について説明する。
メタデータテーブル２０６１Ｃは、ｉｄ、型（ｔｙｐｅ）、識別名（ｎａｍｅ）、所属（ｂｅｌｏｎｇｓＴｏ）の項目を有する。ｉｄ“Ｄ０１５”には、型“Ｔａｂｌｅ”、識別名“ｓｏｕｒｃｅ．ｃｓｖ”が格納されている。また、ｉｄ“Ｄ０１６”には、型“Ｔａｂｌｅ”、識別名“ｍａｓｔｅｒ．ｃｓｖ”が格納されている。また、ｉｄ“Ｄ０１７”には、型“Ｔａｂｌｅ”、識別名“ｔａｒｇｅｔ．ｃｓｖ”が格納されている。

図１７を参照して、データ加工部２０３Ｂを用いて、リニエージテーブル２０６２Ｃの構成について説明する。
図１７（ｂ）に示すように、リニエージテーブル２０６２Ｃは、ｉｄ、識別名（ｎａｍｅ）、加工元（ｉｎｐｕｔ）、加工先（ｏｕｔｐｕｔ）の項目を有する。ｉｄ“Ｌ００７”の識別名には、“ｊｏｉｎ＿ｍａｓｔｅｒ”が格納され、加工元には“Ｄ０１５”が格納され、加工先には“Ｄ０１７”が格納されている。

また、ｉｄ“Ｌ００８”の識別名には、“ｊｏｉｎ＿ｍａｓｔｅｒ”が格納され、加工元には“Ｄ０１６”が格納され、加工先には“Ｄ０１７”が格納されている。

図１７（ａ）に示すように、データファイル２０２Ｅのデータ“ｓｏｕｒｃｅ．ｃｓｖ”とデータファイル２０２Ｆのデータ“ｍａｓｔｅｒ．ｃｓｖ”がデータ加工部２０３Ｂで加工されてデータファイル２０２Ｇのデータ“ｔａｒｇｅｔ．ｃｓｖ”が加工データとして生成されたとする。

この加工により、図１１（ｂ）に示すように、リニエージテーブル２０６２Ｃのｉｄには“Ｌ００７”が格納され、識別名には“ｊｏｉｎ＿ｍａｓｔｅｒ”が格納され、加工元には“Ｄ０１５”が格納され、加工先には“Ｄ０１７”がそれぞれ格納される。つまり、データ加工部２０３Ｂで、“ｊｏｉｎ＿ｍａｓｔｅｒ”という加工が行われた場合、リニエージテーブル２０６２Ｃには、そのデータの加工による来歴情報（データリニエージ）として、“ｊｏｉｎ＿ｍａｓｔｅｒ”、“Ｄ０１５”、“Ｄ０１７”がそれぞれ格納される。

同様に、この加工により、図１１（ｂ）に示すように、リニエージテーブル２０６２Ｃのｉｄには“Ｌ００８”が格納され、識別名には“ｊｏｉｎ＿ｍａｓｔｅｒ”が格納され、加工元には“Ｄ０１６”が格納され、加工先には“Ｄ０１７”がそれぞれ格納される。つまり、データ加工部２０３Ｂで、“ｊｏｉｎ＿ｍａｓｔｅｒ”という加工が行われた場合、リニエージテーブル２０６２Ｃには、そのデータの加工による来歴情報（データリニエージ）として、“ｊｏｉｎ＿ｍａｓｔｅｒ”、“Ｄ０１６”、“Ｄ０１７”がそれぞれ格納される。

このように、データ加工部２０３Ｂは、データファイル２０２Ｅにデータファイル２０２Ｆ（マスターデータ）を結合してデータファイル２０２Ｇを生成する。リニエージ収集部２０６５は、この処理の履歴として、リニエージテーブル２０６２Ｃにリニエージを記録する。

図１８を参照して、ポリシーテーブル２０７１Ｄの構成について説明する。
ポリシーテーブル２０７１Ｄは、ｉｄ、操作主体（ｓｕｂｊｅｃｔ）、資源（ｒｅｓｏｕｒｃｅ）、操作（ａｃｔｉｏｎ）、結果（ｅｆｆｅｃｔ）、状態（ｓｔａｔｕｓ）の項目を有する。

例えば、ｉｄ“Ｒ０１３”には、操作主体“ＰｒｉｖｉｌｅｇｅｄＵｓｅｒ（特権ユーザ）”、資源“Ｄ０１５”、操作“ｒｅａｄ”、結果“Ｐｅｒｍｉｔ”、状態“ｅｎｄｏｒｓｅｄ”が格納されている。

また、ｉｄ“Ｒ０１４”には、操作主体“ＡｎｙＳｕｂｊｅｃｔ（全てのユーザ）”、資源“Ｄ０１６”、操作“ｒｅａｄ”、結果“Ｐｅｒｍｉｔ”、状態“ｅｎｄｏｒｓｅｄ”が格納されている。

また、ｉｄ“Ｒ０１５”には、操作主体“ＰｒｉｖｉｌｅｇｅｄＵｓｅｒ（特権ユーザ）”、資源“Ｄ０１７”、操作“ｒｅａｄ”、結果“Ｐｅｒｍｉｔ”、状態“ｃａｎｄｉｄａｔｅ”が格納されている。

図１８に示すように、データファイル“Ｄ０１５”について，操作主体が“ＰｒｉｖｉｌｅｇｅｄＵｓｅｒ“のロールであるとき，“ｒｅａｄ“操作を許可する（Ｒ０１３）。それ以外の全ての操作主体によるあらゆる操作は拒否される（デフォルト）。一方、データファイル“Ｄ０１６”について，全ての操作主体による“ｒｅａｄ“操作は許可される（Ｒ０１４）。

データファイル“Ｄ０１５”とデータファイル“Ｄ０１６”を結合して生成されたデータファイル“Ｄ０１７”について、“Ｒ０１３”と“Ｒ０１４”の両者から厳格な（許可される範囲が狭い）ルールが適用される。すなわち、操作主体が“ＰｒｉｖｉｌｅｇｅｄＵｓｅｒ“であるとき、“ｒｅａｄ“操作を許可する（Ｒ０１５）。それ以外の全ての操作主体によるあらゆる操作は拒否される（デフォルト）。

次に、図１９のフローチャートを参照して、アクセス制御ポリシー適用の動作について説明する。ポリシー設定部２０７２によるポリシーテーブル２０７１Ｄの作成手順である。
最初に、メタデータテーブル２０６１Ｃを走査する（Ｓ１９０２）。
次に、新規追加データファイル“Ｄ０１７”を検知する（Ｓ１９０４）。
次に、新規追加データファイル“Ｄ０１７”にアクセス制御ポリシーはあるかを判定する（Ｓ１９０６）。

判定の結果、新規追加データファイル“Ｄ０１７”にアクセス制御ポリシーがある場合は、処理は終了する。
判定の結果、新規追加データファイル“Ｄ０１７”にアクセス制御ポリシーがない場合には、リニエージテーブル２０６２Ｃを走査する（Ｓ１９０８）。

次に、リニエージテーブル２０６２Ｃの走査により、リニエージテーブル２０６２Ｃに加工元のデータファイルがあるかを判定する（Ｓ１９１０）。
判定の結果、リニエージテーブル２０６２Ａに加工元データファイルがある場合は、加工元のデータファイルが２つ以上あるかを判定する（Ｓ１９１２）。

加工元のデータファイル（Ｄ０１５、Ｄ０１６）が２つ以上ある場合は、加工元のデータファイルのアクセス制御ポリシーが厳格になるようにマージして追加する（Ｓ１９１４）。

加工元データファイル２つ以上ない場合は、加工元のデータファイルのアクセス制御ポリシーを複製して追加する（Ｓ１９１６）。

ステップＳ１９１０の判定の結果、リニエージテーブル２０６２Ｃに加工元のデータファイルがない場合には、デフォルトのアクセス制御ポリシーを追加する（Ｓ１９１８）。

このように、ポリシー設定部２０７２によるポリシーテーブル２０７１Ｄの作成手順は以下のようである。

新規に追加されたデータファイル“Ｄ０１７”に付与するポリシーの候補を追加する。リニエージテーブル２０６２Ｃを走査して“Ｄ０１７”の加工元データファイルである“Ｄ０１５”および“Ｄ０１６”を抽出し、“Ｄ０１５”のアクセス制御ポリシーである“Ｒ０１３”及び“Ｄ０１６”のアクセス制御ポリシーである“Ｒ０１４”を、アクセス制御ポリシーが厳格に（許可される範囲が狭い方向に）なるようマージして、資源（ｒｅｓｏｕｒｃｅ）の列を“Ｄ０１７”に変えて、“Ｒ０１５”を追加する（ステップＳ１９１４）。状態（ｓｔａｔｕｓ）の列は“ｃａｎｄｉｄａｔｅ”として管理者による承認を待つ。

次に、図２０を参照して、マージすると矛盾するルールの例について説明する。
図２０を参照して、ポリシーテーブル２０７１Ｅの構成について説明する。
ポリシーテーブル２０７１Ｅは、ｉｄ、操作主体（ｓｕｂｊｅｃｔ）、資源（ｒｅｓｏｕｒｃｅ）、操作（ａｃｔｉｏｎ）、結果（ｅｆｆｅｃｔ）、状態（ｓｔａｔｕｓ）の項目を有する。

例えば、ｉｄ“Ｒ０１６”には、操作主体“ＥｘａｍｐｌｅＲｏｌｅ”、資源“Ｄ０１５”、操作“ｒｅａｄ”、結果“Ｐｅｒｍｉｔ”、状態“ｅｎｄｏｒｓｅｄ”が格納されている。

また、ｉｄ“Ｒ０１７”には、操作主体“ＥｘａｍｐｌｅＲｏｌｅ”、資源“Ｄ０１６”、操作“ｒｅａｄ”、結果“Ｄｅｎｙ”、状態“ｅｎｄｏｒｓｅｄ”が格納されている。

また、ｉｄ“Ｒ０１８”には、操作主体“ＰｒｉｖｉｌｅｇｅｄＵｓｅｒ（特権ユーザ）”、資源“Ｄ０１７”、操作“ｒｅａｄ”、結果“Ｐｅｒｍｉｔ”、状態“ｃａｎｄｉｄａｔｅ”が格納されている。

データファイル“Ｄ０１５”について，操作主体が“ＥｘａｍｐｌｅＲｏｌｅ“のロールであるとき“ｒｅａｄ“操作を許可する（Ｒ０１６）。一方、データファイル“Ｄ０１６”について、操作主体“ＥｘａｍｐｌｅＲｏｌｅ“のロールによる“ｒｅａｄ“操作は拒否される（Ｒ０１７）。“Ｒ０１３”と“Ｒ０１４”は、成立条件となる操作主体も操作も同一であるが，その結果（ｅｆｆｅｃｔ）が相反する。

よって、両者を両立させるような厳格な（許可される範囲が狭い）ルールを生成することができない。ポリシー設定部２０７２は、この矛盾のためにデータファイル“Ｄ０１５”、“Ｄ０１６”を結合して生成したデータファイル“Ｄ０１７”のアクセス制御ポリシーの候補を生成できなかったことを管理者に通知する。

上記実施例では、データの複製・加工による来歴情報（データリニエージ）に基づき、新たなデータにアクセス制御ポリシーを適用する。または、適用すべきアクセス制御ポリシーを推薦する。これにより、組織横断的なデータの共有を目的としたデータレイクの管理が行える。データの加工内容を履歴として記録しておく。新たなデータ加工について、その内容をキーワードマッチで履歴から検索し、新たなデータに適用すべきアクセス制御ポリシーを推薦する。

上記実施例は、データの処理によって生成されたデータに、処理元データのアクセス制御ポリシーを適用する。また、データの処理は、例えば加工であり、元データのアクセス制御ポリシーを変更した上で適用する。また、データの加工内容から、アクセス制御ポリシーを推薦する。データの加工内容を記録した履歴情報から推薦を行う。ここで、データの加工内容は、カラムの削除又はマスク処理である。また、データの処理とは格納場所の移動であり、元データのアクセス制御ポリシーを変更した上で適用する。

また、データ格納場所の移動の内容から、アクセス制御ポリシーの変更内容を推薦する。データ格納場所の移動の内容を記録した履歴情報から推薦を行う。

また、複数の処理元データに由来する複数のアクセス制御ポリシーをマージして適用する。この際、複数のアクセス制御ポリシーが矛盾することを管理者に通知する。

上記実施例によれば、アクセス制御の設定に要する工数を減ずることができる。つまり、データレイクにおけるアクセス制御ポリシーの適用を容易化することにより管理に要する工数を減ずることができる。

なお、本発明は、上記の実施例に限定されるものではなく、本発明の趣旨を逸脱しない範囲で、適宜変形して実施することが可能である。

例えば、上記実施例における、プロセッサがプログラムを実行することにより構成していた機能部の一部又は全部を、ハードウェア回路で行うようにしてもよい。また、上記実施例におけるプログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記憶メディア（例えば可搬型の記憶メディア）であってもよい。

２００ データレイク
２０１ データストア
２０３ データ加工部
２０４ データレイク管理部
２０５ アクセス制御部
２０６ メタデータ管理部
２０７ ポリシー管理部
２０８ ポリシー決定部
２０９ ポリシー実施部
３００ ユーザプログラム
４００ ＩＤプロバイダ
２０６４ メタデータ収集部
２０６５ リニエージ収集部
２０６１ メタデータテーブル
２０６２ リニエージテーブル
２０６３ タグテーブル
２０６６ タグ登録部
２０７１ ポリシーテーブル
２０７２ ポリシー設定部
２０７３ ポリシー提供部

Claims (13)

1. データレイクを有するデータアクセス制御システムであって、
   前記データレイクは、
   第１のデータファイルと第２のデータファイルとを有するデータストアと、
   前記第１のデータファイルに格納されている処理元のデータを処理して前記第２のデータファイルに処理データを格納するデータ処理部と、
   メタデータ管理部とポリシー管理部とを有するデータレイク管理部と、を有し、
   前記メタデータ管理部は、
   メタデータ収集部とリニエージ収集部とメタデータテーブルとリニエージテーブルを有し、
   前記ポリシー管理部は、
   ポリシー設定部とポリシーテーブルとポリシー提供部を有し、
   前記データ処理部は、
   前記第２のデータファイルのデータリニエージ情報を前記リニエージ収集部に送信し、
   前記リニエージ収集部は、
   前記データリニエージ情報を収集して、前記リニエージテーブルに格納し、
   前記データファイルのメタデータは、前記メタデータ収集部に送られ、
   前記メタデータ収集部は、
   前記メタデータを収集して前記メタデータテーブルに格納し、
   前記ポリシー設定部は、
   前記リニエージテーブル及び前記メタデータテーブルを参照して、所定のアクセス制御ポリシーを生成して前記ポリシーテーブルに格納し、
   前記ポリシー提供部は、
   前記ポリシーテーブルを参照して、前記第２のデータファイルに適用又は推薦すべきアクセス制御ポリシーを提供することを特徴とするデータアクセス制御システム。
2. 前記データレイクは、アクセス制御部を更に有し、
   前記アクセス制御部は、
   ポリシー決定部とポリシー実施部とを有し、
   前記ポリシー決定部は、
   前記ポリシー提供部から提供された前記アクセス制御ポリシーを決定し、
   前記ポリシー実施部は、
   決定された前記アクセス制御ポリシーを実施することを特徴とする請求項１に記載のデータアクセス制御システム。
3. 前記メタデータ管理部は、
   タグ登録部とタグテーブルとを更に有し、
   前記タグ登録部は、
   前記タグテーブルにタグを格納し、
   前記ポリシー設定部は、
   前記タグテーブルを参照して、前記所定のアクセス制御ポリシーを前記ポリシーテーブルに格納することを特徴とする請求項１に記載のデータアクセス制御システム。
4. 前記データ処理部は、
   前記処理として前記データファイルの加工を行うデータ加工部で構成され、
   前記リニエージ収集部は、
   前記データ加工部が送信する前記データリニエージ情報を収集して、前記リニエージテーブルに格納することを特徴とする請求項１に記載のデータアクセス制御システム。
5. 前記データ加工部は、
   複数の前記データファイルのマージを行うことを特徴とする請求項４に記載のデータアクセス制御システム。
6. 前記データストアは、
   第１のデータファイルを有する第１のデータストアと、第２のデータファイルを有する第２のデータストアとで構成され、
   前記データ処理部は、
   前記第１のデータファイルを前記第２のデータファイルに複製するデータ複製部で構成され、
   前記リニエージ収集部は、
   前記データ複製部で複製された前記第２のデータファイルの前記データリニエージ情報を収集して、前記リニエージテーブルに格納することを特徴とする請求項１に記載のデータアクセス制御システム。
7. 前記ポリシー管理部は、
   前記データ処理部が前記処理データを格納した前記第２のデータファイルに、前記処理元のデータを格納した前記第１のデータファイルのアクセス制御ポリシーを適用することを特徴とする請求項１に記載のデータアクセス制御システム。
8. 前記ポリシー管理部は、
   前記処理元のデータの処理内容に基づいて前記アクセス制御ポリシーを変更して、変更後の前記アクセス制御ポリシーを、前記処理データを格納した前記第２のデータファイルに適用することを推薦することを特徴とする請求項１に記載のデータアクセス制御システム。
9. 前記ポリシー管理部は、
   複数の前記処理元のデータを格納した複数の前記第１のデータファイルに由来する複数の前記アクセス制御ポリシーの中から最も厳格な前記アクセス制御ポリシーを、前記処理データを格納した前記第２のデータファイルに適用することを特徴とする請求項５に記載のデータアクセス制御システム。
10. 前記ポリシー管理部は、
    複数の前記アクセス制御ポリシーが互いに矛盾する場合には、前記矛盾を管理者に通知することを特徴とする請求項９に記載のデータアクセス制御システム。
11. 前記データ加工部は、
    前記データファイルに格納されている前記処理元のデータの前記加工として、テーブルを構成するカラムの削除を行うことを特徴とする請求項４に記載のデータアクセス制御システム。
12. データリニエージの途中にあるプログラムの処理内容に応じてアクセス制御ポリシーを適用するデータアクセス制御方法であって、
    データの処理によって生成された処理先のデータに、処理元のデータのアクセス制御ポリシーを適用することを特徴とするデータアクセス制御方法。
13. データリニエージの途中にあるプログラムの処理内容に応じてアクセス制御ポリシーを変更するデータアクセス制御方法であって、
    データの処理による来歴情報に基づいて、新たなデータに適用すべきアクセス制御ポリシーとして、変更後の前記アクセス制御ポリシーを推薦することを特徴とするデータアクセス制御方法。

Images