JP6415353B2 - 情報処理方装置、情報処理装置の制御方法、およびコンピュータプログラム - Google Patents

Description

本発明は、強制アクセス制御の機能を有する情報処理方装置、情報処理装置の制御方法、およびコンピュータプログラムに関する。

一般的なコンピュータシステムにおいては、通常、システム内の重要な情報にアクセスするためにはシステム管理者の権限が必要になる。これは、システム管理者のみがシステム内の重要な情報にアクセスできるようにすることよって、悪意のある者によるコンピュータシステムの改竄などを防止するための仕組みである。

しかしながら、一方で、システム管理者の権限が悪意のある者に取られてしまうと、
コンピュータシステムの改竄などが容易に行われてしまう危険性もある。そこで、システム管理者の権限を持っていても、システムの特定の実行プロセス、ファイル、及びデバイスなどのコンピュータ資源へのアクセスを制限する仕組みがいくつか提案されている。

提案されている仕組みの一つに、強制アクセス制御（Ｍａｎｄａｔｏｒｙ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ、ＭＡＣと呼ぶ）がある。これは、予め作成したセキュリティポリシー（以下、ポリシー）に基づいて、実行プロセスやファイルへのアクセスを制御するものである。特許文献１には、ＭＡＣに関する技術が開示されている。

特開２０１２−１８１０２号公報

上述の通りに、情報処理装置にＭＡＣを適用するためには、ポリシーを作成しておく必要がある。通常、ポリシーは、コンピュータシステムの構築者などによってあらかじめ作成されている。

しかしながら、一般的に、オペレーティングシステムやアプリケーションプログラムには未知の脆弱性が多く存在する。そして、未知の脆弱性が発見されると、当該脆弱性を利用した不正アクセスが発生することがある。このような不正アクセスの発生は、あらかじめ作成したポリシーでは想定されておらず、あらかじめ作成したポリシーを使い続けると、不正アクセスを許容することになりかねない。よって、ポリシーを更新する必要があるが、未知の脆弱性の発見やその他の情報に基づき、ポリシーを逐次更新することは、コンピュータシステムの管理者にとって大きな作業負荷となってしまう。一方で、ユーザーインターフェースを持つ特定のアプリケーションにポリシーを自動的に更新させると、当該特定のアプリケーションが悪意のある者に乗っ取られてしまった場合、不正アクセスを許すことになりかねない。

本発明は、上記課題を鑑みてなされたものであり、強制アクセス制御の機能を有する情報処理方装置において、アプリケーションの脆弱性に対するセキュリティ強度を維持しつつ、セキュリティポリシーの更新における作業負荷を軽減させることを目的とする。

上記課題を鑑み、本発明は、強制アクセス制御の機能を有する情報処理装置であって、
前記強制アクセス制御によってアプリケーションのアクセスを管理するための当該アプリケーションごとのセキュリティポリシーを保持する保持手段と、アプリケーションの脆弱性に関する情報を取得する取得手段と、前記取得手段で取得された情報に基づき、カーネルスレッドの機能で、前記セキュリティポリシーを更新する更新手段と、を有することを特徴とする。

本発明によれば、強制アクセス制御の機能を有する情報処理方装置において、アプリケーションの脆弱性に対するセキュリティ強度を維持しつつ、セキュリティポリシーの更新における作業負荷を軽減させることが出来る。

（Ａ）情報処理装置の全体構成を示す模式図である。（Ｂ）情報処理装置のプログラム構成を示す模式図である。 （Ａ）第１の実施形態におけるＯＳ１１０の構成を示す概略図である。（Ｂ）プロセス情報１１７の例を示す図である。 第１の実施形態におけるポリシー更新処理のフローチャートである。 第１の実施形態における強制アクセス制御処理のフローチャートである。 第２の実施形態におけるポリシー更新処理のフローチャートである。 （ａ）〜（ｄ）ポリシーの例を示す図である。 （ａ）、（ｂ）アクセスログの例を示す図である。 （ａ）既知の脆弱性情報の例を示す図である。（ｂ）アプリケーションテーブルの例を示す図である。 第１の実施形態におけるアクセスログ解析処理のフローチャートである。 第２の実施形態におけるＯＳ１１０の構成を示す概略図である。

