特開2023-127486アクセス制御方法、アクセス制御プログラム、および情報処理装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023127486
(43)【公開日】2023-09-13
(54)【発明の名称】アクセス制御方法、アクセス制御プログラム、および情報処理装置
(51)【国際特許分類】
G06F 21/62 20130101AFI20230906BHJP
【ＦＩ】
G06F21/62 318
【審査請求】未請求
【請求項の数】8
【出願形態】ＯＬ
(21)【出願番号】P 2022031310
(22)【出願日】2022-03-01
(71)【出願人】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】110002918
【氏名又は名称】弁理士法人扶桑国際特許事務所
(72)【発明者】
【氏名】加藤 千裕
(57)【要約】
【課題】ソフトウェアの種別ごとの効率的なアクセス制限を可能とする。
【解決手段】情報処理装置１は、プロセスが生成されたことを検知すると、生成されたプロセスを有するコンテナのアドレスとプロセスとの対応関係を管理情報７に登録する。次に情報処理装置１は、データベース２ａへのアクセス要求の出力を検知すると、管理情報７においてアクセス要求の送信元アドレスに対応付けられた１または複数のプロセスの中から、アクセス要求の送信元ポート番号を使用している送信元プロセスを特定する。そして情報処理装置１は、特定した送信元プロセスが実行している送信元ソフトウェアを特定する。情報処理装置２は、特定した送信元ソフトウェアからのアクセス要求に応じたデータベース２ａへのアクセスが許可されているか否かを判定する。
【選択図】図１
【解決手段】情報処理装置１は、プロセスが生成されたことを検知すると、生成されたプロセスを有するコンテナのアドレスとプロセスとの対応関係を管理情報７に登録する。次に情報処理装置１は、データベース２ａへのアクセス要求の出力を検知すると、管理情報７においてアクセス要求の送信元アドレスに対応付けられた１または複数のプロセスの中から、アクセス要求の送信元ポート番号を使用している送信元プロセスを特定する。そして情報処理装置１は、特定した送信元プロセスが実行している送信元ソフトウェアを特定する。情報処理装置２は、特定した送信元ソフトウェアからのアクセス要求に応じたデータベース２ａへのアクセスが許可されているか否かを判定する。
【選択図】図１
【特許請求の範囲】
【請求項1】
１または複数のコンテナのいずれかでプロセスが生成されたことを検知すると、生成された前記プロセスを有するコンテナにおけるネットワーク通信用のアドレスと生成された前記プロセスとの対応関係を管理情報に登録し、
データベースへのアクセス要求の出力を検知すると、前記管理情報において前記アクセス要求の送信元アドレスに対応付けられた１または複数のプロセスの中から、前記アクセス要求の送信元ポート番号を使用している送信元プロセスを特定し、
特定した前記送信元プロセスが実行している送信元ソフトウェアを特定し、
特定した前記送信元ソフトウェアからの前記アクセス要求に応じた前記データベースへのアクセスが許可されているか否かを判定する、
処理をコンピュータが実行するアクセス制御方法。
データベースへのアクセス要求の出力を検知すると、前記管理情報において前記アクセス要求の送信元アドレスに対応付けられた１または複数のプロセスの中から、前記アクセス要求の送信元ポート番号を使用している送信元プロセスを特定し、
特定した前記送信元プロセスが実行している送信元ソフトウェアを特定し、
特定した前記送信元ソフトウェアからの前記アクセス要求に応じた前記データベースへのアクセスが許可されているか否かを判定する、
処理をコンピュータが実行するアクセス制御方法。
【請求項2】
前記送信元プロセスを特定する処理では、前記送信元ポート番号を用いた通信で使用しているファイルのファイル識別情報を取得し、取得した前記ファイル識別情報に基づいて、前記送信元プロセスの識別情報を取得する、
請求項１記載のアクセス制御方法。
請求項１記載のアクセス制御方法。
【請求項3】
前記送信元プロセスを特定する処理では、前記１または複数のプロセスそれぞれが使用しているファイルの中から、取得した前記ファイル識別情報に対応するファイルを検索し、該当するファイルを使用しているプロセスを前記送信元プロセスとして特定する、
請求項２記載のアクセス制御方法。
請求項２記載のアクセス制御方法。
【請求項4】
前記管理情報には、ネットワーク通信用の前記アドレスが共通のコンテナが共通で使用するネットワークネームスペースを示す情報が、前記アドレスに対応付けて設定されており、
前記アドレスと生成された前記プロセスとの対応関係を管理情報に登録する処理では、生成された前記プロセスが使用する前記ネットワークネームスペースに対応する前記アドレスに対応付けて、生成された前記プロセスの識別情報を登録する、
請求項２または３に記載のアクセス制御方法。
前記アドレスと生成された前記プロセスとの対応関係を管理情報に登録する処理では、生成された前記プロセスが使用する前記ネットワークネームスペースに対応する前記アドレスに対応付けて、生成された前記プロセスの識別情報を登録する、
請求項２または３に記載のアクセス制御方法。
【請求項5】
前記送信元プロセスを特定する処理では、前記管理情報において前記送信元アドレスに対応する前記ネットワークネームスペースにアクセスすることで、前記送信元ポート番号を用いた通信で使用しているファイルの前記ファイル識別情報を取得する、
請求項４に記載のアクセス制御方法。
請求項４に記載のアクセス制御方法。
【請求項6】
前記データベースへのアクセスが許可されているか否かを判定する処理では、前記データベース内のデータテーブルに対してアクセスを許可するソフトウェアが設定された許可情報において、前記アクセス要求におけるアクセス先となる対象データテーブルに対して、特定した前記送信元プロセスが実行している前記送信元ソフトウェアからのアクセスが許可されている場合、前記データベースへのアクセスを許可する、
請求項１から５までのいずれかに記載のアクセス制御方法。
請求項１から５までのいずれかに記載のアクセス制御方法。
【請求項7】
１または複数のコンテナのいずれかでプロセスが生成されたことを検知すると、生成された前記プロセスを有するコンテナにおけるネットワーク通信用のアドレスと生成された前記プロセスとの対応関係を管理情報に登録し、
データベースへのアクセス要求の出力を検知すると、前記管理情報において前記アクセス要求の送信元アドレスに対応付けられた１または複数のプロセスの中から、前記アクセス要求の送信元ポート番号を使用している送信元プロセスを特定し、
特定した前記送信元プロセスが実行している送信元ソフトウェアを特定し、
特定した前記送信元ソフトウェアからの前記アクセス要求に応じた前記データベースへのアクセスが許可されているか否かを判定する、
処理をコンピュータに実行させるアクセス制御プログラム。
データベースへのアクセス要求の出力を検知すると、前記管理情報において前記アクセス要求の送信元アドレスに対応付けられた１または複数のプロセスの中から、前記アクセス要求の送信元ポート番号を使用している送信元プロセスを特定し、
特定した前記送信元プロセスが実行している送信元ソフトウェアを特定し、
特定した前記送信元ソフトウェアからの前記アクセス要求に応じた前記データベースへのアクセスが許可されているか否かを判定する、
処理をコンピュータに実行させるアクセス制御プログラム。
【請求項8】
１または複数のコンテナのいずれかでプロセスが生成されたことを検知すると、生成された前記プロセスを有するコンテナにおけるネットワーク通信用のアドレスと生成された前記プロセスとの対応関係を管理情報に登録し、データベースへのアクセス要求の出力を検知すると、前記管理情報において前記アクセス要求の送信元アドレスに対応付けられた１または複数のプロセスの中から、前記アクセス要求の送信元ポート番号を使用している送信元プロセスを特定し、特定した前記送信元プロセスが実行している送信元ソフトウェアを特定し、特定した前記送信元ソフトウェアからの前記アクセス要求に応じた前記データベースへのアクセスが許可されているか否かを判定する処理部、
を有する情報処理装置。
を有する情報処理装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、アクセス制御方法、アクセス制御プログラム、および情報処理装置に関する。
【背景技術】
【0002】
アプリケーションソフトウェアなどの様々なソフトウェアを実行する動作環境では、各ソフトウェアからデータベース（ＤＢ：DataBase）内のデータへのアクセスを適切に制限することは非常に重要である。特に第三者から提供された秘密情報を扱う場合には、過失によって秘密情報を漏洩してしまうと大きな問題に発展する恐れがある。そのため、規定や規則によってこれを抑制するだけでなく、コンピュータシステム内でのアクセス制御機構によりアクセスを制限できることが求められる。
【0003】
なおアクセス制御の対象となるソフトウェアは、コンテナと呼ばれる仮想実行環境で実行される場合がある。ソフトウェアを実行するコンテナは、オーケストレーションツールと呼ばれる管理用ソフトウェアを用いて管理される。オーケストレーションツールにおいては、クラスタ内部のネットワーク機構を制御するためのソフトウェアが併用されることが多い。ネットワーク機構を制御するためのソフトウェアとしては、例えばサイドカープロキシと呼ばれる機構がある。代表的なものとしては、例えば、Ｅｎｖｏｙと呼ばれるＯＳＳ（Open Source Software）がある。
【0004】
サイドカープロキシでは、ソフトウェアのポート番号を用いて、ソフトウェアからＤＢへのアクセスの抑制などの制御を行うことができる。すなわちネットワークを介したＤＢへのアクセスの場合、各ソフトウェアには通信用のポート番号が割り振られる。ポート番号が固定的に決まっているソフトウェアであれば、アクセス要求のポート番号に基づいて、そのソフトウェアに関するＤＢへのアクセス制御を行うことができる。
【0005】
また、データ管理のソフトウェアである関係データベース管理システム（ＲＤＢＭＳ：Relational DataBase Management System）においても、データへのアクセス制御の機構は存在する。ＲＤＢＭＳではユーザごとにアクセスの権限を設定し、その権限に従ってデータのアクセス可否を判断する。この権限はテーブル単位、行単位、列単位など、多数の粒度での設定が可能である。
【0006】
コンテナを管理する技術としては、例えばコンテナ間で行われる通信の監視結果を用いて不正動作を検出できる監視システムが提案されている。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特開２０２０－１１５３５８号公報
【発明の概要】
【発明が解決しようとする課題】
【0008】
コンテナ上で実行されているソフトウェアには、データ送信を行う際に、その時点で未使用のポート番号を用いて通信を行うソフトウェアが多数存在する。このように、ポート番号が通信の度に異なるソフトウェアがネットワーク経由でＤＢにアクセスする場合、従来技術では、アクセス要求のポート番号に対応するソフトウェアの種別の判別を効率的に行うことができない。そのため、ソフトウェアの種別ごとにＤＢへの効率的なアクセス制限が困難となっている。
【0009】
１つの側面では、本件は、ソフトウェアの種別ごとの効率的なアクセス制限を可能とすることを目的とする。
【課題を解決するための手段】
【0010】
１つの案では、以下の処理をコンピュータが実行するアクセス制御方法が提供される。
コンピュータは、１または複数のコンテナのいずれかでプロセスが生成されたことを検知すると、生成されたプロセスを有するコンテナにおけるネットワーク通信用のアドレスと生成されたプロセスとの対応関係を管理情報に登録する。次にコンピュータは、データベースへのアクセス要求の出力を検知すると、管理情報においてアクセス要求の送信元アドレスに対応付けられた１または複数のプロセスの中から、アクセス要求の送信元ポート番号を使用している送信元プロセスを特定する。さらにコンピュータは、特定した送信元プロセスが実行している送信元ソフトウェアを特定する。そしてコンピュータは、特定した送信元ソフトウェアからのアクセス要求に応じたデータベースへのアクセスが許可されているか否かを判定する。
コンピュータは、１または複数のコンテナのいずれかでプロセスが生成されたことを検知すると、生成されたプロセスを有するコンテナにおけるネットワーク通信用のアドレスと生成されたプロセスとの対応関係を管理情報に登録する。次にコンピュータは、データベースへのアクセス要求の出力を検知すると、管理情報においてアクセス要求の送信元アドレスに対応付けられた１または複数のプロセスの中から、アクセス要求の送信元ポート番号を使用している送信元プロセスを特定する。さらにコンピュータは、特定した送信元プロセスが実行している送信元ソフトウェアを特定する。そしてコンピュータは、特定した送信元ソフトウェアからのアクセス要求に応じたデータベースへのアクセスが許可されているか否かを判定する。
【発明の効果】
【0011】
１態様によれば、ソフトウェアの種別ごとの効率的なアクセス制限が可能となる。
【図面の簡単な説明】
【0012】
【図1】第１の実施の形態に係るアクセス制御方法の一例を示す図である。
【図2】第２の実施の形態のシステム構成の一例を示す図である。
【図3】ノードのハードウェアの一例を示す図である。
【図4】アプリケーションごとのＤＢへのアクセス管理の一例を示す図である。
【図5】ＤＢへのアクセス制御に関する参考技術の第１の例を示す図である。
【図6】ＤＢへのアクセス制御に関する参考技術の第２の例を示す図である。
【図7】ｉｎｏｄｅ番号を介したアプリケーション特定の一例を示す図である。
【図8】ＤＢへのアクセス制御に関する参考技術の第３の例を示す図である。
【図9】アプリケーション単位でのアクセス制御機能の一例を示すブロック図である。
【図10】死活監視処理の一例を示す図である。
【図11】コンテナ詳細情報の一例を示す図である。
【図12】Ｐｏｄ情報リソース群の一例を示す図である。
【図13】Ｐｏｄ生成時の処理の手順の一例を示すフローチャートである。
【図14】生成されたプロセスのＰＩＤが追記されたＰｏｄ情報リソースの一例を示す図である。
【図15】プロセス生成時の処理の手順の一例を示すフローチャートである。
【図16】ＤＢへのアクセスの際の情報の流れを示す図である。
【図17】アプリケーションのファイルパスの取得手順の一例を示すフローチャートである。
【図18】接続先テーブル名の取得方法の一例を示す図である。
【図19】カスタムリソースから取得する許可情報の一例を示す図である。
【図20】投機的なＤＢアクセス処理の一例を示すシーケンス図である。
【図21】クエリの実行に時間がかかる場合の投機的なＤＢアクセス処理の一例を示すシーケンス図である。
【発明を実施するための形態】
【0013】
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
第１の実施の形態は、ソフトウェアの種別ごとにＤＢへのアクセスを制限可能なアクセス制御方法である。
〔第１の実施の形態〕
第１の実施の形態は、ソフトウェアの種別ごとにＤＢへのアクセスを制限可能なアクセス制御方法である。
【0014】
図１は、第１の実施の形態に係るアクセス制御方法の一例を示す図である。図１には、アクセス制御方法を情報処理装置１，２によって実施した場合の例を示している。情報処理装置１，２は、例えばコンピュータであり、アクセス制御プログラムを実行することにより、アクセス制御方法を実施することができる。
【0015】
情報処理装置１は、記憶部１ａと処理部１ｂとを有する。記憶部１ａは、情報処理装置１が有するメモリまたはストレージ装置である。処理部１ｂは、例えば情報処理装置１が有するプロセッサまたは演算回路である。情報処理装置２は、データベース（ＤＢ）２ａと処理部２ｂとを有する。ＤＢ２ａは、情報処理装置２が有するメモリまたはストレージ装置である。処理部２ｂは、例えば情報処理装置２が有するプロセッサまたは演算回路である。
【0016】
情報処理装置１の記憶部１ａは、Ｐｏｄ６に含まれる１または複数のコンテナ６ａ，６ｂ，・・・内の１または複数のプロセスと、Ｐｏｄ６のネットワーク通信用のアドレス（ＰｏｄＩＰ：１９２．１６．１８．２２）との対応関係を示す管理情報７を記憶する。ネットワーク通信用のアドレスは、例えばＩＰ（Internet Protocol）アドレスである。プロセスは、例えばそのプロセスのプロセスＩＤ（ＰＩＤ：［１５４２４，１５７５６，・・・］）で示される。また管理情報７には、例えばＰｏｄ６で使用されるネットワークネームスペースを示す情報（ｎｓ：４０２６５３１９６８）が含まれる。ネットワークネームスペースを示す情報は、例えばネットワークネームスペースに対応するファイルのｉｎｏｄｅ番号である。
【0017】
情報処理装置１の処理部１ｂは、ソフトウェアの仮想的な実行環境であるコンテナの集合体であるＰｏｄ５，６を有している。例えばＰｏｄ５にはコンテナ５ａが含まれており、Ｐｏｄ６にはコンテナ６ａ，６ｂ，・・・が含まれている。コンテナ５ａは、他のＰｏｄ６およびそのＰｏｄ６内のコンテナ６ａ，６ｂ，・・・を監視するためのコンテナである。コンテナ６ａ，６ｂ，・・・は、ユーザからの要求に応じたサービスの提供に用いるソフトウェア８ａ，８ｂを実行するためのコンテナである。各Ｐｏｄ５，６には、ネットワーク通信用のアドレスが割り振られている。各Ｐｏｄ５，６内のコンテナは、属するＰｏｄに割り振られたアドレスを共有する。
【0018】
例えばコンテナ６ａでは、ソフトウェア８ａ，８ｂそれぞれを実行するためのプロセスが生成される。各プロセスは、ソフトウェア８ａ，８ｂの実行過程でＤＢ２ａ内のデータを用いた処理が発生すると、ＤＢ２ａへのアクセス要求９ａ，９ｂを出力する。出力されるアクセス要求９ａ，９ｂの送信元アドレスは、Ｐｏｄ６に割り振られたアドレスである。またアクセス要求９ａ，９ｂの送信元ポート番号は、アクセス要求９ａ，９ｂの出力時点で他のプロセスが使用していないポート番号である。そのためどのソフトウェア８ａ，８ｂからのアクセス要求９ａ，９ｂがどのポート番号を使用するのかを事前に知ることはできない。
【0019】
Ｐｏｄ５内のコンテナ５ａは、Ｐｏｄ６の死活監視およびＰｏｄ６内のプロセスの死活監視に用いられる。Ｐｏｄ６の死活監視は、例えばＰｏｄ５，６を管理するために用意されたＡＰＩ（Application Programming Interface）を用いて行うことができる。Ｐｏｄ５，６を管理するためのＡＰＩは、例えば図示しないＡＰＩサーバによって提供される。例えばコンテナ５ａ内の監視プロセスは、ネットワーク通信用に同一アドレスを使用するコンテナのＰｏｄが生成されるごとに、生成されたＰｏｄに対応する管理情報７を生成する。
【0020】
プロセスの死活監視は、情報処理装置１のＯＳ（Operating System）３を介して行うことができる。例えばコンテナ５ａ内の監視プロセスは、ＯＳ３のファイルシステムが管理しているプロセスごとのファイルの生成の有無を監視することで、コンテナ６ａ内のプロセスの死活監視を行うことができる。
【0021】
コンテナ５ａ内の監視プロセスは、１または複数のコンテナ６ａ，６ｂ，・・・のいずれかでプロセスが生成されたことを検知すると、管理情報７に、Ｐｏｄ６のアドレスに対応付けて、生成されたプロセスの識別情報を登録する。例えば監視プロセスは、ＯＳ３を介して、生成されたプロセスの使用しているネットワークネームスペースに対応するファイルのｉｎｏｄｅ番号を取得する。そして監視プロセスは、取得したｉｎｏｄｅ番号を含む管理情報７に、生成されたプロセスの識別情報を登録する。
【0022】
さらにコンテナ５ａ内の監視プロセスは、Ｐｏｄ６においてソフトウェア８ａ，８ｂ（送信元ソフトウェア）を実行する送信元プロセスによるＤＢ２ａへのアクセス要求９ａ，９ｂの出力を検知する。例えばコンテナ５ａ内の監視プロセスは、情報処理装置２から、出力されたアクセス要求９ａ，９ｂの送信元アドレスと送信元ポート番号との組を受信することで、アクセス要求９ａ，９ｂの出力を検知することができる。
【0023】
ＤＢ２ａへのアクセス要求９ａ，９ｂの出力を検知すると、コンテナ５ａ内の監視プロセスは、管理情報７において検知したアクセス要求９ａ，９ｂの送信元アドレスに関連付けられた１または複数のプロセスを特定する。さらにコンテナ５ａ内の監視プロセスは、特定した１または複数のプロセスの中から、アクセス要求９ａ，９ｂの送信元ポート番号を使用している送信元プロセスを特定する。例えばコンテナ５ａ内の監視プロセスは、送信元ポート番号を用いた通信で使用しているファイル（例えば受信データのバッファ）のファイル識別情報を取得し、取得したファイル識別情報に基づいて、送信元プロセスの識別情報を取得する。ファイルの識別情報は、例えばｉｎｏｄｅ番号である。
【0024】
そしてコンテナ５ａ内の監視プロセスは、例えばアクセス要求９ａ，９ｂを出力した送信元プロセスが実行しているソフトウェア８ａ，８ｂを示す情報を情報処理装置２に送信する。ソフトウェアを示す情報は、例えばそのソフトウェアの名前（ソフトウェア名）である。例えばコンテナ５ａ内の監視プロセスは、ＯＳ３から、アクセス要求９ａ，９ｂを出力したプロセスの識別情報を用いて、そのプロセスが実行している実行ファイルのファイル名と、そのファイルの保存場所を示すパスとを取得する。そしてコンテナ５ａ内の監視プロセスは、パスとファイル名との組を、ソフトウェア名として情報処理装置２に送信する。以下、パスとファイル名の組をファイルパスと呼ぶこともある。
【0025】
図１の例では、コンテナ５ａの監視プロセスは、送信元アドレスと送信元ポート番号との組「１０．３６．０．２：５５７６５」に応じて、そのポート番号「５５７６５」に対応するソフトウェアのソフトウェア名「ｓｗ＿１」を、情報処理装置２に送信する。またコンテナ５ａの監視プロセスは、送信元アドレスと送信元ポート番号との組「１０．３６．０．２：５０２１２」に応じて、そのポート番号「５０２１２」に対応するソフトウェアのソフトウェア名「ｓｗ＿２」を、情報処理装置２に送信する。
【0026】
情報処理装置２の処理部２ｂは、情報処理装置１からＤＢ２ａへのアクセス要求９ａ，９ｂを受信すると、そのアクセス要求９ａ，９ｂの送信元アドレスと送信元ポート番号との組を、情報処理装置１のＰｏｄ５のアドレスを指定して送信する。すると情報処理装置１から、アクセス要求９ａ，９ｂを送信したプロセスが実行するソフトウェア８ａ，８ｂを示す情報が送られる。そして処理部２ｂは、アクセス要求９ａ，９ｂを送信したプロセスが実行しているソフトウェア８ａ，８ｂに基づき、ＤＢ２ａへのアクセスが許可されているか否かを判定する。
【0027】
例えばＤＢ２ａには、複数のデータテーブル３ａ，３ｂが含まれる。アクセス要求９ａ，９ｂには、アクセス対象のデータテーブルが指定されている。処理部２ｂは、データテーブルごとに、そのデータテーブルに対するアクセスを許可するソフトウェアが示された許可情報４を有する。例えば許可情報４には、データテーブル名に対応付けて、そのデータテーブルへのアクセスを許可するソフトウェア名（許可対象ソフトウェア名）が設定されている。処理部２ｂは、許可情報４に基づいてアクセスが許可されているか否かを判定する。
【0028】
処理部２ｂは、アクセス要求９ａ，９ｂに応じたアクセスが許可されている場合、そのアクセス要求９ａ，９ｂに応じたＤＢ２ａへのアクセスを行い、アクセス結果を情報処理装置１に送信する。また処理部２ｂは、アクセス要求９ａ，９ｂに応じたアクセスが許可されてない場合、そのアクセス要求９ａ，９ｂに応じたＤＢ２ａへのアクセスを行わずに、エラーメッセージを情報処理装置１に送信する。
【0029】
図１の例では、ソフトウェア８ａを実行するプロセスから出力されたアクセス要求９ａのアクセス先は、データテーブル名「ｔｂｌ＿１」のデータテーブル３ａである。許可情報４では、データテーブル３ａに対するソフトウェア名「ｓｗ＿１」からのアクセスが許可されている。従って、処理部２ｂは、アクセス要求９ａの送信元ソフトウェアのソフトウェア名が「ｓｗ＿１」であることを認識すると、アクセス要求９ａに応じたデータテーブル３ａへのアクセスを実行する。
【0030】
またソフトウェア８ｂを実行するプロセスから出力されたアクセス要求９ｂのアクセス先も、データテーブル名「ｔｂｌ＿１」のデータテーブル３ａである。許可情報４では、データテーブル３ａに対するソフトウェア名「ｓｗ＿２」からのアクセスが許可されていない。従って、処理部２ｂは、アクセス要求９ｂの送信元ソフトウェアのソフトウェア名が「ｓｗ＿２」であることを認識すると、アクセス要求９ｂに応じたデータテーブル３ａへのアクセスを許否する。
【0031】
このように処理部２ｂは、コンテナ６ａ，６ｂ，・・・と同じ情報処理装置１内に実装されているコンテナ５ａからポート番号に対応するソフトウェア名を取得することで、一時的に割り当てられたポート番号を使用しているソフトウェアを認識できる。その結果、ポート番号を用いて、データテーブルに対するソフトウェアごとのアクセス制限を行うことができる。しかも情報処理装置１では、予めコンテナ６ａ，６ｂ，・・・内のプロセスの死活監視により、Ｐｏｄ６とプロセスとの対応関係が管理情報７で管理されている。そのため、Ｐｏｄ６のアドレスを送信元アドレスとするアクセス要求９ａ，９ｂであれば、Ｐｏｄ６内に生成されているプロセスの中から、アクセス要求９ａ，９ｂを出力した送信元プロセスを探索すればよい。そのためＰｏｄ６以外にも情報処理装置１内に多数のＰｏｄが存在している場合において、アクセス要求９ａ，９ｂを出力した送信元プロセスを効率的に特定することができる。
【0032】
Ｐｏｄ６のアドレスと生成されたプロセスとの対応関係を管理情報７に登録する際には、Ｐｏｄ６のネットワークネームスペースの情報を有効に利用することができる。例えばコンテナ５ａ内の監視プロセスは、管理情報７に、Ｐｏｄ６内のコンテナ６ａ，６ｂ，・・・が共通で使用するネットワークネームスペースを示す情報を、コンテナ６ａ，６ｂ，・・・が共通で使用するアドレスに対応付けて設定する。コンテナ５ａ内の監視プロセスは、生成されたプロセスが使用するネットワークネームスペースに対応するアドレスに対応付けて、生成されたプロセスの識別情報を管理情報７に登録する。
【0033】
Ｐｏｄ６のネットワークネームスペースを示す情報を管理情報７に含めておくことで、送信元ポート番号に対応するファイル識別情報の取得が容易となる。すなわちＰｏｄ５とＰｏｄ６とのネットワークネームスペースは分かれていることが多い。そのためＰｏｄ５内のプロセスからＰｏｄ６内のネットワークネームスペースで管理されている情報を取得するには、Ｐｏｄ６のネットワークネームスペースを特定する処理を行うこととなる。ネットワークネームスペースを示す情報が管理情報７に予め設定されていれば、例えばコンテナ５ａ内の監視プロセスは、Ｐｏｄ６のネットワークネームスペースにアクセスして、送信元ポート番号を用いた通信で使用しているファイルのファイル識別情報を取得することができる。このようにＰｏｄ６のネットワークネームスペースの特定が容易となり、送信元ポート番号に対応するファイル識別情報の取得も容易となる。
【0034】
またコンテナ５ａ内の監視プロセスは、取得したファイル識別情報に基づいて、アクセス要求９ａ，９ｂを出力したプロセスの識別情報を取得する。その際、コンテナ５ａ内の監視プロセスは、例えば管理情報７においてＰｏｄ６に対応付けて登録されているプロセスそれぞれが使用しているファイルの中から、取得したファイル識別情報に対応するファイルを検索する。このように検索の対象が管理情報７においてＰｏｄ６に対応付けて登録されているプロセスそれぞれが使用しているファイルに限定されることで、処理が効率的となる。
【0035】
なお図１の例では、アクセス制御を行う装置を２台の情報処理装置１，２として説明しているが、２台の情報処理装置１，２を含むシステム全体を１つの情報処理装置と呼ぶこともできる。またＤＢ２ａを情報処理装置１内に設けることもできる。その場合、情報処理装置２の処理部２ｂが実行する許否決定などの処理を情報処理装置１で実行させることとなり、１台の情報処理装置１のみでアクセス制御が実現される。
【0036】
〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態のシステムでは、アプリケーションソフトウェア（以下、アプリケーションと呼ぶ）ごとのＤＢへのアクセス管理を投機的に実行することで、アクセス管理に伴うＤＢのアクセス遅延を抑止する。
次に第２の実施の形態について説明する。第２の実施の形態のシステムでは、アプリケーションソフトウェア（以下、アプリケーションと呼ぶ）ごとのＤＢへのアクセス管理を投機的に実行することで、アクセス管理に伴うＤＢのアクセス遅延を抑止する。
【0037】
図２は、第２の実施の形態のシステム構成の一例を示す図である。第２の実施の形態では、ネットワーク２０を介して３台のノード１００，２００，３００が接続されている。ノード１００は、コンテナを用いてアプリケーションからＤＢへのアクセスを管理する。ノード２００は、コンテナを用いてアプリケーションを実行する。ノード３００は、ノード１００とノード２００で実行されているコンテナを管理する。
【0038】
図３は、ノードのハードウェアの一例を示す図である。ノード１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。
【0039】
メモリ１０２は、ノード１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。
【0040】
バス１０９に接続されている周辺機器としては、ストレージ装置１０３、ＧＰＵ（Graphics Processing Unit）１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。
【0041】
ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。
【0042】
ＧＰＵ１０４は画像処理を行う演算装置であり、グラフィックコントローラとも呼ばれる。ＧＰＵ１０４には、モニタ２１が接続されている。ＧＰＵ１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、有機ＥＬ（Electro Luminescence）を用いた表示装置や液晶表示装置などがある。
【0043】
入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
【0044】
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取り、または光ディスク２４へのデータの書き込みを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ－ＲＡＭ、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ－Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
【0045】
機器接続インタフェース１０７は、ノード１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。
【0046】
ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。ネットワークインタフェース１０８は、例えばスイッチやルータなどの有線通信装置にケーブルで接続される有線通信インタフェースである。またネットワークインタフェース１０８は、基地局やアクセスポイントなどの無線通信装置に電波によって通信接続される無線通信インタフェースであってもよい。
【0047】
ノード１００は、以上のようなハードウェアによって、第２の実施の形態の処理機能を実現することができる。ノード２００，３００も、図３に示したノード１００と同様のハードウェアにより実現することができる。なお、第１の実施の形態に示した情報処理装置１，２も、図３に示したノード１００と同様のハードウェアにより実現することができる。
【0048】
ノード１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態に示す処理機能を実現する。ノード１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、ノード１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またノード１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
【0049】
他のノード２００，３００についてもノード１００と同様に、コンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態に示す処理機能を実現することができる。
【0050】
ここで、第２の実施の形態によって実現しようとするアプリケーションごとのＤＢへのアクセス管理について説明する。
図４は、アプリケーションごとのＤＢへのアクセス管理の一例を示す図である。ノード１００はＤＢ１１０を有している。ＤＢ１１０内にＲＤＢＭＳによって個人情報（住所、氏名）を含む機密情報が保持されている。ＲＤＢＭＳでは、データが複数のデータテーブルに分けて格納されている。各データテーブルには、そのデータテーブルごとに定められたデータ定義に合致するデータが格納される。ＲＤＢＭＳではデータテーブルは一つ以上存在し、それぞれのテーブルに依存関係がある場合もある。
図４は、アプリケーションごとのＤＢへのアクセス管理の一例を示す図である。ノード１００はＤＢ１１０を有している。ＤＢ１１０内にＲＤＢＭＳによって個人情報（住所、氏名）を含む機密情報が保持されている。ＲＤＢＭＳでは、データが複数のデータテーブルに分けて格納されている。各データテーブルには、そのデータテーブルごとに定められたデータ定義に合致するデータが格納される。ＲＤＢＭＳではデータテーブルは一つ以上存在し、それぞれのテーブルに依存関係がある場合もある。
【0051】
図４の例では、ＤＢ１１０内に登録者情報テーブル１１１と購入情報テーブル１１２とがある。登録者情報テーブル１１１には、登録者ＩＤ、登録者、年齢、都道府県の欄が設けられており、各欄に対応するデータを含む複数のレコードが登録されている。購入情報テーブル１１２には、購入ＩＤ、登録者ＩＤ、商品ＩＤ、および日時の欄が設けられており、各欄に対応するデータを含む複数のレコードが登録されている。登録者情報テーブル１１１と購入情報テーブル１１２とは、登録者ＩＤを介して互いに関係付けられている。
【0052】
ノード２００は、コンテナ２１１，２１２を用いてＤＢ１１０へアクセスする。コンテナ２１１，２１２は、コンテナオーケストレーションツールで管理されているものとする。コンテナオーケストレーションツールでは、Ｐｏｄ単位でコンテナを管理する。コンテナ２１１，２１２は、ユーザアプリＰｏｄ２１０に含まれている。
【0053】
ユーザアプリＰｏｄ２１０内のコンテナ２１１，２１２のように同一のＰｏｄ内のコンテナは、共有のストレージアクセス環境・ネットワークアクセス環境を持ち、同じネットワーク名前空間（ネットワークネームスペース）を使用する。そのため、互いに簡単に通信が出来る。多くの場合、メインの動作を行うプログラムが入ったコンテナ一つに、それをサポートするヘルパープログラム（ログ収集、プロキシ、コントローラ、バックアップなど）を実行するコンテナがいくつか入ったものがＰｏｄとして使用される。このようなヘルパープログラムを実行するコンテナを、サイドカーコンテナと呼ぶ。
【0054】
ノード２００はユーザアプリＰｏｄ２１０を有している。ユーザアプリＰｏｄ２１０は、アプリケーションを実行させるための実行単位である。ユーザアプリＰｏｄ２１０は、複数のコンテナ２１１，２１２を有する。コンテナ２１１では、アプリケーション２１１ａが実行されている。コンテナ２１２では、アプリケーション２１２ａが実行されている。
【0055】
例えばアプリケーション２１２ａは、ＤＢ１１０から読み出したデータの匿名化を行うアプリケーションであるものとする。登録者情報テーブル１１１には、ユーザの個人情報が含まれているため、登録者情報テーブル１１１から読み出したデータは、匿名化処理を行った後に利用するのが適切である。そこでノード１００は、アプリケーション２１２ａからのみ登録者情報テーブル１１１にアクセス可能となるように、アクセスを制御する。この場合、アプリケーション２１１ａは、アプリケーション２１２ａを介して、登録者情報テーブル１１１内のデータにアクセス可能となる。なお、購入情報テーブル１１２には個人情報が含まれていないため、ノード１００は、両方のアプリケーション２１１ａ，２１２ａから購入情報テーブル１１２へのアクセスが可能となるように制御する。
【0056】
このようにノード１００は、テーブル単位で、アプリケーションごとに異なるアクセス制限を課すようにアクセス制御を行う。以下、図５，図６を参照して、アプリケーションごとに異なるアクセス制限を課すようなアクセス制御を行うことの困難性について説明する。
【0057】
図５は、ＤＢへのアクセス制御に関する参考技術の第１の例を示す図である。図５には、サイドカーコンテナを用いたコンテナオーケストレーションツールによって、ＤＢ１１０へのアクセスを制御する例が示されている。サイドカーコンテナとしてプロキシコンテナ９００を挿入することで、プロキシコンテナ９００を介した通信について、フィルタリングや統計情報の保存を行うことができる。例えばプロキシコンテナ９００は、ＤＢ１１０へのアクセス要求の送信元のＩＰアドレスとポート番号とに基づいてフィルタリングを行うことができる。送信元のＩＰアドレスとポート番号は、アクセス要求の送信に用いられたパケットのヘッダから取得できる。ただし図５に示すプロキシコンテナ９００は、ポート番号に対応するアプリケーション２１１ａ，２１２ａの識別情報（アプリケーション名など）を取得する機能を持たないものとする。
【0058】
Ｐｏｄ単位でコンテナ２１１，２１２を管理している場合、Ｐｏｄ単位でＩＰアドレスが割り振られる。そのためプロキシコンテナ９００を用いて送信元のＩＰアドレスとポート番号でフィルタリングを行う場合、ＩＰアドレスだけでは同一のユーザアプリＰｏｄ２１０内のアプリケーション２１１ａ，２１２ａを識別することができない。送信元ポート番号は別々に振られているが、特別に送信元が設定しない限りは空いているポート番号が用いられている。すなわちアプリケーション２１１ａ，２１２ａそれぞれが使用するポート番号は動的に変更され、プロキシコンテナ９００においてアクセス要求のポート番号から、そのアクセス要求の送信元のアプリケーションの種別を判別するのは不可能である。
【0059】
またプロキシコンテナ９００では、ＩＰアドレスとポート番号だけではアクセス先となるデータテーブルを把握することができない。そのためプロキシコンテナ９００によるＤＢ１１０内のテーブルごとに、アプリケーションに応じたアクセスの許否を判断するには、送信元のＩＰアドレスとポート番号に対応するアプリケーションの種別が把握できるだけでは不十分である。
【0060】
図６は、ＤＢへのアクセス制御に関する参考技術の第２の例を示す図である。図６には、ＲＤＢＭＳにおけるユーザ単位でのアクセス制御機能を用いて、アプリケーション単位でのアクセス制御を可能とする例が示されている。
【0061】
ＲＤＢＭＳは、テーブルごとに、そのテーブルに対するアクセスを許容するユーザを制限する機構を持っている。そこでＰｏｄ作成者３０は、アプリケーション２１１ａ，２１２ａを、別々のユーザアカウントで実行する。例えばアプリケーション２１１ａは「ユーザＢ」のユーザアカウントで実行され、アプリケーション２１２ａは「ユーザＡ」のユーザアカウントで実行されている。
【0062】
ＲＤＢＭＳには、登録者情報テーブル１１１に設定されているデータ（登録者情報）にアクセス可能なユーザとして、「ユーザＡ」が設定される。また購入情報テーブル１１２に設定されているデータ（購入情報）にアクセス可能なユーザとして、「ユーザＡ、ユーザＢ」が設定される。このようにＲＤＢＭＳには、各テーブルについて、ユーザ単位でのアクセス権限を定義することができる。そしてＲＤＢＭＳは、アクセス可能なユーザのアカウントで実行されているアプリケーションからのアクセスであれば、データへのアクセスを許容する。
【0063】
図６の例では、「ユーザＢ」のアカウントで実行されているアプリケーション２１１ａは、購入情報テーブル１１２へのアクセスは可能であるが、登録者情報テーブル１１１へのアクセスは不可能となる。他方、「ユーザＡ」のアカウントで実行されているアプリケーション２１２ａは、登録者情報テーブル１１１と購入情報テーブル１１２との両方へアクセス可能である。このようにＲＤＢＭＳにおけるユーザのアカウントのアクセス権限管理を用いれば、ユーザのアカウントとアプリケーションとを関連付けることで、アプリケーション単位でのアクセス制御が可能となる。
【0064】
しかし、ＲＤＢＭＳは、アクセスの要求元のアプリケーションのユーザアカウントを判別することはできても、これがどのアプリケーションに使われているかを把握することはできない。そのため、Ｐｏｄ作成者３０が、ＲＤＢＭＳへのアプリケーションテーブルとユーザアカウントとの関係付けの設定を誤った場合、アクセスを拒否するべきアプリケーションからのテーブルへのアクセスが許可されてしまう可能性がある。
【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】
なお、図９に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。
図９に示した構成のシステムにより、アプリケーション２１１ａ，２１２ａからＤＢ１１０へのアクセスのためのクエリが出力されるごとに、そのクエリに応じたアクセスの許否判定処理を効率的に行うことができる。効率的な許否判定のために、監視用コンテナ２２１は、Ｐｏｄ死活監視とプロセス死活監視とを行い、Ｐｏｄ情報リソースを生成する。
図９に示した構成のシステムにより、アプリケーション２１１ａ，２１２ａからＤＢ１１０へのアクセスのためのクエリが出力されるごとに、そのクエリに応じたアクセスの許否判定処理を効率的に行うことができる。効率的な許否判定のために、監視用コンテナ２２１は、Ｐｏｄ死活監視とプロセス死活監視とを行い、Ｐｏｄ情報リソースを生成する。
【0098】
図１０は、死活監視処理の一例を示す図である。監視用Ｐｏｄ２２０が有する監視用コンテナ２２１は、例えばＡＰＩサーバ３１０を介して、ユーザアプリＰｏｄ２１０の死活監視を行う。すなわち、ＡＰＩサーバ３１０は、特定のリソースが作成・更新・削除されたときにそれを検知することができる。監視用コンテナ２２１は、ＡＰＩサーバ３１０の機能を利用して、ユーザアプリＰｏｄ２１０の死活監視を行う。
【0099】
監視用コンテナ２２１は、例えば、定期的にＡＰＩサーバ３１０が管理対象としているＰｏｄの情報をＡＰＩサーバ３１０から取得する。監視用コンテナ２２１は、ユーザアプリＰｏｄ２１０が生成されたことを検知すると、そのユーザアプリＰｏｄ２１０に関するＰｏｄ情報リソース４１をＡＰＩサーバ３１０から取得する。Ｐｏｄ情報リソース４１には、例えばユーザアプリＰｏｄ２１０のＩＰアドレス、ユーザアプリＰｏｄ２１０のネットワークネームスペース用のｉｎｏｄｅ番号、ユーザアプリＰｏｄ２１０内のコンテナのＰＩＤが含まれる。
【0100】
また監視用コンテナ２２１は、例えばＯＳ２０１を介して、ユーザアプリＰｏｄ２１０内のプロセスの死活監視を行う。ＯＳ２０１は、ノード２００内で生成されたプロセスの管理ファイルを有している。そこで監視用コンテナ２２１は、例えばプロセスの管理用のファイル（／ｐｒｏｃ／［ＰＩＤ］）の生成または削除を検知することで、プロセスの死活監視を行うことができる。監視用コンテナ２２１は、プロセスが生成された場合には、そのプロセスの管理ファイルから、プロセス情報５１を取得する。プロセス情報５１には、例えばＰＩＤ、ネットワークネームスペースを示す情報（ネットワークネームスペースのｉｎｏｄｅ番号）などが含まれる。
【0101】
監視用コンテナ２２１は、プロセス情報５１に示されるネットワークネームスペースのｉｎｏｄｅ番号に基づいて、該当プロセスを有するユーザアプリＰｏｄ２１０を特定する。そして監視用コンテナ２２１は、特定したユーザアプリＰｏｄ２１０のＰｏｄ情報リソース４１に、生成されたプロセスのＰＩＤを登録する。
【0102】
次に、Ｐｏｄ死活監視処理におけるＰｏｄ生成時の処理について詳細に説明する。監視用コンテナ２２１内の内部アプリ情報取得部２２１ａは、ユーザアプリＰｏｄ２１０が作成されたことを検知すると、ユーザアプリＰｏｄ２１０内で共通となるネットワークネームスペースの特定処理を行う。なおユーザアプリＰｏｄ２１０から得られる詳細情報にはユーザアプリＰｏｄ２１０内のネットワークネームスペースを直接的に特定する情報は含まれていない。そのため内部アプリ情報取得部２２１ａは、ユーザアプリＰｏｄ２１０内のコンテナのＩＤからコンテナ情報を辿り、そのコンテナのプロセスを特定する。そして内部アプリ情報取得部２２１ａは、特定したプロセスの情報から、ユーザアプリＰｏｄ２１０のネットワークネームスペースを特定する情報（ｉｎｏｄｅ番号）を取得する。
【0103】
例えばコンテナエンジン２０２がＤｏｃｋｅｒ（登録商標）であれば、内部アプリ情報取得部２２１ａは、コンテナＩＤからコンテナ詳細情報を取ることで、コンテナのＰＩＤを取得することができる。コンテナ詳細情報の取得には、ｄｏｃｋｅｒ ｉｎｓｐｅｃｔコマンドを利用することができる。
【0104】
図１１は、コンテナ詳細情報の一例を示す図である。コンテナ詳細情報５２には、例えばコンテナのＩＤに加え、そのコンテナ内のプロセスのＰＩＤが含まれている。図１１の例では、コンテナ詳細情報５２内にＰＩＤ「３７５」が示されている。
【0105】
ユーザアプリＰｏｄ２１０内ではネットワークネームスペースが共有される。そのため、ユーザアプリＰｏｄ２１０内のコンテナのＰＩＤが分かればユーザアプリＰｏｄ２１０内で共通のネットワークネームスペースへとアクセスすることができる。そこで内部アプリ情報取得部２２１ａは、コンテナ詳細情報５２に示されるＰＩＤに対応するプロセスが使用しているネットワークネームスペースにアクセスする。そして内部アプリ情報取得部２２１ａは、そのネットワークネームスペースを共有するプロセスの検出用に、ファイル「／ｐｒｏｃ／［ＰＩＤ］／ｎｓ／ｎｅｔ」のｉｎｏｄｅ番号を、例えばＯＳ２０１から取得する。
【0106】
内部アプリ情報取得部２２１ａは、生成されたユーザアプリＰｏｄ２１０に関する情報を、Ｐｏｄ情報リソースとして保存する。内部アプリ情報取得部２２１ａは、他のユーザアプリＰｏｄが生成された場合にも、同様にＰｏｄリソースを生成し、保存する。その結果、Ｐｏｄ情報リソース群が生成される。なおＰｏｄリソース群は、第１の実施の形態における管理情報７の一例である。
【0107】
図１２は、Ｐｏｄ情報リソース群の一例を示す図である。Ｐｏｄ情報リソース群４０には、複数のＰｏｄ情報リソース４１，４２，４３，・・・が含まれる。例えばＰｏｄ情報リソース４１には、Ｐｏｄ名「ｔｅｓｔ－ｐｏｄ－１ｈｓｙａｂ」、ＩＰアドレス「１９２．１６．１８．２２」、ｉｎｏｄｅ番号「４０２６５３１９６８」、ユーザアプリＰｏｄ２１０内のプロセスのＰＩＤ「１５４２４」が含まれている。Ｐｏｄ情報リソース４１に示されるｉｎｏｄｅ番号は、ネットワークネームスペースに関する情報を示すファイルのｉｎｏｄｅ番号である。
【0108】
なおＰｏｄ情報リソース４１に含まれているＰＩＤは、ユーザアプリＰｏｄ２１０内の１つのコンテナのＰＩＤであり、ユーザアプリＰｏｄ２１０内で動作しているアプリケーション２１１ａ，２１２ａのＰＩＤとは必ずしも一致しない。例えばコンテナ２１１を動かしてから内部でアプリケーション２１１ａを起動した場合には、アプリケーション２１１ａ実行用にコンテナ２１１とは別のプロセスが生成される。アプリケーション２１１ａからクエリが送信される場合、そのクエリの送信元のＰＩＤはアプリケーション２１１ａを実行するプロセスのＰＩＤである。そのため、図１２に示す情報だけでは送信元アプリまで対応付けることはできない。
【0109】
図１３は、Ｐｏｄ生成時の処理の手順の一例を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。
［ステップＳ１０１］内部アプリ情報取得部２２１ａは、ユーザアプリＰｏｄが生成されたことを検知する。例えば内部アプリ情報取得部２２１ａは、ＡＰＩサーバ３１０から管理対象となるユーザアプリＰｏｄの情報を取得し、未知のユーザアプリＰｏｄがある場合、そのユーザアプリＰｏｄが生成されたと検知する。
［ステップＳ１０１］内部アプリ情報取得部２２１ａは、ユーザアプリＰｏｄが生成されたことを検知する。例えば内部アプリ情報取得部２２１ａは、ＡＰＩサーバ３１０から管理対象となるユーザアプリＰｏｄの情報を取得し、未知のユーザアプリＰｏｄがある場合、そのユーザアプリＰｏｄが生成されたと検知する。
【0110】
［ステップＳ１０２］内部アプリ情報取得部２２１ａは、生成されたユーザアプリＰｏｄのコンテナＩＤに基づいて、そのコンテナのＰＩＤを取得する。
［ステップＳ１０３］内部アプリ情報取得部２２１ａは、取得したＰＩＤに対応するファイル「／ｐｒｏｃ／［ＰＩＤ］」の情報に基づいて、ネットワークネームスペースのｉｎｏｄｅ番号を取得する。
［ステップＳ１０３］内部アプリ情報取得部２２１ａは、取得したＰＩＤに対応するファイル「／ｐｒｏｃ／［ＰＩＤ］」の情報に基づいて、ネットワークネームスペースのｉｎｏｄｅ番号を取得する。
【0111】
［ステップＳ１０４］内部アプリ情報取得部２２１ａは、Ｐｏｄ名、ＩＰアドレス、ネットワークネームスペースのｉｎｏｄｅ番号を含むＰｏｄ情報リソースを、メモリまたはストレージ装置に保存する。
【0112】
このようなＰｏｄ死活監視により、例えばユーザアプリＰｏｄ２１０が生成されると、そのユーザアプリＰｏｄ２１０に対応するＰｏｄ情報リソース４１が生成され、内部アプリ情報取得部２２１ａで管理される。
【0113】
次にプロセス死活監視処理について詳細に説明する。内部アプリ情報取得部２２１ａは、例えば定期的に「／ｐｒｏｃ」フォルダをチェックすることでプロセスの死活監視を行う。内部アプリ情報取得部２２１ａは、「／ｐｒｏｃ」フォルダ内に新しい「／ｐｒｏｃ／［ＰＩＤ］」ファイルが生成された場合、それを検知する。そして内部アプリ情報取得部２２１ａは、そのＰＩＤの「／ｐｒｏｃ／［ＰＩＤ］／ｎｓ」フォルダを調べることにより、ネットワークネームスペース用のｉｎｏｄｅ番号を取得する。
【0114】
例えば「／ｐｒｏｃ／［ＰＩＤ］／ｎｓ」フォルダ内にはシンボリックリンクとして見える複数のファイルが配置されている。それらのファイルのうち「／ｐｒｏｃ／［ＰＩＤ］／ｎｓ／ｎｅｔ」は［ＰＩＤ］に対応するプロセスのネットワークネームスペースの操作用ファイルである。内部アプリ情報取得部２２１ａは、このネットワークネームスペースの操作用ファイルのシンボリックリンク先をｒｅａｄｌｉｎｋまたは「ｌｓ －ｌ」コマンドで参照する。これにより、そのプロセスが使用するネットワークネームスペースのｉｎｏｄｅ番号を取得することができる。
【0115】
例えば内部アプリ情報取得部２２１ａは、ＰＩＤが「１」のとき、スーパーユーザ権限で「ｒｅａｄｌｉｎｋ ／ｐｒｏｃ／１／ｎｓ／ｎｅｔ」コマンドの実行をＯＳ２０１に指示する。するとＯＳ２０１からは、例えば「ｎｅｔ：［４０２６５３１９６８］」という情報が応答される。応答された情報内の数字列が、ネットワークネームスペースのｉｎｏｄｅ番号である。また内部アプリ情報取得部２２１ａは、ＰＩＤが「１」のとき、スーパーユーザ権限で「ｌｓ －ｌａ ／ｐｒｏｃ／１／ｎｓ／ｎｅｔ」コマンドの実行をＯＳ２０１に指示する。するとＯＳ２０１からは、例えば「ｌｒｗｘｒｗｘｒｗｘ １ ｒｏｏｔ ｒｏｏｔ ０ １月 １７ １１：０９ ／ｐｒｏｃ／１／ｎｓ／ｎｅｔ －＞ ’ｎｅｔ：［４０２６５３１９６８］’」という情報が応答される。応答された情報内の最後の数字列が、ネットワークネームスペースのｉｎｏｄｅ番号である。
【0116】
内部アプリ情報取得部２２１ａは、ネットワークネームスペースのｉｎｏｄｅ番号を取得すると、対応するＰｏｄ情報リソースを検索する。例えば内部アプリ情報取得部２２１ａは、取得したｉｎｏｄｅ番号を検索キーとして、Ｐｏｄ情報リソース群４０内のＰｏｄ情報リソース４１，４２，４３，・・・を検索する。内部アプリ情報取得部２２１ａは、検索でヒットしたＰｏｄ情報リソースに対応するユーザアプリＰｏｄが、生成されたプロセスを含むユーザアプリＰｏｄであると判断する。内部アプリ情報取得部２２１ａは、生成されたプロセスを含むユーザアプリＰｏｄを特定したら、対応するＰｏｄ情報リソース内に、生成されたプロセスのＰＩＤを追記する。
【0117】
図１４は、生成されたプロセスのＰＩＤが追記されたＰｏｄ情報リソースの一例を示す図である。Ｐｏｄ情報リソース４１には、生成されたプロセスのＰＩＤとして「１５７５６」などのＰＩＤが追記されている。このように生成されたプロセスのＰＩＤをＰｏｄ情報リソース４１，４２，４３，・・・に追記することで、ユーザアプリＰｏｄと、そのユーザアプリＰｏｄの中で動作する複数のプロセスのＰＩＤ（ＰＩＤ一覧）とが関連付けられる。
【0118】
図１５は、プロセス生成時の処理の手順の一例を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。
［ステップＳ１１１］内部アプリ情報取得部２２１ａは、「／ｐｒｏｃ」フォルダ内に新たな「／Ｐｏｄ／［ＰＩＤ］」ファイルが生成されたことを検知する。内部アプリ情報取得部２２１ａは、生成されたファイルの［ＰＩＤ］の部分の文字列を、生成されたプロセスのＰＩＤとして認識する。
［ステップＳ１１１］内部アプリ情報取得部２２１ａは、「／ｐｒｏｃ」フォルダ内に新たな「／Ｐｏｄ／［ＰＩＤ］」ファイルが生成されたことを検知する。内部アプリ情報取得部２２１ａは、生成されたファイルの［ＰＩＤ］の部分の文字列を、生成されたプロセスのＰＩＤとして認識する。
【0119】
［ステップＳ１１２］内部アプリ情報取得部２２１ａは、「／Ｐｏｄ／［ＰＩＤ］」ファイルの情報に基づいて、生成されたプロセスが使用するネットワークネームスペースのｉｎｏｄｅ番号を取得する。
【0120】
［ステップＳ１１３］内部アプリ情報取得部２２１ａは、生成されたプロセスとネットワークネームスペースが同じユーザアプリＰｏｄのＰｏｄ情報リソースを、Ｐｏｄ情報リソース群４０から検索する。例えば内部アプリ情報取得部２２１ａは、Ｐｏｄ情報リソース群４０から、ステップＳ１１２で取得したｉｎｏｄｅ番号を含むＰｏｄ情報リソースを検索する。
【0121】
［ステップＳ１１４］内部アプリ情報取得部２２１ａは、ステップＳ１１３の検索でヒットしたＰｏｄ情報リソースに、生成されたプロセスのＰＩＤを追記する。
このようにして、プロセスが生成されるごとに、そのプロセスのＰＩＤが、そのプロセスを含むユーザアプリＰｏｄのＰｏｄ情報リソースに追記される。
このようにして、プロセスが生成されるごとに、そのプロセスのＰＩＤが、そのプロセスを含むユーザアプリＰｏｄのＰｏｄ情報リソースに追記される。
【0122】
プロセスの死活監視では、プロセスの消滅も検知することができる。プロセスが消滅した場合、対応するＰｏｄ情報リソースから、消滅したプロセスのＰＩＤの表記を削除するのが望ましい。しかし、「／ｐｒｏｃ」フォルダから１つの「／Ｐｏｄ／［ＰＩＤ］」ファイルが消えたとき、そのファイルが消えた後に、そのファイルに対応するプロセスがどのネットワークネームスペースを使っていたかを後追いするのは困難である。例えば内部アプリ情報取得部２２１ａは、プロセスの消滅を検知したとき、すべてのＰｏｄ情報リソース４１，４２，４３，・・・を調べて、対応する「／Ｐｏｄ／［ＰＩＤ］」ファイルが存在しないＰＩＤを見つけ出すこととなる。このような処理は、ユーザアプリＰｏｄの数が増えるほどオーバーヘッドが増大する。場合によっては、ＰＩＤを削除するために、システム全体のパフォーマンスに影響が出る可能性もある。ただしＰＩＤの削除処理は重要度が高くないため、システムのパフォーマンスを犠牲にしてまで実行することは推奨されない。そこで内部アプリ情報取得部２２１ａは、プロセスの消滅に対応するため、以下の２通りの処理のいずれかを行うことができる。
【0123】
第１の処理は、消滅したプロセスのＰＩＤを迅速に削除するものである。例えば内部アプリ情報取得部２２１ａは、ＰＩＤとネットワークネームスペースの対応をキャッシュとして、メモリまたはストレージ装置に保存しておく。これによりＰＩＤに基づいて、そのＰＩＤが記載されたＰｏｄ情報リソースに迅速にアクセス可能となる。その結果、消滅したプロセスのＰＩＤの検出も効率的に行うことができ、システムのパフォーマンスの低下を抑止する。
【0124】
第２の処理は、プロセス消滅時には何も行わず、クエリの送信元アプリ特定時に、存在しないＰＩＤを検出したときに、そのＰＩＤをＰｏｄ情報リソースから削除するものである。例えば消滅したプロセスと同じＰＩＤの別プロセスが生成され、生成されたプロセスと同じＰＩＤが存在するときがある。この場合、内部アプリ情報取得部２２１ａは、クエリの送信元に対応するプロセスのＰＩＤとは異なるネットワークネームスペースのＰｏｄ情報リソースに同じＰＩＤが登録されていることを検出し、消滅したプロセスのＰＩＤの存在を認識する。内部アプリ情報取得部２２１ａは、消滅したプロセスのＰＩＤの存在を認識したら、そのＰＩＤを削除する。
【0125】
より理想に近い挙動は第１の処理である。しかし第２の処理を採用しても、悪い影響は少ない。なぜなら、既に存在しないＰＩＤからクエリが出力されることはなく、クエリの送信元を探索するときは既にＰｏｄ内にないＰＩＤが残存していても、該当するプロセスではないとして検出されないだけで終わるからである。それでも検索対象のＰＩＤの数が増大しすぎると処理速度の低下の原因になりかねない。そのためプロセスの消滅を見つけ次第Ｐｏｄ情報リソースから該当プロセスのＰＩＤを削除するのが好ましい。
【0126】
次にクエリが出力された場合の処理について詳細に説明する。
図１６は、ＤＢへのアクセスの際の情報の流れを示す図である。例えばコンテナ２１２内のアプリケーション２１２ａから、アプリケーションからのアクセスが許可されているテーブル内のデータを参照するクエリが出力されているものとする。出力されたクエリは、プロキシコンテナ１２１内のプロキシ部１２１ａに送信される。プロキシ部１２１ａは、アプリ情報取得部１２１ｂへクエリの送信元のＩＰアドレスとポート番号とを送信する。またプロキシ部１２１ａは、接続先テーブル取得部１２１ｄにクエリを送信する。
図１６は、ＤＢへのアクセスの際の情報の流れを示す図である。例えばコンテナ２１２内のアプリケーション２１２ａから、アプリケーションからのアクセスが許可されているテーブル内のデータを参照するクエリが出力されているものとする。出力されたクエリは、プロキシコンテナ１２１内のプロキシ部１２１ａに送信される。プロキシ部１２１ａは、アプリ情報取得部１２１ｂへクエリの送信元のＩＰアドレスとポート番号とを送信する。またプロキシ部１２１ａは、接続先テーブル取得部１２１ｄにクエリを送信する。
【0127】
アプリ情報取得部１２１ｂは、監視用コンテナ２２１に、クエリの送信元のＩＰアドレスとポート番号との組を送信する。監視用コンテナ２２１内の内部アプリ情報取得部２２１ａは、Ｐｏｄ情報リソース群４０内のＰｏｄ情報リソース４１，４２，４３，・・・から、取得したＩＰアドレスを含むＰｏｄ情報リソースを特定する。内部アプリ情報取得部２２１ａは、特定したＰｏｄ情報リソースに示されているネットワークネームスペースのｉｎｏｄｅ番号と、そのネットワークネームスペース内で動作するプロセスのＰＩＤ一覧を取得する。次に内部アプリ情報取得部２２１ａは、ｉｎｏｄｅ番号で示されるネットワークネームスペース内にアクセスし、送信元のポート番号に対応するｉｎｏｄｅ番号（送信元アプリのｉｎｏｄｅ番号）を取得する。
【0128】
さらに内部アプリ情報取得部２２１ａは、ＰＩＤ一覧に示されるＰＩＤについて「／ｐｒｏｃ／［ＰＩＤ］／ｆｄ」フォルダ内から、送信元アプリのｉｎｏｄｅ番号に対応するファイルディスクリプタを検索する。一致したフォルダのＰＩＤが、送信元アプリのＰＩＤである。このとき検索するＰＩＤは対象となるＰｏｄ情報リソース内のＰＩＤのみを用いればよい。そのため、ノード２００内のすべてのプロセスのＰＩＤを検索対象とする場合に比べ、実行時間を削減することができる。
【0129】
送信元アプリのＰＩＤが特定できると、内部アプリ情報取得部２２１ａは、送信元アプリのＰＩＤに基づいて、「／ｐｒｏｃ／［ＰＩＤ］／ｅｘｅ」などの情報からアプリ名やパスを取得する。そして内部アプリ情報取得部２２１ａは、送信元アプリのファイルパス（パス＋アプリ名）をノード１００のアプリ情報取得部１２１ｂに送信する。
【0130】
アプリ情報取得部１２１ｂは、取得したファイルパスを許否判断部１２１ｅに送信する。許可情報取得部１２１ｃは、カスタムリソース３２０に許可情報の問合せを送信する。カスタムリソース３２０は、許可情報取得部１２１ｃに許可情報を送信する。許可情報取得部１２１ｃは、取得した許可情報を許否判断部１２１ｅに送信する。
【0131】
接続先テーブル取得部１２１ｄは、プロキシ部１２１ａから送られたクエリのＥｘｐｌａｉｎコマンドをＤＢコンテナ１２２に送信する。ＤＢコンテナ１２２は、クエリの接続先テーブル名を含むＥｘｐｌａｉｎ結果を接続先テーブル取得部１２１ｄに送信する。接続先テーブル取得部１２１ｄは、接続先テーブルを示す情報を許否判断部１２１ｅに送信する。
【0132】
許否判断部１２１ｅは、ファイルパス、許可情報、接続先テーブル名に基づいて、クエリによるアクセスの許否を判断し、判断結果（許可または不許可）をプロキシ部１２１ａに送信する。プロキシ部１２１ａは、クエリをＤＢコンテナ１２２に送信する。ＤＢコンテナ１２２は、ＲＤＢＭＳによりクエリに応じたＤＢ１１０へのアクセスを行い、アクセス結果をプロキシ部１２１ａに送信する。プロキシ部１２１ａは、アクセスが許可と判断された場合、取得したアクセス結果をアプリケーション２１２ａに送信する。
【0133】
図１６に示すようなアクセス制御機能によれば、プロキシコンテナ１２１によってＤＢ１１０へのクエリが途中でキャッチされ、送信元のアプリケーションの通信の内容（クエリ）に基づいて、送信元のアプリケーションと接続先テーブルとが特定される。そして、特定されたアプリケーションから接続先テーブルへのアクセスを許可する許可情報が設定されていれば、クエリに基づくＤＢ１１０へのアクセス結果が、クエリの送信元のアプリケーションに送信される。
【0134】
図１７は、アプリケーションのファイルパスの取得手順の一例を示すフローチャートである。以下、図１７に示す処理をステップ番号に沿って説明する。
［ステップＳ２０１］プロキシコンテナ１２１では、アプリ情報取得部１２１ｂがプロキシ部１２１ａから、クエリの送信元のＩＰアドレスとポート番号を受信する。
［ステップＳ２０１］プロキシコンテナ１２１では、アプリ情報取得部１２１ｂがプロキシ部１２１ａから、クエリの送信元のＩＰアドレスとポート番号を受信する。
【0135】
［ステップＳ２０２］アプリ情報取得部１２１ｂは、監視用コンテナ２２１に送信元のＩＰアドレスとポート番号との組を送信する。
［ステップＳ２０３］監視用コンテナ２２１では、内部アプリ情報取得部２２１ａが送信元のＩＰアドレスで、Ｐｏｄ情報リソース群４０内のＰｏｄ情報リソースを検索する。内部アプリ情報取得部２２１ａは、送信元のＩＰアドレスを含むＰｏｄ情報リソースを、送信元のアプリケーションを含むユーザアプリＰｏｄのＰｏｄ情報リソースであると特定する。
［ステップＳ２０３］監視用コンテナ２２１では、内部アプリ情報取得部２２１ａが送信元のＩＰアドレスで、Ｐｏｄ情報リソース群４０内のＰｏｄ情報リソースを検索する。内部アプリ情報取得部２２１ａは、送信元のＩＰアドレスを含むＰｏｄ情報リソースを、送信元のアプリケーションを含むユーザアプリＰｏｄのＰｏｄ情報リソースであると特定する。
【0136】
［ステップＳ２０４］内部アプリ情報取得部２２１ａは、特定したＰｏｄ情報リソースに基づいて、送信元のポート番号とｉｎｏｄｅ番号との対応関係を取得する。例えば内部アプリ情報取得部２２１ａは、特定したＰｏｄ情報リソースに示されるネットワークネームスペースのｉｎｏｄｅ番号に基づいてネットワークネームスペースを特定し、そのネットワークネームスペースにアクセスする。そして内部アプリ情報取得部２２１ａは、ネットワークネームスペースから、送信元のポート番号に対応するアプリケーションのみが使用するファイルのｉｎｏｄｅ番号を取得する。
【0137】
［ステップＳ２０５］内部アプリ情報取得部２２１ａは、送信元ポート番号に対応するｉｎｏｄｅ番号に基づいて、送信元のアプリケーションのＰＩＤを特定する。例えば内部アプリ情報取得部２２１ａは、ステップＳ２０３で特定したＰｏｄ情報リソース内のＰＩＤ一覧に含まれるＰＩＤそれぞれに対応するプロセスが使用するファイルのファイルディスクリプタを参照する。そして内部アプリ情報取得部２２１ａは、ステップＳ２０４で取得したｉｎｏｄｅ番号と一致するファイルディスクリプタを検出する。内部アプリ情報取得部２２１ａは、検出したファイルディスクリプタを使用しているプロセスのＰＩＤを、送信元のアプリケーションのＰＩＤとして特定する。
【0138】
［ステップＳ２０６］内部アプリ情報取得部２２１ａは、特定したＰＩＤに対応するアプリケーションのファイルパスを取得する。例えば内部アプリ情報取得部２２１ａは、ファイル「／ｐｒｏｃ／［ＰＩＤ］／ｅｘｅ」（［ＰＩＤ］はステップＳ２０５で特定したＰＩＤ）にアクセスし、ファイル内の情報を取得する。このファイルは、ＰＩＤに対応する実行ファイルへのシンボリックリンクであり、該当ファイルのファイルパスが含まれている。
【0139】
［ステップＳ２０７］内部アプリ情報取得部２２１ａは、取得したファイルパスをプロキシコンテナ１２１に送信する。
このようにして、プロキシコンテナ１２１においてポート番号に対応するアプリケーションのファイルパスを取得することができる。これにより、アプリケーションからクエリが送信されるごとにポート番号が異なっていても、プロキシコンテナ１２１においてクエリの送信元のアプリケーションを正しく認識できる。
このようにして、プロキシコンテナ１２１においてポート番号に対応するアプリケーションのファイルパスを取得することができる。これにより、アプリケーションからクエリが送信されるごとにポート番号が異なっていても、プロキシコンテナ１２１においてクエリの送信元のアプリケーションを正しく認識できる。
【0140】
テーブルへのアプリケーションごとのアクセス制御を行うため、プロキシコンテナ１２１は、クエリの送信元のアプリケーションの把握に加え、アクセスのために接続する接続先テーブル名の取得を行う。
【0141】
なお、メッセージ内のクエリから正確な情報を取り出すためには、パーサを用いてクエリを解析することとなる。しかし、クエリにはＤＢごとに様々な方言があり、これらすべてのＤＢに応じたパーサをプロキシコンテナ１２１に実装するのは困難であり、拡張性を妨げる可能性もある。
【0142】
そこでプロキシコンテナ１２１は、クエリに対するＥｘｐｌａｉｎコマンドという比較的解析が簡単な情報を用いてアクセス先のテーブルを取得する。クエリに対するＥｘｐｌａｉｎ構文は基本的に後付けが容易なため、クエリを解析せずにすむ。また、Ｅｘｐｌａｉｎ結果はｙａｍｌやＪＳＯＮ（JavaScript（登録商標） Object Notation）などの半構造データで返すことが可能なＲＤＢＭＳが多く、Ｅｘｐｌａｉｎコマンドを用いれば容易に接続先テーブル名を抽出できる。
【0143】
図１８は、接続先テーブル名の取得方法の一例を示す図である。アプリケーション２１２ａからクエリ６１がプロキシコンテナ１２１に送信されると、プロキシコンテナ１２１内の接続先テーブル取得部１２１ｄは、クエリ６１の内容を含むＥｘｐｌａｉｎコマンド６２を生成する。Ｅｘｐｌａｉｎコマンド６２は、命令文「Ｅｘｐｌａｉｎ」に続けて、クエリ６１の内容を記載したものである。接続先テーブル取得部１２１ｄは、生成したＥｘｐｌａｉｎコマンド６２をＤＢコンテナ１２２に送信する。
【0144】
ＤＢコンテナ１２２は、Ｅｘｐｌａｉｎコマンド６２を受信すると、Ｅｘｐｌａｉｎコマンド６２内に示されるクエリ６１の実行計画を生成する。そしてＤＢコンテナ１２２は、実行計画をＥｘｐｌａｉｎ結果６３としてプロキシコンテナ１２１に送信する。
【0145】
図１８に示されているのはＰｏｓｔｇｒｅＳＱＬでのＥｘｐｌａｉｎ結果６３である。このＥｘｐｌａｉｎ結果６３には、接続先テーブルの名称「”Ｒｅｌａｔｉｏｎ Ｎａｍｅ”：”ｔ”，」が含まれている。プロキシコンテナ１２１は、Ｅｘｐｌａｉｎ結果６３から、接続先テーブルの名称の記述を、接続先テーブル名として抽出する。
【0146】
このようにプロキシコンテナ１２１は、Ｅｘｐｌａｉｎのコマンド文字列に、クエリ６１の内容を追加するだけでＥｘｐｌａｉｎコマンド６２を生成できる。すなわちクエリそのものを解析する場合は文字列を解釈しなければならないが、Ｅｘｐｌａｉｎコマンド６２でＪＳＯＮ形式の実行計画をＥｘｐｌａｉｎ結果６３として取得できる。ＪＳＯＮ形式の実行計画は、既存のＪＳＯＮライブラリにより解析できる。そこでプロキシコンテナ１２１は、ＪＳＯＮライブラリを用いて、Ｅｘｐｌａｉｎ結果６３における「Ｐｌａｎ」内の「Ｒｅｌａｔｉｏｎ Ｎａｍｅ」の値を読み込む。読み込んだ値が、接続先テーブルの名称である。このようにＥｘｐｌａｉｎコマンド６２を用いることで、接続先テーブルを容易に判断できる。
【0147】
Ｅｘｐｌａｉｎコマンド６２による実行計画の出力機能は多くのＤＢに実装されており、ＮｏＳＱＬであるＭｏｎｇｏＤＢや、グラフＤＢのＮｅｏ４ｊなども例外ではない。すなわち、Ｅｘｐｌａｉｎコマンド６２を用いた接続先テーブルの判定はＲＤＢＭＳに限らず、その他の様々なＤＢでも同様に可能である。
【0148】
接続先テーブルに対してアクセスを許可するアプリケーションの種別を示す許可情報は、Ｐｏｄ作成者３０によってカスタムリソース３２０に予め定義される。プロキシコンテナ１２１は、カスタムリソース３２０から許可情報を取得することで、接続先テーブルへのアクセスが許可されているアプリケーションを認識できる。
【0149】
図１９は、カスタムリソースから取得する許可情報の一例を示す図である。例えばプロキシコンテナ１２１は、カスタムリソース３２０から、すべてのデータテーブルについての許可情報７１，７２，・・・を取得する。許可情報７１，７２，・・・は、アクセス制限をかけるＲＤＢ１つに対して１つ作成される。許可情報７１，７２，・・・には、ＲＤＢのサービス名、ＲＤＢのポート番号、許可するアプリケーションのファイルパス、許可するテーブル名などが含まれる。
【0150】
プロキシコンテナ１２１は、クエリ６１の送信元のアプリケーションのファイルパスと接続先テーブルの名前との組を、許可情報７１，７２，・・・と照合することで、アクセスの許否を判断する。
【0151】
なお、監視用コンテナ２２１との通信や、テーブル取得のためのＥｘｐｌａｉｎコマンド６２の実行は、ＤＢ１１０へのアクセス処理において無視できないオーバーヘッドとなる可能性がある。そこでプロキシコンテナ１２１は通信の投機的実行を行う。
【0152】
図２０は、投機的なＤＢアクセス処理の一例を示すシーケンス図である。プロキシコンテナ１２１は、ＤＢ１１０へのクエリを受信すると、アプリケーションのファイルパスの取得処理、接続先テーブル名の取得処理、許可情報の取得処理、およびＤＢ１１０に対するクエリの実行処理を並列に行う。
【0153】
アプリケーションのファイルパスの取得処理は、２つのステップＳ１１～Ｓ１２に分かれている。まずプロキシコンテナ１２１は、監視用コンテナ２２１にクエリの送信元のＩＰアドレスとポート番号との組に対応するアプリケーションを問い合わせる（ステップＳ１１）。監視用コンテナ２２１は、アプリケーションのフィルパスをプロキシコンテナ１２１に送信する（ステップＳ１２）。以上が、アプリケーションのファイルパスの取得処理である。
【0154】
接続先テーブル名の取得処理は、２つのステップＳ２１～Ｓ２２に分かれている。まずプロキシコンテナ１２１は、ＤＢコンテナ１２２に、クエリの内容を含むＥｘｐｌａｉｎコマンドを送信する（ステップＳ２１）。ＤＢコンテナ１２２は、Ｅｘｐｌａｉｎコマンドに応じて、クエリの実行計画（接続先テーブル名を含む）を示すＥｘｐｌａｉｎ結果をプロキシコンテナ１２１に送信する（ステップＳ２２）。以上が、接続先テーブル名の取得処理である。
【0155】
許可情報の取得処理は、２つのステップＳ３１～Ｓ３２に分かれている。まずプロキシコンテナ１２１は、カスタムリソース３２０に許可情報を要求する（ステップＳ３１）。カスタムリソース３２０は、ＤＢ１１０内のすべてのデータテーブルに関する許可情報群をプロキシコンテナ１２１に送信する（ステップＳ３２）。以上が、許可情報の取得処理である。
【0156】
クエリの実行処理は、２つのステップＳ４１～Ｓ４２に分かれている。まずプロキシコンテナ１２１は、ＤＢコンテナ１２２に対してクエリを送信することで、クエリの実行を要求する（ステップＳ４１）。ＤＢコンテナ１２２は、クエリのアクセス先のデータテーブルへの接続を行い、該当データテーブルに対してクエリに応じた処理を実行し、実行結果をプロキシコンテナ１２１に送信する（ステップＳ４２）。クエリがデータの参照を要求していれば、実行結果にはクエリに応じたデータが含まれる。クエリがＤＢ１１０内でのデータの操作（更新、削除など）を要求していれば、操作処理の成否を示す情報が実行結果に含まれる。以上が、クエリの実行処理である。
【0157】
プロキシコンテナ１２１は、アプリケーションのファイルパスの取得処理、接続先テーブル名の取得処理、および許可情報の取得処理が完了すると、アクセスの許否を判断する。プロキシコンテナ１２１は、アクセスの許否の判断の前にクエリの実行結果を受信した場合、アクセスの許否が判断できるようになるまでアプリケーションへの応答を待機する。そしてプロキシコンテナ１２１は、クエリに基づく接続先テーブルへのアクセスが許可されたアクセスであると判断できた場合、クエリの実行結果を、クエリの送信元のアプリケーションに送信する（ステップＳ５１）。またプロキシコンテナ１２１は、クエリに基づく接続先テーブルへのアクセスが許可されていないアクセスであると判断した場合、権限エラーを示すメッセージを、クエリの送信元のアプリケーションに送信する（ステップＳ５２）。
【0158】
図２０に示した例は、クエリが短時間で実行できた場合を想定したものである。クエリの実行に長時間を要する場合、クエリの実行が終了するよりも先にアクセスの許否の判断結果が得られる場合がある。この場合において、アクセスが不許可であれば、クエリの実行を中止することで、無駄な処理の発生を最小限に抑えることができる。
【0159】
図２１は、クエリの実行に時間がかかる場合の投機的なＤＢアクセス処理の一例を示すシーケンス図である。アプリケーションのファイルパスの取得処理、接続先テーブル名の取得処理、許可情報の取得処理、およびＤＢ１１０に対するクエリの実行処理を並列に行う点は、図２０と同様である。またアプリケーションのファイルパスの取得処理、接続先テーブル名の取得処理、および許可情報の取得処理の内容も図２０と同様である。クエリの実行処理については、クエリの実行の要求（ステップＳ４１）までは、図２０と同様である。
【0160】
プロキシコンテナ１２１は、クエリの実行が終了するよりも先に許可されたアクセスであると判断した場合、ＤＢコンテナ１２２からの実行結果の受信を待つ。その後、ＤＢコンテナ１２２は、クエリの実行が終了すると実行結果をプロキシコンテナ１２１に送信する（ステップＳ４３）。そしてプロキシコンテナ１２１は、クエリの実行結果を、クエリの送信元のアプリケーションに送信する（ステップＳ５３）。
【0161】
他方、プロキシコンテナ１２１は、クエリの実行が終了するよりも先に不許可のアクセスであると判断した場合、クエリの実行終了を待たずに、ＤＢコンテナ１２２に対してクエリの実行のキャンセルを示すメッセージを送信する（ステップＳ４４）。そしてプロキシコンテナ１２１は、権限エラーを示すメッセージを、クエリの送信元のアプリケーションに送信する（ステップＳ５４）。
【0162】
このような処理を行うことにより、本来の通信処理に加わるオーバーヘッドを最小限にしつつ、アプリケーションごとのアクセス制御を実現することが可能となる。
以上のように、第２の実施の形態のシステムでは、コンテナ内のアプリケーションに紐づいたテーブル単位のアクセス制御に関して、コンポーネントを最適化したうえでそのオーバーヘッドを削減し、より良いパフォーマンスを引き出すことができる。例えば、１６００程度のプロセスが動作するノードでは、全走査には０．２～０．２５秒ほどの時間がかかる。しかし、この検索をユーザアプリＰｏｄ内の数プロセスのみに限定することができれば、例えば１０プロセスほどが動いているユーザアプリＰｏｄであれば０．００１５秒程度に収まる。このように、オーバーヘッドを大きく減らすことができる。
以上のように、第２の実施の形態のシステムでは、コンテナ内のアプリケーションに紐づいたテーブル単位のアクセス制御に関して、コンポーネントを最適化したうえでそのオーバーヘッドを削減し、より良いパフォーマンスを引き出すことができる。例えば、１６００程度のプロセスが動作するノードでは、全走査には０．２～０．２５秒ほどの時間がかかる。しかし、この検索をユーザアプリＰｏｄ内の数プロセスのみに限定することができれば、例えば１０プロセスほどが動いているユーザアプリＰｏｄであれば０．００１５秒程度に収まる。このように、オーバーヘッドを大きく減らすことができる。
【0163】
〔その他の実施の形態〕
第２の実施の形態では、クエリを受信するごとに、許可情報の取得処理を行っているが、許可情報を一度取得したら、許可情報をキャッシュとして保持しておいてもよい。これにより、以降の同じアプリケーションからの同じテーブルへのクエリの受信時には、カスタムリソース３２０からの許可情報の取得処理を省略することができる。
第２の実施の形態では、クエリを受信するごとに、許可情報の取得処理を行っているが、許可情報を一度取得したら、許可情報をキャッシュとして保持しておいてもよい。これにより、以降の同じアプリケーションからの同じテーブルへのクエリの受信時には、カスタムリソース３２０からの許可情報の取得処理を省略することができる。
【0164】
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
【符号の説明】
【0165】
１，２ 情報処理装置
１ａ 記憶部
２ａ データベース
１ｂ，２ｂ 処理部
３ａ，３ｂ データテーブル
４ 許可情報
５，６ Ｐｏｄ
５ａ，６ａ，６ｂ，・・・ コンテナ
７ 管理情報
８ａ，８ｂ ソフトウェア
９ａ，９ｂ アクセス要求
１ａ 記憶部
２ａ データベース
１ｂ，２ｂ 処理部
３ａ，３ｂ データテーブル
４ 許可情報
５，６ Ｐｏｄ
５ａ，６ａ，６ｂ，・・・ コンテナ
７ 管理情報
８ａ，８ｂ ソフトウェア
９ａ，９ｂ アクセス要求
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】