JP2006107505A - アクセス認可のａｐｉ - Google Patents

Abstract

【課題】ポリシーを設定および取り消すためのファシリティを提供すること。
【解決手段】ファシリティは、制御するプロセスから制御されるプロセスへのポリシーの設定要求を受け取り、制御するプロセスが制御されるプロセスにポリシーを適用する特権を有するかどうかを決定する。制御するプロセスが制御されるプロセスにポリシーを適用する特権を有するとファシリティが決定する場合には、ファシリティは、制御されるプロセスに対してポリシーを設定して、これによってポリシーが制御されるプロセスに適用されて、制御されるプロセスが１つまたは複数の資源にアクセスする認可を有するかどうかを決定する。
【選択図】図２

Description

本発明は、一般には、コンピュータセキュリティに関し、より詳細には、コンピュータシステム上の資源（ｒｅｓｏｕｒｃｅ）へのアクセスを制御することに関する。

コンピュータおよびコンピュータネットワークに対する攻撃の高度の複雑化および頻発とともに、コンピュータおよびコンピュータネットワークへの依存が増大するにつれて、コンピュータセキュリティの問題は、産業界において益々顕著になっている。現状のコンピュータセキュリティ技術は、コンピュータシステムに特に損傷を与えまたは中断させるように設計された、悪性ソフトウエア（「マルウエア（ｍａｌｗａｒｅ）」、例えば、ウイルス、ワーム、およびトロイの木馬などから、および他の望ましくない活動から、アプリケーションプログラムおよびオペレーティングシステムを保護するのには不十分である。

既存のアクセス制御のセキュリティモデルは、通常、コンピュータ上の資源へのアクセスを認可するユーザの資格証明（ｃｒｅｄｅｎｔｉａｌｓ）に頼っている。これらのモデルにおいては、ユーザに対して利用可能なすべての資源にプロセスがアクセスする必要があるかどうかにかかわらず、同一の資格証明で遂行または実行されるすべてのプロセスに、同一のアクセス権が与えられる。また、資源へのアクセス、例えば、読取り、書込みなどを必要とするプロセスは、資源にアクセスするときに、必要なアクセスを指定する。

例えば、ユーザは、ユーザアカウントでパーソナルコンピュータにログオンして、結果としてパーソナルコンピュータに記憶され、および特定のワードプロセシングプログラムを使用して作成された、すべてのワードプロセシング文書にアクセスできることを期待する。この期待を満足させるために、従来のアクセス制御セキュリティシステムは、ユーザの文脈で実行されているすべてのプログラムに、ワードプロセシング文書のすべてにアクセスする許可を与える。しかしながら、これは、過剰なレベルの許可であり、なぜならば、ユーザの文脈において実行されているほとんどのプログラムは、実際にはワードプロセシング文書のいずれにもアクセスする必要がないからである。

通常、マルウエアは、コード欠陥を利用することによってプロセスに感染する。危うくされたプロセスの内部でマルウエアが実行されると、プロセスが実行されているユーザのコンテキストのアクセス権を引き継ぎ、ユーザに対して利用可能なすべての資源に対するアクセスを得るが、それは元のプロセスがかつて必要としたものよりはるかに大きくなる可能性がある。

したがって、コンピュータ上の資源のセキュリティを改善しかつ増強するアクセス認可（ａｃｃｅｓｓ ａｕｔｈｏｒｉｚａｔｉｏｎ）に対する統合アプローチは、有用性が高いといえる。

コンピュータシステム上のアプリケーションプログラムおよびオペレーティングシステムの利用から発生する逆効果からコンピュータシステムを保護するソフトウエアファシリティ（「ファシリティ（ｆａｃｉｌｉｔｙ）」）について述べる。いくつかの実施形態において、ファシリティは、オペレーティングシステムに論理駆動のアクセス制御レイヤ（ｌｏｇｉｃ−ｄｒｉｖｅｎ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌａｙｅｒ）を追加する。このファシリティは、様々なセキュリティ敏感資源アクセスに対する認可問い合わせを受け取り、ポリシーに基づいて資源アクセスを許可または拒否する決定を返す、認可モジュールを提供することができる。ポリシーとは、資源―例としては、ネットワーク、ファイルシステム、アプリケーションプログラムなど―を管理かつ保護する方法を決定する１組の規則および慣例（ｐｒａｃｔｉｃｅｓ）である。

認可モジュールは、ユーザモードプログラム、例えばユーザ文脈で実行中のアプリケーションプログラムなど、が発行する資源へのアクセス要求に応ずる、様々なオペレーティングシステム構成要素が直接的に問い合わせをすることができる。代替的には、認可モジュールは、そのようなオペレーティングシステム構成要素の上部に位置する「インターセプションレイヤ（ｉｎｔｅｒｃｅｐｔｉｏｎ ｌａｙｅｒ）」によって問い合わせをすることができる。インターセプションレイヤは、リソースにアクセスするためにユーザモードプログラムが使用するシステムコールファンクションを中断し、中断されたシステムコールファンクションに「ラッパー（ｗｒａｐｐｅｒ）」を適用するコードである。認可モジュールは、そのアクセス制御決定（すなわち、許可または拒否）を、その資源アクセスを試みているアプリケーションプログラム、例えばアプリケーションプロセスの識別（ｉｄｅｎｔｉｔｙ）、ユーザの識別、またはアプリケーションプログラムの識別とそのためにアプリケーションが実行されているユーザの識別との組合せのいずれかである、プリンシパルの識別；そのプリンシパルに適用されるポリシー；ならびに資源およびそのプリンシパルが実行しようとする動作の識別に基づいて行う。

いくつかの実施形態においては、ファシリティは、アプリケーションプログラムプロセスなどのプロセスが、それによってポリシー（例えば、アクセス制限）の設定または取消しを行うアプリケーションプログラムインターフェイス（ＡＰＩ）を提供する。本明細書において使用する場合には、ＡＰＩには１つまたは複数の関係するファンクションが含まれる。ポリシーは、プロセスレベル、またはスレッドレベルで設定することができる。ＡＰＩを使用してアクセス制限が設定されると、そのアクセス制限はファシリティによって執行される。ＡＰＩのタイプとしては、行動制御（ｂｅｈａｖｉｏｒ−ｃｏｎｔｒｏｌｌｅｒ）ＡＰＩ、自主規制（ｓｅｌｆ−ｉｍｐｏｓｅｄ）ＡＰＩ、およびクライアント・サーバＡＰＩが挙げられる。

行動制御ＡＰＩは、プロセスが、対象プロセスに対してアクセス制限を設定して、すべてのプロセスのスレッド、またはある指定されたプロセスのスレッドだけに影響を与えることを可能にする。アクセス制限は、取消し可能であっても、取消し不能であってもよい。アクセス制限が取消し可能である場合には、ファシリティが提供するリフト制限ＡＰＩをコールすることによるなど、その後にファシリティに要求することによって、アクセス制限を解除または取り消すことができる。アクセス制限の取消し要求は、制御するプロセス、すなわちアクセス制限を設定するプロセスによって行うことができる。いくつかの実施形態においては、アクセス制限の取消し要求は、要求を行うプロセスがそれを行うことを認可されている限り、制御されるプロセス、制御するプロセスまたは制御されるプロセス以外のプロセスなどの、制御するプロセス以外のプロセスによって行うことができる。例えば、取消し要求と一緒に識別子を使用して、認可を指示するか、またはその他の方法で取消し要求の要求者を認証してもよい。アクセス制限が取消し不能の場合には、アクセス制限は解除または取り消すことができない。さらに、アクセス制限は、対象プロセスに対する任意の既存ポリシーと累積的であってもよく、または対象プロセスに対する現行ポリシーを代替してもよい。例えば、行動制御ＡＰＩを使用して、親プロセスまたは制御するプロセスは、子プロセスまたは制御されるプロセスに対してポリシーを設定することができる。それに続いて、子プロセスまたは制御されるプロセスが、資源へのアクセス要求を行うと、認可モジュールがそのポリシーをチェックして、その要求を許可するか、または拒否するかを決定する。

自主規制ＡＰＩは、プロセスがそれ自体にアクセス制限を設定して、すべてのプロセスのスレッドに影響を与えるか、または行動制御ＡＰＩで設定されるアクセス制限のような、特定の指定されたプロセスのスレッドだけに影響を与えることができるようにしてもよく、自主規制ＡＰＩで設定されるアクセス制限は、取消し可能または取消し不能とすることができる。アクセス制限が取消し可能である場合には、アクセス制御は、その後にファシリティに対する要求を行うことによって解除または取消しをすることが可能である。アクセス制御が取消し不能である場合には、アクセス制限は解除または取り消すことができない。さらに、アクセス制御は、対象プロセスに対する任意の既存ポリシーと累積的であってもよく、または対象プロセスに対する現行ポリシーを代替してもよい。例えば、プロセスはポリシーなし、または実質的に制限の少ないポリシーで始動してもよく、それによってプロセスはより攻撃的な資源アクセスを実行することが可能となる。それに続いて、始動後において、よりリスクの多い活動、例えばネットワーク上でリッスンすること、およびネットワークトラフィックを受信することを開始する前に、プロセスは、自主規制ＡＰＩ、取消し不能ＡＰＩを使用してそれ自体により制限的なポリシーを設定することができる。別の事例においては、プロセスは自主規制ＡＰＩ、取消し可能ＡＰＩを使用して、マクロを開始する前に、それ自体にポリシーを設定して、マクロが実行されている間、ポリシーが適用されるようにすることができる。マクロの実行が終了すると、プロセスは、マクロの実行に先立って設定したポリシーを取り消すことができる。

クライアント・サーバＡＰＩは、プロセスが、非オペレーティングシステム動作に対する、臨時の（ａｄ ｈｏｃ）資源アクセスのチェックを要求することを可能にする。例えば、クライアントプロセスは、サーバプロセスをコールして、サーバプロセスにある動作を実行すること、例えばある方法を実行することまたはある特定のデータにアクセスすることを要求することができる。クライアント要求の受取りに続いて、サーバプロセスはクライアントプロセス、例えばプリンシパルを偽装して（ｉｍｐｅｒｓｏｎａｔｅ）、クライアント・サーバＡＰＩを使用してクライアントプロセスが要求動作を実行するのに十分な特権を有するかどうかをチェックする。次いで、サーバプロセスは、アクセス制御のチェックの結果に基づいて、要求動作に進むかどうかを決定する。