以下、本発明の一実施形態である第１の実施形態について図面を用いて説明する。

（第１の実施形態）
本実施形態は、アプリケーションのアクセスを強制的に管理する強制アクセス制御の機能を有する情報処理装置に関するものである。本実施形態では、カーネルスレッドの機能を用いて、アクセスログを解析し、対応するアプリケーションのポリシー（セキュリティポリシー）の更新又は新規作成を行う。カーネルスレッドは、一般的にユーザーインターフェースを持たないため、悪意のある者に操作されてしまう可能性が低い。よって、ポリシーの更新においてセキュリティ強度を維持することが可能となる。

（情報処理装置の全体構成）
図１（Ａ）は、本実施形態における情報処理装置１００の全体構成を示したものである。

情報処理装置１００は、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、Ｉ／Ｆ１０４、ＨＤＤ１０５、操作部１０６、表示部１０７、およびエンジン１０８を有する。そして、それぞれの構成はバス１０９で接続されている。

ＣＰＵ１０１はＲＯＭ１０２に格納されたコンピュータプログラムに沿って情報処理装置１００内の各部の動作を制御する。また、ＲＡＭ１０３にロードしたコンピュータプログラム（ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やアプリケーション）を実行したりする。ＲＯＭ１０２は、読み出し専用メモリであり、ブートプログラムやファームウェア、後述する処理を実現するための各種コンピュータプログラム、各種データが格納されている。ＲＡＭ１０３はＣＰＵ１０１にて処理を行うために一時的にプログラムやデータを格納しておくワークメモリであり、ＣＰＵ１０１により各種コンピュータプログラムやデータがロードされる。

Ｉ／Ｆ１０４はネットワーク機器やＵＳＢデバイスといった外部装置と通信するためのインタフェースである。ネットワークを通じたデータ通信や、外部装置とデータの送受信を行う。ＨＤＤ１０５はＯＳや各種コンピュータプログラム、または各種データを保持する不揮発性の記憶装置である。

次に、本実施形態における情報処理装置１００のコンピュータプログラムの構成を図１（Ｂ）に示す。本実施形態における情報処理装置１００は、ＯＳ１１０と複数のアプリケーション１１１を動作させる。複数のアプリケーション１１１は、ＯＳ１１０上で動作するコンピュータプログラムである。

アプリケーション１１１は、情報処理を実施するものであれば、どのようなものでも良い。例えば、文書編集アプリケーション、画像編集アプリケーションおよびＷｅｂ接続アプリケーションなどがある。また、プリント処理アプリケーション、スキャン処理アプリケーション、コピー処理アプリケーションなどもある。アプリケーション１１１がデータをＨＤＤ１０５に書き込む場合には、ＯＳ１１０を介して書込み処理を実施する。読出し処理も同様になる。読み書きの際には、ＯＳ１１０は、ＨＤＤ１０５の論理アドレスを指定してＨＤＤ１０５に対する読み書きを実施する。

（ＯＳ１１０の論理構成）
図２（Ａ）は図１のＯＳ１１０の機能構成を示す模式図である。尚、以下のＯＳ１１０の各機能の少なくとも一部は、カーネルスレッドで実行される。
また、図２（Ｂ）は、ＯＳ１１０上で動作するプロセスのプロセス情報１１７の例を示す図である。なお、ＯＳ１１０の各機能はＣＰＵ１０１がＯＳのプログラムコードを実行することにより実現される。

脆弱性情報解析部１１８は、ＯＳ１１０の起動とともに起動する常駐プロセスである。

起動後は、定期的（例えば、一時間ごとや一日ごと）にログＤＢ１１２から取得したシステムのアクセスログを解析し、解析結果をポリシー処理部１１４に渡す。

ポリシー処理部１１４は、脆弱性情報解析部１１８からアクセスログの解析結果、または制御対象のアプリケーション１１１のシステムコールおよびプロセス情報１１７を受け取ると次に述べる処理を実施する。アクセスログの解析結果を受け取った場合、ポリシー処理部１１４は解析結果に基づいて、ポリシーの更新または新規作成を行い、ポリシーＤＢ１１３に渡す。一方、システムコールおよびプロセス情報１１７を受け取った場合、ポリシー処理部１１４は、システムコールと対応するポリシーをアクセス制御部１１５へ渡す。ここで、プロセス情報１１７は例えば、図２（Ｂ）で示される。１行目の「Ｓｔａｔｕｓ」はプロセスの情報を示しており、例えば、休眠中を示す「ｓｌｅｅｐｉｎｇ」や実行中を示す「ｒｕｎｎｉｎｇ」などがある。２行目の「Ｐｉｄ」は各プロセスの識別子、３行目の「Ｃｍｄｌｉｎｅ」は、実行ファイルのパスを示している。

