JP5126495B2 - 安全度評価と連動するセキュリティの方針設定装置、そのプログラムおよびその方法 - Google Patents

Description

本発明は、ファイルがコンピュータウイルスに感染していないことあるいは悪意あるコードに改竄されていないことといった安全度について評価済みのファイルのみに実行、読込および書込みの許可を与えることができる、安全度評価と連動するセキュリティの方針設定装置、そのプログラムおよびその方法に関する。

悪意ある利用者やプログラム等に起因する、ファイルの改竄、そして、コンピュータウイルス感染といった被害が増加している。

改竄検知の技術としては、一方向ハッシュ関数を用いてファイルのハッシュ値を予め計算してとっておき、改竄チェックしたいときに再びハッシュ値を計算し、以前のハッシュ値と同じであるかどうか比較するといった方法がよく知られている。

この技術は、改竄されているファイルを検知するのみであり、そのファイルの実行、そのファイルからの読込および書込みといった動作を制限するものではない。

また、コンピュータウイルスに感染したファイルのチェック方法として、コンピュータウイルスとなる不正コードまたは不正データのパターンを集めたウイルス定義ファイル（ウイルスチェックデータとも呼ばれる）を利用する方法がある。ウイルス定義ファイル（ウイルスチェックデータ）と、不正コードのチェック対象となる実行プログラムあるいはデータとのパターンマッチングを行ってコンピュータウイルスを含んでいるか否かを判断する方法である。

この技術は、コンピュータウイルスの感染を検知するのみであり、そのファイルの実行、そのファイルからの読込および書込みといった動作を制限するものではない。

また、ファイルを改竄し、コンピュータウイルスに感染させるようなファイルに対する不正なアクセスを防止する技術として、アプリケーションプログラムのアクセス制御を行う方法がある。

アプリケーションプログラム毎に利用できる機能を規定したセキュリティポリシデータベースを持ち、そのアプリケーションプログラムが利用できるリソースを限定することによりアプリケーションプログラムがアクセス可能なファイルなどのリソースおよび機能のアクセス制御を行う方法である。

このアクセス制御方法の一例が、非特許文献１に記載されている。この方法はＳＥＬｉｎｕｘ（Ｌｉｎｕｘは登録商標。）（Security Enhanced Linux）と呼ばれ注目されている。

情報処理装置［ＰＣ（パーソナルコンピュータ）等］にＳＥＬｉｎｕｘが導入されると、「ＳＥＬｉｎｕｘモジュール」がＬｉｎｕｘカーネルに組み込まれ、「セキュリティ・ポリシー・ファイル」という設定ファイルと、「ＳＥＬｉｎｕｘ拡張コマンド」とが追加される。

プロセスがリソースにアクセスする際には、必ず「ＳＥＬｉｎｕｘモジュール」を経由し、以下に述べるような手続きをとる。（１）プロセスはカーネルに対してリソースへのアクセス要求を出す。（２）カーネルはまず、パーミッションのチェックを行う。ここまでの手続きは通常のＬｉｎｕｘの動作と同じである。（３）次に、リソースへのアクセス要求が「ＳＥＬｉｎｕｘモジュール」に渡される。「ＳＥＬｉｎｕｘモジュール」は「セキュリティ・ポリシー・ファイル」を参照し、アクセスが正当であるか否かをチェックする。その際、ＳＥＬｉｎｕｘ独自のアクセス制御が行われる。（４）アクセスが正当である場合、プロセスはリソースにアクセスする。

この技術では、アクセス制御対象となるファイルが正しいものであることをある程度前提にして、そのファイルの実行、そのファイルからの読込および書込みといった動作を制限している。そのため、新たにダウンロードしたファイルなどのように正しいファイルか不正なファイルかわからないようなファイルを扱う場合、どのようなアクセス制御ルールを設定しておけばよいか不明である。また、どのようなセキュリティの方針を示すセキュリティポリシデータ（セキュリティ・ポリシー・ファイル）を設定しておけばよいか不明である。

セキュリティポリシデータの設定に関して以下に示すような、セキュリティの方針設定装置が存在している。

従来のセキュリティの方針設定装置の一例が、特許文献１に記載されている。この特許文献では、情報家電、ＰＣ等のさまざまな情報処理装置に搭載するアクセス制御ルールの生成において、プログラム実行トレースによって各リソースのアクセス履歴情報を取得する。またそれとともに、ディレクトリの同一性、種別同一性、カテゴリ同一のネットワークポートなどの情報等のリソース関連性に基づいて、プログラム実行時の各リソースに対するアクセス有無を類推する。更に、アクセス制御ルールの適用プログラム、ユーザ、機器等の使用環境に応じてバランス設定した効用関数を設定する。設定する効用関数としては、具体的には、フォールスポジティブおよびフォールスネガティブのバランスを調整した効用関数を適用してベイズ推定に基づくアクセス制御ルールを設定する。

従来のセキュリティの方針設定装置の一例が、特許文献２に記載されている。
この特許文献では、ポリシ決定処理部は、利用者情報取得処理部がクライアント端末からのアクセス情報や利用者管理装置にて管理される情報から取得した利用者属性情報や、クライアントプロパティ情報取得処理部がクライアント端末から送られる情報や利用者管理装置にて管理される情報から取得したクライアントプロパティ情報、あるいは、情報システムにて実行すべき処理の内容などから、情報システムの設定を行うために必要となるポリシ情報を決定する。システム設定作成処理部は、ポリシ判断処理部の各構成より提供された情報から、情報システムを構成する各機器の設定内容を示す機器設定情報を作成する。

従来のセキュリティの方針設定装置の一例が、特許文献３に記載されている。この特許文献では、ソフトウェアの種類毎のポリシを記述したサンプル情報と、オブジェクトの種類毎に利用頻度の高いプログラムの情報を記述した関連付け情報と、プログラムの動作を監視して記録したアクセスログ情報のいずれかを用いてポリシの原案を作成するポリシ生成部を備える。そして、ポリシ原案を表示して、利用者による確認と編集を可能とするユーザインタフェース部の処理により、適切なポリシ設定に必要な作業の簡易化を実現する。また差分検出部により、設定済みポリシから更新すべき部分を、現在のオブジェクトとサブジェクト情報を参照して検出し、ユーザインタフェース部を通じて提示するとともに、簡易に更新可能とすることで、適切なポリシ維持も可能とする。

