JP2004303242A - 高信頼性コンピューティングシステムにおけるセキュリティ属性 - Google Patents

Abstract

【課題】 １つまたは複数の論理的被保護コンピューティング環境を含む高信頼性コンピューティングプラットフォームを備えるシステムを提供する。
【解決手段】 それぞれの論理的被保護コンピューティング環境は上記システムによってサポートされる少なくとも１つのサービスまたはプロセスに関連する。システムは、それぞれの上記論理的被保護コンピューティング環境のオペレーションを制御する１つまたは複数のセキュリティルールを含む所定のセキュリティポリシを上記高信頼性コンピューティングプラットフォーム上にロードするように構成される。上記論理的被保護コンピューティング環境の少なくとも１つに対するセキュリティルールは、その論理的被保護コンピューティング環境に関連するサービスまたはプロセスが開始される時にそのサービスまたはプロセスに適用されるべきセキュリティ属性を規定する実行制御ルールを含む。
【選択図】 図３

Description

［発明の分野］
本発明は、包括的に、信頼性の高いコンピューティングシステム、すなわち高信頼性コンピューティングシステムで使用されるセキュリティポリシに関し、特に、システムリソースへの許容されるアクセスに関するセキュリティ属性を規定する方法および装置に関する。

［発明の背景］
商用アプリケーションでは、クライアントコンピューティングプラットフォームは通常、その挙動がローカルまたはリモートのエンティティによる変更に対して脆弱であるような環境で動作する。
プラットフォームのこの潜在的なセキュリティの欠如は、例えば電子商取引の目的で、セキュリティがあればそのプラットフォームを使用しても構わないと考えているローカル当事者や、セキュリティがあればそのプラットフォームと通信するかもしれないリモート当事者によるその使用を制約している。

本出願人による同時係属中の開示ＷＯ００／４８０６３（参照により本明細書に援用する）には、組込みハードウェアおよびソフトウェアコンポーネントの形態で「高信頼性コンポーネント」を有するコンピューティングプラットフォームを備える「高信頼性コンピューティングプラットフォーム」の概念が開示されている。
この文書には、高信頼性デバイス（ＴＤ、Trusted Device）または高信頼性プラットフォームモジュール（ＴＰＭ、Trusted Platform Module）を用いて、完全性メトリックの信頼できる測定および報告により、コンピューティング装置の完全性(integrity)の検証を可能にすることが記載されている。
ＴＤ／ＴＰＭは、Trusted Computing Platform Alliance（ＴＣＰＡ）仕様に準拠している。
例えば非特許文献１(www.trustedpc.org)を参照されたい。

高信頼性デバイスまたは高信頼性プラットフォームモジュールは、その内部でサービスまたはプロセスを実行することが可能な１つまたは複数の論理的に保護されたコンピューティング環境（論理的被保護コンピューティング環境）すなわち「コンパートメント」を含み得る。
コンパートメント内でのアクションまたは特権は、特に、コンパートメントの外部に効果を有するメソッドおよびオペレーション（例えば、ネットワークアクセスやコンパートメントの外部のファイルへのアクセスを要求するメソッド）を実行するプロセスの能力を制限するように制約される。
また、コンパートメント内のプロセスまたはサービスのオペレーションは、外部の影響による干渉およびのぞき見(prying)から高度に隔離されて実行される。
各コンパートメントは、オペレーティングシステムカーネルによって制御されるオペレーティングシステムコンパートメントであってもよい。
これは、コンパートメント化オペレーティングシステムまたは高信頼性オペレーティングシステムとも呼ばれる。

