JP2002517852A

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

Info

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

Abstract

(57)【要約】ウェブサイトからダウンロードされたコンピュータコードまたは他のデータ、電子メールメッセージおよびそこへの任意の添付物、サーバ上で実行するスクリプトまたはクライアントプロセスなどの信頼できないコンテント（content）に関して、制限付き実行コンテキストが提供される。信頼できないコンテントのために制限付きプロセスが設定され、そのコンテントによって試みられる任意のアクションはそのプロセスの制限を受け、これは種々の基準に基づく可能性がある。プロセスがリソースへアクセスしようとするといつでも、そのプロセスに関連付けられたトークンがそのリソースのセキュリティ情報に対して比較され、そのタイプのアクセスが許可されているかどうかを決定する。各リソースのセキュリティ情報はこのように制限付きプロセス、従って信頼できないコンテントがアクセスを有する範囲を決定する。一般に、各信頼できないコンテントのプロセスに関して制限を設定するために使用される基準は、そのコンテントがどの程度信頼できるか信頼できないかを示す情報である。

Description

【発明の詳細な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００３６】

【表１】

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

【００３８】

【表２】

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

【００４０】

【表３】

【００４１】

【表４】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００５９】

【表５】

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

【００６１】

【表６】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図面の簡単な説明】

【図１】本発明を組み込むことのできるコンピュータシステムを表すブロック図である
。

【図２】本発明の一態様による、既存のトークンから制限付きのトークンを作成するこ
とを一般に表すブロック図である。

【図３】プロセスがリソースにアクセスできるかどうかを決定するための種々の構成要
素を一般に表すブロック図である。

【図４】本発明の一態様による、既存のトークンから制限付きのトークンを作成する一
般のステップを表すフローチャートである。

【図５】本発明の一態様による、既存のトークンから制限付きのトークンを作成する一
般のステップを表すフローチャートである。

【図６】本発明の一態様による、リソースにアクセスを試みる関連付けられた制限付き
のトークンを有するプロセスを一般に表すブロック図である。

【図７】本発明の一態様による、プロセスのオブジェクトへアクセスすることを決定す
るための、関連付けられた制限付きのトークンを有する論理を一般に表すブロッ
ク図である。

【図８】本発明の一態様による、リソースへのプロセスアクセスを許可するかどうかを
決定する時にとられる一般のステップを表すフローチャートである。

【図９】共通の制限を伴う多数のプロセスをその中に有するジョブオブジェクトを示す
ブロック図である。

【図１０】本発明の一態様による、設定されたプロセス内の信頼できないコンテントで、
リソースへのアクセスに関して制限されている信頼できないコンテントを一般に
表すブロック図である。

【図１１】信頼できないサイトおよび電子メールコンテントに関する基準に従ってプロセ
スを制限するための、本発明の別の一態様による構成要素を表すブロック図であ
る。

【図１２】信頼できないサイトおよび電子メールコンテントに関する基準に従ってプロセ
スを制限するための、本発明の別の一態様による構成要素を表すブロック図であ
る。

【図１３】本発明の別の一態様による、制限付きプロセスのためにリソースにアクセスす
るためのヘルパープロセスを一般に表すブロック図である。

【図１４】本発明の別の一態様による、アプリケーションプログラミングインタフェース
（ＡＰＩ）がヘルパープロセスを使用して情報をリソースから、そのリソースへ
のアクセスを制限されているプロセスへ戻す方法を示すフロー図である。

【図１５】本発明の別の一態様による、アプリケーションプログラミングインタフェース
（ＡＰＩ）がヘルパープロセスを使用して情報をリソースから、そのリソースへ
のアクセスを制限されているプロセスへ戻す方法を示すフロー図である。

【図１６】本発明の別の一態様による、ファイルシステム内の別のサイトのファイルから
分離されたサイトのファイルの図である。

【図１７】本発明の別の一態様による、信頼できないコンテントのファイルシステム要求
がリダイレクトされる方法を表すブロック図である。

【図１８】本発明の別の一態様による、信頼できないコンテントのレジストリ要求がリダ
イレクトされる方法を表すブロック図である。

【図１９】本発明の別の一態様による、送信者の識別を含む基準によって電子メールコン
テントが制限される方法の例を表すフロー図である。

【図２０】本発明の別の一態様による、設定されたプロセス内の信頼できないスクリプト
で、リソースへのアクセスに関して制限されている信頼できないスクリプトを一
般に表すブロック図である。

【図２１】本発明の別の一態様による、クライアントが認証された方法を含む、基準に従
ってサーバ上でクライアントプロセスが制限される方法の例を表すフロー図であ
る。