従来のセキュリティの方針設定装置の一例が、特許文献４に記載されている。この特許文献では、ソースコードまたはモデリング図から、ターゲットのオペレーティングシステム（ＯＳ）と強制アクセス制御の実装形態に依存しない第１の中間表記を生成する。また、第１の中間表記の生成に際し、あるアクセス関係についてはセキュリティポリシ内で設定するアクセス権限が複数候補挙げられる場合にはユーザに候補のアクセス権限を提示することによりそのアクセス関係のアクセス権限を解決する。更に、第１の中間表記に基づき、ターゲットのＯＳと強制アクセス制御の実装形態の情報からターゲットのディレクトリ構造に依存しない第２の中間表記を生成し、第２の中間表記に基づき、ターゲットのディレクトリ構造の情報からセキュリティポリシを生成する。

従来のセキュリティの方針設定装置一例が、特許文献５に記載されている。この特許文献では、セキュリティポリシ設定対象のリソースに対して異なるタイプを付与する第１のステップを備える。また、当該第１のステップでのタイプ付与環境において特定のプログラムを１ないし複数回実行させて各リソースへのアクセスログをログ情報記憶手段に蓄積する第２のステップ備える。また、蓄積したアクセスログに基づき同一ドメインと同一タイプに関するアクセスベクターを１つのアクセスベクターに集約すると共に、ドメイン名とリソースの種類およびアクセスベクターの関係から、集約可能なタイプを判別し、タイプの集約を行い、集約結果を前記セキュアＯＳのセキュリティポリシとしてセキュリティポリシ記憶手段に格納する第３のステップとを備える。
「ＳＥＬｉｎｕｘ徹底ガイド」（中村雄一、水上友宏、上野修一著、日経ＢＰ社、２００４年３月、ｐｐ．２４〜４１、ｐ．８７、８８） 特開２００５−０４４２４３号公報 特開２００６−１８４９３６号公報 特開２００４−１９２６０１号公報 特開２００５−０６３２２４号公報 特開２００７−１３３６３２号公報

情報処理装置上で、ウイルスチェックなどのファイルチェックを実施する前のアプリケーションプログラムを実行することは危険である。また、アプリケーションプログラムであるファイルの改竄およびウイルスチェックなどの安全度評価により、アプリケーションプログラムの安全性が確認できたファイルについて、再び安全度評価することは冗長な処理となり無駄に電力および計算機資源を消費する。

特許文献１に記載の方法の問題点は、プログラム実行トレースによって各リソースのアクセス履歴情報を取得し、その履歴情報からアクセス制御ルールを決定することが可能となる。しかし、稼働中の情報処理装置に任意のサーバからダウンロードしてきたアプリケーションプログラムは、不正コードを含んでいる可能性もあり、実行履歴をとることは危険である。このため、ダウンロードしてきたアプリケーションプログラムに関して特許文献１の方法を利用したアクセス制御ルールの決定では、危険性を排除できない。

特許文献２に記載の方法の問題点は、利用者属性情報、クライアントプロパティ情報、実行すべき処理内容からポリシを決定するが、稼働中の情報処理装置に任意のサーバからダウンロードしてきたアプリケーションプログラムが不正コードを含んでいるかどうかの判断は行っておらず危険である。また、ダウンロードしてきたアプリケーションプログラムには処理内容は不明な場合が多い。このため、ダウンロードしてきたアプリケーションプログラムに関して特許文献２の方法を利用したポリシ決定では、危険性を排除できない。

特許文献３に記載の方法の問題点は、ソフトウェアの種類毎のポリシを記述したサンプル情報と、オブジェクトの種類毎に利用頻度の高いプログラムの情報を記述した関連付け情報と、プログラムの動作を監視して記録したアクセスログ情報のいずれかを用いてポリシの原案を作成することが可能である。しかし、稼働中の情報処理装置に任意のサーバからダウンロードしてきたアプリケーションプログラムがどのような種類のソフトウェアまたはオブジェクトなのかは不明な場合が多く、また、偽る可能性もある。更に、ダウンロードしてきたアプリケーションプログラムには不正コードを含んでいる場合もあり、そのプログラムを動作させてアクセスログを収集することは危険である。このため、ダウンロードしてきたアプリケーションプログラムに関して特許文献３の方法を利用したポリシ作成は有効ではない。

特許文献４に記載の方法の問題点は、ソースコードまたはモデリング図をもとにしてセキュリティポリシを生成することができるが、稼働中の情報処理装置に任意のサーバからダウンロードしてきたアプリケーションプログラムには、ソースコードまたはモデリング図といった情報はない。このため、ダウンロードしてきたアプリケーションプログラムに関して特許文献４の方法を利用したポリシ生成はできない。

特許文献５の問題点は、プログラムを１ないし複数回実行させて各リソースへのアクセスログを収集し、そのログをもとにしてセキュリティポリシを決定することが可能となる。しかし、稼働中の情報処理装置に任意のサーバからダウンロードしてきたアプリケーションプログラムは、不正コードを含んでいる可能性もあり、実行させてログをとることは危険である。このため、ダウンロードしてきたアプリケーションプログラムに関して特許文献５の方法を利用したアクセス制御ルールの決定では、危険性を排除できない。

そこで、本発明は、ファイルの改竄あるいはコンピュータウイルス感染がないといったことを確認する安全度評価前のファイルに対しては、実行禁止および他のアプリケーションプログラムからファイルへのアクセスを禁止し、安全度評価済のファイルに対しては、実行許可および他のアプリケーションプログラムからファイルへのアクセス許可を与える実行制御およびアクセス制御を可能とする、安全度評価と連携したセキュリティの方針設定装置、そのプログラムおよびその方法を提供することを目的とする。