ポリシー処理部１１４が、仮に、キーボードやマウスなどのインタフェースやネットワークを有していたとすると、悪意のある者に乗っ取られてしまう可能性がある。よって、本実施形態では、ポリシー処理部１１４は、ユーザーインターフェースを持たないＯＳ１１０のカーネルスレッドとして機能する。強制アクセス制御でアクセスや処理を制御できる対象は、ＯＳ１１０のアプリケーションやコマンドなどのユーザ空間に存在するプログラムである。カーネルスレッドは、ユーザ空間とは別空間であるカーネル空間で処理される一関数である。よって、明示的にユーザ空間からのアクセスするためのユーザーインターフェースを実装しない限りは、ユーザからのアクセスが困難である。そのため、悪意のある者による乗っ取りを防ぐことが可能となる。

アクセス制御部１１５は、制御対象のアプリケーション１１１に対応するポリシーに基づいて、システムコールから取得した要求を拒絶する。拒絶されない場合は、システムコール処理部１１６に要求を入力する。システムコール処理部１１６は要求に対応したシステムコール処理を行う。以上が、本実施形態におけるＯＳ１１０の機能構成である。

次に、ＯＳ１１０の＜強制アクセス制御処理＞と＜ポリシー更新処理＞について説明する。

（強制アクセス制御処理）
図４は、ＲＯＭに格納されたＯＳ１１０によって実行される強制アクセス制御処理を示すフローチャートである。以下では、図２（Ａ）の各構成と対応づけて説明する。

まず、図４のステップＳ４０１において、図２（Ａ）のポリシー処理部１１４がアプリケーション１１１から発行されたシステムコール（ＯＳへの要求）を取得する。

ステップＳ４０２において、図２（Ａ）のポリシー処理部１１４が強制アクセス制御をするか否かを判定する。強制アクセス制御をする場合（ＹＥＳ）は、ステップＳ４０３に進む。そして、ステップＳ４０３において、図２（Ａ）のポリシー処理部１１４がポリシーＤＢ１１３から各アプリケーションのポリシーを入力し、アクセス制御部１１５に渡す。

一方、ステップＳ４０２において、強制アクセス制御をしない場合（ＮＯ）は、ステップＳ４０５に進む。そして、ステップＳ４０５において、図２（Ａ）のシステムコール処理部１１６がアプリケーションからの要求を処理するシステムコール処理を行い、ＯＳ１１０の処理を終了する。

ステップＳ４０４において、図２（Ａ）のアクセス制御部１１５が入力されたポリシーに基づいてアプリケーション１１１がアクセスするコンピュータ資源のアクセス要求を許可するか否かを判定する。アクセス要求を許可する場合（ＹＥＳ）は、ステップＳ４０５に進む。そして、ステップＳ４０５において、図２（Ａ）のシステムコール処理部１１６がアプリケーションからの要求を処理するシステムコール処理を行い、ＯＳ１１０処理を終了する。

一例として、アプリケーション「Ａｐｐ１」がファイル「／ｕｓｒ／ｌｏｃａｌ／ｕｓｅｒ＿ｄａｔａ／ｔｅｘｔ．ｔｘｔ」を読み込む要求が入力された場合について説明する。このような入力があった場合、図６（ａ）の６０１にあるポリシーが入力される。６０１の６０１ａには、どのアプリケーションのポリシーかを示すために、アプリケーションの実行ファイルのパスが記述されている。６０１ｂには、具体的なルールが記載されており、ファイル毎に一行ずつ記載されている。各行の前半はファイルのパス名を示し、後半は許可する制御情報が記載される。「ｒｅａｄ」と記載されていれば、読み取りを許可し、「ｗｒｉｔｅ」と記載されていれば、書き込みを許可する。例えば、６０１ｃの行は、ファイル「／ｕｓｒ／ｂｉｎ／Ａｐｐ１」の読み取りを許可する。なお、特殊な記号を使用して一行で複数のファイルのルールをまとめて記載しても良い。例えば、６０２ｄの「／ｕｓｒ／ｌｏｃａｌ／ｕｓｅｒ＿ｄａｔａ／＊ ｒｅａｄ」は「／ｕｓｒ／ｌｏｃａｌ／ｕｓｅｒ＿ｄａｔａ」フォルダ以下にあるファイル全ての読み取りを許可することになる。

