JP4878647B2

JP4878647B2 - 信頼できないコンテントを安全に実行するための方法およびシステム

Info

Publication number: JP4878647B2
Application number: JP2010054439A
Authority: JP
Inventors: ジェイ．チャンシャノン; ジェンセンワーズグレゴリー; シー．ゴートゼルマリオ; シャーバーラト; エム．スイフトマイケル; ビー．ウォードリチャード
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1998-06-12
Filing date: 2010-03-11
Publication date: 2012-02-15
Anticipated expiration: 2019-06-09
Also published as: WO1999064946A1; EP1086413B1; US20020019941A1; EP1086413A1; JP2010176690A; JP4906188B2; ATE518180T1; ES2368200T3; JP2002517852A; US6505300B2

Description

本発明は、一般にコンピュータシステムに関し、より詳細には、コンピュータシステム用のセキュリティの改善に関する。

（発明の背景）
歴史的に、実行可能なコンテント（content）は磁気媒体を物理的にコンピュータに運び、管理権限を持つ人にインストールしてもらうによってのみ、コンピュータにインストールすることができた。しかし現在、インターネットにより、普通のコンピュータユーザがプログラム、ＨＴＭＬページ、および制御などの実行可能なコンテントをダウンロードすることが非常に簡単になり、普及してきた。多くの場合、実行可能なコンテントは、ユーザがこのようなイベントが起きたことに気づくことさえなく、インターネットを介してダウンロードし、実行することが可能である。同様に、コンピュータユーザは実行可能なプログラム、および／またはマクロを含む文書など実行可能なコンテントが含まれるファイルを含む電子メールまたはニュースを受信するか、さらに、メールまたはニュース自体がＨＴＭＬページである場合がある。このようなメッセージまたはその添付物を開くことは、どのような実行可能なコンテントが存在するにせよ受信者のシステムをそのコンテントにさらすことになる。

残念なことに、このような実行可能なコンテントはしばしば不正であり、たとえば、悪意を持って故意にクライアントマシン上のデータを破壊したりエラーが起こりがちで、クライアントのマシンをクラッシュさせるか、または善意であっても注意が足りず、クライアントに関する機密情報を漏らす場合がある。こういったタイプのコンピュータ問題は、以前は「ウィルス」および「トロイの木馬」の形で存在したが、ワールドワイドウェブの普及はこれらの問題を広げ、場合によっては制御不可能にしてしまった。

サーバ側では、ウェブサーバはクライアントのためにＣＧＩスクリプトなどのサーバプログラムを起動し、そのプログラムからのデータをクライアントに戻す。このようなスクリプトのソースは、必ずしも注意深く制御されておらず、また、このようなスクリプトがすべてよく書かれているわけではない。この結果、不完全に書かれたＣＧＩスクリプトは多すぎるコンピュータリソースを使用することによってウェブサーバがクラッシュまたは速度を落とす原因となっている。さらに、不完全に書かれたサーバプログラムは、他のアプリケーションを実行したりまたは記憶域にデータを書き込んだり記憶域からデータを読み出したりなど、それがすべきではないアクションを実行するように悪意あるクライアントによって書き換えられる可能性がある。最後に、一部のウェブサーバはクライアントプログラムが、クライアントのために実行されるべきスクリプトをサーバに送信することさえ許可し、多くの危険を招いている。

一般に、クライアントおよびサーバの動作環境は不正な実行可能なコンテントに対して適切に保護されていない。同時に、信頼できないコンテントという固有のリスクがあるにもかかわらず、多くの実行可能なコンテントが貴重なので、実行可能なコンテントを受信し実行できるニーズは増大を続けるであろう。

簡単に言えば、本発明は、コンテントがアクセスする可能性のあるリソースを制限する、信頼できないコンテント（実行可能コード、ダイナミックＨＴＭＬ、Ｊａｖａ制御またはＡｃｔｉｖｅ−Ｘ制御など）に関して制限付き実行コンテキストを提供する。制限付きプロセスは信頼できないコンテントについて設定され、そのコンテントによって試みられた任意のアクションは、種々の基準に基づいてプロセスの制限を受ける。プロセスがリソースにアクセスしようとする時にはいつでも、各プロセスに関連付けられた制限付きトークンがリソースのセキュリティ情報に対して比較され、そのタイプのアクセスが許可されるかどうかを決定する。リソースのセキュリティ情報はこうして、プロセス、したがって信頼できないコンテントがリソースにアクセスできるかどうかを決定し、アクセスできる場合、許可されたアクセスのタイプを決定する。

信頼できないコンテントはウェブサイトからダウンロードされたデータを含み、このような各サイトはサイト識別およびサイトがカテゴリ化されているゾーンに基づいて設定された制限付きプロセスを有する。ＡＰＩおよびヘルパープロセスはウェブサイトがそれ自体のサイト、ファイル、レジストリキーにアクセスすることを可能にし、一方、そのサイトに関連しない他のリソース上のＡＣＬは、サイト識別、ゾーンまたは他の基準に基づいて所望のようにそのサイトへのアクセスを制限する。他の信頼できないコンテントは、電子メールメッセージ、ニュースおよびそれに対する任意の添付物を含む。このようなコンテントも同様に制限付き実行コンテキスト内で実行され、ここで制限は送信者の識別などの基準に基づいている。サーバもまた、制限付き実行コンテキスト内でスクリプトおよびクライアントプロセスなどの信頼できないコンテントを実行する場合があり、ここで制限はスクリプトの作成者、使用されているクライアント認証の方法、および／または任意の他の、コンテントがどの程度信頼できるかまたは信頼できないかを示す、サーバに使用可能な情報などの基準に基づく可能性がある。

他の利点は図面と共に次の詳細な説明から明らかになる。

本発明を組み込むことのできるコンピュータシステムを表すブロック図である。本発明の一態様による、既存のトークンから制限付きのトークンを作成することを一般に表すブロック図である。プロセスがリソースにアクセスできるかどうかを決定するための種々の構成要素を一般に表すブロック図である。本発明の一態様による、既存のトークンから制限付きのトークンを作成する一般のステップを表すフローチャートである。本発明の一態様による、既存のトークンから制限付きのトークンを作成する一般のステップを表すフローチャートである。本発明の一態様による、リソースにアクセスを試みる関連付けられた制限付きのトークンを有するプロセスを一般に表すブロック図である。本発明の一態様による、プロセスのオブジェクトへアクセスすることを決定するための、関連付けられた制限付きのトークンを有する論理を一般に表すブロック図である。本発明の一態様による、リソースへのプロセスアクセスを許可するかどうかを決定する時にとられる一般のステップを表すフローチャートである。共通の制限を伴う多数のプロセスをその中に有するジョブオブジェクトを示すブロック図である。本発明の一態様による、設定されたプロセス内の信頼できないコンテントで、リソースへのアクセスに関して制限されている信頼できないコンテントを一般に表すブロック図である。信頼できないサイトおよび電子メールコンテントに関する基準に従ってプロセスを制限するための、本発明の別の一態様による構成要素を表すブロック図である。信頼できないサイトおよび電子メールコンテントに関する基準に従ってプロセスを制限するための、本発明の別の一態様による構成要素を表すブロック図である。本発明の別の一態様による、制限付きプロセスのためにリソースにアクセスするためのヘルパープロセスを一般に表すブロック図である。本発明の別の一態様による、アプリケーションプログラミングインタフェース（ＡＰＩ）がヘルパープロセスを使用して情報をリソースから、そのリソースへのアクセスを制限されているプロセスへ戻す方法を示すフロー図である。本発明の別の一態様による、アプリケーションプログラミングインタフェース（ＡＰＩ）がヘルパープロセスを使用して情報をリソースから、そのリソースへのアクセスを制限されているプロセスへ戻す方法を示すフロー図である。本発明の別の一態様による、ファイルシステム内の別のサイトのファイルから分離されたサイトのファイルの図である。本発明の別の一態様による、信頼できないコンテントのファイルシステム要求がリダイレクトされる方法を表すブロック図である。本発明の別の一態様による、信頼できないコンテントのレジストリ要求がリダイレクトされる方法を表すブロック図である。本発明の別の一態様による、送信者の識別を含む基準によって電子メールコンテントが制限される方法の例を表すフロー図である。本発明の別の一態様による、設定されたプロセス内の信頼できないスクリプトで、リソースへのアクセスに関して制限されている信頼できないスクリプトを一般に表すブロック図である。本発明の別の一態様による、クライアントが認証された方法を含む、基準に従ってサーバ上でクライアントプロセスが制限される方法の例を表すフロー図である。

例としてのオペレーティング環境
図１および以下の議論は、本発明が実現できる適切なコンピューティング環境の簡単で一般的な説明を提供することを意図している。必要ではないが、本発明は、パーソナルコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能な命令の一般的なコンテキスト内で説明される。一般に、プログラムモジュールはルーチン、プログラム、オブジェクト、構成要素、データ構造などを含み、特定のタスクを実行するか、特定の抽象的なデータタイプを実装する。さらに、当業者であれば本発明は、ハンドヘルド・デバイス、マルチプロセッサシステム、マイクロプロセッサに基づいたまたはプログラミング可能な消費者電気製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む他ののコンピュータシステム構成でも実行できることが理解されるであろう。本発明はまた、通信ネットワークを介してリンクされた遠隔処理デバイスによってタスクが実行される分散コンピューティング環境内でも実行できる。分散コンピューティング環境では、プログラムモジュールはローカルメモリ記憶デバイスおよび遠隔メモリ記憶デバイスの両方に位置する場合がある。

