JP7391802B2 - 情報処理装置、情報処理方法及びコンピュータプログラム - Google Patents

Description

本発明の実施形態は、情報処理装置、情報処理方法及びコンピュータプログラムに関する。

近年、制御システムを狙ったサイバー攻撃が一般化しており、セキュリティ対策が急務である。制御システムでは機器が外部ネットワークに接続されない場合も多く、可用性の観点から極力、ソフトウェアアップデートを避ける傾向がある。そこでセキュリティ対策にも、パターンファイルの更新が必要のないホワイトリスト型の実行制御技術が広く利用されている。また、計算機内に信頼できるプログラムと、信頼できないプログラムが混在する場合に、信頼できないプログラムを隔離して実行するためのサンドボックス技術が広く利用されている。

サンドボックス技術を用いた例として、プログラムの起動時にあらかじめ設定されたアクセス制御ポリシを参照して、サンドボックス内でプログラムを動作させるか、サンドボックス外でプログラムを動作させるかを決定する技術が知られている。

この技術によれば、信頼できないプログラムをサンドボックス内で実行することができる。しかし、アクセス制御ポリシを参照した処理を行うか否かは、実行対象のプログラムがサンドボックス内で動作しているか、サンドボックス外で動作しているかによって決定されてしまい、柔軟なアクセス制御を行うことができない。

特許第５４２３０６３号公報

本発明の実施形態は、対象データへのアクセス制御を柔軟に変更可能な情報処理装置、情報処理方法及びコンピュータプログラムを提供する。

本実施形態に係る情報処理装置は、対象データへのアクセス要求を検知するアクセス検知部と、前記対象データの位置情報と、照合対象となるデータ範囲とに基づいて、前記対象データへのアクセスが許可されるか否かの情報との照合の要否を判定する判定部と、を備える。

第１の実施形態に係るホストシステムの一例を示す図。 第１の実施形態に係るホストシステムの一例を示す図。 第１の実施形態に係るアクセス制御装置の一例を示す図。 第１の実施形態に係る環境起動プロセステーブルの一例を示す図。 第１の実施形態に係るプロセステーブルの一例を示す図。 第１の実施形態に係る照合対象ディレクトリ表の一例を示す図。 第１の実施形態に係る環境起動時の処理手順の一例を示すフローチャート。 第１の実施形態に係るアクセス制御の処理手順の一例を示すフローチャート 第１の実施形態に係るアクセス制御装置の変形例を示す図。 第１の実施形態の変形例に係るプロセステーブルの一例を示す図。 第１の実施形態の変形例に係るアクセス制御の処理手順の一例を示すフローチャート。 第１の実施形態の変形例に係るプロセス起動時の処理手順の一例を示すフローチャート。 第１の実施形態の変形例に係る環境起動時の処理手順の一例を示すフローチャート。 第２の実施形態に係るアクセス制御装置の一例を示す図。 第２の実施形態に係るプロセステーブルの一例を示す図。 第２の実施形態に係る環境起動プロセステーブルの一例 第２の実施形態に係るプロセステーブルの他の例を示す図。 第２の実施形態に係る環境起動時の処理手順の一例を示すフローチャート。 第２の実施形態のプロセス終了時の処理手順の一例を示すフローチャート。

以下に図面を参照しつつ、本発明の実施形態について説明する。以下の説明では、同一または類似の要素には同一の符号が付され、同じ説明は基本的に省略される。例えば、複数の図において、対応する要素には同じ符号を付して、詳細な説明を省略する場合もある。

（第１の実施形態）
図１は本実施形態に係るホストシステム１の内部構成の一例を示す図である。ホストシステム１内には複数の環境（環境１及び環境２）と、ＣＰＵ（Central Processing Unit）によってＯＳ（Operating System）上で実行されるプログラムＤ（プロセスＤ）と、アクセス制御装置１１と、記憶装置１２（記憶部）とが設けられている。プログラムの実行単位のことをプロセスと呼び、以下ではプログラムＤのことをプロセスＤとも呼ぶ。

アクセス制御装置１１は本実施形態に係る情報処理装置であり、ホストシステム１上で直接動作している。アクセス制御装置１１は一例としてＣＰＵ等のプロセッサにプログラムを実行させることで実現できる。

記憶装置１２には、本実施形態に係るデータの一例であるファイル、アクセス制御装置１１が照合に用いるリスト、ＯＳが生成する情報又はデータ、アクセス制御装置１１が生成する情報、データ、テーブル等が格納されている。記憶装置１２は、揮発性又は不揮発性のメモリ、ハードディスク、ＳＳＤ、光デバイス、磁気記憶装置など任意の記録媒体を含む。

照合に用いるリストにはアクセスが許可された又は許可されていないデータ（ファイル等）に関する情報が含まれている。照合に用いるリストの情報の例として、ファイルの識別子、ファイルパスなどがある。リストに含める情報の詳細は後述する。アクセスが許可されたファイルに関する情報を含むリストはホワイトリストと呼ばれる。アクセスが許可されていないファイルに関する情報を含むリストはブラックリストと呼ばれる。リストは環境ごとに設けられてもよいし、複数の環境に共通に設けられてもよいし、その他の基準で設けられてもよい。

環境１及び環境２は、一例としてＯＳ上で構築された仮想的な環境である。環境１又は環境２はサンドボックスでもよい。環境１及び環境２は同じＯＳ上で構築される場合、異なるＯＳ上で構築される場合のいずれもあり得る。環境１内ではプログラムＡが実行されており、以下では、環境１内で実行されるプログラムＡのことをプロセスＡとも呼ぶ。環境２内ではプログラムＢ、Ｃが実行されており、以下では環境２内で実行されるプログラムＢ、ＣのことをプロセスＢ、Ｃとも呼ぶ。プロセスＢとプロセスＣ間には親子関係があってもよい。環境１内で動作するプログラムＡ（プロセスＡ）は、環境１が起動された際の設定（ルートディレクトリ等）によって定められるデータ範囲に属するデータ（ファイル等）にアクセス可能である。環境２内のプログラムＢ（プロセスＢ）、プログラムＣ（プロセスＣ）についてもプログラムＡと同様、環境２が起動された際の設定によって定められるデータ範囲に属するデータ（ファイル等）にアクセス可能である。つまり、記憶装置１２に格納されているファイルのうち、当該データ範囲に属するファイルにアクセス可能である。但し、アクセス制御装置１１によって照合の対象になったファイルについては照合で許可された場合にのみアクセス可能になるなど、アクセスが許可されない場合もあり得る。