ファシリティの様々な実施形態およびその利点は、図面の図１〜１７を参照することによって最もよく理解できる。図面の要素は、必ずしも比例して拡大縮小せず、代わりに本発明の原理を明確に説明することに重点をおいている。図面全体を通して、様々な図面の同一部品および対応部品には、同一番号を使用している。

図１は、ファシリティが実行される、少なくとも一部のコンピュータシステムに通常、組み込まれている、選択された構成要素を例示するブロック図である。これらのコンピュータシステム１００には、コンピュータプログラムを実行するための１つまたは複数の中央処理ユニット（ＣＰＵ）１０２；プログラムおよびデータ―データ構造を含む―をそれらが使用されている間に記憶するためのコンピュータメモリ１０４；プログラムおよびデータを永続的に記憶するハードドライブなどの永続的な記憶装置１０６；コンピュータ読取可能な媒体に記憶されたプログラムおよびデータを読み取るためのＣＤ−ＲＯＭドライブなどのコンピュータ読取可能な媒体の駆動装置１０８；およびプログラムおよび／またはデータ―データ構造を含む―を交換するために、インターネットを介するなどして、コンピュータシステムを他のコンピュータシステムに接続する、ネットワーク接続１１０を含めることができる。

ファシリティは、コンピュータシステム１００またはその他のデバイスによって実行されるプログラムモジュールのような、コンピュータ読取可能な命令の一般的文脈において説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか、または特定の抽象データタイプを実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造、その他が含まれる。メモリ１０４および永続的な記憶装置１０６は、ファシリティを実現する命令を収容することができるコンピュータ読取可能な媒体である。ここで、メモリ１０４および永続的な記憶装置１０６は、ファシリティを実現する命令に加えて、様々なその他の内容を含むことがあることが認識されるであろう。

ここで、コンピュータシステム１００には、ビデオモニタまたはＬＣＤパネルなどの、プログラム出力を指示する１つまたは複数の表示デバイス、およびキーボード、マイクロフォン、またはマウスなどのポインティングデバイスなどの、ユーザ入力を受信する１つまたは複数の入力デバイスを含めることができることが認識されるであろう。通常、上述のように構成されたコンピュータシステム１００がファシリティの動作をサポートするのに使用されるが、ファシリティは、様々なタイプおよび構成にするとともに、様々な構成要素を有するデバイスを使用して実現することができることが認識されるであろう。

図２は、いくつかの実施形態による、ファシリティの選ばれた構成要素を示すブロック図である。図２に示すように、ファシリティは認可モジュール２０２を含み、このモジュールは、コンピュータシステム１００上で実行するのに適したオペレーティングシステム２０４の一体化構成要素として実現される。認可モジュール２０２は、一般に、ネットワークフェーシングアプリケーション、ネットワークフェーシングサービスおよびオペレーティングシステム構成要素などの高リスクプロセス、信用できない内容を取り扱うアプリケーション、ならびに信用できないコード、例えば、通常、インターネットによって配信されるコードなどに対する、追加の保護レイヤ（ｐｒｏｔｅｃｔｉｏｎ ｌａｙｅｒ）として機能する。認可モジュール２０２は、コンピュータシステム１００上で利用可能な資源のポリシー駆動アクセス制御を実行するための論理を提供する。

ファシリティは、また、認可モジュール２０２がそのアクセス制御決定をそれから行うポリシー２０６を含む。ポリシー２０６は、資源へのアクセスの認可要求を許可するか、または拒否するかを決定する規則である。いくつかの実施形態においては、ポリシー２０６は、オペレーティングシステム２０４および、特に、認可モジュール２０２によって施行される実行時規則、例えばバイナリ規則にコンパイルされる。いくつかの実施形態においては、ポリシー２０６は、集中ポリシー記憶装置（ｃｅｎｔｒａｌｉｚｅｄ ｐｏｌｉｃｙ ｓｔｏｒｅ）の一部として実現されて、この集中ポリシー記憶装置は、例えばユーザおよび／または管理者が、ポリシー２０６内の規則を含みポリシー２０６を、中央から取り消したり、中央から設定したりすることを可能にする。

認可モジュール２０２は、様々なオペレーティングシステムカーネル構成要素２０８が問い合わせをすることが可能であり、これらのカーネル構成要素は、プリンシパル、例えばプリンシパル２１２ａが出す資源へのアクセス要求に答える。また、認可モジュール２０２の問い合わせは、資源にアクセスするためにプリンシパル、例えばプリンシパル２１２ｂが出すシステムコールファンクションを中断する、インターセプションレイヤ２１０が行うこともできる。インターセプションレイヤ２１０は、中断されたシステムコールファンクションにラッパー（ｗｒａｐｐｅｒ）を適用して、認可モジュール２０２が適用可能なポリシー２０６に対するアクセス制御のチェックを実行することを可能にする。例えば、ラッパーを適用することには、プリンシパルおよび／または計算機システム１００に関連する様々な環境要因の識別を決定すること、およびこの情報を認可要求の一部として供給して、認可モジュール２０２へのシステムコールを実行してそれがアクセス制御のチェックを実行することを可能にすることが含まれる。さらに、認可モジュール２０２は、プリンシパル、例えばプリンシパル２１２ｃが直接的に問い合わせをすることもできる。

実施形態によっては、認可モジュール２０２が実行するアクセス制御のチェックは、資源へのアクセス要求を行っているプリンシパルおよびそのプリンシパルに適用するポリシーの関数である。すなわち、認可モジュール２０２は、そのアクセス制御決定（すなわち、許可または拒否）を、プリンシパルの識別―コールしているアプリケーションプログラムの識別、またはコールしているアプリケーションプログラムの識別とそのためにそのアプリケーションプログラムが実行されているユーザの識別との組合せ―およびプリンシパルに適用可能なポリシーにおける規則に基づいて行う。実施形態によっては、認可モジュール２０２は、プリンシパルの識別および、そのアクセス制御決定を行う際のプリンシパルに適用可能なポリシーにおける規則の識別に加えて、一例として、要求アクセスのタイプ、環境因子―例えば、アプリケーションプログラムが実行されている、企業ネットワーク内部または公共ネットワークに接続されたコンピュータ、コンピュータのパッチレベル、その他―などのパラメータをさらに考慮することができる。

実施形態によっては、ファシリティには、図２に破線または「断続線」によって示されている、任意選択の異常検出（ａｎｏｍａｌｙ ｄｅｔｅｃｔｉｏｎ）モジュール２１４を含めることができる。異常検出モジュール２１４は、異常状態を検出するために、全体的には、コンピュータシステム１００の挙動およびコンピュータシステム１００で実行されているプログラムを監視する機能を果たす。実施形態によっては、異常検出モジュール２１４は、異常の検出時に第１の通知を、先に検出された異常の停止検出時に、後続の第２の通知を、ファシリティに提供する。これによって、ファシリティは、異常検出時に、異常が終了するまでポリシー２０６の施行を起動することが可能となり、それ以後は、ポリシー２０６はもう施行されない。代替的に、ファシリティは、異常が検出されるまでより制限の少ないポリシーの組を最初に課してもよく、この場合には、異常が終了して再び制限の少ないポリシーの組が再び施行されるまで、より制限的なポリシーの組が施行される。異常検出モジュール２１４は、コンピュータシステム１００上で実行される単一プロセス、コンピュータシステム１００上で実行されるプロセス群、またはコンピュータシステム１００全体のいずれかにおいて異常を検出することができる。

上述のファシリティの態様は、説明のためだけのものであり、図示した構成要素の実現および／またはファシリティの使用もしくは機能性の範囲に関する限定を意味するものではない。例えば、いくつかの実施形態によっては、認可モジュール２０２は、オペレーティングシステム２０４の一部として、またはそれに一体化して実現する必要はなく、オペレーティングシステム２０４と分離して、またはその外部に、例えば非オペレーティングシステムプログラムとして実現することができる。さらに、いくつかの実施形態においては、ポリシー２０６は集中ポリシー記憶装置として、またはその一部として実現する必要はない。したがって、ポリシー２０６は、１つの場所にある必要はなく、例えば、分散モデルを使用して実現することができる。さらに、ポリシー２０６は、認可モジュール２０２の一部として、またはそれに収容されるものとして記述してあるが、ポリシー２０６は、認可モジュール２０２によってアクセス可能ありさえすれば十分である。

以下の考察においては、ファシリティの実施形態は、様々な実証例と一緒に記述する。ここで、ファシリティの実施形態は、様々な観点でこれらの例から大きく外れる環境において使用できることが認識されるであろう。

図３は、いくつかの実施形態による、ファシリティによる使用に適当な例示ポリシーを示す。例示ポリシーには、ウエブサーバアプリケーションを保護する規則が含まれる。一例として、アイテム３０２と表示されている、資源を要求するアプリケーションプロセスがチェックされて、それがアイテム３０４と表示されている、ＷｅｂＳｅｒｖｅｒＸウエブサーバプロセスであるかどうかが決定される。認可モジュール２０２が、要求元アプリケーションプロセスはＷｅｂＳｅｒｖｅｒＸウエブサーバプロセスであると決定する場合には、認可モジュール２０２は、ポリシー内に含まれる規則に基づいて、要求資源に対する認可を許可または拒否する。

図示するように、例示ポリシーはＷｅｂＳｅｒｖｅｒＸプロセスに与えられる特権またはアクセス権限を包含しており、そのデフォルトは、規則３０６に示すように、その特権またはアクセス権限が指定されない限り、要求資源に対する認可を拒否することである。言い換えると、要求資源がポリシーにおいて明示的に与えられていない限り、要求資源に対する認可は拒否される。実施形態によっては、ポリシーは、アクセス制限を指定する規則、例えば特定の動作を実行することの認可を拒否すべきことを指定する規則、または資源へのアクセスの認可を拒否する規則、あるいは監査を行わせる、例えばイベントをログ記録させる規則を包含することができる。