高信頼性オペレーティングシステムは、機密（軍事）情報を取り扱いかつ処理するために設計された形態で数年前から利用可能となっており、オペレーティングシステムのカーネルによって実施される閉じ込めメカニズムを用いて、ファイル、プロセスおよびネットワークコネクションのようなコンピューティングプラットフォームのリソースに対する強制的アクセス制御を行う。
オペレーティングシステムは、リソースにラベルを付加し、それらのラベル値に基づいて、リソース間の許容される相互作用を統制するセキュリティポリシを実施する。
多くの高信頼性オペレーティングシステムは、Bell-Lapadulaモデルに基づくセキュリティポリシを適用している。
このモデルは、非特許文献２（C I DaltonとJ F GriffinによるComputer Networks and ISDN Systems 29 (1997) 1799-1808に発表された論文「Applying Military Grade Security to the Internet」）に記載されている。

いずれにしても、多くの高信頼性コンピューティングプラットフォームは、比較的簡便な形態のオペレーティングシステムコンパートメントを採用している。
一般的に、保護したいコンピューティングプラットフォームの各リソースに、そのリソースが属するコンパートメントを示すラベルが与えられる。
あるコンパートメントからのリソースが別のコンパートメントからのリソースと干渉しないようにするために、セキュリティポリシを組み込んだ強制的アクセス制御がホストオペレーティングシステムのカーネルにより実行される。
セキュアなシステムでは、システムリソースへのアクセスは、セキュリティまたはサブジェクト属性によって規定される。

上記のセキュリティポリシは、セキュリティルールの形態で表現されることが多い（各セキュリティルールは一般に、セキュリティ属性を規定する命令行を含む）。
一般的に、１つまたは複数のセキュリティルールが１つのコンパートメントに関連する。
また、各コンパートメントが１つまたは複数のサービスに関連してもよい。

従来、セキュリティルールは、プラットフォームの起動シーケンス中のできるだけ早いうちにロードし、サービスまたはプロセスが起動されたら直ちに関連するセキュリティルールが有効になるようにするのが望ましいと考えられている。
そこで、従来技術のシステムでは、すべてのセキュリティルールがシステム初期化時にプラットフォームにロードされることが多い。
すなわち、完全なセキュリティルールがシステム起動時にロードされる。
したがって、セキュリティ属性はセキュリティ初期化によって割り当てられることになり、特別の権限を有するプロセスによらなければ変更することができない。

セキュアなオペレーティングシステムでは、多くの場合（例えば、プロセスが別のプログラムをフォークして実行する時には、サービスがコンパートメントに入るためにセキュリティＩＤを必要とするので）、いくつかのポイントでプログラムのセキュリティ属性を変更する（すなわち「セキュリティ遷移」を実行する）ことが必要になる。
したがって、従来技術のシステムでは、サービスを開始する方法を変更して（すなわち、サービスを開始するスクリプト、制御プログラムまたは他のファシリティを変更して）、そのサービスが確実に正しいコンパートメントに入るようにするか、またはこの問題に対処するために何らかの形のマッピングファンクションを構成するかのいずれかが必要である。

すなわち、いくつかのポイントにおけるプログラムのセキュリティ属性の変更は、従来は、属性を変更するために特別のシステムコールを用いて、または高信頼性ゲートウェイプログラムを用いて、明示的になされているが、これは不便である。
というのは、これは、特別のシステムコールを含めるため、または必要とされるプログラムの代わりに高信頼性ゲートウェイプログラムを呼び出すために、呼出し側プログラムを（上記のように）変更することを伴うからである。
また、呼出し側プログラムが被呼出し側プログラムの属性を変更することを可能にする追加のセキュリティ属性を呼出し側プログラムに与えることも必要になることがある。
www.trustedpc.org C I DaltonとJ F GriffinによるComputer Networks and ISDN Systems 29 (1997) 1799-1808に発表された論文「Applying Military Grade Security to the Internet」

本発明によれば、高信頼性コンピューティングプラットフォームおよび１つまたは複数の論理的被保護コンピューティング環境を備えるシステムであって、それぞれの論理的被保護コンピューティング環境は該システムによってサポートされる少なくとも１つのサービスまたはプロセスに関連し、該サービスまたはプロセスが開始される時に該少なくとも１つのサービスまたはプロセスのうちの１つまたは複数に適用されるべきセキュリティ属性を規定する所定のセキュリティポリシを規定するデータを該高信頼性コンピューティングプラットフォーム上にロードするように構成されるシステムが提供される。