プログラムＤはホストシステム１上で直接動作しており、基本的に記憶装置１２内のすべてのファイルにアクセス可能である。但し、環境１及び環境２の場合と同様に、アクセス制御装置１１によって照合の対象になったファイルについては、照合で許可された場合にのみアクセス可能になるなど、アクセスが許可されない場合もあり得る。

アクセス制御装置１１はプロセス（プロセスＡ、Ｂ、Ｃ、Ｄ等）からファイルへのアクセスの要求があった際に、アクセス対象となるファイルに関する情報に基づき、リストとの照合を行う。ファイルへのアクセスとは、ファイルの読み出し（ファイルデータ本体の読み出し、ファイルのプロパティ値の読み出しなど）、ファイルの実行など、各種の態様を含む。以下の説明で、ファイルのアクセスといった場合、ファイルの実行を含む。

図１のプログラムＡ～Ｄによって実現される機能は装置として実装されることもできる。
図２は、本実施形態に係るホストシステム１の内部構成の他の例を示す図である。図１のプログラムＡ～Ｄが、装置Ａ～Ｄに置き代わっている。また、アクセス制御装置１１が環境３内に設けられている。装置Ａは環境１内で実行され、装置Ｂ、Ｃは環境２内で実行され、装置Ｄはホストシステム１上で直接動作する。アクセス制御装置１１は環境３内で動作する。装置Ａ～Ｄ、アクセス制御装置１１は、有線又は無線の通信ネットワークを介して接続されてもよいし、通信バスを介して接続されてもよい。

図３は、本実施形態に係るアクセス制御装置１１の一例を示すブロック図である。アクセス制御装置１１は、環境起動検知部２１、プロセス関係判定部２２、アクセス検知部２３、照合要否判定部２４（判定部）、パス変換部２５、リスト照合部２６、及びアクセス制御部２７を備えている。

環境起動検知部２１はホストシステム１とは分離された環境の起動及び生成を検知する機能を持つ。ホストシステム１と分離される環境（以降、単に環境と呼ぶ）とは、Linuxの場合、chrootと呼ばれる特定のディレクトリパスをプロセスのルートディレクトリとする方式により実現される環境でもよい。あるいは、namespaceにより名前空間を分離する方式により実現される環境でもよい。いずれの場合においても、特定のシステムコール、例えばchrootシステムコールを捕捉することで、環境起動検知部２１は、環境の起動を検知する。

環境起動機能には、環境内のルートディレクトリを変更する機能が設けられている。例えば元のルートディレクトリ以下の階層の特定のディレクトリを新たなルートディレクトリとする機能がある。例えば元のルートディレクトリが“/”の場合に、“/home/”を新たなルートディレクトリとする機能がある。新たな環境で起動させられて、動作するプロセスは新たなルートディレクトリより上位に存在するファイル又はディレクトリにはアクセスすることができない。よって、ルートディレクトリの変更によって、アクセスできるファイルを限定することができる。例えば/home/を新たなルートディレクトリとする場合には、新たな環境で動作するプロセスからは/home/fooにはアクセスできるが、/barにはアクセスさせない、といったことが可能となる。このようにルートディレクトリによって環境が参照可能なデータ範囲が定められる。

環境起動検知部２１は、環境の起動を検知すると、環境起動プロセステーブル（環境データ）にルートディレクトリのパスと、環境を起動したプロセス（第４プロセス）の識別子（プロセスID）を記録する。

図４は、環境起動プロセステーブルの一例を示す。図４の例では、プロセスIDが１２００であるプロセス（第４プロセス）が、/home/data1/をルートディレクトリパスとする環境を新たに起動した場合が示されている。

プロセス関係判定部２２は、照合要否判定部２４からの要求に応じて、照合要否判定部２４から与えられたプロセスIDを持つプロセスの環境を起動したプロセス（環境起動プロセス）のIDを取得する機能を有する。また、プロセス関係判定部２２は、当該環境起動プロセスのルートディレクトリを取得する機能を持つ。例えばプロセスIDがA（プロセスID=Aと記載する。以下同様）であるプロセス（プロセスA）が環境を起動し、プロセスAがプロセスID=Bである子プロセス（プロセスB）を起動する。さらにプロセスBが、プロセスID=Cである子プロセス（プロセスC）を起動する。この場合、プロセスCの環境を起動したプロセスはプロセスAであり、プロセスCの環境を起動したプロセス（環境起動プロセス）のプロセスIDはAである。

環境起動プロセスのプロセスID及びルートディレクトリを取得する方法として、OS(オペレーティングシステム)が生成するプロセステーブルを用いることができる。プロセステーブルを用いた例を示す。

図５はプロセステーブルの一例を示す。プロセステーブルには、プロセスのプロセスID（自プロセスID）と、当該プロセスを起動したプロセス（親プロセス）のプロセスID（親プロセスID）との組が、１つのエントリとして記録される。例えば、親プロセスID=1234のプロセスの祖先をたどる場合には、まずプロセスID＝1234のエントリを参照し、親プロセスのIDが1230であることがわかる。さらに、プロセステーブルをたどり、プロセスID=1230のエントリを参照すると、親プロセスのIDが1220であることがわかる。さらにプロセステーブルをたどり、プロセスID＝1220のエントリを参照すると、親プロセスが存在しないことを示す情報が記録されている。さらに、このように親プロセスをたどるたびに、図４の環境起動プロセステーブルを参照し、親プロセスのプロセスIDが環境起動プロセステーブルに記録されているかを確認する。

図４および図５の例では、プロセスID＝1234とプロセスID=1230は環境起動プロセステーブルに登録されていない。しかしながら、プロセスID=1220が環境起動プロセステーブルに登録されていることから、環境を起動したプロセス（環境起動プロセス）はプロセスID=1220のプロセスであることがわかる。さらに、環境起動プロセスのルートディレクトリのディレクトリパスは、/home/data1/であることがわかる。