例示ポリシーにおける第１の規則は、ＷｅｂＳｅｒｖｅｒＸプロセスが、アイテム３０８で示す、「＄ｈｔｍｌ」ファイルを、アイテム３１０で示す、「＄Ｗｅｂディレクトリ」に書き込むことを許可する命令である。「＄ｈｔｍｌ」は、例えば^*．ｈｔｍｌ、^*．ｇｉｆ、その他のファイル種類の集合の表現である。「＄Ｗｅｂディレクトリ」は、ウエブディレクトリとして構成されたディレクトリの集合の表現であり、セキュリティ管理者などのポリシーの製作者とは異なる、ウエブ管理者などの管理者による定義が可能である。例えば、認可モジュール２０２は、この規則に基づいて、パラメータ「＄ｈｔｍｌ」で定義される種類のファイルを、パラメータ「＄Ｗｅｂディレクトリ」で定義される種類のディレクトリの１つに書き込む要求をしているＷｅｂＳｅｒｖｅｒＸプロセスに応答して、許可決定（すなわち、認可の授与）を返す。したがって、ポリシー内の規則を、「＄Ｗｅｂディレクトリ」のような動的かつ独立に定義されたオブジェクト群、および「＄ｈｔｍｌ」のような動的で構成可能な環境パラメータに適用することができる。

例示ポリシーにおける第２の規則は、それがアイテム３１４で示す「ユーザＡ」のために実行されている場合には、ＷｅｂＳｅｒｖｅｒＸプロセスが、アイテム３１２で示す、「＄ＦＴＰアップロードディレクトリ」に書込みをすることを許可する命令である。例えば、認可モジュール２０２は、この規則に基づいて、「＄ＦＴＰアップロードディレクトリ」への書込み要求をしているユーザＡのために実行されているＷｅｂＳｅｒｖｅｒＸプロセスに応答して、許可決定（すなわち、認可の授与）を返す。

例示ポリシーにおける第３の規則は、アイテム３１６で示す、内向きｈｔｔｐトラフィックを許可する命令である。例えば、認可モジュール２０２は、この規則に基づいて、内向きｈｔｔｐデータを受信すること、例えばネットワーク接続上を伝送される、ｈｔｔｐデータパケットを受信することを要求しているＷｅｂＳｅｒｖｅｒＸプロセスに応答して、許可決定（すなわち、認可の授与）を返す。

例示ポリシーにおける第４の規則は、アイテム３２０で示す、可変「＄ＦＴＰ」が使用可能である場合に、アイテム３１８で示す「ＦＴＰトラフィック」を許可する命令である。ここで、「＄ＦＴＰ」は変数であり、ポリシーを作成したセキュリティ管理者とは異なる管理者が設定することができる。例えば、認可モジュール２０２は、実行時のチェックを実行して、変数「＄ＦＴＰ」が使用可能であるかどうかを決定し、そうであれば、この規則に基づいて、パラメータ「ＦＴＰトラフィック」によって定義されるデータを送信または受信することを要求するＷｅｂＳｅｒｖｅｒＸプロセスに応答して、許可決定（すなわち、認可の授与）を返す。一方、「＄ＦＴＰ」が使用可能でない場合には、前述のアクセス要求に応答して、認可モジュール２０２はアイテム３０６で示す拒否決定（すなわち、認可の拒否）を返す。

ポリシーには、上記の例示特権で示したアプリケーションプロセスなどの、オペレーティングシステム内部および外部のオブジェクトに対する特権を定義する、規則を含めることができるが認識されるであろう。ポリシー内の規則は、コンパイル式またはインタープリタ式コンピュータ言語を使用する書込みコードと同様の、リッチスキーマ（ｒｉｃｈ ｓｃｈｅｍａ）を使用して指定することができる。例えば、このスキーマは、条件および一時的条件、例えば「Ｙであるときだけ、Ｘを許可する」など、動的に構成可能な環境パラメータおよび変数への依存性、環境因子への依存性、その他を規則に含めることをサポートすることができる。さらに、パラメータの使用によって、現在および将来のオブジェクトに適用する規則の作成が容易になる。例えば、特定の種類の文書を、パラメータで表現することが可能であり、そのパラメータを使用して、現在存在するものであれ、将来作成されるものであれ、その特定の種類のすべての文書に適用する制限を指定する規則を作成することができる。実施形態によっては、ポリシーが指定することによって、ある決定は、例えばポップアップダイアログボックスによって、エンドユーザに決定を委ねられるようにすることができる。

図４は、いくつかの実施形態による、拒否されたアクセス要求の監査をファシリティが実施する方法４００のフローチャートを示している。一例として、あるユーザ（例えば、ユーザＡＢＣ）が、コンピュータにログオンして、ワードプロセシングアプリケーション（例えば、ＷＰＡｐｐ）を開始しており、コンピュータ上のディレクトリ（例えば、ＹＺＤｉｒ）に記憶されているファイル（例えば、ＦｉｌｅＸ）を開くことを要求している。その結果として、ＷＰＡｐｐは、ディレクトリＹＺＤｉｒに記憶された資源ＦｉｌｅＸへのアクセス要求を出す。開始ステップから始まり、認可モジュール２０２は、ステップ４０２において、認可問い合わせ、例えばＹＺＤｉｒに記憶されたＦｉｌｅＸへのアクセスの認可要求を受信する。

ステップ４０４において、認可モジュール２０２は、ＹＺＤｉｒに記憶されたＦｉｌｅＸへのアクセスの認可要求しているプリンシパルを識別する。上記の例においては、プリンシパルは、ＷＰＡｐｐであるか、またはＷＰＡｐｐとユーザＡＢＣの組合せのいずれかとすることができる。ステップ４０６において、認可モジュール２０２は、識別されたプリンシパルに適用可能なポリシーを、例えば、ポリシー２０６などの集中ポリシー記憶装置から識別するとともに、プリンシパルの識別と適用可能なポリシーに基づいてアクセス制御のチェックを実施する。ステップ４０８において、認可モジュール２０２は、ステップ４０６において実施されたアクセス制御のチェックの結果が、アクセスを拒否するものであるかどうかを決定する。上記の例に続いて、ステップ４０８において、認可モジュール２０２は、識別された適用可能なポリシーを分析して、ポリシーにおける規則または特権が、そのプリンシパルがＹＺＤｉｒに記憶されたＦｉｌｅＸにアクセスすることを認可するかどうかを決定する。

認可モジュール２０２が、適用可能なポリシーがプリンシパルに要求動作を実行することを認可すると決定する場合には、ステップ４２０において、認可モジュール２０２は、プリンシパルが要求動作を実行することが認可されたことの表示である、許可決定を返して、最終ステップへと進む。一方、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと認可モジュール２０２が決定する場合には、ステップ４１０において、認可モジュール２０２は拒否決定を返し、これはプリンシパルが要求動作を実行することが認可されないことの表示である。ステップ４１２において、認可モジュール２０２は、プリンシパルにエラーストリングを返し、要求動作を実行する認可がないことをプリンシパルに通知することができる。

ステップ４１４において、認可モジュール２０２は、監査が使用可能かどうかを決定するチェックを行う。適用可能なポリシーまたは規則に関連するフラグまたはレコードによって、監査を実施すべきかどうかを指示することができる。監査が使用可能でない場合には、認可モジュール２０２は、最終ステップへと進む。一方、監査が使用可能である場合には、認可モジュール２０２は、ステップ４１６において、監査ログに記入を行う。この記入項目は、拒否された要求、無効な規則、プリンシパル、および／または要求資源を識別することができる。

ステップ４１８において、認可モジュール２０２は、拒否要求の監査に基づいて１つまたは複数のイベントを始動することができる。例えば、認可モジュール２０２は、例えば電子メール、音声メール、テキストメッセージングなどを介して、セキュリティ管理者に、非認可動作を実行すること、プリンシパルによる非認可動作の実行の試みに続いてアプリケーションプロセスを終了すること、プリンシパルによる非認可動作の実行の試みに続いてより厳格なポリシーの組を課すること、その他の、プリンシパルによる試みの表示を提供することができる。それらのイベントを始動することに続いて、認可モジュール２０２は、最終ステップへと進む。

当業者であれば、本明細書において開示した、これらおよびその他のプロセスならびに方法に対して、プロセスおよび方法において実行される機能は、異なる順序で実現できることを認識するであろう。さらに、概説したステップは、例示的なものにすぎず、本発明の本質から外れることなく、いくつかのステップを任意選択とすること、より少ないステップと組み合わせること、または追加のステップに拡張することができる。

図５は、いくつかの実施形態による、本質的に危険な操作の監査をファシリティが実行する方法５００のフロー図を示す。一例として、ユーザ（例えば、ユーザＡＢＣ）はコンピュータにログオンして、ウエブブラウザプログラム（例えば、ＷｅｂＢｒｏｗｓｅｒ）を開始して、信用のできないウエブサイト（例えば、ＷｅｂＳｉｔｅＹ）上のウエブページ（例えば、ＰａｇｅＸ）へのアクセス要求をしている。結果として、ＷｅｂＢｒｏｗｓｅｒは、ＷｅｂＳｉｔｅＹからＰａｇｅＸを検索する要求を出す。ステップ５０２〜５０８は、実質的に方法４００のステップ４０２〜４０８と同様である。

ステップ５０８において、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと決定する場合には、ステップ５１０において、認可モジュール２０２は拒否決定を返し、これはプリンシパルが要求動作の実行を認可されていないことの表示である。上記の例において、ＷｅｂＢｒｏｗｓｅｒは、信用できないサイトＷｅｂＳｉｔｅＹにアクセスする認可を得ることができない。ステップ５１２において、認可モジュール２０２は、エラーストリングをプリンシパルに返し、要求動作を実行する認可がないことをプリンシパルに通知することができる。エラーストリングを返した後に、認可モジュールは最終ステップへと進む。

一方、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可すると決定する場合には、ステップ５１４において、認可モジュール２０２は許可決定を返し、これは、プリンシパルが要求動作の実行を認可されていることの表示である。ステップ５１６において、認可モジュール２０２は、認可された動作が本質的に危険な操作であるかどうかを決定するためのチェックを行う。例えば、ファシリティは本質的に危険な操作のリストを維持することができるとともに、認可モジュール２０２は、このリストをチェックして、認可された動作が本質的に危険な操作としてリストされているかどうかを決定することができる。

認可された動作が、本質的に危険な操作であることがわかった場合には、ステップ５１８において、認証モジュール２０２が監査操作を実行する。例えば、認可モジュール２０２は、本質的に危険な操作監査ログに、本質的に危険な操作を実行することの要求および認可の表示を記入することができる。この記入項目には、本質的に危険な操作を実行することの認可を要求したプリンシパルの表示を含めてもよい。認可モジュール２０２は、本質的に危険な操作を実行する認可によって始動をかけることができる、さらに他の動作を実行してもよい。ステップ５１８において監査操作を実行するのに続いて、またはステップ５１６において認可された動作が本質的に危険な操作ではないと決定するのに続いて、認可モジュール２０２は最終ステップへと進む。