図１を参照すると、本発明を実現するための一例としてのシステムは、従来のパーソナルコンピュータ２０などの形の汎用コンピューティングデバイスを含み、汎用コンピューティングデバイスは処理ユニット２１、システムメモリ２２、およびシステムメモリから処理ユニット２１までを含む種々のシステム構成要素を結合するシステムバス２３を含む。システムバス２３はいくつかのタイプのバス構成のうち任意の構成であって、その中にはメモリバスまたはメモリコントローラ、周辺バス、種々のバスアーキテクチャのうち任意のアーキテクチャを使用するローカルバスを含んでもよい。システムメモリは読取り専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。起動時などにパーソナルコンピュータ２０内の要素の間で情報を転送する役に立つ基本的なルーチンを含む基本入出力システム２６（ＢＩＯＳ）は、ＲＯＭ２４内に格納されている。パーソナルコンピュータ２０はさらに、図示されてはいないがハードディスクから読み出したり書き込んだりするためのハードディスクドライブ２７、取外し可能磁気ディスク２９から読み出したり書き込んだりするための磁気ディスクドライブ２８、および、ＣＤ−ＲＯＭまたは他の光媒体など、取外し可能光ディスク３１から読み出したり書き込んだりするための光ディスクドライブ３０を含む場合がある。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０はそれぞれ、ハードディスクドライブインタフェース３２、磁気ディスクドライブインタフェース３３、および光ドライブインタフェース３４によってそれぞれシステムバス２３に接続されている。ドライブとその関連付けられたコンピュータ読み取り可能媒体は、パーソナルコンピュータ２０のためにコンピュータ読み取り可能命令、データ構造、プログラムモジュールおよびほかのデータの、不揮発性の格納を提供する。ここに説明された例としての環境は、ハードディスク、取外し可能磁気ディスク２９および取外し可能光ディスク３１を使用しているが、当業者であれば磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）などの、コンピュータによってアクセス可能なデータを格納できる他のタイプのコンピュータ読み取り可能媒体も例としての動作環境内で使用できることが理解されるであろう。

オペレーティングシステム３５（好ましくはＷｉｎｄｏｗｓＮＴ）、１つまたは２つ以上のアプリケーションプログラム３６、ほかのプログラムモジュール３７およびプログラムデータ３８を含むいくつかのプログラムモジュールがハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５に格納できる。ユーザは、キーボード４０およびポインティングデバイス４２などの入力デバイスを介してパーソナルコンピュータ２０にコマンドおよび情報を入力できる。他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどを含む。これらおよび他の入力デバイスはしばしば、システムバスに結合されたシリアルポートインタフェース４６を介して処理ユニット２１に接続されているが、パラレルポート、ゲームポートまたは汎用シリアルバス（ＵＳＢ）などの他のインタフェースによって接続されている場合もある。モニタ４７または他のタイプの表示デバイスもまた、ビデオアダプタ４８などのインタフェースを介してシステムバス２３に接続されている。モニタ４７の外に、パーソナルコンピュータは典型的にはスピーカおよびプリンタなどの他の周辺出力デバイス（図示せず）を含む。

パーソナルコンピュータ２０は、遠隔コンピュータ４９など１つまたは２つ以上の遠隔コンピュータへの論理接続を使用してネットワーク化された環境内で動作する場合がある。遠隔コンピュータ４９は、他のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードであり、典型的にはパーソナルコンピュータに関連して上記に説明された要素の多くまたはすべてを含むが、メモリ記憶デバイス５０のみが図１に示されている。図１に描かれた論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２を含む。このようなネットワーク化環境はオフィス、全社的コンピュータネットワーク、イントラネットおよびインターネットに普通に見られる。

パーソナルコンピュータ２０はＬＡＮネットワーク化環境内で使用されると、ネットワークインタフェースまたはアダプタ５３を介してローカルネットワーク５１に接続される。パーソナルコンピュータ２０はＷＡＮネットワーク化環境内で使用される場合、典型的にはモデム５４または他の手段を含み、インターネットなど広域ネットワーク５２上で通信を確立する。モデム５４は内部的である場合も外部的である場合もあるが、シリアルポートインタフェース４６を介してシステムバス２３に接続されている。ネットワーク化された環境では、パーソナルコンピュータ２０またはその一部に関して描かれたプログラムモジュールは、遠隔のメモリ記憶デバイス内に格納される場合がある。示されたネットワーク接続は例としてのものであって、コンピュータの間で通信リンクを確立する他の手段も使用できることが明らかであろう。

一般的なセキュリティモデル
本発明の好ましいセキュリティモデルは、ＷｉｎｄｏｗｓＮＴセキュリティモデルに関して説明される。しかし、本発明をＷｉｎｄｏｗｓＮＴオペレーティングシステムに限定する意図はなく、逆に、本発明はオペレーティングシステムのレベルでセキュリティチェックを実行する任意のメカニズムで動作し、利益を提供することを目的としている。さらに、本発明はスレッドごとのベースでソフトウェア障害の隔離で使用するか、または制限が現在実行されているクラスのスタックから決定されるバーチャルマシンで使用することもできる。さらに、本発明は必ずしもカーネルモードの動作に依存するわけではなく、ソフトウェア障害の隔離またはバーチャルマシンのように、ユーザモードで実現することもできる。

一般に、ＷｉｎｄｏｗｓＮＴオペレーティングシステムでは、ユーザはプロセス（およびそのスレッド）を介してシステムのリソースにアクセスすることによってタスクを実行する。簡単に説明するために、プロセスおよびそのスレッドは概念上等価と見なされ、以後は簡単にプロセスと呼ぶ。また、ＷｉｎｄｏｗｓＮＴ内ではオブジェクトによって表される、ファイル、共有メモリおよび物理デバイスを含むシステムのリソースは、本明細書では通常リソースまたはオブジェクトと呼ばれる。

ユーザがＷｉｎｄｏｗｓＮＴオペレーティングシステムにログオンし認証されると、セキュリティコンテキストがそのユーザのためにセットアップされ、この中にはアクセストークン６０の構築も含まれる。図２の左側に示すように、従来のユーザベースのアクセストークン６０は、ＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド６２を含む。ＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド６２は、セキュリティ識別子、すなわち、ユーザの証明およびそのユーザが属するグループ（たとえば編成内のグループ）を識別する１つまたは２つ以上のグループＩＤ６６に基づいたセキュリティ識別子（セキュリティＩＤまたはＳＩＤ）を含む。トークン６０はまた、そのユーザに割り当てられた任意の権限を一覧する権限フィールド６８を含む。たとえば、このような権限の１つは、管理レベルのユーザに、特定のアプリケーションプログラミングインタフェース（ＡＰＩ）を介してシステムクロックを設定する能力を与える場合がある。権限は、アクセス制御チェック、これは次に説明されるが、権限がない場合にオブジェクトへのアクセスを許可する前に実行されるアクセス制御チェックに優先することに注意されたい。

次に詳細に説明され、図３に一般に示されるように、オブジェクト７２へのアクセスを所望するプロセス７０は、所望するアクセスのタイプを指定し（たとえばファイルオブジェクトへの読取り／書き込みアクセスを得るなど）、および、カーネルレベルでは関連付けられたトークン６０をオブジェクトマネジャー７４に提供する。オブジェクト７２はそれに関連付けられたカーネルレベルのセキュリティ記述子７６を有し、オブジェクトマネジャー７４はセキュリティ記述子７６およびトークン６０をセキュリティメカニズム７８に提供する。セキュリティ記述子７６の内容は、典型的にはオブジェクトの所有者（たとえば制作者）によって決定され、一般に（任意の）アクセス制御エントリーのアクセス制御リスト（ＡＣＬ）８０を含み、各エントリーについて、そのエントリーに対応する１つまたは２つ以上のアクセス権（許可されたアクションまたは拒否されたアクション）を含む。各エントリーはタイプ（拒否または許可）インジケータ、フラグ、セキュリティ識別子（ＳＩＤ）およびアクセス権をビットマスクの形で含み、各ビットは許可に対応する（たとえば、１つのビットは読取りアクセス、１つのビットは書込みアクセス、など）。セキュリティメカニズム７８はトークン６０内のセキュリティＩＤおよびプロセス７０によって要求されたアクション（複数可）のタイプをＡＣＬ８０内のエントリーと比較する。許可されたユーザまたはグループの一致が発見され、所望のアクセスのタイプがそのユーザまたはグループに対して許可可能な場合、オブジェクト７２へのハンドルはプロセス７０に戻されるが、その他の場合はアクセスは拒否される。

例として、ユーザを「会計（Accounting）」グループのメンバーとして識別するトークンを持つユーザが読取りおよび書込みアクセスで特定のファイルオブジェクトにアクセスしたいとする。ファイルオブジェクトが、ＡＣＬ８０のエントリー内で許可されたタイプの「会計」グループ識別子を有し、そのグループが読取りおよび書き込みアクセスを使用可能にする権利を有する場合、読取りおよび書込みアクセスを許可するハンドルは戻されるが、その他の場合はアクセスは拒否される。効率上の理由から、セキュリティチェックはプロセス７０がまずオブジェクト７２にアクセス（作成または開く）しようと試みた時のみ実行され、したがってそのオブジェクトに対するハンドルはそれを介して実行できるアクションを制限するように、アクセス情報のタイプを格納することに注意されたい。

セキュリティ識別子７６はまた、システムＡＣＬまたはＳＡＣＬ８１を含み、これは監査されるべきクライアントアクションに対応するタイプ監査のエントリーを含む。各エントリー内のフラグは監査が成功したオペレーションまたは失敗したオペレーションのどちらを監視するかを示し、エントリー内のビットマスクは監査されるべきオペレーションのタイプを示す。エントリー内のセキュリティＩＤは、監査されるユーザまたはグループを示す。たとえば、ファイルオブジェクトへの書込みアクセスを有しないグループのメンバーがそのファイルに書き込もうと試みた場合いつでも決定できるように特定のグループが監査される状況を考えてみる。そのファイルオブジェクトに関するＳＡＣＬ８１は、その中にグループセキュリティ識別子と、適切に設定された失敗フラグおよび書込みアクセスビットを有する監査エントリーを含む。その特定のグループに属するクライアントがそのファイルオブジェクトに書き込みしようとして失敗するといつでも、そのオペレーションは記録される。

