コンピュータを監視して前記コンピュータ中の異常状態を検出することと、前記コンピュータ中の異常状態の検出に応じて、前記コンピュータ内部でポリシーの適用を起動することとをコンピュータに実行させる内容を有するコンピュータ読取可能な記憶媒体。前記異常状態が、コンピュータ上で実行されているプロセスにおいて検出され、および前記ポリシーが、前記プロセスの集まりに対して起動されることを特徴とする請求項1に記載のコンピュータ読取可能な記憶媒体。前記異常状態が、プロセスの集まりにおいて検出され、および前記ポリシーが、前記プロセスの集まりに対して起動されることを特徴とする請求項1に記載のコンピュータ読取可能な記憶媒体。前記ポリシーが、前記コンピュータで実行されているすべてのプロセスに対して起動されることを特徴とする請求項1に記載のコンピュータ読取可能な記憶媒体。前記コンピュータを監視して前記異常状態の停止を検出することと、前記異常状態の停止を検出すると、前記コンピュータ内のポリシーの適用を停止することとをコンピュータに実行させる内容をさらに有することを特徴とする請求項1に記載のコンピュータ読取可能な記憶媒体。前記コンピュータ命令が、前記コンピュータ上で実行するのに適したオペレーティングシステムに一体化され、および一部として実行されることを特徴とする請求項1に記載のコンピュータ読取可能な記憶媒体。前記ポリシーが、集中されたポリシーの記憶の一部として保持されることを特徴とする請求項1に記載のコンピュータ読取可能な記憶媒体。コンピュータ内で第1のポリシーを適用するステップと、前記コンピュータを監視して、前記コンピュータ中の異常状態を検出するステップと、前記コンピュータ中の異常状態の検出に応じて、前記コンピュータ内で第2のポリシーを適用するステップとを備えたポリシーを適用するコンピューティングシステムにおける方法。前記第1および第2のポリシーが、前記コンピュータ上で実行されているプロセスに適用されることを特徴とする請求項8に記載の方法。前記第1および第2のポリシーが、前記コンピュータ上で実行されているアプリケーションプログラムのインスタンスに適用されることを特徴とする請求項8に記載の方法。前記第1および第2のポリシーが、前記コンピュータ上で実行されているすべてのプロセスに適用されることを特徴とする請求項8に記載の方法。前記第1のポリシーが、前記第2のポリシーよりも制限が少ないことを特徴とする請求項8に記載の方法。前記ポリシーが、前記コンピュータ上の資源を管理するための少なくとも1つの規則を含むことを特徴とする請求項8に記載の方法。前記第1および第2のポリシーが、集中されたポリシーの記憶の一部として保持されることを特徴とする請求項8に記載の方法。前記コンピュータを監視して前記異常状態の終了を検出するステップと、前記異常状態の終了を検出すると、前記コンピュータ内で前記第2のポリシーの適用を停止するステップとをさらに備えたことを特徴とする請求項8に記載の方法。前記コンピュータ内で前記第1のポリシーを再適用するステップをさらに備えたことを特徴とする請求項15に記載の方法。資源にアクセスする認可を決定するポリシーを適用するシステムであって、プリンシパルに適用可能な第1のポリシーと、前記プリンシパルに適用可能な第2のポリシーと、前記第1のポリシーを前記プリンシパルに適用して前記プリンシパルが非異常状態においてコンピュータ上で要求された動作を実行する認可を有するかどうかを決定する動作を実施し、さらに前記第2のポリシーを前記プリンシパルに適用して前記プリンシパルが異常状態において前記コンピュータ上で前記要求された動作を実行する認可を有するかどうかを決定する動作を実施する認可のモジュールとを備えたことを特徴とするシステム。前記プリンシパルが、前記コンピュータ上で実行中のアプリケーションプログラムプロセスであることを特徴とする請求項17に記載のシステム。前記プリンシパルが、前記コンピュータ上で実行中のアプリケーションプログラムプロセスと、前記アプリケーションプロセスがコンピュータ上で実行されているユーザの内容との組合せであることを特徴とする請求項17に記載のシステム。前記第1および第2のポリシーが、前記コンピュータ上で実行されているアプリケーションプログラムのプロセスに適用されることを特徴とする請求項17に記載のシステム。前記第1および第2のポリシーが、前記コンピュータ上で実行されているアプリケーションプログラムのすべてのプロセスに適用されることを特徴とする請求項17に記載のシステム。前記第1および第2のポリシーが、集中されたポリシーの一部として保持されることを特徴とする請求項21に記載のシステム。通常、マルウエアは、コード欠陥を利用することによってプロセスに感染する。危うくされたプロセスの内部でマルウエアが実行されると、プロセスが実行されているユーザのコンテキストのアクセス権を引き継ぎ、ユーザに対して利用可能なすべての資源に対するアクセスを得るが、それは元のプロセスがかつて必要としたものよりはるかに大きくなる可能性がある。したがって、コンピュータ上の資源のセキュリティを改善しかつ増強するアクセス認可accessauthorizationに対する統合アプローチは、有用性が高いといえる。コンピュータシステム上のアプリケーションプログラムおよびオペレーティングシステムの利用から発生する逆効果からコンピュータシステムを保護するソフトウエアファシリティファシリティfacilityについて述べる。いくつかの実施形態において、ファシリティは、オペレーティングシステムの不可欠の部分として実現され、およびオペレーティングシステムに論理駆動のアクセス制御レイヤlogic-drivenaccesscontrollayerを追加する。例えば、ファシリティは、オペレーティングシステムのアクセス制御機構に不可欠の方法として実現される。ファシリティは、セキュリティに敏感なsecurity-sensitive種々の資源アクセスに関する認可の問い合わせを受け取って、集中されたポリシーに基づいて資源アクセスを許可または拒否する決定を返す。ポリシーは、一例としてネットワーク、ファイルシステム、アプリケーションプログラムなどの資源を管理し、かつ保護する方法を決定する1組の規則および慣行である。集中されたポリシーの記憶装置において、ポリシーの規則は集中的に配置されており、規則および/またはポリシーを集中的に呼び出し、かつ集中的に設定することが可能となる。これは、分散型またはオブジェクト単位per-objectのアクセス制御モデルとは対照的に、通常、物理オブジェクトに結び付けられたアクセス制御リストを使用して実現される。認可モジュールは、ユーザモードプログラム、例えばユーザ文脈で実行中のアプリケーションプログラムなど、が発行する資源へのアクセス要求に応ずる、様々なオペレーティングシステム構成要素が直接的に問い合わせをすることができる。代替的には、認可モジュールは、そのようなオペレーティングシステム構成要素の上部に位置するインターセプションレイヤinterceptionlayerによって問い合わせをすることができる。インターセプションレイヤは、リソースにアクセスするためにユーザモードプログラムが使用するシステムコールファンクションを中断し、中断されたシステムコールファンクションにラッパーwrapperを適用するコードである。認可モジュールは、そのアクセス制御決定すなわち、許可または拒否を、資源アクセスを試みているアプリケーションプログラム、例えばアプリケーションプロセスの識別identityまたはアプリケーションプログラムの識別とアプリケーションが実行されているユーザの識別との組合せのいずれかであり、およびプリンシパルに適用されるポリシーである、プリンシパルの識別に基づいて行う。実施形態において、ファシリティは監査機能を提供する。例えば、ポリシーは、認可が許可例えば、授与されるか、または拒否例えば、阻止されるかにかかわらず、特定の動作を監査の対象として指示することによって、エントリが監査ログに加えられるようにすることができる。このエントリには、不適合規則failedrule、資源またはオブジェクト、およびプリンシパルの表示を含めることができる。本質的に危険な操作などの、ある特定の操作に対しては、そのエントリには、規則、その規則が許可されたか拒否されたか、資源またはオブジェクト、およびプリンシパルの表示を含めることができる。ファシリティは、さらに、監査に基づいてイベントeventを始動することができる。例えば、ファシリティは、プリンシパル例えば、アプリケーションプログラムおよび/またはユーザまたはその他の当事者に、不適合規則または本質的に危険な操作の通知または表示を提供することができる。実施形態において、ファシリティは、ファシリティが規則を適用する代わりに、規則を試験するか、または規則を報告する学習モード機能を提供する。例えば、ポリシーの規則は、動作を実行する認可要求を拒否することを指定することができる。学習モードが、例えば、ポリシーの著者によって、規則に対して起動される場合には、ファシリティは、動作を実行する認可の要求を拒否する代わりに、動作を実行する認可を許可または授与するとともに、イベントを生成して、動作を実行する認可要求は拒否されたであろうことを指示する。ファシリティは、例えば、阻止されるであろう規則、動作を要求する前のアプリケーションプログラムの状態などを示す報告を生成することができる。学習モード機能は、ポリシーの微調整を容易にする。例えば、ポリシーの著者は、報告を分析して、ポリシー内の規則の制限をより多くするかまたは少なくする必要があるかどうかの決定を行うことができる。実施形態において、ファシリティは、段階アクセスtieredaccess制御のチェックの一部として実行される。ここで、ファシリティは、一連のアクセス制御のチェックの一部として、ポリシーチェックを実行する。例えば、資源要求が行われると、最初に従来型アクセス制御機構が呼び出されて、要求された資源に対する認可があるかどうかが決定される。従来型アクセス制御機構が要求された資源に対する認可があるとの最初の決定に続いて、ファシリティが呼び出されて、そのポリシーをチェックして、要求された資源に対する認可があるかどうかを決定することができる。続いて、1つまたは複数のさらなるアクセス制御チェックを追加で呼び出して、要求された資源に対する認可があるかどうかを最終的に決定することができる。ファシリティの様々な実施形態およびその利点は、図面の図1~17を参照することによって最もよく理解できる。図面の要素は、必ずしも比例して拡大縮小せず、代わりに本発明の原理を明確に説明することに重点をおいている。図面全体を通して、様々な図面の同一部品および対応部品には、同一番号を使用している。図1は、ファシリティが実行される、少なくとも一部のコンピュータシステムに通常、組み込まれている、選択された構成要素を例示するブロック図である。これらのコンピュータシステム100には、コンピュータプログラムを実行するための1つまたは複数の中央処理ユニットCPU102;プログラムおよびデータ―データ構造を含む―をそれらが使用されている間に記憶するためのコンピュータメモリ104;プログラムおよびデータを永続的に記憶するハードドライブなどの永続的な記憶装置106;コンピュータ読取可能な媒体に記憶されたプログラムおよびデータを読み取るためのCD-ROMドライブなどのコンピュータ読取可能な媒体の駆動装置108;およびプログラムおよび/またはデータ―データ構造を含む―を交換するために、インターネットを介するなどして、コンピュータシステムを他のコンピュータシステムに接続する、ネットワーク接続110を含めることができる。ファシリティは、コンピュータシステム100またはその他のデバイスによって実行されるプログラムモジュールのような、コンピュータ読取可能な命令の一般的文脈において説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか、または特定の抽象データタイプを実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造などが含まれる。メモリ104および永続的な記憶装置106は、ファシリティを実現する命令を収容することができるコンピュータ読取可能な媒体である。ここで、メモリ104および永続的な記憶装置106は、ファシリティを実現する命令に加えて、様々なその他の内容を含むことがあることが認識されるであろう。ここで、コンピュータシステム100には、ビデオモニタまたはLCDパネルなどの、プログラム出力を指示する1つまたは複数の表示デバイス、およびキーボード、マイクロフォン、またはマウスなどのポインティングデバイスなどの、ユーザ入力を受信する1つまたは複数の入力デバイスを含めることができることが認識されるであろう。通常、上述のように構成されたコンピュータシステム100がファシリティの動作をサポートするのに使用されるが、ファシリティは、様々なタイプおよび構成にするとともに、様々な構成要素を有するデバイスを使用して実現することができることが認識されるであろう。図2は、いくつかの実施形態による、ファシリティの選ばれた構成要素を示すブロック図である。図2に示すように、ファシリティは認可モジュール202を含み、このモジュールは、コンピュータシステム100上で実行するのに適したオペレーティングシステム204の一体化構成要素として実現される。認可モジュール202は、一般に、ネットワークフェーシングアプリケーション、ネットワークフェーシングサービスおよびオペレーティングシステム構成要素などの高リスクプロセス、信用できない内容を取り扱うアプリケーション、ならびに信用できないコード、例えば、通常、インターネットによって配信されるコードなどに対する、追加の保護レイヤprotectionlayerとして機能する。認可モジュール202は、コンピュータシステム100上で利用可能な資源のポリシー駆動アクセス制御を実行するための論理を提供する。ファシリティは、また、認可モジュール202がそのアクセス制御決定をそれから行うポリシー206を含む。ポリシー206は、資源へのアクセスの認可要求を許可するか、または拒否するかを決定する規則である。いくつかの実施形態においては、ポリシー206は、オペレーティングシステム204および、特に、認可モジュール202によって施行される実行時規則、例えばバイナリ規則にコンパイルされる。いくつかの実施形態においては、ポリシー206は、集中ポリシー記憶装置centralizedpolicystoreの一部として実現されて、この集中ポリシー記憶装置は、例えばユーザおよび/または管理者が、ポリシー206内の規則を含みポリシー206を、中央から取り消したり、中央から設定したりすることを可能にする。認可モジュール202は、様々なオペレーティングシステムカーネル構成要素208が問い合わせをすることが可能であり、これらのカーネル構成要素は、プリンシパル、例えばプリンシパル212aが出す資源へのアクセス要求に答える。また、認可モジュール202の問い合わせは、資源にアクセスするためにプリンシパル、例えばプリンシパル212bが出すシステムコールファンクションを中断する、インターセプションレイヤ210が行うこともできる。インターセプションレイヤ210は、中断されたシステムコールファンクションにラッパーwrapperを適用して、認可モジュール202が適用可能なポリシー206に対するアクセス制御のチェックを実行することを可能にする。例えば、ラッパーを適用することには、プリンシパルおよび/またはコンピューティングシステム100に関連する様々な環境要因の識別を決定すること、およびこの情報を認可要求の一部として供給して、認可モジュール202へのシステムコールを実行してそれがアクセス制御のチェックを実行することを可能にすることが含まれる。さらに、認可モジュール202は、プリンシパル、例えばプリンシパル212cが直接的に問い合わせをすることもできる。実施形態によっては、認可モジュール202が実行するアクセス制御のチェックは、資源へのアクセス要求を行っているプリンシパルおよびそのプリンシパルに適用するポリシーの関数である。すなわち、認可モジュール202は、そのアクセス制御決定すなわち、許可または拒否を、プリンシパルの識別―コールしているアプリケーションプログラムの識別、またはコールしているアプリケーションプログラムの識別とそのためにそのアプリケーションプログラムが実行されているユーザの識別との組合せ―およびプリンシパルに適用可能なポリシーにおける規則に基づいて行う。実施形態によっては、認可モジュール202は、プリンシパルの識別および、そのアクセス制御決定を行う際のプリンシパルに適用可能なポリシーにおける規則の識別に加えて、一例として、要求アクセスのタイプ、環境因子―例えば、アプリケーションプログラムが実行されている、企業ネットワーク内部または公共ネットワークに接続されたコンピュータ、コンピュータのパッチレベル、その他―などのパラメータをさらに考慮することができる。実施形態によっては、ファシリティには、図2に破線または断続線によって示されている、任意選択の異常検出anomalydetectionモジュール214を含めることができる。異常検出モジュール214は、異常状態を検出するために、全体的には、コンピュータシステム100の挙動およびコンピュータシステム100で実行されているプログラムを監視する機能を果たす。実施形態によっては、異常検出モジュール214は、異常の検出時に第1の通知を、先に検出された異常の停止検出時に、後続の第2の通知を、ファシリティに提供する。これによって、ファシリティは、異常検出時に、異常が終了するまでポリシー206の施行を起動することが可能となり、それ以後は、ポリシー206はもう施行されない。代替的に、ファシリティは、異常が検出されるまでより制限の少ないポリシーの組を最初に課してもよく、この場合には、異常が終了して再び制限の少ないポリシーの組が再び施行されるまで、より制限的なポリシーの組が施行される。異常検出モジュール214は、コンピュータシステム100上で実行される単一プロセス、コンピュータシステム100上で実行されるプロセス群、またはコンピュータシステム100全体のいずれかにおいて異常を検出することができる。上述のファシリティの態様は、説明のためだけのものであり、図示した構成要素の実現および/またはファシリティの使用もしくは機能性の範囲に関する限定を意味するものではない。例えば、いくつかの実施形態によっては、認可モジュール202は、オペレーティングシステム204の一部として、またはそれに一体化して実現する必要はなく、オペレーティングシステム204と分離して、またはその外部に、例えば非オペレーティングシステムプログラムとして実現することができる。さらに、いくつかの実施形態においては、ポリシー206は集中ポリシー記憶装置として、またはその一部として実現する必要はない。したがって、ポリシー206は、1つの場所にある必要はなく、例えば、分散モデルを使用して実現することができる。さらに、ポリシー206は、認可モジュール202の一部として、またはそれに収容されるものとして記述してあるが、ポリシー206は、認可モジュール202によってアクセス可能ありさえすれば十分である。以下の考察においては、ファシリティの実施形態は、様々な実証例と一緒に記述する。ここで、ファシリティの実施形態は、様々な観点でこれらの例から大きく外れる環境において使用できることが認識されるであろう。図3は、いくつかの実施形態による、ファシリティによる使用に適当な例示ポリシーを示す。例示ポリシーには、ウエブサーバアプリケーションを保護する規則が含まれる。一例として、アイテム302と表示されている、資源を要求するアプリケーションプロセスがチェックされて、それがアイテム304と表示されている、WebServerXウエブサーバプロセスであるかどうかが決定される。認可モジュール202が、要求元アプリケーションプロセスはWebServerXウエブサーバプロセスであると決定する場合には、認可モジュール202は、ポリシー内に含まれる規則に基づいて、要求された資源に対する認可を許可または拒否する。図示するように、例示ポリシーはWebServerXプロセスに与えられる特権またはアクセス権限を包含しており、そのデフォルトは、規則306に示すように、その特権またはアクセス権限が指定されない限り、要求された資源に対する認可を拒否することである。言い換えると、要求された資源がポリシーにおいて明示的に与えられていない限り、要求された資源に対する認可は拒否される。実施形態によっては、ポリシーは、アクセス制限を指定する規則、例えば特定の動作を実行する認可を拒否すべきことを指定する規則、または資源へのアクセスの認可を拒否する規則、あるいは監査を行わせる、例えばイベントをログ記録させる規則を包含することができる。例示ポリシーにおける第1の規則は、WebServerXプロセスが、アイテム308で示す、htmlファイルを、アイテム310で示す、Webディレクトリに書き込むことを許可する命令である。htmlは、例えば.html、.gif、その他のファイル種類の集合の表現である。Webディレクトリは、ウエブディレクトリとして構成されたディレクトリの集合の表現であり、セキュリティ管理者などのポリシーの製作者とは異なる、ウエブ管理者などの管理者による定義が可能である。例えば、認可モジュール202は、この規則に基づいて、パラメータhtmlで定義される種類のファイルを、パラメータWebディレクトリで定義される種類のディレクトリの1つに書き込む要求をしているWebServerXプロセスに応答して、許可決定すなわち、認可の授与を返す。したがって、ポリシー内の規則を、Webディレクトリのような動的かつ独立に定義されたオブジェクト群、およびhtmlのような動的で構成可能な環境パラメータに適用することができる。例示ポリシーにおける第2の規則は、それがアイテム314で示すユーザAのために実行されている場合には、WebServerXプロセスが、アイテム312で示す、FTPアップロードディレクトリに書込みをすることを許可する命令である。例えば、認可モジュール202は、この規則に基づいて、FTPアップロードディレクトリへの書込み要求をしているユーザAのために実行されているWebServerXプロセスに応答して、許可決定すなわち、認可の授与を返す。例示ポリシーにおける第3の規則は、アイテム316で示す、内向きhttpトラフィックを許可する命令である。例えば、認可モジュール202は、この規則に基づいて、内向きhttpデータを受信すること、例えばネットワーク接続上を伝送される、httpデータパケットを受信することを要求しているWebServerXプロセスに応答して、許可決定すなわち、認可の授与を返す。例示ポリシーにおける第4の規則は、アイテム320で示す、可変FTPが使用可能である場合に、アイテム318で示すFTPトラフィックを許可する命令である。ここで、FTPは変数であり、ポリシーを作成したセキュリティ管理者とは異なる管理者が設定することができる。例えば、認可モジュール202は、実行時のチェックを実行して、変数FTPが使用可能であるかどうかを決定し、そうであれば、この規則に基づいて、パラメータFTPトラフィックによって定義されるデータを送信または受信することを要求するWebServerXプロセスに応答して、許可決定すなわち、認可の授与を返す。一方、FTPが使用可能でない場合には、前述のアクセス要求に応答して、認可モジュール202はアイテム306で示す拒否決定すなわち、認可の拒否を返す。ポリシーには、上記の例示特権で示したアプリケーションプロセスなどの、オペレーティングシステム内部および外部のオブジェクトに対する特権を定義する、規則を含めることができるが認識されるであろう。ポリシー内の規則は、コンパイル式またはインタープリタ式コンピュータ言語を使用する書込みコードと同様の、リッチスキーマrichschemaを使用して指定することができる。例えば、このスキーマは、条件および一時的条件、例えばYであるときだけ、Xを許可するなど、動的に構成可能な環境パラメータおよび変数への依存性、環境因子への依存性、その他を規則に含めることをサポートすることができる。さらに、パラメータの使用によって、現在および将来のオブジェクトに適用する規則の作成が容易になる。例えば、特定の種類の文書を、パラメータで表現することが可能であり、そのパラメータを使用して、現在存在するものであれ、将来作成されるものであれ、その特定の種類のすべての文書に適用する制限を指定する規則を作成することができる。実施形態によっては、ポリシーが指定することによって、ある決定は、例えばポップアップダイアログボックスによって、エンドユーザに決定を委ねられるようにすることができる。図4は、いくつかの実施形態による、拒否されたアクセス要求の監査をファシリティが実施する方法400のフローチャートを示している。一例として、あるユーザ例えば、ユーザABCが、コンピュータにログオンして、ワードプロセシングアプリケーション例えば、WPAppを開始しており、コンピュータ上のディレクトリ例えば、YZDirに記憶されているファイル例えば、FileXを開くことを要求している。その結果として、WPAppは、ディレクトリYZDirに記憶された資源FileXへのアクセス要求を出す。開始ステップから始まり、認可モジュール202は、ステップ402において、認可問い合わせ、例えばYZDirに記憶されたFileXへのアクセスの認可要求を受信する。ステップ404において、認可モジュール202は、YZDirに記憶されたFileXへのアクセスの認可要求しているプリンシパルを識別する。上記の例においては、プリンシパルは、WPAppであるか、またはWPAppとユーザABCの組合せのいずれかとすることができる。ステップ406において、認可モジュール202は、識別されたプリンシパルに適用可能なポリシーを、例えば、ポリシー206などの集中ポリシー記憶装置から識別するとともに、プリンシパルの識別と適用可能なポリシーに基づいてアクセス制御のチェックを実施する。ステップ408において、認可モジュール202は、ステップ406において実施されたアクセス制御のチェックの結果が、アクセスを拒否するものであるかどうかを決定する。上記の例に続いて、ステップ408において、認可モジュール202は、識別された適用可能なポリシーを分析して、ポリシーにおける規則または特権が、そのプリンシパルがYZDirに記憶されたFileXにアクセスすることを認可するかどうかを決定する。認可モジュール202が、適用可能なポリシーがプリンシパルに要求動作を実行することを認可すると決定する場合には、ステップ420において、認可モジュール202は、プリンシパルが要求動作を実行することが認可されたことの表示である、許可決定を返して、最終ステップへと進む。一方、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと認可モジュール202が決定する場合には、ステップ410において、認可モジュール202は拒否決定を返し、これはプリンシパルが要求動作を実行することが認可されないことの表示である。ステップ412において、認可モジュール202は、プリンシパルにエラーストリングを返し、要求動作を実行する認可がないことをプリンシパルに通知することができる。ステップ414において、認可モジュール202は、監査が使用可能かどうかを決定するチェックを行う。適用可能なポリシーまたは規則に関連するフラグまたはレコードによって、監査を実施すべきかどうかを指示することができる。監査が使用可能でない場合には、認可モジュール202は、最終ステップへと進む。一方、監査が使用可能である場合には、認可モジュール202は、ステップ416において、監査ログにエントリを作成する。エントリは、拒否された要求、無効な規則、プリンシパル、および/または要求された資源を識別することができる。ステップ418において、認可モジュール202は、拒否要求の監査に基づいて1つまたは複数のイベントを始動することができる。例えば、認可モジュール202は、例えば電子メール、音声メール、テキストメッセージングなどを介して、セキュリティ管理者に、非認可動作を実行すること、プリンシパルによる非認可動作の実行の試みに続いてアプリケーションプロセスを終了すること、プリンシパルによる非認可動作の実行の試みに続いてより厳格なポリシーの組を課すること、その他の、プリンシパルによる試みの表示を提供することができる。それらのイベントを始動することに続いて、認可モジュール202は、最終ステップへと進む。当業者であれば、本明細書において開示した、これらおよびその他のプロセスならびに方法に対して、プロセスおよび方法において実行される機能は、異なる順序で実現できることを認識するであろう。さらに、概説したステップは、例示的なものにすぎず、本発明の本質から外れることなく、いくつかのステップを任意選択とすること、より少ないステップと組み合わせること、または追加のステップに拡張することができる。図5は、いくつかの実施形態による、本質的に危険な操作の監査をファシリティが実行する方法500のフロー図を示す。一例として、ユーザ例えば、ユーザABCはコンピュータにログオンして、ウエブブラウザプログラム例えば、WebBrowserを開始して、信用のできないウエブサイト例えば、WebSiteY上のウエブページ例えば、PageXへのアクセス要求をしている。結果として、WebBrowserは、WebSiteYからPageXを検索する要求を出す。ステップ502~508は、実質的に方法400のステップ402~408と同様である。ステップ508において、認可モジュール202が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと決定する場合には、ステップ510において、認可モジュール202は拒否決定を返し、これはプリンシパルが要求動作の実行を認可されていないことの表示である。上記の例において、WebBrowserは、信用できないサイトWebSiteYにアクセスする認可を得ることができない。ステップ512において、認可モジュール202は、エラーストリングをプリンシパルに返し、要求動作を実行する認可がないことをプリンシパルに通知することができる。エラーストリングを返した後に、認可モジュールは最終ステップへと進む。一方、認可モジュール202が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可すると決定する場合には、ステップ514において、認可モジュール202は許可決定を返し、これは、プリンシパルが要求動作の実行を認可されていることの表示である。ステップ516において、認可モジュール202は、認可された動作が本質的に危険な操作であるかどうかを決定するためのチェックを行う。例えば、ファシリティは本質的に危険な操作のリストを保持することができるとともに、認可モジュール202は、このリストをチェックして、認可された動作が本質的に危険な操作としてリストされているかどうかを決定することができる。認可された動作が、本質的に危険な操作であることがわかった場合には、ステップ518において、認証モジュール202が監査操作を実行する。例えば、認可モジュール202は、本質的に危険な操作監査ログに、本質的に危険な操作を実行することの要求および認可の表示のエントリを作成することができる。エントリには、本質的に危険な操作を実行することの認可を要求したプリンシパルの表示を含めてもよい。認可モジュール202は、本質的に危険な操作を実行する認可によって始動をかけることができる、さらに他の動作を実行してもよい。ステップ518において監査操作を実行するのに続いて、またはステップ516において認可された動作が本質的に危険な操作ではないと決定するのに続いて、認可モジュール202は最終ステップへと進む。実施形態によっては、認可モジュール202は、本質的に危険な操作監査ログに、本質的に危険な操作を実行する認可要求の表示を書き込んでもよい。上記の例の続きとして、信用のできないサイトWebSiteYにアクセスすることが本質的に危険な操作であり、さらに適用可能なポリシーはWebBrowserにWebSiteYにアクセスする認可を与えないことを仮定して、認可モジュール202は、拒否決定を返しステップ510、本質的に危険な操作を実行する認可要求と、その後の認可の拒否を、例えば、本質的に危険な操作監査ログに記録する。認可モジュール202は、本質的に危険な活動を実行する認可を要求したプリンシパルの表示も記録することができる。図6は、いくつかの実施形態による、ポリシーの微調整を容易にする学習をファシリティが実行する方法600のフロー図である。一例として、ユーザ例えば、ユーザABCがコンピュータ上にログオンして、ウエブブラウザプログラム例えば、WebBrowserを開始して、ウエブサイト例えば、WebSiteY上のウエブページ例えば、PageXへのアクセス要求をしている。その結果として、WebBrowserは、WebSiteYからPageXの検索要求を出す。ステップ602~608は、方法400のステップ402~408と実質的に同様である。ステップ608において、認可モジュール202が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可すると決定する場合には、ステップ610において、認可モジュール202は、プリンシパルが要求動作を実行することを認可されていることの表示である、許可決定を返して、最終ステップへと進む。一方、認可モジュール202が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと決定する場合には、ステップ612において、認可モジュール202は、要求動作の実行の認可を拒否する、ポリシーにおける規則に対する学習が使用可能であるかどうかをチェックして決定する。上記の例に続いて、WebBrowserに適用可能なポリシーに、WebBrowserのインターネットへのアクセス、したがってWebSiteYへのアクセスを明確に拒否するルールを含めてもよいが、規則を適用する代わりに学習を適用する表示を提供することもできる。認可モジュール202が、要求動作の実行の認可を拒否する規則に対する学習は使用可能ではないと決定する場合には、ステップ618において、認可モジュール202は、拒否決定を返し、これはプリンシパルが要求動作を実行することが認可されていないことの表示である。上記の例において、WebBrowserのインターネットへの、したがってWebSiteYへのアクセスを明確に拒否する規則は、学習を適用することの表示を有していないことがある。この場合には、この規則が適用されて、WebBrowserはWebSiteにアクセスすることを拒否される。ステップ620において、認可モジュール202は、プリンシパルにエラーストリングを返し、要求動作を実行する認可がないことをプリンシパルに通知する。エラーストリングを返すのに続いて、認可モジュールは最終ステップへと進む。一方、ステップ612において、認可モジュール202が、要求動作を実行する認可を拒否する規則に対する学習が使用可能であると決定する場合には、ステップ614において、認可モジュール202は、無効規則の表示を学習報告ログlearningreportlogにエントリを作成する。エントリには、無効規則となった動作を実行することの認可を要求した、プリンシパルの表示を含めてもよい。ステップ616において、認可モジュール202は、プリンシパルが要求動作を実行することを認可されていることの表示である、許可決定を返して、最終ステップへと進む。すなわち、適用可能な規則を適用する代わりに、認可モジュール202は、要求動作を実行する認可を与えて、このイベントの表示を記録する。セキュリティ管理者またはその他の関心のあるユーザは、次いで、学習報告ログの内容を分析して、規則またはポリシーが制限的すぎるか、または十分に制限的ではないかを決定して、規則またはポリシーを実際に施行または実現する前に、規則またはポリシーを微調整する。実施形態によっては、認可モジュール202は、要求動作を実行する認可を与えた規則の表示の学習報告ログにエントリを作成することができる。上記の例に続いて、ルールが、WebBrowserがインターネット、したがってWebSiteYにアクセスすることを明確に認可するとともに、学習を適用する表示も与えることを仮定して、認可モジュール202は許可決定を返すステップ610とともに、要求動作を実行することの認可を与えた規則の表示を記録する。この情報は、規則またはポリシーを微調整するのに使用することができる。例えば、報告ログのエントリから、資源にアクセスする認可が、容易に授与されすぎると決定されると、規則またはポリシーを、調節または変更して、その資源へアクセスする認可が授与される事例を減少させることができる。図7は、いくつかの実施形態による、段階アクセスtieredaccess制御のチェックをファシリティが提供する方法700のフロー図を示す。先の例の1つを再び参照すると、ユーザ例えば、ユーザABCはコンピュータにログオンして、ワードプロセシングアプリケーション例えば、WPAppを開始しており、コンピュータ上のディレクトリ例えば、YZDir内に記憶されたファイル例えば、FileXを開くことを要求している。その結果として、WPAppは、ディレクトリYZDirに記憶された資源FileXへのアクセス要求を出す。開始ステップから始まり、認可モジュール202は、ステップ702において、認可問い合わせ、例えば、YZDirに記憶されたFileXへのアクセスの認可要求を受信する。ステップ704において、ユーザのコンピュータで実行されているオペレーティングシステムは、従来のアクセス制御のチェックを実行する。上記の例に続いて、オペレーティングシステムは、ユーザがYZDirのFileXを開く例えば、読取りアクセス特権を有するかどうかをチェックして決定することができる。ステップ706において、オペレーティングシステムは、その従来のアクセス制御のチェック機構を使用して、FileXへのユーザアクセスを拒否すべきかどうかを決定する。オペレーティングシステムの従来のアクセスチェック機構が、そのユーザのFileXへのアクセスを拒否すべきであると決定すると、ステップ708において、オペレーティングシステムは、拒否決定を返して、最終ステップへと進む。この拒否決定は、ユーザが要求動作、例えばFileXを開くこと、を実行することが認可されていないことの表示である。一方、オペレーティングシステムの従来のアクセスチェック機構が、そのユーザのFileXへのアクセスを拒否すべきでないと決定する場合には、ステップ710において、認可モジュール202は、YZDirに記憶されたFileXへのアクセスの認可を要求しているプリンシパルを識別する。ステップ712において、認可モジュール202は、識別されたプリンシパルに適用可能なポリシーを、例えば、ポリシー206などの集中ポリシー記憶装置から識別して、プリンシパルの識別と適用可能なポリシーとに基づいてアクセス制御のチェックを実行する。上記の例に続いて、認可モジュール202は、ステップ714において識別された適用可能なポリシーを分析して、ポリシーにおける規則または特権はプリンシパルがYZDirに記憶されたFileXにアクセスすることを認可するかどうかを決定する。認可モジュール202が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可すると決定する場合には、ステップ720において、認可モジュール202は、プリンシパルが要求動作を実施することを認可されていることの表示である、許可決定を返して、最終ステップへと進む。一方、認可モジュール202が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと決定する場合には、ステップ716において、認可モジュール202は、プリンシパルが要求動作を実行することが認可されていないことの表示である拒否決定を返す。ステップ718において、認可モジュール202は、エラーストリングをプリンシパルに返して、最終ステップに進むことができる。エラーストリングは、要求動作を実行する認可がないことをプリンシパルに通知することができる。ここで、段階アクセスのチェックを、方法700によって示す順序と逆の順序で実行できることが認識されるであろう。例えば、認可モジュール202は、最初にそのアクセス制御のチェックを実行する。認可モジュール202が、特定の資源アクセスに対して認可を与えるべきであると決定すると、オペレーティングシステムが、その従来のアクセス制御機構を使用して、そのセキュリティチェックを実施する。図8は、いくつかの実施形態による、アプリケーションプログラムのセキュリティリスクのレベルをファシリティが決定する方法800を示すフロー図である。特に、ファシリティは、セキュリティリスクのレベルおよび/またはアプリケーションプログラムの意図の評価を、そのアプリケーションプログラムに専用のポリシーの分析に基づいて行う。一例として、ユーザはコンピュータにログオンして、アプリケーションをコンピュータ上にロードおよび/または実行することを要求している。開始ステップから始まり、ステップ802において、ユーザのコンピュータ上で実行されているオペレーティングシステムは、アプリケーションプログラムをロード/実行する要求を受信する。ステップ804において、オペレーティングシステムは、ファシリティを呼び出して、アプリケーションプログラムが対応するポリシーを有するかどうかを決定する。例えば、そのアプリケーションプログラムに適用可能なポリシーは、ポリシー206の一部として保持することができる。ファシリティが、そのアプリケーションプログラムに適用可能なポリシーは存在しないと決定する場合には、ファシリティは、適用可能なポリシーが存在しないことをオペレーティングシステムに通知する。ステップ806において、オペレーティングシステムは、アプリケーションプログラムをロード/実行することの要求を拒否し、エラー状態を返す。要求を拒否するのに続いて、オペレーティングシステムは、この要求に対する最終ステップへと進む。一方、ステップ804において、ファシリティが、そのアプリケーションプログラムに適用化なポリシーは存在すると決定する場合には、ステップ808において、ファシリティは、その適用可能なポリシーを分析して、そのアプリケーションプログラムをロード/実行することに関連する、またはそれから生ずる潜在的セキュリティリスクのレベルを決定する。ファシリティは、そのポリシーにおける規則によって与えられる認可のレベルまたは範囲に、リスクのレベルを基づかせることができる。例えば、規則がアプリケーションプログラムを多数の資源またはある数の本質的に危険な資源に対して認可する場合には、ファシリティは、規則がアプリケーションプログラムを小数の、比較的安全な資源に対してのみ認可する場合よりも、リスクのレベルを高く設定することができる。ファシリティは、適用可能なポリシーが存在することをオペレーティングシステムに通知して、最終ステップへと進む。図9は、いくつかの実施形態による、異常の検出時により制限的なポリシーをファシリティが課する方法900を示すフロー図である。一例として、コンピュータ上で実行中のファシリティは、2つのポリシー、ポリシーAおよびポリシーBを有することができ、これらはアプリケーションプログラムに適用可能である。さらに、ポリシーAは、ポリシーAがより多数の資源に認可を授与する点において、ポリシーBよりも制限が少ない。開始ステップから始まって、ステップ902において、ファシリティは制限の少ないポリシーAを課する。ステップ904において、ファシリティは、コンピュータ上で実行中のアプリケーションプログラムのインスタンスにおける異常状態を検出することができる。上記の例に続いて、アプリケーションプログラムのインスタンスがコンピュータ上で実行中であり、ファシリティは、実行中のアプリケーションプログラムプロセスを監視中である。アプリケーションプログラムプロセスの監視中に、ファシリティは、そのプロセスにおける異常条件または状態を検出することができる。例えば、ファシリティは、そのコンピュータ上で実行されたアプリケーションプログラムの先のインスタンスを追跡することによって、アプリケーションプログラムが通常出すシステムコールを表す有向グラフdirectedgraphを先に生成しておき、現行アプリケーションプログラムプロセスが行うシステムコールと有向グラフとの比較から異常状態の存在を決定することができる。ステップ906において、異常状態の検出に応答して、ファシリティは、より制限的なポリシーBを課して、最終ステップへと進む。一実施態様においては、ファシリティは、より制限的なポリシーBを、異常状態が検出されたアプリケーションプログラムプロセスに課する。代替的に、ファシリティは、より制限的なポリシーBを、アプリケーションプログラム、例えば、アプリケーションプログラムのすべてのインスタンスまたはプロセスに、課することができる。さらに、検出される異常、アプリケーションプログラム、および/または特定のポリシーに応じて、ファシリティは、コンピュータ全体により制限的なポリシーの組を課することが可能であり、例えば、より制限的なポリシーがコンピュータ上で実行中のすべてのプロセスに適用される。図10は、いくつかの実施形態による、異常の検出時にファシリティがポリシーを課する方法1000を示すフロー図である。一例として、コンピュータ上で実行中のファシリティは、ウエブアプリケーションプログラムに適用可能なポリシー、ポリシーAを有する。開始ステップで始まって、ステップ1002において、ファシリティは、ウエブアプリケーションプログラムにそのポリシーを課さない。したがって、ポリシーAは休眠しており、コンピュータ上で実行中のウエブアプリケーションプログラムのインスタンスに適用されない。ステップ1004において、ファシリティは、コンピュータ上で実行中のウエブアプリケーションプログラムのインスタンスにおける異常状態を検出することがある。上記の例に続いて、ウエブアプリケーションプログラムのインスタンスがコンピュータ上で実行されており、ファシリティは実行中のウエブアプリケーションプログラムプロセスを監視中である。アプリケーションプログラムプロセスを監視する間に、ファシリティは、プロセス中の異常条件または状態を検出することができる。例えば、ファシリティは、ウエブアプリケーションプロセスによって生成されるかまたはそれによって発生するネットワークトラフィックを監視して、そのネットワークトラフィックから、ウエブアプリケーションプロセス中に異常状態が存在することを決定することができる。ステップ1006において、ファシリティは、休眠ポリシー、ポリシーAをウエブアプリケーションプログラム、例えば異常の検出されたウエブアプリケーションプログラムプロセスに課して、最終ステップへと進む。別の選択肢として、ファシリティは、ポリシーAをウエブアプリケーションプログラムのすべてのインスタンスまたはプロセスに課すことができる。このようにして、休眠ポリシーは活動状態になり、ウエブアプリケーションプログラムに適用される。前述の内容から、本発明の特定の実施形態を説明の目的で記述したが、本発明の趣旨と範囲から逸脱することなく、様々な修正が可能であることが認識されるであろう。したがって、本発明は、添えられた特許請求の範囲による場合を除いて、限定されるものではない。