実施形態によっては、認可モジュール２０２は、本質的に危険な操作監査ログに、本質的に危険な操作を実行する認可要求の表示を書き込んでもよい。上記の例の続きとして、信用のできないサイトＷｅｂＳｉｔｅＹにアクセスすることが本質的に危険な操作であり、さらに適用可能なポリシーはＷｅｂＢｒｏｗｓｅｒにＷｅｂＳｉｔｅＹにアクセスする認可を与えないことを仮定して、認可モジュール２０２は、拒否決定を返し（ステップ５１０）、本質的に危険な操作を実行する認可要求と、その後の認可の拒否を、例えば、本質的に危険な操作監査ログに記録する。認可モジュール２０２は、本質的に危険な活動を実行する認可を要求したプリンシパルの表示も記録することができる。

図６は、いくつかの実施形態による、ポリシーの微調整を容易にする学習をファシリティが実行する方法６００のフロー図である。一例として、ユーザ（例えば、ユーザＡＢＣ）がコンピュータ上にログオンして、ウエブブラウザプログラム（例えば、ＷｅｂＢｒｏｗｓｅｒ）を開始して、ウエブサイト（例えば、ＷｅｂＳｉｔｅＹ）上のウエブページ（例えば、ＰａｇｅＸ）へのアクセス要求をしている。その結果として、ＷｅｂＢｒｏｗｓｅｒは、ＷｅｂＳｉｔｅＹからＰａｇｅＸの検索要求を出す。ステップ６０２〜６０８は、方法４００のステップ４０２〜４０８と実質的に同様である。

ステップ６０８において、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可すると決定する場合には、ステップ６１０において、認可モジュール２０２は、プリンシパルが要求動作を実行することを認可されていることの表示である、許可決定を返して、最終ステップへと進む。一方、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと決定する場合には、ステップ６１２において、認可モジュール２０２は、要求動作の実行の認可を拒否する、ポリシーにおける規則に対する学習が使用可能であるかどうかをチェックして決定する。上記の例に続いて、ＷｅｂＢｒｏｗｓｅｒに適用可能なポリシーに、ＷｅｂＢｒｏｗｓｅｒのインターネットへのアクセス、したがってＷｅｂＳｉｔｅＹへのアクセスを明確に拒否するルールを含めてもよいが、規則を適用する代わりに学習を適用する表示を提供することもできる。

認可モジュール２０２が、要求動作の実行の認可を拒否する規則に対する学習は使用可能ではないと決定する場合には、ステップ６１８において、認可モジュール２０２は、拒否決定を返し、これはプリンシパルが要求動作を実行することが認可されていないことの表示である。上記の例において、ＷｅｂＢｒｏｗｓｅｒのインターネットへの、したがってＷｅｂＳｉｔｅＹへのアクセスを明確に拒否する規則は、学習を適用することの表示を有していないことがある。この場合には、この規則が適用されて、ＷｅｂＢｒｏｗｓｅｒはＷｅｂＳｉｔｅにアクセスすることを拒否される。ステップ６２０において、認可モジュール２０２は、プリンシパルにエラーストリングを返し、要求動作を実行する認可がないことをプリンシパルに通知する。エラーストリングを返すのに続いて、認可モジュールは最終ステップへと進む。

一方、ステップ６１２において、認可モジュール２０２が、要求動作を実行する認可を拒否する規則に対する学習が使用可能であると決定する場合には、ステップ６１４において、認可モジュール２０２は、無効規則の表示を学習報告ログ（ｌｅａｒｎｉｎｇ ｒｅｐｏｒｔ ｌｏｇ）に記入を行う。この記入項目には、無効規則となった動作を実行することの認可を要求した、プリンシパルの表示を含めてもよい。ステップ６１６において、認可モジュール２０２は、プリンシパルが要求動作を実行することを認可されていることの表示である、許可決定を返して、最終ステップへと進む。すなわち、適用可能な規則を適用する代わりに、認可モジュール２０２は、要求動作を実行する認可を与えて、このイベントの表示を記録する。セキュリティ管理者またはその他の関心のあるユーザは、次いで、学習報告ログの内容を分析して、規則またはポリシーが制限的すぎるか、または十分に制限的ではないかを決定して、規則またはポリシーを実際に施行または実現する前に、規則またはポリシーを微調整する。

実施形態によっては、認可モジュール２０２は、要求動作を実行する認可を与えた規則の表示の学習報告ログに記入をすることができる。上記の例に続いて、ルールが、ＷｅｂＢｒｏｗｓｅｒがインターネット、したがってＷｅｂＳｉｔｅＹにアクセスすることを明確に認可するとともに、学習を適用する表示も与えることを仮定して、認可モジュール２０２は許可決定を返す（ステップ６１０）とともに、要求動作を実行することの認可を与えた規則の表示を記録する。この情報は、規則またはポリシーを微調整するのに使用することができる。例えば、報告ログの記入項目から、資源にアクセスする認可が、容易に授与されすぎると決定されると、規則またはポリシーを、調節または変更して、その資源へアクセスする認可が授与される事例を減少させることができる。

図７は、いくつかの実施形態による、段階アクセス（ｔｉｅｒｅｄ ａｃｃｅｓｓ）制御のチェックをファシリティが提供する方法７００のフロー図を示す。先の例の１つを再び参照すると、ユーザ（例えば、ユーザＡＢＣ）はコンピュータにログオンして、ワードプロセシングアプリケーション（例えば、ＷＰＡｐｐ）を開始しており、コンピュータ上のディレクトリ（例えば、ＹＺＤｉｒ）内に記憶されたファイル（例えば、ＦｉｌｅＸ）を開くことを要求している。その結果として、ＷＰＡｐｐは、ディレクトリＹＺＤｉｒに記憶された資源ＦｉｌｅＸへのアクセス要求を出す。開始ステップから始まり、認可モジュール２０２は、ステップ７０２において、認可問い合わせ、例えば、ＹＺＤｉｒに記憶されたＦｉｌｅＸへのアクセスの認可要求を受信する。

ステップ７０４において、ユーザのコンピュータで実行されているオペレーティングシステムは、従来のアクセス制御のチェックを実行する。上記の例に続いて、オペレーティングシステムは、ユーザがＹＺＤｉｒのＦｉｌｅＸを開く（例えば、読取りアクセス）特権を有するかどうかをチェックして決定することができる。ステップ７０６において、オペレーティングシステムは、その従来のアクセス制御のチェック機構を使用して、ＦｉｌｅＸへのユーザアクセスを拒否すべきかどうかを決定する。

オペレーティングシステムの従来のアクセスチェック機構が、そのユーザのＦｉｌｅＸへのアクセスを拒否すべきであると決定すると、ステップ７０８において、オペレーティングシステムは、拒否決定を返して、最終ステップへと進む。この拒否決定は、ユーザが要求動作、例えばＦｉｌｅＸを開くこと、を実行することが認可されていないことの表示である。一方、オペレーティングシステムの従来のアクセスチェック機構が、そのユーザのＦｉｌｅＸへのアクセスを拒否すべきでないと決定する場合には、ステップ７１０において、認可モジュール２０２は、ＹＺＤｉｒに記憶されたＦｉｌｅＸへのアクセスの認可を要求しているプリンシパルを識別する。

ステップ７１２において、認可モジュール２０２は、識別されたプリンシパルに適用可能なポリシーを、例えば、ポリシー２０６などの集中ポリシー記憶装置から識別して、プリンシパルの識別と適用可能なポリシーとに基づいてアクセス制御のチェックを実行する。上記の例に続いて、認可モジュール２０２は、ステップ７１４において識別された適用可能なポリシーを分析して、ポリシーにおける規則または特権はプリンシパルがＹＺＤｉｒに記憶されたＦｉｌｅＸにアクセスすることを認可するかどうかを決定する。

認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可すると決定する場合には、ステップ７２０において、認可モジュール２０２は、プリンシパルが要求動作を実施することを認可されていることの表示である、許可決定を返して、最終ステップへと進む。一方、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと決定する場合には、ステップ７１６において、認可モジュール２０２は、プリンシパルが要求動作を実行することが認可されていないことの表示である拒否決定を返す。ステップ７１８において、認可モジュール２０２は、エラーストリングをプリンシパルに返して、最終ステップに進むことができる。エラーストリングは、要求動作を実行する認可がないことをプリンシパルに通知することができる。

ここで、段階アクセスのチェックを、方法７００によって示す順序と逆の順序で実行できることが認識されるであろう。例えば、認可モジュール２０２は、最初にそのアクセス制御のチェックを実行する。認可モジュール２０２が、特定の資源アクセスに対して認可を与えるべきであると決定すると、オペレーティングシステムが、その従来のアクセス制御機構を使用して、そのセキュリティチェックを実施する。

図８は、いくつかの実施形態による、アプリケーションプログラムのセキュリティリスクのレベルをファシリティが決定する方法８００を示すフロー図である。特に、ファシリティは、セキュリティリスクのレベルおよび／またはアプリケーションプログラムの意図の評価を、そのアプリケーションプログラムに専用のポリシーの分析に基づいて行う。一例として、ユーザはコンピュータにログオンして、アプリケーションをコンピュータ上にロードおよび／または実行することを要求している。

開始ステップから始まり、ステップ８０２において、ユーザのコンピュータ上で実行されているオペレーティングシステムは、アプリケーションプログラムをロード／実行する要求を受信する。ステップ８０４において、オペレーティングシステムは、ファシリティを呼び出して、アプリケーションプログラムが対応するポリシーを有するかどうかを決定する。例えば、そのアプリケーションプログラムに適用可能なポリシーは、ポリシー２０６の一部として維持することができる。ファシリティが、そのアプリケーションプログラムに適用可能なポリシーは存在しないと決定する場合には、ファシリティは、適用可能なポリシーが存在しないことをオペレーティングシステムに通知する。ステップ８０６において、オペレーティングシステムは、アプリケーションプログラムをロード／実行することの要求を拒否し、エラー状態を返す。要求を拒否するのに続いて、オペレーティングシステムは、この要求に対する最終ステップへと進む。