ＡＣＬ８０は、（すべての権利または選択された権利に関して）グループユーザにアクセスを許可する識別子ではなくて、グループユーザのアクセスを拒否するためにマークされる、１つまたは２つ以上の識別子を含む場合があることに注意されたい。たとえば、ＡＣＬ８０内にリストされた１つのエントリーは、他の場合に、「グループ₃」のメンバーにオブジェクト７２へのアクセスを許可するが、ＡＣＬ８０内の他のエントリーは特に、「グループ₂₄」のすべてのアクセスを拒否する場合がある。トークン６０が「グループ₂₄」セキュリティＩＤを含んでいる場合、アクセスは「グループ₃」のセキュリティＩＤの存在にかかわらず拒否されることになる。もちろん、セキュリティチェックが正しく機能するために、セキュリティチェックは、”グループ₃”エントリーを介したアクセスを許可しないようにアレンジされ、その後に、すべてのＤＥＮＹ（拒否）エントリーをＡＣＬ８０の前面に置くなどによって、グループ₂₄エントリーの「ＤＥＮＹＡＬＬ（すべて拒否）」状態をチェックする。この構成（ａｒｒａｎｇｅｍｅｎｔ）は、グループの残りのメンバーの各々を個別にリストしてそのアクセスを許可する必要なく、グループの、１人または２人以上の分離したメンバーを個別にＡＣＬ８０内で排除できるので、向上した効率を提供することが明らかであろう。

アクセスのタイプを指定する代わりに、コーラ−（ｃａｌｌｅｒ）はＭＡＸＩＭＵＭ＿ＡＬＬＯＷＥＤアクセスを要求することもでき、これによって、１つのアルゴリズムが通常のＵｓｅｒＡｎｄＧｒｏｕｐｓリスト対ＡＣＬ８０内の各々のエントリーに基づいて、許可される最大のアクセスタイプを決定することに注意されたい。より詳しくは、アルゴリズムは所与のユーザのための権利を蓄積している識別子のリストをウォークダウンする（すなわち、種々のビットマスクをＯＲする）。権利が一度蓄積されると、ユーザに蓄積された権利が与えられる。しかし、ウォークスルーの間にユーザ識別子またはグループ識別子および要求された権利に一致する拒否エントリーが発見されると、アクセスは拒否される。

制限付きのトークン
制限付きのトークンは次のように、既存のアクセストークン（制限付きまたは制限なし）から作成される。また次に説明するように、制限付きトークンが任意の制限付きセキュリティＩＤを含む場合、そのトークンは追加のアクセスチェックを受け、その中で制限付きセキュリティＩＤはオブジェクトのＡＣＬ内のエントリーと比較される。

制限付きトークンの主な用途は、プロセスに、それ自体のトークンの制限付きのバージョンを持つ新しいプロセスを作成させることである。制限付きのプロセスはついで、リソースに関して実行できるアクションにおいて制限される。たとえば、ファイルオブジェクトリソースは、関連付けられた制限付きトークンの中に同じマイクロソフトワード制限付きＳＩＤを有する制限付きプロセスのみがそのファイルオブジェクトにアクセスできるように、単一の制限付きＳＩＤ、すなわち、マイクロソフトワードのアプリケーションプログラムを識別する単一の制限付きＳＩＤをそのＡＣＬの中に有する場合がある。オリジナルユーザはさらにオブジェクトにアクセスする必要があるので、ＡＣＬもまた、ユーザアクセスおよびマイクロソフトワードプログラムを許可するアクセス制御エントリーを含む必要があることに注意されたい。そのため、たとえば、ブラウザを介してダウンロードされたコードなど、信用できないコードは、制限付きプロセス内で実行される。制限付きプロセスは、制限付きトークン内にマイクロソフトワード制限付きセキュリティＩＤを有しない（不正である可能性のある）コードがファイルオブジェクトへアクセスすることを防ぐ。

セキュリティ上の理由から、異なるトークンを伴うプロセスの作成は通常、ＳｅＡｓｓｉｇｎＰｒｉｍａｒｙＴｏｋｅｎ権限として知られる権限を必要とする。しかし、プロセスが制限付きトークンと関連付けられるようにするために、制限付きトークンが主トークンから導出されている場合に、プロセス管理は別のプロセスへの十分なアクセスを持つ１つのプロセスが、その主トークンを制限付きトークンに変更できるようにする。新しいプロセスのトークンのＰａｒｅｎｔＴｏｋｅｎＩｄを既存のプロセスのトークンのＴｏｋｅｎＩｄと比較することによって、オペレーティングシステム３５はプロセスがそれ自体の制限付きバージョンを作成しているだけであることを確認する。

制限付きトークン８４は親トークンより少ないアクセスしか有せず、ユーザ情報またはグループ情報のみに基づいてアクセスを許可または拒否するのみでなく、そのオブジェクトにアクセスしようと試みるプロセスのタイプ（またユーザまたはグループ）に基づいてオブジェクトへのアクセスを防止することなどが可能である。制限付きのトークンはまた、親トークンがこれらのＳＩＤを介してアクセスを許可している場合でも、「ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹ」と特にマークされた１人または２人以上のユーザまたはグループのセキュリティＩＤを介したアクセスを許可しない場合もあり、および／または、親トークンに存在する権限を削除してしまう場合もある。

したがって、アクセスを削減する１つの方法は、制限付きトークン内の１つまたは２つ以上のユーザセキュリティ識別子および／またはグループのセキュリティ識別子の属性を変更して、アクセスを許可するのではなくアクセスを許可できないようにすることである。ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされたセキュリティＩＤは、アクセスを許可する目的のためには効果的に無視されるが、そのセキュリティＩＤに関して「ＤＥＮＹ（拒否）」エントリーを有するＡＣＬは依然としてアクセスが拒否される。例として、制限付きトークン８４（図３）内のグループ₂のセキュリティＩＤが、ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされている場合、ユーザのプロセスがグループ₂を許可されたものとしてリストしているＡＣＬ８０を有するオブジェクト７２にアクセスしようと試みた時、このエントリーは効果的に無視され、プロセスは他のなんらかのセキュリティＩＤによってアクセスを得なければならないことになる。しかし、ＡＣＬ８０が要求されたタイプのアクションに関して、グループ₂をＤＥＮＹとリストしたエントリーを含んでいる場合、１度テストされると、他のセキュリティＩＤにかかわらずアクセスは許可されない。

セキュリティＩＤはいくつかのオブジェクトのＡＣＬの中で「ＤＥＮＹ」としてマークされている可能性があり、それによってその識別子を削除するとこれらのオブジェクトへのアクセスを拒否するのではなく許可することになってしまうため、ユーザのトークンからセキュリティＩＤをただ除去するだけではオブジェクトへのアクセスは安全に削減できないことに注意されたい。したがって、本発明は制限付きのトークン内でＳＩＤの属性がＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹに変更できるようにする。さらに、このＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹセキュリティチェックをオフにするためのメカニズムは提供されていない。

制限付きトークン内でアクセスを削除する別の方法は、親トークンに関して１つまたは２つ以上の権限を削除することである。たとえば、管理権限を伴う通常のトークンを有するユーザは、そのユーザが特にシステムに別の情報を与えなければ、そのユーザのプロセスが権限のない制限付きトークンで実行するようにシステムを設定する場合がある。これはユーザが管理者の範囲内で意図的に行動していない時に発生する可能性のある、偶然のエラーを防ぐことを理解されたい。同様に、プログラムがユーザの権限に応じて異なるモードで実行するように開発され、これによって管理レベルのユーザはあるオペレーションを実行するために管理権限でプログラムを実行しなければならないが、より基本的なオペレーションを実行するためには低減された権限でオペレーションを実行しなければならない場合がある。ここで再び、これはこのようなユーザが通常のオペレーションを実行しようとしているだけなのに、高められた権限で実行している時に生じる可能性のある深刻なエラーを防ぐのに役立つ。

トークンのアクセスを低減するさらに別の方法は、そこに制限付きのセキュリティＩＤを追加することである。制限付きのセキュリティＩＤは、プロセス、リソースオペレーションなどを表す数であり、ＧＵＩＤへ接頭辞を追加するかまたは暗号ハッシュなどを介して生成された数字を追加するなどによってユニークになっており、これらのセキュリティＩＤを他のセキュリティＩＤから区別する情報を含む場合もある。本発明に必ず必要ではないが便利のために、ＧＵＩＤをセキュリティＩＤに変換したり、セキュリティＩＤを人間が読み取り可能な形態で表示したりなど、アプリケーションおよびユーザをセキュリティＩＤにインタフェースさせるための種々のアプリケーションプログラミングインタフェース（ＡＰＩ）が提供される。

アプリケーション（プロセス）要求アクセスに基づいてリソースへのアクセスを制限することに加えて、同様にリソースの制限付き使用に基づいて特定のセキュリティＩＤを開発する場合もある。例として、「ＵＳＥ＿ＷＩＮＤＯＷＳ」などのセキュリティＩＤは、ウィンドウステーションおよびデスクトップのデフォルトのＡＣＬに置かれ、制限付きトークンの中に対応するＳＩＤを有するプロセスによってのみアクセスを許可する場合がある。同様に、プリンタオブジェクトのデフォルトＡＣＬは、そのデフォルトのＡＣＬの中に「ＵＳＥ＿ＰＲＩＮＴＩＮＧ」ＳＩＤを含み、プロセスが制限付きトークンの中でリストされたこのセキュリティＩＤのみを伴う制限付きプロセスを作成し、これによって制限付きプロセスはプリンタにはアクセスできるが他のリソースにはアクセスできないようにする場合もある。他のリソースにアクセスするために、多くの他のセキュリティＩＤも実現できることが理解されるであろう。

図３に示すように、制限付きセキュリティＩＤは、制限付きトークン８４の特別なフィールド８２内に置かれ、アクションを要求しているプロセスを識別することなどを行う。以下にさらに詳細に説明するように、少なくとも１つのユーザ（またはグループ）セキュリティＩＤおよび少なくとも１つの制限付きセキュリティＩＤの両方についてオブジェクトへのアクセスを許可するように要求することによって、オブジェクトは要求側プロセス（またユーザまたはグループ）に基づいて選択的にアクセスを許可できる。たとえば、ファイルオブジェクトなどのオブジェクトは、マイクロソフトワード、マイクロソフトエクセルまたはＷｉｎｄｏｗｓエクスプローラのプロセスがそれにアクセスすることを許可するが、他のプロセスへのアクセスを拒否する場合がある。さらに、許可されたプロセスの各々は、異なるアクセス権が与えられる場合もある。