そして、今回は、「／ｕｓｒ／ｌｏｃａｌ／ｕｓｅｒ＿ｄａｔａ」フォルダ以下にある「ｔｅｘｔ．ｔｘｔ」の読み取りは許可されているため、この要求は許可され、処理が実行される。一方、ステップＳ４０４において、アクセス要求を許可しない場合（ＮＯ）は、要求を拒否し、ＯＳ１１０の処理を終了する。

（ポリシー更新処理）
図３は、ＯＳ１１０で実行されるポリシー更新処理の詳細を示すフローチャートである。以下では、図２（Ａ）の各構成と対応づけて説明する。なお、この処理は、あらかじめ定められた時間間隔で定期的に実施される。例えば、一時間ごとや一日ごとに実施される。

まず、図３のステップＳ３０１において、図２（Ａ）の脆弱性情報解析部１１８がログＤＢ１１２からアクセスログを取得する。例えば、図７（ａ）に示す７０１、図７（ｂ）に示す７０２のようなアクセスログを取得する。

次に、ステップＳ３０２において、図２（Ａ）の脆弱性情報解析部１１８がステップＳ３０１で取得したアクセスログを解析する。解析は異常なアクセスの有無の観点で行われる。ステップＳ３０２の具体的な処理は、例えば、図９（ａ）や図９（ｂ）に示す処理になる。ステップＳ３０２の具体的な処理として、図９（ａ）および図９（ｂ）に示す処理について説明する。

図９（ａ）の処理では、同じファイルへのアクセスが異常に多いか否かで異常なアクセスを判定している。

まず、ステップＳ３０２ａにおいて、同じファイルへのアクセス数が所定の閾値ＴＨ＿Ａ以上か否かを判定する。閾値ＴＨ＿Ａは、例えば１００などと設定しておいても良い。閾値ＴＨ＿Ａ以上の場合（ＹＥＳ）は、ステップＳ３０２ｂに進み、ステップＳ３０２ｂにおいて、異常発見フラグをＯＮにする。なお、異常発見フラグの初期値は＜ポリシー更新処理＞の開始前はＯＦＦである。閾値ＴＨ＿Ａ未満の場合（ＮＯ）は、処理を終了する。

例えば、図７（ａ）の７０１の場合は、７０１ａの各行のファイルアクセスをカウントすると、同じファイル「ｔｅｘｔ．ｔｘｔ」へ１４０回アクセスがあるので、閾値ＴＨ＿Ａ以上となる。ステップＳ３０２ｃにおいて、閾値ＴＨ＿Ａ以上の対象ファイルのパスを記録する。以上が、図９（ａ）の処理である。

一方で、図９（ｂ）の処理は、不明なＩＰアドレスからのアクセスが異常に多いか否かで異常なアクセスを判定している。

まず、ステップＳ３０２ｄにおいて、不明なＩＰアドレスを持つ端末からのアクセスが閾値ＴＨ＿Ｂ以上か否かを判定する。閾値ＴＨ＿Ｂは例えば、１０とする。閾値ＴＨ＿Ｂ以上の場合（ＹＥＳ）は、ステップＳ３０２ｂに進み、ステップＳ３０２ｂにおいて、異常発見フラグをＯＮにする。閾値ＴＨ＿Ｂ未満の場合（ＮＯ）は、処理を終了する。例えば、図７（ｂ）の７０２の場合は、７０２ａの不明なＩＰアドレスをカウントすると、同じ不明なＩＰアドレス「ＸＸＸ．ＸＸＸ．ＸＸＸ．ＹＹＹ」から３０回アクセスがあるので、閾値ＴＨ＿Ｂ以上となる。ステップＳ３０２ｅにおいて、閾値ＴＨ＿Ｂ以上の対象ＩＰアドレスを記録する。以上が図９（ｂ）の処理である。