本発明の第１の観点によれば装置として、セキュリティの方針を設定する情報処理装置において、セキュリティの方針を設定する対象となるファイルの安全性を確認する安全度評価手段と、前記ファイルの種別を確認する種別確認手段と、前記安全度評価手段における安全度評価の結果、安全であると判断した場合、ファイル種別に応じてセキュリティの方針を決定する方針決定手段と、前記決定したセキュリティの方針を、前記ファイルのセキュリティの方針として設定する方針設定手段と、当該情報処理装置上のそれぞれのファイルについて既に前記安全度評価手段における安全性の確認を行ったか否かを示すリストと、前記安全性の確認を行ったファイルを、前記リストに記載するリスト記載手段と、前記リストに記載されているファイルについては、前記安全度評価手段の対象から除外する手段と、を備え、前記リスト記載手段は、前記安全性の確認を行ったファイルであっても、該ファイルに設定したセキュリティの方針に、該ファイルに対する書き込みを許可する旨が含まれている場合は該ファイルをリストに記載しないことを特徴とする情報処理装置が提供される。

本発明の第２の観点によれば方法として、セキュリティの方針を設定する情報処理方法において、セキュリティの方針を設定する対象となるファイルの安全性を確認する安全度評価ステップと、前記ファイルの種別を確認する種別確認ステップと、前記安全度評価ステップにおける安全度評価の結果、安全であると判断した場合、ファイル種別に応じてセキュリティの方針を決定する方針決定ステップと、前記決定したセキュリティの方針を、前記ファイルのセキュリティの方針として設定する方針設定ステップと、情報処理装置上のそれぞれのファイルについて既に前記安全度評価手段における安全性の確認を行ったか否かを示すリストを用意するステップと、前記安全性の確認を行ったファイルを、前記リストに記載するリスト記載ステップと、前記リストに記載されているファイルについては、前記安全度評価手段の対象から除外するステップと、を備え、前記リスト記載ステップでは、前記安全性の確認を行ったファイルであっても、該ファイルに設定したセキュリティの方針に、該ファイルに対する書き込みを許可する旨が含まれている場合は該ファイルをリストに記載しないことを特徴とする情報処理方法が提供される。

本発明の第３の観点によればプログラムとして、セキュリティの方針を設定する情報処理プログラムにおいて、コンピュータを、セキュリティの方針を設定する対象となるファイルの安全性を確認する安全度評価手段と、前記ファイルの種別を確認する種別確認手段と、前記安全度評価機能における安全度評価の結果、安全であると判断した場合、ファイル種別に応じてセキュリティの方針を決定する方針決定手段と、前記決定したセキュリティの方針を、前記ファイルのセキュリティの方針として設定する方針設定手段と、当該情報処理装置上のそれぞれのファイルについて既に前記安全度評価手段における安全性の確認を行ったか否かを示すリストを用意すると、前記安全性の確認を行ったファイルを、前記リストに記載するリスト記載手段と、前記リストに記載されているファイルについては、前記安全度評価手段の対象から除外する手段と、を備え、前記リスト記載手段は、前記安全性の確認を行ったファイルであっても、該ファイルに設定したセキュリティの方針に、該ファイルに対する書き込みを許可する旨が含まれている場合は該ファイルをリストに記載しない情報処理装置として機能させることを特徴とする情報処理プログラムが提供される。

本発明によれば、安全度評価を実施し、その結果が安全であると判断された場合のみセキュリティポリシデータを更新可能としていることから実行可能なファイルについてのセキュリティポリシデータを自動的に作成する場合、そのファイルを実行することなくセキュリティポリシデータを作成することが可能となる。

［本発明の第１の実施の形態］
次に、発明を実施するための最良の形態について図面を参照して詳細に説明する。

図１を参照すると、本発明の第１の実施の形態は、情報処理装置１を備える。

情報処理装置１は、ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、ＨＤＤ１０４、外部メモリ１０５、出力装置１０６、通信装置１０７、入力装置１０８、ＯＳ処理手段１０９、ファイル１１０、アクセス制御手段１１１、ポリシ変更手段１１２、ポリシ決定手段１１３、安全度評価手段１１４及びファイル情報獲得手段１１５を備える。

これらの手段、装置はそれぞれ概略つぎのように動作する。

ＣＰＵ１０１は、セントラル・プロセッシング・ユニットであり、各手段やプログラムの実行を制御し、計算処理を行う。

ＲＡＭ１０２は、ランダム・アクセス・メモリであり、読書き可能な記憶装置である。各手段やプログラムの実行時に使用されるデータを読書きする場合に一時的な記憶領域となる。また、実行コードそのものを一時的に記憶する場合もある。

ＲＯＭ１０３は、リード・オンリー・メモリであり、読込みのみ可能な記憶装置である。各手段やプログラムの実行コード、データなどを記憶する。情報処理装置１の電源をＯＦＦとした場合であっても、ＲＯＭ１０３に記憶されている実行コードおよびデータは消えない。

ＨＤＤ１０４は、ハード・ディスク・ドライブであり、読書き可能な記憶装置である。ＲＡＭ１０２と比べて読み込みおよび書き込みの処理速度は遅いが、大容量であり、情報処理装置１の電源をＯＦＦしても記憶されている実行コードおよびデータは消えない。

外部メモリ１０５は、情報処理装置１に脱着可能な読書き可能な記憶装置である。実行コードやデータなどのファイル１１０を外部メモリ１０５に記憶させ、情報処理装置１に装着することで情報処理装置１に実行コードやデータを追加する。

出力装置１０６は、情報処理装置１で実行された処理結果を出力する。具体的にはディスプレイに表示したり、スピーカ等から音声出力したりする。

通信装置１０７は、ファイル１１０などの実行コードやデータを外部と通信して情報処理装置１に取り込む。

入力装置１０８は、新たな処理の実行を依頼するためのキー（ボタン）、音声などにより、情報を情報処理装置１に取り込む。

ＯＳ処理手段１０９は、ＯＳ（オペレーティングシステム）が行う処理であり、実行コードを含むファイル１１０から生成されるプロセスが呼び出すシステムコールの処理を行う。また、ＣＰＵ１０１などの資源を管理している。

ファイル１１０は、アプリケーションプログラムである実行コード、ライブラリ、ユーザデータなどを含む。なお、ファイル１１０は図１において一つのみ図示されているが、本実施形態では複数存在しているものとする。