この設計は、ユーザのコンテキスト内で異なるプロセスが実行することを制御するための、大きな融通性と細分性を提供する。これらの機能に関する１つの期待される使用モデルは、信頼できるアプリケーションと信頼できないアプリケーションとの区別を含む。「アプリケーション」は、所与のセキュリティコンテキストの下で「ユーザモード」で実行できる任意のコードの一部分を記述するための、一般的な意味で使用されることに注意されたい。たとえば、マイクロソフトワードなどのアプリケーションはＡｃｔｉｖｅＸ制御からのプロセスとして実行され、ＡｃｔｉｖｅＸは既存のプロセス内にロードされ実行される場合がある。マイクロソフトのインターネットエクスプローラなどの他のアプリケーションを起動するアプリケーションは、このインフラストラクチャを使用した「信頼モデル」を導入する可能性がある。

例として、インターネットエクスプローラなどのアプリケーションは制限付きトークンを使用して異なるプロセスの下で信頼できない実行可能なコードを実行し、これらのプロセスがユーザの全体的なアクセス権および権限の中で行うことを制御できる。この目的のために、インターネットエクスプローラアプリケーションは、それ自体のトークンから制限付きトークンを作成し、どの制限付きセキュリティＩＤを制限付きトークン内に置くかを決定する。ついで、信頼できない実行可能コードは制限付きのコンテキストがアクセスできるオブジェクトにのみアクセスするように制限される。

さらに、制限付きＳＩＤおよび他の制限に対応するエントリーは、監査目的のためにＳＡＣＬ８１のフィールドに置くことができる。たとえば、リソースのＳＡＣＬは、インターネットエクスプローラプログラムがそのリソースの読取りまたは書込みアクセスを試みるたびに、および／またはＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされたＳＩＤの使用が監査される場合にはいつでも監査するように設定することができる。単純化のために、監査はこのあと詳細に説明しないが、制限付きＳＩＤを介したアクセス制御に関して説明されたコンセプトは監査動作にも適用可能であることは容易に理解されるであろう。

既存のトークンから制限付きトークンを作成するために、ＮｔＦｉｌｔｅｒＴｏｋｅｎと名付けられたアプリケーションプログラミングインタフェース（ＡＰＩ）が提供され、その内容は次のとおりである。

ＮｔＦｉｌｔｅｒＴｏｋｅｎＡＰＩは、ＣｒｅａｔｅＲｅｓｔｒｉｃｔｅｄＴｏｋｅｎと名付けられたＷｉｎ３２ＡＰＩの下でラップされ、ＣｒｅａｔｅＲｅｓｔｒｉｃｔｅｄＴｏｋｅｎの内容は次のとおりである。

図２および図４〜５に表示されたように、これらのＡＰＩ８６は共同して機能し、制限付きでも制限なしでも既存のトークン６０をとり、変更された（制限付き）トークン８４をそこから作成する。ログオンしたユーザのインスタンスに関する識別情報を含む制限付きトークンの構造は、ＰａｒｅｎｔＴｏｋｅｎＩｄ，ＲｅｓｔｒｉｃｔｅｄＳｉｄＣｏｕｎｔ、およびＲｅｓｔｒｉｃｔｅｄＳｉｄｓの３つの新しいフィールドを含む（次の表で太字で示されている）。

通常の（制限なしの）トークンがＣｒｅａｔｅＴｏｋｅｎＡＰＩを介して作成される時、ＲｅｓｔｒｉｃｔｅｄＳｉｄｓフィールドもＰａｒｅｎｔＴｏｋｅｎＩｄフィールドも空であることに注意されたい。

制限付きトークン８４を作成するために、このプロセスは適切なフラグ設定および／または入力フィールド中の情報を伴うＣｒｅａｔｅＲｅｓｔｒｉｃｔｅｄＴｏｋｅｎＡＰＩを呼び出し、これはＮｔＦｉｌｔｅｒＴｏｋｅｎＡＰＩを順番に起動する。図４のステップ４００の初めに示すように、ＮｔＦｉｌｔｅｒＴｏｋｅｎＡＰＩは、ＤＩＳＡＢＬＥ＿ＭＡＸ＿ＳＩＤＳと名付けられたフラグが設定されているかどうかをチェックする。このフラグは新しい、制限付きトークン８４の中にあるグループに関してすべてのセキュリティＩＤがＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされていなければならないことを示す。このフラグは、各々のグループを個別に識別する必要なく、トークン内のグループ（多くのグループである可能性がある）を制限するための便利な方法を提供する。フラグが設定されている場合、ステップ４００はステップ４０２に分岐し、ステップ４０２では新しいトークン８４内のグループセキュリティＩＤの各々について、ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹを示すビットを設定する。

ＤＩＳＡＢＬＥ＿ＭＡＸ＿ＳＩＤＳフラグが設定されていない場合、ステップ４００はステップ４０４に分岐し、ＮｔＦｉｌｔｅｒＴｏｋｅｎＡＰＩのＳｉｄｓＴｏＤｉｓａｂｌｅフィールド内にセキュリティＩＤが個別にリストされているかどうかをテストする。図４のステップ４０４で示されたように、オプションのＳｉｄｓＴｏＤｉｓａｂｌｅ入力フィールドが存在する時、ステップ４０６では、そこにリストされ、また、親トークン６０のＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド６２内にも存在する任意のセキュリティＩＤは、新しい制限付きトークン８４のＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド８８内でＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとして個別にマークされる。上記のようにこのようなセキュリティＩＤは、アクセスを拒否するためにのみ使用でき、アクセスを許可するためには使用できず、さらに、あとから削除または使用可能にはできない。したがって、図２に示された例では、グループ₂のセキュリティＩＤは、ＮｔＦｉｌｔｅｒＴｏｋｅｎＡＰＩ８６のＳｉｄｓＴｏＤｉｓａｂｌｅ入力フィールド内にグループ₂セキュリティＩＤを指定することにより、制限付きトークン８４内でＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとしてマークされる。

フィルタプロセスはついで図４のステップ４１０に続き、ここではＤＩＳＡＢＬＥ＿ＭＡＸ＿ＰＲＩＶＩＬＥＤＧＥＳと名付けられたフラグがテストされる。このフラグは同様に、新しい、制限付きトークン８４内のすべての権限を削除すべきであることを示す、便利なショートカットとして設定できる。このように設定された場合、ステップ４１０はステップ４１２に分岐し、ステップ４１２では新しいトークン８４からすべての権限が削除される。

フラグが設定されていない場合、ステップ４１０はステップ４１４に分岐し、ここではオプションのＰｒｉｖｉｌｅｇｅｓＴｏＤｅｌｅｔｅフィールドが確認される。ＮｔＦｉｌｔｅｒＴｏｋｅｎＡＰＩ８６が呼ばれた時に存在する場合は、ステップ４１６で、この入力フィールドにリストされまた既存のトークン６０の権限フィールド６８にも存在する任意の権限は、新しいトークン８４の権限フィールド９０から個別に削除される。図２に示された例では、「権限₂」から「権限_m」として示された権限は、ＮｔＦｉｌｔｅｒＴｏｋｅｎＡＰＩ８６のＰｒｉｖｉｌｅｇｅｓＴｏＤｅｌｅｔｅ入力フィールド内にこれらの権限を指定することによって、新しいトークン８４の権限フィールド９０から削除されている。上記のように本発明の１つの態様によれば、これは、トークン内で使用可能な権限を削減する機能を提供する。このプロセスは図５のステップ４２０に続く。

制限付きトークン８４を作成する時に、ステップ４２０でＲｅｓｔｒｉｃｔｉｎｇＳｉｄｓ入力フィールド内にＳＩＤが存在していた場合、親トークンが通常のトークンか、または親トークン自体が制限付きＳＩＤを有する制限付きトークンであるかどうかに関して決定が行われる。ＡＰＩ、ＩｓＴｏｋｅｎＲｅｓｔｒｉｃｔｅｄがステップ４２２で呼び出され、親トークンのＲｅｓｔｒｉｃｔｉｎｇＳｉｄｓフィールドを（ＮｔＱｕｅｒｙＩｎｆｏｒｍａｔｉｏｎＴｏｋｅｎＡＰＩを介して）照会してこれがＮＵＬＬでないかどうかを確認することによってこの問題を解決し、ここでＮＵＬＬでなかった場合、親トークンは制限付きトークンであり、ＡＰＩはＴＲＵＥ（真）を戻す。テストが満足できなかった場合、親トークンは通常のトークンでありＡＰＩはＦＡＬＳＥ（偽）を戻す。続くステップ４２６または４２８のために、トークン自体は制限付きであるが制限付きＳＩＤを有しない親トークン（すなわち、権限が削除されているかおよび／またはＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹＳＩＤｓである場合）は、制限付きでないとして処理される可能性があることに注意されたい。

ステップ４２４では、親トークンが制限付きである場合、ステップ４２４はステップ４２６に分岐し、ステップ４２６では、親トークンの制限付きセキュリティＩＤフィールドと、ＡＰＩの制限付きセキュリティＩＤ入力リストの両方にある任意のセキュリティＩＤは、新しいトークン８４の制限付きセキュリティＩＤフィールド９２に置かれる。制限付きセキュリティＩＤが両方のリストになければならないため、制限付き実行コンテキストが、制限付きセキュリティＩＤフィールド９２にさらなるセキュリティＩＤを追加することを阻止し、この場合、アクセスを減らすのではなく効果的にアクセスを増やすことになる。同様に、ステップ４２６で共通なセキュリティＩＤがなかった場合、少なくとも１つの制限付きＳＩＤを新しいトークン内の元のトークンから取り去るなどによって、作成された任意のトークンはそのアクセスを増やすことなく制限されなければならない。その他の場合は、新しいトークン内の空の制限付きＳＩＤフィールドはそのトークンが制限されていないことを示し、この場合、アクセスを減らすのではなく効果的にアクセスを増やすことになる。