一方、ステップ８０４において、ファシリティが、そのアプリケーションプログラムに適用化なポリシーは存在すると決定する場合には、ステップ８０８において、ファシリティは、その適用可能なポリシーを分析して、そのアプリケーションプログラムをロード／実行することに関連する、またはそれから生ずる潜在的セキュリティリスクのレベルを決定する。ファシリティは、そのポリシーにおける規則によって与えられる認可のレベルまたは範囲に、リスクのレベルを基づかせることができる。例えば、規則がアプリケーションプログラムを多数の資源またはある数の本質的に危険な資源に対して認可する場合には、ファシリティは、規則がアプリケーションプログラムを小数の、比較的安全な資源に対してのみ認可する場合よりも、リスクのレベルを高く設定することができる。ファシリティは、適用可能なポリシーが存在することをオペレーティングシステムに通知して、最終ステップへと進む。

図９は、いくつかの実施形態による、異常の検出時により制限的なポリシーをファシリティが課する方法９００を示すフロー図である。一例として、コンピュータ上で実行中のファシリティは、２つのポリシー、ポリシーＡおよびポリシーＢを有することができ、これらはアプリケーションプログラムに適用可能である。さらに、ポリシーＡは、ポリシーＡがより多数の資源に認可を授与する点において、ポリシーＢよりも制限が少ない。

開始ステップから始まって、ステップ９０２において、ファシリティは制限の少ないポリシーＡを課する。ステップ９０４において、ファシリティは、コンピュータ上で実行中のアプリケーションプログラムのインスタンスにおける異常状態を検出することができる。上記の例に続いて、アプリケーションプログラムのインスタンスがコンピュータ上で実行中であり、ファシリティは、実行中のアプリケーションプログラムプロセスを監視中である。アプリケーションプログラムプロセスの監視中に、ファシリティは、そのプロセスにおける異常条件または状態を検出することができる。例えば、ファシリティは、そのコンピュータ上で実行されたアプリケーションプログラムの先のインスタンスを追跡することによって、アプリケーションプログラムが通常出すシステムコールを表す有向グラフ（ｄｉｒｅｃｔｅｄ ｇｒａｐｈ）を先に生成しておき、現行アプリケーションプログラムプロセスが行うシステムコールと有向グラフとの比較から異常状態の存在を決定することができる。

ステップ９０６において、異常状態の検出に応答して、ファシリティは、より制限的なポリシーＢを課して、最終ステップへと進む。一実施態様においては、ファシリティは、より制限的なポリシーＢを、異常状態が検出されたアプリケーションプログラムプロセスに課する。代替的に、ファシリティは、より制限的なポリシーＢを、アプリケーションプログラム、例えば、アプリケーションプログラムのすべてのインスタンスまたはプロセスに、課することができる。さらに、検出される異常、アプリケーションプログラム、および／または特定のポリシーに応じて、ファシリティは、コンピュータ全体により制限的なポリシーの組を課することが可能であり、例えば、より制限的なポリシーがコンピュータ上で実行中のすべてのプロセスに適用される。

図１０は、いくつかの実施形態による、異常の検出時にファシリティがポリシーを課する方法１０００を示すフロー図である。一例として、コンピュータ上で実行中のファシリティは、ウエブアプリケーションプログラムに適用可能なポリシー、ポリシーＡを有する。開始ステップで始まって、ステップ１００２において、ファシリティは、ウエブアプリケーションプログラムにそのポリシーを課さない。したがって、ポリシーＡは休眠しており、コンピュータ上で実行中のウエブアプリケーションプログラムのインスタンスに適用されない。ステップ１００４において、ファシリティは、コンピュータ上で実行中のウエブアプリケーションプログラムのインスタンスにおける異常状態を検出することがある。

上記の例に続いて、ウエブアプリケーションプログラムのインスタンスがコンピュータ上で実行されており、ファシリティは実行中のウエブアプリケーションプログラムプロセスを監視中である。アプリケーションプログラムプロセスを監視する間に、ファシリティは、プロセス中の異常条件または状態を検出することができる。例えば、ファシリティは、ウエブアプリケーションプロセスによって生成されるかまたはそれによって発生するネットワークトラフィックを監視して、そのネットワークトラフィックから、ウエブアプリケーションプロセス中に異常状態が存在することを決定することができる。ステップ１００６において、ファシリティは、休眠ポリシー、ポリシーＡをウエブアプリケーションプログラム、例えば異常の検出されたウエブアプリケーションプログラムプロセスに課して、最終ステップへと進む。別の選択肢として、ファシリティは、ポリシーＡをウエブアプリケーションプログラムのすべてのインスタンスまたはプロセスに課すことができる。このようにして、休眠ポリシーは活動状態になり、ウエブアプリケーションプログラムに適用される。

図１１は、対象プロセスにポリシーを設定するために、いくつかの実施形態においてファシリティが使用する、通信フローを示すブロック図である。一例として、コンピュータ上で実行中のネットワークサーバプロセスは、サーバプロセスのためにネットワークパケットをリッスンして受信するように構成されているリスナープロセスに対するポリシーを、設定したいと望むことがある。この場合には、サーバプロセスは制御するプロセスであり、リスナープロセスは対象プロセスまたは制御されるプロセスであると考えることができる。

図１１に示すように、制御するプロセス１１０２は、制御されるプロセス１１０８にポリシーを設定することの要求を、コンピュータ上で実行中のオペレーティングシステム１１０４に送ることができる（段階１）。このポリシーは要求とともに送るか、または先に送っておいてもよく、この場合には、要求にはそのポリシーを識別する識別子を含めることができる。要求は、アクセス制御ＡＰＩ １１０６を介して行うことができる。アクセス制御ＡＰＩ １１０６は、概して、アプリケーション開発者がポリシーを設定および取り消すのに使用することのできる、様々なインターフェイスを公開して使用可能にする機能を果たす。一実施形態においては、アクセス制御ＡＰＩ １１０６は呼び出し規則（ｃａｌｌｉｎｇ ｃｏｎｖｅｎｔｉｏｎ）を提供し、それによって、アプリケーションプログラムはオペレーティングシステム１１０４にアクセスしてポリシーを設定したり取り消すことができる。

ポリシーの設定要求の受取りに応答して、オペレーティングシステム１１０４は、制御するプロセス１１０２が、対象プロセスにポリシーを設定するのに適切な特権を有するかどうかをチェックして決定する（段階２）。例えば、オペレーティングシステム１１０４は、制御するプロセス１１０２が、制御されるプロセス１１０８が実行される特権レベルよりも高い特権レベルで実行されることを要求してもよい。代替的に、オペレーティングシステム１１０４は、プロセスが子プロセスにポリシーを設定することだけを許可してもよい。オペレーティングシステム１１０４が、制御するプロセス１１０２が適切な特権を有すると決定する場合には、オペレーティングシステム１１０４は、制御されるプロセス１１０８にポリシーを設定する。要求がそのポリシーを含む場合には、オペレーティングシステム１１０４は、受信されたポリシーを、例えばポリシー２０６に記憶するとともに、そのポリシーを適用することの表示を設定する。要求がそのポリシーを識別する識別子を含む場合には、オペレーティングシステム１１０４はその識別子を使用して、例えばポリシー２０６内のポリシーを識別、例えば捜し出すとともに、ポリシーを適用することの表示を設定する。そうではなく、オペレーティングシステム１１０４が、制御するプロセス１１０２は適切な特権を有さないと決定する場合には、オペレーティングシステム１１０４は、制御されるプロセス１１０８にポリシーを設定しない。オペレーティングシステム１１０４は、制御されるプロセス１１０８にポリシーを設定することの要求の結果を、制御するプロセス１１０２に返す（段階３）。

続いて、制御されるプロセス１１０８が、資源へのアクセス要求をオペレーティングシステム１１０４に対して行うと（段階４）、オペレーティングシステム１１０４は、アクセス制御のチェックを行い、制御されるプロセス１１０８がその資源にアクセスする認可を有するかどうかを決定する（段階５）。例えば、オペレーティングシステム１１０４は、認可モジュール２０２を使用して、適用可能なポリシーがあるかどうかを決定して、利用可能なポリシーにおける規則を適用して、制御されるプロセス１１０８がその資源にアクセスする認可を有するかどうかを決定することができる。

アクセス制御のチェックの結果に応じて、オペレーティングシステム１１０４は、資源へのアクセス要求に答える。例えば、オペレーティングシステム１１０４が、適用可能なポリシーを適用することによって、制御されるプロセス１１０８は資源へのアクセスの認可を有すると決定する場合、オペレーティングシステム１１０４は、前進して資源へのアクセス要求をさらに処理する。そうでない場合には、オペレーティングシステム１１０４は、資源へのアクセス要求をさらには処理しない。オペレーティングシステム１１０４は、その資源へのアクセス要求の結果を制御されるプロセス１１０８に返す（段階６）。

上記および後続の例において、制御するプロセス１１０２とオペレーティングシステム１１０４とは、同一のコンピュータ上で実行されるように記述してあるが、それは、当業者あれば、制御するプロセス１１０２はオペレーティングシステム１１０４と同一のコンピュータ上で実行する必要はないことを認識するように、限定を意味するものではない。例えば、ポリシーの設定要求は、通信ネットワーク上で送ることができる。さらに、ここで認識されるのは、制御されるプロセス１１０８は、制御されるプロセス１１０８にポリシーの設定要求をする時間に、存在しても、しなくてもよいことである。

図１２は、対象プロセスに取消し可能ポリシーを設定するために、いくつかの実施形態においてファシリティが使用する通信フローを示すブロック図である。制御するプロセス１２０２は、アクセス制御ＡＰＩ １１０６を介して、制御されるプロセス１２０４に取消し可能ポリシーを設定することの要求を、コンピュータ上で実行中のオペレーティングシステム１１０４に送る（段階１）。取消し可能なポリシーの設定要求の受取りに応答して、オペレーティングシステム１１０４は、制御するプロセス１２０２が対象プロセスに取消し可能ポリシーを設定する適切な特権を有するかどうかをチェックして決定する（段階２）。オペレーティングシステム１１０４が、制御するプロセス１２０２は適切な特権を有すると決定すると、オペレーティングシステム１１０４は、制御されるプロセス１２０４にポリシーを適用することの表示を設定する。そうでなく、オペレーティングシステム１１０４が、制御するプロセス１２０２は適切な特権を有さないと決定する場合には、オペレーティングシステム１１０４は、制御されるプロセス１２０４にポリシーを設定しない。