１実施形態において、ポリシは、論理的被保護コンピューティング環境のオペレーションを制御する１つまたは複数のセキュリティルールを含む。

好ましくは、論理的被保護コンピューティング環境の少なくとも１つに対するセキュリティルールは、セキュリティ属性を規定する実行制御ルールを含む。

また、本発明によれば、高信頼性コンピューティングプラットフォームおよび１つまたは複数の論理的被保護コンピューティング環境を含むシステムにおいてセキュリティポリシを適用する方法であって、それぞれの論理的被保護コンピューティング環境は該システムによってサポートされる少なくとも１つのサービスまたはプロセスに関連し、該方法は、該論理的被保護コンピューティング環境の少なくとも１つに関連するサービスまたはプロセスを開始するステップと、該サービスまたはプロセスの開始後に、該サービスまたはプロセスにセキュリティ属性を適用することにより該少なくとも１つの論理的被保護コンピューティング環境のオペレーションを制御するステップとを含む。

好ましくは、属性は実行制御ルールによって規定され、該実行制御ルールはポリシの少なくとも一部を実施するセキュリティルールに含まれる。

理解されるように、本発明との関連では、「信頼」という用語は次のような意味で使用される。
すなわち、何かが「高信頼性」であるとは、それが常に本来の目的で期待通りに挙動する場合をいう。

このように、本発明は、論理的被保護コンピューティング環境（すなわち「コンパートメント」）に対するセキュリティルール内に実行制御ルール（以下「ｅｘｅｃルール」という）を含めることを可能にする。
ｅｘｅｃルールは、サービスまたはプロセスが開始される時にそのサービスまたはプロセスに適用されるべきセキュリティ属性を規定または変更する。
これによって、既存のプログラムを変更したり、セキュリティ的に高信頼性のゲートウェイプログラムを使用したりする必要がなくなる。

セキュリティ属性は、サービスまたはプロセスが開始された時にそれぞれの論理的被保護コンピューティング環境に提供されるべき１つまたは複数の権限；サービスまたはプロセスが開始される時にそれぞれの論理的被保護コンピューティング環境の権限を変更する１つまたは複数のファンクション；サービスまたはプロセスが開始される時にそのサービスまたはプロセスが指定された論理的被保護コンピューティング環境内に配置されて実行されるようにするファンクション；サービスまたはプロセスが実行されるべきユーザｉｄ、グループｉｄ、または論理的被保護コンピューティング環境を変更することができるファンクション；および／またはそれぞれのサービスまたはプロセスがｃｈｒｏｏｔされる先のディレクトリを規定するファンクション、を含み得る。
当業者には理解されるように、「ｃｈｒｏｏｔ」という用語は、ルートディレクトリ（１）を、カレントプロセスの存続期間中、そのデフォルト以外のものにするコマンドのことである。

セキュリティ属性が、プロセスまたはサービスが開始された時にそれぞれの論理的被保護コンピューティング環境の権限を変更する１つまたは複数のファンクションを含む場合、当該ファンクションは、指定された権限を引き上げるか、または引き下げてもよい。
本発明の一実施形態では、権限のセットをフィルタリングする手段が提供され、当該権限のうちそのフィルタリング手段によって選択される１つまたは複数の権限のみが変更されてもよい。

各実行制御ルールは、好ましくは、関連する論理的被保護コンピューティング環境を識別することによって、その実行制御ルールが適用されるサービスまたはプロセスを指定する。
その結果、ルールは、論理的被保護コンピューティング環境を指定するサービスおよびプロセスのみに適用される。

好ましくは、サービスまたはプロセスを構成するファイルはリードオンリであり、好ましくは、このようなファイルの名前を変更する、システムにより実行されるオペレーションを監視する手段が提供される。

以下、本発明の一実施形態が、単なる例として、添付図面を参照して説明される。