あるいは、ステップ４２４で親トークンが通常のトークンであると判断された場合、ステップ４２８で新しいトークン８４のＲｅｓｔｒｉｃｔｉｎｇＳｉｄｓフィールド９２は入力フィールド内にリストされたものに設定される。これはセキュリティＩＤを追加するが、次に詳細に説明されるように制限付きＳＩＤを有するトークンが第２のアクセステストを受けるため、アクセスは実際には減らされることに注意されたい。

最後に、ステップ４３０も実行され、ここで新しいトークン８４内のＰａｒｅｎｔＴｏｋｅｎＩｄ９３は既存の（親）トークンのＴｏｋｅｎＩｄに設定される。これはオペレーティングシステムに、通常は親トークン以外には許可されていない場所で、そのトークンの制限付きのバージョンを使用するプロセスをのちに許可するオプションを提供する。

特に図６〜８を参照して本発明の動作の説明に戻ると、図６に表示されたように、制限付きプロセス９４が作成され、読取り／書込みアクセスでファイルオブジェクト７０を開こうと試みている。オブジェクト７２のセキュリティ記述子内では、ＡＣＬ８０はそこにリストされた多くのセキュリティＩＤおよび、各ＩＤに関して許可されたタイプのアクセスを有し、ここで「ＲＯ」は読取りのみのアクセスが許可されていることを示し、「ＷＲ」は読取り／書込みアクセスを示し、「ＳＹＮＣ」は同期化アクセスが許可されていることを示す。他の場合は「ＸＪｏｎｅｓ」が許可されたグループ内のメンバーシップを介してアクセスを許可されている場合でも、「ＸＪｏｎｅｓ」は特にオブジェクト７２へのアクセスを拒否されていることに注意されたい。さらに、関連付けられたこのトークン８４を有するプロセス９４は、このエントリーは「ＤＥＮＹ」（すなわち、ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹ）とマークされているため、トークン８４内の「バスケットボール」セキュリティＩＤを介して任意のオブジェクトへのアクセスを許可されないことになる。

セキュリティの目的のために、制限付きセキュリティコンテキストは第一に、ＷｉｎｄｏｗｓＮＴカーネル内で実現される。オブジェクト７２にアクセスしようと試みるために、プロセス９４はオブジェクトマネジャー７４に、アクセスが望ましいオブジェクトを識別する情報および、所望されるアクセスのタイプを提供する（図８、ステップ８００）。オブジェクトマネジャー７４はこれに応答して、ステップ８０２に示されたように、セキュリティメカニズム７８と共同して機能し、トークン８４内にリストされた（プロセス９４と関連付けられている）ユーザセキュリティＩＤおよびグループセキュリティＩＤをＡＣＬ８０内のエントリーに対して比較し、所望のアクセスが許可されるべきか拒否されるべきかを決定する。

ステップ８０４で一般に示されているように、アクセスがリストされたユーザまたはグループに関して許可されていない場合、セキュリティチェックはステップ８１４でアクセスを拒否する。しかし、ステップ８０４でアクセスチェックのユーザ部分およびグループ部分の結果が許可可能なアクセスを示した場合には、セキュリティプロセスはステップ８０６に分岐し、制限付きトークン８４が任意の制限付きセキュリティＩＤを有しているかどうかを決定する。有していない場合、追加の制限はなく、ここでアクセスチェックは完了し、ステップ８１２において、ユーザアクセスおよびグループアクセスのみに基づいてアクセスは許可される（そのオブジェクトへのハンドルが戻される）。このようにして、通常のトークンは本質的に以前と同じようにチェックされる。しかし、ステップ８０６によって決定されたように、トークンが制限付きセキュリティＩＤを含んでいる場合、ついでステップ８０８によって、制限付きセキュリティＩＤをＡＣＬ８０内のエントリーと比較することによって、第２のアクセスチェックが実行される。ステップ８１０でこの第２のアクセステストがアクセスを許可した場合、そのオブジェクトへのアクセスはステップ８１２で許可される。そうでない場合、アクセスはステップ８１４で拒否される。

図７で論理的に示すように、トークン８４の中に制限付きセキュリティＩＤが存在する時はいつでも、２つの部分からなるテストがこのように実行される。トークン８４内のセキュリティＩＤおよび所望のアクセスビット９６をオブジェクト７２のセキュリティ記述子に対して考慮することによって、通常のアクセステスト（ビットごとのＡＮＤ）および制限付きセキュリティＩＤのアクセステストの両方は、プロセスがそのオブジェクトへのアクセスを許可されるようにアクセスを許可しなければならない。本発明に必要ではないが上記のように、通常のアクセステストが最初に行われ、アクセスが拒否された場合には、さらなるテストは必要ではない。トークン内にＡＣＬの識別子に一致するセキュリティＩＤがないため、またはＡＣＬエントリーが特に、その中にあるセキュリティ識別子に基づいてトークンへのアクセスを拒否したためのどちらの理由でも、アクセスは拒否されることに注意されたい。

このように図６に示された例では、トークン８４（フィールド９２）内の制限付きＳＩＤのみが「インターネットエクスプローラ」を識別する一方、オブジェクトのＡＣＬ８０内には対応する制限付きＳＩＤがないため、図６に示された例では、オブジェクト７２へのアクセスはプロセス９４へは許可されない。ユーザは通常のトークンで実行するプロセスを介してオブジェクトへアクセスする権利を有していたが、プロセス９４はＡＣＬ内に「インターネットエクスプローラ」ＳＩＤ（非ＤＥＮＹ）を有するオブジェクトのみにアクセスできるようにするように、制限された。

アクセスのタイプを指定する代わりに、コーラ−が、指定されたＭＡＸＩＭＵＭ＿ＡＬＬＯＷＥＤアクセスを有する場合、これによって上記のように、アルゴリズムは最大のアクセスを決定するＡＣＬ８０をウォークスルーする。制限付きトークンで、１つでも任意のタイプのユーザアクセスまたはグループアクセスが許可された場合、ユーザおよびグループの実行に続いて許可可能なアクセス権のタイプ（複数可）は、第２の実行に関して所望のアクセスとして指定され、第２の実行はＲｅｓｔｒｉｃｔｅｄＳｉｄｓリストをチェックする。このようにして、制限付きトークンは通常のアクセスより少ないかまたは等しいアクセスを許可されることが確認される。

最後に、本発明のセキュリティモデルは、他のセキュリティモデルと共に使用できることに注意されたい。たとえば、オペレーティングシステムの上に常駐する、機能に基づいたセキュリティモデルは、本発明のオペレーティングシステムレベルのセキュリティモデルの上で使用することができる。

ジョブ
ジョブとは一組の編成化されたプロセスをその中に有するカーネルオブジェクトであり、各ジョブはそれに関連付けられた異なるタイプの制限を有する可能性がある。本発明によれば、制限付きトークンはＷｉｎｄｏｗｓＮＴジョブオブジェクトに統合され、同じ制限の下に実行される多数のプロセスの管理を可能にできる。ジョブオブジェクト制限は次のように表される。

ここで、関連するＳｅｃｕｒｉｔｙＬｉｍｉｔＦｌａｇｓは、次のように表される。

これらの種々の情報の部分は、ＮｔＳｅｔＩｎｆｏｒｍａｔｉｏｎＪｏｂＯｂｊｅｃｔＡＰＩを使用してジョブオブジェクト上で定でき、一方、プロセスはＮｔＡｓｓｉｇｎＰｒｏｃｅｓｓＴｏＪｏｂＯｂｊｅｃｔＡＰＩを使用してジョブに割り当てられる。ジョブ上で定されたセキュリティ制限は、プロセスが割り当てられた時に実施される。ジョブを制限するために、ＪＯＢ＿ＯＢＪＥＣＴ＿ＳＥＣＵＲＩＴＹ＿ＦＩＬＴＥＲ＿ＴＯＫＥＮＳ制限フラグが設定され、これによって、ジョブに割り当てられているプロセスの主トークンは、セキュリティ制限情報内に提供されているＳｉｄｓＴｏＤｉｓａｂｌｅ、ＰｒｉｖｉｌｅｇｅｓＴｏＤｅｌｅｔｅおよびＲｅｓｔｒｉｃｔｅｄＳｉｄｓ情報を使用して、プロセスに関連付けられたトークンが上記のようにフィルタ処理されるのと同じ方法でフィルタ処理される。

図９に示されたように、ジョブ１１０は、ジョブＮｔＡｓｓｉｇｎＰｒｏｃｅｓｓＴｏＪｏｂＯｂｊｅｃｔＡＰＩを介してそこに割り当てられた多くのプロセス（たとえばプロセス１１２〜１１４）を有する。各プロセス１１２〜１１４は、そこに関連付けられた各トークン１１６_a〜１１６_cを有し、これは「制限Ｒ」として示されたその制限に関して同じである。たとえば、これらがその下で実行されるトークン１１６_a〜１１６_cが所定のセキュリティＩＤ（たとえば管理者（Administrator）ＳＩＤ）を使用不可にしており、一定の権限が削除され、および／または一組の制限付きセキュリティＩＤが追加されているため、ジョブオブジェクト１１０はその中にあるプロセス１１２〜１１４を制限し、所定の動作のみを行う。トークンは他のアクセス権に関しては同じであるため、この場合すべてのトークンは本質的に同じであるが、これは必要ではないことに注意されたい。プロセス（たとえばプロセス１１４）が他のプロセス１１８を生成した場合、同じ制限Ｒがそのトークン１１６_dを介して新しいプロセス１１８に関連付けられていることをジョブオブジェクト１１０が確認するため、そのプロセス１１８は同じ制限Ｒを伴うジョブ１１０内で実行される。