オペレーティングシステム１１０４は、制御するプロセス１２０２に、制御されるプロセス１２０４に取消し可能ポリシーを設定する要求の結果を返す（段階３）。取消し可能ポリシーが有効に設定される場合には、オペレーティングシステム１１０４は、制御するプロセス１２０２に、例えば「クッキー」内の識別子を返す。一実施形態においては、この識別子は、取消し可能ポリシーを設定するプロセスを認証するとともに、取消し可能ポリシーを識別して取り消すのに使用される。言い換えると、識別子は、取消し可能なポリシーを取り消す特権または認可と類似しており、その後に、ポリシーの取消し要求とともに、オペレーティングシステム１１０４に提出される。その他の実施形態においては、クッキーには、先に実施されたポリシーを識別する識別子などの、状態情報も含めることができる。

続いて、制御されるプロセス１２０４がオペレーティングシステム１１０４に資源へのアクセスの要求を行うとき（段階４）、オペレーティングシステム１１０４は、アクセス制御のチェックを実行して、制御されるプロセス１２０４がその資源にアクセスする認可を有するかどうかを決定する（段階５）。アクセス制御のチェックの結果に応じて、オペレーティングシステム１１０４は、資源へのアクセス要求に答える。例えば、オペレーティングシステム１１０４が、適用可能なポリシーを適用することによって、制御されるプロセス１２０４が資源にアクセスする認可を有すると決定すると、オペレーティングシステム１１０４は、さらに続けて資源へのアクセス要求を処理する。そうでない場合には、オペレーティングシステム１１０４は、資源へのアクセス要求をさらに処理することはない。オペレーティングシステム１１０４は、資源へのアクセス要求の結果を、制御されるプロセス１２０４に返す（段階６）。

次いで、制御するプロセス１２０２は、アクセス制御ＡＰＩ １１０６を介して、制御されるプロセス１２０４に先に設定された、取消し可能なポリシーの取消し要求を、オペレーティングシステム１１０４に送ることができる（段階７）。代替的に、制御するプロセス１２０２は、識別子を含むクッキーを制御されるプロセス１２０４に送ってもよく（段階８）、その後に制御されるプロセス１２０４が、アクセス制御ＡＰＩ １１０６を介して、制御されるプロセス１２０４に先に設定された取消し可能なポリシーを取り消す要求を、オペレーティングシステム１１０４に送ることができる（段階９）。両方の場合において、クッキーは、取消し可能なポリシーを取り消す要求とともに送られる。

取消し可能ポリシーを取り消す要求の受け取りに応答して、オペレーティングシステム１１０４は、クッキーに含まれる識別子を使用して、指示された取消し可能ポリシーを取り消す認可を有するプロセスとして、要求者を認証する。また、オペレーティングシステム１１０４は、識別子を使用して、取り消すべきポリシーを識別する。要求者―制御するプロセス１２０２（段階７）または制御されるプロセス１２０４（段階９）のいずれか―を認証した後に、オペレーティングシステム１１０４は、制御されるプロセス１２０２に現在、適用されている取消しポリシーを取り消す。別の実施形態においては、オペレーティングシステム１１０４は、取り消されたばかりの取消し可能ポリシーの適用に先立って、制御されるプロセス１２０４に適用されていたポリシーを適用することができる。例えば、先に実施されたポリシーを識別する識別子を、取消し可能ポリシーを取り消す要求とともに送られた「クッキー」に入れて、オペレーティングシステム１１０４に送ることができる。代替的に、オペレーティングシステム１１０４は、取消し可能ポリシーを適用する以前の状態情報を、例えばコンピュータ上の永続的な記憶装置に保存しておいてもよい。

図１３は、プロセスに自主規制ポリシー（ｓｅｌｆ−ｉｍｐｏｓｅｄ ｐｏｌｉｃｙ）を設定するために、いくつかの実施形態においてファシリティが使用する通信フローを示すブロック図である。一例として、コンピュータ上のユーザは、ウエブブラウザアプリケーションプログラムを起動したところである。初期化プロセスの一部として、ウエブブラウザアプリケーションプロセス１３０２は、アクセス制御ＡＰＩ １１０６を介して、マイポリシーをポリシーＡに設定する要求を、コンピュータ上で実行中のオペレーティングシステム１１０４に送る（段階１）。それに応答して、オペレーティングシステム１１０４は、プロセス１３０２に対するポリシーをポリシーＡに設定する（段階２）。要求がポリシーＡを含む場合には、オペレーティングシステム１１０４は、例えば、ポリシー２０６にポリシーＡを記憶して、ポリシーＡを適用することの表示を設定する。要求がポリシーＡを識別する識別子を含む場合には、オペレーティングシステム１１０４は、識別子を使用して、例えば、ポリシー２０６内のポリシーＡを識別、例えば探し出し、ポリシーＡを適用することの表示を設定する。オペレーティングシステム１１０４は、マイポリシーをポリシーＡに設定する要求の結果を、プロセス１３０２に返す（段階３）。

続いて、プロセス１３０２は、ポリシーＡが活動状態の状態で、処理を継続する（段階４）。この処理には、オペレーティングシステム１１０４との対話を含めることができる。例えば、ユーザは、プロセス１３０２を使用して、１つまたは複数のウエブアプリケーションをアップロードすることができる。ウエブアプリケーションをアップロードすると、ユーザは、プロセス１３０２を介してアップロードしたウエブアプリケーションの処理を要求している。このユーザ要求に応答して、プロセス１３０２は、アクセス制御ＡＰＩ １１０６を介して、マイポリシーをポリシーＢに設定する要求をオペレーティングシステム１１０４に送る（段階５）。例えば、プロセス１３０２は、アップロードされたユーザ開始によるウエブブラウザアプリケーションの完全性を信用することなく、ポリシーをより厳格なポリシーＢに設定することを要求する。それに応答して、オペレーティングシステム１１０４は、プロセス１３０２に対するポリシーをポリシーＢに設定する（段階６）。オペレーティングシステム１１０４は、マイポリシーをポリシーＢに設定することの要求の結果をプロセス１３０２に返す（段階７）。

ポリシーをポリシーＢに設定することの要求の返された結果に応じて、プロセス１３０２は処理を継続する（段階８）。例えば、ポリシーをポリシーＢに設定する要求が正常に終わった場合には、プロセス１３０２は、要求ウエブアプリケーションの実行を開始する。ここで、より厳格なポリシーＢがウエブアプリケーションプロセスに適用される。一方、ポリシーをポリシーＢに設定する要求が正常に終わらなかった場合には、プロセス１３０２は、ウエブアプリケーションの実行を開始せず、エラー状態、例えばウエブアプリケーションを実行しない理由をユーザに通知することができる。

いくつかの実施形態においては、ポリシーＢがウエブアプリケーションプロセスに適用されて、ポリシーＡが実質上、取り消される。この場合、ポリシーＡは取消し可能ポリシーであった可能性がある。いくつかの実施形態においては、ポリシーＡとポリシーＢの両方が、ウエブアプリケーションプロセスに適用される。ここで、ポリシーＡは取消し不能であり、したがって、実際上、ポリシーＢとともに残留する。

図１４は、取消し可能自主規制ポリシーをプロセスに設定するために、いくつかの実施形態においてファシリティが使用する通信フローを示すブロック図である。一例として、コンピュータ上のユーザは、アプリケーションプログラムを実行しており、マクロを実行すべきポイントに到達している。マクロによって実行されるべき処理を知って、アプリケーションプロセス１４０２は、アクセス制御ＡＰＩ １１０６を介して、取消し可能マイポリシーをポリシーＡに設定する要求を、コンピュータ上で実行中のオペレーティングシステム１１０４に送る（段階１）。例えば、ポリシーＡは、現在プロセス１４０２に適用されているポリシーよりも、より制限的なポリシーとすることができる。

それに応答して、オペレーティングシステム１１０４は、プロセス１４０２に対するポリシーをポリシーＡに設定し（段階２）、取消し可能マイポリシーをポリシーＡに設定する要求の結果をプロセス１４０２に返す（段階３）。ポリシーＡが正常に設定される場合には、オペレーティングシステム１１０４は、識別子および／または状態情報を含むクッキー、例えば、ポリシーＡより先にプロセス１４０２に適用されていた、以前のいずれかのポリシーに関する情報もプロセス１４０２に返す。この識別子は、そのホルダーを、取消し可能ポリシーを取り消す認可を有するプロセスとして認証する。

取消し可能ポリシーをポリシーＡに設定する要求に対して返された結果に応じて、プロセス１４０２は処理を継続する（段階４）。例えば、取消し可能ポリシーをポリシーＡに設定する要求が正常に行われた場合、プロセス１４０２は、マクロの実行へと進む。ここで、より制限的なポリシーＡがマクロに適用される。一方、取消し可能ポリシーをポリシーＡに設定する要求が正常に行われなかった場合には、プロセス１４０２は、マクロの実行に進まない。

続いて、例えば、マクロが実行を終了したことを検出した後に、プロセス１４０２は、アクセス制御ＡＰＩ １１０６を介して、マイポリシー、例えばポリシーＡの取消し要求をオペレーティングシステム１１０４に送る（段階５）。プロセス１４０２は、オペレテーティングシステム１１０４から、マイポリシーの取消し要求とともに先に受信された「クッキー」を提出する。マイポリシーの取消し要求の受取りに応答して、オペレーティングシステム１１０４は、クッキー内に収容された識別子を使用してプロセス１４０２を、そのポリシーを取り消す認可を有するプロセスとして認証する。プロセス１４０２の認証に続いて、オペレーティングシステム１１０４はポリシーＡを取り消して、クッキー内に識別されたポリシーをプロセス１４０２に適用する（段階６）。オペレーティングシステム１１０４は、マイポリシーの取消し要求の結果をプロセス１４０２に返し（段階７）、プロセス１４０２は処理を継続する（段階８）。別の実施形態においては、マイポリシー取消し要求は、現在の取消し可能ポリシーの取消しに続いて、適用されるべきポリシーを識別することができる。

図１５は、クライアント・サーバのアクセス制御のチェックを実行するために、いくつかの実施形態において、ファシリティが使用する通信フローを示すブロック図である。一例として、電子メールクライアントプロセス１５０２は、電子メールサーバプロセス１５０４をコールして、電子メールメッセージをアドレス指定された受信者に送ることができる（段階１）。クライアントプロセス１５０２は、その識別子、例えばクライアントＩＤを、コールの一部としてサーバプロセス１５０４に送る。それに応答して、アドレス指定された受信者に電子メールを送る試みをする前に、サーバプロセス１５０４は、クライアントプロセス１５０４が要求動作を実行、例えば、この場合には電子メールをアドレス指定された受信者に送るのに十分な特権を有するかどうかを決定するチェックを実行する。すなわち、サーバプロセス１５０４は、クライアントプロセス１５０２の識別を仮定することによって、クライアントプロセス１５０２を偽装する（段階２）。