［発明の詳細な説明］
以下の説明では、本発明の十分な理解を提供するために数多くの具体的詳細が記載される。
しかし、当業者には明らかなように、本発明はこれらの具体的詳細に限定されることなく実施されてもよい。
他の場合、既知の方法および構造は、本発明を不必要に分かりにくくすることがないように、詳細には記載されていない。

本発明の一実施形態を実行するのに一般的に好適なタイプの高信頼性コンピューティングプラットフォームが、２０００年２月１５日に出願された「Trusted Computing Platform」と題する本出願人の国際特許出願ＰＣＴ／ＧＢ００／００５２８に詳細に記載されており、その内容は参照により本明細書に援用される。
この文書には、高信頼性コンピューティングプラットフォームの構成の本質的要素、およびコンピューティングプラットフォームの状態を当該プラットフォームのユーザに知らせる完全性メトリックを提供する際のその役割、ならびに当該メトリックをユーザに通信することが記載されている。

簡単に述べれば、図面の図１を参照すると、高信頼性コンピューティングプラットフォーム１０は、キーボード１４、マウス１６および視覚表示装置（ＶＤＵ）１８の標準的機能を含み、これらはプラットフォームの物理的な「ユーザインタフェース」を提供する。
高信頼性プラットフォームのこの実施形態はスマートカードリーダ１２も含むが、これは本発明のすべての実施形態に必須ではない。
スマートカードリーダ１２のそばに、高信頼性プラットフォームとの高信頼性ユーザ対話を可能にするスマートカード１９が図示されている（この態様は、２０００年３月３日に出願された「Smartcard User Interface for Trusted Computing Platform」と題する本出願人の国際特許出願ＰＣＴ／ＧＢ００／００７５１にさらに記載されており、その出願の内容は参照により本明細書に援用される）。
プラットフォーム１０には複数のモジュール１５がある。
これらは、当該プラットフォームに適した、実質的に任意の種類の高信頼性プラットフォームの他の機能要素である（このような要素の機能的意味は本発明とは直接の関連性がないので、本明細書ではこれ以上説明しない）。

図面の図２を参照すると、高信頼性コンピューティングプラットフォーム１０のマザーボード２０は、（標準的なコンポーネントのうちでも特に）メインプロセッサ２１、メインメモリ２２、高信頼性デバイス２４、データバス２６ならびにそれぞれの制御ライン２７およびアドレスライン２８、プラットフォーム１０のためのＢＩＯＳプログラム（これは、リセット後に、その内部でオペレーティングシステムプログラムが実行されることになる適切な環境を構築する）を含むＢＩＯＳメモリ２９、ならびに入出力（Ｉ／Ｏ）デバイス２３を含む。
Ｉ／Ｏデバイス２３は、マザーボードのコンポーネントと、スマートカードリーダ１２、キーボード１４、マウス１６およびＶＤＵ１８との間の対話を制御する。
メインメモリ２２は通常、ランダムアクセスメモリ（ＲＡＭ）である。
動作において、プラットフォーム１０は、ハードディスク（図示せず）からＲＡＭにオペレーティングシステムをロードする。

そこで、リセット後、メインプロセッサは最初に、高信頼性デバイスによって制御される。
すると、高信頼性デバイスは、プラットフォーム固有のＢＩＯＳプログラムに制御を渡し、このＢＩＯＳプログラムが通常通りすべての入出力デバイスを初期化する。
ＢＩＯＳプログラムが実行された後、制御はオペレーティングシステムプログラムに渡される。
オペレーティングシステムプログラムは通常、ハードディスクドライブ（図示せず）からメインメモリ２２にロードされる。
ＢＩＯＳブートブロックが高信頼性デバイス２４内に含まれることが強く望まれる。
これは、完全性メトリックの取得の妨害（これは不正なソフトウェアプロセスが存在する場合に起こり得る）を防ぐとともに、ＢＩＯＳ（たとえ正しくても）がオペレーティングシステムのための適切な環境を構築できない状況を不正なソフトウェアプロセスが作り出すことを防ぐ。