アクセス制御手段１１１は、実行コードを含むファイル１１０からプロセス生成されることを許可するという実行制御を行う。また、プロセスが情報処理装置１内の他のファイル１１０や様々な機能といった計算機資源へアクセスする際に、アクセス制限を行う。

実行制御およびアクセス制御の方式としては、ＤＡＣ（任意アクセス制御：Discretionary Access Control）、ＭＡＣ（強制アクセス制御：Mandatory Access Control）あるいはＡＣＬ（Access Control List）等が例示できる。また、例示した方式以外のその他の方式であってもよい。

アクセス制御を実施する場合に、制御の方針が記述されているセキュリティポリシデータの記述方法は、アクセス可能なあるいはアクセス不可能なファイル一覧をその資源の場所をパス名で示すものでもよい。また、セキュリティ的な属性を示すためにその資源に対して付与するラベルにより、アクセス制御のためのセキュリティポリシデータを記述するといった、ＳＥＬｉｎｕｘが採用しているラベルベースのものでもよい。

更に、アクセス制御手段１１１は、どのファイル１１０に対して実行制御するのか、また、プロセスに対してどのような資源に関してアクセス制御をするのかといったセキュリティポリシデータを保持している。

ここで、セキュリティポリシとは、どの情報を誰が読み取れるようにするか、どの操作を誰に対して許可するかなど、情報の目的外利用や外部からの侵入、機密漏洩などを防止するための方針を定めたものである。そのデータをセキュリティポリシデータという。以降の説明で使用するセキュリティポリシという言葉は、セキュリティポリシおよびセキュリティポリシデータの両方を意味する。

ポリシ変更手段１１２は、アクセス制御手段１１１が保持しているセキュリティポリシの、それぞれのファイル１１０ごとについて、実行可否、読み込み可否、書き込み可否といった情報の変更を行う。

ポリシ決定手段１１３は、ファイル１１０について実行可否、読み込み可否、書き込み可否といったポリシを決定する。

安全度評価手段１１４は、ファイル１１０ついてウイルス感染していないか、改竄されていないかといった評価を行う。

ファイル情報獲得手段１１５は、安全度評価したファイル１１０について情報処理装置１のなかで一意に識別可能な識別子を獲得する。また、ファイル１１０が実行可能ファイルなのか、データファイルなのかといった情報も獲得する。

次に本実施の形態の動作について詳細に説明する。

アクセス制御手段１１１の制御方法としては２つの方法が考えられる。ひとつは、実行制御およびアクセス制御といった情報が、該当するファイル１１０についてのセキュリティポリシデータの情報として存在しない場合は実行、書き込み、読み込みなどすべて禁止するという方法である。また、もうひとつは実行、書き込み、読み込みなどに対しての可否をすべてセキュリティポリシデータとして保持するという方法である。本実施の形態では、後者の方で説明する。

まず、前処理として、すべてのファイル１１０に対して実行、書き込み、読み込みなどのすべてを禁止としておく。ただし、安全度評価手段１１４からの書き込みおよび読み込み、あるいは、読み込みのみ許可しておく。この前処理を実施した結果、できあがるセキュリティポリシデータを図２に示す。図２を見ると、情報処理端末１に存在しているファイル１１０は、ファイルＡ〜ファイルＤであり、それぞれのファイルの実行、プロセスからそれぞれのファイルに対しての読み込みおよび書き込みが禁止されていることがわかる。

次に、ファイル１１０に対する安全度評価からセキュリティポリシを変更するまでの処理をフローチャートとして図３に示す。

まず、安全度評価を実施すべきかどうかを安全度評価手段１１４が保持しているリストを参照して確認する。このリストには、すでに安全度評価を実施済みのファイル１１０を示す情報が含まれている。

これから安全度評価をうけるファイル１１０がこのリストに含まれている場合、そのファイル１１０は既に安全度評価を受けていることになるためステップＡ２に進まずに処理を終了する。一方、リストに含まれていない場合はステップＡ２に進む。（ステップＡ１）
次にファイル１１０に対して安全度評価手段１１４が安全度評価を実施する。この安全度評価は、ウイルスチェック、改竄チェック、証明書チェック、また、不正動作を可能とする実行コードがないか確認する脆弱性チェックやバイナリチェックあるいはこれら例示したものと別のチェックのうちいずれか１つ、２つ以上での組み合わせ、あるいはすべてのチェックが実施される。これらチェック方法についての一例を以下に説明する。

ウイルスチェックの方法の一例として、ウイルス定義ファイルとファイル１１０の内容とをパターンマッチングしてコンピュータウイルスに感染していないか確認する。

また、改竄チェックの方法の一例として、ファイル１１０にデジタル署名が関連付けられており、そのデジタル署名を確認する方法がある。デジタル署名の形式としては、例えばＳＨＡ−１（Secure Hash Algorithm 1）等のハッシュアルゴリズムを利用したファイルのハッシュデータを、ファイル１１０の配布者が保持している秘密鍵によって暗号化したものを署名データとして利用するといった手法が広く使われている。再度ハッシュ値を計算し、予め用意されていたハッシュ値と等しければ改竄されていないと判断することができる。

また、証明書チェックでは、ファイル１１０に関連付けられたデジタル証明書を確認し、そのファイル１１０の素性を確認することが可能となる。デジタル証明書の形式としては、例えばＸ．５０９形式が広く利用されている。デジタル証明書を利用することで、信頼できる認証機関によってファイル１１０の正当性が保証されることになる。

脆弱性チェックやバイナリチェックの例としては、バッファーオーバーフロー、スタックオーバーフローなどが発生する実行コードを含んでいないかを、実行コードを解析することで判断する手法などが挙げられる。