なお、ステップＳ３０２における、同じファイルへのアクセスや同じＩＰアドレスからのアクセスのカウントは、シェルスクリプトやＰｅｒｌなどを使用して文字列カウントすれば良い。

ステップＳ３０３において、図２（Ａ）における脆弱性情報解析部１１８が異常発見フラグを検知し、異常が発見されたか否かを判定する。異常発見フラグがＯＮになっており、異常が発見された場合（ＹＥＳ）は、ステップＳ３０４に進む。そして、図２（Ａ）のポリシー処理部１１４がポリシーＤＢ１１３から各アプリケーションのポリシーを入力する。異常発見フラグがＯＦＦになっており、異常が発見されない場合（ＮＯ）は、処理を終了する。

ステップＳ３０５においては、図２（Ａ）のポリシー処理部１１４によって、異常が発見されたアプリケーションのポリシーがあるか否かを判定する。ポリシーがある場合（ＹＥＳ）は、ステップＳ３０６に進み、図２（Ａ）のポリシー処理部１１４がポリシーを更新して処理を終了する。更新方法としては、２つある。一つは、異常アクセスがあったファイルへのアクセスや異常なアクセスがあったＩＰアドレスからのアクセスを拒否するルールのみを追加する方法である。例えば、元のポリシーが図６（ａ）の６０１だとすると、図６（ｂ）の６０２ｂや６０２ｃのようにルールを追加する。ルールの先頭に「ｄｅｎｙ」を記述することで拒否するルールになる。なお、６０２ｃはＩＰアドレス「ＸＸＸ．ＸＸＸ．ＸＸＸ．ＹＹＹ」からの全て「ＡＬＬ」のアクセスを拒否する。もう一つは、拒否する範囲を拡大して追加する方法である。異常アクセスがあったファイルが所属するフォルダへのアクセスを拒否したり、異常なアクセスがあったＩＰアドレスがあれば、全ての外部のＩＰアドレスを拒否するルールのみを追加する。例えば、元のポリシーが図６（ａ）の６０１だとすると、図６（ｃ）の６０３ｂや６０３ｃのようにルールを追加する。なお、６０３ｃは全ての外部のＩＰアドレス「ＯＵＴＳＩＤＥ＿ＩＰ＿ＡＬＬ」からの全て「ＡＬＬ」のアクセスを拒否する。また、他の更新方法があれば、その方法を適応しても良い。

一方、ポリシーがない場合（ＮＯ）は、ステップＳ３０７に進み、図２（Ａ）のポリシー処理部１１４がポリシーの新規作成を行い、処理を終了する。ポリシーの新規作成は、例えば、まずは、たたき台として、図６（ａ）の６０１ａに示すようなアプリケーションの実行ファイルのパスおよび６０１ｂに示すような実行ファイルの読み込みを許可のルールのみのポリシーを作成する。次に、異常アクセスが見つかったファイルの読み込みを拒否するルールを追加する。

なお、上記実施形態では、異常アクセスが発見されたら、ポリシーを更新した。しかし、異常アクセスが無くなったり、異常アクセスに対応したアプリケーションのパッチが適応されたら、元のポリシーに戻しても良い。

（第２の実施形態）
第１の実施形態では、まず、アクセスログを解析した。そして、特定のアプリケーションへの攻撃がされているとみなすことが出来る場合は、カーネルスレッドを用いて、対応するアプリケーションのポリシー更新または新規作成を行った。本実施形態では、アプリケーションが既知となった脆弱性に対応していない場合に、カーネルスレッドを用いて、既知となった脆弱性情報に基づき、ポリシー更新または新規作成を行う。これによって、ポリシーを手動で更新または新規作成することなく、既知となった脆弱性にアプリケーションを対応させることが出来る。

本実施形態と第１の実施形態とは、（ＯＳ１１０の論理構成）の一部と（ポリシー更新処理）のみが異なり、それ以外は全て同じである。よって、以下では、（ＯＳ１１０の論理構成）の第１の実施形態からの差分と（ポリシー更新処理）のみを説明する。

