(57)【特許請求の範囲】
【請求項１】
コンピュータシステムのOS上で動作するプロセスに応じてファイルの多重化を行う情報漏洩防止システムであって、
前記プロセスのセキュリティレベルを判定するセキュリティレベル判定部と、
前記プロセスによるファイルのオープンがファイルの変更を生じさせうるかどうかを判定するファイル変更判定部と、
ファイルの多重化がなされているかどうかをファイル単位で記憶し、判定するファイル多重化判定部と、
前記プロセスがファイルをオープンする際に、前記ファイル変更判定部が変更を生じさせると判定し、前記ファイル多重化判定部が多重化がなされていないと判定したファイルを、前記セキュリティレベル判定部により判定されたセキュリティレベルに応じて、同一のパスを持つ実体の異なるファイルに切り替えるファイルシステムのディレクトリの多重化を行う多重化部とを具備する情報漏洩防止システム。
【請求項２】
請求項１記載の情報漏洩防止システムにおいて、
特定のセキュリティレベルからのみ変更が可能なファイルやディレクトリを、ファイル単位にアクセスポリシーとして列挙して保存したアクセスポリシー管理部と、
前記プロセスがファイルにアクセスした際に、前記アクセスポリシー管理部に保存されたアクセスポリシーに応じてファイルへのアクセスを禁止するアクセス制限部と、
を具備する情報漏洩防止システム。
【請求項３】
請求項１記載の情報漏洩防止システムにおいて、
前記プロセスをそれぞれ異なるセキュリティレベルとする複数のモードがあり、そのモードに応じて、前記ファイルシステムにおける前記多重化部により多重化されたファイルの情報を削除する再共有部を有する情報漏洩防止システム。
【請求項４】
請求項３記載の情報漏洩防止システムにおいて、
特定のセキュリティレベルからのみ変更が可能なファイルやディレクトリを、ファイル単位にアクセスポリシーとして列挙して保存したアクセスポリシー管理部と、
前記プロセスがファイルにアクセスした際に、前記アクセスポリシー管理部に保存されたアクセスポリシーに応じてファイルへのアクセスを禁止するアクセス制限部と、
を具備する情報漏洩防止システム。
【請求項５】
請求項１ないし請求項４のいずれかに記載の情報漏洩防止システムにおいて、
前記プロセスのログオン時に該プロセスのセキュリティレベルを決定する一括モード選択部と、
前記一括モード選択部により決定されたセキュリティレベルに応じて、前記プロセスによる外部メディア装置へのアクセスを制限するデバイス制御部と、
前記一括モード選択部により決定されたセキュリティレベルに応じて、ネットワーク経由の情報送信を制限するネットワークフィルタ部と、
を備える情報漏洩防止システム。
【請求項６】
請求項１ないし請求項４のいずれかに記載の情報漏洩防止システムにおいて、
前記プロセスの起動時にプロセスのセキュリティレベルを決定する個別モード選択部と、
前記個別モード選択部により決定されたセキュリティレベルに応じて、前記プロセスによる外部メディア装置へのアクセスを制限するデバイス制御部と、
前記個別モード選択部により決定されたセキュリティレベルに応じて、ネットワーク経由の情報送信を制限するネットワークフィルタ部と、
前記個別モード選択部により決定されたセキュリティレベルに応じて、第１のプロセスから第２のプロセスとの間の通信を防止するIPC防止部を備える情報漏洩防止システム。
【請求項７】
コンピュータシステムのOS上で動作するプロセスに応じてファイルの多重化を行う情報漏洩防止方法であって、
前記プロセスのセキュリティレベルを判定し、
前記プロセスによるファイルのオープンがファイルの変更を生じさせうるかどうかを判定し、
ファイルの多重化がなされているかどうかを判定し、
前記プロセスがファイルをオープンする際に、そのことが変更を生じさせると判定し、多重化がなされていないと判定したファイルについては、判定したセキュリティレベルに応じて、同一のパスを持つ実体の異なるファイルに切り替えるファイルシステムのディレクトリの多重化を行う情報漏洩防止方法。
【請求項８】
請求項７記載の情報漏洩防止方法において、
特定のセキュリティレベルからのみ変更が可能なファイルやディレクトリを、ファイル単位にアクセスポリシーとして列挙して保存し、
前記プロセスがファイルにアクセスした際に、前記アクセスポリシーに応じてファイルへのアクセスを禁止する情報漏洩防止方法。
【請求項９】
請求項７記載の情報漏洩防止システムにおいて、
前記プロセスをそれぞれ異なるセキュリティレベルとする複数のモードがあり、そのモードに応じて、前記ファイルシステムにおける前記多重化部により多重化されたファイルの情報を削除する情報漏洩防止方法。
【請求項１０】
請求項９記載の情報漏洩防止方法において、
特定のセキュリティレベルからのみ変更が可能なファイルやディレクトリを、ファイル単位にアクセスポリシーとして列挙して保存し、
前記プロセスがファイルにアクセスした際に、前記アクセスポリシーアクセスポリシーに応じてファイルへのアクセスを禁止する情報漏洩防止方法。
【請求項１１】
請求項７ないし請求項１０のいずれかに記載の情報漏洩防止方法において、
前記プロセスのログオン時に該プロセスのセキュリティレベルを決定し、
前記決定されたセキュリティレベルに応じて、前記プロセスによる外部メディア装置へのアクセスを制限し、
前記決定されたセキュリティレベルに応じて、ネットワーク経由の情報送信を制限する情報漏洩防止方法。
【請求項１２】
請求項７ないし請求項１０のいずれかに記載の情報漏洩防止方法において、
前記プロセスの起動時にプロセスのセキュリティレベルを決定し、
前記決定されたセキュリティレベルに応じて、前記プロセスによる外部メディア装置へのアクセスを制限し、
前記決定されたセキュリティレベルに応じて、ネットワーク経由の情報送信を制限し、
前記決定されたセキュリティレベルに応じて、第１のプロセスから第２のプロセスとの間の通信を防止する情報漏洩防止方法。
【請求項１３】
請求項１ないし請求項６のシステムをコンピュータシステム上に構築するプログラム。
【請求項１４】
請求項１３記載のプログラムを格納した記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報漏洩防止システム、情報漏洩防止方法、プログラムおよび記録媒体に関し、特に対象とするアプリケーションを限定せずに、機密情報のみの漏洩を防止するシステム、方法、プログラム、記録媒体に関する。
【背景技術】
【０００２】
近年、企業内ネットワークなどの情報システムで管理されている機密情報が、インターネット上に流出したり、印刷されて持ち出されたり、フロッピーディスクやＵＳＢメモリのような外部メディアにコピーされて持ち出されたりする情報漏洩事件・事故が問題となっている。このような問題は、特に管理が不十分なクライアントPCで生じることが多く、いくつかの対処技術が提案されている。
【０００３】
まず、ユーザの権限に応じて、外部メディアやネットワーク機能に制限を加えるという技術が実用化されている（従来技術１）。この機能は、例えば、Microsoft社のWindows 2000以降のOSであれば、Active Directoryのグループポリシーによって実現することが可能である。しかし、このような制限を一律に加えてしまうと、常に外部メディアの利用や、ネットワーク機能の利用に制限が加わるため、利便性に問題がある。
【０００４】
従来技術１の問題を解決する手段として、特許文献１（特開２００２−２８８０３０号公報）に開示される技術のように、機密情報のみを保存するディレクトリを用意し、そのディレクトリ内のファイルを読み込んだアプリケーションはそれ以外のディレクトリにファイルを保存できなくし、外部メディアやプリンタへのアクセスも制限するという技術が公開されている。これを従来技術２と呼ぶ。
【０００５】
図２３は、従来技術２の動作を表す図である。機密情報を保存するディレクトリ（機密領域と呼ぶ）１００３内の機密ファイル１００４を読み込んだアプリケーションプロセスＡ１００１は、機密情報を保存するディレクトリ（機密領域と呼ぶ）１００３に機密ファイル１００４を保存することができるが、機密で無い領域１００５には機密ファイル１００４およびファイル１００６を保存することができない。一方、機密ファイル１００４を読み込んでいないアプリケーションプロセスＢ１００２は、機密領域以外の領域１００５へのファイル１００６の保存が可能である。
【０００６】
従来技術２により、過失または故意によって、機密ファイルをＵＳＢメモリなどの外部メディアに書き出すことはできなくなる。なぜならば、ＵＳＢメモリなどの外部メディアは機密で無い領域１００５であるため、機密ファイルを読み込んだプロセスがファイルを書き出すことができないためである。その一方、機密ファイルを読んでいないプロセス１００２に関しては制限されないので、従来技術１にあった問題を解消できる。
【０００７】
しかし、従来技術２では、利用できるアプリケーションに制限が生じたり、特定のディレクトリを介した情報漏洩が生じたりするという問題がある。
【０００８】
例えば、多くのアプリケーションは、実行中にテンポラリファイル（一時ファイル）をディスク上に書き出して処理を行う。仮に、図２３のアプリケーションプロセスＡ１００１も、アプリケーションプロセスＢ１００２も共に、c:\windows\tempに一時ファイルを出力する機能を持っていたとする。
【０００９】
ここで、c:\windows\tempを機密領域１００３として指定すると、アプリケーションプロセスＡ１００１は一時ファイルを書き出すことができるが、アプリケーションプロセスＢ１００２は一時ファイルを書き出すことができず、処理を中断するなどの誤動作を起こす。一方、c:\windows\tempを機密でない領域１００５として指定すると、アプリケーションプロセスＢ１００２は一時ファイルを書き出すことができるが、アプリケーションプロセスＡ１００１は一時ファイルを書き出すことができず、やはり処理を中断するなどの誤動作を起こす。
【００１０】
上記の問題への対処方法は特許文献１には明記されていないが、c:\windows\tempは例外的に常にファイルを書き出せるようにすると、機密領域中の機密ファイルを、アプリケーションプロセスＡ１００１で読んでc:\windows\tempに保存し、その後、アプリケーションプロセスＢ１００２でc:\windows\tempに保存されている機密ファイルを読んで印刷することができてしまい、情報漏洩が生じてしまう。この問題は、一時ファイルに限らず、アプリケーションのカスタマイズ情報を保存しておく設定ファイルや、ログファイルなどによっても引き起こされる。
【００１１】
このような、従来技術２の問題に対処するため、特別にセキュリティに配慮して設計されたトラステッドOSでは、プロセスのセキュリティレベルに応じて、見かけ上は同一のディレクトリの内容を、実質的には切り替える方式(deflection directory)が実装されている。これを従来技術３と呼ぶ。なお、同一のパスを持つディレクトリまたはファイルの実体を、アクセス元のプロセスに応じて切り替えることを、以降「多重化」と呼ぶ。
【００１２】
非特許文献１（サンマイクロシステムズ、「Trusted Solaris管理の手順」、ＭＬＤを使った作業、［平成１８年３月２８日検索］、インターネット<URL:http://docs.sun.com/app/docs/doc/805-8093/6j7k0s5av?a=view>）に記載された、Sun Microsystems社のTrusted Solarisでは、このようなディレクトリをMLD(Multi Level Directory)と呼び、例えば、/tmpとホームディレクトリが既定でMLDとして定義されている。
【００１３】
図２４は、MLDの動作例である。プロセスのセキュリティレベルがConfidentialの場合、そのプロセスから/myHomeDirを参照した場合、図２４（ａ）に示すように、実際には/myHomeDir/.SLD.0の内容が参照される(file1のみ存在するように見える)。また、別のプロセスのセキュリティレベルがSecretの場合、そのプロセスから/myHomeDirを参照した場合、図２４（ｂ）に示すように、実際には/myHomeDir/.SLD.1の内容が参照される(file2とfile3のみ存在するように見える)。その結果、仮にファイル名が同じであっても、両者は別のファイルを参照することになる。
【００１４】
Trusted Solarisでは、ユーザはプロセスのセキュリティレベルをプロセス起動時に設定することができる。従って、機密情報を編集する際には、アプリケーションをSecretレベルで起動して機密ファイルを読み込み、社内情報を編集する際には、アプリケーションをConfidentialレベルで起動して社内ファイルを読み込む。ここで、Confidentialレベルのプロセスはプリンタデバイスにアクセス可能だが、Secretレベルのプロセスはプリンタデバイスにアクセス不可にしておけば、印刷による機密情報の漏洩は防止できる。
【００１５】
また、MLDにより、従来技術２の課題は解決できる。例えば、テンポラリディレクトリをＭＬＤに指定しておけば、機密文書を読み込んだプロセスが保存する一時ファイルの場所と、機密文書を読み込んでいないプロセスが保存する一時ファイルの場所とは、見かけは同じでも実質的には異なるので、一時ファイルの保存を許可しても漏洩は生じない。
【特許文献１】特開２００２−２８８０３０号公報
【非特許文献１】サンマイクロシステムズ、「Trusted Solaris管理の手順」、ＭＬＤを使った作業、［平成１８年３月２８日検索］、インターネット<URL:http://docs.sun.com/app/docs/doc/805-8093/6j7k0s5av?a=view>
【発明の開示】
【発明が解決しようとする課題】
【００１６】
従来技術３により、従来技術１や従来技術２の持つ課題を解消できるが、従来技術３にも依然として以下に挙げる３つの課題がある。
【００１７】
１つ目の課題は、どのディレクトリを多重化するのかを、予め設定する必要があるため、対象とできるアプリケーションに依然として制限が生じることである。
【００１８】
UNIX系OSでは、ユーザ毎の設定ファイルや一時ファイルを保管する場所が慣習的にほぼ決まっているため、/tmpディレクトリとホームディレクトリを多重化することによって、設定ファイルや一時ファイルを分離することは比較的容易であり、アプリケーションの制限は比較的生じにくい。しかし、Windows OS上では、マルチユーザ環境を意識せずに作成されたアプリケーションも多く、どこをMLDに指定するかを決定するのは難しい。
【００１９】
例えば、本来はプログラムを保管すべき場所であるc:\program filesの下に、設定ファイルやログファイルを書き出すようなアプリケーションが多く存在する。このようなアプリケーションに対応するために、c:\program files以下を全て多重化すると、ディスク容量を浪費することになる上に、全てのセキュリティレベルで同じアプリケーションを使用したい場合、それぞれのセキュリティレベルでインストールを繰り返す必要が生じてしまい、運用性の負荷が増大する。
【００２０】
２つ目の課題は、ディレクトリ単位で多重化する場所を指定する必要があるため、OSのパッチ適用などの管理の手間が増えることである。
【００２１】
マルチユーザ環境を意識せずに作成されたアプリケーションが多いWindows OS上では、本来はOSを構成するファイルが配置されているc:\windows\system32の下に、設定ファイルを書き出すようなアプリケーションも存在する。このようなアプリケーションに対応するためには、従来技術３ではc:\windows\system32以下をMLDに指定する必要があるが、そうしてしまうと、OSのパッチを適用する際に、それぞれのセキュリティレベルでパッチ当てを繰り返す必要が生じてしまう。なぜならば、それぞれのセキュリティレベルから見えるc:\windows\system32の実体が異なるため、c:\windows\system32に配置されているOSを構成するファイルを更新するには、それぞれのセキュリティレベルにおいてc:\windows\system32の実体を更新する必要があるためである。
【００２２】
３つ目の課題は、ファイルやディレクトリが多重化されるという動作が、一般のユーザには直感的に理解しにくく、利用者の混乱を引き起こす可能性がある点である。
【００２３】
例えば、あるセキュリティレベルでアプリケーションの設定をカスタマイズしても、別のセキュリティレベルで起動した場合はカスタマイズする前の状態のままである。これは、アプリケーションの設定ファイルが多重化されており、実体が異なるためであるが、一般のユーザには分かりにくい動作である。また、図２４を用いて説明した例のように、あるセキュリティレベルではホームディレクトリにあった文書が、別のセキュリティレベルでは見えなくなる、という動作も一般のユーザには混乱を引き起こす可能性がある。そのため、ファイルやディレクトリが多重化されていることをあまりユーザが意識せずにすむように、多重化を抑える機能があることが望ましい。
【００２４】
本発明は上述した従来の技術が有する問題点に鑑みてなされたものであって、プロセスのセキュリティレベルに応じて、ファイルを多重化することによって従来技術２の課題を解消する方式において、どのディレクトリを多重化するのかを、予め設定する必要がない方式を提供し、Windows OSのように、マルチユーザ環境を意識せずに作成されたアプリケーションが動作するような環境であっても、ファイルの多重化を効率よく、運用の負荷をかけずに実現することを目的とする。
【００２５】
また、本発明の他の目的は、プロセスのセキュリティレベルに応じて、ファイルを多重化することによって従来技術２の課題を解消する方式において、OSのパッチ適用やアプリケーションのインストール、アップグレードは一括して行う方式を提供することである。
【００２６】
また、本発明のさらに他の目的は、ファイルの多重化によって一般のユーザが混乱することを避けるために、プロセスのセキュリティレベルが異なる場合であっても、情報の漏洩やアプリケーションの誤動作を防ぎつつ、できるだけ同一のファイル環境を提供するように、ファイルの多重化を抑制することである。
【課題を解決するための手段】
【００２７】
本発明の方法による情報漏洩防止システムは、コンピュータシステムのOS上で動作するプロセスに応じてファイルの多重化を行う情報漏洩防止システムであって、
前記プロセスのセキュリティレベルを判定するセキュリティレベル判定部と、
前記プロセスによるファイルのオープンがファイルの変更を生じさせうるかどうかを判定するファイル変更判定部と、
ファイルの多重化がなされているかどうかをファイル単位で記憶し、判定するファイル多重化判定部と、
前記プロセスがファイルをオープンする際に、前記ファイル変更判定部が変更を生じさせると判定し、前記ファイル多重化判定部が多重化がなされていないと判定したファイルについては、前記セキュリティレベル判定部により判定されたセキュリティレベルに応じて、同一のパスを持つ実体の異なるファイルに切り替えるファイルシステムのディレクトリの多重化を行う多重化部とを具備する。
【００２８】
上記のような構成を採用し、予め多重化するディレクトリを指定しておく必要なしに、多重化する必要がある部分だけ多重化されるようにすることにより、本発明の第１の目的を達成することができる。
【００２９】
この場合、特定のセキュリティレベルからのみ変更が可能なファイルやディレクトリを、ファイル単位にアクセスポリシーとして列挙して保存したアクセスポリシー管理部と、
前記プロセスがファイルにアクセスした際に、前記アクセスポリシー管理部に保存されたアクセスポリシーに応じてファイルへのアクセスを禁止するアクセス制限部と、
を具備することとしてもよい。
【００３０】
上記のような構成を採用し、OSやアプリケーションプログラムの構成ファイルを事前にアクセスポリシーとして登録しておくことにより、OSのパッチ適用やアプリケーションのアップグレードを、特定のセキュリティレベルでのみ実行すれば、それらは多重化されないため、他のセキュリティレベルでも反映され、本発明の第２の目的を達成することができる。
【００３１】
また、ログオン時に前記プロセスをそれぞれ異なるセキュリティレベルとする複数のモードのいずれかとする一括モード選択部を備え、ログオン時およびログオフ時に前記一括モード選択部により決定されたモードのセキュリティレベルに応じて、前記ファイルシステムにおける前記多重化部により多重化されたファイルの情報を削除する再共有部を有することとしてもよい。
【００３２】
上記のような構成を採用し、定期的に各セキュリティレベルにおけるファイル構造を同一のものにそろえることにより、ファイルの多重化を抑えることができる。特に、機密ファイルがサーバ上で管理されており、クライアントコンピュータ上に保存することが前提とされていない運用形態では、ユーザの作成した文書ファイルのような重要なデータが多重化されることがないため、多重化されたファイルの情報が削除されても重大な情報の損失は生じない。このような運用形態では、このような構成を採用することによって、本発明の第３の目的を達成することができる。
【００３３】
さらに、特定のセキュリティレベルからのみ変更が可能なファイルやディレクトリを、ファイル単位にアクセスポリシーとして列挙して保存したアクセスポリシー管理部と、
前記プロセスがファイルにアクセスした際に、前記アクセスポリシー管理部に保存されたアクセスポリシーに応じてファイルへのアクセスを禁止するアクセス制限部と、
を具備することとしてもよい。
【００３４】
上記のような構成を採用し、定期的に各セキュリティレベルにおけるファイル構造を同一のものにそろえることにより、ファイルの多重化を抑えることができる。ポリシーで指定された特定のディレクトリに関しては、元のセキュリティレベルにおけるファイルが保存されるため、クライアントコンピュータ上で機密文書を扱うことが前提とされている運用形態であっても、ユーザの作成した文書ファイルをこのディレクトリに保存するという運用規定を定めておけば、多重化されたファイルの情報が削除されても重大なデータの損失は生じない。したがって、クライアントコンピュータ上で機密文書を扱うことが前提とされている運用形態においても、本発明の第３の目的を達成することができる。
【００３５】
上記のいずれにおいても、前記プロセスのログオン時に該プロセスのセキュリティレベルを決定する一括モード選択部と、
前記一括モード選択部により決定されたセキュリティレベルに応じて、前記プロセスによる外部メディア装置へのアクセスを制限するデバイス制御部と、
前記一括モード選択部により決定されたセキュリティレベルに応じて、ネットワーク経由の情報送信を制限するネットワークフィルタ部と、
を備えることとしてもよい。
【００３６】
また、前記プロセスの起動時にプロセスのセキュリティレベルを決定する個別モード選択部と、
前記個別モード選択部により決定されたセキュリティレベルに応じて、前記プロセスによる外部メディア装置へのアクセスを制限するデバイス制御部と、
前記個別モード選択部により決定されたセキュリティレベルに応じて、ネットワーク経由の情報送信を制限するネットワークフィルタ部と、
前記個別モード選択部により決定されたセキュリティレベルに応じて、第１のプロセスから第２のプロセスとの間の通信を防止するIPC防止部を備えることとしてもよい。
【００３７】
本発明のプログラムは上記のシステムをコンピュータシステム上に構築し、本は積みの記録媒体はそのプログラムを格納する。
【発明の効果】
【００３８】
本発明は以上説明したように構成されているので、以下に記載するような効果を奏する。
【００３９】
第１の効果は、機密情報を扱うアプリケーションの種類を限定せずに、機密情報のみの漏洩を防止できることである。その理由は、多重化手段により、機密情報を扱うプロセスによるファイル入出力を、予め多重化するディレクトリを指定しておく必要なしに、多重化する必要がある部分だけ多重化するためである。
【００４０】
第２の効果は、OSのパッチ適用のような重要な日常管理の運用の手間は増大させないことである。その理由は、アクセス制限手段により、OSを構成するファイル等についてはファイル単位でファイル名のパターンを基づいて多重化を抑制することにより、一度にOSを構成するファイルを更新できることにある。
【００４１】
第３の効果は、ファイルの多重化によって生じる、ユーザから見た分かりにくさを緩和することである。その理由は、機密ファイルを保存する場所を限定できるような運用形態において、再共有手段により、定期的に多重化されたファイルを多重化されていない状態に戻し、ファイルの多重化を抑制することにより、ユーザはセキュリティレベルの異なるプロセスから見えるファイル構造の違いをあまり意識せずにすむことによる。また、再共有手段によって、重要なデータが削除されることが無いように、アクセス制御手段により、多重化を抑制し、再共有手段によってもファイルが削除されない領域を設けることによる。
【発明を実施するための最良の形態】
【００４２】
次に、発明を実施するための最良の形態について図面を参照して詳細に説明する。
【００４３】
図１を参照すると、本発明の第１の実施の形態は、プログラム制御により動作するコンピュータ（中央処理装置；プロセッサ；データ処理装置）１００と、コンピュータ１００上で動作するオペレーティングシステム（ＯＳ）１０２と、ＯＳ１０２上で動作するプロセス１０１と、ＯＳ１０２のログオン時にプロセス１０１のセキュリティレベルを選択するための一括モード選択部１１３と、ＯＳ１０２によって管理される固定ディスク装置（ハードディスク）１０６と、外部メディア装置（フロッピーディスク、ＵＳＢメモリ、プリンタを含む）１０９と、ネットワークインタフェースカード（ＮＩＣ）１１２とから構成されている。
【００４４】
OS１０２は、固定ディスク装置１０６上にファイルシステムを構築するファイルシステムドライバ１０５と、プロセス１０１からファイルシステムまたは外部デバイスへのアクセスを仲介して、プロセスのセキュリティレベルを判定するセキュリティレベル判定部１０３と、プロセス１０１からファイルシステムへのアクセスを仲介して、ファイル・ディレクトリの多重化を動的に行う多重化部１０４と、外部メディア装置１０９を駆動する外部メディアドライバ１０８と、プロセス１０１から外部メディアドライバ１０８へのアクセスを仲介して、外部メディア装置１０９の利用を制限するデバイス制御手段１０７と、ＮＩＣ１１２を駆動するネットワークドライバ１１１と、プロセス１０１によるネットワークドライバへの通信をフィルタリングし、特定の通信を制限するネットワークフィルタ部１１０を含む。
【００４５】
また、多重化部１０４は、ファイルオープン要求の内容を判定してファイルの変更を伴うアクセス（書き込みアクセス、ファイル作成、ファイル削除など）であるかどうかを判定するファイル変更判定部１０４aと、アクセスの対象となったファイルが多重化されているかどうかを判定するファイル多重化判定部１０４ｂを含む。
【００４６】
これらの各部は、それぞれ概略次のように動作する。
【００４７】
一括モード選択部１１３は、ユーザのＯＳ１０２へのログオン時に、プロセス１０１のセキュリティレベルを選択する機能を持つ。例えば、ログオン画面またはログオン直後に、ユーザに「機密モード」でログオンするか「通常モード」でログオンするかを選択させる画面を表示するものである。それぞれのログオンシェル内で起動されたプロセス１０１は、それぞれ「機密」または「通常」というセキュリティレベルが設定され、「機密」の方がよりセキュリティレベルが高いものとする。以降、セキュリティレベルが「機密」であるプロセスを機密プロセスと呼び、セキュリティレベルが「通常」であるプロセスを通常プロセスと呼ぶ。
【００４８】
セキュリティレベル判定部１０３は、プロセスからファイルシステムまたは外部デバイスへのアクセスを検知した際に、現在どちらのモードでログオンしたかを一括モード選択部１１３に問い合わせ、機密モードでログオンしていれば、セキュリティレベルは「機密」として、通常モードでログオンしていれば、セキュリティレベルは「通常」として判定する機能を持つ。
【００４９】
デバイス制御部１０７は、プロセス１０１のセキュリティレベルに応じて、外部メディアドライバ１０８へのリクエストを制限することにより、外部メディア装置１０９の利用を制限する機能を持つ。例えば、機密プロセスはプリンタ、ＵＳＢメモリ、フロッピーディスクを使用できないが、通常プロセスはそれらを使用可能であるというような制御を行う。デバイス制御部１０７は、セキュリティレベル判定部１０３と外部メディアドライバ１０８の間に介在し、セキュリティレベル判定部１０３から外部メディアドライバ１０８に対するリクエストを仲介し、セキュリティレベル判定部１０３の出力内容に応じて、リクエストをそのまま外部メディアドライバ１０８に渡すか、「アクセス禁止」エラーを返すようにすることで実現できる。
【００５０】
ネットワークフィルタ部１１０は、プロセス１０１のセキュリティレベルに応じて、ネットワークドライバ１１１へのリクエストを制限することにより、ＮＩＣ１１２の利用を制限する機能を持つ。例えば、機密プロセスはネットワーク通信ができないが、通常プロセスはネットワーク通信が可能であるというような制御を行う。
【００５１】
あるいは、ネットワークフィルタ部１１０に通信プロトコルを解析する能力を持たせ、機密プロセスによる情報漏洩のおそれのある通信のみ遮断するようにしてもよい。例えば、機密プロセスはWebサイトの閲覧のみ可能だが、Webサイトへのファイルのアップロードはできないというような制御を行ってもよい。これは、httpプロトコルのGETコマンドのみ許可し、POSTコマンドやPUTコマンドを禁止することによって実現することができる。このようにすれば、機密プロセスであっても、情報漏洩のおそれの無い通信は許可されるので、利便性が向上する。
【００５２】
また、ネットワークフィルタ部１１０では、通信相手毎に通信の可否を判定するようにしてもよい。例えば、コンピュータ１００が、図２に示すように、ネットワークを介して機密ファイルサーバ２０１、一般ファイルサーバ２０２、機密Ｗｅｂサーバ２０３および一般Ｗｅｂサーバ２０４に接続されているとする。
【００５３】
ここで、機密ファイルサーバ２０１は機密ファイルを保存するためのファイルサーバであり、厳重にアクセス管理がなされているものとする。一方、一般ファイルサーバ２０２はどのようなコンピュータからも自由にアクセスできるサーバであるとする。同様に、機密Ｗｅｂサーバ２０３は機密情報を管理するためのＷｅｂサーバであり、厳重にアクセス管理がなされているものとする。一方、一般Ｗｅｂサーバ２０４はどのようなコンピュータからも自由にアクセスできるＷｅｂサーバであるとする。
【００５４】
この場合、ネットワークフィルタ部１１０に図３に示すような、アクセス先のサーバのＩＰアドレス毎にアクセス可否を定めたフィルタリングルールを事前に与えておくことにより、機密ファイルサーバ２０１または機密Ｗｅｂサーバ２０３上の情報は常に機密プロセスからのみアクセス可能であり、一般ファイルサーバ２０２または一般Ｗｅｂサーバ２０４に流出したり、印刷されたり、外部メディアにコピーされたりすることを防ぐことができる。なお、ＩＰアドレスによるネットワークのアクセス制御は、ファイアウォールで広く用いられている公知の技術である。
【００５５】
多重化部１０４は、プロセス１０１のセキュリティレベルに応じて、プロセス１０１からファイルシステムへのアクセスを仲介し、ファイル変更判定部１０４aによりファイルの変更を伴うアクセスかどうかを判定し、変更を伴うアクセスであった場合は、ファイル多重化判定部１０４ｂにより、アクセス先のファイルが既に多重化されているかどうかを判定し、多重化されていなければ多重化処理を行う。ファイルの変更を伴わないアクセスであった場合、多重化処理は行わない。そして、いずれの場合も、既に多重化されているファイルに対してアクセスが生じた場合は、多重化されたファイルの実体をアクセス先に変更する。
【００５６】
また、多重化部１０４は、プロセス１０１からディレクトリの一覧取得を要求された場合、ファイル多重化判定部１０４ｂにより、そのディレクトリ内のファイルが既に多重化されているかどうかを判定し、それぞれの場合に応じて、適宜ディレクトリの内容をマージした上で、プロセスに返す機能を持つ。
【００５７】
図４は多重化されたファイル・ディレクトリの実現方法を表す図であり、図５は多重化される前のファイル構造の一例を示す図であり、図６は多重化された後のファイル構造の一例を示す図である。以下に、図４、図５、図６を参照して、多重化部１０４の動作について詳細に説明する。
【００５８】
多重化されるファイルシステムのルートディレクトリには、予め$secと$markという２つの特殊なディレクトリが作成されている。なお、本実施の形態では、ディレクトリの区切り文字は\で表されるものとする。
【００５９】
$secディレクトリは、機密プロセスから見たファイルの実体を格納するディレクトリである。$markディレクトリは、ファイルが多重化されているかどうかを記憶するための領域であり、多重化されているファイルの場合、$markディレクトリ配下のそのファイルのパスに、サイズ０のファイルが作成される。サイズを０とするのは、ファイルの存在自体で多重化しているかどうかを表すこととするため、ファイルの実体は必要ないことによる。
【００６０】
図４には、$secディレクトリと$markディレクトリの関係が示されている。ここで、[FILE]は、あるファイルの絶対パス(\a.txtとか、\sub\b.txtなど)を表す。初期状態では、R101かR102のいずれかであり、\$mark[FILE]は存在しないため、多重化はされておらず、通常プロセスからも機密プロセスからも同じファイルの実体が見える(R102)か、通常プロセスでも機密プロセスでもそのファイルは無い(R101)かのいずれかである。
【００６１】
通常プロセスまたは機密プロセスでファイルの変更が生じると、ファイルは多重化される。多重化された場合、サイズ0の\$mark[FILE]が生成される。\$mark[FILE]が存在する状態はR103からR106で表される。R103からR106では、通常プロセスから見えるファイルの実体は[FILE]であり、機密プロセスから見えるファイルの実体は\$sec[FILE]である。
【００６２】
R101の状態で、通常プロセスから新しく[FILE]を作成するとR103の状態になり、機密プロセスから新しく[FILE]を作成するとR105の状態になる。また、R102の状態で、通常プロセスまたは機密プロセスで[FILE]を更新すると、R104の状態になる。また、R103の状態で、機密プロセスから新しく[FILE]を作成するとR104の状態になり、R105の状態で、通常プロセスから新しく[FILE]を作成するとR104の状態になる。R103の状態で、通常プロセスから[FILE]を削除したり、R105の状態で、機密プロセスから[FILE]を削除すると、R106の状態になる。
【００６３】
なお、図４に挙げた以外のパターン、例えば、[FILE]有、\$mark[FILE]無、\$sec[FILE]有といったパターンは多重化部１０４の処理では存在しない。
【００６４】
図５は、どのファイルも多重化されていない、初期状態におけるファイル構造の例である。ファイルシステムドライバ１０５上では図５（ｃ）に示すようなファイル構造が構成されている。多重化部１０４により、$secと$markは隠蔽され、機密プロセスからは図５（ａ）に示すように見え、通常プロセスからは図５（ｂ）に示すように見える。この場合、まだどのファイルも多重化されていないため、機密プロセスから見えるファイル構造と通常プロセスから見えるファイル構造には違いが無い。
【００６５】
図６（ｃ）は、機密プロセスが\c.txtを新規作成して\b.txtを削除し、通常プロセスが\sub\c.txtを新規作成して\sub\b.txtを削除し、機密プロセスか通常プロセスのいずれかが\sub\a.txtの内容を変更したときのファイル構造を示す図である。このとき、\b.txt, \c.txt, \sub\a.txt, \sub\b.txt, \sub\c.txtは多重化され、\a.txtは多重化されずに残る。そのため、$mark以下には、多重化されたことを表すため、\$mark\b.txt, \$mark\c.txt, \$mark\sub\a.txt, \$mark\sub\b.txt, \$mark\sub\c.txtというサイズ０のファイルが作成される。
【００６６】
ここで、図６では、ファイルの実体が異なることを明示するために、$sec配下のファイル・ディレクトリにはハッチをかけている。同じパス名で表されていても、ハッチがかかっているものとそうでないものは実体が異なる。
【００６７】
多重化部１０４を通して、通常プロセスから見たファイルの構造は図６（ｂ）に示すようになる。通常プロセスから見た場合、多重化部１０４により、$secと$markは隠蔽されるが、それ以外は実際のファイル構造がそのまま見える。
【００６８】
また、機密プロセスから見たファイル構造は図６（ａ）に示すようになる。機密プロセスから見た場合、多重化部１０４により、$secと$markが隠蔽されるだけでなく、多重化されていないファイルと、$sec以下のファイルがマージされて表示される。例えば、図６（ａ）に示される状態では、ルート直下は、多重化されていないファイルa.txtと、$sec以下にあるc.txtとsubからなるディレクトリであるかのように見える。
【００６９】
以上の例より、多重化部１０４により、ファイル単位で動的にファイル・ディレクトリの内容が多重化されることが分かる。すなわち、新しく作成されたファイル\c.txtは機密プロセスのみから参照することが可能となり、\sub\c.txtは通常プロセスのみから参照することが可能となる。
【００７０】
また、削除されたファイル\b.txtは機密プロセスからのみ見えなくなり、\sub\b.txtは通常プロセスからのみ見えなくなる。また、変更されたファイル\sub\a.txtは、機密プロセスと通常プロセスの両方から参照可能であるが、そのファイルの実体は、機密プロセスから見た場合\$sec\sub\a.txtであり、通常プロセスから見た場合は\sub\a.txtであり、実体は異なる。
【００７１】
以降、機密プロセスが\sub\a.txtを開いた場合、開かれるファイルの実体は\$sec\sub\a.txtであり、機密情報を書き出したとしても、通常プロセスから読まれることは無い。なぜならば、機密プロセスが\sub\a.txtを開いた場合、開かれるファイルの実体は\sub\a.txtであり、\$sec\sub\a.txtとは異なるためである。
【００７２】
また、全く変更が無かったファイル\a.txtは、そのファイルの実体は、機密プロセスから見ても通常プロセスから見ても同じ\a.txtである。通常プロセスまたは機密プロセスから、ファイルの変更を伴うアクセスが生じない限り、この状態は維持される。
【００７３】
以下、より詳細に、多重化部１０４の動作手順について述べる。
【００７４】
まず、通常プロセスがファイルをオープンする際の、多重化部１０４の動作を図７に示す。ここで、[FILE]はオープンするファイルの絶対パス（例：\foo.txt, \windows\temp\1.tmp）を表す。
【００７５】
まず、"\$mark"に[FILE]を連結したパス(例えば、"\$mark\foo.txt")を作成し、そのパスにファイルが存在するかどうかをチェックする（ステップＳ１０１）。存在することが確認された場合、そのファイルは既に多重化されていることを表すので、そのまま[FILE]のオープンを継続する（ステップＳ１０６）。
【００７６】
ステップＳ１０１で連結したパスにファイルが存在しないことが確認された場合、このファイルオープンが書き込みオープンかどうかを判定する（ステップＳ１０２）。書き込みオープンでない場合、ファイルが変更される（ファイルの作成・書き込み・削除など）ことはなく、多重化する必要は無いので、そのまま[FILE]のオープンを継続する（ステップＳ１０６）。
【００７７】
書き込みオープンであった場合、オープン先のファイルが既に存在するかどうかをチェックし（ステップＳ１０３）、既に存在する場合は、そのファイルを$sec配下にコピーする（ステップＳ１０４）。そして、ファイルの存在の有無に関わらず、$mark配下に\$markに[FILE]を連結したパスで表されるサイズ０のファイルを生成する（ステップＳ１０５）。その上で、[FILE]のオープンを継続する（ステップＳ１０６）。ステップＳ１０３からステップＳ１０５までの手順により、通常プロセスと機密プロセスとの間で、[FILE]が多重化される。
【００７８】
次に、機密プロセスが、ファイルをオープンする際の、多重化部１０４の動作を図８に示す。
【００７９】
まず、\$markに[FILE]を連結したパスを作成し、そのパスにファイルが存在するかどうかをチェックする（ステップＳ２０１）。存在する場合、そのファイルは既に多重化されていることを表すので、\$secを[FILE]の先頭に付加したパスのオープンを継続する（ステップＳ２０６）。
【００８０】
ステップＳ２０１にて連結したパスにファイルが存在しないことが確認された場合、このファイルオープンが書き込みオープンかどうかを判定する（ステップＳ２０２）。書き込みオープンでない場合、ファイルが変更されたり削除されたりすることはないので多重化する必要は無いので、そのまま[FILE]のオープンを継続する（ステップＳ２０７）。
【００８１】
書き込みオープンであった場合、オープン先のファイルが既に存在するかどうかをチェックし（ステップＳ２０３）、既に存在する場合は、そのファイルを$sec配下にコピーする（ステップＳ２０４）。そして、ファイルの存在の有無に関わらず、$mark配下に\$markに[FILE]を連結したパスで表されるサイズ０のファイルを生成する（ステップＳ２０５）。ステップＳ２０３からステップＳ２０５までの手順により、通常プロセスと機密プロセスとの間で、[FILE]が多重化されたので、機密プロセスからは多重化された$sec配下のファイルのオープンを継続する（ステップＳ２０６）。
【００８２】
次に、通常プロセスが、ディレクトリの内容一覧を取得（リスティング）する際の、多重化部１０４の動作を図９に示す。ここで、[DIR]は、リスティングの対象となるディレクトリの絶対パス（例：\windows）を示す。まず、[DIR]内部を実際にリスティングし（ステップＳ３０１）、[DIR]がルートディレクトリの場合には（ステップＳ３０２）リスティング結果から$secと$markを除外する（ステップＳ３０３）。ルートディレクトリでない場合は、リスティング結果をそのまま返す。以上により、通常プロセスから$secと$markを隠蔽しつつディレクトリのリスティングをすることができる。
【００８３】
次に、機密プロセスがディレクトリのリスティングする際の、多重化部１０４の動作を図１０に示す。
【００８４】
まず、[DIR]内部を実際にリスティングし（ステップＳ４０１）、[DIR]がルートディレクトリの場合は（ステップＳ４０２）リスティング結果から$secと$markを除外する（ステップＳ４０３）。そして、さらに、リスティング結果から、$mark配下にファイルがあるものを除外する（ステップＳ４０４）。例えば図６に示した例では、\直下のリスティング結果がa.txt, b.txt, subであり、\mark\以下に、b.txt, c.txt, subが存在するので、b.txtとsubを除外して、a.txtのみをステップＳ４０４のリスティング結果とする。
【００８５】
そして、さらに、$sec配下にディレクトリ\$sec[DIR]が存在すれば、その内容をリスティングし、その結果をステップＳ４０４の結果にマージする。例えば図６に示した例では、\$sec\のリスティング結果がc.txt, subであるので、それを前記のa.txtとマージし、\直下にはa.txt, c.txt, subの３つのファイル・ディレクトリがあるものとして返す。
【００８６】
以上により、図６（ｃ）に示すようなファイル構造は、機密プロセスからは図６（ａ）のように見えることとになる。
【００８７】
次に、本発明を実施するための最良の形態の効果について説明する。
【００８８】
ユーザが機密情報を扱う場合は、一括モード選択部１１３で機密モードでログオンする必要があり、その場合、セキュリティレベル判定部１０３とデバイス制御部１０７、ネットワークフィルタ部１１０により、機密ファイルを外部メディアやネットワークを介して外部に漏洩させることは制限される。
【００８９】
一方、機密でない情報を扱う場合は、このような制限は生じない。これより、従来技術１と異なり、利便性を損なうことなく機密情報の漏洩の防止のみ実現できる。
【００９０】
また、多重化部１０４により、機密プロセスと通常プロセスから見た構造を多重化するため、従来技術２にあった、一時ファイルや設定ファイルの読み書きが発生する際にアプリケーションの動作が不正になったり、一時ファイルや設定ファイルの読み書きを例外的に許可することで情報漏洩の経路が生じたりする、といった課題を解消することができる。
【００９１】
さらに、多重化部１０４を、ファイル変更判定部１０４aとファイル多重化判定部１０４ｂを含む構成にし、機密プロセスと通常プロセスから見た構造を、ファイル単位で、ファイルの変更が生じたときに自動的に多重化するように構成されている。このため、従来技術３と異なり、予め多重化する場所を指定する必要はなく、かつ、変更が生じた部分のみファイル単位で多重化することとなる。これにより、OSの構成ファイルが格納されているディレクトリに設定ファイルがあったり、アプリケーションプログラムの構成ファイルが格納されているディレクトリに一時ファイルが書き出されたりするような場合であっても、OSの構成ファイルやアプリケーションプログラムの構成ファイルを多重化することなく、設定ファイルやログファイルのみを多重化することができる。
【００９２】
この結果、利用するアプリケーションの動作に応じてどのディレクトリを多重化するかを指定する必要はなくなる。特にWindowsのようにファイルの利用の仕方がアプリケーションによってまちまちな環境であっても、利用可能なアプリケーションに制限が生じたり、運用が難しくなったりする問題を解消できる。
【００９３】
なお、本実施の形態では、ファイルが多重化されているかどうかを識別する方法として、ファイルシステム上に$markというディレクトリを作成し、そこにサイズ０のファイルを配置する実現方法について述べたが、他の実現方法によってこれを実現してもよい。例えば、図１１に示すように、多重化されているファイルのリストの一覧を記載した単一のファイルに記憶するようにしてもよい。
【００９４】
また、本実施の形態では、ファイルが多重化されているかどうかを表すファイルは、多重化されていないファイルを多重化するときに生成されるものの、削除されることはなかったが、図４のR106の状態になった場合に削除してR101の状態に戻すようにしてもよい。このようにすれば、多少ディスク消費量を節約することが可能である。
【００９５】
また、本実施の形態では、多重化されたファイルの実体を管理する方法として、機密プロセスが参照するファイルの実体を特殊ディレクトリ内に格納する実現方法について述べたが、これは通常プロセスによるファイルのオープン、ディレクトリのリスティング処理のオーバーヘッドを少なくすることを目的とした実現方法であり、その他の実現方法を用いてもよい。例えば、通常プロセスが参照するファイルの実体を特殊ディレクトリ内に格納するようにしてもよい。
【００９６】
また、本実施の形態では、セキュリティレベルが通常と機密の２つだけ定義され、通常＜機密という関係がある場合について述べたが、それらが３つ以上ある場合でも実現することが可能である。例えば、通常＜社外秘＜機密という３段階のセキュリティレベルがある場合、$secの他に、例えば$confという特殊ディレクトリを設け、社外秘のファイルは$confに多重化するようにすればよい。また、通常＜機密A、通常＜機密Bというような関係がある場合、例えば、$secA, $secBという特殊ディレクトリを設け、機密Aのファイルは$secA、機密Bのファイルは$secBに多重化するようにすればよい。
【００９７】
また、本実施の形態では、多重化部１０４はファイルシステムドライバ１０５とプロセス１０１の間の処理を仲介して、プロセスからファイルシステムドライバへの処理を置き換えるフィルタドライバあるいはＡＰＩフックとして実現する方法について述べたが、ファイルシステムドライバに直接変更を加えてもよい。フィルタドライバやＡＰＩフックで実現した場合、ファイルシステム自体は変更しないため、一時的に本機能を利用したり、特定のユーザのみ本機能を利用するといった、より柔軟な運用が可能となるという長所がある。
【００９８】
次に、本発明の第２の発明を実施するための最良の形態について図面を参照して詳細に説明する。
【００９９】
図１２は、第２の実施の形態の構成図である。第２の実施の形態は、第１の実施の形態にアクセス制限部１１４と、アクセスポリシー管理部１１５を加えたものである。アクセス制限部１１４は、アクセスポリシー管理部１１５に記述された、通常領域ポリシー１１５aを参照し、プロセス１０１からのファイルアクセスを選択的に禁止する機能を持つ。
【０１００】
アクセスポリシー管理部１１５は、コンピュータ１００の固定ディスク１０６上に配置してもよいし、別のコンピュータ上に配置して、そこからコンピュータ１００に配布するようにしてもよい。別のコンピュータ上に配置して配布した場合、複数のコンピュータにアクセスポリシーを同時に配布できると言う長所がある。
【０１０１】
通常領域ポリシー１１５aは、特定のセキュリティレベルからのみ変更が可能であり、機密プロセスからのファイル変更を伴うアクセスを禁止して多重化を抑止するファイルまたはディレクトリのリストである。図１３は、通常領域ポリシー１１５aの一部の例である。この例では、Windows OSを構成するファイル名のパターンが通常領域ポリシーとして記述されている。なお、この例では、通常領域ポリシーの記述形式としてワイルドカードを含むパターンを用いているが、正規表現などを用いるようにしてもよい。
【０１０２】
図１４はアクセス制限部１１４の動作を表すフローチャートである。
【０１０３】
まず、ファイルオープン処理を実行したプロセスが、機密プロセスであるかどうか判定し（ステップＳ５０１）、機密プロセスであれば、そのファイルオープン処理がファイルの変更を伴うものであるかどうかを判定し（ステップＳ５０２）、変更を伴うものである場合、オープン先のファイルが通常領域ポリシーにマッチするかどうか判定する（ステップＳ５０３）。通常領域ポリシーにマッチする場合は、そのファイルオープンを失敗させる（ステップＳ５０５）。具体的には、「アクセス拒否」のエラーコードを返すなどすればよい。上記の条件に合致しない場合は、そのまま多重化部１０４を実行する（ステップＳ５０４）。
【０１０４】
次に、本実施の形態の効果について説明する。
【０１０５】
図１３の通常領域ポリシーを用いた場合、機密プロセスがOSを構成するファイルを変更することはできなくなり、その結果、OSを構成するファイルが多重化されることもなくなる。これにより、通常プロセスでOSのパッチ適用（OSを構成するファイルの更新）を行うと、その結果は機密プロセスにも反映される。なぜなら、OSを構成するファイルは多重化されることがないためである。その結果、OSのパッチ適用を一度に済ますことが可能になる。同様に、アプリケーションを構成するファイルのパスを通常領域ポリシーに登録しておくことにより、アプリケーションのパッチ適用も一度に済ますことが可能になる。
【０１０６】
OSを構成するファイルが配置されているディレクトリが厳密に決まっており、そのディレクトリ内には一般のアプリケーションはファイルを書き出すことが無いのであれば、同様の効果を、従来技術３でも達成することは可能である。すなわち、OSを構成するファイルが配置されているディレクトリはMLDに指定しないようにすればよい。
【０１０７】
しかし、Windows環境のように、OSを構成するファイルが配置されている場所に設定ファイル等を書き出すアプリケーションが存在しうる場合、従来技術３では、ＯＳのパッチ適用の一括実施と、アプリケーションの正常な動作は両立できない。それと比べ、本実施の形態ではこの２つを両立することができる。これは、ファイル単位で自動的に多重化しつつ、ＯＳの構成ファイルに対してのみ通常領域ポリシーを適用して、多重化を抑止できるためである。
【０１０８】
本実施の形態の別の効果は、通常プロセスから機密プロセスへのファイルの受け渡しを行うための、専用のディレクトリを提供できることである。例えば、通常領域ポリシーに、"c:\my documents"というディレクトリを登録しておけば、通常プロセスからはc:\ my documentsに自由に読み書きできるディレクトリとして見え、機密プロセスからは、c:\ my documentsは読み込みのみ可能なディレクトリとして見える。従って、通常モードで作成した文書を参照しながら、機密モードで文書を作成する場合などに利用できる。
【０１０９】
次に、本発明の第３の発明を実施するための最良の形態について図面を参照して詳細に説明する。
【０１１０】
図１５は、第３の実施の形態の構成図である。本実施の形態は、本発明の第１の実施の形態に、再共有部１１６を追加したものである。
【０１１１】
再共有部１１６は、多重化部１０４をバイパスして、直接ファイルシステムドライバ１０５にアクセスし、多重化されているファイルを強制的に多重化されていない状態に戻す機能を持つ。具体的には、$sec以下の全てのファイル・ディレクトリと、$mark以下の全てのファイル・ディレクトリを削除する機能を持つ。これにより、機密プロセスがファイル構造に対して行った変更は全てリセットされ、通常プロセスから見えるファイル構造と、機密プロセスから見えるファイル構造は同一のものになる。
【０１１２】
再共有部１１６は、例えば機密モードログオン時・ログオフ時に自動的に実行すればよい。このようにすれば、機密モードログオン中の作業によって作成・変更されたファイルは、ログオフ時に自動的に元に戻ることになる。
【０１１３】
そのため、ユーザから見た作業環境（ファイルの構造、アプリケーションやＯＳの設定など）が、通常モードと機密モードで食い違うことがなくなり、ユーザにとって直感的に動作が分かりやすくなる。その代わり、機密モードで固定ディスクに保存した文書が失われてしまうため、本実施の形態は、固定ディスクに文書を保存する必要が無い場合に適している。例えば、図２に示したようなネットワーク構成上で、機密ファイルサーバ２０１または機密Ｗｅｂサーバ２０３上のファイルを閲覧・更新する業務のみ行う場合に適している。このような場合、固定ディスク上に保存されて多重化されるファイルは、一時ファイルやアプリケーションの設定ファイルなどであり、それらが多重化される前の状態に戻っても大きな問題は生じないためである。
【０１１４】
また、第２の実施の形態に述べた多重化禁止ポリシーを指定しなくても、通常モードでＯＳやアプリケーションにパッチ適用した場合、それは必ず機密モードでも反映されるようになるため、運用性が向上する。
【０１１５】
次に、本発明の第４の発明を実施するための最良の形態について図面を参照して詳細に説明する。図１６は、第４の実施の形態の構成図である。
【０１１６】
本実施の形態は、本発明の第２の実施の形態に、再共有部１１６を追加し、かつ、アクセスポリシー管理部１１５に機密領域ポリシー１１５ｂを含むようにし、アクセス制御部１１４の処理に変更を加えたものである。機密領域ポリシー１１５ｂは、通常プロセスからのアクセスを禁止して多重化を抑止するファイル名またはディレクトリ名のパターンのリストである。
【０１１７】
本実施の形態におけるアクセス制御部１１４の処理の流れを図１７に示す。
【０１１８】
本実施の形態におけるアクセス制御部１１４は、アクセス元のプロセスが機密プロセスでなかった場合、機密領域ポリシー１１５ｂを参照し、機密領域ポリシーにマッチするかどうか調べ（ステップＳ５０６）、マッチする場合はファイルアクセスを禁止する（ステップＳ５０５）という機能を持つ。図１７におけるステップＳ５０２〜ステップＳ５０５の動作は図１４と同様である。
【０１１９】
本実施の形態における、通常領域ポリシーと機密領域ポリシーの例の一部を図１８に示す。
【０１２０】
この例の場合、P101からP103までの通常領域ポリシーにより、機密モードでのOSの構成ファイルへの変更が防止され、P１０４の通常領域ポリシーにより、c:\My Documentsは通常モードではファイルを読み書き可能なフォルダとして使用できるが、機密モードでは読み込みのみ可能なフォルダとなる。そして、P105の機密領域ポリシーにより、c:\My Documents\Secretは、機密モードでは読み書き可能なフォルダとして使用できるが、通常モードでは読み書き不可なフォルダとなる。そして、いずれの領域も、多重化されることはない。
【０１２１】
本実施の形態の効果を、上記の例に即して述べる。
【０１２２】
機密モードでファイルを固定ディスク上に保存する場合は、c:\My Documents\Secretに保存するようにしておけば、このファイルは多重化されることはないので、再共有部１１６が実行されても、c:\My Documents\Secretに保存された機密ファイルは消されることがない。そのため、再共有部１１６によって機密モードと通常モードとの環境の乖離を防ぎつつ、機密ファイルを固定ディスク上に保存したまま、機密ファイルの編集などを行うことが可能になる。
【０１２３】
また、ユーザにはc:\My Documents\Secretは機密ファイルを保存する場所であり、通常モードでは参照不可であることを周知しておく必要があるが、機密プロセスからのc:\My Documentsへのファイル保存はP104の通常領域ポリシーによって禁止されているため、ユーザが機密プロセスから誤ってc:\My Documentsにファイルを保存することはなく、c:\My Documents \Secretに保存することを徹底しやすい。本実施の形態では、ユーザから見た文書保存場所が上記のとおり明確に分離され、それぞれアクセス制限がなされているように見える。ファイルやディレクトリのアクセス制限は、ディレクトリの多重化よりもはるかに良く知られたセキュリティ機能であるため、一般のユーザにも馴染みが深く、より理解しやすいという効果もある。
【０１２４】
次に、本発明の第５の発明を実施するための最良の形態について図面を参照して詳細に説明する。図１９は第５の実施の形態の構成図である。
【０１２５】
本実施の形態は、本発明の第１の実施の形態から一括モード選択部１０７を取り除き、個別モード選択部１１７と、ＩＰＣ制御部１１８を追加したものである。
【０１２６】
個別モード選択部１１７は、プロセスの起動時にそのプロセスを機密プロセスとして起動するか、通常プロセスとして起動するか選択する機能を持つ。例えば、プロセスの起動を検知して「機密」か「通常」かを選択するダイアログを表示するようにしてもよいし、特定のアプリケーションを機密プロセスとして起動するための専用のショートカットを作成しておいてもよい。あるいは、特定の環境変数が設定されて起動されたプロセスは機密プロセスとする、という取り決めをしてもよい。
【０１２７】
個別モード選択部１１７で設定された情報はプロセス単位に保存され、セキュリティレベル判定部１０３から参照される。この情報は、個々のプロセスが持つ環境変数領域に格納してもよいし、OSの管理しているメインメモリ上に対応表の形で格納してもよい。
【０１２８】
IPC制御部１１８は、機密プロセスと通常プロセスの間のプロセス間通信を制限する機能を持つ。
【０１２９】
本発明の第１の実施の形態では、ログオン時に一括モード選択部１０７によって「機密モード」なのか「通常モード」なのかを選択するため、ログオン中に実行中されるプロセスは同じセキュリティレベルで動作しており、プロセス間通信による情報の漏洩は生じない。一方、本実施の形態では、実行中のプロセスは異なるセキュリティレベルで動作する可能性があるので、プロセス間通信による情報の漏洩を防止する機能が必要であり、IPC制御部１１８はその機能を実現する。
【０１３０】
IPC制御部１１８を実装する手段として、例えば、ＯＳで提供されているIPC機能をフックし、IPC機能の動作を変更すればよい。
【０１３１】
例えば、クリップボード経由のコピー＆ペーストによる、機密プロセスから通常プロセスへの情報の漏洩を防止する手段として、アプリケーションから呼び出されるクリップボードコピーAPIと、クリップボードペーストAPIを仲介して、機密プロセスからクリップボードにコピーされた場合、通常プロセスではペーストできないようにすればよい。
【０１３２】
図２０は、クリップボードコピーＡＰＩを仲介したＩＰＣ制御部１１８の処理手順である。まず、クリップボードコピーを呼び出したプロセスのセキュリティレベルをセキュリティレベル判定部１０３に問い合わせる（ステップＳ８０１）。機密プロセスであればクリップボード状態フラグに１を設定し（ステップＳ８０４）、通常プロセスであればクリップボード状態フラグに０を設定する（ステップＳ８０２）。ここで、クリップボード状態フラグは、全てのプロセスから参照可能な共有メモリ上や、カーネルメモリ空間上に配置されたメモリ領域である。その後、クリップボードペーストＡＰＩを実行して（ステップＳ８０３）終了する。
【０１３３】
図２１は、クリップボードペーストＡＰＩを仲介したＩＰＣ制御部１１８の処理手順である。まず、クリップボードペーストを呼び出したプロセスのセキュリティレベルをセキュリティレベル判定部１０３に問い合わせる（ステップＳ６０１）。通常プロセスであればクリップボード状態フラグが０であるかどうか調べ（ステップＳ６０２）、１であればクリップボードペーストＡＰＩを実行せずに終了する（ステップＳ６０３）。それ以外の場合は、クリップボードペーストＡＰＩをそのまま実行する（ステップＳ６０４）。
【０１３４】
以上の手順により、機密プロセス同士、通常プロセス同士、通常プロセスから機密プロセスへのコピー＆ペーストは許可しつつ、機密プロセスから通常プロセスへのコピー＆ペーストは禁止することができる。
【０１３５】
また、共有メモリによって、機密プロセスから通常プロセスへの情報の漏洩を防止する手段として、アプリケーションから呼び出される共有メモリオープン関数（名前を指定して共有メモリを作成する場合と、名前を指定して共有メモリを参照する場合の両方を含む）を仲介して、機密プロセスから作成された共有メモリの名前と、通常プロセスから作成された共有メモリの名前が重ならないようにすればよい。
【０１３６】
図２２は、共有メモリオープンAPIを仲介したIPC制御部１１８の処理手順である。まず、共有メモリオープンを呼び出したプロセスのセキュリティレベルをセキュリティレベル判定部１０３に問い合わせる（Ｓ７０１）。機密プロセスであった場合、オープンが要求された共有メモリの名前の先頭に"$$sec$$"という文字列を付加して（Ｓ７０２）、共有メモリオープンAPI関数を実行する（Ｓ７０３）。通常プロセスであった場合、要求されたそのままの名前で共有メモリオープンAPI関数を実行する。
【０１３７】
以上の手順により、機密プロセスが作成した共有メモリは、機密プロセスからしかアクセスできず、通常プロセスが作成した共有メモリは、通常プロセスからしかアクセスできないため、機密プロセスから通常プロセスに対して、共有メモリを介して情報が漏洩することを防止できる。
【０１３８】
本実施の形態の効果について述べる。
【０１３９】
本実施の形態では、実施の形態１と異なり、プロセス単位で機密モードか通常モードかを選択する個別モード選択部１１７を持ち、プロセス間通信を行うAPI関数を仲介して、プロセス間通信による漏洩を防止する、IPC制御部１１８を持つように構成されているため、ユーザがログオン時に機密モードか通常モードかを選択する必要はなく、アプリケーション起動時に選択すればよいので、ユーザから見た利便性を向上させることができる。
【０１４０】
なお、上述したように、本発明によるシステムはコンピュータシステム上に構築されるものであり、本発明には本発明によるシステムをコンピュータシステム上に構築するプログラムおよび該プログラムを格納するＣＤ−ＲＯＭ、フロッピーディスク、ＤＶＤ−ＲＯＭなどの記録媒体も含まれる。
【産業上の利用可能性】
【０１４１】
本発明によれば、機密ファイルのクライアントコンピュータからの持ち出しを防止する機能を実現するアプリケーションプログラムといった用途に適用できる。また、クライアントコンピュータで動作するOSを、機密ファイルのクライアントコンピュータからの持ち出しを防止するように拡張する機能といった用途にも適用できる。
【図面の簡単な説明】
【０１４２】
【図１】本発明の第１の発明を実施するための最良の形態の構成を示すブロック図である。
【図２】第１の発明が前提とするネットワーク構成図である。
【図３】ネットワークフィルタ部による通信制限の方法を表す図である。
【図４】多重化されたファイル・ディレクトリの実現方法を表す図である。
【図５】多重化される前のファイル構造の一例を示す図である。
【図６】多重化された後のファイル構造の一例を示す図である。
【図７】通常プロセスによるファイルオープンを対象とした多重化部の動作を示す流れ図である。
【図８】機密プロセスによるファイルオープンを対象とした多重化部の動作を示す流れ図である。
【図９】通常プロセスによるディレクトリ一覧取得を対象とした多重化部の動作を示す流れ図である。
【図１０】機密プロセスによるディレクトリ一覧取得を対象とした多重化部の動作を示す流れ図である。
【図１１】多重化されたファイルの情報を保持するための別手段を示す図である。
【図１２】本発明の第２の発明を実施するための最良の形態の構成を示すブロック図である。
【図１３】本発明の第２の発明における、通常領域ポリシーの例を示す図である。
【図１４】本発明の第２の発明における、アクセス制限部の動作を示す流れ図である。
【図１５】本発明の第３の発明を実施するための最良の形態の構成を示すブロック図である。
【図１６】本発明の第４の発明を実施するための最良の形態の構成を示すブロック図である。
【図１７】本発明の第４の発明における、アクセス制限部の動作を示す流れ図である。
【図１８】本発明の第２の発明における、通常領域ポリシーと機密領域ポリシーの例を示す図である。
【図１９】本発明の第５の発明を実施するための最良の形態の構成を示すブロック図である。
【図２０】クリップボードコピー時のIPC制御部の動作を示す流れ図である。
【図２１】クリップボードペースト時のIPC制御部の動作を示す流れ図である。
【図２２】共有メモリオープン時のIPC制御部の動作を示す流れ図である。
【図２３】従来技術２の動作を示す図である。
【図２４】従来技術３の動作を示す図である。
【符号の説明】
【０１４３】
１００    コンピュータ（中央処理装置；プロセッサ；データ処理装置）
１０３    セキュリティレベル判定部
１０４    多重化部
１０４a   ファイル変更判定部
１０４ｂ  ファイル多重化判定部
１０６    固定ディスク装置
１１４    アクセス制御部
１１５    アクセスポリシー管理部
１１６    再共有部
【図１】
0004654963.tif 000002
【図２】
0004654963.tif 000003
【図３】
0004654963.tif 000004
【図４】
0004654963.tif 000005
【図５】
0004654963.tif 000006
【図６】
0004654963.tif 000007
【図７】
0004654963.tif 000008
【図８】
0004654963.tif 000009
【図９】
0004654963.tif 000010
【図１０】
0004654963.tif 000011
【図１１】
0004654963.tif 000012
【図１２】
0004654963.tif 000013
【図１３】
0004654963.tif 000014
【図１４】
0004654963.tif 000015
【図１５】
0004654963.tif 000016
【図１６】
0004654963.tif 000017
【図１７】
0004654963.tif 000018
【図１８】
0004654963.tif 000019
【図１９】
0004654963.tif 000020
【図２０】
0004654963.tif 000021
【図２１】
0004654963.tif 000022
【図２２】
0004654963.tif 000023
【図２３】
0004654963.tif 000024
【図２４】
0004654963.tif 000025