高信頼性デバイス２４の構成は、本出願人による前述の国際特許出願ＰＣＴ／ＧＢ００／００５２８にさらに詳細に記載されている。
高信頼性デバイスの具体的構成は本発明とは直接の関連性がないので、本明細書ではこれ以上説明しない。

高信頼性コンピューティングプラットフォームは、いったん起動された後は、コンパートメント化すなわち高信頼性オペレーティングシステムを有することになる。
つまり、オペレーティングシステムによってサポートされる必要のある１つまたは複数のサービスまたはプロセスが、論理的被保護コンピューティング環境であるコンパートメント内で実行される。
既に述べたように、コンパートメント内でのアクションまたは特権は、特に、コンパートメントの外部に効果を有するメソッドおよびオペレーション（例えば、ネットワークアクセスやコンパートメントの外部のファイルへのアクセスを要求するメソッド）を実行するプロセスの能力を制限するように（セキュリティポリシによって）制約される。
さらに、コンパートメント内のプロセスのオペレーションは、外部の影響による干渉およびのぞき見から高度に隔離されて実行される。

好ましい一実施形態では、コンパートメントは、オペレーティングシステムカーネルによって制御されるオペレーティングシステムコンパートメントであり、既に述べたように、これは、コンパートメント化オペレーティングシステムまたは高信頼性オペレーティングシステムとも呼ばれる。

コンパートメントとネットワークリソースの間の通信は、ＴＣＰ／ＵＤＰのようなトランスポートメカニズムへの狭いカーネルレベル制御のインタフェースを通じて行われる。
これらの通信インタフェースへのアクセスは、コンパートメントごとに指定されたルールによって統制される。
カーネル内の適当なポイントで、例えばどのコンパートメントがどのコンパートメントのリソースにアクセスすることが許容されるかを示すルールのテーブルを参照する動的ロード可能セキュリティモジュールへのフックを用いることにより、アクセス制御チェックが実行される。
コンパートメント間アクセスが行われることを明示的に許容するルールがない場合、アクセス試行はカーネルによって拒否される。
ルールは、別のコンパートメントのリソースにアクセスすることが明示的に許容されたコンパートメントを除いて、個別のコンパートメント間の強制的セグメンテーションを実施する。

図面の図３を参照すると、本発明によるプロセスの例示的な一実施形態はステップ１００から開始され、プラットフォームの起動が実行される。
起動時に、プラグ式認証モジュール（ＰＡＭ）として知られるセキュリティモジュールをロードするためのスクリプトが実行され、２個の入力ファイルがメモリにロードされる。
これらの２個の入力ファイルはそれぞれ、コンパートメント名と番号の間のマッピング、およびネットワークインタフェース名とネットワークインタフェース番号の間のマッピングである。
プラットフォームは、システム上に構成されるコンパートメントごとに１個ずつの、いくつかのサブディレクトリを含むディレクトリを含み、この時点で、システム初期化（のみ）に関連するコンパートメントに関連するサブディレクトリがアクセスされる。
また、これらのサブディレクトリにわたって反復されるもう１つのスクリプトが実行される。
このスクリプトは、システム初期化に関連するコンパートメントをロードするとともに、それぞれのロードされたコンパートメントに関連するセキュリティルールをロードする。

ステップ１０２で、セキュリティコンフィグレーションがロードされる。

ステップ１０６で、システムはサービスを開始することを決定し、（ステップ１０８で）そのサービスに関連するコンパートメントがロードされるとともに、（ステップ１１０で）付随するセキュリティルールがロードされる。
セキュリティルールには、１つまたは複数のｅｘｅｃルール、すなわち、サービスまたはプロセスが実行された後でそれに適用されるルールが含まれてもよい。
これらのｅｘｅｃルールはステップ１１２で適用される。