（ＯＳ１１０の論理構成）
図１０は、本実施形態におけるＯＳ１１０の機能構成を示す模式図である。なお、ＯＳ１１０の各機能はＣＰＵ１０１がＯＳのプログラムコードを実行することにより実現される。また、ポリシーＤＢ１１３、アクセス制御部１１５、システムコール処理部１１６及びプロセス情報１１７は、図２（Ａ）の同一名称の各部と同様なので、説明は省略する。

脆弱性情報解析部１１８は、ＯＳ１１０の起動とともに起動する常駐プロセスである。起動後は、定期的にＯＳ１１０の外部にある通信ネットワーク１１９を通じて、既知脆弱性情報ＤＢ１２０から、新たに既知となった脆弱性情報を取得する。取得する間隔は、例えば、一時間ごとや一日ごとなどに設定しておけばよい。既知となった脆弱性情報は、例えば、ＣＶＥ（Ｃｏｍｍｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｉｅｓ ａｎｄ Ｅｘｐｏｓｕｒｅｓ）で示され、図８（ａ）に示すようなものである。そして、既知となった脆弱性情報とＯＳ１１０の内部にある図８（ｂ）に示すようなアプリケーションテーブルとを比較した後、既知となった脆弱性情報を解析する。解析後、解析結果をポリシー処理部１１４に渡す。

また、ポリシー処理部１１４は、脆弱性情報解析部１１８から既知となった脆弱性情報の解析結果、または制御対象のアプリケーション１１１のシステムコールおよびプロセス情報１１７を受け取ると次に述べる処理を実施する。既知となった脆弱性情報の解析結果を受け取った場合、ポリシー処理部１１４は解析結果に基づいて、ポリシーの更新または新規作成を行い、ポリシーＤＢ１１３に渡す。一方、システムコールおよびプロセス情報１１７を受け取った場合、ポリシー処理部１１４は、システムコールと対応するポリシーをアクセス制御部１１５へ渡す。

ここで、第１の実施形態と同様に、ポリシー処理部１１４は、ユーザーインターフェースを持たないカーネルスレッドとする。これによって、悪意のある者による乗っ取りを防ぐことが可能となる。

（ポリシー更新処理）
図５は、ＯＳ１１０におけるポリシー更新処理の詳細を示すフローチャートである。図２（Ａ）の各構成と対応づけて説明する。なお、この処理は第１の実施形態と同様に定期的に実施する。

まず、図５のステップＳ５０１において、図２（Ａ）の脆弱性情報解析部１１８がＯＳ１１０の外部にある既知脆弱性情報ＤＢから、新たに既知となった脆弱性情報を取得する。例えば、図８（ａ）に示すような脆弱性情報を取得する。

次に、ステップＳ５０２においては、図２（Ａ）の脆弱性情報解析部１１８によって、発見された脆弱性に該当するアプリケーションが存在するか否かを判定する。当該判定は、脆弱性情報に記載されたアプリケーションの情報とＯＳ１１０の内部にあるアプリケーションテーブルとを比較して行われる。具体的には、まず、アプリケーションテーブルに記載されたアプリケーション名が脆弱性情報のタイトルや概要に対する存在するかを既存の文字列検索を使用して行う。検索して該当するアプリケーション名があった場合は、バージョンが該当するかについて同様に文字列検索する。例えば、図８（ａ）の脆弱性情報と図８（ｂ）のアプリケーションテーブルを用いた場合は、８０１ａの「Ａｐｐ１ ｂｅｆｏｒｅ ５」を見ると、まず、アプリケーション名が８０２ａの「Ａｐｐ１」と一致することが分かる。次に、８０１ａからバージョンが「５以前」だと分かるので、８０２ｂの「４．２」が該当することが分かる。従って、脆弱性情報に対応していないバージョンだと分かる。

脆弱性が発見されたアプリケーションが存在する場合（ＹＥＳ）は、ステップＳ５０３に進み、ステップＳ５０３において、脆弱性情報を解析する。アプリケーションのどこの部分に脆弱性があるのかを「ｆｕｎｃ」や「ｐｒｏｃｅｓｓ」などの機能や処理を示す文字列から分かる範囲で解析する。例えば、図８（ａ）の脆弱性情報の場合は、８０１ｂより「ｈｏｇｅ」機能で脆弱性があることが分かる。