クライアントプロセス１５０２の識別を仮定することによって、サーバプロセス１５０４は、アクセス制御ＡＰＩ １１０６を介して、アクセス制御のチェックの実行要求をオペレテーティングシステム１１０４に送る（段階３）。この要求には、クライアントプロセス１５０２の識別、例えばクライアントＩＤ、および要求動作、例えば、電子メールメッセージをアドレス指定された受信者に送ることが含まれる。オペレーティングシステム１１０４は、アクセス制御のチェックを実行して、クライアントプロセス１５０２が要求動作を実行する認可を有するかどうかの表示をサーバプロセス１５０４に送る。いくつかの実施形態においては、オペレーティングシステム１１０４は、ポリシー２０６内の適用可能なポリシーをチェックして、クライアントプロセス１５０２がその要求動作を実行する認可を有するかどうかを決定することができる。いくつかの実施形態においては、オペレーティングシステム１１０４は、認可モジュール２０２を使用して、クライアントプロセス１５０２が、その要求動作を実行する認可を有するかどうかを決定することができる。アクセス制御のチェックの結果に応じて、サーバプロセス１５０４は、電子メールメッセージの処理を継続する、例えば、電子メールメッセージをアドレス指定された受信者に送るか、または電子メールメッセージの処理を停止して、エラーメッセージをクライアントプロセス１５０２に送る。上記の例においては、サーバプロセス１５０４は、アクセス制御のチェックの実行要求をオペレテーティングシステム１１０４に送ったが、サーバプロセス１５０４は、認可モジュール２０２を直接的に呼び出して、アクセス制御のチェックを実行してもよかったことが認識されるであろう。

図１６は、いくつかの実施形態による、アプリケーションプログラム中に埋め込まれたポリシーを抽出するプロセスを示している。これによって、そのポリシーを、そのアプリケーションを含むソフトウエアパッケージの一部として配布することが可能となり、アプリケーションを含むコードのいずれかの実行が開始される以前に、そのポリシーが抽出されて適用される。したがって、そのコードが悪性コードによって利用された欠陥を含む場合には、このアプローチを使用することによって、攻撃損害を低減／または阻止することができる。

ステップ１６０２において、ポリシーがアプリケーションプログラムのコードの一部として埋め込まれる。この埋込みポリシーは、アプリケーションコードにおいて境界指定される。いくつかの実施形態において、コード内のポリシーは、例えば、実行可能なコード内にフラグを配置することによって、境界指定され、このフラグは、オペレーティングシステムまたは埋込みポリシーを抽出するのに適したその他のプロセスに、そのポリシーの存在を指示する。ステップ１６０４において、アプリケーションプログラムコードは、結果として得られるイメージを保護するように署名がされている。コードの署名は、署名されたイメージは、ディジタル署名のプロバイダ、例えばコードの署名者のものであることの保証を与える。公的キーおよび私的キーを使用するディジタル署名は、当業者には周知であり、したがって本明細書においてはさらに詳細を述べない。

続いて、ステップ１６０６において、アプリケーションプログラムイメージを、例えばコンピュータ上にロードする要求が行われる。ステップ１６０８において、オペレーティングシステム、またはオペレーティングシステムのローダ構成要素が、アプリケーションプログラムイメージの完全性を決定する。オペレーティングシステムがアプリケーションプログラムイメージの完全性が満足でないと決定する場合には（ステップ１６１０）、ステップ１６１８において、オペレーティングシステムは、アプリケーションプログラムイメージをコンピュータにロードしない。オペレーティングシステムは、また、エラー状態を生成して、エラーの表示を提供する。

一方、オペレーティングシステムが、アプリケーションプログラムイメージの完全性は満足であると決定する場合には（ステップ１６１０）、ステップ１６１２において、オペレーティングシステムは、アプリケーションプログラムイメージをコンピュータにロードする。ステップ１６１４において、オペレーティングシステムは、埋込みポリシーの存在をチェックして、埋込みポリシーが検出される場合には、アプリケーションプログラムイメージからポリシーを抽出する。いくつかの実施形態において、オペレーティングシステムは、抽出したポリシーを、オペレーティングシステムが提供するポリシーテーブルまたはリポジトリ、例えば、ポリシー２０６に記憶させることができる。ステップ１６１６において、オペレーティングシステムは、ロードしたアプリケーションプログラムイメージに、抽出したポリシーを適用する。

図１７は、いくつかの実施形態による、レガシーなアプリケーションプログラムをファシリティがロードして、それにポリシーを適用する方法１７００を示すフロー図である。一例として、レガシーなアプリケーションプログラムは、コンピュータ上に記憶することができる。レガシーなアプリケーションコードを修正することに伴うリスク、または潜在的に多数のレガシーなアプリケーションプログラムのアンイントール、再インストール、および再構成に関連付けられた煩わしさおよびコストを招くことなくレガシーなアプリケーションプログラムにポリシーを適用したいために、レガシーなアプリケーションプログラムに対するポリシーは、レガシーなアプリケーションプログラムと独立のプロセスによって配布することができる。

開始ステップから始まり、ステップ１７０２において、レガシーなアプリケーションのホストとして働くコンピュータ上で実行中のオペレテーティングシステムは、プロセスから、レガシーなアプリケーションプログラムためのポリシーをロードする要求を受信する。例えば、このプロセスは、コンピュータ上で実行中のアップデートプログラムのインスタンスでもよい。さらに、ポリシー内に含めることのできる規則に加えて、ポリシーには、独立であるとともに、レガシーなアプリケーションコードのバージョン、レガシーなアプリケーションコードに組み込まれたパッチレベル、その他などの情報に依存するとともに、それに基づいて適用可能な規則をさらに含めることができる。ステップ１７０４において、オペレーティングシステムは、プロセスからポリシーを受け取り、そのポリシーをレガシーなアプリケーションプログラムに対してロードする。オペレーティングシステムは、そのプロセスが、そのレガシーなアプリケーションプログラムに適用可能なポリシーを配布することを認可されていることを確認することができる。また、オペレーティングシステムは、ポリシーを受信して記憶する以前に、そのプロセスおよびポリシーの両方の完全性を確認することもできる。いくつかの実施形態においては、オペレーティングシステムは、そのポリシーをポリシーテーブルまたはレポジトリ内にロードして、そのポリシーをレガシーなアプリケーションプログラムに関連づける。この関連付けは、ポリシーのメタデータによって指示することができる。

続いて、ステップ１７０６において、オペレーティングシステムは、レガシーなアプリケーションプログラムのロード要求を受信する。ステップ１７０８において、オペレーティングシステムは、レガシーなアプリケーションプログラムに適用可能なポリシーがあるかどうかをチェックして決定する。レガシーなアプリケーションプログラムが、適用可能なポリシーを含まない場合には、ステップ１７０４において、オペレーティングシステムは、レガシーなアプリケーションプログラムをロードしない。この場合に、オペレーティングシステムは、実際上、適用可能なポリシーを含むアプリケーションだけをロードして実行するように構成してもよい。オペレーティングシステムは、レガシーなアプリケーションプログラムをロードすることの失敗を示すエラーを返すことができる。エラーの表示をするのに続いて、オペレーティングシステムは処理を継続する。

ステップ１７０８において、オペレーティングシステムが、レガシーなアプリケーションプログラムは適用可能なポリシーを有すると決定する場合には、ステップ１７１０において、オペレーティングシステムはレガシーなアプリケーションプログラムをロードする。ステップ１７１２において、オペレーティングシステムは、それの実行中に、レガシーなアプリケーションプログラムにポリシーを適用して、処理を継続する。

前述の内容から、本発明の特定の実施形態を説明の目的で記述したが、本発明の趣旨と範囲から逸脱することなく、様々な修正が可能であることが認識されるであろう。したがって、本発明は、添付のクレームに明示的に記載された要素による場合を除いて、限定されるものではない。

ファシリティが実行される、少なくとも一部のコンピュータシステムに通常組み込まれる、選ばれた構成要素を例示するブロック図である。 いくつかの実施形態による、ファシリティの選ばれた構成要素を例示するブロック図である。 いくつかの実施形態による、ファシリティが使用するのに適当な事例のポリシーを例示する図である。 いくつかの実施形態による、拒否されたアクセス要求の監査をファシリティが実行する方法を例示するフローチャートである。 いくつかの実施形態による、本質的に危険な動作の監査をファシリティが実行する方法を例示するフローチャートである。 いくつかの実施形態による、ポリシーの微調整を容易にする学習をファシリティが実行する方法を例示するフローチャートである。 いくつかの実施形態による、段階アクセス制御のチェックをファシリティが提供する方法を例示するフローチャートである。 いくつかの実施形態による、アプリケーションプログラムのセキュリティリスクのレベルをファシリティが決定する方法を例示するフローチャートである。 いくつかの実施形態による、異常検出時により制限的なポリシーをファシリティが課する方法を例示するフローチャートである。 いくつかの実施形態による、異常検出時にポリシーをファシリティが課する方法を例示するフローチャートである。 いくつかの実施形態による、対象プロセスに対してポリシーを設定するのにファシリティが使用する通信のフローを例示するブロック図である。 いくつかの実施形態による、対象プロセスに対して取消し可能なポリシーを設定するのにファシリティが使用する通信のフローを例示するブロック図である。 いくつかの実施形態による、プロセスに対して自主規制ポリシーを設定するのにファシリティが使用する通信のフローを例示するブロック図である。 いくつかの実施形態による、プロセスに対して取消し可能な自主規制ポリシーを設定するのにファシリティが使用する通信のフローを例示するブロック図である。 いくつかの実施形態による、クライアントサーバアクセス制御チェックを実行するのにファシリティが使用する通信のフローを例示するブロック図である。 いくつかの実施形態による、アプリケーションプログラムに埋め込まれたポリシーをファシリティが抽出するプロセスを例示する図である。 いくつかの実施形態による、レガシーなアプリケーションプログラムにファシリティがポリシーをロードして適用する方法のフローチャートである。

Claims (32)