信頼できないコンテントの実行
本発明の一態様によれば、制限付きトークンを使用して信頼できないコンテントを実行するための制限付きセキュリティコンテキストが設定される。典型的に信頼できないコンテントの１つのタイプは、インターネットのサイトからダウンロードされたコンテントである。このようなコンテントを制限するために、プロセスを（少なくとも）一般に制限付きトークンおよび他の制限と関連付けることによって、ブラウズされた各サイトを実行するための制限付きプロセスを設定できる。プロセスはジョブオブジェクトの中にもあり、これによって、サイトのプロセスによって作成された任意のプロセスが自動的に同じ制限を与えられる場合があることに注意されたい。ジョブオブジェクトの他の利点は、たとえば、プロセスがマシンをシャットダウンしたりまたはクリップボードのデータにアクセスできないように、ウィンドウ化動作も制限できることである。いずれの場合でも、ダイナミックＨＴＭＬ、Ｊａｖａ制御またはＡｃｔｉｖｅ−Ｘ制御を介するなどでサイトのコンテントが実行する任意のアクションはプロセス内で発生し、これによって、そのプロセスの制限を受ける。多数のフレームが同時に画面上のウィンドウ内に表示されても、フレームの実際のサイトソースにかかわらず、異なるフレームは異なるサイトとして処理されることに注意されたい。

例として図１０に示したように、インターネットエクスプローラなどブラウザ１３０を介してアクセスされた任意のコンテントは、その制限付きＳＩＤフィールド１３６内に「インターネットエクスプローラ」制限付きＳＩＤを含む制限付きトークン１３４を有するプロセス１３２内で実行できる。上記のように、これは、（アクセスが他の一致する制限付きＳＩＤを介していない限り）インターネットエクスプローラＳＩＤに対応する許可エントリーを有しない任意のリソースへのアクセスを自動的に防ぐ。したがって、たとえば、プロセス１３２がインターネットエクスプローラのウィンドウ内でＨＴＭＬページをレンダリングする場合もあるが、リソースのＡＣＬが特に、そのアクションを許可する対応する制限付きＳＩＤを伴うエントリーを含んでいない限り、それ以上の実行を制限できる。

ダウンロードされたインターネットコンテントを制限する別の方法は、サイト識別に基づいてリソースへのアクセスを制限することである。たとえば、各サイトは一意的なＵＲＬ（ユニフォームリソースロケータ）を有し、バイナリの証明ＩＤを有する場合がある。図１１に示されるように、ＵＲＬに基づいて制限するためには、ブラウザ１３０は、ＵＲＬ文字列を制限付きＳＩＤに変換するコンバータ１４０へサイトＵＲＬ１３８を渡す、識別メカニズムとして機能する。このようなメカニズムはＭＤ５などの１方向の暗号ハッシュを使用して文字列を１２８ビットのバイナリ値に変換し、このバイナリ値は、その番号がＳＩＤでありその番号が生成された方法を示すヘッダなどの少量の情報を追加することによって、制限付きＳＩＤになる。このようなＳＩＤは、非常に高い可能性で、別のＳＩＤに関して一意的である。バイナリ証明ＩＤがそのサイトに関して使用可能である場合は、その値を使用して制限付きＳＩＤが生成できることに注意されたい。いずれの場合でも図１０に示されたように、制限付きＳＩＤはそのサイトのために設定されたプロセス１３２に関連付けられた、制限付きトークン１３４の制限付きＳＩＤフィールド１３６内に置かれる。

さらに、制限はインターネットゾーン（サイトの集合）に基づく場合もある。たとえば図１１に示されたように、ユーザは特に信頼できるサイトのリストを含むゾーンと、特に信頼できないサイトのリストを含むゾーンを設定できる。信頼できるゾーンは１つの制限付きＳＩＤに対応し、信頼できないゾーンは別の制限付きＳＩＤに対応する。また、イントラネットサイトとインターネットサイトの間を区別するためにゾーンを設定することもできる。さらなる区別は、１つのタイプの証明などを有するインターネットサイトに関して、区別が行われる任意の細分性について行われる可能性がある。いずれの場合でも、ブラウザ１３０はサイトをゾーンにグループ分けする情報１３１へのアクセスを有し、これによってサイトのゾーンに対応する制限付きＳＩＤが生成され、制限付きトークン１３６内に置かれ、ＡＣＬに基づいたセキュリティチェックのためにそのゾーンをシステムリソースに対して識別する。

上記のように、制限付きＳＩＤがトークンの中に置かれると、セキュリティメカニズム７８はユーザおよびグループチェックでアクセス評価を実行し、次に（ユーザおよびグループテストがパスした場合）、制限付きＳＩＤのチェックが行われる。この結果、各リソースに関するＡＣＬは、信頼できないコードがその中に対応するエントリーがあるかないかによって処理される方法を決定する。たとえば、ファイルオブジェクトは読み出しアクセスを特に信頼できるサイトまたはゾーンに許可するが、任意の他のタイプのアクセスを許可しないか、どのサイトまたはゾーンについてもアクセスを許可しない場合がある。非常に機密のファイルは特に、なんらかの他の制限付きＳＩＤを介した任意のアクセスを防ぐために、「インターネットエクスプローラ」ＳＩＤを有する任意の制限付きトークンへのアクセスを否定する可能性がある。したがって、たとえば図１０に示されたように、リソースＡ（１４２）は、そのＡＣＬ１４４がプロセス１３２の制限付きトークン１３４内に、「Ｓｉｔｅ１．ｃｏｍ」制限付きＳＩＤに対応する「Ｓｉｔｅ１．ｃｏｍ」エントリーを含むため、プロセス１３２へ読み出しアクセスを許可する。しかし、リソースＢ（１４６）は対応するエントリーが存在しないため、アクセスを許可しない。

上記のメカニズムはアクセスを制限するように機能するが、リソースは、サイトまたはゾーンなど種々の区別に基づいて区別する細分性を欠いている場合があるため、ある種の困難が生じる。たとえば、特定のインターネットサイトに関して設定されたプロセスはそのサイトへのアクセスを必要とする場合がある。しかし、ウィンドウズソケットを処理するドライバ（ＡＦＤデバイスドライバ）は、ネットワーク化を許可または否定するように設定されたＡＣＬのいずれかを有するが、実際には各サイトまたはゾーンの間を区別できない。ネットワーク化をすべて否定すると、プロセスがそれ自体の対応するサイトへアクセスすることが妨げられるが、プロセスが任意のサイトへアクセスすることを許可すると、そのプロセスに他のサイトへのアクセスを許可し、クライアントに関する機密情報をもらす可能性がある。ネットワークアクセスを制限する理由は、通常はインターネットからアクセスできないファイルサーバ上の保護されていないファイルへのアクセスを防ぐこと、保護されていない内部のデータベースへのアクセスを防ぐこと、ネットワークリソースへの攻撃を防ぐこと（たとえば悪いパケットまたはＤＨＣＰ応答を介して）、およびネットワークに到達する他の可能性のある方法に関して情報の漏洩を防ぐことを含む。

一定のサイトへのプロセスを選択的に制限することによってこのジレンマを解消するために、本発明は、一般にはプロセスをネットワーク化から制限するが、そのサイトに関してネットワーク化を実行できる、信頼できるヘルパープロセスを使用する。ヘルパープロセスは、それによって決定されたように、制限付きプロセスが選択されたサイト（たとえば、「Ｍｉｃｒｏｓｏｆｔ．ｃｏｍ」で終わるすべてのサイト）のみにアクセスできるようにする程度にプロセスを制限する。具体的には、図１３に示されているように、制限付きプロセス１３２はウィンドウズソケットＡＦＤドライバ１５０（「Ｘ」によって表されている）への直接のアクセスを拒否されており、これによって、制限付きプロセス１３２はそれ自体も含め、任意のサイトに関してソケットハンドルを直接得ることはできない。デバイスドライバ１５０のＡＣＬ１５２を介して制限付きプロセスへのアクセスを拒否することにより、デバイスドライバ１５０は、直接カーネル内に呼ぶなど、他のなんらかの方法を介して、制限付きプロセス１３２によってアクセスできないことに注意されたい。しかし、信頼できるヘルパープロセス１５４は、それ自体の制限なしトークン１５６を介してドライバ１５０へのアクセスを有しており、ソケットハンドルを検索できる。制限付きプロセス１３２がソケットハンドルを検索しようと試みた時にいつでもヘルパープロセス１５４を起動するようにＷｉｎｓｏｃｋｃｏｎｎｅｃｔ（）ＡＰＩ１５８を変更することによって、適切なメカニズム（すなわちＡＰＩ１５８）が使用されている時に、サイトの検証されたまたは許可されたソケットの１つへのハンドルが戻される。

具体的には図１４に示されたように、ステップ１４００でＷｉｎｓｏｃｋｓｏｃｋｅｔ（）およびｃｏｎｎｅｃｔ（）ＡＰＩ１５８が呼び出され、ハンドルをソケットへ戻した時に、ｃｏｎｎｅｃｔ（）ＡＰＩ１５８はまず、ステップ１５０２において呼出しプロセス１３２がそのトークン１３４の中で適切な制限付きＳＩＤを介して制限されているかどうかをチェックする。制限されていない場合、ステップ１４０２はステップ１４０４に分岐し、ｃｏｎｎｅｃｔ（）ＡＰＩ１５８は以前と同じように動作してソケットハンドルまたは適切なエラーコード（たとえば、使用可能なソケットはありません、ホストに接続できません、アクセスが拒否されました、など）を戻す。