ｅｘｅｃルールは２つの主要な用途を有する。
第１に、それらは、プロセスが開始される時にプロセスが有するべきセキュリティ属性を規定するために使用可能である（ステップ１１４）。
一例として、次のｅｘｅｃルールを考える。

exec[ from.comp system;
filename /sbin/mingetty;
comp system;
permitted.raise CAP_MAC_ADMIN
CAP_MAC_SETCID ]

このように、「filename /sbin/mingetty」によって識別されるプロセスが「system」コンパートメント内で実行されている場合、そのコンパートメントに特権「CAP_MAC_ADMIN」および「CAP_MAC_SETCID」が与えられるため、ＰＡＭは、各ユーザが正しい特権を取得することを保証することができる。
すなわち、ＰＡＭには、必要な特権を全ユーザに与える能力が付与される。
より詳細には、ユーザログインを制御するプログラムが提供され、ＰＡＭモジュールがログイン時に実行されて、ユーザのログインに対してユーザのコンパートメントおよび権限を設定する。
これは特権オペレーションであるため、ユーザログインを制御するプログラムは規定された権限（CAP_MAC_ADMINおよびCAP_MAC_SETCID）を有する必要がある。
それにより、それらの権限はＰＡＭを実行するプロセスによって継承され、そのプロセスはログインを正しく設定するための特権を有する。

第２に、ｅｘｅｃルールは、プロセスがどこで実行されるべきかを規定するマッピングを提供するために使用可能である。
そこで例えば、サービスａがコンパートメントＡで実行される場合を考える。
コンパートメントＡがオープンまたはロードされると、そのコンパートメントに関連するルールもまたロードされる。
それらのルール内には、サービスａが開始される時に、それをコンパートメントＡ内で実行することを指定するｅｘｅｃルールがあってもよい。
その場合、そのルールが（ステップ１１６で）適用される。
こうして、サービスａは通常通り開始されることが可能であり（したがってサービスａは変更される必要がない）、コンパートメントＡがロードされる時に関連するｅｘｅｃルールがロードされる正しいコンパートメントに移動される。
各ｅｘｅｃルールは、影響を受けるファイル（複数可）および当該ルールが適用されるコンパートメントを指定するので、ｅｘｅｃルールを使用することにより、高信頼性ゲートウェイを使用することが不要になる。

要約すれば、本発明のこの例示的実施形態によるｅｘｅｃルールは、次のような、プロセスのセキュリティ関連プロパティを制御する：
・ｕｉｄ：結果として得られるユーザｉｄ（指定がなければ変更されない）
・ｇｉｄ：結果として得られるグループｉｄ（指定がなければ変更されない）
・権限：有効なセット、許容されるセットおよび継承可能なセットに対する権限モディファイア。
（権限は、引き上げられ、引き下げられ、またはフィルタリングされ得る。
引き上げられた権限はオンに設定される。
引き下げられた権限はオフに設定される。
フィルタセット内の権限は変更されず、フィルタセット内にない権限は引き下げられる。
権限モディファイアは、それがなければシステム管理者の立場からなされ得る種々の（機密に関わる）ことを制限するために使用可能である。
権限制限は、無権限者がこれらの権限を取得しないように、「ｒｏｏｔ」権能を制限するために使用可能である。）
・コンパートメント：結果として得られるコンパートメント（指定がなければ変更されない）
・ｃｈｒｏｏｔ：プロセスをｃｈｒｏｏｔする先のディレクトリ（指定がなければｃｈｒｏｏｔはない）

上記のプロセスでは、ｅｘｅｃルールは、それが適用されるプロセスを、コンパートメントｉｄを与えることによって指定する。
ルールは、そのコンパートメントｉｄを有するプロセスのみに適用される。
本発明のこの例示的実施形態では、ｅｘｅｃルールはファイルパスも含む。
このファイルパスは、ディレクトリまたは個別のファイルの名前であってもよい。
ファイルパスがディレクトリである場合、それは、別のｅｘｅｃルールのほうが「より特定的」でない限り、当該ディレクトリおよびそのサブディレクトリ内の全ファイルに適用される。
ルール衝突がある場合に「より特定的」なルールを選択するという考え方は当業者に既知であろう。
さらに、このようなルール衝突が解決され得る方法は本発明とは直接の関連性がほとんどないので、本明細書ではこれ以上説明しない。