アクセス検知部２３は、プロセスによるデータ（ファイル）へアクセスの要求を検知する機能を有する。アクセス検知部２３は、特定のシステムコールを捕捉することで、ファイルアクセスを検知する。ファイルアクセスの要求を検知した時点ではファイルへのアクセスはまだ行われていない。アクセス検知部２３は、ファイルアクセスの要求を検知すると、照合要否判定部２４に、ファイルアクセスの要求を行ったプロセスのIDと、アクセス要求先のファイルのパス（位置情報）とを照合要否判定部２４に通知する。このパスは、ファイルアクセスの要求を行ったプロセスが属する環境内の視点でファイルの位置を表したパスではなく、ホストシステム１からの視点でファイルの位置を表したパスである。

照合要否判定部２４（判定部）は、アクセス検知部２３によりプロセスからファイルアクセスの要求が検知された場合に、アクセス要求されたファイル（対象データ）が、アクセスが許可された又は許可されていないファイルに該当するかの照合の要否を判定する。照合の要否の判定には、種々の情報を用いることができる。例えば、プロセスが要求したアクセス要求先のファイルの位置情報（例えばファイルパス等）、アクセス要求を行ったプロセスが動作している環境から参照可能なファイルの範囲（第１データ範囲）、セキュリティ機能を有するプロセス（セキュリティプロセスと呼ぶ場合もある）から参照可能なファイルの範囲（第２データ範囲）、各プロセスが動作している環境の情報、などがある。以下、照合の要否の判定の具体例（１）～（５）を示す。

（１）例えば、セキュリティプロセス（第３プロセス）と、ファイルアクセスを要求したプロセス（第２プロセス）とが同一の環境で動作しているか否かによって（両プロセスの先祖が同じか否かに応じて）、照合の要否を判定する。一例として、照合要否判定部２４は、両プロセスが同一の環境で動作している場合は、照合を行うと決定する。一方、両プロセスが同一の環境で動作していない場合は、照合を行わないと決定する。具体的には、照合要否判定部２４は、プロセス関係判定部２２から、セキュリティプロセスの環境を起動したプロセスのプロセスIDと、アクセスを要求したプロセスの環境を起動したプロセスのプロセスIDとを取得する。取得した両プロセスIDが同じであれば、両プロセスが同一環境で動作していると判断する。両プロセスが同一の環境で動作している場合、セキュリティプロセスから参照可能なデータ範囲（照合対象となるデータ範囲あるいは第２データ範囲）にファイルの位置情報が含まれているといえる。

（２）セキュリティプロセス（第３プロセス）が、プロセス（第２プロセス）によりアクセス要求された先のファイルにアクセスできるか否かによって、照合の要否を判定する。例えば、セキュリティプロセスが参照可能なデータ範囲（照合対象となるデータ範囲あるいは第２データ範囲）にファイルの位置情報が含まれるかに応じて、照合の要否を判定する。セキュリティプロセスがファイルにアクセスできる場合は、照合を行うと決定し、アクセスできない場合は照合を行わないと決定する。具体的には、照合要否判定部２４は、セキュリティプロセスが動作する環境を起動したプロセスのルートディレクトリパス（すなわちセキュリティプロセスが動作する環境のルートディレクトリパス）をプロセス関係判定部２２から取得する。照合要否判定部２４は、取得したディレクトリパスと、プロセスによりアクセス要求された先のファイルのパスとの間で前方一致の検査を行う。例えば環境起動プロセスのディレクトリパスが/home/であり、アクセス要求先のファイルのパスが/home/foo/barであれば、前方一致の検査結果が真となる。この場合、セキュリティプロセスは当該ファイルにアクセスできる。一方、アクセス要求先のファイルのパスが/hoge/の場合には、前方一致の検査結果が偽となる。この場合、セキュリティプロセスは、当該ファイルにアクセスができない。

（３）セキュリティプロセス（第３プロセス）が動作する環境のルートディレクトリパスと、アクセス要求を行ったプロセス（第２プロセス）が動作する環境のルートディレクトリパスとを比較することによって照合の要否を判定する。換言すれば、当該プロセスとセキュリティプロセスとが子孫関係に該当するかによって照合の要否を判定する。例えば、セキュリティプロセスが動作する環境のルートディレクトリパスが/home/であり、アクセス要求を行ったプロセスが動作する環境のディレクトリパスが/home/foo/であるとする。この場合、両ルートディレクトリパス間の前方一致の検査を行い、前方一致の検査結果が真となる（この場合、プロセスがセキュリティプロセスの子孫に該当する）。つまりファイルの位置情報はセキュリティプロセスが参照可能なデータ範囲（照合対象となるデータ範囲あるいは第２データ範囲）に含まれる。このため、セキュリティプロセスは、当該プロセスのアクセス要求先のファイルにアクセスできる。よって、この場合、照合要否判定部２４は、照合を行うと決定する。一方、前方一致の検査結果が偽となる場合、照合を行わないと決定する。

（４）あらかじめ照合対象のディレクトリパスのリストをリスト化しておく。照合要否判定部２４は、アクセス要求先のファイルと、リストに登録されたディレクトリパスとの関係（ファイルの位置情報と照合対象となるデータ範囲との関係）に基づいて照合の要否を判定する。すなわちアクセス要求先のファイルが、リストに登録されたディレクトリパスが示すディレクトリ以下の階層に存在するか否かを判定する。ファイルが当該ディレクトリ以下の階層に存在する場合は、照合を行うと判定し、存在しない場合は、照合を行わないと判定する。
（５）アクセス要求を行ったプロセス（第２プロセス）が、当該プロセスの環境を起動したプロセス（第１プロセス）と子孫関係にある場合に、照合を行うことを決定してもよい。子孫関係にある場合、アクセス要求先のファイルの位置情報は、当該プロセスの環境から参照可能なデータ範囲（照合対象となるデータ範囲あるいは第１データ範囲）に含まれる。

図６は、照合対象のディレクトリパスをリスト化した照合対象ディレクトリ表の例を示す。アクセス要求先のファイルが、/home/data1/以下の階層に存在する場合には、照合を行うと決定し、存在しない場合は、照合を行わないと決定する。

（１）～（５）の判定方法を複数組み合わせて、照合の要否を判定してもよい。

