(57)【特許請求の範囲】
【請求項１】
情報処理手段およびリソースを有し、リソースへのアクセスを有する第１のプロセスを前記情報処理手段が実行するコンピュータシステムにおいて、第２のプロセスのリソースへのアクセスを許可または拒否する方法であって、前記情報処理手段は、
第１のプロセスに関連付けられた親トークンから制限付きのトークンを作成し、制限付きのトークンは親トークン内の権限およびセキュリティ識別子アクセス権のサブセットである権限およびセキュリティ識別子アクセス権および前記第２のプロセスについて許可または拒否されるエントリーを示す制限付きセキュリティ識別子であって、前記親トークンには含まれていない制限付きセキュリティ識別子を有するステップと、
制限付きのトークンを第２のプロセスに関連付けるステップと、
第２のプロセスにリソースへのアクセスを与えるように要求するステップと、
セキュリティメカニズムにリソースに関連付けられたセキュリティ記述子を提供するステップと、
制限付きトークンをセキュリティメカニズムに提供するステップと、
制限付きトークン内の情報をセキュリティ記述子内の情報と比較することによって、セキュリティメカニズムにおいてアクセス評価を実行するステップと、
アクセス評価の結果に基づいてアクセスを許可するかまたは拒否するかを決定するステップと
を実行することを特徴とする方法。
【請求項２】
親トークンから制限付きのトークンを作成するステップが、親トークンに関連する少なくとも１つの権限を制限付きトークンから削除するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
親トークンから制限付きのトークンを作成するステップが、親トークン内でアクセスを許可するための、対応するセキュリティ識別子の属性情報に関連して、そのセキュリティ識別子を介して、制限付きトークン内の制限付きセキュリティ識別子の属性情報をアクセス拒否に変更するステップを含むことを特徴とする請求項１に記載の方法。
【請求項４】
セキュリティメカニズムにおいてアクセス評価を実行するステップが、
制限付きトークン内のユーザに基づいたセキュリティ識別子情報および、前記セキュリティ記述子内のセキュリティ識別子情報を使用して第１のアクセスチェックを実行するステップと、
前記セキュリティ記述子内のセキュリティ識別子情報と、アクセスを拒否する属性情報を有する制限付きのトークン内のユーザに基づいたセキュリティ識別子との間に対応が検出された場合、リソースへのプロセスアクセスを拒否するステップとを含むことを特徴とする請求項３に記載の方法。
【請求項５】
親トークンから制限付きのトークンを作成するステップが、制限付きセキュリティ識別子を制限付きトークンに追加するステップを含むことを特徴とする請求項１に記載の方法。
【請求項６】
セキュリティメカニズムにおいてアクセス評価を実行するステップが、
制限付きトークン内のユーザに基づいたセキュリティ識別子情報および前記セキュリティ記述子内のセキュリティ識別子情報を使用して第１のアクセスチェックを実行するステップと、
第１のアクセスチェックがアクセスが許可可能であることを示した場合に、制限付きトークン内の制限付きセキュリティ識別子情報および、セキュリティ記述子内のセキュリティ識別子エントリーを使用して第２のアクセスチェックを実行するステップと、
第２のアクセスチェックがアクセスが許可可能であることを示した場合に、アクセスを許可するステップとを含むことを特徴とする請求項５に記載の方法。
【請求項７】
第１のアクセスチェックを実行するステップがアクセスが許可可能ではないことを示した場合、リソースへの第２のプロセスのアクセスを拒否することを特徴とする請求項６に記載の方法。
【請求項８】
制限付きのトークンを作成するステップが、
識別子および権限を、親トークンから制限付きトークンへコピーするステップと、
少なくとも１つの権限を制限付きトークンから削除するステップと、
制限付きトークン内の少なくとも１つのセキュリティ識別子の属性情報を変更してアクセスを拒否するステップと、
制限付きトークンに第２のプロセスを識別する少なくとも１つの制限付きセキュリティ識別子を追加するステップとを含むことを特徴とする請求項１に記載の方法。
【請求項９】
アクセス評価を実行するステップが、
制限付きトークン内の少なくとも１つのセキュリティ識別子を、セキュリティ記述子内の少なくとも１つのセキュリティ識別子と比較照合させるステップを含むことを特徴とする請求項１に記載の方法。
【請求項１０】
アクセス評価を実行するステップがさらに、
第２のプロセスによって所望されるアクションのタイプを、セキュリティ記述子内で識別されたアクションの許可されたタイプに対して比較照合させるステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１１】
アクセス評価を実行するステップが、
制限付きのトークン内で権限を評価するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１２】
アクセス評価の結果を監査するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１３】
親トークンから制限付きのトークンを作成するステップが、
複数セットの制限付きセキュリティ識別子を制限付きトークンに追加するステップを含み、
セキュリティメカニズムにおいてアクセス評価を実行するステップが、
制限付きセキュリティ識別子のセットについてアクセスチェックを実行して複数の結果を得るステップと、
結果をブール式を介して結合し、アクセスを許可するか拒否するかを決定するステップとを含むことを特徴とする請求項１に記載の方法。
【請求項１４】
コンピュータを有するコンピュータシステムにおいて、リソースへのアクセスをプロセスに許可する方法であって、前記コンピュータは、
トークンを作成し、トークンを、アクセスを要求するプロセスに関連付け、トークンはユーザセキュリティ識別子およびグループセキュリティ識別子および前記プロセスについて許可または拒否されるエントリーを示す少なくとも１つの制限付きセキュリティ識別子を含むステップと、
アクセス制御リストをリソースに割り当て、アクセス制御リストはリソースへのアクセスを有する識別子のエントリーを含むステップと、
トークン内のユーザ識別子およびグループ識別子と、アクセス制御リスト内の識別子とで第１の比較を実行するステップと、
第１の比較の結果がアクセスが許可可能であることを示した場合、前記少なくとも１つの制限付きセキュリティ識別子とアクセス制御リスト内の識別子とで第２の比較を実行するステップと、
第２の比較の結果が、前記少なくとも１つの制限付きセキュリティ識別子が許可のエントリーを示すとなった場合に、前記プロセスによる前記リソースへのアクセスを許可するステップとを含むことを特徴とする方法。
【請求項１５】
アクセス制御リストが、各エントリーを伴う少なくとも１つの許可可能なタイプのアクションを含む請求項１４に記載の方法であって、
所望のタイプのアクションをセキュリティメカニズムに示すステップをさらに含み、
第１の比較および第２の比較を実行するステップが各々、所望のタイプのアクションを許可可能なタイプのアクションと比較するステップを含むことを特徴とする請求項１４に記載の方法。
【請求項１６】
第１の比較がアクセスが許可可能でないことを示した場合に、第２の比較を実行する前にアクセスを拒否するステップをさらに含むことを特徴とする請求項１４に記載の方法。
【請求項１７】
コンピュータシステム内でアクセス制御を提供するためのシステムであって、
プロセスを実行する第１の情報処理ユニットと、
プロセスに関連付けられたトークンおよびアクセス制御リストを記憶する記憶デバイスであって、前記トークンは前記プロセスと関連付けられるエントリーを示す少なくとも１つの制限付きセキュリティ識別子を含み、前記アクセス制御リストは前記プロセスについて許可または拒否されるエントリーを示す少なくとも１つの制限付きセキュリティ識別子を含む記憶デバイスと、
前記トークン内の少なくとも１つの制限付きセキュリティ識別子を、アクセス制御リスト内の識別子と比較することによってアクセス評価を実行し、アクセス評価の結果に基づいてリソースへのプロセスアクセスを許可または拒否するためのセキュリティメカニズムとして機能する第２の情報処理ユニットと
を備え、前記トークンおよび前記アクセス制御リストがさらにユーザ情報およびグループ情報を識別するセキュリティ識別子を含み、
セキュリティメカニズムが、前記トークン内のユーザ識別子およびグループ識別子をアクセス制御リスト内のユーザ識別子およびグループ識別子と比較する第１のアクセスチェックおよび、トークンリスト内の少なくとも１つの制限付きセキュリティ識別子を、アクセス制御リスト内の制限付きセキュリティ識別子と比較する第２のアクセスチェックを含み、第１のアクセスチェックおよび第２のアクセスチェックの結果に基づいて、リソースへのプロセスアクセスを許可または拒否するかのアクセス評価を実行することを特徴とするシステム。
【請求項１８】
第１のアクセスチェックは、トークン内のユーザまたはグループを表すセキュリティ識別子がアクセス制御リスト内のセキュリティ識別子に対応することを決定し、
第２のアクセスチェックがトークン内の少なくとも１つのプロセスを表すセキュリティ識別子が、アクセス制御リスト内のセキュリティ識別子に対応することを決定した時にセキュリティメカニズムがアクセスを許可し、
それ以外の場合はセキュリティメカニズムはアクセスを拒否することを特徴とする請求項１７に記載のシステム。
【発明の詳細な説明】
【０００１】
（発明の分野）
本発明は、一般にコンピュータシステムに関し、より詳細には、コンピュータシステム用の改善されたセキュリティモデルに関する。
【０００２】
（発明の背景）
歴史的に、実行可能なコンテンツは磁気媒体を物理的にコンピュータに運び、管理権限を持つ人にインストールしてもらうことによってのみ、コンピュータシステムにインストールされる。しかし現在、インターネットにより、普通のコンピュータユーザがＡｃｔｉｖｅＸ制御、プログラム、スクリプトなどの実行可能な内容をダウンロードすることが非常に簡単になり、普及してきた。多くの場合、実行可能なコンテンツは、ユーザがこのようなイベントが起きたことに気づくことさえなく、インターネットを介してダウンロードし、実行することが可能である。
【０００３】
残念なことに、このような実行可能なコンテンツはしばしば不正であり、たとえば、悪意を持って故意にクライアントマシン上のデータを破壊したりエラーが起こりがちで、クライアントのマシンをクラッシュさせるか、または善意であっても注意が足りず、クライアントに関する機密情報を漏らす場合がある。こういったタイプのコンピュータ問題は、以前は「ウィルス」および「トロイの木馬」の形で存在したが、ワールドワイドウェブの普及はこれらの問題を広げ、場合によっては制御不能が生じる。一般に、クライアントの動作環境は不正なコードに対して適切に保護されていない。
【０００４】
いくつかのオペレーティングシステムはすでに既存のセキュリティメカニズムを有しており、セキュリティシステムは権限のないユーザが行うことを制限する。たとえば、Ｗｉｎｄｏｗｓ  ＮＴオペレーティングシステムに組み込まれたセキュリティシステムは、ユーザの識別に基づいてリソースへのアクセスを制御する。Ｗｉｎｄｏｗｓ  ＮＴプロセスがリソースにアクセスして所定のアクションを実行しようとすると、Ｗｉｎｄｏｗｓ  ＮＴ内のセキュリティメカニズムはクライアントのユーザＩＤおよびグループＩＤおよびそのプロセスに関連付けられた権限を、そのリソースに割り当てられたセキュリティ情報と比較して、そのリソースへのアクセスを許可または拒否する。このようにして、許可されないユーザがリソースにアクセスし、害を及ぼす可能性が防止されるが、一方、許可されたユーザは実行できるアクションに制限を受ける場合がある。
【０００５】
しかし現在、ユーザプロセスがリソースにアクセスする適切な権利または権限を有する時、プロセスが不正な実行可能な内容を含み、リソースにアクセスして望ましくない結果を伴う可能性がある。たとえば、適切な証明を有するＷｉｎｄｏｗｓ  ＮＴユーザが不正なコードをダウンロードし実行し、これによって、上記の有害な結果のうち任意の結果またはすべての結果が生じる可能性がある。ほかのセキュリティモデルも同様な欠点および他の欠点を有し、同じ問題の影響が受けやすくなっている。
【０００６】
（発明の概要）
簡潔に言えば、本発明は制限付きのアクセストークンを提供し、各々のアクセストークンは既存の（親）トークンから作成されたアクセストークンのうちの修正された、制限付きのバージョンである。制限付きのトークンは、コピー元の親トークンより少ないアクセスを有し、親トークン内でアクセスを許可する１つまたは複数のセキュリティ識別子の属性を、制限付きのトークン内で許可されたアクセスを使用不可にするような設定に変更することにより制限付きトークンは作成される。および／または、親トークンに存在する１つまたは複数の権限を制限付きのトークンから削除することによっても制限付きトークンが作成される。さらに、制限付きのトークンはその中に制限付きのセキュリティ識別子を置くことによっても作成される。
【０００７】
使用に際しては、プロセスはそのプロセスを起動するアプリケーションなどにより、制限付きのトークンに関連付けられる。制限付きのプロセスがリソース上でアクションを実行しようと試みると、カーネルモードのセキュリティメカニズムはまず、ユーザベースのセキュリティ識別子および目的のアクションタイプを、そのリソースに関連付けられた識別子およびアクションのリストと比較する。制限付きのトークン内に制限付きのセキュリティ識別子がない場合、アクセスはこの最初の比較の結果によって決定される。制限付きのトークン内に制限付きのセキュリティ識別子がある場合、このアクションに関する第２のアクセスチェックは制限付きのセキュリティ識別子をそのリソースに関連付けられた識別子およびアクションのリストと比較する。制限付きのセキュリティ識別子を有するトークンでは、第１および第２のアクセスチェックの両方がパスした場合のみ、そのプロセスはそのリソースへのアクセスを許可される。
【０００８】
制限付きのトークンを作成することによって、プロセスは制限付きのコンテキスト内で、元の権利および権限のサブセットである別のプロセスを起動することができる。このようにして、プロセスは別のプロセス、すなわち、リソースに対して実行できるアクション内で不正なコードの可能性があるような別のプロセスを制限することができる。
【０００９】
他の利点は図面と共に次の説明から明らかになる。
【００１０】
（詳細な説明）
例としてのオペレーション環境
図１および以下の議論は、本発明が実現できる適切なコンピューティング環境の簡単で一般的な説明を提供することを意図している。必要ではないが、本発明は、パーソナルコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能な命令の一般的なコンテキスト内で説明される。一般に、プログラムモジュールはルーチン、プログラム、オブジェクト、構成要素、データ構造などを含み、特定のタスクを実行するか、特定の抽象的なデータタイプを実装する。さらに、当業者であれば本発明は、手持ちデバイス、マルチプロセッサシステム、マイクロプロセッサに基づいたまたはプログラミング可能な消費者電気製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む他ののコンピュータシステム構成でも実行できることが理解されるであろう。本発明はまた、通信ネットワークを介してリンクされた遠隔処理デバイスによってタスクが実行される分散コンピューティング環境内でも実行できる。分散コンピューティング環境では、プログラムモジュールはローカルメモリ記憶デバイスおよび遠隔メモリ記憶デバイスの両方に位置する場合がある。
【００１１】
図１を参照すると、本発明を実現するための一例としてのシステムは、従来のパーソナルコンピュータ２０などの形の汎用コンピューティングデバイスを含み、汎用コンピューティングデバイスは処理ユニット２１、システムメモリ２２、およびシステムメモリから処理ユニット２１までを含む種々のシステム構成要素を結合するシステムバス２３を含む。システムバス２３はいくつかのタイプのバス構成のうち任意の構成であって、その中にはメモリバスまたはメモリコントローラ、周辺バス、種々のバスアーキテクチャのうち任意のアーキテクチャを使用するローカルバスを含んでもよい。システムメモリは読取り専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。起動時などにパーソナルコンピュータ２０内の要素の間で情報を転送する役に立つ基本的なルーチンを含む基本入出力システム２６（ＢＩＯＳ）は、ＲＯＭ２４内に格納されている。パーソナルコンピュータ２０はさらに、図示されてはいないがハードディスクから読み出したり書き込んだりするためのハードディスクドライブ２７、取外し可能磁気ディスク２９から読み出したり書き込んだりするための磁気ディスクドライブ２８、および、ＣＤ−ＲＯＭまたは他の光媒体など、取外し可能光ディスク３１から読み出したり書き込んだりするための光ディスクドライブ３０を含む場合がある。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０はそれぞれ、ハードディスクドライブインタフェース３２、磁気ディスクドライブインタフェース３３、および光ドライブインタフェース３４によってそれぞれシステムバス２３に接続されている。ドライブとその関連付けられたコンピュータ可読媒体は、パーソナルコンピュータ２０のためにコンピュータ可読命令、データ構造、プログラムモジュールおよびほかのデータの、不揮発性の格納を提供する。ここに説明された例としての環境は、ハードディスク、取外し可能磁気ディスク２９および取外し可能光ディスク３１を使用しているが、当業者であれば磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）などの、コンピュータによってアクセス可能なデータを格納できる他のタイプのコンピュータ可読媒体も例としての動作環境内で使用できることが理解されるであろう。
【００１２】
オペレーティングシステム３５（好ましくはＷｉｎｄｏｗｓ  ＮＴ）、１つまたは複数のアプリケーションプログラム３６、ほかのプログラムモジュール３７およびプログラムデータ３８を含むいくつかのプログラムモジュールがハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５に格納できる。ユーザは、キーボード４０およびポインティングデバイス４２などの入力デバイスを介してパーソナルコンピュータ２０にコマンドおよび情報を入力できる。他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどを含む。これらおよび他の入力デバイスはしばしば、システムバスに結合されたシリアルポートインタフェース４６を介して処理ユニット２１に接続されているが、パラレルポート、ゲームポートまたは汎用シリアルバス（ＵＳＢ）などの他のインタフェースによって接続されている場合もある。モニタ４７または他のタイプの表示デバイスもまた、ビデオアダプタ４８などのインタフェースを介してシステムバス２３に接続されている。モニタ４７の外に、パーソナルコンピュータは典型的にはスピーカおよびプリンタなどの他の周辺出力デバイス（図示せず）を含む。
【００１３】
パーソナルコンピュータ２０は、遠隔コンピュータ４９など１つまたは複数の遠隔コンピュータへの論理接続を使用してネットワーク化された環境内で動作する場合がある。遠隔コンピュータ４９は、他のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードであり、典型的にはパーソナルコンピュータに関連して上記に説明された要素の多くまたはすべてを含むが、メモリ記憶デバイス５０のみが図１に示されている。図１に描かれた論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２を含む。このようなネットワーク化環境はオフィス、全社的コンピュータネットワーク、イントラネットおよびインターネットに普通に見られる。
【００１４】
パーソナルコンピュータ２０はＬＡＮネットワーク化環境内で使用されると、ネットワークインタフェースまたはアダプタ５３を介してローカルネットワーク５１に接続される。パーソナルコンピュータ２０はＷＡＮネットワーク化環境内で使用されると、典型的にはモデム５４または他の手段を含み、インターネットなど広域ネットワーク５２上で通信を確立する。モデム５４は内部的である場合も外部的である場合もあるが、シリアルポートインタフェース４６を介してシステムバス２３に接続されている。ネットワーク化された環境では、パーソナルコンピュータ２０またはその一部に関して描かれたプログラムモジュールは、遠隔のメモリ記憶デバイス内に格納される場合がある。示されたネットワーク接続は例としてのものであって、コンピュータの間で通信リンクを確立する他の手段も使用できることが明らかであろう。
【００１５】
一般的なセキュリティモデル
本発明の好ましいセキュリティモデルは、Ｗｉｎｄｏｗｓ  ＮＴセキュリティモデルに関して説明される。しかし、本発明をＷｉｎｄｏｗｓ  ＮＴオペレーティングシステムに限定する意図はなく、逆に、本発明はオペレーティングシステムのレベルでセキュリティチェックを実行する任意のメカニズムで動作し、利益を提供することを目的としている。さらに、本発明はスレッドごとのベースでソフトウェア障害の隔離で使用するか、または制限が現在実行されているクラスのスタックから決定されるバーチャルマシンで使用することもできる。さらに、本発明は必ずしもカーネルモードの動作に依存するわけではなく、ソフトウェア障害の隔離またはバーチャルマシンのように、ユーザモードで実現することもできる。
【００１６】
一般に、Ｗｉｎｄｏｗｓ  ＮＴオペレーティングシステムでは、ユーザはプロセス（およびそのスレッド）を介してシステムのリソースにアクセスすることによってタスクを実行する。簡単に説明するために、プロセスおよびそのスレッドは概念上等価と見なされ、以後は簡単にプロセスと呼ぶ。また、Ｗｉｎｄｏｗｓ  ＮＴ内ではオブジェクトによって表される、ファイル、共有メモリおよび物理デバイスを含むシステムのリソースは、本明細書では通常リソースまたはオブジェクトと呼ばれる。
【００１７】
ユーザがＷｉｎｄｏｗｓ  ＮＴオペレーティングシステムにログオンし認証されると、セキュリティコンテキストがそのユーザのためにセットアップされ、この中にはアクセストークン６０の構築も含まれる。図２の左側に示すように、従来のユーザベースのアクセストークン６０は、ＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド６２を含む。ＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド６２は、セキュリティ識別子、すなわち、ユーザの証明およびそのユーザが属するグループ（たとえば編成内のグループ）を識別する１つまたは複数のグループＩＤ６６に基づいたセキュリティ識別子（セキュリティＩＤまたはＳＩＤ）を含む。トークン６０はまた、そのユーザに割り当てられた任意の権限を一覧する権限フィールド６８を含む。たとえば、このような権限の１つは、管理レベルのユーザに、特定のアプリケーションプログラミングインタフェース（ＡＰＩ）を介してシステムクロックを設定する能力を与える場合がある。権限は、アクセス制御チェック、これは次に説明されるが、権限がない場合にオブジェクトへのアクセスを許可する前に実行されるアクセス制御チェックに優先することに注意されたい。
【００１８】
次に詳細に説明され、図３に一般に示されるように、オブジェクト７２へのアクセスを所望するプロセス７０は、所望するアクセスのタイプを指定し（たとえばファイルオブジェクトへの読取り／書き込みアクセスを得るなど）、および、カーネルレベルでは関連付けられたトークン６０をオブジェクトマネジャー７４に提供する。オブジェクト７２はそれに関連付けられたカーネルレベルのセキュリティ記述子７６を有し、オブジェクトマネジャー７４はセキュリティ記述子７６およびトークン６０をセキュリティメカニズム７８に提供する。セキュリティ記述子７６の内容は、典型的にはオブジェクトの所有者（たとえば制作者）によって決定され、一般に（任意に）アクセス制御エントリーのアクセス制御リスト（ＡＣＬ）８０を含み、各エントリーについて、そのエントリーに対応する１つまたは複数のアクセス権（許可されたアクションまたは拒否されたアクション）を含む。各エントリーはタイプ（拒否または許可）インジケータ、フラグ、セキュリティ識別子（ＳＩＤ）およびアクセス権をビットマスクの形で含み、各ビットは許可に対応する（たとえば、１つのビットは読取りアクセス、１つのビットは書込みアクセス、など）。セキュリティメカニズム７８はトークン６０内のセキュリティＩＤおよびプロセス７０によって要求されたアクション（複数可）のタイプをＡＣＬ８０内のエントリーと比較する。許可されたユーザまたはグループの一致が発見され、所望のアクセスのタイプがそのユーザまたはグループに対して許可可能な場合、オブジェクト７２へのハンドルはプロセス７０に戻されるが、その他の場合はアクセスは拒否される。
【００１９】
例として、ユーザを「会計」グループのメンバーとして識別するトークンを持つユーザが読取りおよび書込みアクセスで特定のファイルオブジェクトにアクセスしたいとする。ファイルオブジェクトが、ＡＣＬ８０のエントリー内で許可されたタイプの「会計」グループ識別子を有し、そのグループが読取りおよび書き込みアクセスを使用可能にする権利を有する場合、読取りおよび書込みアクセスを許可するハンドルは戻されるが、その他の場合はアクセスは拒否される。効率上の理由から、セキュリティチェックはプロセス７０がまずオブジェクト７２（作成または開く）にアクセスしようと試みた時のみ実行され、したがってそのオブジェクトに対するハンドルはそれを介して実行できるアクションを制限するように、アクセス情報のタイプを格納することに注意されたい。
【００２０】
セキュリティ識別子７６はまた、システムＡＣＬまたはＳＡＣＬ８１を含み、これは監査されるべきクライアントアクションに対応するタイプ監査のエントリーを含む。各エントリー内のフラグは監査が成功したオペレーションまたは失敗したオペレーションのどちらを監視するかを示し、エントリー内のビットマスクは監査されるべきオペレーションのタイプを示す。エントリー内のセキュリティＩＤは、監査されるユーザまたはグループを示す。たとえば、ファイルオブジェクトへの書込みアクセスを有しないグループのメンバーがそのファイルに書き込もうと試みた場合いつでも決定できるように特定のグループが監査される状況を考えてみる。そのファイルオブジェクトに関するＳＡＣＬ８１は、その中にグループセキュリティ識別子と、適切に設定された失敗フラグおよび書込みアクセスビットを有する監査エントリーを含む。その特定のグループに属するクライアントがそのファイルオブジェクトに書き込みしようとして失敗するといつでも、そのオペレーションは記録される。
【００２１】
ＡＣＬ８０は、（すべての権利または選択された権利に関して）グループユーザにアクセスを許可する識別子ではなくて、グループユーザのアクセスを拒否するためにマークされる１つまたは複数の識別子を含む場合があることに注意されたい。たとえば、ＡＣＬ８０内にリストされた１つのエントリーは、他の場合に、「グループ3」のメンバーにオブジェクト７２へのアクセスを許可するが、ＡＣＬ８０内の他のエントリーは特に、「グループ24」のすべてのアクセスを拒否する場合がある。トークン６０が「グループ24」セキュリティＩＤを含んでいる場合、アクセスは「グループ3」のセキュリティＩＤの存在にかかわらず拒否されることになる。もちろん、セキュリティチェックが正しく機能するために、セキュリティチェックは、”グループ3”エントリーを介したアクセスを許可しないようにアレンジされ、その後に、すべてのＤＥＮＹ（拒否）エントリーをＡＣＬ８０の前面に置くなどによって、グループ24エントリーの「ＤＥＮＹ  ＡＬＬ（すべて拒否）」状態をチェックする。この構成（ａｒｒａｎｇｅｍｅｎｔ）は、グループの残りのメンバーの各々を個別にリストしてそのアクセスを許可する必要なく、グループの、１人または複数の分離したメンバーを個別にＡＣＬ８０内で排除できるので、向上した効率を提供することが明らかであろう。
【００２２】
アクセスのタイプを指定する代わりに、コーラ−（ｃａｌｌｅｒ）はＭＡＸＩＭＵＭ＿ＡＬＬＯＷＥＤアクセスを要求することもでき、これによって、１つのアルゴリズムが通常のＵｓｅｒＡｎｄＧｒｏｕｐｓリスト対ＡＣＬ８０内の各々のエントリーに基づいて、許可される最大のアクセスタイプを決定することに注意されたい。より詳しくは、アルゴリズムは所与のユーザのための権利を蓄積している識別子のリストをウォークダウンする（すなわち、種々のビットマスクをＯＲする）。権利が一度蓄積されると、ユーザに蓄積された権利が与えられる。しかし、ウォークスルーの間にユーザ識別子またはグループ識別子および要求された権利に一致する拒否エントリーが発見されると、アクセスは拒否される。
【００２３】
制限付きのトークン
本発明の一態様によれば、制限付きのトークンは次のように、既存のアクセストークン（制限付きまたは制限なし）から作成される。また次に説明するように、制限付きトークンが任意の制限付きセキュリティＩＤを含む場合、そのトークンは追加のアクセスチェックを受け、その中で制限付きセキュリティＩＤはオブジェクトのＡＣＬ内のエントリーと比較される。
【００２４】
制限付きトークンの主な用途は、プロセスに、それ自体のトークンの制限付きのバージョンを持つ新しいプロセスを作成させることである。制限付きのプロセスはついで、リソースに関して実行できるアクションにおいて制限される。たとえば、ファイルオブジェクトリソースは、関連付けられた制限付きトークンの中に同じマイクロソフトワード制限付きＳＩＤを有する制限付きプロセスのみがそのファイルオブジェクトにアクセスできるように、単一の制限付きＳＩＤ、すなわち、マイクロソフトワードのアプリケーションプログラムを識別する単一の制限付きＳＩＤをそのＡＣＬの中に有する場合がある。オリジナルユーザはさらにオブジェクトにアクセスする必要があるので、ＡＣＬもまた、ユーザアクセスおよびマイクロソフトワードプログラムを許可するアクセス制御エントリーを含む必要があることに注意されたい。そのため、たとえば、ブラウザを介してダウンロードされたコードなど、信用できないコードは、制限付きプロセス内で実行される。制限付きプロセスは、制限付きトークン内にマイクロソフトワード制限付きセキュリティＩＤを有しない（不正である可能性のある）コードがファイルオブジェクトへアクセスすることを防ぐ。
【００２５】
セキュリティ上の理由から、異なるトークンを伴うプロセスの作成は通常は、ＳｅＡｓｓｉｇｎＰｒｉｍａｒｙＴｏｋｅｎ権限として知られる権限を必要とする。しかし、プロセスが制限付きトークンと関連付けられるようにするために、制限付きトークンが主トークンから導出されている場合に、プロセス管理は別のプロセスへの十分なアクセスを持つ１つのプロセスが、その主トークンを制限付きトークンに変更できるようにする。新しいプロセスのトークンのＰａｒｅｎｔＴｏｋｅｎＩｄを既存のプロセスのトークンのＴｏｋｅｎＩｄと比較することによって、オペレーティングシステム３５はプロセスがそれ自体の制限付きバージョンを作成しているだけであることを確認する。
【００２６】
制限付きトークン８４は親トークンより少ないアクセスしか有せず（すなわち、親トークンの権利と権限のサブセットを有するため）、ユーザ情報またはグループ情報のみに基づいてアクセスを許可または拒否するのみでなく、そのオブジェクトにアクセスしようと試みるプロセスのタイプ（またユーザまたはグループ）に基づいてオブジェクトへのアクセスを防止することなどが可能である。制限付きのトークンはまた、親トークンがこれらのＳＩＤを介してアクセスを許可している場合でも、「ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹ」と特にマークされた１人または複数のユーザまたはグループのセキュリティＩＤを介したアクセスを許可しない場合もあり、および／または、親トークンに存在する権限を削除してしまう場合もある。
【００２７】
したがって、アクセスを削減する１つの方法は、制限付きトークン内の１つまたは複数のユーザセキュリティ識別子および／またはグループのセキュリティ識別子の属性を変更して、アクセスを許可するのではなくアクセスを許可できないようにすることである。ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされたセキュリティＩＤは、アクセスを許可する目的のためには効果的に無視されるが、そのセキュリティＩＤに関して「ＤＥＮＹ（拒否）」エントリーを有するＡＣＬは依然としてアクセスが拒否される。例として、制限付きトークン８４（図３）内のグループ2のセキュリティＩＤが、ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされている場合、ユーザのプロセスがグループ2を許可されたものとしてリストしているＡＣＬ８０を有するオブジェクト７２にアクセスしようと試みた時、このエントリーは効果的に無視され、プロセスは他のなんらかのセキュリティＩＤによってアクセスを得なければならないことになる。しかし、ＡＣＬ８０が要求されたタイプのアクションに関して、グループ2をＤＥＮＹとリストしたエントリーを含んでいる場合、１度テストされると、他のセキュリティＩＤにかかわらずアクセスは許可されない。
【００２８】
セキュリティＩＤはいくつかのオブジェクトのＡＣＬの中で「ＤＥＮＹ」としてマークされている可能性があり、それによってその識別子を削除するとこれらのオブジェクトへのアクセスを拒否するのではなく許可することになってしまうため、ユーザのトークンからセキュリティＩＤをただ除去するだけではオブジェクトへのアクセスは安全に削減できないことに注意されたい。したがって、本発明は制限付きのトークン内でＳＩＤの属性がＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹに変更できるようにする。さらに、このＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹセキュリティチェックをオフにするためのメカニズムは提供されていない。
【００２９】
制限付きトークン内でアクセスを削除する別の方法は、親トークンに関して１つまたは複数の権限を削除することである。たとえば、管理権限を伴う通常のトークンを有するユーザは、そのユーザが特にシステムに別の情報を与えなければ、そのユーザのプロセスが権限のない制限付きトークンで実行するようにシステムを設定する場合がある。これはユーザが管理者の範囲内で意図的に行動していない時に発生する可能性のある、偶然のエラーを防ぐことを理解されたい。同様に、プログラムがユーザの権限に応じて異なるモードで実行するように開発され、これによって管理レベルのユーザはあるオペレーションを実行するために管理権限でプログラムを実行しなければならないが、より基本的なオペレーションを実行するためには低減された権限でオペレーションを実行しなければならない場合がある。ここで再び、これはこのようなユーザが通常のオペレーションを実行しようとしているだけなのに、高められた権限で実行している時に生じる可能性のある深刻なエラーを防ぐのに役立つ。
【００３０】
トークンのアクセスを低減するさらに別の方法は、そこに制限付きのセキュリティＩＤを追加することである。制限付きのセキュリティＩＤは、プロセス、リソースオペレーションなどを表す数であり、ＧＵＩＤへ接頭辞を追加するかまたは暗号ハッシュなどを介して生成された数字を追加するなどによってユニークになっており、これらのセキュリティＩＤを他のセキュリティＩＤから区別する情報を含む場合もある。本発明に必ず必要ではないが便利のために、ＧＵＩＤをセキュリティＩＤに変換したり、セキュリティＩＤを人間が可読な形態で表示したりなど、アプリケーションおよびユーザをセキュリティＩＤにインタフェースさせるための種々のアプリケーションプログラミングインタフェース（ＡＰＩ）が提供される。
【００３１】
アプリケーション（プロセス）要求アクセスに基づいてリソースへのアクセスを制限することに加えて、同様にリソースの制限付き使用に基づいて特定のセキュリティＩＤを開発する場合もある。例として、「ＵＳＥ＿ＷＩＮＤＯＷＳ」などのセキュリティＩＤは、ウィンドウステーションおよびデスクトップのデフォルトのＡＣＬに置かれ、制限付きトークンの中に対応するＳＩＤを有するプロセスによってのみアクセスを許可する場合がある。同様に、プリンタオブジェクトのデフォルトＡＣＬは、そのデフォルトのＡＣＬの中に「ＵＳＥ＿ＰＲＩＮＴＩＮＧ」ＳＩＤを含み、プロセスが制限付きトークンの中でリストされたこのセキュリティＩＤのみを伴う制限付きプロセスを作成し、これによって制限付きプロセスはプリンタにはアクセスできるが他のリソースにはアクセスできないようにする場合もある。他のリソースにアクセスするために、多くの他のセキュリティＩＤも実現できることが理解されるであろう。
【００３２】
図３に示すように、制限付きセキュリティＩＤは、制限付きトークン８４の特別なフィールド８２内に置かれ、アクションを要求しているプロセスを識別することなどを行う。以下にさらに詳細に説明するように、少なくとも１つのユーザ（またはグループ）セキュリティＩＤおよび少なくとも１つの制限付きセキュリティＩＤの両方についてオブジェクトへのアクセスを許可するように要求することによって、オブジェクトは要求側プロセス（またユーザまたはグループ）に基づいて選択的にアクセスを許可できる。たとえば、ファイルオブジェクトなどのオブジェクトは、マイクロソフトワード、マイクロソフトエクセルまたはＷｉｎｄｏｗｓ  エクスプローラのプロセスがそれにアクセスすることを許可するが、他のプロセスへのアクセスを拒否する場合がある。さらに、許可されたプロセスの各々は、異なるアクセス権が与えられる場合もある。
【００３３】
この設計は、ユーザのコンテキスト内で異なるプロセスが実行することを制御するための、大きな融通性と細分性を提供する。これらの機能に関する１つの期待される使用モデルは、信頼できるアプリケーションと信頼できないアプリケーションとの区別を含む。「アプリケーション」は一般的な意味で、所与のセキュリティコンテキストの下で「ユーザモード」で実行できる任意のコードの一部分を記述する。たとえば、マイクロソフトワードなどのアプリケーションはＡｃｔｉｖｅＸ制御からのプロセスとして実行され、ＡｃｔｉｖｅＸは既存のプロセス内にロードされ実行される場合がある。マイクロソフトのインターネットエクスプローラなどの他のアプリケーションを起動するアプリケーションは、このインフラストラクチャを使用した「信頼モデル」を導入する可能性がある。
【００３４】
例として、インターネットエクスプローラなどのアプリケーションは制限付きトークンを使用して異なるプロセスの下で信頼できない実行可能なコードを実行し、これらのプロセスがユーザの全体的なアクセス権および権限の中で行うことを制御できる。この目的のために、インターネットエクスプローラアプリケーションは、それ自体のトークンから制限付きトークンを作成し、どの制限付きセキュリティＩＤを制限付きトークン内に置くかを決定する。ついで、信頼できない実行可能コードは制限付きのコンテキストがアクセスできるオブジェクトにのみアクセスするように制限される。
【００３５】
さらに、制限付きＳＩＤおよび他の制限に対応するエントリーは、監査目的のためにＳＡＣＬ８１のフィールドに置くことができる。たとえば、リソースのＳＡＣＬは、インターネットエクスプローラプログラムがそのリソースの読取りまたは書込みアクセスを試みるたびに、および／またはＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされたＳＩＤの使用が監査される場合にはいつでも監査するように設定することができる。単純化のために、監査はこのあと詳細に説明しないが、制限付きＳＩＤを介したアクセス制御に関して説明されたコンセプトは監査動作にも適用可能であることは容易に理解されるであろう。
【００３６】
既存のトークンから制限付きトークンを作成するために、ＮｔＦｉｌｔｅｒＴｏｋｅｎと名付けられたアプリケーションプログラミングインタフェース（ＡＰＩ）が提供され、その内容は次のとおりである。
【００３７】
【表１】
0004809530.tif 000002
【００３８】
ＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩは、ＣｒｅａｔｅＲｅｓｔｒｉｃｔｅｄＴｏｋｅｎと名付けられたＷｉｎ３２  ＡＰＩの下でラップされ、ＣｒｅａｔｅＲｅｓｔｒｉｃｔｅｄＴｏｋｅｎの内容は次のとおりである。
【００３９】
【表２】
0004809530.tif 000003
【００４０】
図２および図４〜５に表示されたように、これらのＡＰＩ８６は共同して機能し、制限付きでも制限なしでも既存のトークン６０をとり、変更された（制限付き）トークン８４をそこから作成する。ログオンしたユーザのインスタンスに関する識別情報を含む制限付きトークンの構造は、ＰａｒｅｎｔＴｏｋｅｎＩｄ，ＲｅｓｔｒｉｃｔｅｄＳｉｄＣｏｕｎｔ、およびＲｅｓｔｒｉｃｔｅｄＳｉｄｓの３つの新しいフィールドを含む（次の表で太字で示されている）。
【００４１】
【表３】
0004809530.tif 000004
【００４２】
通常の（制限なしの）トークンがＣｒｅａｔｅＴｏｋｅｎ  ＡＰＩを介して作成される時、ＲｅｓｔｒｉｃｔｅｄＳｉｄｓフィールドもＰａｒｅｎｔＴｏｋｅｎＩｄフィールドも空であることに注意されたい。
【００４３】
制限付きトークン８４を作成するために、このプロセスは適切なフラグ設定および／または入力フィールド中の情報を伴うＣｒｅａｔｅＲｅｓｔｒｉｃｔｅｄＴｏｋｅｎ  ＡＰＩを呼び出し、これはＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩを順番に起動する。図４のステップ４００の初めに示すように、ＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩは、ＤＩＳＡＢＬＥ＿ＭＡＸ＿ＳＩＤＳと名付けられたフラグが設定されているかどうかをチェックする。このフラグは新しい、制限付きトークン８４の中にあるグループに関してすべてのセキュリティＩＤがＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされていなければならないことを示す。このフラグは、各々のグループを個別に識別する必要なく、トークン内のグループ（多くのグループである可能性がある）を制限するための便利な方法を提供する。フラグが設定されている場合、ステップ４００はステップ４０２に分岐し、ステップ４０２では新しいトークン８４内のグループセキュリティＩＤの各々について、ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹを示すビットを設定する。
【００４４】
ＤＩＳＡＢＬＥ＿ＭＡＸ＿ＳＩＤＳフラグが設定されていない場合、ステップ４００はステップ４０４に分岐し、ＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩのＳｉｄｓＴｏＤｉｓａｂｌｅフィールド内にセキュリティＩＤが個別にリストされているかどうかをテストする。図４のステップ４０４で示されたように、オプションのＳｉｄｓＴｏＤｉｓａｂｌｅ入力フィールドが存在する時、ステップ４０６では、そこにリストされ、また、親トークン６０のＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド６２内にも存在する任意のセキュリティＩＤは、新しい制限付きトークン８４のＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド８８内でＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとして個別にマークされる。上記のようにこのようなセキュリティＩＤは、アクセスを拒否するためにのみ使用でき、アクセスを許可するためには使用できず、さらに、あとから削除または使用可能にはできない。したがって、図２に示された例では、グループ2のセキュリティＩＤは、ＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩ８６のＳｉｄｓＴｏＤｉｓａｂｌｅ入力フィールド内にグループ2セキュリティＩＤを指定することにより、制限付きトークン８４内でＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとしてマークされる。
【００４５】
フィルタプロセスはついで図４のステップ４１０に続き、ここではＤＩＳＡＢＬＥ＿ＭＡＸ＿ＰＲＩＶＩＬＥＤＧＥＳと名付けられたフラグがテストされる。このフラグは同様に、新しい、制限付きトークン８４内のすべての権限を削除すべきであることを示す、便利なショートカットとして設定できる。このように設定された場合、ステップ４１０はステップ４１２に分岐し、ステップ４１２では新しいトークン８４からすべての権限が削除される。
【００４６】
フラグが設定されていない場合、ステップ４１０はステップ４１４に分岐し、ここではオプションのＰｒｉｖｉｌｅｇｅｓＴｏＤｅｌｅｔｅフィールドが確認される。ＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩ８６が呼ばれた時に存在する場合は、ステップ４１６で、この入力フィールドにリストされまた既存のトークン６０の権限フィールド６８にも存在する任意の権限は、新しいトークン８４の権限フィールド９０から個別に削除される。図２に示された例では、「権限2」から「権限m」として示された権限は、ＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩ８６のＰｒｉｖｉｌｅｇｅｓＴｏＤｅｌｅｔｅ入力フィールド内にこれらの権限を指定することによって、新しいトークン８４の権限フィールド９０から削除されている。上記のように本発明の１つの態様によれば、これは、トークン内で使用可能な権限を削減する機能を提供する。このプロセスは図５のステップ４２０に続く。
【００４７】
制限付きトークン８４を作成する時に、ステップ４２０でＲｅｓｔｒｉｃｔｉｎｇＳｉｄｓ入力フィールド内にＳＩＤが存在していた場合、親トークンが通常のトークンか、または親トークン自体が制限付きＳＩＤを有する制限付きトークンであるかどうかに関して決定が行われる。ＡＰＩ、ＩｓＴｏｋｅｎＲｅｓｔｒｉｃｔｅｄがステップ４２２で呼び出され、親トークンのＲｅｓｔｒｉｃｔｉｎｇＳｉｄｓフィールドを（ＮｔＱｕｅｒｙＩｎｆｏｒｍａｔｉｏｎＴｏｋｅｎ  ＡＰＩを介して）照会してこれがＮＵＬＬでないかどうかを確認することによってこの問題を解決し、ここでＮＵＬＬでなかった場合、親トークンは制限付きトークンであり、ＡＰＩはＴＲＵＥ（真）を戻す。テストが満足できなかった場合、親トークンは通常のトークンでありＡＰＩはＦＡＬＳＥ（偽）を戻す。続くステップ４２６または４２８のために、トークン自体は制限付きであるが制限付きＳＩＤを有しない親トークン（すなわち、権限が削除されているかおよび／またはＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹ  ＳＩＤＳである場合）は、制限付きでないとして処理される可能性があることに注意されたい。
【００４８】
ステップ４２４では、親トークンが制限付きである場合、ステップ４２４はステップ４２６に分岐し、ステップ４２６では、親トークンの制限付きセキュリティＩＤフィールドと、ＡＰＩの制限付きセキュリティＩＤ入力リストの両方にある任意のセキュリティＩＤは、新しいトークン８４の制限付きセキュリティＩＤフィールド９２に置かれる。制限付きセキュリティＩＤが両方のリストになければならないため、制限付き実行コンテキストが、制限付きセキュリティＩＤフィールド９２にさらなるセキュリティＩＤを追加することを阻止し、この場合、アクセスを減らすのではなく効果的にアクセスを増やすことになる。同様に、ステップ４２６で共通なセキュリティＩＤがなかった場合、少なくとも１つの制限付きＳＩＤを新しいトークン内の元のトークンから取り去るなどによって、作成された任意のトークンはそのアクセスを増やすことなく制限されなければならない。その他の場合は、新しいトークン内の空の制限付きＳＩＤフィールドはそのトークンが制限されていないことを示し、この場合、アクセスを減らすのではなく効果的にアクセスを増やすことになる。
【００４９】
あるいは、ステップ４２４で親トークンが通常のトークンであると判断された場合、ステップ４２８で新しいトークン８４のＲｅｓｔｒｉｃｔｉｎｇＳｉｄｓフィールド９２は入力フィールド内にリストされたものに設定される。これはセキュリティＩＤを追加するが、次に詳細に説明されるように制限付きＳＩＤを有するトークンが第２のアクセステストを受けるため、アクセスは実際には減らされることに注意されたい。
【００５０】
最後に、ステップ４３０も実行され、ここで新しいトークン８４内のＰａｒｅｎｔＴｏｋｅｎＩｄ９３は既存の（親）トークンのＴｏｋｅｎＩｄに設定される。これはオペレーティングシステムに、通常は親トークン以外には許可されていない場所で、そのトークンの制限付きのバージョンを使用するプロセスをのちに許可するオプションを提供する。
【００５１】
特に図６〜８を参照して本発明の動作の説明に戻ると、図６に表示されたように、制限付きプロセス９４が作成され、読取り／書込みアクセスでファイルオブジェクト７０を開こうと試みている。オブジェクト７２のセキュリティ記述子内では、ＡＣＬ８０はそこにリストされた多くのセキュリティＩＤおよび、各ＩＤに関して許可されたタイプのアクセスを有し、ここで「ＲＯ」は読取りのみのアクセスが許可されていることを示し、「ＷＲ」は読取り／書込みアクセスを示し、「ＳＹＮＣ」は同期化アクセスが許可されていることを示す。他の場合は「ＸＪｏｎｅｓ」が許可されたグループ内のメンバーシップを介してアクセスを許可されている場合でも、「ＸＪｏｎｅｓ」は特にオブジェクト７２へのアクセスを拒否されていることに注意されたい。さらに、関連付けられたこのトークン８４を有するプロセス９４は、このエントリーは「ＤＥＮＹ」（すなわち、ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹ）とマークされているため、トークン８４内の「バスケットボール」セキュリティＩＤを介して任意のオブジェクトへのアクセスを許可されないことになる。
【００５２】
セキュリティの目的のために、制限付きセキュリティコンテキストは第一に、Ｗｉｎｄｏｗｓ  ＮＴカーネル内で実現される。オブジェクト７２にアクセスしようと試みるために、プロセス９４はオブジェクトマネジャー７４に、アクセスが望ましいオブジェクトを識別する情報および、所望されるアクセスのタイプを提供する（図８、ステップ８００）。オブジェクトマネジャー７４はこれに応答して、ステップ８０２に示されたように、セキュリティメカニズム７８と共同して機能し、トークン８４内にリストされた（プロセス９４と関連付けられている）ユーザセキュリティＩＤおよびグループセキュリティＩＤをＡＣＬ８０内のエントリーに対して比較し、所望のアクセスが許可されるべきか拒否されるべきかを決定する。
【００５３】
ステップ８０４で一般に示されているように、アクセスがリストされたユーザまたはグループに関して許可されていない場合、セキュリティチェックはステップ８１４でアクセスを拒否する。しかし、ステップ８０４でアクセスチェックのユーザ部分およびグループ部分の結果が許可可能なアクセスを示した場合には、セキュリティプロセスはステップ８０６に分岐し、制限付きトークン８４が任意の制限付きセキュリティＩＤを有しているかどうかを決定する。有していない場合、追加の制限はなく、ここでアクセスチェックは完了し、ステップ８１２において、ユーザアクセスおよびグループアクセスのみに基づいてアクセスは許可される（そのオブジェクトへのハンドルが戻される）。このようにして、通常のトークンは本質的に以前と同じようにチェックされる。しかし、ステップ８０６によって決定されたように、トークンが制限付きセキュリティＩＤを含んでいる場合、ついでステップ８０８によって、制限付きセキュリティＩＤをＡＣＬ８０内のエントリーと比較することによって、第２のアクセスチェックが実行される。ステップ８１０でこの第２のアクセステストがアクセスを許可した場合、そのオブジェクトへのアクセスはステップ８１２で許可される。そうでない場合、アクセスはステップ８１４で拒否される。
【００５４】
図７で論理的に示すように、トークン８４の中に制限付きセキュリティＩＤが存在する時はいつでも、２つの部分からなるテストがこのように実行される。トークン８４内のセキュリティＩＤおよび所望のアクセスビット９６をオブジェクト７２のセキュリティ記述子に対して考慮することによって、通常のアクセステスト（ビットごとのＡＮＤ）および制限付きセキュリティＩＤのアクセステストの両方は、プロセスがそのオブジェクトへのアクセスを許可されるようにアクセスを許可しなければならない。本発明に必要ではないが上記のように、通常のアクセステストが最初に行われ、アクセスが拒否された場合には、さらなるテストは必要ではない。トークン内にＡＣＬの識別子に一致するセキュリティＩＤがないため、またはＡＣＬエントリーが特に、その中にあるセキュリティ識別子に基づいてトークンへのアクセスを拒否したためのどちらの理由でも、アクセスは拒否されることに注意されたい。別法としては、トークンを制限付きＳＩＤの多数の組を有するように構成し、たとえば、組Ａ  ＯＲ（組Ｂ  ＡＮＤ組Ｃ）がアクセスを許可するなど、これらのＳＩＤの評価をカバーするさらに複雑なブール式を伴う場合もある。
【００５５】
このように図６に示された例では、トークン８４（フィールド９２）内の制限付きＳＩＤのみが「インターネットエクスプローラ」を識別する一方、オブジェクトのＡＣＬ８０内には対応する制限付きＳＩＤがないため、図６に示された例では、オブジェクト７２へのアクセスはプロセス９４へは許可されない。ユーザは通常のトークンで実行するプロセスを介してオブジェクトへアクセスする権利を有していたが、プロセス９４はＡＣＬ内に「インターネットエクスプローラ」ＳＩＤ（非ＤＥＮＹ）を有するオブジェクトのみにアクセスできるようにするように、制限された。
【００５６】
アクセスのタイプを指定する代わりに、コーラ−が、指定されたＭＡＸＩＭＵＭ＿ＡＬＬＯＷＥＤアクセスを有する場合、これによって上記のように、アルゴリズムは最大のアクセスを決定するＡＣＬ８０をウォークスルーする。制限付きトークンで、１つでも任意のタイプのユーザアクセスまたはグループアクセスが許可された場合、ユーザおよびグループの実行に続いて許可可能なアクセス権のタイプ（複数可）は、第２の実行に関して所望のアクセスとして指定され、第２の実行はＲｅｓｔｒｉｃｔｅｄＳｉｄｓリストをチェックする。このようにして、制限付きトークンは通常のアクセスより少ないかまたは等しいアクセスを許可されることが確認される。
【００５７】
最後に、本発明のセキュリティモデルは、他のセキュリティモデルと共に使用できることに注意されたい。たとえば、オペレーティングシステムの上に常駐する、機能に基づいたセキュリティモデルは、本発明のオペレーティングシステムレベルのセキュリティモデルの上で使用することができる。
【００５８】
ジョブ
ジョブとは一組の編成化されたプロセスをその中に有するカーネルオブジェクトであり、各ジョブはそれに関連付けられた異なるタイプの制限を有する可能性がある。本発明によれば、制限付きトークンはＷｉｎｄｏｗｓ  ＮＴジョブオブジェクトに統合され、同じ制限の下に実行される多数のプロセスの管理を可能にできる。ジョブオブジェクト制限は次のように表される。
【００５９】
【表４】
0004809530.tif 000005
【００６０】
ここで、関連するＳｅｃｕｒｉｔｙＬｉｍｉｔＦｌａｇｓは、次のように表される。
【００６１】
【表５】
0004809530.tif 000006
【００６２】
これらの種々の情報の部分は、ＮｔＳｅｔＩｎｆｏｒｍａｔｉｏｎＪｏｂＯｂｊｅｃｔ  ＡＰＩを使用してジョブオブジェクト上で定でき、一方、プロセスはＮｔＡｓｓｉｇｎＰｒｏｃｅｓｓＴｏＪｏｂＯｂｊｅｃｔ  ＡＰＩを使用してジョブに割り当てられる。ジョブ上で定されたセキュリティ制限は、プロセスが割り当てられた時に実施される。ジョブを制限するために、ＪＯＢ＿ＯＢＪＥＣＴ＿ＳＥＣＵＲＩＴＹ＿ＦＩＬＴＥＲ＿ＴＯＫＥＮＳ制限フラグが設定され、これによって、ジョブに割り当てられているプロセスの主トークンは、セキュリティ制限情報内に提供されているＳｉｄｓＴｏＤｉｓａｂｌｅ、ＰｒｉｖｉｌｅｇｅｓＴｏＤｅｌｅｔｅおよびＲｅｓｔｒｉｃｔｅｄＳｉｄｓ情報を使用して、プロセスに関連付けられたトークンが上記のようにフィルタ処理されるのと同じ方法でフィルタ処理される。
【００６３】
図９に示されたように、ジョブ１１０は、ジョブＮｔＡｓｓｉｇｎＰｒｏｃｅｓｓＴｏＪｏｂＯｂｊｅｃｔ  ＡＰＩを介してそこに割り当てられた多くのプロセス（たとえばプロセス１１２〜１１４）を有する。各プロセス１１２〜１１４は、そこに関連付けられた各トークン１１６a〜１１６cを有し、これは「制限Ｒ」として示されたその制限に関して同じである。たとえば、これらがその下で実行されるトークン１１６a〜１１６cが所定のセキュリティＩＤ（たとえば管理ＳＩＤ）を使用不可にしており、一定の権限が削除され、および／または一組の制限付きセキュリティＩＤが追加されているため、ジョブオブジェクト１１０はその中にあるプロセス１１２〜１１４を制限し、所定の動作のみを行う。トークンは他のアクセス権に関しては同じであるため、この場合すべてのトークンは本質的に同じであるが、これは必要ではないことに注意されたい。プロセス（たとえばプロセス１１４）が他のプロセス１１８を生成した場合、同じ制限Ｒがそのトークン１１６dを介して新しいプロセス１１８に関連付けられていることをジョブオブジェクト１１０が確認するため、そのプロセス１１８は同じ制限Ｒを伴うジョブ１１０内で実行される。
【００６４】
ネットワーク上の制限付きトークン
本発明の別の態様によれば、制限付きトークンは、特に図１０〜１２を参照してここに説明されるように、ネットワーク上で使用できる。この目的のために、一定の認証プロトコルは、認証の時にクライアントが特別な制限を指定できるようにしている。たとえば、ケルベロスプロトコルは、チケットによって許可された権限を制限するフィールドを認証チケットに追加することによって制限の指定を可能にする。次に説明するように、この機能はクライアントのオペレーティングシステムおよびサーバのオペレーティングシステムによって使用でき、ネットワーク接続上で制限を実行する。
【００６５】
図１０に示すように、クライアント１３０がサーバ１３２への接続を望むとき、認証が要求される。ケルベロスプロトコルによれば、サーバ１３２への接続の認証はチケット１３４を介して達成される。チケットはまず、キーの分散センタ（ＫＤＣ）１３６として知られる、ネットワーク上のチケット発行機能から、クライアント１３０によって受信される。チケット１３４は一定期間の間再使用可能であり、これによってセッションが終わった時でも、チケット１３４が有効な間はクライアント１３０は認証プロセスを繰り返す必要がない。
【００６６】
このようにして図１１〜１２のフローチャートに示されたように、プロセス（たとえば、関連付けられた制限付きトークン１３９を有する制限付きプロセス１３８）が別のマシン１３２上の別のプロセス１４０へ認証された接続を作成しようと試みた時、ステップ１１００においてプロセス１３８は接続を要求する認証コードをそのオペレーティングシステム１４２の中で呼び出す。ケルベロスでは、ステップ１１０２において、オペレーティングシステムコード１４２はまず、サーバ１３２への既存の認証チケットを探す。既存のチケットがない場合は、ステップ１１０２はステップ１１０４に分岐し、コードはＫＤＣ１３６を呼び出してチケット１４４にサービスを要求する。ＫＤＣ１３６への要求の中で、クライアント１３０はチケット１４４の中に置かれるべき制限を提供する場合がある。しかし通常は、なにも含まれていない。一度クライアント１３０に戻ると、チケット１４４は認証（たとえば、クライアント要求、サーバチャレンジ、クライアント応答）が、クライアントとサーバの間で起こるようにする。
【００６７】
ステップ１１１０はクライアントプロセスが認証された時（元の接続を開始したプロセスが制限付きプロセス１３８であった場合）、またはのちに、クライアントのオペレーティングシステムがサーバ１３２への認証を求める要求を制限付きプロセス１３８から受け取った時のいずれでも起きる。ステップ１１１０では、制限付きプロセス１３８は、遠隔サーバプロセス１４０への認証された接続を要求する（すでにそれが行われていない場合）。ステップ１１１２ではそれに応答して、クライアントのオペレーティングシステム１４２は制限フィールド１４６の中に適切な制限が存在する、サーバ１３２への既存のチケットを探す。適切な制限が存在しない場合（たとえば、図１０内のＮＵＬＬとして示されたように）、ステップ１１１４ではオペレーティングシステム１４２は制限付きクライアントプロセス１３８上に置かれた制限を含み、ステップ１１１６では、クライアント１３０のチケット許可チケット１４４を使用してＫＤＣ１３６から新しいチケット１４８1を要求する。ＫＤＣ１３６はこれらの制限を、これが戻すチケット１４８1の制限フィールド１５０1内に含める。たとえば、制限は制限付きセキュリティＩＤのリスト、拒否のみとマークされるセキュリティＩＤのリスト、および／または削除する権限のリストを含む可能性がある。
【００６８】
クライアントプロセス１３８はついで、図１２のステップ１２００に示すように、そのチケットのコピー１４８2をサーバプロセス１４０に送る。サーバのオペレーティングシステム１５２がそのチケット１４８2からトークン１５４を構築する時、これは制限１５０2を認識し（ステップ１２０２）、ステップ１２０４において、これが作成した（制限付きの）トークン、すなわち制限付きトークン１５４に適用する。制限がない場合、通常のトークンはステップ１２０６を介して作成される。どの場合でも、サーバ１３２上のクライアントのアクセストークン１５４のコピーはクライアントマシン１３０上のプロセス１３８の対応するトークン１３９と同じ制限を有する。トークンを制限するために権限は削除されるが、一度削除されると、制限されたトークンが遠隔の場所に送られた時も知られないので、その遠隔の場所では後から作成しなおせないことに注意されたい。しかし、別法として、ビット付き権限を使用不可能にし、これによって、権限情報は制限付きトークンに残り、後から作成しなおすようにすることもできる。
【００６９】
制限付きプロセス１３８は認証コード（およびそのライブラリ）を介さずに、ＫＤＣ１３６からチケットを直接要求することができるが、プロセス１３８はユーザからパスワードを得なければチケットを得られないことに注意されたい。これは、プロセス１３８がクライアントのパスワードまたはチケット許可チケット１４４へのアクセスを有しないためである。これは制限付きプロセス１３８の能力を、オペレーティングシステム１４２内の認証コードによって実行されるものに効果的に制限する。
【００７０】
さらに、本発明はケルベロスを実装した分散コンピューティング環境（ＤＣＥ）内で使用できる。クライアントのために機能しているサーバが第２のサーバに接続する時、元のサーバの識別およびクライアントの識別の両方が送信される。第２のサーバはついで、両方の識別の組に基づいてアクセス制御決定を行うことができる。２つ以上のサーバがあった場合、他の間に入っているサーバの識別も送信される。
【００７１】
最後に、容易に認識できるように、本発明は、認証証明と共に、追加の情報（すなわち制限情報）がクライアントとサーバの間を通過可能にする任意の他の認証プロトコルで実現することも可能である。
【００７２】
上述の詳細な説明からわかるように、プロセスが、制限付きのコンテキストの中でその権利および権限のサブセットである別のプロセスを起動可能にする、改善されたセキュリティモデルが提供される。この目的のために、親トークンから制限付きトークンが作成され、制限付きトークンは、親トークンに関連してアクセスを許可せずにアクセスを拒否するセキュリティＩＤを含み、親トークンに関連する権限を削除し、および／または親トークンに関連して制限付きセキュリティＩＤを追加する。制限付きセキュリティＩＤが追加された場合、カーネルモードのセキュリティメカニズムは、アクセスがリソースに許可される前に、２つｎチェック、すなわち、リソースのアクセス制御リストに対する、ユーザ／グループに基づいたアクセスチェックおよび制限付きセキュリティＩＤアクセスチェックの両方が、所望のアクションのためにアクセスが許可という結果となることを要求する。
【００７３】
本発明は種々の変形および代替の構成を可能にするが、そのうち所定の図示された実施形態が図に示され、上記に詳細に説明された。しかし、本発明を開示された特定の形態に限定する意図はなく、逆に、本発明の精神と範囲に含まれるすべての変形例、代替の構成、等価物をカバーすることが目的であることを理解されたい。
【図面の簡単な説明】
【図１】  本発明を組み込むことのできるコンピュータシステムを表すブロック図である。
【図２】  本発明の一態様による、既存のトークンから制限付きのトークンを作成することを一般に表すブロック図である。
【図３】  プロセスがリソースにアクセスできるかどうかを決定するための種々の構成要素を一般に表すブロック図である。
【図４】  本発明の一態様による、既存のトークンから制限付きのトークンを作成する一般のステップを表すフローチャートである。
【図５】  本発明の一態様による、既存のトークンから制限付きのトークンを作成する一般のステップを表すフローチャートである。
【図６】  本発明の一態様による、リソースにアクセスを試みる関連付けられた制限付きのトークンを有するプロセスを一般に表すブロック図である。
【図７】  本発明の一態様による、プロセスのオブジェクトへアクセスすることを決定するための、関連付けられた制限付きのトークンを有する論理を一般に表すブロック図である。
【図８】  本発明の一態様による、リソースへのプロセスアクセスを許可するかどうかを決定する時にとられる一般のステップを表すフローチャートである。
【図９】  共通の制限を伴う多数のプロセスをその中に有するジョブオブジェクトを示すブロック図である。
【図１０】  本発明の別の態様による、ネットワーク上で制限付きのトークンを実現することを示すブロック図である。
【図１１】  ネットワーク上で制限付きのトークンを使用する時にとられる一般的なステップを表すフローチャートである。
【図１２】  ネットワーク上で制限付きのトークンを使用する時にとられる一般的なステップを表すフローチャートである。
【図１】
0004809530.tif 000007
【図２】
0004809530.tif 000008
【図３】
0004809530.tif 000009
【図４】
0004809530.tif 000010
【図５】
0004809530.tif 000011
【図６】
0004809530.tif 000012
【図７】
0004809530.tif 000013
【図８】
0004809530.tif 000014
【図９】
0004809530.tif 000015
【図１０】
0004809530.tif 000016
【図１１】
0004809530.tif 000017
【図１２】
0004809530.tif 000018