この安全度評価がウイルスチェック、改竄チェック、証明書チェック、不正動作を可能とする実行コードがないか確認する脆弱性チェックやバイナリチェックあるいは別のチェックのいずれか１つが実施される場合、その結果がＯＫであればステップＡ３に進み、ＮＧであれば終了する。また、２つ以上のチェックが実施されるのであれば、そのすべてのチェック結果がＯＫであればステップＡ３に進み、どれか１つでもＮＧであれば処理を終了する。（ステップＡ２）
安全度評価のチェック結果がＯＫで安全なファイルであるということが確認できた後、安全度評価がＯＫとなったファイル１１０に対して、ファイル情報獲得手段１１４は、ＯＳ処理手段１０９からファイル情報を獲得する。この時獲得する情報は、ファイル１１０を一意に識別可能な情報である。たとえば、ファイル１１０の配置場所（パス）やＬｉｎｕｘなどのＵＮＩＸ（登録商標）系ＯＳでは、ｉノード情報などである。

また、ファイル情報獲得手段１１４は、ファイル１１０が実行ファイルなのか、データファイルなのかを判断する。この判断方法としては、ＵＮＩＸ（登録商標）系ＯＳではファイルパーミッションを参照することが考えられる。また、ファイルの形式により判断することも可能である。たとえば、実行可能なファイルの形式である、ＥＬＦ（Executable and Linking Format）形式であれば、ファイルヘッダ（ファイルの先頭部分）にＥＬＦ形式であることを示す識別子が埋め込まれている。そのため、その識別子が確認できれば実行可能ファイルであることが判断できる。また、ファイル内容を直接解析し、ＣＰＵ１０１で実行可能な命令列を含んでいるか確認し、命令列を含んでいれば実行可能なファイルであると判断できる。一方、実行可能なファイルでなければデータファイルであると判断できる。（ステップＡ３）
ファイル１１０が実行可能なファイルあるいはデータファイルと判断されたあと、その種類に応じてセキュリティの方針を決定する。たとえば、実行可能なファイルであれば、実行許可および他プロセスからの読み込み許可を与える。また、データファイルであれば他ファイルからの読み込み許可と書き込み許可を与える。なお、ファイル１１０が実行可能なファイルあるいはデータファイルであるかといった種別ごとにどんな許可を与えるかといった方針は予め決定しておき、ポリシ決定手段１１３が保持しているものとする。（ステップＡ４）
次に、実行可能なファイルあるいはデータファイルであるファイル１１０について、セキュリティポリシデータの変更を実施する。ステップＡ３で獲得したファイル１１０を一意に識別可能な識別子と、ステップＡ４で決定した、実行、書き込み、読み込みなどについて何を許可するかといった情報を関連付け、それらの情報に基づいてアクセス制御手段１１１が保持しているセキュリティポリシデータを更新する。（ステップＡ５）
最後に、上述した安全度評価手段１１４が保持している安全度評価を実施しているかどうかといったことを示すリストに、安全度評価を実施したことを示す情報を追記する。

ただし、データファイルに書き込み許可を与えると決定する場合は、場合によっては上記の追記をせずに安全度評価を未実施としてもよい。これは、現在は安全なデータファイルであったとしても書き込み許可がなされている以上、データファイルが書き換えられる可能性があるためである。すなわち、もしウイルスチェックのような安全度評価方法であれば、再度ウイルスチェックを実施した方が安全である場合も考えられるからである。（ステップＡ６）
図２に示したセキュリティポリシデータのファイルＡおよびファイルＢについて上記のステップＡ１からステップＡ６までを実施した後のセキュリティポリシデータを図４に示す。ファイルＣおよびファイルＤについては何も処理されていないものとする。ステップＡ３でファイルＡは実行可能なファイルで、ファイルＢはデータファイルであると判断されている。また、ステップＡ４で実行可能ファイルには実行許可とプロセスからの読み込みが許可され、データファイルにはプロセスから読み込みおよび書き込み許可が与えられている。

つまり、ステップＡ１からステップＡ６までの処理を実施していない状態では、図２に示すセキュリティポリシがアクセス制御手段１１１に適用される。そのため、いずれかのファイルを実行する、プロセスからそれらファイルに書き込みまたは読み込みしようとするとアクセス制御手段１１１により拒否されてエラーとなる。

しかし、ファイルＡおよびファイルＢについて、ステップＡ１からステップＡ６までの処理を実施した場合、図４に示すセキュリティポリシがアクセス制御手段１１１に適用される。そのため、ファイルＡの実行及びプロセスからファイルＢへの書き込みおよび読み込みに関しては、アクセス制御手段１１１が許可し、正常に処理が実施される。

なお、図１記載のブロック図の各手段は、アクセス制御手段がＯＳ内で動作し、それ以外はＯＳ外で動作するといった構成でもよいし、アクセス制御手段以外のいずれか１つがＯＳ内で動作し、それ以外はＯＳ外で動作するといった構成でもよいし、すべての手段がＯＳ外で動作してもよい。

次に本実施の形態の効果について説明する。本実施の形態では、実行可能なファイルについてのセキュリティポリシを自動的に作成する場合、そのファイルを実行することなくセキュリティポリシを作成することが可能である。これは、ウイルスチェック、改竄チェック、証明書チェック、またはその他のチェックによる安全度評価を実施し、その結果が安全であると判断された場合のみセキュリティポリシを更新可能としているからである。

本実施の形態の他の効果について説明する。安全性が確認できたファイルについて、再び安全度評価するといった冗長な処理による無駄な電力の消費はない。これは、安全度評価により安全であると確認されていないファイルの実行およびそれらファイルへのアクセスはすべて禁止されるが、安全度評価により安全であると確認されたファイルに関して、実行可能であれば実行許可を与え、データファイルであれば、プロセスからの読み込み書き込みを与えるというように、ファイルの種類に応じて必要最低限の許可を与えるようにセキュリティポリシを書き換えることが可能なためである。たとえば、実行可能ファイルであれば、書き込みは禁止したままで、実行許可を与える。

［本発明の第２の実施形態］
次に、第２の実施形態について図面を参照して説明する。第２の実施形態では、安全度評価手段１１４により評価されていないファイル１１０を見つける手段が追加されている点が第１の実施形態と異なる。

図５に第２の実施形態の構成を示す。第１実施形態の構成を示す図１と比べると図５では、ファイル検知手段１１６が追加されている。

第１の実施形態の構成に存在する手段は第２の実施形態でも同様の機能を有しているため説明を省略する。ここでは、追加されているファイル通知手段１１６について以下で説明する。