パス変換部２５は、照合の対象となるファイルのパスを、セキュリティプロセスから参照可能なパスに変換する。例えばセキュリティプロセスの動作する環境のルートディレクトリが/home/であり、アクセス要求先のファイルのパスが/home/foo/barであるとする。この場合、/home/foo/bar を/foo/barと変換する。具体的には、まずセキュリティプロセスが動作する環境のルートディレクトリを取得する。次に、取得したルートディレクトリのパスと、アクセス要求先のファイルパスとの前方の一致する部分の文字列を、アクセス要求先のファイルパスから削除する。例えば/home/foo/barから前方の/home/と削るとfoo/barとなる。先頭に“/”を補完して/foo/barとする。

リスト照合部２６は、照合要否判定部２４により照合を行うことが決定された場合に、アクセス要求先のファイル（対象データ）に関する情報を、アクセスが許可された又は許可されていないファイルに関する情報を格納したリストと照合する。アクセス要求先のファイルに関する情報は、セキュリティプロセスから取得することができる。セキュリティプロセスは、例えば、上記の変換されたパスに基づきファイルからファイルに関する情報を取得し、取得した情報をリスト照合部２６に提供する。

照合に用いるリストはホワイトリスト、もしくはブラックリストである。ホワイトリストリストには、アクセスが許可された１つ以上のファイルに関する情報が登録されている。ブラックリストには、アクセスが禁止された１つ以上のファイルに関する情報が登録されている。

リスト照合部２６は、アクセス要求先のファイルに関する情報をリスト（ホワイトリスト又はブラックリスト）と照合する。アクセス要求先のファイルに関する情報が、リストに登録されているいずれかのファイルの情報に一致するかを判断する。照合する情報の例としては、アクセス要求先のファイルの位置情報（ファイルシステム上のパス）、ファイルの識別子、inode等のメタデータ情報、ファイルのハッシュ値、シグネチャ情報、ファイルへアクセス要求したプロセス（プログラム）が発行するシステムコール列等の動作の振る舞い等が考えうる。これら１つの情報を照合してもよいし、複数の情報を照合してもよい。

照合に用いるリストは、ファイルにアクセス要求しているプロセスの環境に応じて変えてもよい。これにより、同一ファイルへのアクセスであっても、ファイルアクセスを行う環境によって、アクセス制御ポリシ（照合に用いるリスト）を変更することができる。

アクセス制御部２７は照合結果に応じて、アクセス制御を行う機能を有する。ホワイトリスト方式では、一例として、アクセス要求先のファイルに関する情報と同じ情報がリストに登録されていた場合（照合結果が一致した場合に）、ファイル実行等のファイルアクセスを許可する。照合結果が一致しない場合にはアクセスを拒否する。あるいは、照合結果が一致しない場合に、ログ出力等によりアラートを出力した上で、アクセスは許可する方法も可能である。

逆にブラックリスト方式の場合には、アクセス制御部２７は、照合結果が一致した場合にはファイル実行等のファイルアクセスを拒否し、一致しない場合にはアクセスを許可する。この場合にもアクセスを拒否するのではなく、アラートを出力した上で、アクセスを許可する方法も可能である。

アクセス制御部２７がセキュリティプロセスの一部として実装されてもよいし、セキュリティプロセスとは別のモジュール又は機能として実装されていてもよい。

図７及び図８はアクセス制御装置１１の動作の一例を示すフローチャートである。より詳細には、図７は環境起動時の処理フロー、図８はファイルアクセス時の処理フローを示す。

最初に図７を用いて環境起動時の処理フローを説明する。環境起動検知部２１は特定の命令あるいはシステムコールの発行等を捕捉することにより、環境の起動を検知する（Ｓ１１）。環境起動検知部２１は、環境を起動したプロセスのプロセスIDを取得し（Ｓ１２）、さらに環境を起動したプロセスのルートディレクトリのパスを取得する（Ｓ１３）。環境起動検知部２１は、プロセスIDとルートディレクトリのパスとを環境起動プロセステーブルに登録する（Ｓ１４）。

続いて、図８を用いてファイルアクセス時の処理フローを説明する。アクセス検知部２３がファイル実行等のファイルアクセスのアクセス命令を検知する（Ｓ２１）。アクセス検知部２３は、アクセス要求先のファイルのパスと、アクセス要求を行ったプロセス（アクセス命令を発行したプロセス）のプロセスIDとを取得する（Ｓ２２）。ファイルのパスは、ファイルアクセスを要求したプロセスが属する環境内から見たファイルの位置を表すパスではなく、ルートディレクトリの変更前のパス（ホストシステムから見たファイルの位置を表すパス）である。

照合要否判定部２４は、アクセス要求を行ったプロセス（自プロセス）のルートディレクトリのパスを得るために、プロセス関係判定部２２を用いて、以下の処理を行う。まず、Proc_idに自プロセスのプロセスIDを代入する（Ｓ２３）。

次に環境起動プロセステーブル（図４参照）にProc_idが登録されているかを確認する（Ｓ２４）。Proc_idが登録されている場合にはステップＳ２５に進み、Proc_idに対応するルートディレクトリパス（ルートディレクトリパスＡとする）を得る（Ｓ２５）。

Proc_idが登録されていない場合には、プロセステーブル（図５参照）から自プロセスIDがProc_idに一致するエントリを探し（Ｓ２６）、見つけたエントリにおける親プロセスIDを得る。親プロセスが存在する場合（図４の例では親プロセスIDが“なし”以外の場合）には、Proc_idに親プロセスのプロセスIDを代入し（Ｓ２７）、ステップＳ２４まで戻る。

親プロセスがない場合（図５の例では親プロセスIDが“なし”の場合）には、ルートディレクトリパス（ルートディレクトリパスＡとする）を“/”とする（Ｓ２８）。

さらにセキュリティ機能のプロセス（セキュリティプロセス）が動作する環境のルートディレクトリパスを得る。具体的には、ステップＳ２４～Ｓ２９までの流れと同様の方法で、セキュリティプロセスが動作する環境のルートディレクトリパス（ルートディレクトリパスＢとする）を取得する（Ｓ２９）。例えば、図４と図５の例ではプロセスID=1234を持つプロセスのルートディレクトリパスは“/home/data1/”となる。