しかし、制限付きプロセス１３２がステップ１４０２によって決定されたようにｃｏｎｎｅｃｔ（）コールを作成すると、ｃｏｎｎｅｃｔ（）ＡＰＩ１５８はステップ１４０６でヘルパープロセス１５４（図１３および図１８）を呼び出す。図１５のステップ１５１０によって表されたように、ヘルパープロセス１５４はサイトのサイト情報を制限付きトークン１３４から抽出し、ステップ１５１２で、サイトの許可された（または拒否された）アドレスを要求されたアドレスと比較する。これらが許可されていない場合、ステップ１５１２はステップ１５１４に分岐し、ここでソケット要求は適切なエラーコードを設定するなどにより効果的に拒否される。これらが同じ場合、ステップ１５１２はステップ１５１６に分岐し、ここでヘルパープロセス１５４はデバイスドライバ１５０にアクセスして、プロセス１３２に対応するサイトへのソケットハンドルを得る（ハンドルが使用可能で、他のエラーがないと仮定する）。ヘルパープロセス１５４（図１５）は、ステップ１５１８でハンドルをコピーし、コピーされたハンドルまたはなんらかのエラーの指示のいずれかをｃｏｎｎｅｃｔ（）ＡＰＩ１５８（図１４）に戻し、その後、ｃｏｎｎｅｃｔ（）ＡＰＩ１５８はステップ１４２０でソケットハンドルまたはエラーコードを制限付きプロセス１３２へ戻す（図１４）。この方法で、ハンドルが戻された場合、制限付きプロセス１３２はハンドルを介して検証／許可されたサイトにアクセスできるが、他のサイトにはアクセスできない。ヘルパープロセス１５４が信頼できるものであり、そのサイトのソケットハンドルのみを許可するように注意深く書かれていることに注意されたい。

同様に、制限付きプロセスがファイルをダウンロードした時に、ファイルレベルでＵＲＬで識別されたデータをダウンロードするＷｉｎｉｎｅｔ．ｄｌｌ（他の関数も含む）は、ヘルパープロセスを使用する。ヘルパープロセスはサイトが要求しているＵＲＬを抽出および確認し、確認された場合、ダウンロードおよび他のＷｉｎｉｎｅｔ作業を実行するが、一方、制限付きプロセスへ通知を提供する。ヘルパープロセスがダウンロードされたファイル上でＡＣＬを設定できるようにすることによって、これらのファイルを他のサイトから守ることが容易に理解されるであろう。再び、制限付きプロセスがｗｉｎｉｎｅｔ関連のＡＰＩを呼び出す時、ＡＰＩは適切なヘルパープロセスを起動する。

他のサイトへの制限付きアクセスの他に、サイトについて設定された制限付きプロセスは、それ自体のファイル以外のファイルへのアクセスからも制限されている。この目的のために、ユーザのシステム上でサイトによって作成された任意のファイルは、そのサイトに特に対応するＡＣＬエントリーを有するフォルダ内に置かれる。たとえば図１６に示されているように（ここではフォルダは三角形として表され、階層的なフォルダ構造を示す）、各サイト（Ｓｉｔｅ₁．ｃｏｍからＳｉｔｅ_n．ｃｏｍ）は、インターネットサイトのファイルフォルダ１６２の下などのように、ファイルシステム内に自分自身のサブフォルダ１６０₁〜１６０_nを有する。そのサイトのプロセスのみ（たとえばＳｉｔｅ１．ｃｏｍ）がそれ自体のトークンの中にＡＣＬ１６４₁内のエントリーに対応する制限付きＳＩＤを有するので、他のサイト（たとえばＳｉｔｅ２．ｃｏｍ）はそのサイトにはアクセスできず、またその逆も同じである。このような隔離によってサイトがそれ自体のファイルにアクセス（たとえば作成、開く、読み出す、書き込む、削除する）することは可能になるが、別のサイトからのコンテントがこれらのファイルにアクセスすることを防ぐ。

図１７に示されたように、サイトに基づいてファイルの隔離を達成するためのメカニズムは、ファイルを開き、作成するためにＡＰＩ１７０に構築される場合がある。ファイルを作成し開くためのＡＰＩは、インターネットサイトに関して設定されたプロセス１３２が呼んでいる時を認識し（制限付きトークン１３４の中で制限付きＳＩＤを確認することによって）、および制限付きトークンに基づいて各ファイルを適切に置くおよび／または位置付けるようにパスを調節するように設定される。他のファイル動作（たとえば読み出し、書き込みおよび削除）はこれらのＡＰＩによって戻されたファイルハンドルを使用するので、他のＡＰＩを変更してパスをリダイレクト（ｒｅｄｉｒｅｃｔ）する必要はないことに注意されたい。

同様に、図１８に示されたように、制限付きプロセス１３２はシステムレジストリ１７４には間接的にしかアクセスできないが、本発明によれば、たとえばそれ自体のサイトに基づいたキー名（キー名がプロセスによって提供されていても）の元など、レジストリのバーチャル化されたビューを介さなければシステムレジストリ１７４にアクセスできない。たとえば、サイトはシステムレジストリ１７４に書き込みを試みるＡｃｔｉｖｅ−Ｘ制御を含む場合がある。制限付きプロセスにレジストリのバーチャル化されたビューを提供するために、レジストリにアクセスするためのレジストリＷＩＮ３２ＡＰＩ１７６（たとえば、ＲｅｇＳａｖｅＫｅｙ（）およびＲｅｇＲｅｓｔｏｒｅＫｅｙ（）ＡＰＩ）は、制限付きプロセスをレジストリ（またはそのコピー）内のそのサイト特定のサブツリー１７８へリダイレクトしたり、そこからリダイレクトしたりする。この方法で、信頼できないコンテントは、レジストリ１７４内の情報を指定された位置に登録できると信じるが、実際にはサブツリーまたはバーチャルレジストリ１７８にアクセスするように制限され、これによって既存のレジストリ情報を効果的に分離する。

信頼できないコンテントがマシンにダウンロードされる可能性のある別の方法は、電子メール（ｅメール）を介してである。電子メールでは、信頼のレベルはだれがメッセージを送信したかに依存しており、任意の添付物があった場合は、添付物のタイプ（知られている場合は出典）に依存している。図１２は、送信者の識別に基づいて信頼性を決定するための例としての構成要素を示し、ここでメールアプリケーション１３３は識別１３５を識別メカニズム１３７へ渡す。識別メカニズム１３７は、ＳＩＤ表１４１などへの信頼レベル内で制限付きＳＩＤ１３９を探すなどによって、ユーザ識別（およびその識別が真であることを確認するなんらかの認証など別の基準）を制限付きＳＩＤ１３９へ変換するために、ユーザの信頼性レベルを決定する。メールのコンテントが実行されるプロセス１４３は、制限付きＳＩＤ１３９を含む制限付きトークン１４５に関連付けられる。

図１９は、識別メカニズム１３７によって使用され、電子メールメッセージの送信者に基づいてアクセスを制限する例示的な方法としての一般的な論理を表す。メッセージの「送信者（From）」フィールドを使用して送信者の主張された識別を決定するが、ディジタル署名を介するなど認証メカニズム（たとえば電子メールアプリケーション１３３内）を使用して、送信者が本当にメッセージのソースであることを確認する場合もあることに注意されたい。さらに、ソースに基づいた制限はオンラインニュースについても同様に設定でき、これによってダウンロードされたニュースのコンテントは、送信者の識別に基づいて制限付きコンテキスト内で実行される。

例として、電子メールの送信者が非常に信頼できる、信頼できる、または信頼できないのいずれかであり、送信者が認証される場合とされない場合に、マシン上に設定できる次の簡単な方針を考えてみる。たとえば、個人の監督者および直接の同僚は非常に信頼できる送信者であり、従業員や親しい友人は信頼できる送信者であり、他のすべては信頼できない送信者である。マシン上でリソースＡＣＬは、信頼性レベル１を示す制限付きＳＩＤを有する制限付きトークンを伴うプロセスはファイルを読み出したり書き込んだりすることができるが、一方信頼レベル２のプロセスはファイルを読み出すのみであるように、制限付きＳＩＤに対応するエントリーで設定されている場合がある。信頼レベル３を示す制限付きＳＩＤを有する制限付きトークンを伴うプロセスは、任意のリソースへのアクセスを拒否される。信頼レベル０は、通常の（制限なし）トークンがそのプロセスに関連付けられていることを意味する。

図１９のステップ１９００において示されたように、ユーザが非常に信頼できる場合（たとえば「送信者」フィールドの名前を名前のリストと比較することによって）ステップ１９０２が実行され、送信者が認証されているかどうかを決定する。たとえば、受信者がメッセージの送信者の本当の識別を確認するように、メッセージにディジタルな署名がある場合がある。認証された場合、ステップ１９０４は信頼レベルをゼロに設定し、ステップ１９０６は通常のトークンをそのメッセージについて設定されたプロセスと関連付ける。認証されなかった場合、ステップ１９０８は信頼レベルを２に設定し、その後、ステップ１９２０は、２の信頼レベルに基づいてそのメッセージ用に設定されたプロセスのために制限付きトークンを作成し、その制限付きトークンをそのメッセージについて設定されたプロセスと関連付ける。信頼レベル１、２および３のための制限付きＳＩＤは予め定められており、表１４１の中など、マシン上に記憶されていることを注意されたい。

ユーザが非常に信頼できるユーザでない場合、ステップ１９００はステップ１９１０に分岐し、ユーザが信頼できるユーザか、または信頼できないユーザかを決定する。セキュリティ方針に従って信頼できるユーザであると決定された場合は、ステップ１９１０はステップ１９１２に分岐し、送信者が認証されているかどうかを決定する。認証されている場合、ステップ１９１４および１９２０において、メッセージプロセスはレベル１の信頼（読み出しおよび書き込みアクセス）になるように設定される。ステップ１９１２において認証されていないと決定された場合、信頼レベルはステップ１９０８で２（読み出しのみ（リードオンリー））に設定され、それに従って再度ステップ１９２０で適切な制限付きＳＩＤを検索し、制限付きトークンに挿入することによって、プロセスは制限される。最後に、ユーザが信頼できない場合、ステップ１９１０はステップ１９１６に分岐し、信頼レベルは３に設定され、ステップ１９２０では、プロセスはそれに対応してシステムリソースへのアクセスを拒否されるように制限される。上のセキュリティ方針は、ポイントシステムを介した実装を提案する、すなわち、送信者の識別および認証されている場合の種々のポイントに応じて種々のポイントを蓄積し、すべてのポイントに基づいてアクセスレベルを決定することに注意されたい。