ファイル検知手段１１６は、評価がされていないファイル１１０を検知した場合に、安全度評価手段１１４に通知をする。具体的には、通知ファイル１１０が生成された、情報処理装置１の外から通信装置１０７を使用してダウンロードされた、あるいは、着脱可能な外部メモリ１０５が装着されることで得られたといったことを安全度評価手段１１４に通知する。

次に第２の実施形態の動作について説明する。第２の実施形態の動作を示すフローチャートを図６に示す。

ファイル検知手段１１６は、安全度評価手段１１４により評価されていないファイル１１０を見つけだす。

ファイル検知手段１１６が情報処理装置１にファイルが追加されるタイミングで検知する方法として、プロセスから発行されるＯＳ処理手段１０９のシステムコールを監視するといったものがある。この監視方法としては、システムコールテーブルをフックする方法やＬｉｎｕｘであればＬＳＭ（Linux Security Module）Ｉ／Ｆなどを利用した方法、さらに、システムコール内に独自フックを追加する方法が知られている。新たなファイル１１０がｏｐｅｎおよびｃｌｏｓｅシステムコールにより作成されると、その旨を安全度評価手段１１４に通知する。

ファイル１１０がダウンロードされた場合もシステムコールフック、ＬＳＭ Ｉ／Ｆ、独自フックにより同様に検知可能である。

また、着脱可能な外部メモリ１０５が装着された場合も、システムコールフック、ＬＳＭ Ｉ／Ｆ、独自フックによりｍｏｕｎｔシステムコールを監視し、ｍｏｕｎｔされたファイルシステムをサーチすることでファイル１１０の検知が可能である。ファイル１１０を識別する情報としては、例えばシステムコールフック、ＬＳＭ Ｉ／Ｆ、独自フックした時に渡される情報（ファイルパス、ｉノード番号など）を利用する。

また、情報処理装置１にファイル１１０が使用されるタイミングで検知する方法としても、上記のシステムコールテーブルをフックする方法やＬｉｎｕｘであればＬＳＭ Ｉ／Ｆなどを利用した方法、さらに、システムコール内に独自フックを追加する方法が利用可能である。ファイル１１０を実行する場合、ｅｘｅｃシステムコールが発行されたことを検知してその旨を安全度評価手段１１４に通知する。ファイル１１０がライブラリであった場合でも、Ｌｉｎｕｘであれば、あるプロセス起動時にライブラリがロードされる。このタイミングに独自フックを埋め込んでおくか、ＬＳＭ Ｉ／Ｆを利用することで、検知可能である。デバイスドライバのロードの検知方法としては、Ｌｉｎｕｘの場合、ｉｎｓｍｏｄコマンドによりカーネル内にロードするタイミングで上記と同様の検知方法で可能となる（ステップＢ１）。

第２の実施形態の動作であるステップＢ２からステップＢ７は、第１の実施形態の動作であるステップＡ１からステップＡ６までと同じであるため説明を省略する。

なお、ファイル削除、ライブラリのアンロード、デバイスドライバのアンロード、着脱可能な外部メモリ１０５がはずされた場合もシステムコールフック、ＬＳＭ Ｉ／Ｆ、独自フックにより同様に検知可能である。この場合も安全度評価手段１１４にファイル１１０が削除されたことが通知され、安全度評価手段１１４が保持しているリストからそのファイル１１０の情報を削除することが可能となる。

次に本実施の形態の効果について説明する。本実施の形態では、新規追加されたファイルのみを対象としてセキュリティポリシを作成することが可能である。これは、生成されたファイル、ダウンロードされたファイル、マウントされたファイルシステム上のファイルなど情報処理装置１上のファイルの状態を監視しているからである。

本実施形態の他の効果について説明する。本実施の形態では、セキュリティポリシの変更がされていなかったファイルのみを対象としてセキュリティポリシを作成することが可能である。これは、ライブラリ、デバイドライバを含んだ実行可能なファイルであれば、それがＯＳにロードされるタイミングを監視しているからである。また、データファイルであっても、ｏｐｅｎシステムコールなどそのファイルにアクセスするタイミングを監視しているからである。

［本発明の第３の実施形態］
次に、第３の実施形態について図面を参照して説明する。第３の実施形態の構成を図７に示す。第３の実施形態では、安全度評価手段１１４がファイル１１０を評価するときに利用するデータが更新された場合の動作が新たに追加される。図７と第１の実施形態について示された図１とを比較すると、定義データ更新手段１１７が追加されている点が異なる。この定義データ更新手段１１７について以下に説明する。

定義データ更新手段１１７は、安全度評価手段１１４がファイル１１０を評価するために必要となる定義データを更新する。たとえば、安全度評価手段１１４がウイルスチェックを行う機能を備えていれば、そのウイルスチェックを実施する際に必要となるウイルス定義ファイルを更新する仕組みが定義データ更新手段１１７である。

次に第３の実施形態の動作について説明する。

本発明の第３の実施形態の動作を示すフローチャートを図８に示す。

まず、定義データ更新手段１１７は安全度評価手段１１４がファイル１１０を評価するために必要となる定義データを更新すると、更新した旨を安全度評価手段１１４に通知する。なお、ここでの定義データの更新とは、定義データの追加、書き換え等を示す（ステップＣ１）。

安全度評価手段１１４は、自身が保持している安全度評価を実施すべきかどうかを示すリストに対して、再度安全度評価を実施しなければいけないという情報に書き換える。安全度評価済みリストであれば、すべての情報を削除する。（ステップＣ２）
このリストからファイル情報を削除する前にそのファイル情報を獲得する（ステップＣ３）
ファイル情報とそのファイル１１０についてのセキュリティポリシを書き換える。安全度評価を再度行う必要があるファイル１１０は、実行、書き込み、読み込みといったあらゆる操作を禁止にする。これは、既存のファイル１１０に新たに発見された脅威が存在するかもしれないと判断したためである。すべてのファイル１１０について禁止にしたセキュリティポリシの一例を図２に示す。（ステップＣ４）
次に本実施の形態の効果について説明する。本実施の形態では、新たに発見された脅威に対してファイルの安全性を確保可能である。これは、安全度評価手段が保持する評価基準となる定義データが更新された場合、新たに発見された脅威がファイルに存在するかもしれないと判断し、情報処理装置上のファイルを再度安全度評価するまですべての権限を無効化することが可能であるからである。