続いてルートディレクトリパスＡ、ルートディレクトリパスＢ、アクセス要求を行ったプロセスのプロセスID、セキュリティプロセスの環境を起動したプロセスのプロセスID等に基づき、アクセス要求先のファイルに対して照合を行うか否かを判断する（Ｓ３０）。この方法としては、上記の項目（１）～（４）の説明で述べた方法を用いればよい。

アクセス要求先のファイルが照合の対象の場合には、アクセス要求先のファイルがセキュリティプロセスのルートディレクトリパスＢ以下の階層に存在するかどうかを判断する（ステップＳ３１）。これによりセキュリティプロセスがアクセス要求先のファイルにアクセス可能かどうかを判断できる。

アクセス要求先のファイルがセキュリティプロセスのルートディレクトリパスＢ以下の階層に存在する場合、パス変換部２５は、アクセス要求先のファイルのパスを、セキュリティプロセスが動作する環境のパスに変換する（Ｓ３２）。リスト照合部２６は、変換後のパスと同じパスがリストに登録されているかを照合する照合を行う（Ｓ３３）。ここではアクセス要求先のファイルに関する情報としてパス（ファイルの位置情報）がリストに登録されているかを判断しているが、照合の対象とする情報はパスに限定されない。アクセス制御部２７は、照合の結果に基づき、アクセス要求したプロセスによるファイルへのアクセス制御を実行する（Ｓ３４）。

照合の結果に基づくアクセス制御は前述した通りである。すなわち、アクセス制御は、ブラックリスト方式か、ホワイトリスト方式かによって変わる。また、ホワイトリストに登録されていない又はブラックリストに登録されているファイルの実行要求の場合は、ファイル実行を拒否する以外に、ログを出力し、ファイル実行自体は許可するという方法を採ってもよい。

ステップＳ３１においてセキュリティプロセスからアクセス要求先のファイルにアクセスできないと判断された場合、アクセス制御部２７は任意の方法でアクセス制御を行う（Ｓ３４）。例えば、あらかじめアクセス制御のデフォルトポリシを設定しておき（例えば常に実行許可、あるいは、常に実行拒否を設定できるようにしておく）、アクセス制御時にはそのデフォルトポリシに従って動作させるような機能を設けてもよい。なお、セキュリティプロセスからアクセス要求先のファイルにアクセスできないと判断された場合に、照合を行う構成も可能である。

第１の実施形態によれば、ファイルアクセスの要求を行ったプロセスが動作する環境（ルートディレクトリパス）、セキュリティプロセスが動作する環境（ルートディレクトリパス）等に基づいて、照合を行うかどうかを決定することができる。例えばファイルアクセスの要求を行ったプロセスが動作する環境がサンドボックスである場合、セキュリティプロセス（セキュリティ機能）がサンドボックスと同じ環境に属するか否かに応じて、照合を行うかどうかを決定することができる。つまり、ホワイトリスト型の実行制御等のセキュリティ対策のソフトウェア（セキュリティ機能）がサンドボックス外で動作しているか、サンドボックス内で動作しているかによって、照合を行うかどうかを決定することができる。また、アクセス要求先のファイルがセキュリティプロセスの環境内に存在するか又は環境外に存在するかによって、照合を行うかどうかを決定することができる。また、第１の実施形態によれば、ファイルにアクセスするためのパス変換（識別子の変換）を行うため、セキュリティプロセスからファイルにアクセスして、照合に用いるファイルに関する情報を取得できる。

（第１の実施形態の変形例）
第１の実施形態ではファイルのアクセス要求の発生時に毎回、アクセス要求を行ったプロセスの親プロセスをたどり、当該プロセスの環境を起動したプロセスのプロセスID及びルートディレクトリパスを得ていた。この処理はオーバーヘッドが高いため、本変形例ではこのオーバーヘッドを低減する。

図９は、第１の実施形態の変形例に係るアクセス制御装置１１のブロック図である。図９では、図３に対してプロセス起動検知部３１が追加で設けられ、プロセス関係判定部２２の代わりに、ルートディレクトリ取得部３２（データ範囲取得部）が設けられている。環境起動検知部２１の動作が第１の実施形態と異なる。

図１０は、本変形例に係るプロセステーブル（プロセス関連データ）を示す。プロセステーブルのエントリに環境起動プロセスIDフィールドを追加する。環境起動プロセスIDは、環境を起動したプロセスのIDである。プロセス生成時に、当該プロセスのエントリに環境起動プロセスIDを追加する。環境起動プロセスIDの代わりに、環境起動プロセスが起動した環境のルートディレクトリのパスを登録するようにしてもよい。

プロセス起動検知部３１は、プロセスの起動を検知した場合に、親プロセスの環境起動プロセスIDを取得し、プロセスのエントリに環境起動プロセスIDを設定する。例えばプロセスID=1234のプロセスが起動した場合には、当該プロセスの親プロセスのエントリ、すなわち、プロセスID=1230が“自プロセスID”であるエントリを参照する。参照した親プロセスのエントリから環境起動プロセスID=1220を取得して、当該プロセスのエントリに環境起動プロセスID=1220を設定する。

環境起動検知部２１は、環境起動の命令を捕捉した場合に、環境起動の命令を発行したプロセスのエントリに環境起動プロセスIDとして当該プロセスのIDを設定する。例えば図１０の例ではプロセスID=1220のプロセスが環境を起動した場合には、プロセスID=1220のエントリの環境起動プロセスIDフィールドに1220を設定する。

図１１は本変形例に係るアクセス制御時の処理フローである。図１１は図８と点線で囲った部分の処理手順が異なる。ここでは点線で囲った部分の処理手順について説明する。ルートディレクトリ取得部３２は、環境を起動したプロセス（環境起動プロセス）のプロセスIDを取得し（Ｓ４１）、プロセスIDがプロセステーブルに存在するかを判断する。存在する場合は、ステップＳ２５に進み、ルートディレクトリパス（ルートディレクトリパスＡ）を環境起動プロセステーブルから取得する（Ｓ２５）。プロセスIDが存在しない場合には、ルートディレクトリパス（ルートディレクトリパスＡ）を“/”とし、ステップＳ２９に進む。

