JP5069369B2 - 統合されたアクセス認可 - Google Patents

Description

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

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

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

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

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

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

コンピュータシステム上のアプリケーションプログラムおよびオペレーティングシステムの利用から発生する逆効果からコンピュータシステムを保護するソフトウエアファシリティ（「ファシリティ（ｆａｃｉｌｉｔｙ）」）について述べる。いくつかの実施形態において、ファシリティは、オペレーティングシステムの不可欠の部分として実現され、およびオペレーティングシステムに論理駆動のアクセス制御レイヤ（ｌｏｇｉｃ−ｄｒｉｖｅｎ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌａｙｅｒ）を追加する。例えば、ファシリティは、オペレーティングシステムのアクセス制御機構に不可欠の方法として実現される。

ファシリティは、セキュリティに敏感な（ｓｅｃｕｒｉｔｙ−ｓｅｎｓｉｔｉｖｅ）種々の資源アクセスに関する認可の問い合わせを受け取って、集中されたポリシーに基づいて資源アクセスを許可または拒否する決定を返す。ポリシーは、一例としてネットワーク、ファイルシステム、アプリケーションプログラムなどの資源を管理し、かつ保護する方法を決定する１組の規則および慣行である。集中されたポリシーの記憶装置において、ポリシーの規則は集中的に配置されており、規則および／またはポリシーを集中的に呼び出し、かつ集中的に設定することが可能となる。これは、分散型またはオブジェクト単位（ｐｅｒ−ｏｂｊｅｃｔ）のアクセス制御モデルとは対照的に、通常、物理オブジェクトに結び付けられたアクセス制御リストを使用して実現される。

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

実施形態において、ファシリティは監査機能を提供する。例えば、ポリシーは、認可が許可（例えば、授与）されるか、または拒否（例えば、阻止）されるかにかかわらず、特定の動作を監査の対象として指示することによって、エントリが監査ログに加えられるようにすることができる。このエントリには、不適合規則（ｆａｉｌｅｄ ｒｕｌｅ）、資源またはオブジェクト、およびプリンシパルの表示を含めることができる。本質的に危険な操作などの、ある特定の操作に対しては、そのエントリには、規則、その規則が許可されたか拒否されたか、資源またはオブジェクト、およびプリンシパルの表示を含めることができる。ファシリティは、さらに、監査に基づいてイベント（ｅｖｅｎｔ）を始動することができる。例えば、ファシリティは、プリンシパル（例えば、アプリケーションプログラムおよび／またはユーザ）またはその他の当事者に、不適合規則または本質的に危険な操作の通知または表示を提供することができる。

実施形態において、ファシリティは、ファシリティが規則を適用する代わりに、規則を試験するか、または規則を報告する学習モード機能を提供する。例えば、ポリシーの規則は、動作を実行する認可要求を拒否することを指定することができる。学習モードが、例えば、ポリシーの著者によって、規則に対して起動される場合には、ファシリティは、動作を実行する認可の要求を拒否する代わりに、動作を実行する認可を許可または授与するとともに、イベントを生成して、動作を実行する認可要求は拒否されたであろうことを指示する。ファシリティは、例えば、阻止されるであろう規則、動作を要求する前のアプリケーションプログラムの状態などを示す報告を生成することができる。学習モード機能は、ポリシーの微調整を容易にする。例えば、ポリシーの著者は、報告を分析して、ポリシー内の規則の制限をより多くするかまたは少なくする必要があるかどうかの決定を行うことができる。

実施形態において、ファシリティは、段階アクセス（ｔｉｅｒｅｄ ａｃｃｅｓｓ）制御のチェックの一部として実行される。ここで、ファシリティは、一連のアクセス制御のチェックの一部として、ポリシーチェックを実行する。例えば、資源要求が行われると、最初に従来型アクセス制御機構が呼び出されて、要求された資源に対する認可があるかどうかが決定される。従来型アクセス制御機構が要求された資源に対する認可があるとの最初の決定に続いて、ファシリティが呼び出されて、そのポリシーをチェックして、要求された資源に対する認可があるかどうかを決定することができる。続いて、１つまたは複数のさらなるアクセス制御チェックを追加で呼び出して、要求された資源に対する認可があるかどうかを最終的に決定することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (3)