また、本発明のこの例示的実施形態では、ルールのパス自体がシンボリックリンクを表すのでない限り、ルールが適用されるファイルのセットを決定する場合に、シンボリックリンクはたどられないことになる。

適用可能なｅｘｅｃルールを有するファイルは、呼出し側がａｄｍｉｎ権限を持っていない限り、全コンパートメントからリードオンリにするのが好ましい。
その理由は、ｅｘｅｃルールを有するファイルは実質上、それに付与される特権を有し、変更されるファイルにこの特権が付与されるのは望ましくないからである。
場合によっては、無権限エンティティが、ファイルへのハードリンクを作成することによって、そのファイルに適用されるルールを変更することが可能であるかもしれない。
しかし、本発明のこの例示的実施形態では、不正なリンクは削除され、エラーが返される。

ｅｘｅｃルールがどのファイルに適用されるかの正しい認識を維持するため、ファイル名前空間を変更するオペレーション、すなわち、ファイル作成、ファイル名変更、リンク作成、リンク削除、マウント、アンマウントを監視するのが好ましい。

要約すれば、ｅｘｅｃルールは、別のプログラムを呼び出した後にプロセスのセキュリティ属性を直接に指定することによって、既存のプログラムを変更することや、高信頼性ゲートウェイを使用することを不要にする。
図３のプロセスを実行するのに適した例示的装置は、論理的被保護コンピューティング環境の権限のセットをフィルタリングするフィルタリング手段を備えてもよい。
フィルタリング手段は、それらの権限のうち、フィルタリング手段によって選択される１つまたは複数の権限のみを変更する。
実行制御ルールが適用されるサービスまたはプログラムを構成するファイルの名前を変更する（システムによって実行される）オペレーションを監視する監視手段が提供されてもよい。

実行制御ルールは、関連する論理的被保護コンピューティング環境を識別することによって、その実行制御ルールが適用されるサービスまたはプロセスを指定してもよい。
その結果、ルールは、論理的被保護コンピューティング環境を指定するサービスまたはプロセスのみに適用される。

以上、本発明の一実施形態を単なる例として説明したが、当業者には明らかなように、添付の請求項によって規定される本発明の範囲から逸脱することなく、記載した実施形態に対して変更および変形を行うことが可能である。

本発明の実施形態を実施することが可能なシステムを示す図である。 スマートカードリーダおよびモジュール群と通信するように構成された高信頼性デバイスを含むマザーボードである。 本発明の例示的な一実施形態による（簡略化された）方法を示す流れ図である。

符号の説明

１０・・・高信頼性コンピューティングプラットフォーム、
１２・・・スマートカードリーダ、
１４・・・キーボード、
１６・・・マウス、
１８・・・視覚表示装置（ＶＤＵ）、
２０・・・マザーボード、
２１・・・メインプロセッサ、
２２・・・メインメモリ、
２３・・・Ｉ／Ｏデバイス、
２４・・・高信頼性デバイス、
２６・・・データバス、
２７・・・制御ライン、
２８・・・アドレスライン、
２９・・・ＢＩＯＳメモリ、

Claims (17)

1. 高信頼性コンピューティングプラットフォームおよび１つまたは複数の論理的被保護コンピューティング環境を備えるシステムであって、
   それぞれの論理的被保護コンピューティング環境は、該システムによってサポートされる少なくとも１つのサービスまたはプロセスに関連し、
   該サービスまたはプロセスが開始される時に、該少なくとも１つのサービスまたはプロセスのうちの１つまたは複数に適用されるべきセキュリティ属性を規定する所定のセキュリティポリシを規定するデータを、該高信頼性コンピューティングプラットフォーム上にロードするように構成される
   システム。