図１２は、本変形例に係るプロセス起動時の処理フローである。プロセス起動検知部３１がプロセスの起動を検知すると（Ｓ５１）、プロセステーブルにおける親プロセスのエントリから環境起動プロセスIDを取得する（Ｓ５２）。さらに、起動されたプロセスのプロセスIDを持つエントリの環境起動プロセスIDフィールドに、環境起動プロセスIDを設定する（Ｓ５３）。

図１３は環境起動時の処理フローである。図１３は図７と点線で囲った部分の処理手順が異なる。ここでは点線で囲った部分の処理手順について説明する。点線で囲った部分では、プロセステーブルにおいて環境を起動したプロセスのエントリに環境起動プロセスIDとして、ステップＳ１２で取得したプロセスIDを設定する。

本変形例によれば、第１の実施形態に比べてアクセス制御時の処理を簡略化することができる。

（第２の実施形態）
本実施形態では、起動した環境から、さらに別の環境を起動する場合を扱う。これにより環境を多重に起動する場合にも対処可能になる。

図１４は第２の実施形態に係るアクセス制御装置１１の内部構成を示すブロック図である。図１４は、ホストパス取得部３４（データ範囲情報取得部）と、プロセス終了検知部３５を備える点、環境起動検知部２１の内部動作が、図３の構成と異なる。その他のブロックの動作は第１の実施形態と同じであるため説明を省略する。

環境起動検知部２１は、環境起動の命令の捕捉により新たな環境の起動を検知した際に、新たな環境を起動したプロセスのプロセスID及び環境起動の命令の引数等の情報を、ホストパス取得部３４に提供する。

ホストパス取得部３４は、新たな環境を起動したプロセスのルートディレクトリパス（新たな環境を起動する前のもともとの環境のルートディレクトリパス）をプロセス関係判定部２２から取得する。またホストパス取得部３４は、環境起動の命令の引数などから新たに起動された環境のルートディレクトリ情報（新たな環境を起動する前のもともとの環境から見た相対的なルートディレクトリパス）を取得する。ホストパス取得部３４は、これらの取得した情報に基づき、新たに起動させられたプロセスの環境のルートディレクトリパスを、ホストシステム１のルートディレクトリから見たパスの形式で生成する。

つまり、上記新たに起動された環境のルートディレクトリ情報は、第１環境から参照可能なデータ範囲（第１データ範囲とする）の情報であり、もともとの環境（第２環境）からの視点で当該第１データ範囲を定義している。ホストパス取得部３４は、当該第１データ範囲の情報と、第２環境（もともとの環境）から参照可能なデータ範囲（第３データ範囲とする）の情報とに基づき、第２環境が設けられているホストシステムからの視点で当該第１データ範囲を定義したデータ範囲情報を取得する。

以下、ホストパス取得部３４の動作を図１５及び図１６を用いて説明する。

図１５は、第２の実施形態に係るプロセステーブルの一例を示す。図１６は、第２の実施形態に係る環境起動プロセステーブルの一例を示す。

図１５の例において、プロセスID＝１００のプロセスがプロセスID=１２２０のプロセスを起動し、さらにプロセスID=１２２０のプロセスはプロセスID=１２３０、２２２０のプロセスを起動している。さらにプロセスID=２２２０のプロセスは、プロセスID＝２２３０のプロセスを起動している。

このときプロセスID=１００のプロセスは、環境起動前の状態（ホストシステム上）で動作しているものとする。また、プロセスID＝１２２０のプロセスが、ルートディレクトリとして、“/home/data1/”を指定して、新たな環境（第２環境）を起動としたとする。さらに、プロセスID＝２２３０のプロセスが、ルートディレクトリとして“/foo/”を指定して、新たな環境（第１環境）を起動したとする。つまり第２環境が先に起動し、第２環境内で第１環境が起動する。

この場合、図１６のように、最初にプロセスID＝１２２０のプロセスに対して、当該プロセスが起動した環境（第２環境）のルートディレクトリパスとして“/home/data1/”が記録される。すなわち、最初にプロセスID＝１２２０のプロセスがルートディレクトリパスとして/home/data1/を指定して、環境（第２環境）を起動したことが記録される。さらにプロセスID=２２３０のプロセスが新たな環境（第１環境）を起動した際には、プロセスID=２２３０のプロセスに対して、当該プロセスが起動した環境（第１環境）のルートディレクトリパスとして、/home/data1/foo/が記録される。つまり、プロセスID=２２３０のプロセスは、もともとプロセスID＝１２２０のプロセスが起動した環境（第２環境）内で動作していたため、もともとの環境（第２環境）のルートディレクトリは“/home/data1/”である。そして、プロセスID=２２３０が環境（第１環境）の起動時に指定したルートディレクトリ情報は“/foo/”であるから、ホストシステムから見た/foo/のパスは“/home/data1/foo/”となる。つまり、ホストシステムからみたルートディレクトリパスは、環境起動を行ったプロセスの元々のルートディレクトリパス（/home/data1/）と、環境起動の際に与えられたルートディレクトリ情報（/foo/）とを結合することで得ることができる。

プロセス終了検知部３５は、プロセスの終了を検知し、当該プロセスの環境で動作している他のプロセス（環境を起動したプロセスを含む）が残存しているかを確認する。他のプロセスが残存していない場合には、環境起動プロセステーブルから、環境起動したプロセスに対するルートディレクトリパスを削除する。

具体的には、プロセス終了検知部３５は、あるプロセスの終了を検知した場合には、当該プロセスが属する環境を起動したプロセスのプロセスIDを確認する。さらに、当該環境を起動したプロセスから起動された子プロセスが存在するかどうかを確認し、存在する場合には、さらにその子プロセスが存在するかどうかを確認していく。これを繰り返すことで、当該環境で動作するプロセスが残存しているかを確認する。残存していない場合には、環境起動プロセステーブルから、環境を起動したプロセスのプロセスIDを含むエントリを削除する。図１７を用いて具体例を示す。

図１７は、第２の実施形態のプロセステーブルの他の例を示す。図１７の例では、エントリに子プロセスIDの情報を含めている。これにより親プロセスから子プロセスに対して効率的にたどることができるようになる。例えば、プロセスID=１２３４のプロセスが終了した場合には、プロセスID=１２３４のプロセスが属する環境を起動したプロセスを特定する。環境を起動したプロセスはプロセスID=１２２０のプロセスであるため、プロセスID＝１２２０のプロセスの子供をたどっていき、残存するプロセスがあるかどうかを効率的に判断できる。残存するプロセスが存在しない場合は、プロセスID=１２２０のエントリを環境起動プロセステーブルから削除する。残存するプロセスが１つでも存在する場合は、プロセスID=１２２０のエントリを環境起動プロセステーブルから削除しない。