一方、脆弱性が発見されたアプリケーションが存在しない場合（ＮＯ）は、処理を終了する。

ステップＳ５０４においては、図２（Ａ）のポリシー処理部１１４がポリシーＤＢ１１３から各アプリケーションのポリシーを入力する。

ステップＳ５０５においては、図２（Ａ）のポリシー処理部１１４によって、異常が発見されたアプリケーションのポリシーがあるか否かを判定する。ポリシーがある場合（ＹＥＳ）は、ステップＳ５０６に進み、図２（Ａ）のポリシー処理部１１４がポリシーを更新して処理を終了する。例えば、図８（ａ）の脆弱性情報の場合は、「ｈｏｇｅ」機能に関するデータを拒否するルールを追加する。その場合は、図６（ａ）の６０１に示すポリシーが図６（ｄ）の６０４に示すポリシーに変更される。６０４ｂに示すルールは「ｈｏｇｅ」機能に関するデータを拒否するルールである。また、第１の実施形態のステップＳ３０６で説明したように、拒否する範囲を拡大して追加したり、他の更新方法があれば、その方法を適応しても良い。

一方、ポリシーがない場合（ＮＯ）は、ステップＳ５０７に進み、図２（Ａ）のポリシー処理部１１４がポリシーの新規作成を行い、処理を終了する。ポリシーの新規作成は、第１の実施形態のステップＳ３０７で説明した例と同様に行えば良い。

なお、上記実施形態では、既知となった脆弱性情報に該当するアプリケーションがあれば、ポリシーの更新や新規作成を行った。しかしながら、深刻な脆弱性のみに対応し、軽微な脆弱性には対応しないことで、ポリシーの更新や新規作成の処理の負荷を軽減しても良い。具体的には、例えば、ＣＶＥでは、脆弱性の共通脆弱性評価システムＣＶＳＳ（Ｃｏｍｍｏｎ Ｖｕｌｎｅｒａｂｉｌｉｔｙ Ｓｃｏｒｉｎｇ Ｓｙｓｔｅｍ）のベーススコアが記載されている。このスコアが高いほど、脆弱性の深刻だと判断できる。そのため、ベーススコアが一定以上の場合のみ、ポリシーの更新または新規作成を行っても良い。

（第３の実施形態）
第１の実施形態では、まずアクセスログを解析した。そして、特定のアプリケーションへの攻撃がされていると見なすことが出来る場合は、ユーザーインターフェースを持たないカーネルスレッドを用いて、対応するアプリケーションのポリシー更新または新規作成を行った。

第２の実施形態では、アプリケーションが新たに既知となった脆弱性に対応していない場合に、ユーザーインターフェースを持たないカーネルスレッドを用いて、既知となった脆弱性情報を基づき、アプリケーションのポリシー更新または新規作成を行った。

本実施形態では、上記の２つの実施形態を組み合わせる。これによって、未知脆弱性と、新たに既知となった脆弱性の両方に対応したポリシーの更新または新規作成を効率的に行うことが出来る。

第１の実施形態とは、（ＯＳ１１０の論理構成）の一部と（ポリシー更新処理）のみが異なり、それ以外は全て同じである。以下では、（ＯＳ１１０の論理構成）の第１の実施形態からの差分と（ポリシー更新処理）のみ説明する。

（ＯＳ１１０の論理構成）
第１の実施形態からの差分は以下の通りである。脆弱性情報解析部１１８は、ＯＳ１１０の起動とともに起動する常駐プロセスである。起動後は、定期的（例えば、一時間ごとや一日ごと）にログＤＢ１１２から取得したシステムのアクセスログを解析し、解析結果をポリシー処理部１１４に渡す。それに加えて、図１０に示すようなＯＳ１１０の外部にある通信ネットワーク１１９を通じて既知脆弱性情報ＤＢ１２０から既知となった脆弱性情報を取得する。そして、既知となった脆弱性情報とＯＳ１１０の内部にある図８（ｂ）に示すようなアプリケーションテーブルを比較する。比較後、既知となった脆弱性情報を解析し、解析結果をポリシー処理部１１４に渡す。