上述した本発明の実施形態は以下の効果を奏する。

第１の効果は、実行可能なファイルについてのセキュリティポリシデータを自動的に作成する場合、そのファイルを実行することなくセキュリティポリシデータを作成できることにある。その理由は、ウイルスチェック、改竄チェック、証明書チェック、脆弱性チェック、バイナリチェックまたはその他のチェックによる安全度評価を実施し、その結果が安全であると判断された場合のみセキュリティポリシデータを更新可能としているからである。

第２の効果は、安全性が確認できたファイルについて、再び安全度評価するといった冗長な処理による無駄な電力の消費が発生しないことにある。その理由は、安全度評価により安全であると確認されていないファイルの実行およびそれらファイルへのアクセスはすべて禁止されるためである。また、安全度評価により安全であると確認されたファイルに関して、実行可能であれば実行許可を与え、データファイルであれば、プロセスからの読み込み書き込みを与えるというように、ファイルの種類に応じて必要最低限の許可を与えるようにセキュリティポリシデータを書き換えることが可能なためである。たとえば、実行可能ファイルであれば、書き込みは禁止したままで、実行許可を与えているためである。

第３の効果は、新規追加されたファイルのみを対象としてセキュリティポリシデータを作成できることにある。その理由は、生成されたファイル、ダウンロードされたファイル、マウントされたファイルシステム上のファイルなどの情報処理装置上のファイルの状態を監視しているためである。

第４の効果は、セキュリティポリシデータについて変更されていなかったファイルのみを対象としてセキュリティポリシデータを作成できることにある。その理由は、ライブラリ、デバイドライバを含んだ実行可能なファイルであれば、それらがＯＳにロードされるタイミングを監視しているからである。また、データファイルであっても、ｏｐｅｎシステムコールなどそのファイルにアクセスするタイミングを監視しているためである。

第５の効果は、新たに発見された脅威に対してファイルの安全性を確保できることにある。その理由は、安全度評価手段が保持する評価基準となる定義データが更新された場合、新たに発見された脅威がファイルに存在するかもしれないと判断し、情報処理装置上のファイルを再度安全度評価するまですべての権限を無効化することを可能としているからである。

第６の効果は、安全度評価や、セキュリティポリシデータの自動的な作成を、ファイルを単位として、ファイルごとに別個に実行することが可能な点である。

これにより、安全度評価を既に行ったファイルであっても、他の全てのファイルの安全度評価を行うまでは、セキュリティポリシデータの作成を行えない、というような問題を解消することが可能となる。

なお、安全度評価と連動するセキュリティの方針設定装置は、ハードウェア、ソフトウェア又はこれらの組合せにより実現することができる。

本発明によれば、アクセス制御に使用するセキュリティポリシデータが動的に作成するといった用途に適用できる。

本発明の第１の実施形態の構成を示すブロック図である。 本発明の第１の実施形態及び第３の実施形態のセキュリティポリシの具体例を示す図である。 本発明の第１の実施形態のセキュリティポリシを更新する流れ図である。 本発明の第１の実施形態のセキュリティポリシの具体例を示す図である。 本発明の第２の実施形態の構成を示すブロック図である。 本発明の第２の実施形態のセキュリティポリシを更新する流れ図である。 本発明の第３の実施形態の構成を示すブロック図である。 本発明の第３の実施形態のセキュリティポリシを更新する流れ図である。

符号の説明

１ 情報処理装置
１０１ ＣＰＵ
１０２ ＲＡＭ
１０３ ＲＯＭ
１０４ ＨＤＤ
１０５ 外部メモリ
１０６ 出力装置
１０７ 通信装置
１０８ 入力装置
１０９ ＯＳ処理手段
１１０ ファイル
１１１ アクセス制御手段
１１２ ポリシ変更手段
１１３ ポリシ決定手段
１１４ 安全度評価手段
１１５ ファイル情報獲得手段
１１６ ファイル検知手段
１１７ 定義データ更新手段

Claims (24)

1. セキュリティの方針を設定する情報処理装置において、
   セキュリティの方針を設定する対象となるファイルの安全性を確認する安全度評価手段と、
   前記ファイルの種別を確認する種別確認手段と、
   前記安全度評価手段における安全度評価の結果、安全であると判断した場合、ファイル種別に応じてセキュリティの方針を決定する方針決定手段と、
   前記決定したセキュリティの方針を、前記ファイルのセキュリティの方針として設定する方針設定手段と、
   当該情報処理装置上のそれぞれのファイルについて既に前記安全度評価手段における安全性の確認を行ったか否かを示すリストと、
   前記安全性の確認を行ったファイルを、前記リストに記載するリスト記載手段と、
   前記リストに記載されているファイルについては、前記安全度評価手段の対象から除外する手段と、
   を備え、前記リスト記載手段は、前記安全性の確認を行ったファイルであっても、該ファイルに設定したセキュリティの方針に、該ファイルに対する書き込みを許可する旨が含まれている場合は該ファイルをリストに記載しないことを特徴とする情報処理装置。
2. 前記安全度評価手段における安全性の確認は、ウイルスチェック、改竄チェック、証明書検証、脆弱性チェック、バイナリチェックのいずれか１つ、２つ以上での組み合わせ、あるいは全てにより行われることを特徴とする請求項１に記載の情報処理装置。
3. 前記方針設定手段とは、セキュリティポリシデータを設定あるいは更新する手段であることを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記方針決定手段におけるファイルの種別の確認とは、実行可能なファイル、あるいはデータファイルであることを判断可能とすることを指すことを特徴とする請求項１乃至３の何れか１項に記載の情報処理装置。
5. 前記方針設定手段における設定に従ってファイルへのアクセス制御、または、そのファイルの実行制御のいずれか、あるいは両方の制御を行う制御手段を更に備えることを特徴とする請求項１乃至４の何れか１項に記載の情報処理装置。
6. 新規にファイルを追加されたことを検知する手段を更に備えることを特徴とする請求項１乃至５の何れか１項に記載の情報処理装置。
7. 前記安全度評価手段が評価基準となる定義データを更新する更新手段と、
   前記更新に伴い、前記リストを書き換えることにより、前記安全性の確認を既に行ったファイルを再度前記安全性の確認の対象とするリスト書き換え手段と、
   を更に備えることを特徴とする請求項１乃至６の何れか１項に記載の情報処理装置。