図１８及び図１９は本実施形態における処理フローの一例である。アクセス制御のフローについては、図８と同様であるため図示および説明を省略する。

図１８は環境起動時の処理フローである。環境起動検知部２１が特定のシステムコールを捕捉等することにより環境の起動を検知し（Ｓ６１）、環境の起動を命令したプロセス（自プロセス）のプロセスIDを取得する。自プロセスのルートディレクトリパスを得るためにホストパス取得部３４は以下の処理を行う。

まずProc_idに自プロセスのプロセスIDを代入する（Ｓ６３）。Proc_idのプロセスが環境起動プロセステーブルに登録されているか確認する（Ｓ６４）。Proc_idのプロセスが登録されていない場合には、プロセス関係判定部２２を用いて、Proc_idのプロセスに親プロセスが存在するか確認する（Ｓ６５）。親プロセスが存在する場合には、Proc_idに親プロセスのプロセスIDを代入し（Ｓ６６）、ステップＳ６４に戻る。ステップＳ６４にてProc_idのプロセスが環境起動プロセステーブルに登録されている場合には、Proc_idのプロセスに対応するルートディレクトリ（ルートディレクトリパスＡとする）を環境起動プロセステーブルから取得する（Ｓ６８）。この後、ステップＳ６９に進む。また、ステップＳ６５でProc_idのプロセスに親プロセスが存在しない場合には、Proc_idのプロセスはホストシステム１上で動いていると判断する。そして、ルートディレクトリパスを"/”（ルートディレクトリパスＡとする）とする（Ｓ６７）。この後、ステップＳ６９に進む。

ステップＳ６９では、ホストパス取得部３４は、環境起動の命令の引数等からルートディレクトリ情報（新たな環境を起動する前のもともとの環境から見た相対的なルートディレクトリパス。ルートディレクトリパスＢとする）を取得する（Ｓ７０）。ルートディレクトリパスＢは、ルートディレクトリパスＡから見た相対パスである。ルートディレクトリパスＡをもとに、ルートディレクトリパスＢをホストシステム１から見たルートディレクトリパス（ルートディレクトリパスＣ）に変換する。さらにルートディレクトリパスＣと、環境を起動したプロセスのプロセスIDとを対応付けてエントリとして環境起動テーブルに登録する（Ｓ７１）。

図１９は、プロセス終了時の処理フローである。プロセス終了検知部３５がプロセスの終了を検知すると（Ｓ８１）、Proc_idに、終了したプロセス（自プロセス）のプロセスIDを代入する（Ｓ８２）。さらにProc_idが環境起動プロセステーブルに登録されているか確認し（Ｓ８３）、登録されていない場合には、プロセス関係判定部２２を用いて、Proc_idのプロセスに親プロセスが存在するか確認する（Ｓ８４）。プロセス関係判定部２２は、プロセステーブルを参照して、Proc_idのプロセスに親プロセスが存在するか確認する。親プロセスが存在する場合には、プロセス終了検知部３５は、Proc_idに親プロセスのプロセスIDを代入して（Ｓ８５）、ステップＳ８３に戻る。親プロセスが存在しない場合には、ホストシステム１上で直接、Proc_idのプロセスが動作していると判断して、処理を終了する。ステップＳ８３において、Proc_idが環境起動プロセステーブルに登録されている場合には、Proc_idのプロセスから順にプロセスをたどっていく。すなわち、Proc_idのプロセスから起動された子プロセスや、さらにその子プロセスから起動されたプロセス（孫プロセス）、さらにその孫プロセスから起動されたプロセス（以降同様）、と順にたどっていく。これにより、Proc_idのプロセス（環境を起動したプロセス）のすべての子孫となるプロセスが終了しているかを確認する（Ｓ８６）。１つでも終了していないプロセスが存在する場合は、処理を終了する。一方で、すべてのプロセスが終了している場合には、環境起動プロセステーブルからProc_idのプロセスに関するエントリを削除する（Ｓ８７）。

本実施形態によれば、環境を多重に起動する場合にも柔軟なアクセス制御を行うことができる。また一度起動した環境を終了させる場合にも対処できる。すなわち、通常、多くの環境ではプロセスIDはプロセス終了後に再利用される。このため、終了したプロセスのプロセスIDに関する情報が環境起動プロセステーブルに残っていると、プロセスの環境とルートディレクトリとを正しく判別できない。これに対して、本実施形態によれば、プロセスの終了時に、当該プロセスのルートディレクトリ以下のすべての階層のプロセスが終了している場合には、環境起動プロセステーブルから当該環境を起動したプロセスのルートディレクトリパスを削除する。これにより、プロセスIDの再利用時にも環境起動プロセステーブルが正しく維持され、プロセスの環境とルートディレクトリとを正しく判別できる。

プロセステーブルに直接、ルートディレクトリ情報（ルートディレクトリパス）を登録してもよい。その場合には環境起動を行ったプロセスのIDも登録しておく。

なお、本発明は上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素を適宜組み合わせることによって種々の発明を形成できる。また例えば、各実施形態に示される全構成要素からいくつかの構成要素を削除した構成も考えられる。さらに、異なる実施形態に記載した構成要素を適宜組み合わせてもよい。

１ ホストシステム
１１ アクセス制御装置
１２ 記憶装置
２１ 環境起動検知部
２２ プロセス関係判定部
２３ アクセス検知部
２４ 照合要否判定部（判定部）
２５ パス変換部（変換部）
２６ リスト照合部
２７ アクセス制御部
３１ プロセス起動検知部
３２ ルートディレクトリ取得部（データ範囲取得部）
３４ ホストパス取得部（データ範囲情報取得部）
３５ プロセス終了検知部

Claims (17)