また、ポリシー処理部１１４は脆弱性情報解析部１１８からアクセスログまたは既知となった脆弱性情報の解析結果、または制御対象のアプリケーション１１１のシステムコールおよびプロセス情報１１７を受け取ると次に述べる処理を実施する。アクセスログまたは既知となった脆弱性情報の解析結果を受け取った場合、ポリシー処理部１１４は解析結果に基づいて、ポリシーの更新または新規作成を行い、ポリシーＤＢ１１３に渡す。一方、システムコールおよびプロセス情報１１７を受け取った場合、ポリシー処理部１１４は、システムコールと対応するポリシーをアクセス制御部１１５へ渡す。

ここで、ポリシー処理部１１４は、第１の実施形態と同様に、ユーザーインターフェースを持たないカーネルスレッドとする。これによって、攻撃者による乗っ取りを防ぐ。以上が第１の実施形態からの差分であり、その他は第１の実施形態と同様である。

（ポリシー更新処理）
本実施形態では、第１の実施形態の（ポリシー更新処理）と第２の実施形態の（ポリシー更新処理）の両方を定期的に実施する。

（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１１４ ポリシー処理部
１１８ 脆弱性情報解析部

Claims (9)

1. 強制アクセス制御の機能を有する情報処理装置であって、
   前記強制アクセス制御によってアプリケーションのアクセスを管理するための当該アプリケーションごとのセキュリティポリシーを保持する保持手段と、
   前記アプリケーションの脆弱性に関する情報を取得する取得手段と、
   前記取得手段で取得された情報に基づき、カーネルスレッドの機能で、前記セキュリティポリシーを更新する更新手段と、を有することを特徴とする情報処理装置。
2. 前記取得手段で取得された情報は、前記アプリケーションによるアクセスのログであることを特徴とする請求項１に記載の情報処理装置。
3. 前記取得手段で取得された情報に基づき、前記アプリケーションによる所定のファイルへのアクセス数が所定値以上であるか否かを判定する判定手段を更に有し、
   前記更新手段は、前記判定手段によって前記アクセス数が所定の値以上であると判定された場合、カーネルスレッドの機能で、前記セキュリティポリシーを更新することを特徴とする請求項１に記載の情報処理装置。
4. 前記取得手段で取得された情報は、前記アプリケーションの新たに発見された脆弱性の情報であり、日付に基づき新たに発見されたことが特定された情報であることを特徴とする請求項１に記載の情報処理装置。
5. 前記更新手段は、前記新たに発見された脆弱性に該当するアプリケーションが前記情報
   処理装置に存在する場合、カーネルスレッドの機能で、前記セキュリティポリシーを更新
   することを特徴とする請求項４に記載の情報処理装置。
6. 前記更新手段は、
   前記取得手段で取得された情報に基づき、カーネルスレッドの機能で、前記アプリケーシ
   ョンによる所定のアクセスを拒否するルールを追加することによって、前記セキュリティポリシーを更新する請求項１乃至５のいずれか１項に記載の情報処理装置。
7. 前記更新手段は、
   前記取得手段で取得された情報に基づき、カーネルスレッドの機能で、前記アプリケーションによる所定のアクセスを拒否するルールを含むセキュリティポリシーを新規作成することによって、前記セキュリティポリシーを更新する請求項１乃至５のいずれか１項に記載の情報処理装置。
8. 強制アクセス制御の機能を有する情報処理装置の制御方法であって、
   保持手段が、前記強制アクセス制御によってアプリケーションのアクセスを管理するための当該アプリケーションごとのセキュリティポリシーを保持する保持工程と、
   取得手段が、アプリケーションの脆弱性に関する情報を取得する取得工程と、
   更新手段が、前記取得手段で取得された情報に基づき、カーネルスレッドの機能で、前記セキュリティポリシーを更新する更新工程と、を有することを特徴とする情報処理装置の制御方法。
9. コンピュータを、
   強制アクセス制御の機能を有する情報処理装置であって、
   前記強制アクセス制御によってアプリケーションのアクセスを管理するための当該アプリケーションごとのセキュリティポリシーを保持する保持手段と、
   アプリケーションの脆弱性に関する情報を取得する取得手段と、
   前記取得手段で取得された情報に基づき、カーネルスレッドの機能で、前記セキュリティポリシーを更新する更新手段と、を有することを特徴とする情報処理装置として機能させるためのコンピュータプログラム。

Images