1. コンピュータ実行可能命令を備えたコンピュータ読み取り可能な記憶媒体であって、前記コンピュータ実行可能命令は、
   ユーザコンピュータが、アプリケーションプログラムをメモリにロードする要求を受け取るステップと、
   ユーザコンピュータが、ポリシー記憶装置に前記アプリケーションプログラムに適用できるポリシーがあるかどうか判定するステップであって、前記ポリシーは、前記アプリケーションプログラムの資源へのアクセスの認可要求を許可するか否かを決定する、ステップと、
   ユーザコンピュータが、前記アプリケーションプログラムに適用できるポリシーがないと判断した場合、アプリケーションプログラムをロードする要求を拒否するステップと、
   ユーザコンピュータが、前記アプリケーションプログラムに適用できるポリシーがあると判断した場合、前記アプリケーションプログラムが予め定められた資源にアクセスすることを伴うかどうかを判定するステップであって、前記アプリケーションプログラムが前記予め定められた資源へのアクセスを伴うかどうかを判定することは、前記アプリケーションプログラムに適用可能なポリシーを分析して、前記あらかじめ定められた資源の数および危険度に応じて、アプリケーションプログラムをロードおよび／または実行することに関連するセキュリティリスクを設定することに基づく、ステップと、
   ユーザコンピュータが、前記アプリケーションプログラムが前記予め定められた資源へのアクセスを伴うと判定するのに応答して、前記アプリケーションプログラムをロードする要求を拒否するステップと
   をコンピュータのオペレーティングシステムに実行させることを特徴とするコンピュータ読取可能な記憶媒体。
2. アプリケーションプログラムのセキュリティリスクを決定するコンピューティングシステムにおける方法であって、
   ポリシー記憶装置にアプリケーションプログラムに適用可能なポリシーが存在するかどうかを、前記コンピューティングシステムのオペレーティングシステムが判定するステップであって、前記ポリシーは、前記アプリケーションプログラムの資源へのアクセスの認可要求を許可するか否かを決定する規則である、ステップと、
   前記オペレーティングシステムが、ポリシー記憶装置に前記アプリケーションプログラムに適用可能なポリシーが存在すると判定することに応答して、前記適用可能なポリシーを分析して、前記分析により前記あらかじめ定められた資源の数および危険度に応じて前記アプリケーションプログラムをロードおよび／又は実行する際に存在する潜在的セキュリティリスクのレベルを設定し、前記アプリケーションプログラムをロードおよび／又は実行するステップと、
   前記オペレーティングシステムが、ポリシー記憶装置に前記アプリケーションプログラムに適用可能なポリシーが存在しないと判定することに応答して、前記アプリケーションプログラムをロードおよび／又は実行しないステップと
   を備えたことを特徴とする方法。
3. アプリケーションプログラムを処理するコンピューティングシステムにおける方法であって、
   前記コンピューティングシステムのオペレーティングシステムがポリシー記憶装置に前記コンピューティングシステムにおいて処理されるアプリケーションプログラムに適用可能なポリシーが存在するかどうかを決定するステップであって、前記ポリシーは、前記アプリケーションプログラムの資源へのアクセスの認可要求を許可するか否かを決定する規則である、ステップと、
   前記オペレーティングシステムが前記アプリケーションプログラムに適用可能なポリシーが存在すると判定するのに応じて、前記適用可能なポリシーを分析して、前記アプリケーションプログラムが予め定められた資源にアクセスすることを伴うかを判定するステップであって、前記アプリケーションプログラムが前記予め定められた資源へのアクセスを伴うかどうかを判定することは、前記アプリケーションプログラムに適用可能なポリシーを分析して、前記あらかじめ定められた資源の数および危険度に応じて、アプリケーションプログラムをロードおよび／または実行することに関連するセキュリティリスクを設定することに基づく、ステップと、
   前記判定に基づいて、前記オペレーティングシステムが前記アプリケーションプログラムをロードおよび／又は実行するかどうかを決定するステップと
   を備えたことを特徴とする方法。

Images