2. 前記ポリシは、
   論理的被保護コンピューティング環境のオペレーションを制御する１つまたは複数のセキュリティルール
   を含む
   請求項１に記載のシステム。
3. 前記論理的被保護コンピューティング環境の少なくとも１つに対する各セキュリティルールは、
   前記セキュリティ属性を規定する実行制御ルール
   を含む
   請求項２に記載のシステム。
4. 前記セキュリティ属性は、
   前記サービスまたはプロセスが開始される時にそれぞれの論理的被保護コンピューティング環境に提供されるべき１つまたは複数の権限
   を含む
   請求項３に記載のシステム。
5. 前記セキュリティ属性は、
   前記サービスまたはプロセスが開始される時にそれぞれの論理的被保護コンピューティング環境の権限を変更する１つまたは複数のファンクション
   を含む
   請求項３に記載のシステム。
6. サービスまたはプロセスが開始される時に、前記セキュリティ属性は、指定された論理的被保護コンピューティング環境内に該サービスまたはプロセスが配置されて実行されるように作用する
   請求項３に記載のシステム。
7. 前記セキュリティ属性は、サービスまたはプロセスが実行されるべきユーザｉｄ、グループｉｄまたは論理的被保護コンピューティング環境を変更するように作用する
   請求項３に記載のシステム。
8. 前記セキュリティ属性は、前記サービスまたはプロセスがｃｈｒｏｏｔされる先のディレクトリを規定するように作用する
   請求項３に記載のシステム。
9. 前記実行制御ルールは、指定された権限を引き上げるか、または引き下げることができる
   請求項５に記載のシステム。
10. 前記セキュリティ属性は、論理的被保護コンピューティング環境の権限のセットをフィルタリングし、該権限のうち該フィルタリング手段によって選択される１つまたは複数の権限のみを変更するように作用する
    請求項５または９に記載のシステム。
11. 前記実行制御ルールは、関連する論理的被保護コンピューティング環境を識別することによって、該実行制御ルールが適用されるサービスまたはプロセスを指定し、それによって該ルールは、該論理的被保護コンピューティング環境を指定するサービスまたはプロセスのみに適用される
    請求項のいずれか請求項１〜１０のいずれかに記載のシステム。
12. 前記実行制御ルールが適用されるサービスまたはプロセスを構成するファイルは、リードオンリ設定である
    請求項１〜１１のいずれかに記載のシステム。
13. 前記実行制御ルールが適用されるサービスまたはプロセスを構成するファイルの名前を変更する該システムによって実行されるオペレーションを監視する手段
    を含む請求項１〜１２のいずれかに記載のシステム。
14. 添付図面を参照して本明細書に実質的に記載された
    システム。
15. 高信頼性コンピューティングプラットフォーム、および、１つまたは複数の論理的被保護コンピューティング環境を含むシステムにおいてセキュリティポリシを適用する方法であって、それぞれの論理的被保護コンピューティング環境は、該システムによってサポートされる少なくとも１つのサービスまたはプロセスに関連し、該方法は、
    該論理的被保護コンピューティング環境の少なくとも１つに関連するサービスまたはプロセスを開始するステップと、
    該サービスまたはプロセスの開始後に、該サービスまたはプロセスにセキュリティ属性を適用することにより該少なくとも１つの論理的被保護コンピューティング環境のオペレーションを制御するステップと
    を含むセキュリティポリシを適用する方法。
16. 前記属性は、実行制御ルールによって規定され、
    該実行制御ルールは、前記ポリシの少なくとも一部を実施するセキュリティルールに含まれる
    請求項１５に記載のセキュリティポリシを適用する方法。
17. 高信頼性コンピューティングプラットフォームを含むシステムにおいてセキュリティポリシを適用する方法であって、
    添付図面を参照して本明細書に実質的に記載された
    セキュリティポリシを適用する方法。

Images