同様な方針は添付物を制限するためにも設定できることが容易に理解されるであろう。しかし、添付物の送信者に基づいて制限することに加えて、添付物はそのタイプについてもチェックされる場合がある。たとえば、実行可能ファイル（＊．ｅｘｅ、＊．ｂａｔ、＊．ｃｏｍなど）はテキストのみの文書から区別され、マイクロソフトワード文書およびマイクロソフトエクセル文書（これはウィルスや、マクロを介した他の不正なコードを含む可能性がある）からは、制限に関して異なるように処理される場合がある。たしかに、任意の数の基準が使用され、および／または他の基準と組み合わせられて、所望のセキュリティ方針に従って制限付きセキュリティコンテキストを設定することができる。

ウェブサーバ上の信頼できないコンテントの考慮を考えると、クライアントプロセス、スクリプト、および他のこのようなヘルパープログラムは、このようなコンテントが実行できることに関して、制限付きの実行コンテキストを介して限定される場合がある。本発明の別の態様によれば、ウェブサーバがコンテントを使用するための第１の方法は、このようなコンテントが任意の中心的なオペレーティングシステムを傷つけたり、および他のヘルパープログラムのデータに干渉したりすることを防ぐ、制限付きコンテキスト内でこのようなコンテントのすべてを起動することである。上記のように、信頼できないコンテントの各断片について、適切に制限されたトークンに関連付けられたプロセスを設定し、これによって、所望のようにこれらのＡＣＬを介したシステムのデータファイルへのアクセスを拒否し、および所望のように信頼できないコンテントの任意のファイルを分離することによって、これが達成できる。メモリの保護はすでにプロセスの境界を介してすでに存在することに注意されたい。

さらに、スクリプトの作成者によって識別する、および／またはスクリプトが任意のファイルへのアクセスを必要とするかどうか、またはほかのユーザファイルまたはシステムファイルとファイルを共有する必要があるかどうかを決定することによるなどで、制限が実行されているサーバスクリプトに基づく場合がある。たとえば、図２０に示されたように、特にそのために制限付きＳＩＤ２０６を含む制限付きトークン２０４を作成することによって制限されているプロセス２０２内でウェブサーバヘルパースクリプト２００を実行することによって、スクリプトはそれが必要とするリソースのみに限定され他のリソースにはアクセスできず、スクリプトがそれが意図されたこと以外には何もできないように効果的に限定できる。したがって、図２０に示されたように、スクリプト１２００は、リソースＸ（２１８）およびリソースＺ（２２６）のそれぞれのＡＣＬ２２０、２２８が「スクリプト１」エントリーを含むため、リソースＸおよびリソースＺにアクセスすることができる。同様に、スクリプト２２１０は、リソースＹ（２２２）およびリソースＺ（２２６）のそれぞれのＡＣＬ２２４、２２８が「スクリプト２」エントリーを含むため、リソースＹおよびリソースＺにアクセスすることができる。したがって、示されたリソースがデータファイルである場合、スクリプト１はスクリプト２のデータに干渉することはできず、またその逆も同じであるが、リソースＺ内は例外である、しかしリソースＺは共有ファイルとして設計されている。たとえば、ＡＣＬエントリーを介してリソースＺ（２２６）はこれらのプロセス２０２、２１２に関して読み出しのみのデータファイルである可能性があり、これにによってスクリプト２００、２１０はこのファイルの情報を使用することはできるが、これを変更することはできない。

本発明によって提供される別のオプションはジョブオブジェクトを作成することであって、これは上記のように、その中のすべてのプロセスに関して制限を含むカーネルレベルのオブジェクトである。さらに、ジョブオブジェクトはＣＰＵの処理が消費される程度など他の制限も含む場合がある。上記のように、このジョブに追加された任意のプロセスは同じ制限を受け、これによってウェブサーバはクライアントのためにプロセスを作成し、ついでプロセスを既存のジョブに追加することができる。制限はついで自動的にプロセスに適用される。

本発明によれば、ウェブサーバはさらに、クライアントの識別（たとえば、彼らが会社の従業員か否か）、そのクライアントによって使用されている認証の方法（たとえば、パスワードの提示、証明、スマートカードの使用、または親指の指紋／網膜走査など）、およびクライアントの位置（たとえば、クライアントが同じネットワーク上にいるか、ダイアルインしているか、またはインターネット上で接続しているかに基づく）を含む、任意の数の基準に基づいて、クライアントプロセスなどに適用する制限をさらに選択することができる。図２１は、認証タイプに応じて、および認証がローカルマシンを介してではなくなんらかの遠隔（したがって理論的にはより安全でない）接続を介して行われたかどうかに応じて、信頼レベルを設定するための論理を示す、例としてのフロー図を示す。簡単に説明するために、信頼レベルと、それを使用して対応する制限付きＳＩＤを検索して制限付きトークンを設定することは同様に上に説明されているので、図２１の個別のステップおよび論理は詳細には説明されない。しかし、一般に、認証がより信頼できる場合は、割り当てられる信頼レベルはより低い（ここでは増大されたアクセス権に対応する）ことに注意されたい。

最後に、インターネットサービスプロバイダは制限付き実行コンテキストを使用して、単一のウェブサーバ上で多数のウェブサイトを安全にホストすることができる。この目的のために、各ウェブサイトはジョブオブジェクトおよび制限付きトークンから構成される、別の制限付き実行コンテキスト内で実行される。ジョブオブジェクトは、ウェブサーバのリソースの一部が各ウェブサイトに割りつけられるように、割当てを提供する。制限付きトークンはウェブサイトの間に分離を提供し、顧客リストなどのプライベートなデータを認証されないアクセスから保護する。

上記の詳細な説明から分かるように、本発明の制限付き実行コンテキストは、信頼できないコンテントがシステムリソースへアクセスすることを制限する。制限は、システムに使用可能な任意の基準に応じて、リソースごとのベースで適用できる。

本発明は種々の変形および代替の構成を可能にするが、そのうち所定の図示された実施形態が図に示され、上記に詳細に説明された。しかし、本発明を開示された具体的な形に制限する意図はなく、逆に、本発明の精神と範囲に含まれるすべての変形例、代替の構成、均等物をカバーすることが目的であることを理解されたい。

６０トークン
６２ＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド
６４ユーザＳＩＤ
６６グループＳＩＤ
６８権限
７２オブジェクト
７４オブジェクトマネジャー
７６セキュリティ記述子
７８セキュリティメカニズム
８０ＤＡＣＬ
８１ＳＡＣＬ
８４制限付きトークン
８６ＮｔＦｉｌｔｅｒＴｏｋｅｎＡＰＩ
８８ＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド
９０権限フィールド
９２制限付きセキュリティＩＤフィールド
９４制限付きプロセス

Claims

コンピュータシステムにおいて、実行可能なコンテントが、記憶装置に記憶されたリソースへアクセスすることを制限する方法であって、
前記コンピュータシステムのプロセッサにおいて、前記コンテントを実行中の前記プロセッサが前記リソースへアクセスするためのプロセスを設定するステップと、
前記コンピュータシステムの識別手段において、前記コンピュータシステムにログオン中のユーザの認証方法の種類に基づいて前記プロセスの信頼レベルを決定するステップと、
前記コンピュータシステムの制御手段において、前記決定された信頼レベルに対応するアクセス権の範囲内で前記プロセスが前記リソースにアクセスすることを決定するステップと、
前記識別手段において、前記決定された信頼レベルに対応するセキュリティ識別子を決定するステップと、
前記コンピュータシステムの作成手段において、前記決定されたセキュリティ識別子を含む制限付きトークンを作成するステップと
を備え、
前記コンピュータシステムは、前記リソースに関連付けられたセキュリティ識別子およびアクセス権の情報を前記記憶装置に記憶しており、かつ前記プロセスの信頼レベルを前記セキュリティ識別子に関連付けて前記記憶装置に記憶しており、
前記プロセスが前記リソースにアクセスすることを決定するステップは、前記制御手段において、前記リソースに関連付けられた前記記憶されたセキュリティ識別子を参照し、前記制限付きトークンに含まれたセキュリティ識別子が見つかった場合、前記見つかったセキュリティ識別子に対応する前記アクセス権の範囲内で前記プロセスが前記リソースにアクセスすることを決定するステップを含むことを特徴とする方法。
前記コンピュータシステムはサーバであり、および前記信頼レベルを決定するステップは、クライアントが前記サーバに認証された方法を決定するステップと、前記決定された認証方法に応じて前記信頼レベルを決定するステップとを含むことを特徴とする請求項１に記載の方法。
コンピュータシステムにおいて、実行可能なコンテントが、記憶装置に記憶されたリソースへアクセスすることを制限するためのシステムであって、
前記コンテントを実行中の前記コンピュータシステムのプロセッサによって設定された前記リソースへアクセスするためのプロセスと、
前記コンピュータシステムにログオン中のユーザの認証方法の種類に基づいて前記プロセスの信頼レベルを決定するための識別手段と、
前記プロセスが前記決定された信頼レベルに対応するアクセス権の範囲内で前記リソースにアクセスするように制御するための制御手段と
を備え、
前記コンピュータシステムは、前記リソースに関連付けられたセキュリティ識別子およびアクセス権の情報を前記記憶装置に記憶しており、かつ前記プロセスの信頼レベルを前記セキュリティ識別子に関連付けて前記記憶装置に記憶しており、
前記識別手段は、前記決定された信頼レベルに応じてセキュリティ識別子を決定し、
前記セキュリティ識別子を含む制限付きトークンを作成するための作成手段を更に備え、
前記制御手段は、前記リソースに関連付けられた前記記憶されたセキュリティ識別子を参照し、前記作成手段により作成された制限付きトークン内のセキュリティ識別子が見つかった場合に、前記見つかったセキュリティ識別子に対応する前記アクセス権の範囲内で前記プロセスが前記リソースにアクセスすることを決定することを特徴とするシステム。
前記システムはサーバであり、および前記信頼レベルは、クライアントが認証され前記サーバに接続する方法に従って決定されることを特徴とする請求項３に記載のシステム。