1. 第１のポリシーが第１の資源にアクセスする認可があるかどうかを決定するのに使用され、および第２のポリシーが前記第２の資源にアクセスする認可があるかどうかを決定するのに使用される内容を有するコンピュータ可読記憶媒体であって、
   前記第１のポリシーに自主規制ポリシーを設定するための第１の要求を提出することと、
   前記第１の資源にアクセスするための少なくとも１つの要求を提出することと、
   前記第２のポリシーに自主規制ポリシーを設定するための第２の要求を提出することと、
   第２の資源にアクセスするための少なくとも１つの要求を提出することと
   をコンピュータに動作させる内容を有することを特徴とするコンピュータ読取可能な記憶媒体。
2. 前記第２のポリシーが、前記第１のポリシーよりもより制限的であることを特徴とする請求項１に記載のコンピュータ読取可能な記憶媒体。
3. 前記第２のポリシーに自主規制ポリシーを設定するための前記第２の要求が、前記第１のポリシーを取り消すことを特徴とする請求項１に記載のコンピュータ読取可能な記憶媒体。
4. 前記第２のポリシーに自主規制ポリシーを設定するための前記第２の要求が、前記第１のポリシーを取り消さないことを特徴とする請求項１に記載のコンピュータ読取可能な記憶媒体。
5. 前記第２のポリシーに自主規制ポリシーを設定するための前記第２の要求が、前記第１のポリシーを取り消さずに、前記第１のポリシーおよび前記第２のポリシーが、前記第２の資源にアクセスする認可があるかどうかを決定するのに使用されることを特徴とする請求項１の記載のコンピュータ読取可能な記憶媒体。
6. クライアント・サーバのアクセス制御のチェックを提供するコンピュータシステム上の方法であって、前記コンピュータシステム上で実行中のプロセスの制御の下に、
   第１のプロセスにより提供される資源に対する、識別子を含む要求を前記プロセスから受信するステップと、
   前記第１のプロセスを偽装するステップと、
   前記第１のプロセスが前記資源を要求する認可を有するかどうかを決定するステップと、
   前記第１のプロセスが前記資源を要求する認可を有すると決定した後に、前記資源に対する前記要求を処理するステップと
   を備えたことを特徴とする方法。
7. 前記プロセスが、前記第１のプロセスの識別を仮定することによって、前記第１のプロセスを偽装することを特徴とする請求項６に記載の方法。
8. 前記プロセスは、前記第１のプロセスがアクセス制御のチェックを実行する要求を送ることにより前記資源を要求する認可を有するかどうかを決定し、および前記要求は、前記第１のプロセスから受信する前記識別子および前記要求された資源の表示を含むことを特徴とする請求項６に記載の方法。
9. 前記アクセス制御のチェックを実行する要求が、オペレーティングシステムに対して行われることを特徴とする請求項８に記載の方法。
10. 前記第１のプロセスが前記資源を要求する認可を有するかどうかを決定するステップは、前記第１のプロセスに適用可能なポリシーのチェックを行うステップを含むことを特徴とする請求項６に記載の方法。
11. アクセス制御のチェックを実行する場合に、ポリシーが制御されるプロセスに適用されて、前記制御されるプロセスが資源にアクセスする特権を有するどうかを決定するシステム上で実行中の前記制御されるプロセスに前記ポリシーを設定するシステムであって、
    制御するプロセスから前記制御されるプロセスに前記ポリシーを設定する要求を受信する構成要素と、
    前記制御するプロセスが前記制御されるプロセスに前記ポリシーを設定する特権を有するかどうかを決定する構成要素と、
    前記制御するプロセスが前記制御されるプロセスに前記ポリシーを設定する特権を有すると決定するのに応答して、前記ポリシーを前記制御されるプロセスに設定する構成要素と
    を備えたことを特徴とするシステム。
12. 前記ポリシーは、取消し可能ポリシーであり、および前記ポリシーを前記制御されるプロセスに設定した後に、前記設定されたポリシーの取消しを要求するのに使用する識別子を前記制御するプロセスに送ることを特徴とする請求項１１に記載のシステム。
13. 前記制御されるプロセスに前記ポリシーを設定した後に、前記ポリシーを設定する前に実施された前のポリシーの表示を前記制御するプロセスに送る構成要素をさらに備えたことを特徴とする請求項１２に記載のシステム。
14. 前記制御されるプロセスへの前記ポリシーを取り消す要求を受信する構成要素と、
    前記制御されるプロセスへの前記ポリシーを取り消す要求を認証する構成要素と、
    前記ポリシーを取り消す要求を認証するのに応答して、前記制御されるプロセス上の前記ポリシーを取り消す構成要素と
    をさらに備えたことを特徴とする請求項１２に記載のシステム。
15. 前記要求を認証する構成要素は、前記識別子が前記ポリシーを取り消す要求の一部として受信されたかどうかを決定するチェックを行う構成要素を含むことを特徴とする請求項１４に記載のシステム。
16. 前記ポリシーを取り消す要求が、前記制御するプロセスから受信されることを特徴とする請求項１４に記載のシステム。
17. 前記ポリシーを取り消す要求が、前記制御されるプロセスから受信されることを特徴とする請求項１４に記載のシステム。
18. 前記ポリシーを取り消す要求が、前記制御するプロセスまたは前記制御されるプロセス以外のプロセスから受信されることを特徴とする請求項１４に記載のシステム。
19. 前記ポリシーを取り消す要求を認証するのに応答して、取り消したばかりの前記ポリシーを設定する前に実施された前のポリシーを前記制御されるプロセスに設定する構成要素をさらに備えたことを特徴とする請求項１４に記載のシステム。
20. 前記制御されるプロセスおよび前記制御するプロセスが、同一のプロセスであることを特徴とする請求項１１に記載のシステム。
21. 前記制御されるプロセスが、前記制御するプロセスの実行するスレッドであることを特徴とする請求項１１に記載のシステム。
22. 記憶されたポリシーがコンピュータ上で実行するアプリケーションプログラムのインスタンスに、続いて適用される内容を有するコンピュータ読取可能な記憶媒体であって、
    前記アプリケーションプログラムのインスタンス以外の、別のコンピュータ上で実行中のプロセスによって行われ、アプリケーションプログラムに適用可能なポリシーをロードする要求を受信することと、
    前記ポリシーをポリシーのレポジトリに記憶することと、
    前記対応するアプリケーションプログラムに前記ポリシーを関連付けることと
    をコンピュータに動作させる内容を有することを特徴とするコンピュータ読取可能な記憶媒体。
23. 前記コンピュータ上に前記アプリケーションプログラムをロードする要求を受信することと、
    前記アプリケーションプログラムに適用可能なポリシーが前記ポリシーのレポジトリに存在するかどうかを決定し、前記アプリケーションに適用可能なポリシーが存在すると決定するのに応答して、前記コンピュータ上に前記アプリケーションプログラムをロードし、および前記適用可能なポリシーを前記アプリケーションプログラムに適用させることと
    をコンピュータに動作させる内容をさらに有することを特徴とする請求項２２に記載のコンピュータ読取可能な記憶媒体。
24. 前記アプリケーションプログラムに適用可能なポリシーが前記ポリシーのレポジトリに存在するかどうかを決定することと、
    前記アプリケーションプログラムに適用可能なポリシーが存在しないと決定するのに応答して、前記アプリケーションプログラムを前記コンピュータ上にロードしないことと
    をコンピュータに動作させる内容をさらに有することを特徴とする請求項２３に記載のコンピュータ読取可能な記憶媒体。
25. 埋込まれたポリシーを受信するためのコンピュータシステムにおける方法であって、
    アプリケーションプログラムイメージをロードする要求を受信するステップと、
    前記アプリケーションプログラムイメージ内にポリシーが埋め込まれているかどうかを決定するステップと、
    前記アプリケーションプログラムイメージ内にポリシーが埋め込まれていると決定するのに応答して、
    前記アプリケーションプログラムイメージから前記ポリシーを抽出するステップと、
    前記アプリケーションプログラムイメージをロードするステップと、
    前記抽出されたポリシーを前記ロードされたアプリケーションプログラムイメージに適用するステップと
    を備えたことを特徴とする方法。
26. 前記埋込まれたポリシーが、ＸＭＬを使用して宣言されることを特徴とする請求項２５に記載の方法。
27. 前記埋込まれたポリシーが、プログラミング言語にコード化されていることを特徴とする請求項２５に記載の方法。
28. 前記埋込まれたポリシーを抽出する前に、前記アプリケーションプログラムイメージの完全性を検証し、前記アプリケーションプログラムイメージをロードし、および前記抽出されたポリシーを前記アプリケーションプログラムイメージに適用するステップと、
    前記埋込まれたポリシーを抽出し、前記アプリケーションイメージをロードし、および前記アプリケーションプログラムイメージの完全性を検証することに続いて、前記抽出されたポリシーを前記アプリケーションプログラムイメージに適用するステップと
    をさらに備えたことを特徴とする請求項２５に記載の方法。
29. 前記抽出されたポリシーをポリシーのレポジトリに記憶するステップをさらに備えたことを特徴とする請求項２５に記載の方法。
30. 記憶されたポリシーが記アプリケーションプログラムのインスタンスに適用され、別のプロセスに適用可能なポリシーをプロセスから受信するシステムであって、
    レガシーなアプリケーションプログラムに適用可能なポリシーを配布する動作が可能な、前記レガシーなアプリケーションプログラムのプロセスではないアップデートプロセスの構成要素と、
    前記受信されたポリシーをポリシーのレポジトリに記憶して、および前記ポリシーを前記レガシーなアプリケーションプログラムに関係付ける動作も可能である、前記レガシーなアプリケーションプログラムに適用可能なポリシーを受信する動作が可能なポリシーをロードする構成要素と
    を備えたことを特徴とするシステム。
31. 前記レガシーなアプリケーションプログラムのイメージをロードする要求を受信する動作が可能であり、ならびに前記レガシーなアプリケーションプログラムのイメージに適用可能なポリシーが前記ポリシーのレポジトリに存在するかどうかを決定し、前記アプリケーションプログラムのイメージに適用可能なポリシーが存在することを決定することに応答して、前記アプリケーションプログラムの前記イメージをロードし、および前記ポリシーを前記アプリケーションプログラムの前記イメージに適用する動作が可能である前記アプリケーションをロードする構成要素をさらに備えたことを特徴とする請求項３０に記載のシステム。
32. 前記ローダする構成要素は、前記アプリケーションプログラムのイメージに適用可能なポリシーが存在しないことを決定することに応答して、前記アプリケーションプログラムのイメージをロードしない動作が可能であることを特徴とする請求項３１に記載のシステム。
    
    

Images