1. 対象データへのアクセス要求を検知するアクセス検知部と、
   前記対象データの位置情報と、照合対象となるデータ範囲とに基づいて、前記対象データへのアクセスが許可されるか否かの情報との照合の要否を判定する判定部と、
   第１環境の起動を検知し、前記第１環境から参照可能なデータ範囲の情報を取得する環境起動検知部と、を備え、
   前記照合対象となるデータ範囲は、前記第１環境から参照可能な第１データ範囲である
   情報処理装置。
2. 前記判定部は、前記位置情報が前記照合対象となるデータ範囲に含まれる場合に前記照合を行うことを決定する
   請求項１に記載の情報処理装置。
3. 前記第１環境は第１プロセスにより起動され、
   前記対象データへのアクセス要求は第２プロセスにより生成され、
   前記判定部は、前記第２プロセスが前記第１プロセスと子孫関係にある場合に、前記照合を行うことを決定する
   請求項１に記載の情報処理装置。
4. 対象データへのアクセス要求を検知するアクセス検知部と、
   前記対象データの位置情報と、照合対象となるデータ範囲とに基づいて、前記対象データへのアクセスが許可されるか否かの情報との照合の要否を判定する判定部と、を備え、
   前記照合対象となるデータ範囲は、セキュリティ機能に関する第３プロセスから参照可能な第２データ範囲である
   情報処理装置。
5. 前記対象データへのアクセス要求は第２プロセスにより生成され、
   前記判定部は、前記第２プロセスが、前記第３プロセスと子孫関係にある場合に、前記照合を行うことを決定する
   請求項４に記載の情報処理装置。
6. 前記対象データへのアクセス要求は第２プロセスにより生成され、
   前記判定部は、前記第３プロセスが、前記第２プロセスと同じ環境内に存在する場合に、前記照合を行うことを決定する
   請求項４に記載の情報処理装置。
7. 第１環境の起動を検知し、前記第１環境から参照可能な第１データ範囲の情報を取得する環境起動検知部を備え、
   前記第１環境は第１プロセスにより起動され、
   前記第３プロセスが前記第１プロセスと子孫関係にある場合に、前記第１データ範囲の情報に基づき、前記対象データの位置情報を前記第３プロセスから参照可能な形式に変換する変換部
   を備えた請求項４～６のいずれか一項に記載の情報処理装置。
8. 前記照合は、前記対象データの変換後の位置情報が、前記アクセスが許可されている又は許可されていないデータの位置情報を含むリストに合致するかを判断する処理である
   請求項７に記載の情報処理装置。
9. 前記対象データの位置情報は、階層構造の第１パスで表され、
   前記第２データ範囲は、階層構造の第２パスで表され、
   前記変換部は、前記第１パスと前記第２パスとの間で最上位の階層から連続して一致するパス部分を前記第１パスから削除することにより、前記対象データの位置情報を変換する
   請求項７又は８に記載の情報処理装置。
10. 前記対象データへのアクセス要求は、第２プロセスにより生成され、
    環境内におけるプロセスの起動を検知し、検知した前記プロセスを、前記環境を起動したプロセスである第４プロセスに関連付けたプロセス関連データを生成する、プロセス起動検知部と、
    前記第４プロセスと、前記第４プロセスが起動した前記環境から参照可能なデータ範囲とを対応付けた環境データと、
    前記プロセス関連データにおいて、前記第２プロセスに関連付けられた前記第４プロセスを特定し、前記環境データにおいて、前記第４プロセスに対応する前記データ範囲を前記第１データ範囲とするデータ範囲取得部と
    を備えた請求項１、３、７～９のいずれか一項に記載の情報処理装置。
11. 前記対象データへのアクセス要求は、第２プロセスにより生成され、
    環境内におけるプロセスの起動を検知し、検知した前記プロセスを、前記環境から参照可能なデータ範囲に関連付けたプロセス関連データを生成する、プロセス起動検知部と、
    前記プロセス関連データにおいて前記第２プロセスに関連付けられたデータ範囲を前記第１データ範囲とするデータ範囲取得部と
    を備えた請求項１、３、７～９のいずれか一項に記載の情報処理装置。
12. 前記環境起動検知部は、第２環境内において前記第１環境の起動を検知し、前記第１データ範囲の情報を取得し、前記第１データ範囲の情報は前記第２環境からの視点で前記第１データ範囲を定義しており、
    前記第１データ範囲の情報と、前記第２環境から参照可能な第３データ範囲の情報とに基づき、前記第２環境が設けられているシステムからの視点で前記第１データ範囲を定義したデータ範囲情報を取得するデータ範囲情報取得部
    を備えた請求項１、３、７～１１のいずれか一項に記載の情報処理装置。
13. 前記第１データ範囲の情報を記憶する記憶部と、
    前記第１環境を起動した第１プロセス及び前記第１プロセスの子孫関係にあるプロセスがすべて終了しているか否かを検査し、前記第１プロセス及び前記第１プロセスの子孫関係にあるプロセスがすべて終了している場合は、前記記憶部から前記第１データ範囲の情報を消去するプロセス終了検知部と
    を備えた請求項１、３、７～１２のいずれか一項に記載の情報処理装置。
14. 前記判定部により前記照合を行うことが決定された場合に、前記照合を行う照合部
    を備えた請求項１～１３のいずれか一項に記載の情報処理装置。
15. 前記照合部は、前記対象データに関する第１情報が、前記アクセスを許可されている又は許可されていないデータに関する情報のリストに含まれているか否かを判断する
    請求項１４に記載の情報処理装置。
16. 対象データへのアクセス要求を検知し、
    前記対象データの位置情報と、照合対象となるデータ範囲とに基づいて、前記対象データへのアクセスが許可されるか否かの情報との照合の要否を判定し、
    第１環境の起動を検知し、前記第１環境から参照可能なデータ範囲の情報を取得し、
    前記照合対象となるデータ範囲は、前記第１環境から参照可能な第１データ範囲である
    情報処理方法。
17. 対象データへのアクセス要求を検知するステップと、
    前記対象データの位置情報と、照合対象となるデータ範囲とに基づいて、前記対象データへのアクセスが許可されるか否かの情報との照合の要否を判定するステップと、
    第１環境の起動を検知し、前記第１環境から参照可能なデータ範囲の情報を取得するステップと、をコンピュータに実行させ、
    前記照合対象となるデータ範囲は、前記第１環境から参照可能な第１データ範囲である
    コンピュータプログラム。

Images