8. 前記更新手段が定義データとして、ウイルスを定義したデータを更新する手段であることを特徴とする請求項７に記載の情報処理装置。
9. セキュリティの方針を設定する情報処理方法において、
   セキュリティの方針を設定する対象となるファイルの安全性を確認する安全度評価ステップと、
   前記ファイルの種別を確認する種別確認ステップと、
   前記安全度評価ステップにおける安全度評価の結果、安全であると判断した場合、ファイル種別に応じてセキュリティの方針を決定する方針決定ステップと、
   前記決定したセキュリティの方針を、前記ファイルのセキュリティの方針として設定する方針設定ステップと、
   情報処理装置上のそれぞれのファイルについて既に前記安全度評価手段における安全性の確認を行ったか否かを示すリストを用意するステップと、
   前記安全性の確認を行ったファイルを、前記リストに記載するリスト記載ステップと、
   前記リストに記載されているファイルについては、前記安全度評価手段の対象から除外するステップと、
   を備え、前記リスト記載ステップでは、前記安全性の確認を行ったファイルであっても、該ファイルに設定したセキュリティの方針に、該ファイルに対する書き込みを許可する旨が含まれている場合は該ファイルをリストに記載しないことを特徴とする情報処理方法。
10. 前記安全度評価ステップにおける安全性の確認は、ウイルスチェック、改竄チェック、証明書検証、脆弱性チェック、バイナリチェックのいずれか１つ、２つ以上での組み合わせ、あるいは全てにより行われることを特徴とする請求項９に記載の情報処理方法。
11. 前記方針設定ステップとは、セキュリティポリシデータを設定あるいは更新するステップであることを特徴とする請求項９又は１０に記載の情報処理方法。
12. 前記方針決定ステップにおけるファイルの種別の確認とは、実行可能なファイル、あるいはデータファイルであることを判断可能とすることを指すことを特徴とする請求項９乃至１１の何れか１項に記載の情報処理方法。
13. 前記方針設定ステップにおける設定に従ってファイルへのアクセス制御、または、そのファイルの実行制御のいずれか、あるいは両方の制御を行う制御ステップを更に備えることを特徴とする請求項９乃至１２の何れか１項に記載の情報処理方法。
14. 新規にファイルを追加されたことを検知するステップを更に備えることを特徴とする請求項９乃至１３の何れか１項に記載の情報処理方法。
15. 前記安全度評価ステップが評価基準となる定義データを更新する更新ステップと、
    前記更新に伴い、前記リストを書き換えることにより、前記安全性の確認を既に行ったファイルを再度前記安全性の確認の対象とするリスト書き換えステップと、
    を更に備えることを特徴とする請求項９乃至１４の何れか１項に記載の情報処理方法。
16. 前記更新ステップが定義データとして、ウイルスを定義したデータを更新するステップであることを特徴とする請求項１５に記載の情報処理方法。
17. セキュリティの方針を設定する情報処理プログラムにおいて、
    コンピュータを、
    セキュリティの方針を設定する対象となるファイルの安全性を確認する安全度評価手段と、
    前記ファイルの種別を確認する種別確認手段と、
    前記安全度評価機能における安全度評価の結果、安全であると判断した場合、ファイル種別に応じてセキュリティの方針を決定する方針決定手段と、
    前記決定したセキュリティの方針を、前記ファイルのセキュリティの方針として設定する方針設定手段と、
    当該情報処理装置上のそれぞれのファイルについて既に前記安全度評価手段における安全性の確認を行ったか否かを示すリストを用意すると、
    前記安全性の確認を行ったファイルを、前記リストに記載するリスト記載手段と、
    前記リストに記載されているファイルについては、前記安全度評価手段の対象から除外する手段と、
    を備え、前記リスト記載手段は、前記安全性の確認を行ったファイルであっても、該ファイルに設定したセキュリティの方針に、該ファイルに対する書き込みを許可する旨が含まれている場合は該ファイルをリストに記載しない情報処理装置として機能させることを特徴とする情報処理プログラム。
18. 前記安全度評価機能における安全性の確認は、ウイルスチェック、改竄チェック、証明書検証、脆弱性チェック、バイナリチェックのいずれか１つ、２つ以上での組み合わせ、あるいは全てにより行われることを特徴とする請求項１７に記載の情報処理プログラム。
19. 前記方針設定機能とは、セキュリティポリシデータを設定あるいは更新する機能であることを特徴とする請求項１７又は１８に記載の情報処理プログラム。
20. 前記方針決定機能におけるファイルの種別の確認とは、実行可能なファイル、あるいはデータファイルであることを判断可能とすることを指すことを特徴とする請求項１７乃至１９の何れか１項に記載の情報処理プログラム。
21. 前記方針設定機能における設定に従ってファイルへのアクセス制御、または、そのファイルの実行制御のいずれか、あるいは両方の制御を行う制御機能を更にコンピュータに実現させることを特徴とする請求項１７乃至２０の何れか１項に記載の情報処理プログラム。
22. 新規にファイルを追加されたことを検知する機能を更にコンピュータに実現させることを特徴とする請求項１７乃至２１の何れか１項に記載の情報処理プログラム。
23. 前記安全度評価機能が評価基準となる定義データを更新する更新機能と、
    前記更新に伴い、前記リストを書き換えることにより、前記安全性の確認を既に行ったファイルを再度前記安全性の確認の対象とするリスト書き換え機能と、
    を更にコンピュータに実現させることを特徴とする請求項１７乃至２２の何れか１項に記載の情報処理プログラム。
24. 前記更新機能が定義データとして、ウイルスを定義したデータを更新する機能であることを特徴とする請求項２３に記載の情報処理プログラム。

Images