統合されたアクセス認可
【課題】アクセス制御のチェックを実行するファシリティを提供すること。
【解決手段】ファシリティは、コンピュータ上で実行されているオペレーティングシステムの不可欠な部分として実行され、およびプリンシパルが資源にアクセスする認可を有するかどうかを決定する認可の問い合わせを受け取る。ファシリティは、集中されたポリシーの記憶装置に保持され、プリンシパルに適用可能なポリシーを適用して、資源にアクセスする認可が存在するかどうかを決定する。ファシリティは、認可の問い合わせの監査に基づいてイベントを始動することができ、資源にアクセスする認可の表示を監査ログに記録することもできる。ファシリティは、認可の問い合わせが本質的に危険な操作を実行する認可の要求であるかどうかを決定し、本質的に危険な操作を実行する認可の表示を監査ログに記録することができる。
【解決手段】ファシリティは、コンピュータ上で実行されているオペレーティングシステムの不可欠な部分として実行され、およびプリンシパルが資源にアクセスする認可を有するかどうかを決定する認可の問い合わせを受け取る。ファシリティは、集中されたポリシーの記憶装置に保持され、プリンシパルに適用可能なポリシーを適用して、資源にアクセスする認可が存在するかどうかを決定する。ファシリティは、認可の問い合わせの監査に基づいてイベントを始動することができ、資源にアクセスする認可の表示を監査ログに記録することもできる。ファシリティは、認可の問い合わせが本質的に危険な操作を実行する認可の要求であるかどうかを決定し、本質的に危険な操作を実行する認可の表示を監査ログに記録することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般には、コンピュータセキュリティに関し、より詳細には、コンピュータシステム上の資源（ｒｅｓｏｕｒｃｅ）へのアクセスを制御することに関する。
【背景技術】
【０００２】
コンピュータおよびコンピュータネットワークに対する攻撃の高度の複雑化および頻発とともに、コンピュータおよびコンピュータネットワークへの依存が増大するにつれて、コンピュータセキュリティの問題は、産業界において益々顕著になっている。現状のコンピュータセキュリティ技術は、コンピュータシステムに特に損傷を与えまたは中断させるように設計された、悪性ソフトウエア（「マルウエア（ｍａｌｗａｒｅ）」、例えば、ウイルス、ワーム、およびトロイの木馬などから、および他の望ましくない活動から、アプリケーションプログラムおよびオペレーティングシステムを保護するのには不十分である。
【０００３】
既存のアクセス制御のセキュリティモデルは、通常、コンピュータ上の資源へのアクセスを認可するユーザの資格証明（ｃｒｅｄｅｎｔｉａｌｓ）に頼っている。これらのモデルにおいては、ユーザに対して利用可能なすべての資源にプロセスがアクセスする必要があるかどうかにかかわらず、同一の資格証明で遂行または実行されるすべてのプロセスに、同一のアクセス権が与えられる。また、資源へのアクセス、例えば、読取り、書込みなどを必要とするプロセスは、資源にアクセスするときに、必要なアクセスを指定する。
【０００４】
例えば、ユーザは、ユーザアカウントでパーソナルコンピュータにログオンして、結果としてパーソナルコンピュータに記憶され、および特定のワードプロセシングプログラムを使用して作成された、すべてのワードプロセシング文書にアクセスできることを期待する。この期待を満足させるために、従来のアクセス制御セキュリティシステムは、ユーザの文脈で実行されているすべてのプログラムに、ワードプロセシング文書のすべてにアクセスする許可を与える。しかしながら、これは、過剰なレベルの許可であり、なぜならば、ワードプロセシングプログラム以外のユーザの文脈において実行されているほとんどのプログラムは、実際にはワードプロセシング文書のいずれにもアクセスする必要がないからである。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
通常、マルウエアは、コード欠陥を利用することによってプロセスに感染する。危うくされたプロセスの内部でマルウエアが実行されると、プロセスが実行されているユーザのコンテキストのアクセス権を引き継ぎ、ユーザに対して利用可能なすべての資源に対するアクセスを得るが、それは元のプロセスがかつて必要としたものよりはるかに大きくなる可能性がある。
【０００６】
したがって、コンピュータ上の資源のセキュリティを改善しかつ増強するアクセス認可（ａｃｃｅｓｓ ａｕｔｈｏｒｉｚａｔｉｏｎ）に対する統合アプローチは、有用性が高いといえる。
【課題を解決するための手段】
【０００７】
コンピュータシステム上のアプリケーションプログラムおよびオペレーティングシステムの利用から発生する逆効果からコンピュータシステムを保護するソフトウエアファシリティ（「ファシリティ（ｆａｃｉｌｉｔｙ）」）について述べる。いくつかの実施形態において、ファシリティは、オペレーティングシステムの不可欠の部分として実現され、およびオペレーティングシステムに論理駆動のアクセス制御レイヤ（ｌｏｇｉｃ−ｄｒｉｖｅｎ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌａｙｅｒ）を追加する。例えば、ファシリティは、オペレーティングシステムのアクセス制御機構に不可欠の方法として実現される。
【０００８】
ファシリティは、セキュリティに敏感な（ｓｅｃｕｒｉｔｙ−ｓｅｎｓｉｔｉｖｅ）種々の資源アクセスに関する認可の問い合わせを受け取って、集中されたポリシーに基づいて資源アクセスを許可または拒否する決定を返す。ポリシーは、一例としてネットワーク、ファイルシステム、アプリケーションプログラムなどの資源を管理し、かつ保護する方法を決定する１組の規則および慣行である。集中されたポリシーの記憶装置において、ポリシーの規則は集中的に配置されており、規則および／またはポリシーを集中的に呼び出し、かつ集中的に設定することが可能となる。これは、分散型またはオブジェクト単位（ｐｅｒ−ｏｂｊｅｃｔ）のアクセス制御モデルとは対照的に、通常、物理オブジェクトに結び付けられたアクセス制御リストを使用して実現される。
【０００９】
認可モジュールは、ユーザモードプログラム、例えばユーザ文脈で実行中のアプリケーションプログラムなど、が発行する資源へのアクセス要求に応ずる、様々なオペレーティングシステム構成要素が直接的に問い合わせをすることができる。代替的には、認可モジュールは、そのようなオペレーティングシステム構成要素の上部に位置する「インターセプションレイヤ（ｉｎｔｅｒｃｅｐｔｉｏｎ ｌａｙｅｒ）」によって問い合わせをすることができる。インターセプションレイヤは、リソースにアクセスするためにユーザモードプログラムが使用するシステムコールファンクションを中断し、中断されたシステムコールファンクションに「ラッパー（ｗｒａｐｐｅｒ）」を適用するコードである。認可モジュールは、そのアクセス制御決定（すなわち、許可または拒否）を、資源アクセスを試みているアプリケーションプログラム、例えばアプリケーションプロセスの識別（ｉｄｅｎｔｉｔｙ）またはアプリケーションプログラムの識別とアプリケーションが実行されているユーザの識別との組合せのいずれかであり、およびプリンシパルに適用されるポリシーである、プリンシパルの識別に基づいて行う。
【００１０】
実施形態において、ファシリティは監査機能を提供する。例えば、ポリシーは、認可が許可（例えば、授与）されるか、または拒否（例えば、阻止）されるかにかかわらず、特定の動作を監査の対象として指示することによって、エントリが監査ログに加えられるようにすることができる。このエントリには、不適合規則（ｆａｉｌｅｄ ｒｕｌｅ）、資源またはオブジェクト、およびプリンシパルの表示を含めることができる。本質的に危険な操作などの、ある特定の操作に対しては、そのエントリには、規則、その規則が許可されたか拒否されたか、資源またはオブジェクト、およびプリンシパルの表示を含めることができる。ファシリティは、さらに、監査に基づいてイベント（ｅｖｅｎｔ）を始動することができる。例えば、ファシリティは、プリンシパル（例えば、アプリケーションプログラムおよび／またはユーザ）またはその他の当事者に、不適合規則または本質的に危険な操作の通知または表示を提供することができる。
【００１１】
実施形態において、ファシリティは、ファシリティが規則を適用する代わりに、規則を試験するか、または規則を報告する学習モード機能を提供する。例えば、ポリシーの規則は、動作を実行する認可要求を拒否することを指定することができる。学習モードが、例えば、ポリシーの著者によって、規則に対して起動される場合には、ファシリティは、動作を実行する認可の要求を拒否する代わりに、動作を実行する認可を許可または授与するとともに、イベントを生成して、動作を実行する認可要求は拒否されたであろうことを指示する。ファシリティは、例えば、阻止されるであろう規則、動作を要求する前のアプリケーションプログラムの状態などを示す報告を生成することができる。学習モード機能は、ポリシーの微調整を容易にする。例えば、ポリシーの著者は、報告を分析して、ポリシー内の規則の制限をより多くするかまたは少なくする必要があるかどうかの決定を行うことができる。
【００１２】
実施形態において、ファシリティは、段階アクセス（ｔｉｅｒｅｄ ａｃｃｅｓｓ）制御のチェックの一部として実行される。ここで、ファシリティは、一連のアクセス制御のチェックの一部として、ポリシーチェックを実行する。例えば、資源要求が行われると、最初に従来型アクセス制御機構が呼び出されて、要求された資源に対する認可があるかどうかが決定される。従来型アクセス制御機構が要求された資源に対する認可があるとの最初の決定に続いて、ファシリティが呼び出されて、そのポリシーをチェックして、要求された資源に対する認可があるかどうかを決定することができる。続いて、１つまたは複数のさらなるアクセス制御チェックを追加で呼び出して、要求された資源に対する認可があるかどうかを最終的に決定することができる。
【図面の簡単な説明】
【００１３】
【図１】ファシリティが実行される、少なくとも一部のコンピュータシステムに通常組み込まれる、選ばれた構成要素を例示するブロック図である。
【図２】いくつかの実施形態による、ファシリティの選ばれた構成要素を例示するブロック図である。
【図３】いくつかの実施形態による、ファシリティが使用するのに適当な事例のポリシーを例示する図である。
【図４】いくつかの実施形態による、拒否されたアクセス要求の監査をファシリティが実行する方法を例示するフローチャートである。
【図５】いくつかの実施形態による、本質的に危険な動作の監査をファシリティが実行する方法を例示するフローチャートである。
【図６】いくつかの実施形態による、ポリシーの微調整を容易にする学習をファシリティが実行する方法を例示するフローチャートである。
【図７】いくつかの実施形態による、段階アクセス制御のチェックをファシリティが提供する方法を例示するフローチャートである。
【図８】いくつかの実施形態による、アプリケーションプログラムのセキュリティリスクのレベルをファシリティが決定する方法を例示するフローチャートである。
【図９】いくつかの実施形態による、異常検出時により制限的なポリシーをファシリティが課する方法を例示するフローチャートである。
【図１０】いくつかの実施形態による、異常検出時にポリシーをファシリティが課する方法を例示するフローチャートである。
【発明を実施するための形態】
【００１４】
ファシリティの様々な実施形態およびその利点は、図面の図１〜１７を参照することによって最もよく理解できる。図面の要素は、必ずしも比例して拡大縮小せず、代わりに本発明の原理を明確に説明することに重点をおいている。図面全体を通して、様々な図面の同一部品および対応部品には、同一番号を使用している。
【００１５】
図１は、ファシリティが実行される、少なくとも一部のコンピュータシステムに通常、組み込まれている、選択された構成要素を例示するブロック図である。これらのコンピュータシステム１００には、コンピュータプログラムを実行するための１つまたは複数の中央処理ユニット（ＣＰＵ）１０２；プログラムおよびデータ―データ構造を含む―をそれらが使用されている間に記憶するためのコンピュータメモリ１０４；プログラムおよびデータを永続的に記憶するハードドライブなどの永続的な記憶装置１０６；コンピュータ読取可能な媒体に記憶されたプログラムおよびデータを読み取るためのＣＤ−ＲＯＭドライブなどのコンピュータ読取可能な媒体の駆動装置１０８；およびプログラムおよび／またはデータ―データ構造を含む―を交換するために、インターネットを介するなどして、コンピュータシステムを他のコンピュータシステムに接続する、ネットワーク接続１１０を含めることができる。
【００１６】
ファシリティは、コンピュータシステム１００またはその他のデバイスによって実行されるプログラムモジュールのような、コンピュータ読取可能な命令の一般的文脈において説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか、または特定の抽象データタイプを実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造などが含まれる。メモリ１０４および永続的な記憶装置１０６は、ファシリティを実現する命令を収容することができるコンピュータ読取可能な媒体である。ここで、メモリ１０４および永続的な記憶装置１０６は、ファシリティを実現する命令に加えて、様々なその他の内容を含むことがあることが認識されるであろう。
【００１７】
ここで、コンピュータシステム１００には、ビデオモニタまたはＬＣＤパネルなどの、プログラム出力を指示する１つまたは複数の表示デバイス、およびキーボード、マイクロフォン、またはマウスなどのポインティングデバイスなどの、ユーザ入力を受信する１つまたは複数の入力デバイスを含めることができることが認識されるであろう。通常、上述のように構成されたコンピュータシステム１００がファシリティの動作をサポートするのに使用されるが、ファシリティは、様々なタイプおよび構成にするとともに、様々な構成要素を有するデバイスを使用して実現することができることが認識されるであろう。
【００１８】
図２は、いくつかの実施形態による、ファシリティの選ばれた構成要素を示すブロック図である。図２に示すように、ファシリティは認可モジュール２０２を含み、このモジュールは、コンピュータシステム１００上で実行するのに適したオペレーティングシステム２０４の一体化構成要素として実現される。認可モジュール２０２は、一般に、ネットワークフェーシングアプリケーション、ネットワークフェーシングサービスおよびオペレーティングシステム構成要素などの高リスクプロセス、信用できない内容を取り扱うアプリケーション、ならびに信用できないコード、例えば、通常、インターネットによって配信されるコードなどに対する、追加の保護レイヤ（ｐｒｏｔｅｃｔｉｏｎ ｌａｙｅｒ）として機能する。認可モジュール２０２は、コンピュータシステム１００上で利用可能な資源のポリシー駆動アクセス制御を実行するための論理を提供する。
【００１９】
ファシリティは、また、認可モジュール２０２がそのアクセス制御決定をそれから行うポリシー２０６を含む。ポリシー２０６は、資源へのアクセスの認可要求を許可するか、または拒否するかを決定する規則である。いくつかの実施形態においては、ポリシー２０６は、オペレーティングシステム２０４および、特に、認可モジュール２０２によって施行される実行時規則、例えばバイナリ規則にコンパイルされる。いくつかの実施形態においては、ポリシー２０６は、集中ポリシー記憶装置（ｃｅｎｔｒａｌｉｚｅｄ ｐｏｌｉｃｙ ｓｔｏｒｅ）の一部として実現されて、この集中ポリシー記憶装置は、例えばユーザおよび／または管理者が、ポリシー２０６内の規則を含みポリシー２０６を、中央から取り消したり、中央から設定したりすることを可能にする。
【００２０】
認可モジュール２０２は、様々なオペレーティングシステムカーネル構成要素２０８が問い合わせをすることが可能であり、これらのカーネル構成要素は、プリンシパル、例えばプリンシパル２１２ａが出す資源へのアクセス要求に答える。また、認可モジュール２０２の問い合わせは、資源にアクセスするためにプリンシパル、例えばプリンシパル２１２ｂが出すシステムコールファンクションを中断する、インターセプションレイヤ２１０が行うこともできる。インターセプションレイヤ２１０は、中断されたシステムコールファンクションにラッパー（ｗｒａｐｐｅｒ）を適用して、認可モジュール２０２が適用可能なポリシー２０６に対するアクセス制御のチェックを実行することを可能にする。例えば、ラッパーを適用することには、プリンシパルおよび／またはコンピューティングシステム１００に関連する様々な環境要因の識別を決定すること、およびこの情報を認可要求の一部として供給して、認可モジュール２０２へのシステムコールを実行してそれがアクセス制御のチェックを実行することを可能にすることが含まれる。さらに、認可モジュール２０２は、プリンシパル、例えばプリンシパル２１２ｃが直接的に問い合わせをすることもできる。
【００２１】
実施形態によっては、認可モジュール２０２が実行するアクセス制御のチェックは、資源へのアクセス要求を行っているプリンシパルおよびそのプリンシパルに適用するポリシーの関数である。すなわち、認可モジュール２０２は、そのアクセス制御決定（すなわち、許可または拒否）を、プリンシパルの識別―コールしているアプリケーションプログラムの識別、またはコールしているアプリケーションプログラムの識別とそのためにそのアプリケーションプログラムが実行されているユーザの識別との組合せ―およびプリンシパルに適用可能なポリシーにおける規則に基づいて行う。実施形態によっては、認可モジュール２０２は、プリンシパルの識別および、そのアクセス制御決定を行う際のプリンシパルに適用可能なポリシーにおける規則の識別に加えて、一例として、要求アクセスのタイプ、環境因子―例えば、アプリケーションプログラムが実行されている、企業ネットワーク内部または公共ネットワークに接続されたコンピュータ、コンピュータのパッチレベル、その他―などのパラメータをさらに考慮することができる。
【００２２】
実施形態によっては、ファシリティには、図２に破線または「断続線」によって示されている、任意選択の異常検出（ａｎｏｍａｌｙ ｄｅｔｅｃｔｉｏｎ）モジュール２１４を含めることができる。異常検出モジュール２１４は、異常状態を検出するために、全体的には、コンピュータシステム１００の挙動およびコンピュータシステム１００で実行されているプログラムを監視する機能を果たす。実施形態によっては、異常検出モジュール２１４は、異常の検出時に第１の通知を、先に検出された異常の停止検出時に、後続の第２の通知を、ファシリティに提供する。これによって、ファシリティは、異常検出時に、異常が終了するまでポリシー２０６の施行を起動することが可能となり、それ以後は、ポリシー２０６はもう施行されない。代替的に、ファシリティは、異常が検出されるまでより制限の少ないポリシーの組を最初に課してもよく、この場合には、異常が終了して再び制限の少ないポリシーの組が再び施行されるまで、より制限的なポリシーの組が施行される。異常検出モジュール２１４は、コンピュータシステム１００上で実行される単一プロセス、コンピュータシステム１００上で実行されるプロセス群、またはコンピュータシステム１００全体のいずれかにおいて異常を検出することができる。
【００２３】
上述のファシリティの態様は、説明のためだけのものであり、図示した構成要素の実現および／またはファシリティの使用もしくは機能性の範囲に関する限定を意味するものではない。例えば、いくつかの実施形態によっては、認可モジュール２０２は、オペレーティングシステム２０４の一部として、またはそれに一体化して実現する必要はなく、オペレーティングシステム２０４と分離して、またはその外部に、例えば非オペレーティングシステムプログラムとして実現することができる。さらに、いくつかの実施形態においては、ポリシー２０６は集中ポリシー記憶装置として、またはその一部として実現する必要はない。したがって、ポリシー２０６は、１つの場所にある必要はなく、例えば、分散モデルを使用して実現することができる。さらに、ポリシー２０６は、認可モジュール２０２の一部として、またはそれに収容されるものとして記述してあるが、ポリシー２０６は、認可モジュール２０２によってアクセス可能ありさえすれば十分である。
【００２４】
以下の考察においては、ファシリティの実施形態は、様々な実証例と一緒に記述する。ここで、ファシリティの実施形態は、様々な観点でこれらの例から大きく外れる環境において使用できることが認識されるであろう。
【００２５】
図３は、いくつかの実施形態による、ファシリティによる使用に適当な例示ポリシーを示す。例示ポリシーには、ウエブサーバアプリケーションを保護する規則が含まれる。一例として、アイテム３０２と表示されている、資源を要求するアプリケーションプロセスがチェックされて、それがアイテム３０４と表示されている、ＷｅｂＳｅｒｖｅｒＸウエブサーバプロセスであるかどうかが決定される。認可モジュール２０２が、要求元アプリケーションプロセスはＷｅｂＳｅｒｖｅｒＸウエブサーバプロセスであると決定する場合には、認可モジュール２０２は、ポリシー内に含まれる規則に基づいて、要求された資源に対する認可を許可または拒否する。
【００２６】
図示するように、例示ポリシーはＷｅｂＳｅｒｖｅｒＸプロセスに与えられる特権またはアクセス権限を包含しており、そのデフォルトは、規則３０６に示すように、その特権またはアクセス権限が指定されない限り、要求された資源に対する認可を拒否することである。言い換えると、要求された資源がポリシーにおいて明示的に与えられていない限り、要求された資源に対する認可は拒否される。実施形態によっては、ポリシーは、アクセス制限を指定する規則、例えば特定の動作を実行する認可を拒否すべきことを指定する規則、または資源へのアクセスの認可を拒否する規則、あるいは監査を行わせる、例えばイベントをログ記録させる規則を包含することができる。
【００２７】
例示ポリシーにおける第１の規則は、ＷｅｂＳｅｒｖｅｒＸプロセスが、アイテム３０８で示す、「＄ｈｔｍｌ」ファイルを、アイテム３１０で示す、「＄Ｗｅｂディレクトリ」に書き込むことを許可する命令である。「＄ｈｔｍｌ」は、例えば*．ｈｔｍｌ、*．ｇｉｆ、その他のファイル種類の集合の表現である。「＄Ｗｅｂディレクトリ」は、ウエブディレクトリとして構成されたディレクトリの集合の表現であり、セキュリティ管理者などのポリシーの製作者とは異なる、ウエブ管理者などの管理者による定義が可能である。例えば、認可モジュール２０２は、この規則に基づいて、パラメータ「＄ｈｔｍｌ」で定義される種類のファイルを、パラメータ「＄Ｗｅｂディレクトリ」で定義される種類のディレクトリの１つに書き込む要求をしているＷｅｂＳｅｒｖｅｒＸプロセスに応答して、許可決定（すなわち、認可の授与）を返す。したがって、ポリシー内の規則を、「＄Ｗｅｂディレクトリ」のような動的かつ独立に定義されたオブジェクト群、および「＄ｈｔｍｌ」のような動的で構成可能な環境パラメータに適用することができる。
【００２８】
例示ポリシーにおける第２の規則は、それがアイテム３１４で示す「ユーザＡ」のために実行されている場合には、ＷｅｂＳｅｒｖｅｒＸプロセスが、アイテム３１２で示す、「＄ＦＴＰアップロードディレクトリ」に書込みをすることを許可する命令である。例えば、認可モジュール２０２は、この規則に基づいて、「＄ＦＴＰアップロードディレクトリ」への書込み要求をしているユーザＡのために実行されているＷｅｂＳｅｒｖｅｒＸプロセスに応答して、許可決定（すなわち、認可の授与）を返す。
【００２９】
例示ポリシーにおける第３の規則は、アイテム３１６で示す、内向きｈｔｔｐトラフィックを許可する命令である。例えば、認可モジュール２０２は、この規則に基づいて、内向きｈｔｔｐデータを受信すること、例えばネットワーク接続上を伝送される、ｈｔｔｐデータパケットを受信することを要求しているＷｅｂＳｅｒｖｅｒＸプロセスに応答して、許可決定（すなわち、認可の授与）を返す。
【００３０】
例示ポリシーにおける第４の規則は、アイテム３２０で示す、可変「＄ＦＴＰ」が使用可能である場合に、アイテム３１８で示す「ＦＴＰトラフィック」を許可する命令である。ここで、「＄ＦＴＰ」は変数であり、ポリシーを作成したセキュリティ管理者とは異なる管理者が設定することができる。例えば、認可モジュール２０２は、実行時のチェックを実行して、変数「＄ＦＴＰ」が使用可能であるかどうかを決定し、そうであれば、この規則に基づいて、パラメータ「ＦＴＰトラフィック」によって定義されるデータを送信または受信することを要求するＷｅｂＳｅｒｖｅｒＸプロセスに応答して、許可決定（すなわち、認可の授与）を返す。一方、「＄ＦＴＰ」が使用可能でない場合には、前述のアクセス要求に応答して、認可モジュール２０２はアイテム３０６で示す拒否決定（すなわち、認可の拒否）を返す。
【００３１】
ポリシーには、上記の例示特権で示したアプリケーションプロセスなどの、オペレーティングシステム内部および外部のオブジェクトに対する特権を定義する、規則を含めることができるが認識されるであろう。ポリシー内の規則は、コンパイル式またはインタープリタ式コンピュータ言語を使用する書込みコードと同様の、リッチスキーマ（ｒｉｃｈ ｓｃｈｅｍａ）を使用して指定することができる。例えば、このスキーマは、条件および一時的条件、例えば「Ｙであるときだけ、Ｘを許可する」など、動的に構成可能な環境パラメータおよび変数への依存性、環境因子への依存性、その他を規則に含めることをサポートすることができる。さらに、パラメータの使用によって、現在および将来のオブジェクトに適用する規則の作成が容易になる。例えば、特定の種類の文書を、パラメータで表現することが可能であり、そのパラメータを使用して、現在存在するものであれ、将来作成されるものであれ、その特定の種類のすべての文書に適用する制限を指定する規則を作成することができる。実施形態によっては、ポリシーが指定することによって、ある決定は、例えばポップアップダイアログボックスによって、エンドユーザに決定を委ねられるようにすることができる。
【００３２】
図４は、いくつかの実施形態による、拒否されたアクセス要求の監査をファシリティが実施する方法４００のフローチャートを示している。一例として、あるユーザ（例えば、ユーザＡＢＣ）が、コンピュータにログオンして、ワードプロセシングアプリケーション（例えば、ＷＰＡｐｐ）を開始しており、コンピュータ上のディレクトリ（例えば、ＹＺＤｉｒ）に記憶されているファイル（例えば、ＦｉｌｅＸ）を開くことを要求している。その結果として、ＷＰＡｐｐは、ディレクトリＹＺＤｉｒに記憶された資源ＦｉｌｅＸへのアクセス要求を出す。開始ステップから始まり、認可モジュール２０２は、ステップ４０２において、認可問い合わせ、例えばＹＺＤｉｒに記憶されたＦｉｌｅＸへのアクセスの認可要求を受信する。
【００３３】
ステップ４０４において、認可モジュール２０２は、ＹＺＤｉｒに記憶されたＦｉｌｅＸへのアクセスの認可要求しているプリンシパルを識別する。上記の例においては、プリンシパルは、ＷＰＡｐｐであるか、またはＷＰＡｐｐとユーザＡＢＣの組合せのいずれかとすることができる。ステップ４０６において、認可モジュール２０２は、識別されたプリンシパルに適用可能なポリシーを、例えば、ポリシー２０６などの集中ポリシー記憶装置から識別するとともに、プリンシパルの識別と適用可能なポリシーに基づいてアクセス制御のチェックを実施する。ステップ４０８において、認可モジュール２０２は、ステップ４０６において実施されたアクセス制御のチェックの結果が、アクセスを拒否するものであるかどうかを決定する。上記の例に続いて、ステップ４０８において、認可モジュール２０２は、識別された適用可能なポリシーを分析して、ポリシーにおける規則または特権が、そのプリンシパルがＹＺＤｉｒに記憶されたＦｉｌｅＸにアクセスすることを認可するかどうかを決定する。
【００３４】
認可モジュール２０２が、適用可能なポリシーがプリンシパルに要求動作を実行することを認可すると決定する場合には、ステップ４２０において、認可モジュール２０２は、プリンシパルが要求動作を実行することが認可されたことの表示である、許可決定を返して、最終ステップへと進む。一方、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと認可モジュール２０２が決定する場合には、ステップ４１０において、認可モジュール２０２は拒否決定を返し、これはプリンシパルが要求動作を実行することが認可されないことの表示である。ステップ４１２において、認可モジュール２０２は、プリンシパルにエラーストリングを返し、要求動作を実行する認可がないことをプリンシパルに通知することができる。
【００３５】
ステップ４１４において、認可モジュール２０２は、監査が使用可能かどうかを決定するチェックを行う。適用可能なポリシーまたは規則に関連するフラグまたはレコードによって、監査を実施すべきかどうかを指示することができる。監査が使用可能でない場合には、認可モジュール２０２は、最終ステップへと進む。一方、監査が使用可能である場合には、認可モジュール２０２は、ステップ４１６において、監査ログにエントリを作成する。エントリは、拒否された要求、無効な規則、プリンシパル、および／または要求された資源を識別することができる。
【００３６】
ステップ４１８において、認可モジュール２０２は、拒否要求の監査に基づいて１つまたは複数のイベントを始動することができる。例えば、認可モジュール２０２は、例えば電子メール、音声メール、テキストメッセージングなどを介して、セキュリティ管理者に、非認可動作を実行すること、プリンシパルによる非認可動作の実行の試みに続いてアプリケーションプロセスを終了すること、プリンシパルによる非認可動作の実行の試みに続いてより厳格なポリシーの組を課すること、その他の、プリンシパルによる試みの表示を提供することができる。それらのイベントを始動することに続いて、認可モジュール２０２は、最終ステップへと進む。
【００３７】
当業者であれば、本明細書において開示した、これらおよびその他のプロセスならびに方法に対して、プロセスおよび方法において実行される機能は、異なる順序で実現できることを認識するであろう。さらに、概説したステップは、例示的なものにすぎず、本発明の本質から外れることなく、いくつかのステップを任意選択とすること、より少ないステップと組み合わせること、または追加のステップに拡張することができる。
【００３８】
図５は、いくつかの実施形態による、本質的に危険な操作の監査をファシリティが実行する方法５００のフロー図を示す。一例として、ユーザ（例えば、ユーザＡＢＣ）はコンピュータにログオンして、ウエブブラウザプログラム（例えば、ＷｅｂＢｒｏｗｓｅｒ）を開始して、信用のできないウエブサイト（例えば、ＷｅｂＳｉｔｅＹ）上のウエブページ（例えば、ＰａｇｅＸ）へのアクセス要求をしている。結果として、ＷｅｂＢｒｏｗｓｅｒは、ＷｅｂＳｉｔｅＹからＰａｇｅＸを検索する要求を出す。ステップ５０２〜５０８は、実質的に方法４００のステップ４０２〜４０８と同様である。
【００３９】
ステップ５０８において、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと決定する場合には、ステップ５１０において、認可モジュール２０２は拒否決定を返し、これはプリンシパルが要求動作の実行を認可されていないことの表示である。上記の例において、ＷｅｂＢｒｏｗｓｅｒは、信用できないサイトＷｅｂＳｉｔｅＹにアクセスする認可を得ることができない。ステップ５１２において、認可モジュール２０２は、エラーストリングをプリンシパルに返し、要求動作を実行する認可がないことをプリンシパルに通知することができる。エラーストリングを返した後に、認可モジュールは最終ステップへと進む。
【００４０】
一方、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可すると決定する場合には、ステップ５１４において、認可モジュール２０２は許可決定を返し、これは、プリンシパルが要求動作の実行を認可されていることの表示である。ステップ５１６において、認可モジュール２０２は、認可された動作が本質的に危険な操作であるかどうかを決定するためのチェックを行う。例えば、ファシリティは本質的に危険な操作のリストを保持することができるとともに、認可モジュール２０２は、このリストをチェックして、認可された動作が本質的に危険な操作としてリストされているかどうかを決定することができる。
【００４１】
認可された動作が、本質的に危険な操作であることがわかった場合には、ステップ５１８において、認証モジュール２０２が監査操作を実行する。例えば、認可モジュール２０２は、本質的に危険な操作監査ログに、本質的に危険な操作を実行することの要求および認可の表示のエントリを作成することができる。エントリには、本質的に危険な操作を実行することの認可を要求したプリンシパルの表示を含めてもよい。認可モジュール２０２は、本質的に危険な操作を実行する認可によって始動をかけることができる、さらに他の動作を実行してもよい。ステップ５１８において監査操作を実行するのに続いて、またはステップ５１６において認可された動作が本質的に危険な操作ではないと決定するのに続いて、認可モジュール２０２は最終ステップへと進む。
【００４２】
実施形態によっては、認可モジュール２０２は、本質的に危険な操作監査ログに、本質的に危険な操作を実行する認可要求の表示を書き込んでもよい。上記の例の続きとして、信用のできないサイトＷｅｂＳｉｔｅＹにアクセスすることが本質的に危険な操作であり、さらに適用可能なポリシーはＷｅｂＢｒｏｗｓｅｒにＷｅｂＳｉｔｅＹにアクセスする認可を与えないことを仮定して、認可モジュール２０２は、拒否決定を返し（ステップ５１０）、本質的に危険な操作を実行する認可要求と、その後の認可の拒否を、例えば、本質的に危険な操作監査ログに記録する。認可モジュール２０２は、本質的に危険な活動を実行する認可を要求したプリンシパルの表示も記録することができる。
【００４３】
図６は、いくつかの実施形態による、ポリシーの微調整を容易にする学習をファシリティが実行する方法６００のフロー図である。一例として、ユーザ（例えば、ユーザＡＢＣ）がコンピュータ上にログオンして、ウエブブラウザプログラム（例えば、ＷｅｂＢｒｏｗｓｅｒ）を開始して、ウエブサイト（例えば、ＷｅｂＳｉｔｅＹ）上のウエブページ（例えば、ＰａｇｅＸ）へのアクセス要求をしている。その結果として、ＷｅｂＢｒｏｗｓｅｒは、ＷｅｂＳｉｔｅＹからＰａｇｅＸの検索要求を出す。ステップ６０２〜６０８は、方法４００のステップ４０２〜４０８と実質的に同様である。
【００４４】
ステップ６０８において、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可すると決定する場合には、ステップ６１０において、認可モジュール２０２は、プリンシパルが要求動作を実行することを認可されていることの表示である、許可決定を返して、最終ステップへと進む。一方、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと決定する場合には、ステップ６１２において、認可モジュール２０２は、要求動作の実行の認可を拒否する、ポリシーにおける規則に対する学習が使用可能であるかどうかをチェックして決定する。上記の例に続いて、ＷｅｂＢｒｏｗｓｅｒに適用可能なポリシーに、ＷｅｂＢｒｏｗｓｅｒのインターネットへのアクセス、したがってＷｅｂＳｉｔｅＹへのアクセスを明確に拒否するルールを含めてもよいが、規則を適用する代わりに学習を適用する表示を提供することもできる。
【００４５】
認可モジュール２０２が、要求動作の実行の認可を拒否する規則に対する学習は使用可能ではないと決定する場合には、ステップ６１８において、認可モジュール２０２は、拒否決定を返し、これはプリンシパルが要求動作を実行することが認可されていないことの表示である。上記の例において、ＷｅｂＢｒｏｗｓｅｒのインターネットへの、したがってＷｅｂＳｉｔｅＹへのアクセスを明確に拒否する規則は、学習を適用することの表示を有していないことがある。この場合には、この規則が適用されて、ＷｅｂＢｒｏｗｓｅｒはＷｅｂＳｉｔｅにアクセスすることを拒否される。ステップ６２０において、認可モジュール２０２は、プリンシパルにエラーストリングを返し、要求動作を実行する認可がないことをプリンシパルに通知する。エラーストリングを返すのに続いて、認可モジュールは最終ステップへと進む。
【００４６】
一方、ステップ６１２において、認可モジュール２０２が、要求動作を実行する認可を拒否する規則に対する学習が使用可能であると決定する場合には、ステップ６１４において、認可モジュール２０２は、無効規則の表示を学習報告ログ（ｌｅａｒｎｉｎｇ ｒｅｐｏｒｔ ｌｏｇ）にエントリを作成する。エントリには、無効規則となった動作を実行することの認可を要求した、プリンシパルの表示を含めてもよい。ステップ６１６において、認可モジュール２０２は、プリンシパルが要求動作を実行することを認可されていることの表示である、許可決定を返して、最終ステップへと進む。すなわち、適用可能な規則を適用する代わりに、認可モジュール２０２は、要求動作を実行する認可を与えて、このイベントの表示を記録する。セキュリティ管理者またはその他の関心のあるユーザは、次いで、学習報告ログの内容を分析して、規則またはポリシーが制限的すぎるか、または十分に制限的ではないかを決定して、規則またはポリシーを実際に施行または実現する前に、規則またはポリシーを微調整する。
【００４７】
実施形態によっては、認可モジュール２０２は、要求動作を実行する認可を与えた規則の表示の学習報告ログにエントリを作成することができる。上記の例に続いて、ルールが、ＷｅｂＢｒｏｗｓｅｒがインターネット、したがってＷｅｂＳｉｔｅＹにアクセスすることを明確に認可するとともに、学習を適用する表示も与えることを仮定して、認可モジュール２０２は許可決定を返す（ステップ６１０）とともに、要求動作を実行することの認可を与えた規則の表示を記録する。この情報は、規則またはポリシーを微調整するのに使用することができる。例えば、報告ログのエントリから、資源にアクセスする認可が、容易に授与されすぎると決定されると、規則またはポリシーを、調節または変更して、その資源へアクセスする認可が授与される事例を減少させることができる。
【００４８】
図７は、いくつかの実施形態による、段階アクセス（ｔｉｅｒｅｄ ａｃｃｅｓｓ）制御のチェックをファシリティが提供する方法７００のフロー図を示す。先の例の１つを再び参照すると、ユーザ（例えば、ユーザＡＢＣ）はコンピュータにログオンして、ワードプロセシングアプリケーション（例えば、ＷＰＡｐｐ）を開始しており、コンピュータ上のディレクトリ（例えば、ＹＺＤｉｒ）内に記憶されたファイル（例えば、ＦｉｌｅＸ）を開くことを要求している。その結果として、ＷＰＡｐｐは、ディレクトリＹＺＤｉｒに記憶された資源ＦｉｌｅＸへのアクセス要求を出す。開始ステップから始まり、認可モジュール２０２は、ステップ７０２において、認可問い合わせ、例えば、ＹＺＤｉｒに記憶されたＦｉｌｅＸへのアクセスの認可要求を受信する。
【００４９】
ステップ７０４において、ユーザのコンピュータで実行されているオペレーティングシステムは、従来のアクセス制御のチェックを実行する。上記の例に続いて、オペレーティングシステムは、ユーザがＹＺＤｉｒのＦｉｌｅＸを開く（例えば、読取りアクセス）特権を有するかどうかをチェックして決定することができる。ステップ７０６において、オペレーティングシステムは、その従来のアクセス制御のチェック機構を使用して、ＦｉｌｅＸへのユーザアクセスを拒否すべきかどうかを決定する。
【００５０】
オペレーティングシステムの従来のアクセスチェック機構が、そのユーザのＦｉｌｅＸへのアクセスを拒否すべきであると決定すると、ステップ７０８において、オペレーティングシステムは、拒否決定を返して、最終ステップへと進む。この拒否決定は、ユーザが要求動作、例えばＦｉｌｅＸを開くこと、を実行することが認可されていないことの表示である。一方、オペレーティングシステムの従来のアクセスチェック機構が、そのユーザのＦｉｌｅＸへのアクセスを拒否すべきでないと決定する場合には、ステップ７１０において、認可モジュール２０２は、ＹＺＤｉｒに記憶されたＦｉｌｅＸへのアクセスの認可を要求しているプリンシパルを識別する。
【００５１】
ステップ７１２において、認可モジュール２０２は、識別されたプリンシパルに適用可能なポリシーを、例えば、ポリシー２０６などの集中ポリシー記憶装置から識別して、プリンシパルの識別と適用可能なポリシーとに基づいてアクセス制御のチェックを実行する。上記の例に続いて、認可モジュール２０２は、ステップ７１４において識別された適用可能なポリシーを分析して、ポリシーにおける規則または特権はプリンシパルがＹＺＤｉｒに記憶されたＦｉｌｅＸにアクセスすることを認可するかどうかを決定する。
【００５２】
認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可すると決定する場合には、ステップ７２０において、認可モジュール２０２は、プリンシパルが要求動作を実施することを認可されていることの表示である、許可決定を返して、最終ステップへと進む。一方、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと決定する場合には、ステップ７１６において、認可モジュール２０２は、プリンシパルが要求動作を実行することが認可されていないことの表示である拒否決定を返す。ステップ７１８において、認可モジュール２０２は、エラーストリングをプリンシパルに返して、最終ステップに進むことができる。エラーストリングは、要求動作を実行する認可がないことをプリンシパルに通知することができる。
【００５３】
ここで、段階アクセスのチェックを、方法７００によって示す順序と逆の順序で実行できることが認識されるであろう。例えば、認可モジュール２０２は、最初にそのアクセス制御のチェックを実行する。認可モジュール２０２が、特定の資源アクセスに対して認可を与えるべきであると決定すると、オペレーティングシステムが、その従来のアクセス制御機構を使用して、そのセキュリティチェックを実施する。
【００５４】
図８は、いくつかの実施形態による、アプリケーションプログラムのセキュリティリスクのレベルをファシリティが決定する方法８００を示すフロー図である。特に、ファシリティは、セキュリティリスクのレベルおよび／またはアプリケーションプログラムの意図の評価を、そのアプリケーションプログラムに専用のポリシーの分析に基づいて行う。一例として、ユーザはコンピュータにログオンして、アプリケーションをコンピュータ上にロードおよび／または実行することを要求している。
【００５５】
開始ステップから始まり、ステップ８０２において、ユーザのコンピュータ上で実行されているオペレーティングシステムは、アプリケーションプログラムをロード／実行する要求を受信する。ステップ８０４において、オペレーティングシステムは、ファシリティを呼び出して、アプリケーションプログラムが対応するポリシーを有するかどうかを決定する。例えば、そのアプリケーションプログラムに適用可能なポリシーは、ポリシー２０６の一部として保持することができる。ファシリティが、そのアプリケーションプログラムに適用可能なポリシーは存在しないと決定する場合には、ファシリティは、適用可能なポリシーが存在しないことをオペレーティングシステムに通知する。ステップ８０６において、オペレーティングシステムは、アプリケーションプログラムをロード／実行することの要求を拒否し、エラー状態を返す。要求を拒否するのに続いて、オペレーティングシステムは、この要求に対する最終ステップへと進む。
【００５６】
一方、ステップ８０４において、ファシリティが、そのアプリケーションプログラムに適用化なポリシーは存在すると決定する場合には、ステップ８０８において、ファシリティは、その適用可能なポリシーを分析して、そのアプリケーションプログラムをロード／実行することに関連する、またはそれから生ずる潜在的セキュリティリスクのレベルを決定する。ファシリティは、そのポリシーにおける規則によって与えられる認可のレベルまたは範囲に、リスクのレベルを基づかせることができる。例えば、規則がアプリケーションプログラムを多数の資源またはある数の本質的に危険な資源に対して認可する場合には、ファシリティは、規則がアプリケーションプログラムを小数の、比較的安全な資源に対してのみ認可する場合よりも、リスクのレベルを高く設定することができる。ファシリティは、適用可能なポリシーが存在することをオペレーティングシステムに通知して、最終ステップへと進む。
【００５７】
図９は、いくつかの実施形態による、異常の検出時により制限的なポリシーをファシリティが課する方法９００を示すフロー図である。一例として、コンピュータ上で実行中のファシリティは、２つのポリシー、ポリシーＡおよびポリシーＢを有することができ、これらはアプリケーションプログラムに適用可能である。さらに、ポリシーＡは、ポリシーＡがより多数の資源に認可を授与する点において、ポリシーＢよりも制限が少ない。
【００５８】
開始ステップから始まって、ステップ９０２において、ファシリティは制限の少ないポリシーＡを課する。ステップ９０４において、ファシリティは、コンピュータ上で実行中のアプリケーションプログラムのインスタンスにおける異常状態を検出することができる。上記の例に続いて、アプリケーションプログラムのインスタンスがコンピュータ上で実行中であり、ファシリティは、実行中のアプリケーションプログラムプロセスを監視中である。アプリケーションプログラムプロセスの監視中に、ファシリティは、そのプロセスにおける異常条件または状態を検出することができる。例えば、ファシリティは、そのコンピュータ上で実行されたアプリケーションプログラムの先のインスタンスを追跡することによって、アプリケーションプログラムが通常出すシステムコールを表す有向グラフ（ｄｉｒｅｃｔｅｄ ｇｒａｐｈ）を先に生成しておき、現行アプリケーションプログラムプロセスが行うシステムコールと有向グラフとの比較から異常状態の存在を決定することができる。
【００５９】
ステップ９０６において、異常状態の検出に応答して、ファシリティは、より制限的なポリシーＢを課して、最終ステップへと進む。一実施態様においては、ファシリティは、より制限的なポリシーＢを、異常状態が検出されたアプリケーションプログラムプロセスに課する。代替的に、ファシリティは、より制限的なポリシーＢを、アプリケーションプログラム、例えば、アプリケーションプログラムのすべてのインスタンスまたはプロセスに、課することができる。さらに、検出される異常、アプリケーションプログラム、および／または特定のポリシーに応じて、ファシリティは、コンピュータ全体により制限的なポリシーの組を課することが可能であり、例えば、より制限的なポリシーがコンピュータ上で実行中のすべてのプロセスに適用される。
【００６０】
図１０は、いくつかの実施形態による、異常の検出時にファシリティがポリシーを課する方法１０００を示すフロー図である。一例として、コンピュータ上で実行中のファシリティは、ウエブアプリケーションプログラムに適用可能なポリシー、ポリシーＡを有する。開始ステップで始まって、ステップ１００２において、ファシリティは、ウエブアプリケーションプログラムにそのポリシーを課さない。したがって、ポリシーＡは休眠しており、コンピュータ上で実行中のウエブアプリケーションプログラムのインスタンスに適用されない。ステップ１００４において、ファシリティは、コンピュータ上で実行中のウエブアプリケーションプログラムのインスタンスにおける異常状態を検出することがある。
【００６１】
上記の例に続いて、ウエブアプリケーションプログラムのインスタンスがコンピュータ上で実行されており、ファシリティは実行中のウエブアプリケーションプログラムプロセスを監視中である。アプリケーションプログラムプロセスを監視する間に、ファシリティは、プロセス中の異常条件または状態を検出することができる。例えば、ファシリティは、ウエブアプリケーションプロセスによって生成されるかまたはそれによって発生するネットワークトラフィックを監視して、そのネットワークトラフィックから、ウエブアプリケーションプロセス中に異常状態が存在することを決定することができる。ステップ１００６において、ファシリティは、休眠ポリシー、ポリシーＡをウエブアプリケーションプログラム、例えば異常の検出されたウエブアプリケーションプログラムプロセスに課して、最終ステップへと進む。別の選択肢として、ファシリティは、ポリシーＡをウエブアプリケーションプログラムのすべてのインスタンスまたはプロセスに課すことができる。このようにして、休眠ポリシーは活動状態になり、ウエブアプリケーションプログラムに適用される。
【００６２】
前述の内容から、本発明の特定の実施形態を説明の目的で記述したが、本発明の趣旨と範囲から逸脱することなく、様々な修正が可能であることが認識されるであろう。したがって、本発明は、添えられた特許請求の範囲による場合を除いて、限定されるものではない。
【技術分野】
【０００１】
本発明は、一般には、コンピュータセキュリティに関し、より詳細には、コンピュータシステム上の資源（ｒｅｓｏｕｒｃｅ）へのアクセスを制御することに関する。
【背景技術】
【０００２】
コンピュータおよびコンピュータネットワークに対する攻撃の高度の複雑化および頻発とともに、コンピュータおよびコンピュータネットワークへの依存が増大するにつれて、コンピュータセキュリティの問題は、産業界において益々顕著になっている。現状のコンピュータセキュリティ技術は、コンピュータシステムに特に損傷を与えまたは中断させるように設計された、悪性ソフトウエア（「マルウエア（ｍａｌｗａｒｅ）」、例えば、ウイルス、ワーム、およびトロイの木馬などから、および他の望ましくない活動から、アプリケーションプログラムおよびオペレーティングシステムを保護するのには不十分である。
【０００３】
既存のアクセス制御のセキュリティモデルは、通常、コンピュータ上の資源へのアクセスを認可するユーザの資格証明（ｃｒｅｄｅｎｔｉａｌｓ）に頼っている。これらのモデルにおいては、ユーザに対して利用可能なすべての資源にプロセスがアクセスする必要があるかどうかにかかわらず、同一の資格証明で遂行または実行されるすべてのプロセスに、同一のアクセス権が与えられる。また、資源へのアクセス、例えば、読取り、書込みなどを必要とするプロセスは、資源にアクセスするときに、必要なアクセスを指定する。
【０００４】
例えば、ユーザは、ユーザアカウントでパーソナルコンピュータにログオンして、結果としてパーソナルコンピュータに記憶され、および特定のワードプロセシングプログラムを使用して作成された、すべてのワードプロセシング文書にアクセスできることを期待する。この期待を満足させるために、従来のアクセス制御セキュリティシステムは、ユーザの文脈で実行されているすべてのプログラムに、ワードプロセシング文書のすべてにアクセスする許可を与える。しかしながら、これは、過剰なレベルの許可であり、なぜならば、ワードプロセシングプログラム以外のユーザの文脈において実行されているほとんどのプログラムは、実際にはワードプロセシング文書のいずれにもアクセスする必要がないからである。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
通常、マルウエアは、コード欠陥を利用することによってプロセスに感染する。危うくされたプロセスの内部でマルウエアが実行されると、プロセスが実行されているユーザのコンテキストのアクセス権を引き継ぎ、ユーザに対して利用可能なすべての資源に対するアクセスを得るが、それは元のプロセスがかつて必要としたものよりはるかに大きくなる可能性がある。
【０００６】
したがって、コンピュータ上の資源のセキュリティを改善しかつ増強するアクセス認可（ａｃｃｅｓｓ ａｕｔｈｏｒｉｚａｔｉｏｎ）に対する統合アプローチは、有用性が高いといえる。
【課題を解決するための手段】
【０００７】
コンピュータシステム上のアプリケーションプログラムおよびオペレーティングシステムの利用から発生する逆効果からコンピュータシステムを保護するソフトウエアファシリティ（「ファシリティ（ｆａｃｉｌｉｔｙ）」）について述べる。いくつかの実施形態において、ファシリティは、オペレーティングシステムの不可欠の部分として実現され、およびオペレーティングシステムに論理駆動のアクセス制御レイヤ（ｌｏｇｉｃ−ｄｒｉｖｅｎ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌａｙｅｒ）を追加する。例えば、ファシリティは、オペレーティングシステムのアクセス制御機構に不可欠の方法として実現される。
【０００８】
ファシリティは、セキュリティに敏感な（ｓｅｃｕｒｉｔｙ−ｓｅｎｓｉｔｉｖｅ）種々の資源アクセスに関する認可の問い合わせを受け取って、集中されたポリシーに基づいて資源アクセスを許可または拒否する決定を返す。ポリシーは、一例としてネットワーク、ファイルシステム、アプリケーションプログラムなどの資源を管理し、かつ保護する方法を決定する１組の規則および慣行である。集中されたポリシーの記憶装置において、ポリシーの規則は集中的に配置されており、規則および／またはポリシーを集中的に呼び出し、かつ集中的に設定することが可能となる。これは、分散型またはオブジェクト単位（ｐｅｒ−ｏｂｊｅｃｔ）のアクセス制御モデルとは対照的に、通常、物理オブジェクトに結び付けられたアクセス制御リストを使用して実現される。
【０００９】
認可モジュールは、ユーザモードプログラム、例えばユーザ文脈で実行中のアプリケーションプログラムなど、が発行する資源へのアクセス要求に応ずる、様々なオペレーティングシステム構成要素が直接的に問い合わせをすることができる。代替的には、認可モジュールは、そのようなオペレーティングシステム構成要素の上部に位置する「インターセプションレイヤ（ｉｎｔｅｒｃｅｐｔｉｏｎ ｌａｙｅｒ）」によって問い合わせをすることができる。インターセプションレイヤは、リソースにアクセスするためにユーザモードプログラムが使用するシステムコールファンクションを中断し、中断されたシステムコールファンクションに「ラッパー（ｗｒａｐｐｅｒ）」を適用するコードである。認可モジュールは、そのアクセス制御決定（すなわち、許可または拒否）を、資源アクセスを試みているアプリケーションプログラム、例えばアプリケーションプロセスの識別（ｉｄｅｎｔｉｔｙ）またはアプリケーションプログラムの識別とアプリケーションが実行されているユーザの識別との組合せのいずれかであり、およびプリンシパルに適用されるポリシーである、プリンシパルの識別に基づいて行う。
【００１０】
実施形態において、ファシリティは監査機能を提供する。例えば、ポリシーは、認可が許可（例えば、授与）されるか、または拒否（例えば、阻止）されるかにかかわらず、特定の動作を監査の対象として指示することによって、エントリが監査ログに加えられるようにすることができる。このエントリには、不適合規則（ｆａｉｌｅｄ ｒｕｌｅ）、資源またはオブジェクト、およびプリンシパルの表示を含めることができる。本質的に危険な操作などの、ある特定の操作に対しては、そのエントリには、規則、その規則が許可されたか拒否されたか、資源またはオブジェクト、およびプリンシパルの表示を含めることができる。ファシリティは、さらに、監査に基づいてイベント（ｅｖｅｎｔ）を始動することができる。例えば、ファシリティは、プリンシパル（例えば、アプリケーションプログラムおよび／またはユーザ）またはその他の当事者に、不適合規則または本質的に危険な操作の通知または表示を提供することができる。
【００１１】
実施形態において、ファシリティは、ファシリティが規則を適用する代わりに、規則を試験するか、または規則を報告する学習モード機能を提供する。例えば、ポリシーの規則は、動作を実行する認可要求を拒否することを指定することができる。学習モードが、例えば、ポリシーの著者によって、規則に対して起動される場合には、ファシリティは、動作を実行する認可の要求を拒否する代わりに、動作を実行する認可を許可または授与するとともに、イベントを生成して、動作を実行する認可要求は拒否されたであろうことを指示する。ファシリティは、例えば、阻止されるであろう規則、動作を要求する前のアプリケーションプログラムの状態などを示す報告を生成することができる。学習モード機能は、ポリシーの微調整を容易にする。例えば、ポリシーの著者は、報告を分析して、ポリシー内の規則の制限をより多くするかまたは少なくする必要があるかどうかの決定を行うことができる。
【００１２】
実施形態において、ファシリティは、段階アクセス（ｔｉｅｒｅｄ ａｃｃｅｓｓ）制御のチェックの一部として実行される。ここで、ファシリティは、一連のアクセス制御のチェックの一部として、ポリシーチェックを実行する。例えば、資源要求が行われると、最初に従来型アクセス制御機構が呼び出されて、要求された資源に対する認可があるかどうかが決定される。従来型アクセス制御機構が要求された資源に対する認可があるとの最初の決定に続いて、ファシリティが呼び出されて、そのポリシーをチェックして、要求された資源に対する認可があるかどうかを決定することができる。続いて、１つまたは複数のさらなるアクセス制御チェックを追加で呼び出して、要求された資源に対する認可があるかどうかを最終的に決定することができる。
【図面の簡単な説明】
【００１３】
【図１】ファシリティが実行される、少なくとも一部のコンピュータシステムに通常組み込まれる、選ばれた構成要素を例示するブロック図である。
【図２】いくつかの実施形態による、ファシリティの選ばれた構成要素を例示するブロック図である。
【図３】いくつかの実施形態による、ファシリティが使用するのに適当な事例のポリシーを例示する図である。
【図４】いくつかの実施形態による、拒否されたアクセス要求の監査をファシリティが実行する方法を例示するフローチャートである。
【図５】いくつかの実施形態による、本質的に危険な動作の監査をファシリティが実行する方法を例示するフローチャートである。
【図６】いくつかの実施形態による、ポリシーの微調整を容易にする学習をファシリティが実行する方法を例示するフローチャートである。
【図７】いくつかの実施形態による、段階アクセス制御のチェックをファシリティが提供する方法を例示するフローチャートである。
【図８】いくつかの実施形態による、アプリケーションプログラムのセキュリティリスクのレベルをファシリティが決定する方法を例示するフローチャートである。
【図９】いくつかの実施形態による、異常検出時により制限的なポリシーをファシリティが課する方法を例示するフローチャートである。
【図１０】いくつかの実施形態による、異常検出時にポリシーをファシリティが課する方法を例示するフローチャートである。
【発明を実施するための形態】
【００１４】
ファシリティの様々な実施形態およびその利点は、図面の図１〜１７を参照することによって最もよく理解できる。図面の要素は、必ずしも比例して拡大縮小せず、代わりに本発明の原理を明確に説明することに重点をおいている。図面全体を通して、様々な図面の同一部品および対応部品には、同一番号を使用している。
【００１５】
図１は、ファシリティが実行される、少なくとも一部のコンピュータシステムに通常、組み込まれている、選択された構成要素を例示するブロック図である。これらのコンピュータシステム１００には、コンピュータプログラムを実行するための１つまたは複数の中央処理ユニット（ＣＰＵ）１０２；プログラムおよびデータ―データ構造を含む―をそれらが使用されている間に記憶するためのコンピュータメモリ１０４；プログラムおよびデータを永続的に記憶するハードドライブなどの永続的な記憶装置１０６；コンピュータ読取可能な媒体に記憶されたプログラムおよびデータを読み取るためのＣＤ−ＲＯＭドライブなどのコンピュータ読取可能な媒体の駆動装置１０８；およびプログラムおよび／またはデータ―データ構造を含む―を交換するために、インターネットを介するなどして、コンピュータシステムを他のコンピュータシステムに接続する、ネットワーク接続１１０を含めることができる。
【００１６】
ファシリティは、コンピュータシステム１００またはその他のデバイスによって実行されるプログラムモジュールのような、コンピュータ読取可能な命令の一般的文脈において説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか、または特定の抽象データタイプを実装する、ルーチン、プログラム、オブジェクト、構成要素、データ構造などが含まれる。メモリ１０４および永続的な記憶装置１０６は、ファシリティを実現する命令を収容することができるコンピュータ読取可能な媒体である。ここで、メモリ１０４および永続的な記憶装置１０６は、ファシリティを実現する命令に加えて、様々なその他の内容を含むことがあることが認識されるであろう。
【００１７】
ここで、コンピュータシステム１００には、ビデオモニタまたはＬＣＤパネルなどの、プログラム出力を指示する１つまたは複数の表示デバイス、およびキーボード、マイクロフォン、またはマウスなどのポインティングデバイスなどの、ユーザ入力を受信する１つまたは複数の入力デバイスを含めることができることが認識されるであろう。通常、上述のように構成されたコンピュータシステム１００がファシリティの動作をサポートするのに使用されるが、ファシリティは、様々なタイプおよび構成にするとともに、様々な構成要素を有するデバイスを使用して実現することができることが認識されるであろう。
【００１８】
図２は、いくつかの実施形態による、ファシリティの選ばれた構成要素を示すブロック図である。図２に示すように、ファシリティは認可モジュール２０２を含み、このモジュールは、コンピュータシステム１００上で実行するのに適したオペレーティングシステム２０４の一体化構成要素として実現される。認可モジュール２０２は、一般に、ネットワークフェーシングアプリケーション、ネットワークフェーシングサービスおよびオペレーティングシステム構成要素などの高リスクプロセス、信用できない内容を取り扱うアプリケーション、ならびに信用できないコード、例えば、通常、インターネットによって配信されるコードなどに対する、追加の保護レイヤ（ｐｒｏｔｅｃｔｉｏｎ ｌａｙｅｒ）として機能する。認可モジュール２０２は、コンピュータシステム１００上で利用可能な資源のポリシー駆動アクセス制御を実行するための論理を提供する。
【００１９】
ファシリティは、また、認可モジュール２０２がそのアクセス制御決定をそれから行うポリシー２０６を含む。ポリシー２０６は、資源へのアクセスの認可要求を許可するか、または拒否するかを決定する規則である。いくつかの実施形態においては、ポリシー２０６は、オペレーティングシステム２０４および、特に、認可モジュール２０２によって施行される実行時規則、例えばバイナリ規則にコンパイルされる。いくつかの実施形態においては、ポリシー２０６は、集中ポリシー記憶装置（ｃｅｎｔｒａｌｉｚｅｄ ｐｏｌｉｃｙ ｓｔｏｒｅ）の一部として実現されて、この集中ポリシー記憶装置は、例えばユーザおよび／または管理者が、ポリシー２０６内の規則を含みポリシー２０６を、中央から取り消したり、中央から設定したりすることを可能にする。
【００２０】
認可モジュール２０２は、様々なオペレーティングシステムカーネル構成要素２０８が問い合わせをすることが可能であり、これらのカーネル構成要素は、プリンシパル、例えばプリンシパル２１２ａが出す資源へのアクセス要求に答える。また、認可モジュール２０２の問い合わせは、資源にアクセスするためにプリンシパル、例えばプリンシパル２１２ｂが出すシステムコールファンクションを中断する、インターセプションレイヤ２１０が行うこともできる。インターセプションレイヤ２１０は、中断されたシステムコールファンクションにラッパー（ｗｒａｐｐｅｒ）を適用して、認可モジュール２０２が適用可能なポリシー２０６に対するアクセス制御のチェックを実行することを可能にする。例えば、ラッパーを適用することには、プリンシパルおよび／またはコンピューティングシステム１００に関連する様々な環境要因の識別を決定すること、およびこの情報を認可要求の一部として供給して、認可モジュール２０２へのシステムコールを実行してそれがアクセス制御のチェックを実行することを可能にすることが含まれる。さらに、認可モジュール２０２は、プリンシパル、例えばプリンシパル２１２ｃが直接的に問い合わせをすることもできる。
【００２１】
実施形態によっては、認可モジュール２０２が実行するアクセス制御のチェックは、資源へのアクセス要求を行っているプリンシパルおよびそのプリンシパルに適用するポリシーの関数である。すなわち、認可モジュール２０２は、そのアクセス制御決定（すなわち、許可または拒否）を、プリンシパルの識別―コールしているアプリケーションプログラムの識別、またはコールしているアプリケーションプログラムの識別とそのためにそのアプリケーションプログラムが実行されているユーザの識別との組合せ―およびプリンシパルに適用可能なポリシーにおける規則に基づいて行う。実施形態によっては、認可モジュール２０２は、プリンシパルの識別および、そのアクセス制御決定を行う際のプリンシパルに適用可能なポリシーにおける規則の識別に加えて、一例として、要求アクセスのタイプ、環境因子―例えば、アプリケーションプログラムが実行されている、企業ネットワーク内部または公共ネットワークに接続されたコンピュータ、コンピュータのパッチレベル、その他―などのパラメータをさらに考慮することができる。
【００２２】
実施形態によっては、ファシリティには、図２に破線または「断続線」によって示されている、任意選択の異常検出（ａｎｏｍａｌｙ ｄｅｔｅｃｔｉｏｎ）モジュール２１４を含めることができる。異常検出モジュール２１４は、異常状態を検出するために、全体的には、コンピュータシステム１００の挙動およびコンピュータシステム１００で実行されているプログラムを監視する機能を果たす。実施形態によっては、異常検出モジュール２１４は、異常の検出時に第１の通知を、先に検出された異常の停止検出時に、後続の第２の通知を、ファシリティに提供する。これによって、ファシリティは、異常検出時に、異常が終了するまでポリシー２０６の施行を起動することが可能となり、それ以後は、ポリシー２０６はもう施行されない。代替的に、ファシリティは、異常が検出されるまでより制限の少ないポリシーの組を最初に課してもよく、この場合には、異常が終了して再び制限の少ないポリシーの組が再び施行されるまで、より制限的なポリシーの組が施行される。異常検出モジュール２１４は、コンピュータシステム１００上で実行される単一プロセス、コンピュータシステム１００上で実行されるプロセス群、またはコンピュータシステム１００全体のいずれかにおいて異常を検出することができる。
【００２３】
上述のファシリティの態様は、説明のためだけのものであり、図示した構成要素の実現および／またはファシリティの使用もしくは機能性の範囲に関する限定を意味するものではない。例えば、いくつかの実施形態によっては、認可モジュール２０２は、オペレーティングシステム２０４の一部として、またはそれに一体化して実現する必要はなく、オペレーティングシステム２０４と分離して、またはその外部に、例えば非オペレーティングシステムプログラムとして実現することができる。さらに、いくつかの実施形態においては、ポリシー２０６は集中ポリシー記憶装置として、またはその一部として実現する必要はない。したがって、ポリシー２０６は、１つの場所にある必要はなく、例えば、分散モデルを使用して実現することができる。さらに、ポリシー２０６は、認可モジュール２０２の一部として、またはそれに収容されるものとして記述してあるが、ポリシー２０６は、認可モジュール２０２によってアクセス可能ありさえすれば十分である。
【００２４】
以下の考察においては、ファシリティの実施形態は、様々な実証例と一緒に記述する。ここで、ファシリティの実施形態は、様々な観点でこれらの例から大きく外れる環境において使用できることが認識されるであろう。
【００２５】
図３は、いくつかの実施形態による、ファシリティによる使用に適当な例示ポリシーを示す。例示ポリシーには、ウエブサーバアプリケーションを保護する規則が含まれる。一例として、アイテム３０２と表示されている、資源を要求するアプリケーションプロセスがチェックされて、それがアイテム３０４と表示されている、ＷｅｂＳｅｒｖｅｒＸウエブサーバプロセスであるかどうかが決定される。認可モジュール２０２が、要求元アプリケーションプロセスはＷｅｂＳｅｒｖｅｒＸウエブサーバプロセスであると決定する場合には、認可モジュール２０２は、ポリシー内に含まれる規則に基づいて、要求された資源に対する認可を許可または拒否する。
【００２６】
図示するように、例示ポリシーはＷｅｂＳｅｒｖｅｒＸプロセスに与えられる特権またはアクセス権限を包含しており、そのデフォルトは、規則３０６に示すように、その特権またはアクセス権限が指定されない限り、要求された資源に対する認可を拒否することである。言い換えると、要求された資源がポリシーにおいて明示的に与えられていない限り、要求された資源に対する認可は拒否される。実施形態によっては、ポリシーは、アクセス制限を指定する規則、例えば特定の動作を実行する認可を拒否すべきことを指定する規則、または資源へのアクセスの認可を拒否する規則、あるいは監査を行わせる、例えばイベントをログ記録させる規則を包含することができる。
【００２７】
例示ポリシーにおける第１の規則は、ＷｅｂＳｅｒｖｅｒＸプロセスが、アイテム３０８で示す、「＄ｈｔｍｌ」ファイルを、アイテム３１０で示す、「＄Ｗｅｂディレクトリ」に書き込むことを許可する命令である。「＄ｈｔｍｌ」は、例えば*．ｈｔｍｌ、*．ｇｉｆ、その他のファイル種類の集合の表現である。「＄Ｗｅｂディレクトリ」は、ウエブディレクトリとして構成されたディレクトリの集合の表現であり、セキュリティ管理者などのポリシーの製作者とは異なる、ウエブ管理者などの管理者による定義が可能である。例えば、認可モジュール２０２は、この規則に基づいて、パラメータ「＄ｈｔｍｌ」で定義される種類のファイルを、パラメータ「＄Ｗｅｂディレクトリ」で定義される種類のディレクトリの１つに書き込む要求をしているＷｅｂＳｅｒｖｅｒＸプロセスに応答して、許可決定（すなわち、認可の授与）を返す。したがって、ポリシー内の規則を、「＄Ｗｅｂディレクトリ」のような動的かつ独立に定義されたオブジェクト群、および「＄ｈｔｍｌ」のような動的で構成可能な環境パラメータに適用することができる。
【００２８】
例示ポリシーにおける第２の規則は、それがアイテム３１４で示す「ユーザＡ」のために実行されている場合には、ＷｅｂＳｅｒｖｅｒＸプロセスが、アイテム３１２で示す、「＄ＦＴＰアップロードディレクトリ」に書込みをすることを許可する命令である。例えば、認可モジュール２０２は、この規則に基づいて、「＄ＦＴＰアップロードディレクトリ」への書込み要求をしているユーザＡのために実行されているＷｅｂＳｅｒｖｅｒＸプロセスに応答して、許可決定（すなわち、認可の授与）を返す。
【００２９】
例示ポリシーにおける第３の規則は、アイテム３１６で示す、内向きｈｔｔｐトラフィックを許可する命令である。例えば、認可モジュール２０２は、この規則に基づいて、内向きｈｔｔｐデータを受信すること、例えばネットワーク接続上を伝送される、ｈｔｔｐデータパケットを受信することを要求しているＷｅｂＳｅｒｖｅｒＸプロセスに応答して、許可決定（すなわち、認可の授与）を返す。
【００３０】
例示ポリシーにおける第４の規則は、アイテム３２０で示す、可変「＄ＦＴＰ」が使用可能である場合に、アイテム３１８で示す「ＦＴＰトラフィック」を許可する命令である。ここで、「＄ＦＴＰ」は変数であり、ポリシーを作成したセキュリティ管理者とは異なる管理者が設定することができる。例えば、認可モジュール２０２は、実行時のチェックを実行して、変数「＄ＦＴＰ」が使用可能であるかどうかを決定し、そうであれば、この規則に基づいて、パラメータ「ＦＴＰトラフィック」によって定義されるデータを送信または受信することを要求するＷｅｂＳｅｒｖｅｒＸプロセスに応答して、許可決定（すなわち、認可の授与）を返す。一方、「＄ＦＴＰ」が使用可能でない場合には、前述のアクセス要求に応答して、認可モジュール２０２はアイテム３０６で示す拒否決定（すなわち、認可の拒否）を返す。
【００３１】
ポリシーには、上記の例示特権で示したアプリケーションプロセスなどの、オペレーティングシステム内部および外部のオブジェクトに対する特権を定義する、規則を含めることができるが認識されるであろう。ポリシー内の規則は、コンパイル式またはインタープリタ式コンピュータ言語を使用する書込みコードと同様の、リッチスキーマ（ｒｉｃｈ ｓｃｈｅｍａ）を使用して指定することができる。例えば、このスキーマは、条件および一時的条件、例えば「Ｙであるときだけ、Ｘを許可する」など、動的に構成可能な環境パラメータおよび変数への依存性、環境因子への依存性、その他を規則に含めることをサポートすることができる。さらに、パラメータの使用によって、現在および将来のオブジェクトに適用する規則の作成が容易になる。例えば、特定の種類の文書を、パラメータで表現することが可能であり、そのパラメータを使用して、現在存在するものであれ、将来作成されるものであれ、その特定の種類のすべての文書に適用する制限を指定する規則を作成することができる。実施形態によっては、ポリシーが指定することによって、ある決定は、例えばポップアップダイアログボックスによって、エンドユーザに決定を委ねられるようにすることができる。
【００３２】
図４は、いくつかの実施形態による、拒否されたアクセス要求の監査をファシリティが実施する方法４００のフローチャートを示している。一例として、あるユーザ（例えば、ユーザＡＢＣ）が、コンピュータにログオンして、ワードプロセシングアプリケーション（例えば、ＷＰＡｐｐ）を開始しており、コンピュータ上のディレクトリ（例えば、ＹＺＤｉｒ）に記憶されているファイル（例えば、ＦｉｌｅＸ）を開くことを要求している。その結果として、ＷＰＡｐｐは、ディレクトリＹＺＤｉｒに記憶された資源ＦｉｌｅＸへのアクセス要求を出す。開始ステップから始まり、認可モジュール２０２は、ステップ４０２において、認可問い合わせ、例えばＹＺＤｉｒに記憶されたＦｉｌｅＸへのアクセスの認可要求を受信する。
【００３３】
ステップ４０４において、認可モジュール２０２は、ＹＺＤｉｒに記憶されたＦｉｌｅＸへのアクセスの認可要求しているプリンシパルを識別する。上記の例においては、プリンシパルは、ＷＰＡｐｐであるか、またはＷＰＡｐｐとユーザＡＢＣの組合せのいずれかとすることができる。ステップ４０６において、認可モジュール２０２は、識別されたプリンシパルに適用可能なポリシーを、例えば、ポリシー２０６などの集中ポリシー記憶装置から識別するとともに、プリンシパルの識別と適用可能なポリシーに基づいてアクセス制御のチェックを実施する。ステップ４０８において、認可モジュール２０２は、ステップ４０６において実施されたアクセス制御のチェックの結果が、アクセスを拒否するものであるかどうかを決定する。上記の例に続いて、ステップ４０８において、認可モジュール２０２は、識別された適用可能なポリシーを分析して、ポリシーにおける規則または特権が、そのプリンシパルがＹＺＤｉｒに記憶されたＦｉｌｅＸにアクセスすることを認可するかどうかを決定する。
【００３４】
認可モジュール２０２が、適用可能なポリシーがプリンシパルに要求動作を実行することを認可すると決定する場合には、ステップ４２０において、認可モジュール２０２は、プリンシパルが要求動作を実行することが認可されたことの表示である、許可決定を返して、最終ステップへと進む。一方、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと認可モジュール２０２が決定する場合には、ステップ４１０において、認可モジュール２０２は拒否決定を返し、これはプリンシパルが要求動作を実行することが認可されないことの表示である。ステップ４１２において、認可モジュール２０２は、プリンシパルにエラーストリングを返し、要求動作を実行する認可がないことをプリンシパルに通知することができる。
【００３５】
ステップ４１４において、認可モジュール２０２は、監査が使用可能かどうかを決定するチェックを行う。適用可能なポリシーまたは規則に関連するフラグまたはレコードによって、監査を実施すべきかどうかを指示することができる。監査が使用可能でない場合には、認可モジュール２０２は、最終ステップへと進む。一方、監査が使用可能である場合には、認可モジュール２０２は、ステップ４１６において、監査ログにエントリを作成する。エントリは、拒否された要求、無効な規則、プリンシパル、および／または要求された資源を識別することができる。
【００３６】
ステップ４１８において、認可モジュール２０２は、拒否要求の監査に基づいて１つまたは複数のイベントを始動することができる。例えば、認可モジュール２０２は、例えば電子メール、音声メール、テキストメッセージングなどを介して、セキュリティ管理者に、非認可動作を実行すること、プリンシパルによる非認可動作の実行の試みに続いてアプリケーションプロセスを終了すること、プリンシパルによる非認可動作の実行の試みに続いてより厳格なポリシーの組を課すること、その他の、プリンシパルによる試みの表示を提供することができる。それらのイベントを始動することに続いて、認可モジュール２０２は、最終ステップへと進む。
【００３７】
当業者であれば、本明細書において開示した、これらおよびその他のプロセスならびに方法に対して、プロセスおよび方法において実行される機能は、異なる順序で実現できることを認識するであろう。さらに、概説したステップは、例示的なものにすぎず、本発明の本質から外れることなく、いくつかのステップを任意選択とすること、より少ないステップと組み合わせること、または追加のステップに拡張することができる。
【００３８】
図５は、いくつかの実施形態による、本質的に危険な操作の監査をファシリティが実行する方法５００のフロー図を示す。一例として、ユーザ（例えば、ユーザＡＢＣ）はコンピュータにログオンして、ウエブブラウザプログラム（例えば、ＷｅｂＢｒｏｗｓｅｒ）を開始して、信用のできないウエブサイト（例えば、ＷｅｂＳｉｔｅＹ）上のウエブページ（例えば、ＰａｇｅＸ）へのアクセス要求をしている。結果として、ＷｅｂＢｒｏｗｓｅｒは、ＷｅｂＳｉｔｅＹからＰａｇｅＸを検索する要求を出す。ステップ５０２〜５０８は、実質的に方法４００のステップ４０２〜４０８と同様である。
【００３９】
ステップ５０８において、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと決定する場合には、ステップ５１０において、認可モジュール２０２は拒否決定を返し、これはプリンシパルが要求動作の実行を認可されていないことの表示である。上記の例において、ＷｅｂＢｒｏｗｓｅｒは、信用できないサイトＷｅｂＳｉｔｅＹにアクセスする認可を得ることができない。ステップ５１２において、認可モジュール２０２は、エラーストリングをプリンシパルに返し、要求動作を実行する認可がないことをプリンシパルに通知することができる。エラーストリングを返した後に、認可モジュールは最終ステップへと進む。
【００４０】
一方、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可すると決定する場合には、ステップ５１４において、認可モジュール２０２は許可決定を返し、これは、プリンシパルが要求動作の実行を認可されていることの表示である。ステップ５１６において、認可モジュール２０２は、認可された動作が本質的に危険な操作であるかどうかを決定するためのチェックを行う。例えば、ファシリティは本質的に危険な操作のリストを保持することができるとともに、認可モジュール２０２は、このリストをチェックして、認可された動作が本質的に危険な操作としてリストされているかどうかを決定することができる。
【００４１】
認可された動作が、本質的に危険な操作であることがわかった場合には、ステップ５１８において、認証モジュール２０２が監査操作を実行する。例えば、認可モジュール２０２は、本質的に危険な操作監査ログに、本質的に危険な操作を実行することの要求および認可の表示のエントリを作成することができる。エントリには、本質的に危険な操作を実行することの認可を要求したプリンシパルの表示を含めてもよい。認可モジュール２０２は、本質的に危険な操作を実行する認可によって始動をかけることができる、さらに他の動作を実行してもよい。ステップ５１８において監査操作を実行するのに続いて、またはステップ５１６において認可された動作が本質的に危険な操作ではないと決定するのに続いて、認可モジュール２０２は最終ステップへと進む。
【００４２】
実施形態によっては、認可モジュール２０２は、本質的に危険な操作監査ログに、本質的に危険な操作を実行する認可要求の表示を書き込んでもよい。上記の例の続きとして、信用のできないサイトＷｅｂＳｉｔｅＹにアクセスすることが本質的に危険な操作であり、さらに適用可能なポリシーはＷｅｂＢｒｏｗｓｅｒにＷｅｂＳｉｔｅＹにアクセスする認可を与えないことを仮定して、認可モジュール２０２は、拒否決定を返し（ステップ５１０）、本質的に危険な操作を実行する認可要求と、その後の認可の拒否を、例えば、本質的に危険な操作監査ログに記録する。認可モジュール２０２は、本質的に危険な活動を実行する認可を要求したプリンシパルの表示も記録することができる。
【００４３】
図６は、いくつかの実施形態による、ポリシーの微調整を容易にする学習をファシリティが実行する方法６００のフロー図である。一例として、ユーザ（例えば、ユーザＡＢＣ）がコンピュータ上にログオンして、ウエブブラウザプログラム（例えば、ＷｅｂＢｒｏｗｓｅｒ）を開始して、ウエブサイト（例えば、ＷｅｂＳｉｔｅＹ）上のウエブページ（例えば、ＰａｇｅＸ）へのアクセス要求をしている。その結果として、ＷｅｂＢｒｏｗｓｅｒは、ＷｅｂＳｉｔｅＹからＰａｇｅＸの検索要求を出す。ステップ６０２〜６０８は、方法４００のステップ４０２〜４０８と実質的に同様である。
【００４４】
ステップ６０８において、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可すると決定する場合には、ステップ６１０において、認可モジュール２０２は、プリンシパルが要求動作を実行することを認可されていることの表示である、許可決定を返して、最終ステップへと進む。一方、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと決定する場合には、ステップ６１２において、認可モジュール２０２は、要求動作の実行の認可を拒否する、ポリシーにおける規則に対する学習が使用可能であるかどうかをチェックして決定する。上記の例に続いて、ＷｅｂＢｒｏｗｓｅｒに適用可能なポリシーに、ＷｅｂＢｒｏｗｓｅｒのインターネットへのアクセス、したがってＷｅｂＳｉｔｅＹへのアクセスを明確に拒否するルールを含めてもよいが、規則を適用する代わりに学習を適用する表示を提供することもできる。
【００４５】
認可モジュール２０２が、要求動作の実行の認可を拒否する規則に対する学習は使用可能ではないと決定する場合には、ステップ６１８において、認可モジュール２０２は、拒否決定を返し、これはプリンシパルが要求動作を実行することが認可されていないことの表示である。上記の例において、ＷｅｂＢｒｏｗｓｅｒのインターネットへの、したがってＷｅｂＳｉｔｅＹへのアクセスを明確に拒否する規則は、学習を適用することの表示を有していないことがある。この場合には、この規則が適用されて、ＷｅｂＢｒｏｗｓｅｒはＷｅｂＳｉｔｅにアクセスすることを拒否される。ステップ６２０において、認可モジュール２０２は、プリンシパルにエラーストリングを返し、要求動作を実行する認可がないことをプリンシパルに通知する。エラーストリングを返すのに続いて、認可モジュールは最終ステップへと進む。
【００４６】
一方、ステップ６１２において、認可モジュール２０２が、要求動作を実行する認可を拒否する規則に対する学習が使用可能であると決定する場合には、ステップ６１４において、認可モジュール２０２は、無効規則の表示を学習報告ログ（ｌｅａｒｎｉｎｇ ｒｅｐｏｒｔ ｌｏｇ）にエントリを作成する。エントリには、無効規則となった動作を実行することの認可を要求した、プリンシパルの表示を含めてもよい。ステップ６１６において、認可モジュール２０２は、プリンシパルが要求動作を実行することを認可されていることの表示である、許可決定を返して、最終ステップへと進む。すなわち、適用可能な規則を適用する代わりに、認可モジュール２０２は、要求動作を実行する認可を与えて、このイベントの表示を記録する。セキュリティ管理者またはその他の関心のあるユーザは、次いで、学習報告ログの内容を分析して、規則またはポリシーが制限的すぎるか、または十分に制限的ではないかを決定して、規則またはポリシーを実際に施行または実現する前に、規則またはポリシーを微調整する。
【００４７】
実施形態によっては、認可モジュール２０２は、要求動作を実行する認可を与えた規則の表示の学習報告ログにエントリを作成することができる。上記の例に続いて、ルールが、ＷｅｂＢｒｏｗｓｅｒがインターネット、したがってＷｅｂＳｉｔｅＹにアクセスすることを明確に認可するとともに、学習を適用する表示も与えることを仮定して、認可モジュール２０２は許可決定を返す（ステップ６１０）とともに、要求動作を実行することの認可を与えた規則の表示を記録する。この情報は、規則またはポリシーを微調整するのに使用することができる。例えば、報告ログのエントリから、資源にアクセスする認可が、容易に授与されすぎると決定されると、規則またはポリシーを、調節または変更して、その資源へアクセスする認可が授与される事例を減少させることができる。
【００４８】
図７は、いくつかの実施形態による、段階アクセス（ｔｉｅｒｅｄ ａｃｃｅｓｓ）制御のチェックをファシリティが提供する方法７００のフロー図を示す。先の例の１つを再び参照すると、ユーザ（例えば、ユーザＡＢＣ）はコンピュータにログオンして、ワードプロセシングアプリケーション（例えば、ＷＰＡｐｐ）を開始しており、コンピュータ上のディレクトリ（例えば、ＹＺＤｉｒ）内に記憶されたファイル（例えば、ＦｉｌｅＸ）を開くことを要求している。その結果として、ＷＰＡｐｐは、ディレクトリＹＺＤｉｒに記憶された資源ＦｉｌｅＸへのアクセス要求を出す。開始ステップから始まり、認可モジュール２０２は、ステップ７０２において、認可問い合わせ、例えば、ＹＺＤｉｒに記憶されたＦｉｌｅＸへのアクセスの認可要求を受信する。
【００４９】
ステップ７０４において、ユーザのコンピュータで実行されているオペレーティングシステムは、従来のアクセス制御のチェックを実行する。上記の例に続いて、オペレーティングシステムは、ユーザがＹＺＤｉｒのＦｉｌｅＸを開く（例えば、読取りアクセス）特権を有するかどうかをチェックして決定することができる。ステップ７０６において、オペレーティングシステムは、その従来のアクセス制御のチェック機構を使用して、ＦｉｌｅＸへのユーザアクセスを拒否すべきかどうかを決定する。
【００５０】
オペレーティングシステムの従来のアクセスチェック機構が、そのユーザのＦｉｌｅＸへのアクセスを拒否すべきであると決定すると、ステップ７０８において、オペレーティングシステムは、拒否決定を返して、最終ステップへと進む。この拒否決定は、ユーザが要求動作、例えばＦｉｌｅＸを開くこと、を実行することが認可されていないことの表示である。一方、オペレーティングシステムの従来のアクセスチェック機構が、そのユーザのＦｉｌｅＸへのアクセスを拒否すべきでないと決定する場合には、ステップ７１０において、認可モジュール２０２は、ＹＺＤｉｒに記憶されたＦｉｌｅＸへのアクセスの認可を要求しているプリンシパルを識別する。
【００５１】
ステップ７１２において、認可モジュール２０２は、識別されたプリンシパルに適用可能なポリシーを、例えば、ポリシー２０６などの集中ポリシー記憶装置から識別して、プリンシパルの識別と適用可能なポリシーとに基づいてアクセス制御のチェックを実行する。上記の例に続いて、認可モジュール２０２は、ステップ７１４において識別された適用可能なポリシーを分析して、ポリシーにおける規則または特権はプリンシパルがＹＺＤｉｒに記憶されたＦｉｌｅＸにアクセスすることを認可するかどうかを決定する。
【００５２】
認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可すると決定する場合には、ステップ７２０において、認可モジュール２０２は、プリンシパルが要求動作を実施することを認可されていることの表示である、許可決定を返して、最終ステップへと進む。一方、認可モジュール２０２が、適用可能なポリシーはプリンシパルが要求動作を実行することを認可しないと決定する場合には、ステップ７１６において、認可モジュール２０２は、プリンシパルが要求動作を実行することが認可されていないことの表示である拒否決定を返す。ステップ７１８において、認可モジュール２０２は、エラーストリングをプリンシパルに返して、最終ステップに進むことができる。エラーストリングは、要求動作を実行する認可がないことをプリンシパルに通知することができる。
【００５３】
ここで、段階アクセスのチェックを、方法７００によって示す順序と逆の順序で実行できることが認識されるであろう。例えば、認可モジュール２０２は、最初にそのアクセス制御のチェックを実行する。認可モジュール２０２が、特定の資源アクセスに対して認可を与えるべきであると決定すると、オペレーティングシステムが、その従来のアクセス制御機構を使用して、そのセキュリティチェックを実施する。
【００５４】
図８は、いくつかの実施形態による、アプリケーションプログラムのセキュリティリスクのレベルをファシリティが決定する方法８００を示すフロー図である。特に、ファシリティは、セキュリティリスクのレベルおよび／またはアプリケーションプログラムの意図の評価を、そのアプリケーションプログラムに専用のポリシーの分析に基づいて行う。一例として、ユーザはコンピュータにログオンして、アプリケーションをコンピュータ上にロードおよび／または実行することを要求している。
【００５５】
開始ステップから始まり、ステップ８０２において、ユーザのコンピュータ上で実行されているオペレーティングシステムは、アプリケーションプログラムをロード／実行する要求を受信する。ステップ８０４において、オペレーティングシステムは、ファシリティを呼び出して、アプリケーションプログラムが対応するポリシーを有するかどうかを決定する。例えば、そのアプリケーションプログラムに適用可能なポリシーは、ポリシー２０６の一部として保持することができる。ファシリティが、そのアプリケーションプログラムに適用可能なポリシーは存在しないと決定する場合には、ファシリティは、適用可能なポリシーが存在しないことをオペレーティングシステムに通知する。ステップ８０６において、オペレーティングシステムは、アプリケーションプログラムをロード／実行することの要求を拒否し、エラー状態を返す。要求を拒否するのに続いて、オペレーティングシステムは、この要求に対する最終ステップへと進む。
【００５６】
一方、ステップ８０４において、ファシリティが、そのアプリケーションプログラムに適用化なポリシーは存在すると決定する場合には、ステップ８０８において、ファシリティは、その適用可能なポリシーを分析して、そのアプリケーションプログラムをロード／実行することに関連する、またはそれから生ずる潜在的セキュリティリスクのレベルを決定する。ファシリティは、そのポリシーにおける規則によって与えられる認可のレベルまたは範囲に、リスクのレベルを基づかせることができる。例えば、規則がアプリケーションプログラムを多数の資源またはある数の本質的に危険な資源に対して認可する場合には、ファシリティは、規則がアプリケーションプログラムを小数の、比較的安全な資源に対してのみ認可する場合よりも、リスクのレベルを高く設定することができる。ファシリティは、適用可能なポリシーが存在することをオペレーティングシステムに通知して、最終ステップへと進む。
【００５７】
図９は、いくつかの実施形態による、異常の検出時により制限的なポリシーをファシリティが課する方法９００を示すフロー図である。一例として、コンピュータ上で実行中のファシリティは、２つのポリシー、ポリシーＡおよびポリシーＢを有することができ、これらはアプリケーションプログラムに適用可能である。さらに、ポリシーＡは、ポリシーＡがより多数の資源に認可を授与する点において、ポリシーＢよりも制限が少ない。
【００５８】
開始ステップから始まって、ステップ９０２において、ファシリティは制限の少ないポリシーＡを課する。ステップ９０４において、ファシリティは、コンピュータ上で実行中のアプリケーションプログラムのインスタンスにおける異常状態を検出することができる。上記の例に続いて、アプリケーションプログラムのインスタンスがコンピュータ上で実行中であり、ファシリティは、実行中のアプリケーションプログラムプロセスを監視中である。アプリケーションプログラムプロセスの監視中に、ファシリティは、そのプロセスにおける異常条件または状態を検出することができる。例えば、ファシリティは、そのコンピュータ上で実行されたアプリケーションプログラムの先のインスタンスを追跡することによって、アプリケーションプログラムが通常出すシステムコールを表す有向グラフ（ｄｉｒｅｃｔｅｄ ｇｒａｐｈ）を先に生成しておき、現行アプリケーションプログラムプロセスが行うシステムコールと有向グラフとの比較から異常状態の存在を決定することができる。
【００５９】
ステップ９０６において、異常状態の検出に応答して、ファシリティは、より制限的なポリシーＢを課して、最終ステップへと進む。一実施態様においては、ファシリティは、より制限的なポリシーＢを、異常状態が検出されたアプリケーションプログラムプロセスに課する。代替的に、ファシリティは、より制限的なポリシーＢを、アプリケーションプログラム、例えば、アプリケーションプログラムのすべてのインスタンスまたはプロセスに、課することができる。さらに、検出される異常、アプリケーションプログラム、および／または特定のポリシーに応じて、ファシリティは、コンピュータ全体により制限的なポリシーの組を課することが可能であり、例えば、より制限的なポリシーがコンピュータ上で実行中のすべてのプロセスに適用される。
【００６０】
図１０は、いくつかの実施形態による、異常の検出時にファシリティがポリシーを課する方法１０００を示すフロー図である。一例として、コンピュータ上で実行中のファシリティは、ウエブアプリケーションプログラムに適用可能なポリシー、ポリシーＡを有する。開始ステップで始まって、ステップ１００２において、ファシリティは、ウエブアプリケーションプログラムにそのポリシーを課さない。したがって、ポリシーＡは休眠しており、コンピュータ上で実行中のウエブアプリケーションプログラムのインスタンスに適用されない。ステップ１００４において、ファシリティは、コンピュータ上で実行中のウエブアプリケーションプログラムのインスタンスにおける異常状態を検出することがある。
【００６１】
上記の例に続いて、ウエブアプリケーションプログラムのインスタンスがコンピュータ上で実行されており、ファシリティは実行中のウエブアプリケーションプログラムプロセスを監視中である。アプリケーションプログラムプロセスを監視する間に、ファシリティは、プロセス中の異常条件または状態を検出することができる。例えば、ファシリティは、ウエブアプリケーションプロセスによって生成されるかまたはそれによって発生するネットワークトラフィックを監視して、そのネットワークトラフィックから、ウエブアプリケーションプロセス中に異常状態が存在することを決定することができる。ステップ１００６において、ファシリティは、休眠ポリシー、ポリシーＡをウエブアプリケーションプログラム、例えば異常の検出されたウエブアプリケーションプログラムプロセスに課して、最終ステップへと進む。別の選択肢として、ファシリティは、ポリシーＡをウエブアプリケーションプログラムのすべてのインスタンスまたはプロセスに課すことができる。このようにして、休眠ポリシーは活動状態になり、ウエブアプリケーションプログラムに適用される。
【００６２】
前述の内容から、本発明の特定の実施形態を説明の目的で記述したが、本発明の趣旨と範囲から逸脱することなく、様々な修正が可能であることが認識されるであろう。したがって、本発明は、添えられた特許請求の範囲による場合を除いて、限定されるものではない。
【特許請求の範囲】
【請求項１】
アプリケーションプログラムイメージをメモリにロードする要求を受け取ることと、
前記アプリケーションプログラムイメージが予め定められた資源にアクセスすることを意図するかどうかを決定することと、
前記アプリケーションプログラムイメージが前記予め定められた資源にアクセスすることを意図することを決定するのに応じて、前記アプリケーションプログラムイメージをロードする要求を拒否することと
をコンピュータに実行させる内容を有するコンピュータ読取可能な記憶媒体。
【請求項２】
前記予め定められた資源にアクセスする意図することを決定することは、前記アプリケーションプログラムイメージに適用可能なポリシーの分析によるを特徴とする請求項１に記載のコンピュータ読取可能な記憶媒体。
【請求項３】
アプリケーションプログラムのセキュリティリスクを問い合わせるコンピューティングシステムにおける方法であって、
アプリケーションプログラムイメージに適用可能なポリシーがあるかどうかを決定するステップと、
適用可能なポリシーがあることを決定するのに応じて、前記アプリケーションプログラムイメージを処理するステップと、
適用可能なポリシーが存在しないことを決定するのに応じて、前記アプリケーションプログラムイメージを処理しないステップと
を備えたことを特徴とする方法。
【請求項４】
適用可能なポリシーがあること決定するのに応じて、前記アプリケーションプログラムイメージに関連付けられた潜在的セキュリティリスクを決定するステップをさらに備えたことを特徴とする請求項３に記載の方法。
【請求項５】
前記アプリケーションプログラムイメージのさらなる処理が前記アプリケーションプログラムイメージの意図によるように、前記適用可能なポリシーを分析して、前記アプリケーションプログラムイメージの意図を決定するステップをさらに備えたことを特徴とする請求項３に記載の方法。
【請求項６】
前記アプリケーションプログラムイメージを処理するステップは、前記アプリケーションプログラムイメージをロードするステップを含むことを特徴とする請求項３に記載の方法。
【請求項７】
前記アプリケーションプログラムイメージを処理するステップは、前記アプリケーションプログラムイメージを実行するステップを含むことを特徴とする請求項３に記載の方法。
【請求項１】
アプリケーションプログラムイメージをメモリにロードする要求を受け取ることと、
前記アプリケーションプログラムイメージが予め定められた資源にアクセスすることを意図するかどうかを決定することと、
前記アプリケーションプログラムイメージが前記予め定められた資源にアクセスすることを意図することを決定するのに応じて、前記アプリケーションプログラムイメージをロードする要求を拒否することと
をコンピュータに実行させる内容を有するコンピュータ読取可能な記憶媒体。
【請求項２】
前記予め定められた資源にアクセスする意図することを決定することは、前記アプリケーションプログラムイメージに適用可能なポリシーの分析によるを特徴とする請求項１に記載のコンピュータ読取可能な記憶媒体。
【請求項３】
アプリケーションプログラムのセキュリティリスクを問い合わせるコンピューティングシステムにおける方法であって、
アプリケーションプログラムイメージに適用可能なポリシーがあるかどうかを決定するステップと、
適用可能なポリシーがあることを決定するのに応じて、前記アプリケーションプログラムイメージを処理するステップと、
適用可能なポリシーが存在しないことを決定するのに応じて、前記アプリケーションプログラムイメージを処理しないステップと
を備えたことを特徴とする方法。
【請求項４】
適用可能なポリシーがあること決定するのに応じて、前記アプリケーションプログラムイメージに関連付けられた潜在的セキュリティリスクを決定するステップをさらに備えたことを特徴とする請求項３に記載の方法。
【請求項５】
前記アプリケーションプログラムイメージのさらなる処理が前記アプリケーションプログラムイメージの意図によるように、前記適用可能なポリシーを分析して、前記アプリケーションプログラムイメージの意図を決定するステップをさらに備えたことを特徴とする請求項３に記載の方法。
【請求項６】
前記アプリケーションプログラムイメージを処理するステップは、前記アプリケーションプログラムイメージをロードするステップを含むことを特徴とする請求項３に記載の方法。
【請求項７】
前記アプリケーションプログラムイメージを処理するステップは、前記アプリケーションプログラムイメージを実行するステップを含むことを特徴とする請求項３に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１２−３７８７（Ｐ２０１２−３７８７Ａ）
【公開日】平成２４年１月５日（２０１２．１．５）
【国際特許分類】
【出願番号】特願２０１１−２２０９９５（Ｐ２０１１−２２０９９５）
【出願日】平成２３年１０月５日（２０１１．１０．５）
【分割の表示】特願２００５−２９００９１（Ｐ２００５−２９００９１）の分割
【原出願日】平成１７年１０月３日（２００５．１０．３）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成２４年１月５日（２０１２．１．５）
【国際特許分類】
【出願日】平成２３年１０月５日（２０１１．１０．５）
【分割の表示】特願２００５−２９００９１（Ｐ２００５−２９００９１）の分割
【原出願日】平成１７年１０月３日（２００５．１０．３）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]