(57)【特許請求の範囲】
【請求項１】
オブジェクト指向プログラムを実行するように構成された仮想マシン（ＶＭ）において、強く型付けされた言語に基づき、強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）によって、強制アクセス制御（ＭＡＣ）を保証するための方法（１００）であって、
アクセスポリシー（Ａｃｃ＿ｐｏｌ）を用いて強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）を構成するステップと、
メソッド呼び出し（Ｍｅｔｈ＿ｅｎｔｒｙ）または変数メンバへのアクセス要求を指示するイベント受信すると、「呼び出し元」（ＣａｌＲ）と名付けられた、メソッド（Ｍｅｔｈ）を呼び出している、またはアクセスを要求しているオブジェクト、ならびに「呼び出し先」（ＣａｌＥ）と名付けられた、メソッド（Ｍｅｔｈ）に呼び出される、またはそのアクセスが要求されるオブジェクトに、呼び出し元および呼び出し先言語型（Ｔｙｐ＿ＣａｌＲ、Ｔｙｐ＿ＣａｌＥ）に従って、アクセス制御ラベル（ＬａｂＥ、ＬａｂＲ）を追加するステップと、
前記アクセス制御ラベル（ＬａｂＥ、ＬａｂＲ）、呼び出し元および呼び出し先のインスタンス番号（Ｉｎｓｔ＿Ｎｕｍ）、アクセスポリシー（Ａｃｃ＿ｐｏｌ）、ならびにアクセス許可に従って、「ネガティブ決定」と名付けられた、メソッド（Ｍｅｔｈ）の実行もしくは変数メンバへのアクセスをブロックする決定（Ｄｅｃ）、または「ポジティブ決定」と名付けられた、仮想マシン（ＶＭ）にメソッド（Ｍｅｔｈ）を実行させる、もしくは変数メンバにアクセスさせる決定（Ｄｅｃ）を行うステップと、
対応するアクセス試行をブロックするまたは許可するために、前記決定（Ｄｅｃ）を仮想マシン（ＶＭ）に送信するステップと
を含む、方法。
【請求項２】
強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）を構成するステップが、仮想マシン（ＶＭ）の起動または初期化（ＶＭ＿ｓｔａｒｔ、ＶＭ＿ｉｎｉｔ）を指示するイベントを受信したとき実現される、請求項１に記載の方法（１００）。
【請求項３】
イベントが、コールバック機能をアクティブにする、標準化されたインストルメント化指向イベントである、請求項１または２に記載の方法（１００）。
【請求項４】
強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）を構成するステップが、言語型とアクセス制御ラベルとの間の対応を定義するラベルポリシーファイル（Ｌａｂ＿ｐｏｌ＿ｆｉｌｅ）をロードするステップを含み、ラベル（ＬａｂＥ、ＬａｂＲ）を追加するステップが、前記ラベルポリシーファイル（Ｌａｂ＿ｐｏｌ＿ｆｉｌｅ）によって実現される、請求項１から３のいずれか一項に記載の方法（１００）。
【請求項５】
アクセス制御ラベル（ＬａｂＥ、ＬａｂＲ）を追加するステップが、オブジェクトインスタンスとアクセス制御ラベルとの間の対応を含んだ外部データベース（Ｌａｂ＿ｃａｃｈｅ）を使用するステップを含む、請求項１から４のいずれか一項に記載の方法（１００）。
【請求項６】
決定（Ｄｅｃ）を行うステップが、強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）と外部決定エンジン（Ｅｘｔ＿ｄｅｃ＿ｅｎｇ）との協力によって実現される、請求項１から５のいずれか一項に記載の方法（１００）。
【請求項７】
外部データベース（Ｔｒ＿ｄａｔａｂａｓｅ）に、
呼び出されたメソッド（Ｍｅｔｈ）に関する情報、
呼び出し元（ＣａｌＲ）および呼び出し先（ＣａｌＥ）に関する情報、例えばそれらの言語型（Ｔｙｐ＿ＣａｌＲ、Ｔｙｐ＿ＣａｌＥ）、それらのアクセス制御ラベル（ＬａｂＥ、ＬａｂＲ）、またはそれらのインスタンス番号（Ｉｎｓｔ＿Ｎｕｍ）、
行われた決定（Ｄｅｃ）
を記録するステップを含む、請求項１から６のいずれか一項に記載の方法（１００）。
【請求項８】
要求されたメソッド（Ｍｅｔｈ）の実行または変数メンバへのアクセスをブロックするために、ネガティブ決定の場合、仮想マシン（ＶＭ）による例外を生成するステップを含む、請求項１から７のいずれか一項に記載の方法（１００）。
【請求項９】
オブジェクト指向プログラムを実行するように構成された仮想マシン（ＶＭ）において、強く型付けされた言語に基づき、強制アクセス制御（ＭＡＣ）を保証するための強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）であって、
メソッド（Ｍｅｔｈ）呼び出しおよび変数メンバアクセスのための強制的な経路であって、「ネガティブ決定」と名付けられた、前記メソッド（Ｍｅｔｈ）の実行または変数メンバへの前記アクセスをブロックする決定（Ｄｅｃ）、または「ポジティブ決定」と名付けられた、仮想マシン（ＶＭ）に前記メソッド（Ｍｅｔｈ）を実行させる、または前記変数メンバにアクセスさせる決定（Ｄｅｃ）を仮想マシン（ＶＭ）へ送信するように構成された参照モニタ（Ｒｅｆ＿ｍｏｎ）と、
「呼び出し元」（ＣａｌＲ）と名付けられた、メソッド（Ｍｅｔｈ）を呼び出している、またはアクセスを要求しているオブジェクト、および「呼び出し先」（ＣａｌＥ）と名付けられた、メソッド（Ｍｅｔｈ）に呼び出される、またはそのアクセスが要求されるオブジェクトに、呼び出し元および呼び出し先言語型（Ｔｙｐ＿ＣａｌＲ、Ｔｙｐ＿ＣａｌＥ）に従って、アクセス制御ラベル（ＬａｂＥ、ＬａｂＲ）を追加するように構成されたラベル付けエンジン（Ｌａｂ＿ｅｎｇ）と、
前記ラベル（ＬａｂＥ、ＬａｂＲ）、呼び出し元および呼び出し先のインスタンス番号（Ｉｎｓｔ＿Ｎｕｍ）、ならびにアクセスポリシー（Ａｃｃ＿ｐｏｌ）に従って、前記決定（Ｄｅｃ）を行うように構成された決定エンジン（Ｄｅｃ＿ｅｎｇ）と、
を含む、強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）。
【請求項１０】
強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）が、インストルメント化モジュールと名付けられ、標準的なプロトコルおよび標準的なインストルメント化インタフェース（Ｉｎｓｔ＿ｉｎｔｅｒｆ）を介して仮想マシン（ＶＭ）と通信するように構成され、部分的に仮想マシン（ＶＭ）外部のモジュールである、請求項９に記載の強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）。
【請求項１１】
ラベル付けエンジン（Ｌａｂ＿ｅｎｇ）が、呼び出し元および呼び出し先言語型（Ｔｙｐ＿ＣａｌＲ、Ｔｙｐ＿ＣａｌＥ）を要求するために仮想マシン（ＶＭ）と通信するように構成された、請求項１０に記載の強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）。
【請求項１２】
ラベル付けエンジン（Ｌａｂ＿ｅｎｇ）が、オブジェクトインスタンスとアクセス制御ラベルとの間の対応を含む外部データベース（Ｌａｂ＿ｃａｃｈｅ）と通信するように構成された、請求項９から１１のいずれか一項に記載の強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）。
【請求項１３】
決定エンジン（Ｄｅｃ＿ｅｎｇ）が、外部決定エンジン（Ｅｘｔ＿ｄｅｃ＿ｅｎｇ）と通信し、外部決定エンジン（Ｅｘｔ＿ｄｅｃ＿ｅｎｇ）からの外部決定（Ｅｘｔ＿Ｄｅｃ）がポジティブまたはネガティブ決定（Ｄｅｃ）を行うのを待つように構成された、請求項９から１２のいずれか一項に記載の強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）。
【請求項１４】
外部データベース（Ｔｒ＿ｄａｔａｂａｓｅ）に、呼び出されたメソッド（Ｍｅｔｈ）に関する情報、例えば言語型（Ｔｙｐ＿ＣａｌＲ、Ｔｙｐ＿ＣａｌＲ）、ならびに呼び出し元および呼び出し先のアクセス制御ラベル（ＬａｂＥ、ＬａｂＲ）、それらのインスタンス番号（Ｉｎｓｔ＿Ｎｕｍ）、ならびに行われた決定（Ｄｅｃ）を、記録するように構成されたトレースエンジン（Ｔｒ＿ｅｎｇ）を含む、請求項９から１３のいずれか一項に記載の強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）。
【請求項１５】
請求項９に記載の強制アクセス制御モジュール（Ｉｎｓｔｒ＿ｍｏｄｕｌｅ）を含む仮想マシン（ＶＭ）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想マシンに関し、より詳細には、仮想マシンにおけるセキュリティ制御に関する。
【背景技術】
【０００２】
ソフトウェアエコシステムは、ますます複雑になっているので、情報セキュリティをシステム全体に適用することが非常に難しくなっている。実際に、今日では、単にインハウスソフトウェアを使用することによってマシンソフトウェアスタックを構築することはまれであり、安全な開発および設計に関して非常に異なるノウハウおよび技能を有するオープンソースソフトウェア、市販ソフトウェア、およびインハウスソリューションを組み合わせることが一般的である。結果として、設計、開発、配備、および維持管理活動におけるたった１つの障害が、セキュリティ違反を発生させる可能性がある。さらに、ソフトウェア脆弱性が、クライアント側（Ｆｌａｓｈプラグイン、Ａｃｒｏｂａｔ  Ｒｅａｄｅｒ、インターネットブラウザ、スマートフォンアプリ）において、ならびにサーバ側（マシン仮想化、アプリケーションサーバ（ＰＨＰ、Ｊａｖａ（登録商標）、．Ｎｅｔ）、ウェブミドルウェア、データベース）において、アプリケーションレベルでますます目立ってきている。
【０００３】
長い間、任意アクセス制御（Ｄｉｓｃｒｅｔｉｏｎａｒｙ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ：ＤＡＣ）が使用されてきた。この手法は、ユーザまたは役割ベースであり、そのため、ルート／管理者アクセスが攻撃者によってえられると、アクセス制御全体が役立たないものになる。この問題に対処するために、強制アクセス制御（Ｍａｎｄａｔｏｒｙ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ：ＭＡＣ）が設計された。強制アクセス制御は、アクセス要求チェックを強いることによってオペレーティングシステムの承認（ｏｐｅｒａｔｉｎｇ  ｓｙｓｔｅｍ  ａｕｔｈｏｒｉｚａｔｉｏｎ）を実施するセキュリティ手法である。これは、システムユーザから独立してセキュリティポリシーに関して行われる。
【０００４】
１つのＭＡＣ実装として、ＳＥｌｉｎｕｘでは、システムレベルで適用されて、ユーザ識別に関係なく、セキュリティポリシーを実施することができる。ＭＡＣによって違法の「ルート」がブロックされることさえ可能である。Ｗｉｎｄｏｗｓ（登録商標）  ＶｉｓｔａおよびＳｅｖｅｎは、現在デフォルト設定でＭＡＣを含んでおり、管理タスクは明示的に定義または同意されなければならない。
【０００５】
しかしながら、この型のアクセス制御は、仮想マシン、例えばＪａｖａ仮想マシン（ＪＶＭ）にセキュリティを保証するには効率的ではない。実際、ＪＶＭプロセスは、システムに対してブラックボックスのようであり、そのためにシステムが、ＪＶＭにおける悪意のあるアクティビティと正当なアクティビティとを区別することは多くの場合困難である。Ｊａｖａ認証承認サービス（ＪＡＡＳ）が、ＪＶＭにおけるセキュリティを保証するために、古くから使用されているが、このセキュリティメカニズムは強制的ではなく、ＪＶＭとシステムとの間の周辺保護にすぎない。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】Ｊ．Ｂｒｉｆｆａｕｔ、「Ｆｏｒｍａｌｉｓａｔｉｏｎ  ｅｔ  ｇａｒａｎｔｉｅ  ｄｅ  ｐｒｏｐｒｉｅｔｅｓ  ｄｅ  ｓｅｃｕｒｉｔｅ  ｓｙｓｔｅｍｅ：  ａｐｐｌｉｃａｔｉｏｎ  ａ  ｌａ  ｄｅｔｅｃｔｉｏｎ  ｄ‘ｉｎｔｒｕｓｉｏｎｓ」、ｔｈｅｓｅ  ｄｅ  ｄｏｃｔｏｒａｔ  ｄ’Ｉｎｆｏｒｍａｔｉｑｕｅ、ｓｏｕｔｅｎｕｅ  ｌｅ  １３  ｄｅｃｅｍｂｒｅ  ２００７、ＬＩＦＯ  Ｕｎｉｖｅｒｓｉｔｅ  ｄ‘Ｏｒｌｅａｎｓ、Ｆｒａｎｃｅ
【非特許文献２】Ｊ．Ｂｒｉｆｆａｕｔ、Ｃ．Ｔｏｉｎａｒｄ、Ｍ．Ｐｅｒｅｓ、「Ａ  ｄｙｎａｍｉｃ  Ｅｎｄ−ｔｏ−Ｅｎｄ  Ｓｅｃｕｒｉｔｙ  ｆｏｒ  Ｃｏｏｒｄｉｎａｔｉｎｇ  Ｍｕｌｔｉｐｌｅ  Ｐｒｏｔｅｃｔｉｏｎｓ  ｗｉｔｈｉｎ  ａ  Ｌｉｎｕｘ（登録商標）  Ｄｅｓｋｔｏｐ」、コラボレーションおよびセキュリティ（Ｃｏｌｓｅｃ  ２０１０）ワークショップ、ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ２０１０  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｓｙｍｐｏｓｉｕｍ  ｏｎ  Ｃｏｌｌａｂｏｒａｔｉｖｅ  Ｔｅｃｈｎｏｌｏｇｉｅｓ  ａｎｄ  Ｓｙｓｔｅｍｓ  （ＣＴＳ  ２０１０）、ＵＳＡ
【発明の概要】
【発明が解決しようとする課題】
【０００７】
仮想マシンに適用する強制アクセス制御モデルを提供するために、セキュリティモデルを説明することが、本発明の目的である。
【課題を解決するための手段】
【０００８】
この目的のために、本発明は、オブジェクト指向プログラムを実行するように構成された仮想マシンにおいて、強く型付けされた言語に基づき、強制アクセス制御モジュールによって、強制アクセス制御を保証するための方法を提供し、方法は：
−  アクセスポリシーを用いて強制アクセス制御モジュールを構成するステップと、
−  メソッド呼び出しまたは変数メンバ（ｖａｒｉａｂｌｅ  ｍｅｍｂｅｒ）へのアクセス要求を指示するイベント受信すると、「呼び出し元（ｃａｌｌｅｒ）」と名付けられた、メソッドを呼び出している、もしくはアクセスを要求しているオブジェクト、および「呼び出し先（ｃａｌｌｅｅ）」と名付けられた、メソッドによって呼び出される、もしくはそのアクセスが要求されるオブジェクトに、呼び出し元および呼び出し先言語型に従って、アクセス制御ラベルを追加するステップと、
−  前記アクセス制御ラベル、呼び出し元および呼び出し先のインスタンス番号、ならびにアクセスポリシーに従って、「ネガティブ決定（ｎｅｇａｔｉｖｅ  ｄｅｃｉｓｉｏｎ）」と名付けられた、メソッドの実行、もしくは変数メンバへのアクセスをブロックする決定、または、「ポジティブ決定（ｐｏｓｉｔｉｖｅ  ｄｅｃｉｓｉｏｎ）」と名付けられた、仮想マシンにメソッドを実行させる、もしくは変数メンバにアクセスさせる決定を行うステップと、
−  前記決定を仮想マシンに送信して、対応するアクセス試行をブロックするまたは許可するステップと
を含む。
【０００９】
非限定的実施形態によれば、この方法は、次の追加の特徴の１つまたは複数を含むことができる。
【００１０】
−  仮想マシンの起動または初期化（ＶＭ＿ｓｔａｒｔ、ＶＭ＿ｉｎｉｔ）を指示するイベントを受信すると、強制アクセス制御モジュールを構成するステップが実現される。
【００１１】
−  イベントが、コールバック機能をアクティブにする、標準化されたインストルメント化指向イベント（ｓｔａｎｄａｒｄｉｚｅｄ  ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ  ｏｒｉｅｎｔｅｄ  ｅｖｅｎｔ）である。
【００１２】
−  イベント受信が、仮想マシン内部（ｉｎｔｅｒｎａｌｓ）を直接変更する。
【００１３】
−  強制アクセス制御モジュールを構成するステップは、言語型とアクセス制御ラベルとの対応を定義するラベルポリシーファイルをロードするステップを含み、ラベルを追加するステップは、前記ラベルポリシーファイルによって実現される。
【００１４】
−  アクセス制御ラベルを追加するステップは、オブジェクトインスタンスとアクセス制御ラベルとの対応を含んだ外部データベースを使用することを含む。
【００１５】
−  決定を行うステップは、強制アクセス制御モジュールと外部決定エンジンとの協力によって実現される。
【００１６】
−  この方法は、外部データベースに以下を記録するステップを含む：
・呼び出されるメソッドに関する情報
・呼び出し元および呼び出し元に関する情報、例えばそれらの言語型およびそれらのアクセス制御ラベル、それらのインスタンス番号
・行われた決定
【００１７】
−  この方法は、ネガティブ決定の場合、要求されるメソッドの実行または変数メンバへのアクセスをブロックするために、仮想マシンによって例外を生成するステップを含む。
【００１８】
さらに、オブジェクト指向プログラムを実行するように構成された仮想マシンにおいて、強く型付けされた言語に基づき、強制アクセス制御を保証するための、以下を含む強制アクセス制御モジュールが提供される：
−  メソッド呼び出しおよび変数メンバアクセスのための強制的な経路（ｍａｎｄａｔｏｒｙ  ｐａｔｈ）であって、「ネガティブ決定」と名付けられた、前記メソッドの実行もしくは変数メンバへの前記アクセスをブロックする決定、または「ポジティブ決定」と名付けられた、仮想マシンに前記方法を実行させる、もしく前記変数メンバにアクセスさせる決定を仮想マシンに送信するように構成された参照モニタ。
−  「呼び出し元」と名付けられた、メソッドを呼び出している、もしくはアクセスを要求しているオブジェクト、および「呼び出し先」と名付けられた、メソッドに呼び出される、もしくはそのアクセスが要求されるオブジェクトに、呼び出し元および呼び出し先言語型に従って、アクセス制御ラベルを追加するように構成されたラベル付けエンジン。
−  前記ラベル、呼び出し元および呼び出し先のインスタンス番号、ならびにアクセスポリシーに従って、前記決定を行うように構成された決定エンジン。
【００１９】
非限定的実施形態によれば、強制アクセス制御モジュールは、次の追加の特徴の１つまたは複数を含むことができる。
【００２０】
−  強制アクセス制御モジュールは、標準的なプロトコルおよび標準的なインストルメント化インタフェースを介して仮想マシンと通信するように適合された、インストルメント化モジュール（ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ  ｍｏｄｕｌｅ）と名付けられた、部分的に仮想マシン外部のモジュールである。
【００２１】
−  ラベル付けエンジンは、呼び出し元および呼び出し先の言語型を要求するために仮想マシンと通信するように構成される。
【００２２】
−  ラベルエンジンは、オブジェクトインスタンスとアクセス制御ラベルとの対応を含んだ外部データベースと通信するように構成される。
【００２３】
−  決定エンジンは、外部決定エンジンと通信し、決定エンジンからの外部決定を待って、ポジティブ決定またはネガティブ決定を行うように構成される。
【００２４】
−  強制アクセス制御モジュールは、外部データベースに、呼び出されたメソッドに関する情報、例えば言語型、ならびに呼び出し元および呼び出し先のアクセス制御ラベル、それらのインスタンス番号、ならびに行われた決定などを記録するように構成されたトレースエンジンを含む。
【００２５】
次に本発明の諸実施形態に従った装置および／または方法の一部の実施形態について、単に一例として、また添付の図面を参照して説明する。
【図面の簡単な説明】
【００２６】
【図１】本発明の非限定的実施形態による方法を概略的に説明するフローチャートである。
【図２】本発明の非限定的実施形態による強制アクセス制御モジュールを概略的に説明する図である。
【発明を実施するための形態】
【００２７】
次の説明では、当業者によく知られている機能または構成について、これらが不必要な詳細で本発明を曖昧にすることから、詳細に説明しない。
【００２８】
図１は、本発明の非限定的実施形態による方法１００を説明するフローチャートを示す。この方法１００は、オブジェクト指向プログラムを実行するように構成された仮想マシンにおいて、強く型付けされた言語に基づき、強制アクセス制御を保証することを目的とする。より詳細には、この方法１００は、ポリシーが順守されない場合、前記仮想マシンによる第１のオブジェクトからのメソッドの実行、または、先のものとは異なる第２のオブジェクトからの変数メンバへのアクセスをブロックすることを目的とする。
【００２９】
この原理は、参照モニタが実装されることが可能であり、関連する言語がオブジェクト指向であって、メソッド呼び出しもしくはフィールドメンバアクセスが、インターセプトされ、ブロックされることが可能であるならば、例えばＪａｖａ仮想マシン（ＪＶＭ）、Ｄａｌｖｉｋ、Ｐｙｔｈｏｎ、またはＰＨＰなど、いかなる仮想マシンＶＭベースのシステムにも適用されることが可能である。
【００３０】
図２に表されるように、方法１００は、この非限定的実施形態では、部分的に仮想マシンＶＭ外部のモジュールである強制アクセス制御モジュールＩｎｓｔｒ＿ｍｏｄｕｌｅによって行われる。外部モジュールを使用することにより、仮想マシンＶＭを変更することが回避される。この構成では、仮想マシンＶＭと強制アクセス制御モジュールＩｎｓｔｒ＿ｍｏｄｕｌｅとの間の標準化されたインタフェースＩｎｓｔｒ＿Ｉｎｔｅｒｆが使用される。制御モジュールＩｎｓｔｒ＿ｍｏｄｕｌｅは、いくつかのイベント、すなわち少なくとも仮想マシンＶＭの起動ＶＭ＿ｓｔａｒｔまたは初期化ＶＭ＿ｉｎｉｔを指示するイベント、およびメソッド呼び出しＭｅｔｈ＿ｅｎｔｒｙまたは変数メンバへのアクセス要求を指示するイベントへの、サブスクリプション（ｓｕｂｓｃｒｉｐｔｉｏｎ）を取得する必要がある。
【００３１】
別の詳細ではない実施形態では、強制アクセス制御モジュールは、仮想マシンＶＭに完全に含まれることに留意されたい。制御モジュールを仮想マシンに含めると、パフォーマンスを向上させ、応答時間を削減することができる。
【００３２】
詳細な実施形態では、制御モジュールＩｎｓｔｒ＿ｍｏｄｕｌｅは、互いの間で通信しているいくつかのモジュールを含み、その機能についてさらに説明する：
−  参照モニタＲｅｆ＿ｍｏｎ。
−  ポリシーローダーモジュールＰｏｌ＿ｌｏａｄ。
−  ラベル付けエンジンＬａｂ＿ｅｎｇ。
−  決定エンジンＤｅｃ＿ｅｎｇ。
−  トレースエンジンＴｒ＿ｅｎｇ。
【００３３】
この方法１００は、以下を含む。
【００３４】
−  ステップ１において、仮想マシンＶＭがユーザのプログラムを実行する準備ができると、仮想マシンは起動イベントＶＭ＿ｓｔａｒｔまたは初期化イベントＶＭ＿ｉｎｉｔを生成し、これが制御モジュールＩｎｓｔｒ＿ｍｏｄｕｌｅの構成をトリガする。より正確には、アクセスポリシーＡｃｃ＿ｐｏｌを定義するアクセスポリシーファイルＡｃｃ＿ｒｕｌ＿ｆｉｌｅ、およびラベル付けポリシーＬａｂ＿ｐｏｌを定義するラベルポリシーファイルＬａｂ＿ｐｏｌ＿ｆｉｌｅが、ポリシーローダーモジュールＰｏｌ＿ｌｏａｄによってロードされる。アクセスポリシーＡｃｃ＿ｐｏｌおよびラベルポリシーＬａｂ＿ｐｏｌの概念について、さらに説明する。
【００３５】
−  ステップ２において、メソッド呼び出しＭｅｔｈ＿ｅｎｔｒｙまたは変数メンバへのアクセス要求を指示するイベントがあると、参照モニタＲｅｆ＿ｍｏｎが呼び出される。図１および図２は、呼び出し元ＣａｌＲと名付けられたオブジェクトによって呼び出され、呼び出し先ＣａｌＥと名付けられたオブジェクトを呼び出すメソッドＭｅｔｈの場合を取り上げている。
【００３６】
参照モニタＲｅｆ＿ｍｏｎは、メソッドが呼び出されるとき、または変数メンバへのアクセスが要求されるときの、強制的な経路であり、これは、仮想マシンＶＭ内で強制アクセス制御を実行するのに必要である。参照モニタＲｅｆ＿ｍｏｎは、呼び出し元ＣａｌＲおよび呼び出し先ＣａｌＥを識別して、それらの型シグネチャおよび要求される許可からセキュリティコンテキストを推論する。
【００３７】
Ｊａｍｅｓ  Ｐ．Ａｎｄｅｒｓｏｎによって定義された参照モニタＲｅｆ＿ｍｏｎは、エンティティ間のアクセス要求を仲介して、アクセス制御ポリシーを実施する検証メカニズムであることに留意されたい。定義により、参照モニタは、強制的なものであり、耐不正変更（ｔａｍｐｅｒｐｒｏｏｆ）であり、十分に小さいものであると公式に証明されている。
【００３８】
−  ステップ３において、ラベル付けエンジンＬａｂ＿ｅｎｇは開始される。ラベル付けエンジンＬａｂ＿ｅｎｇは、呼び出し先ＣａｌＥおよび呼び出し元ＣａｌＲに、アクセス制御ラベルＬａｂＥおよびＬａｂＲを追加することを目的とする。ラベルは、同じセキュリティ要件を有するエンティティの集合を指し示す一意のセキュリティ識別子である。ラベル付けメカニズムは、エンティティをあらかじめ定められたラベルに関連付ける。ラベリゼーション（Ｌａｂｅｌｉｚａｔｉｏｎ）は、ラベル付けポリシーＬａｂ＿ｐｏｌに従って実行される。例えば、ラベル付けポリシーは、言語の継承原理に基づくことができる。これは、所与のクラスのセキュリティラベルが、デフォルトによりそのスーパークラスのセキュリティラベルから継承されることを意味する。
【００３９】
この非限定的実施形態では、ラベル付けエンジンＬａｂ＿ｅｎｇは、まず外部データベースＬａｂ＿ｃａｃｈｅに前記データベースは、呼び出し元ＣａｌＲと呼び出し先ＣａｌＥのラベルがわかっているかを問う。ここで前記データベースはオブジェクトインスタンスとアクセス制御ラベルとの間の対応を含む。このステップはオプションであるが、呼び出し元ＣａｌＲおよびＣａｌＥがすでにメソッド呼び出しに含まれていた場合、パフォーマンスを向上させる。外部データベースＬａｂ＿ｃａｃｈｅが、所望のラベルを格納していない場合、ラベル付けエンジンＬａｂ＿ｅｎｇは、呼び出し元ＣａｌＲおよびＣａｌＥにそれらの型Ｔｙｐ＿ＣａｌＲ、Ｔｙｐ＿ＣａｌＥに従って制御ラベルＬａｂＥおよびＬａｂＲを追加する。実際には、ラベルポリシーＬａｂ＿ｐｏｌは、アクセス制御ラベルを有する言語型間の対応を定義する。次いで、ラベル付けエンジンＬａｂ＿ｅｎｇは、対応を外部データベースＬａｂ＿ｃａｃｈｅに格納する。
【００４０】
−  ステップ４において、決定エンジンＤｅｃ＿ｅｎｇが開始されて、前記アクセス制御ラベルＬａｂＥおよびＬａｂＲ、呼び出し元のインスタンス番号Ｉｎｓｔ＿Ｎｕｍ＿ＣａｌＲおよび呼び出し先のインスタンス番号Ｉｎｓｔ＿Ｎｕｍ＿ＣａｌＥ、アクセスポリシーＡｃｃ＿ｐｏｌ、ならびにアクセス許可（例えば、読み取り／書き込み）に従って、「ネガティブ決定」と名付けられた、メソッドＭｅｔｈの実行をブロックする決定Ｄｅｃ、または「ポジティブ決定」と名付けられた、仮想マシンＶＭにメソッドＭｅｔｈを実行させる決定を行う。
【００４１】
この非限定的実施形態では、外部決定エンジンＥｘｔ＿ｄｅｃ＿ｅｎｇが、決定エンジンＤｅｃ＿Ｅｎｇに接続され、決定エンジンＤｅｃ＿Ｅｎｇは、補足的決定について、この第三者アクセス制御エンジンＥｘｔ＿ｄｅｃ＿ｅｎｇに依存する。この場合、局所決定Ｌｏｃ＿Ｄｅｃが外部決定エンジンＥｘｔ＿ｄｅｃ＿Ｅｎｇに送信され、外部決定エンジンＥｘｔ＿ｄｅｃ＿Ｅｎｇが、局所決定Ｌｏｃ＿Ｄｅｃに従って外部決定Ｅｘｔ＿Ｄｅｃを行う。アクセスポリシーをかいくぐることを目的とする推移的な情報フローを防ぐために、外部決定エンジンが、特に重要である。言い換えれば、外部決定エンジンＥｘｔ＿ｄｅｃ＿ｅｎｇは、間接的なアクセス違反を制御する。これは、決定エンジンＤｅｃ＿Ｅｎｇと外部決定エンジンＥｘｔ＿ｄｅｃ＿ｅｎｇとの協力の結果、可能である。
【００４２】
次の使用事例は、この状況を説明する。この使用事例は、２つのＪａｖａオブジェクト、管理者（Ａｄｍｉｎ）およびユーザ（Ｕｓｅｒ）と、機密データ「秘密」とを含む。ラベル付けポリシーの結果、ユーザのオブジェクトに関して、管理者のオブジェクト機密性を保証することが目的である。アクセス制御ポリシーＡｃｃ＿ｐｏｌが、Ｍａｉｎから管理者およびユーザへのメソッド呼び出しを許可する。結果として、外部決定エンジンＥｘｔ＿ｄｅｃ＿ｅｎｇなしで、管理者からＭａｉｎへの、およびＭａｉｎからユーザへの直接的情報フローが許可されるが、直接管理者からユーザへは許可されない。実際には、管理者とユーザとの間のメソッド呼び出しが、デフォルトによりアクセスポリシーＡｃｃ＿ｐｏｌによって定義される。外部決定エンジンＥｘｔ＿ｄｅｃ＿ｅｎｇは、オブジェクトのインスタンス間のすべての情報フローを監視することによって、ユーザがＭａｉｎを介して秘密を取得することを防止することを可能にする。
【００４３】
−  ステップ５において、決定Ｄｅｃがポジティブである、すなわち、決定エンジンＤｅｃ＿ｅｎｇが、アクセスポリシーＡｃｃ＿ｐｏｌに従ってメソッドＭｅｔｈ呼び出しを許可する場合、参照モニタＲｅｆ＿ｍｏｎは、仮想マシンＶＭが呼び出されたメソッドＭｅｔｈを実行するよう要求される。反対に、決定Ｄｅｃがネガティブである、すなわち決定エンジンＤｅｃ＿Ｅｎｇがメソッド呼び出しを許可しない場合、参照モニタＲｅｆ＿ｍｏｎは、仮想マシン例外を生成して、メソッドＭｅｔｈ呼び出しをブロックするよう要求される。
【００４４】
メソッド呼び出しの代わりに変数メンバへのアクセス要求の場合は、ポジティブ決定は、アクセスが許可されることを意味し、ネガティブ決定は、アクセスが拒否されることを意味することに留意されたい。
【００４５】
本発明の非限定的実施形態では、呼び出されたメソッドＭｅｔｈに関する情報、呼び出し元ＣａｌＲおよび呼び出し先ＣａｌＥに関する情報、例えばその言語型Ｔｙｐ＿ＣａｌＥ、Ｔｙｐ＿ＣａｌＲ、およびそのアクセス制御ラベルＬａｂＥおよびＬａｂＲ、そのインスタンス番号Ｉｎｓｔ＿Ｎｕｍ、ならびに行われた決定Ｌｏｃ＿Ｄｅｃ、Ｅｘｔ＿Ｄｅｃは、トレースエンジンＴｒ＿ｅｎｇによって外部データベースＴｒ＿ｄａｔａｂａｓｅに記録されることに留意されたい。より詳細には、トレーシングエンジンＴｒ＿ｅｎｇは、メソッドＭｅｔｈがログに記録されなければならないかどうかをポリシーからチェックする。記録されなければならない場合、抽出された情報は、アクセス要求としてフォーマットされ、トレースログが作成される。
【００４６】
Ｊａｖａ仮想マシンに専用のこのＭＡＣモデルの、ＳＥＪａｖａと名付けられた第１の実装がテストされた。ＳＥＪａｖａは、各メソッド呼び出しおよびフィールドアクセスを仲介することによって、２つのＪａｖａオブジェクト（クラスまたはクラスインスタンス）間のすべての情報フローを制御する。セキュリティコンテキストは、Ｊａｖａオブジェクトに基づき、ラベル付けメカニズムは、Ｊａｖａオブジェクト型シグネチャに依存する（Ｊａｖａの型シグネチャに関する詳細についてはＯｒａｃｌｅが提供しているＪａｖａ仕様参照）。ＳＥＪａｖａは、ＪＶＭＴＩ仕様を使用して、すなわちＪＶＭ内部をパッチせずに、ＯｐｅｎＪＤＫのＪａｖａ仮想マシンで実装されている。ＪＶＭＴＩは、互換性のある仮想マシンを備えることを可能にし、主にプロファイリングの目的で使用される、Ｏｒａｃｌｅが提供している標準Ｊａｖａ  ＡＰＩである。ＪＶＭＴＩは、すべてのメソッド呼び出しに対してＳＥＪａｖａのエンジンを呼び出すためにＡｎｄｅｒｓｏｎの参照モニタとして使用されるように調整されている。このエンジンは、メソッド呼び出しがＳＥＪａｖａセキュリティポリシーを満たすかどうかをチェックする。標準インストルメント化インタフェース（ここではＪＶＭＴＩ）の使用により、仮想マシン内の参照モニタの実装が容易になる。
【００４７】
主としてメソッドと外部リソース（例えばファイル）との間のフローを制御するＪＡＡＳと対照的に、ＳＥＪａｖａは、以下を可能にする：
−  すべてのＪａｖａオブジェクト間のフローを制御すること。
−  「アクセス制御実施」段階の前に、「学習」段階の間に必要とされるセキュリティポリシーを学習すること。
−  ＳＥＪａｖａを外部参照モニタ、例えばＰＩＧＡに接続すること。ＰＩＧＡは、以下に詳述されている。
【００４８】
Ｊ．Ｂｒｉｆｆａｕｔ、「Ｆｏｒｍａｌｉｓａｔｉｏｎ  ｅｔ  ｇａｒａｎｔｉｅ  ｄｅ  ｐｒｏｐｒｉｅｔｅｓ  ｄｅ  ｓｅｃｕｒｉｔｅ  ｓｙｓｔｅｍｅ：  ａｐｐｌｉｃａｔｉｏｎ  ａ  ｌａ  ｄｅｔｅｃｔｉｏｎ  ｄ‘ｉｎｔｒｕｓｉｏｎｓ」、ｔｈｅｓｅ  ｄｅ  ｄｏｃｔｏｒａｔ  ｄ’ｉｎｆｏｒｍａｔｉｑｕｅ、ｓｏｕｔｅｎｕｅ  ｌｅ  １３  ｄｅｃｅｍｂｒｅ  ２００７、ＬＩＦＯ  Ｕｎｉｖｅｒｓｉｔｅ  ｄ‘Ｏｒｌｅａｎｓ、Ｆｒａｎｃｅ
【００４９】
Ｊ．Ｂｒｉｆｆａｕｔ、Ｃ．Ｔｏｉｎａｒｄ、Ｍ．Ｐｅｒｅｓ、「Ａ  ｄｙｎａｍｉｃ  Ｅｎｄ−ｔｏ−Ｅｎｄ  Ｓｅｃｕｒｉｔｙ  ｆｏｒ  Ｃｏｏｒｄｉｎａｔｉｎｇ  Ｍｕｌｔｉｐｌｅ  Ｐｒｏｔｅｃｔｉｏｎｓ  ｗｉｔｈｉｎ  ａ  Ｌｉｎｕｘ  Ｄｅｓｋｔｏｐ」、コラボレーションおよびセキュリティ（Ｃｏｌｓｅｃ  ２０１０）ワークショップ、ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ２０１０  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｓｙｍｐｏｓｉｕｍ  ｏｎ  Ｃｏｌｌａｂｏｒａｔｉｖｅ  Ｔｅｃｈｎｏｌｏｇｉｅｓ  ａｎｄ  Ｓｙｓｔｅｍｓ  （ＣＴＳ  ２０１０）、ＵＳＡ
【００５０】
実際の製品については、セキュリティモデリングは、ソフトウェアの実行時の観察に基づいて支援されることになる。デフォルトの、および最初のラベル付けは、アプリケーションのＪａｖａ型階層の葉（ｌｅａｖｅｓ）に基づくことになる。各型は、その一意のセキュリティコンテキストに割り当てられ、異なる型のオブジェクトのすべてのインスタンス間の情報フローを観察することを可能にする。これは、現在のＳＥＪａｖａですでに実装されている事例である。
【００５１】
結果は、このアプリケーションのセキュリティモデルを作成する担当者に表示される。ユーザは、既存のセキュリティコンテキストを結び付ける、または分割することを選択することができる。ユーザはまた、許可される情報および禁止される情報を選択し、したがってアクセス制御ルールを作成する。
【００５２】
ＳＥＤａｌｖｉｋと名付けられた第２の実装がテストされた。上述と同じセキュリティモデルに基づくこの実装における唯一の違いは、それが仮想マシンのインタープリタおよびデバッガに組み込まれるように書かれたことである。これは、たとえＶＭのバイトコードが異なっていても、使用言語、Ｊａｖａ（セキュリティモデル）が同じであるので可能であった。
【００５３】
結論として、この方法は、Ｊａｖａアプリケーションの効率的な隔離メカニズムを提供する。実際に、仮想マシンに利用可能な最先端のセキュリティ機能は、全世界的に、データ汚染（ｄａｔａ  ｔａｉｎｔｉｎｇ）、仮想マシンプログラム分析のインタープリタ状態の仮想マシン詳細検査に基づいている。しかし、それらの大部分は、動的ポリシーを有するリアルタイムの仮想マシンプログラム実装を行うことができない。
【００５４】
さらに、仮想マシン用の現在のセキュリティ機能は、開発者および／または管理者に、各プログラムが実行する特定のセキュリティポリシーを提供するよう強いる。この方法１００は、セキュリティコンテキストおよび必要とされるルールを動的に計算できるようにする。第１に、セキュリティコンテキストは、クラス命名規則、すなわちシグネチャから導出される。第２に、参照モニタＲｅｆ＿ｍｏｎは、すべてのメソッド呼び出しを検査する。したがって、方法１００は、拒否された呼び出しをすべてＳＥＪａｖａルールに変換できるようにする。
【００５５】
以下に留意することが重要である：
−  アプリケーションのソースコードを有することが求められない。
−  情報フローを観察するためにソースコードを変更することが求められない。
−  仮想マシンは、変更を必要としない（ＪＶＭＴＩサポートに依存）。
したがって、提案される方法およびその実装は、以前から存在するアプリケーションまたはソフトウェア製品に適用可能である。
【００５６】
既存のソリューションについて、３つの改善点がある：
−  すべてのＪａｖａオブジェクト間で情報フローの制御が実行される。
−  このソリューションは、いかなるコードの事前処理、分析、またはいかなるインストルメント化も必要としない。
−  定義されたポリシーは、新しいプログラムに十分に適用可能である、および／または直接学習されることが可能である。
【図１】
0005990646.tif 000002
【図２】
0005990646.tif 000003