───────────────────────────────────────────────────── フロントページの続き (72)発明者グレゴリージェンセンワーズアメリカ合衆国 98053 ワシントン州レッドモンド 264 アベニューノースイースト 3428 (72)発明者マリオシー．ゴートゼルアメリカ合衆国 98033 ワシントン州カークランドノースイースト 107 プレイス 12631 (72)発明者バーラトシャーアメリカ合衆国 98059 ワシントン州ニューキャッスル 136 アベニューサウスイースト 8223 (72)発明者マイケルエム．スイフトアメリカ合衆国 98105 ワシントン州シアトル１アベニューノースイースト 4220 (72)発明者リチャードビー．ウォードアメリカ合衆国ワシントン州レッドモンド 261 アベニューノースイースト 8565 Ｆターム(参考） 5B076 BB06 FA14 FB00 FB06 FD08 5B085 AE06 BG07

Claims

【特許請求の範囲】

【請求項１】各々のリソースに関連付けられたセキュリティ情報に対する
、各々のプロセスに関連付けられたアクセストークン内の情報に基づいて、プロ
セスがリソースへアクセスすることを決定するセキュリティメカニズムを準備し
たオペレーティングシステムを有するシステムにおいて、コンテントがリソース
へアクセスすることを制限する方法であって、前記コンテントに関するプロセス
を設定するステップと、前記システムに使用可能な基準に基づいて制限情報を決
定するステップと、前記制限情報を制限付きアクセストークンに追加するステッ
プと、前記制限付きアクセストークンを、前記コンテントのプロセスのアクセス
トークンとして使用するステップとを備えたことを特徴とする方法。
【請求項２】前記コンテントは、信頼できないソースから得られたデータ
を備えたことを特徴とする請求項１に記載の方法。
【請求項３】前記信頼できないソースは、フロッピディスクであることを
特徴とする請求項２に記載の方法。
【請求項４】前記コンテントは前記システムにファイルを書き込み、およ
び前記方法は、サイトに対応する制限付きセキュリティ識別子を生成するステッ
プと、前記セキュリティ識別子を前記ファイルのセキュリティ情報に追加するス
テップと、前記ファイルを前記システム内に格納するステップとをさらに備えた
ことを特徴とする請求項２に記載の方法。
【請求項５】前記コンテントは前記システムにファイルを書き込み、およ
び前記方法は、前記コンテントによって提供されたパスを、前記サイトに関連付
けられたパスにリダイレクトするステップをさらに備えたことを特徴とする請求
項２に記載の方法。
【請求項６】前記データはネットワークデータを備え、前記信頼できない
ソースはネットワークサイトであることを特徴とする請求項２に記載の方法。
【請求項７】前記サイトはインターネットサイトであり、および前記制限
情報を決定するステップは、前記インターネットサイトの一意的な情報からセキ
ュリティ識別子を生成するステップを含むことを特徴とする請求項６に記載の方
法。
【請求項８】前記一意的な情報は、前記インターネットサイトのバイナリ
証明識別子を備えたことを特徴とする請求項７に記載の方法。
【請求項９】前記一意的な情報は前記インターネットサイトのユニフォー
ムリソースロケータ（ＵＲＬ）を備え、および前記セキュリティ識別子を生成す
るステップは、前記ＵＲＬを前記制限付きセキュリティ識別子に変換するステッ
プを含むことを特徴とする請求項７に記載の方法。
【請求項１０】前記ＵＲＬを前記制限付きセキュリティ識別子に変換する
ステップは、前記ＵＲＬを暗号化ハッシュ関数でハッシュするステップを含むこ
とを特徴とする請求項９に記載の方法。
【請求項１１】前記コンテントは電子メールメッセージを備えたことを特
徴とする請求項１に記載の方法。
【請求項１２】前記制限情報を決定するステップは、前記メッセージの送
信者を決定するステップを含むことを特徴とする請求項１１に記載の方法。
【請求項１３】前記メッセージの送信者を決定するステップは、前記送信
者を認証するステップを含むことを特徴とする請求項１２に記載の方法。
【請求項１４】前記コンテントはスクリプトを備えたことを特徴とする請
求項１に記載の方法。
【請求項１５】前記システムはサーバであり、および前記制限情報を決定
するステップは、クライアントが前記サーバに認証された方法を決定するステッ
プを含むことを特徴とする請求項１４に記載の方法。
【請求項１６】前記コンテントはサイトからダウンロードされたデータを
備え、前記方法は、前記サイトに対応するゾーンを決定するステップをさらに備
え、および前記制限情報を制限付きアクセストークンに追加するステップは、前
記ゾーンに対応する制限付きセキュリティ識別子を前記制限付きアクセストーク
ンに追加するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１７】ヘルパープロセスを介して前記リソースへアクセスするス
テップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項１８】前記ヘルパープロセスは、前記コンテントに関連付けられ
た情報を前記制限付きトークンから抽出することを特徴とする請求項１７に記載
の方法。
【請求項１９】アプリケーションプログラミングインタフェースにおいて
、前記制限付きトークンをアクセストークンとして有する前記プロセスからリソ
ースへアクセスしようとする試みを検出するステップと、それに応答して、前記
ヘルパープロセスを呼び出して前記リソースへアクセスするステップと、前記ヘ
ルパープロセスから、前記制限付きトークンをアクセストークンとして有する前
記プロセスへ情報を戻すステップとをさらに備えたことを特徴とする請求項１７
に記載の方法。
【請求項２０】前記リソースの前記セキュリティ情報が前記ヘルパープロ
セスへアクセスすることを許可し、前記制限付きトークンをアクセストークンと
して有する前記プロセスへアクセスすることを否定するように前記リソースの前
記セキュリティ情報を設定するステップをさらに備えたことを特徴とする請求項
１７に記載の方法。
【請求項２１】前記プロセスをジョブオブジェクトに入れるステップをさ
らに備えたことを特徴とする請求項１に記載の方法。
【請求項２２】前記コンテントがシステムレジストリにアクセスしようと
試み、前記コンテントによって提供されたレジストリ位置を、前記コンテントに
関連付けられたレジストリ位置へリダイレクトするステップをさらに備えたこと
を特徴とする請求項１に記載の方法。
【請求項２３】コンピュータシステムにおいて、コンテントがリソースへ
アクセスすることを制限するためのシステムであって、前記コンテントに関して
設定されたプロセスと、前記コンテントに対応する情報に基づいて少なくとも１
つの制限付きセキュリティ識別子を決定するための識別メカニズムと、前記少な
くとも１つの制限付きセキュリティ識別子を前記制限付きアクセストークンに追
加することによって、前記プロセスのために制限付きアクセストークンを作成す
るためのメカニズムと、前記制限付きアクセストークン内の情報と前記リソース
に関連付けられたセキュリティ情報とを比較することによって前記コンテントの
プロセスがリソースにアクセスすることを決定するためのセキュリティメカニズ
ムとを備えたことを特徴とするシステム。
【請求項２４】前記コンテントはサイトからダウンロードされたデータを
備えたことを特徴とする請求項２３に記載のシステム。
【請求項２５】前記サイトはインターネットサイトであり、および前記識
別メカニズムは前記インターネットサイトの情報から制限付きセキュリティ識別
子を生成することを特徴とする請求項２４に記載のシステム。
【請求項２６】前記インターネットサイトの情報は、前記インターネット
サイトのバイナリの証明識別子を備えたことを特徴とする請求項２５に記載のシ
ステム。
【請求項２７】前記インターネットサイトの情報はユニフォームリソース
ロケータ（ＵＲＬ）を備え、および、前記ＵＲＬを前記制限付きセキュリティ識
別子に変換するためのコンバータをさらに備えたことを特徴とする請求項２５に
記載のシステム。
【請求項２８】前記コンバータは、一方向の暗号化ハッシュ関数を含むこ
とを特徴とする請求項２７に記載のシステム。
【請求項２９】前記コンテントは電子メールメッセージを備えたことを特
徴とする請求項２３に記載のシステム。
【請求項３０】前記識別メカニズムは、前記メッセージの送信者に基づい
て制限付きセキュリティ識別子を決定することを特徴とする請求項２９に記載の
システム。
【請求項３１】前記コンテントはスクリプトを備えたことを特徴とする請
求項２３に記載のシステム。
【請求項３２】前記システムはサーバであり、および制限付きセキュリテ
ィ識別子は、前記クライアントが認証され前記サーバに接続する方法に従って生
成されることを特徴とする請求項２３に記載のシステム。
【請求項３３】前記制限付きトークンから前記コンテントに関連付けられ
た情報を抽出し、および前記プロセスのために前記リソースへアクセスするため
のヘルパープロセスをさらに備えたことを特徴とする請求項２３に記載のシステ
ム。
【請求項３４】ジョブオブジェクトをさらに備え、前記プロセスは前記ジ
ョブオブジェクト内で実行されることを特徴とする請求項２３に記載のシステム
。
【請求項３５】コンピュータサーバ内で、コンテントがリソースへアクセ
スすることを制限するためのシステムであって、各ウェブサイトのコンテントが
そのために設定されたプロセスを有する、別個のウェブサイトに準備された複数
のコンテントと、各サイトに対応する情報に基づいて、少なくとも１つの制限付
きセキュリティ識別子を決定するための識別メカニズムと、前記サイトに対応す
る少なくとも１つの制限付きセキュリティ識別子を前記プロセスのための前記制
限付きアクセストークンに追加することによって、各プロセスについて制限付き
アクセストークンを作成するためのメカニズムと、前記制限付きアクセストーク
ン内の情報と前記リソースに関連付けられたセキュリティ情報とを比較すること
によって、各コンテントのプロセスがリソースへアクセスすることを決定するた
めのセキュリティメカニズムとを備えたことを特徴とするシステム。