(57)【特許請求の範囲】
【請求項１】
ユーザーが複数の仮想的なロケーションのうち１つのロケーションからネットワークに選択的に接続することができるコンピュータ・ネットワーク上のシステムにおいて、改善されたネットワーク・セキュリティを提供する方法であって、
前記システムの識別機構が、前記ユーザーが接続しているロケーションを決定するステップと、
前記識別機構が、前記ユーザーが接続している前記ロケーションを含む基準に基づいて、少なくとも２つの異なるアクセス・レベルから前記ユーザーのアクセス・レベルを選択するステップと、
前記識別機構が、前記ユーザーを前記ネットワークに接続するステップと、
前記システムのセキュリティ・プロバイダが、前記ユーザーのアクセス・レベルに応じてネットワーク・リソースへのアクセスを制限するために、前記ユーザーの識別に基づいて前記ユーザーのアクセス権を定義するアクセス・トークンから、前記ユーザーのアクセス・レベルに応じてアクセス権が制限された制限付きトークンを作成するステップであって、該制限付きトークンは、前記アクセス・レベルに応じた前記ユーザーのセキュリティ識別子および前記ユーザーが属するグループのセキュリティ識別子を含む、作成するステップと、
前記システムの実施機構が、前記制限付きトークン内の前記ユーザーのセキュリティ識別子および前記グループのセキュリティ識別子と、前記ネットワーク・リソースに関連付けられたアクセス制御リスト内のエントリとを比較することによって、前記ネットワーク・リソースへの前記ユーザーのアクセスを決定するステップと
を備えることを特徴とする方法。
【請求項２】
前記識別機構が、前記ユーザーに、該ユーザーが接続している前記ロケーションに応じたインターネット・プロトコル・アドレスを割り当てるステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記識別機構が、前記ユーザーが接続しているロケーションを決定するステップは、前記ユーザーに割り当てられたインターネット・プロトコル・アドレスを査定するステップを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記識別機構が、前記少なくとも２つの異なるアクセス・レベルからアクセス・レベルを選択するステップは、前記インターネット・プロトコル・アドレスに従って前記アクセス・レベルを選択するステップを含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記識別機構が、前記ユーザーが接続しているロケーションを決定するステップは、前記ユーザーがリモート・アクセス・サーバを介して前記ネットワークに接続していることを決定するステップを含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記識別機構が、前記ユーザーがダイアルアップ接続を介して接続しているかどうかを決定するステップをさらに備えることを特徴とする請求項５に記載の方法。
【請求項７】
前記ユーザーがダイアルアップ接続を介して接続していると決定されたとき、前記識別機構が、
前記ユーザーが接続している電話番号を決定するステップと、
前記電話番号を登録済みユーザーのリストと比較するステップと
をさらに含み、
前記識別機構が、前記アクセス・レベルを選択するステップは、前記電話番号が前記リスト内にある場合にはあるアクセス・レベルを選択し、前記電話番号が前記リストにない場合には別のアクセス・レベルを選択するステップを含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記識別機構が、前記ユーザーが接続しているロケーションを決定するステップは、前記ユーザーがリモート・アクセス・サーバを介して前記ネットワークに接続しているかどうかを決定するステップを含み、
前記ユーザーがリモート・アクセス・サーバを介して接続しているとき、前記アクセス・レベルを選択するステップは、より多くの制限付きアクセス権に対応するアクセス・レベルを選択するステップを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記識別機構が、前記ユーザーが接続しているロケーションを決定するステップは、前記ユーザーがイントラネットを介して前記ネットワークに接続していることを決定するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１０】
前記識別機構が、前記ユーザーが接続しているロケーションを決定するステップは、前記ユーザーが仮想的な組織内ネットワークを介して前記ネットワークに接続していることを決定するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
前記制限付きトークン内の前記ユーザーのセキュリティ識別子および前記グループのセキュリティ識別子は、前記ユーザーの資格認定情報と前記アクセス・レベルとに従って決定された、前記ユーザーのアクセス権を示すことを特徴とする請求項１に記載の方法。
【請求項１２】
前記制限付きトークンは、前記アクセス・トークンに少なくとも１つの制限付きセキュリティ識別子を追加することによって作成されることを特徴とする請求項１に記載の方法。
【請求項１３】
前記アクセス・トークンは、前記ユーザーに関連付けられた１つまたは複数の特権を含み、前記制限付きトークンは、前記ユーザーの前記アクセス・レベルに応じて前記アクセス・トークンから少なくとも１つの特権を削除することによって作成されることを特徴とする請求項１に記載の方法。
【請求項１４】
前記アクセス・トークンは、前記ユーザーのセキュリティ識別子および前記ユーザーの属するグループのセキュリティ識別子を含み、前記制限付きトークンは、該制限付きトークン内の前記ユーザーのセキュリティ識別子または前記グループのセキュリティ識別子を介したアクセスを拒否するように、前記アクセス・トークン内の対応する前記ユーザーのセキュリティ識別子または前記グループのセキュリティ識別子の属性情報を変更することによって作成されることを特徴とする請求項１に記載の方法。
【請求項１５】
前記ユーザーを前記ネットワークに接続するステップは、前記ユーザーを、質疑応答型プロトコルを介して認証するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１６】
前記ユーザーを前記ネットワークに接続するステップは、チケット発行機能によって発行されたチケットを前記ユーザーから受け取ることによって、前記ユーザーを認証するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１７】
前記ユーザーを前記ネットワークに接続するステップは、認証機関によって発行された証明を前記ユーザーから受け取ることによって、前記ユーザーを認証するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１８】
前記ネットワーク・リソースへの前記ユーザーのアクセスを決定するステップは、前記制限付きトークンに追加された前記少なくとも１つの制限付きセキュリティ識別子と、前記アクセス制御リスト内のエントリとをさらに比較することを含むことを特徴とする請求項１２に記載の方法。
【請求項１９】
ユーザーが複数の仮想的なロケーションのうち１つからネットワークへ選択的に接続することができるコンピュータ・ネットワークにおいて、改善されたネットワーク・セキュリティを提供するためのシステムであって、
ユーザーが接続している仮想的なロケーションを決定し、決定したロケーションに基づいて少なくとも２つの異なるアクセス・レベルから１つのアクセス・レベルを選択する識別機構と、
前記ユーザーの前記アクセス・レベルに応じてネットワーク・リソースへのアクセスを制限するために、前記ユーザーの識別に基づいて前記ユーザーのアクセス権を定義するアクセス・トークンから、前記ユーザーのアクセス・レベルに応じてアクセス権が制限された制限付きトークンを作成する、セキュリティ・プロバイダであって、該作成される制限付きトークンは、前記アクセス・レベルに応じた前記ユーザーのセキュリティ識別子および前記ユーザーが属するグループのセキュリティ識別子を含む、セキュリティ・プロバイダと、
前記制限付きトークン内の前記ユーザーのセキュリティ識別子および前記グループのセキュリティ識別子と、前記ネットワーク・リソースに関連付けられたアクセス制御リスト内のエントリとを比較することによって、前記ネットワーク・リソースへの前記ユーザーのアクセスを決定する、実施機構と
を備えたことを特徴とするシステム。
【請求項２０】
前記識別機構は、前記決定したロケーションに基づいて前記ユーザーにインターネット・プロトコル・アドレスを割り当てることを特徴とする請求項１９に記載のシステム。
【請求項２１】
前記識別機構は、前記ユーザーに割り当てられたインターネット・プロトコル・アドレスを査定することを特徴とする請求項１９に記載のシステム。
【請求項２２】
前記識別機構は、前記インターネット・プロトコル・アドレスに従って前記アクセス・レベルを選択することを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記識別機構は、前記ユーザーがリモート・アクセス・サーバを介して前記ネットワークに接続していることを決定することを特徴とする請求項１９に記載のシステム。
【請求項２４】
前記識別機構は、さらに、前記ユーザーがダイアルアップ接続を介して接続していることを決定することを特徴とする請求項２３に記載のシステム。
【請求項２５】
前記識別機構に接続された登録済み電話番号のリストと発呼者ＩＤ機構とをさらに備え、前記識別機構は、前記発呼者ＩＤ機構にアクセスして前記ユーザーの電話番号を決定し、前記リストにアクセスして前記電話番号が前記リスト内にあるかどうかを決定し、前記電話番号が前記リスト内にある場合は或るアクセス・レベルを決定し、前記番号が前記リスト内にない場合は別のアクセス・レベルを決定することを特徴とする請求項２４に記載のシステム。
【請求項２６】
前記識別機構は、前記ユーザーがリモート・アクセス・サーバを介して前記ネットワークに接続していると決定したとき、前記ネットワークへの直接接続に対して選択される前記ユーザーのアクセス権に比較してより制限されたアクセス権に相当するアクセス・レベルを前記ユーザーに対して選択することを特徴とする請求項２３に記載のシステム。
【請求項２７】
前記識別機構は、前記ユーザーがイントラネットを介して前記ネットワークに接続している時日を決定するための手段を含むことを特徴とする請求項１９に記載のシステム。
【請求項２８】
前記識別機構は、前記ユーザーが仮想的な組織内ネットワークを介して前記ネットワークに接続している時を決定するための手段を含むことを特徴とする請求項１９に記載のシステム。
【発明の詳細な説明】
【０００１】
（発明の分野）
本発明は、一般にコンピュータ・システムに関し、より詳細には、コンピュータ・システムの改善されたセキュリティ・モデルに関する。
【０００２】
（発明の背景）
現在のコンピュータ・セキュリティ・システムは、ユーザーの資格認定（credentials）に従って与えられた許可に基づいて、ネットワーク・リソースへのユーザーのアクセスを決定する。このユーザー中心のモデルは、増大するモバイル／リモート（mobile/remote）ユーザー人口に大きな融通性を提供する。たとえば、リモート・アクセス・サーバおよびインターネットの接続性は、ユーザーが仮想的に任意のロケーションから会社のリソースにユーザーに意識させないで（transparently）アクセスすることを可能にする。
【０００３】
この融通性はユーザーおよびネットワーク所有者（たとえば会社、企業）の両方に利点を提供するが、このような増大した有用性および簡単な接続性は本質的に、許可されないアクセスについてのリスクを引き上げる。暗号化されたネットワーク通信は有線盗聴を防ぐが、機密情報のある企業リソースへのリモート・アクセスを許すという本質的なリスクを依然として有している。実際には、リソース（ファイルなど）が送信されるときに保護されているにもかかわらず、正式に認可されたユーザーが適正な任意のロケーションからアクセスされることを会社が望まない企業リソースの機密情報を含むサブセットがある可能性が依然としてある。
【０００４】
たとえば、ラップトップ・コンピュータのユーザーが飛行機の上で作業をしているときなどに、非常に機密性のある会社の戦略を意図しない閲覧者に不注意に表示する場合がある。新しい、広い視野角のラップトップ画面では、他の乗客がモニタの内容をのぞき見することを防ぐことはさらに困難である。同様に、モバイル・ユーザーの人口は増大しているので、ノートブック・コンピュータの盗難または紛失はさらに、機密性のある企業データのセキュリティを脅かしている。ユーザーのアカウントおよびパスワードも、特に盗まれたラップトップ上に維持されている場合は、盗まれる可能性がある。ユーザーが適切な資格認定を有する限り、既存のセキュリティ機構（security mechanism）は、リモートからファイルをダウンロードし、他のリモート・アクションを実行することが容易とし、したがって、これらのセキュリティ・リスクおよび他のセキュリティ・リスクに寄与する。
【０００５】
簡単に言えば、リモート・アクセス・サーバ（ＲＡＳ）およびインターネットの接続性は、ユーザーが仮想的な任意のロケーションから企業リソースにアクセスできるようにする。しかし、一定のロケーション（特にリモート・ロケーション）は他よりも安全ではない。たとえば、軽便でアクセスが増大されているため、ラップトップ・コンピュータへダウンロードされたファイルは、会社のオフィス内にあるデスクトップ・マシン上のファイルより簡単に盗める。同様に、許可されない人がユーザーのアカウントおよびパスワードを得る可能性もあり、これによって、彼らがリモート・ロケーションから会社のリソースへアクセスしようとする可能性が最大になる。
【０００６】
（発明の概要）
簡単に言えば、本発明は、ネットワーク・リソースへのアクセスが接続しているユーザーのロケーションを含む情報に基づいている改善されたコンピュータ・ネットワーク・セキュリティ・システムおよび方法を提供する。通常は、ユーザーのロケーションの信頼性がより低ければ、そのユーザーに割り当てられたアクセス権はより制限される。識別機構（discrimination mechanism）は、ローカル・ユーザー、イントラネット・ユーザ、およびダイアルアップ・ユーザーを互いに区別するなど、いくつかのカテゴリのセキュリティ方針に関してユーザーのロケーションを決定する。セキュリティ・プロバイダは、ロケーションおよびユーザーの資格認定を含む情報に基づいて、そのユーザー用アクセス・トークンを設定するなどによって、そのユーザーのアクセス権を確立する。実施機構（enforcement mechanism）は、そのユーザーのために設定されたアクセス権を使用して、リソースへのアクセスを許可または拒否するかどうかを決定する。ロケーションに基づいたアクセス権は、セキュリティ方針に従って、ユーザーの通常のアクセス権に関して制限することができる。たとえば、ローカル・ユーザーのプロセスは、ユーザーの通常のアクセス・トークン内のユーザーに基づいたセキュリティ情報を越えて制限することはできないが、一方、ダイアルアップ接続を介しての同じユーザーの接続は制限付きプロセスを有する場合がある。好ましい制限付きトークンを使用して、信頼性の低いロケーションから接続しているユーザーのアクセスを制限することによって、ロケーションに基づいた識別を実行する。制限付きトークンが使用され、信頼性の低いロケーションからのユーザー接続でのアクセスを制限するによるロケーション・ベースの識別を実行することは、望ましいことである。
【０００７】
他の目的および利点は、図面を参照してなされる次の詳細な説明から明らかになろう。
【０００８】
（詳細な説明）
例としての動作環境
図１および以下の考察は、本発明が実現できる適切なコンピューティング環境の簡単で一般的な説明を提供すること、を意図している。必要ではないが、本発明は、パーソナル・コンピュータによって実行されるプログラム・モジュールなどのコンピュータ実行可能な命令の一般的なコンテキスト内で説明される。一般に、プログラム・モジュールは、ルーチン、プログラム、オブジェクト、構成要素、データ構造、そして特定のタスクを実行するか、特定の抽象的なデータ・タイプに道具を提供するもの実現するなどを含む。さらに、当業者であれば、本発明は、ハンド・ヘルド・デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースのプログラミング可能な消費者用電気製品、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータなどを含むほかのコンピュータ・システム構成でも実行できることが理解されるであろう。本発明はまた、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境内でも実行できる。分散コンピューティング環境では、プログラム・モジュールはローカル・メモリ記憶デバイスおよびリモート・メモリ記憶デバイスの両方に配置される場合がある。
【０００９】
図１を参照すると、本発明を実現するための１例としてのシステムは、従来のパーソナル・コンピュータ２０などの形の汎用コンピューティング・デバイスを含み、汎用コンピューティング・デバイスは、処理ユニット２１、システム・メモリ２２、および処理ユニット（processing unit）２１のためのシステム・メモリを含む種々のシステム構成要素を結合するシステム・バス２３を含む。システム・バス２３は、メモリ・バスまたはメモリ・コントローラ、周辺バス、種々のバス・アーキテクチャのうち任意のアーキテクチャを使用するローカル・バスを含むいくつかのタイプのバス構成のどれでも含むことができる。システム・メモリは、読み取り専用メモリ（ＲＯＭ）２４およびランダム・アクセス・メモリ（ＲＡＭ）２５を含む。基本入出力システム２６（ＢＩＯＳ）は、ＲＯＭ２４内に格納され、起動時などにパーソナル・コンピュータ２０内の構成要素の間で情報を転送するのに役立つ基本的なルーチンを含んでいる。パーソナル・コンピュータ２０はさらに、図示されてはいないがハードディスクから読み出したり書き込んだりするためのハードディスク・ドライブ２７、取り外し可能な（removable）磁気ディスク２９から読み出したり書き込んだりするための磁気ディスク・ドライブ２８、および、ＣＤ−ＲＯＭまたは他の光媒体など、取り外し可能な光ディスク３１から読み出したり書き込んだりするための光ディスク・ドライブ３０を含む場合がある。ハードディスク・ドライブ２７、磁気ディスク・ドライブ２８、および光ディスク・ドライブ３０はそれぞれ、ハードディスク・ドライブ・インタフェース３２、磁気ディスク・ドライブ・インタフェース３３、および光ドライブ・インターフェース３４によってそれぞれシステム・バス２３に接続されている。ドライブとその関連付けられたコンピュータ読み取り可能媒体は、パーソナル・コンピュータ２０のためにコンピュータ読み取り可能命令、データ構造、プログラム・モジュールおよびほかのデータの、不揮発性のストレージを提供する。ここに説明された例としての環境は、ハードディスク、取り外し可能磁気ディスク２９および取り外し可能光ディスク３１を使用しているが、当業者であれば磁気カセット、フラッシュメモリ・カード、ディジタル・ビデオ・ディスク、ベルヌーイ・カートリッジ、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）などの、コンピュータによってアクセス可能なデータを格納できる他のタイプのコンピュータ読み取り可能な媒体も例としての動作環境内で使用できることが理解されるであろう。
【００１０】
オペレーティング・システム３５（好ましくはＷｉｎｄｏｗｓ  ＮＴ）、１つまたは複数のアプリケーション・プログラム３６、ほかのプログラム・モジュール３７およびプログラム・データ３８を含むいくつかのプログラム・モジュールがハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５に格納できる。ユーザーは、キーボード４０およびポインティング・デバイス４２などの入力デバイスを介してパーソナル・コンピュータ２０にコマンドおよび情報を入力できる。他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲーム・パッド、サテライト・ディッシュ（satellite dish）、スキャナなどを含むことができる。これらおよび他の入力デバイスはしばしば、システム・バスに結合されたシリアルポート・インタフェース４６を介して処理ユニット２１に接続されているが、パラレル・ポート、ゲーム・ポートまたは汎用シリアルバス（ＵＳＢ）などの他のインターフェースによって接続されている場合もある。モニタ４７または他のタイプの表示デバイスもまた、ビデオ・アダプタ４８などのインターフェースを介してシステム・バス２３に接続されている。モニタ４７の外に、パーソナル・コンピュータは典型的にはスピーカおよびプリンタなどの他の周辺出力デバイス（図示せず）を含む。
【００１１】
パーソナル・コンピュータ２０は、リモート・コンピュータ４９など１つまたは複数のリモート・コンピュータへの論理接続を使用してネットワーク化された環境内で動作する場合がある。リモート・コンピュータ４９は、他のパーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア・デバイス（peer device）または他の共通ネットワーク・ノードであり、典型的にはパーソナル・コンピュータに関連して上記に説明された要素の多くまたはすべてを含むことができるが、メモリ・ストレージ・デバイス５０のみが図１に示されている。図１に描かれた論理接続は、ローカルエリア・ネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２を含む。このようなネットワーク化環境はオフィス、全社的コンピュータ・ネットワーク、イントラネットおよびインターネットに普通に見られる。
【００１２】
パーソナル・コンピュータ２０はＬＡＮネットワーク化環境内で使用される際には、ネットワーク・インターフェースまたはアダプタ５３を介してローカル・ネットワーク５１に接続される。パーソナル・コンピュータ２０はＷＡＮネットワーク化環境内で使用される際には、典型的にはモデム５４または他の手段を含み、インターネットなど広域ネットワーク５２上で通信を確立する。モデム５４は内部あるいは外部に置かれる場合もあるが、シリアルポート・インタフェー４６を介してシステム・バス２３に接続されている。ネットワーク化された環境では、パーソナル・コンピュータ２０またはその一部に関連して描かれたプログラム・モジュールは、リモートのメモリ・ストレージ・デバイス内に格納される場合がある。示されたネットワーク接続は例としてのものであって、コンピュータの間で通信リンクを確立する他の手段も使用できることが明らかであろう。
【００１３】
ロケーション識別
本発明の一視点によれば、（ユーザーの資格認定に基づいたユーザーの通常のアクセス権の他に）ユーザーのロケーションに基づいてリソースへのアクセスを決定する方法およびシステムが提供される。たとえば、ローカルな安全なロケーションにいると決定された有効なユーザーには彼らの完全なアクセス権を与えられるが、一方、リモートのロケーションにいるユーザーは制限付きのアクセス権を与えられる。さらに、制限の量はリモート・アクセスのタイプに基づいて変化させることもできる。
【００１４】
例として、図２はユーザーが（ローカル・マシン（複数可）を含む）企業ネットワーク６０に接続することができる、多くのロケーションを示す。ユーザーは（図１に示されたようにＬＡＮ５１およびネットワーク・インターフェース５３など）ローカルエリア・ネットワークを介してコンピュータ６２1〜６２nへ接続することができる。他のユーザーはたとえばＴ１接続を介してリモートのオフィス・サーバ６４1〜６４nへ接続し、さらに他のユーザーは仮想的な組織内（ＶＰＮ）６６を介してインターネットを介して接続する場合がある。さらにべつのユーザーは、任意の数のリモート・アクセス・サーバ（たとえば６８1〜６８2）を介して、他のロケーション（図示せず）から多くの方法で接続できる。
【００１５】
本発明に遵守すれば、ネットワーク・リソースへアクセスするためにユーザーに許可されたアクセスのレベルは、所与のユーザーが接続した（仮想的な）ロケーションに依存する。たとえば、ＬＡＮ６２1を介してローカル・マシン６０に接続されたユーザーには完全なアクセス権を与えられるが、リモート・オフィス６４1を介したユーザーにはいくらか制限付きの権利、ＲＡＳ６８1、６８2、またはＶＰＮ６６を介したユーザーにはかなり制限付きのアクセス権を与えられる場合がある。
【００１６】
ここに使用されているように、用語「ロケーション」は、接続がそこから発生しているという距離に関連する物理的な概念ではなく、接続ロケーションのタイプに関する論理的な概念であることが容易に分かるであろう。たとえば、ユーザーは任意のタイプの電話サービスを有する、仮想的な任意の物理的なロケーションからＲＡＳ６８2を介してネットワーク６０に接続できる。同様に、ローカル・マシン６０から比較的（物理的に）遠い可能性のある「イントラネット」のロケーションから接続する場合がある。実際に、ＲＡＳ６８1、６８2ダイアルアップ・ユーザーは、Ｔ１回線を介してリモート・オフィス６４1で接続しているユーザーよりも物理的な距離においては近い可能性があるが、ダイアルアップ・ユーザーは通常は安全性が低いと考えられている。このように、ここに使用されているようなロケーション、ユーザーが接続することのできる各ロケーションは、物理的なロケーションというより仮想的なロケーションと考えられる。それにもかかわらず、本発明はさらに、ユーザーの物理的なロケーションが実際に知られている場合には、物理的なロケーションに関連していくらかの動作をする場合もある（たとえば、本発明はさらに発呼者ＩＤを介して、所定のエリア・コードから呼び出すすべてのＲＡＳユーザーへアクセスを制限する場合もある）。
【００１７】
ロケーション識別を実行するために、ユーザーのロケーションを確実に決定するための機構／プロセス６７が（たとえばネットワーク・マシン６０内に）提供される。機構／プロセス６７は、１つのマシン内に種々の構成要素を備える場合もあるし、ネットワーク内の種々の構成要素の間で分散される場合もある。さらに、ここに説明されたように、ＩＰアドレスのロケーション識別に関しては２つの異なる機構がある。第１の機構はインターネット・ロケーション・サービス（ＩＬＳ）６９に基づいており、別の機構は種々のロケーションにいるクライアントに一定の範囲のＩＰアドレス（好ましくはディレクトリ・サービスによって管理されている）を割り当てること、そして信頼性のより低いロケーションから信頼性のより高いＩＰアドレスを使用することを防ぐために信頼できるルータを使用する、こと、に基づいている。どちらの方法もルーティング機構、および明確な信頼できるアクセスポイントを備えた任意のネットワーク上で機能する。
【００１８】
ユーザーが信頼できるロケーションにいないかどうかを決定する第１の（ＩＬＳ）方法は、機構６７が、そのユーザーがリモート・アクセス・サーバ（ＲＡＳ）を介して接続しているかどうかをチェックすることである。その際に、リモート・アクセス・サーバを介して接続しているのであれば、そのユーザーは、リモートで信頼性がより低い。この目的のために、図３のステップ３００によって表されたように、ＲＡＳがリモート・ユーザーのログオンを認証するとき、ＲＡＳはユーザーにインターネット・プロトコル（ＩＰ）アドレスを割り当て、このユーザーおよびＩＰアドレスをＩＬＳ（インターネット・ロケーション・サービス）６９で登録する。図３の流れ図に示すように、ＩＰアドレスがＩＬＳにリストされている場合（ステップ３０２）、ユーザーはこのＲＡＳクラスタを介してログオンしているので、信頼できない。このようなユーザーには、次に詳細に説明されるように、一定の削減されたアクセス・レベルを設定し（ステップ３０４）、次いでそのレベルを使用して（制限付きの）アクセス権を割り当てる（ステップ３１０）などによって、制限付きのアクセスを与えられる。
【００１９】
しかし、ユーザーのＩＰアドレスがＩＬＳ６９内でＲＡＳ  ＩＰアドレスとしてリストされていない場合、そのユーザーは必ずしもローカルでもなく信頼もできない。例として、ユーザーがヨーロッパのＲＡＳサーバを介してログオンし、次いでそこを介してＣｈａｒｌｏｔｔｅ（ノースカロライナ）ドメインへアクセスしたい場合、Ｃｈａｒｌｏｔｔｅ  ＲＡＳ  ＩＬＳはそのローカルＩＬＳにリストされたヨーロッパのＲＡＳ接続を有していない。したがって、ローカルＩＬＳ６９にリストされていないユーザーについては、ユーザーのロケーションを決定するために追加の情報が必要になる。
【００２０】
追加情報の１つの断片は割り当てられたＩＰアドレスであり、これはステップ３０６で査定される。このＩＰアドレスが、ローカル・マシンによって割り当てられたローカルな、信頼できるＩＰアドレスの範囲内にない場合、ユーザーはローカルではない。したがって、ステップ３０６における機構／プロセス６７はステップ３０４に分岐し、ここでは上記のようにレベルは信頼できないと設定される。しかしアドレスがローカルな信頼できるＩＰアドレスの範囲内にある場合、ユーザーはローカルではあってしかもＲＡＳを介して接続しておらず、したがって信頼できる。このようなユーザーには、以下に詳細に説明されるように、ユーザーに信頼できるアクセス・レベルを割り当て（ステップ３０８）、次いでそのレベルを使用してアクセス権を割り当てる（ステップ３１０）などによって、通常のアクセスが与えられる。
【００２１】
接続のための完全なルーティング・パスはサーバに使用可能であり、したがってロケーションを決定するときに、アクセスは、ユーザーのパケットがルーティングされているもっとも信頼性の低いロケーション（すなわち「もっとも弱いリンク」）に基づいて割り当てられる。さらに、ＩＰアドレスが「信頼できない」ロケーションの範囲内にないとき、信頼できる範囲内にあるとは仮定されず、ロケーション識別の性質は排他的ではなく包括的であり、すなわち、信頼できるＩＰ範囲のリストは信頼できないロケーションのリストを脱落することによってレベルを割り当てるのではなく、レベルを割り当てることをテストされる。
【００２２】
他の電子セキュリティ・システムと同様に、一般に、本発明が使用される配慮のレベルはまた、全体的なセキュリティの結果についても責任を有する。たとえば、ネットワークを異なる信頼レベルで分離するときに配慮が行われるべきであり、細目は適切にルーティングされるべきであり、内部の手続きはたとえば、だれかが個人的な使用のために会社のオフィス内のデスクトップ・マシン上にＲＡＳサーバをインストールできないようにすべき、などである。
【００２３】
上記の例は簡単な、２つのレベルのローカルな識別機構６７を提供する。しかし、多数の信頼レベル制御をより細かく細分化するために、ＩＰアドレスは、ユーザーが接続しているロケーションに関する追加のロケーション情報に対応する範囲内でサーバによって割り当てられることもできる。ＲＡＳサーバはさらにロケーション識別機構７１で構成され、「許可された」電話番号からの発呼者に関しては１つの範囲で、無名のまたは登録されていない電話番号に関しては別の範囲で、ＩＰアドレスを割り当てることもできる。機構／プロセス７１は、上記の機構／プロセス６７と同じまたは同様の構成要素および追加の構成要素を含み、１つのマシン内にある場合もあり、またはネットワーク内の多くのマシンの間で分散されている場合もあることに注意されたい。しかし、より細かい細分性を提供する他に、ドメイン・サーバにおいて信頼できるＩＰアドレス範囲を維持すると、照会時にＩＬＳ６９でチェックするより時間がかからない。さらに、次に明らかになるように、全体的なセキュリティを達成するには、ロケーションマッピングへのグローバルなアドレスのデータベース、信頼できるアドレス割り当ておよび安全なルータ／ゲートウェイを含む、３つの部分の機構が一般にあることが明らかであろう。
【００２４】
次の表は、架空の会社のために恣意的に設定された所定の方針に基づいて、ユーザーに割り当てられる可能性のある信頼レベルおよびＩＰアドレスを示したものである。ローカル・マシンへ直接（たとえばＬＡＮインターフェース・カード５３を介して）接続しているユーザーはレベル０の信頼性である。
【００２５】
【表１】
0004625181.tif 000002
【００２６】
例として、図４はユーザーがＲＡＳサーバ（たとえば、６８2）へ接続する際に経由するユーザー接続の、３つの異なるタイプを示す。第１のユーザーはＲＡＳ登録済み電話番号からダイアルインすることによって、リモート・コンピュータ７０1をＲＡＳサーバ６８2へ接続し、第２のユーザーは未登録またはブロックされた電話番号を介してリモート・コンピュータ７０2から接続し、第３のユーザーは任意の電話番号から接続する。最初の２人のユーザーは自分がシステムの許可されたユーザーであることを主張するユーザー認証を有するが、第３のユーザーは許可されたユーザーであると主張せず、ゲストとして接続しようとしているのみである。アクセス・レベルを決定するために、ＲＡＳサーバ６８2はまず、発呼者ＩＤ７４を介して、呼び出し側コンピュータの電話番号を決定する。電話番号が使用可能な場合（たとえば発呼者によってブロック（妨害）されていない場合）、ＲＡＳサーバ６８2は、データベース（またはテーブル）７２に問い合わせる。このデータベースは、リソースへの拡大されたアクセスを許可されている登録済み電話番号のリストを保持している。  この方法で、登録済み番号から呼び出すリモート・コンピュータ７０1のユーザーに対して、未登録の電話番号またはブロックされた電話番号から呼び出すリモート・コンピュータ７０2のユーザーよりも、リソースへのより大きなアクセスを与えることが可能になる。さらに、７０1のユーザー、７０2のユーザーの双方は、ゲスト・ユーザ７０3の電話番号にかかわらず、ゲスト・ユーザ７０3よりも大きなアクセス権を有することが可能になる。たとえば、リモート・コンピュータ７０3のユーザーは公共サーバ７６上のファイルへのアクセスのみを許可されるが、一方、未登録の番号から呼び出すユーザー・コンピュータ７０2は、公共サーバ７６および従業員サーバ７８へのアクセスを有する可能性がある。最後に、登録済み番号から呼び出すユーザー・コンピュータ７０1は、公共サーバ７６、従業員サーバ７８、および機密サーバ８０にアクセスを有するが、トップ・シークレットサーバ８２にはアクセスを有しない可能性がある。このような区別は、会社が任意の数のアクセス方針を設定することを可能にする。上記の例では、移動中の従業員は未登録のロケーションから呼び出して一部の従業員レベルのファイルにアクセスすることはできるが（さらに彼らのユーザー資格認定によって制限される）、しかし機密ファイルにはアクセスできないことになる。機密ファイルは、ユーザーの家または登録済み電話番号を有する他の知られたロケーションからのみアクセスでき、一方、トップ・シークレット・ファイルはどのＲＡＳ接続を介してもアクセスできない。
【００２７】
まとめると、図５〜６は、既定の方針に基づいてアクセス・レベルが割り当てられる方法を示す、例としての流れ図を含む。図５のステップ５００でユーザーがローカル・マシン６０を介して接続している場合、ステップ５０２で信頼レベルは０に設定され、これは次いでステップ５１６に続き、ここではアクセス権は信頼レベルに基づいて（部分的に）割り当てられる。しかし、ローカル・マシンを介して接続していない場合、プロセス／機構７１は図６に続き、ここではリモート接続のタイプが割り当てられたＩＰアドレスを介して信頼レベルを決定する。図６のステップ５２０でユーザーがダイアルアップ接続を介して接続していない場合、ステップ５２０はステップ５２２へ分岐し、そのユーザーに割り当てられたＩＰアドレスは、ローカル・イントラネット・ユーザのために保存されたアドレスの範囲内である。この簡単な例では、ユーザーはローカル・マシンに直接接続するか、イントラネット接続を介するかまたはダイアルアップ接続を介して接続するかのいずれかであることに注意されたい。
【００２８】
しかし、ステップ５２０でユーザーがダイアルアップ接続を介して接続していると検出された場合、ステップ５２０はステップ５２４に分岐し、接続が行われている電話番号を決定する。この情報は発呼者ＩＤ機構７２などを介して使用可能にされる場合があることが理解されるであろう。呼び出し発生時にユーザーが発呼者ＩＤ機能をブロック（妨害）している可能性、または発呼側電話が機能を稼動できない（たとえば、発呼側電話が発呼者ＩＤを備えた領域以外のロケーションにある場合など）可能性があるため、ステップ５２６はその電話番号が使用可能かどうかをテストし、決定する。機構７２が、必要な場合には意図的にブロックされた呼び出しと、検出できないだけの呼び出しとを区別する機能がある場合、方針は２つのタイプを区別し、異なる信頼レベルを設定できることに注意されたい。しかし、ここの例では、どういう理由でも電話番号が使用可能でない場合、ステップ５２６はステップ５３２に分岐し、そこでＩＰアドレスは、ＲＡＳ未登録ユーザー範囲内で割り当てられる。
【００２９】
しかし、ステップ５２６でその番号が使用可能な場合、ステップ５２８が実行され、ここでは番号を使用してデータベース７４などを問い合わせ、その番号が既定の信頼できるロケーションとして登録済み番号であるかどうかを決定する。この時点で、ロケーション情報はオプションとしてユーザー識別と組み合わせられる場合があり、たとえば、ユーザーＸと識別されたユーザーは、彼または彼女の登録済みの家の番号から呼び出している場合には拡大されたアクセスを与えられるが、その他のユーザーはその番号から呼び出しても拡大されたアクセスを受け取らないことに注意されたい。
【００３０】
ステップ５３０によって番号が適切に登録されていると決定された場合、ステップ５３０はステップ５３４に分岐し、ここでＩＰアドレスは発呼側コンピュータに関するＲＡＳ登録済みユーザー範囲内で割り当てられる。番号が適切に登録されていると決定されなかった場合、ステップ５３０はステップ５３２に分岐し、ここでＩＰアドレスはＲＡＳ未登録ユーザー範囲内で割り当てられる。ロケーション識別プロセス／機構７１は次いで図５のステップ５０４に戻り、ここで割り当てられたアドレスはアクセス権を決定するマシンによって査定される。
【００３１】
ステップ５０４でＩＰアドレスがローカル・イントラネット・ユーザの範囲内にある場合、ステップ５０４はステップ５０６に分岐し、ここでは信頼レベルはこのユーザーについて１と設定される。ＩＰアドレスがローカル・イントラネット・ユーザの範囲内にない場合、ステップ５０８はその範囲がＲＡＳ登録済みユーザーの範囲内にあるかどうかをテストし決定する。範囲内にある場合、ステップ５１０で信頼レベルは２に設定されるが、範囲内にない場合、信頼レベルはステップ５１２で３と設定される。信頼レベルが０から３に一度設定されると、プロセスは次にステップ５１６に続き、次に詳細に説明するようにここでユーザーの資格認定の組み合わせにおけるユーザーの信頼レベルに基づいてアクセス権が割り当てられる。
【００３２】
図７は一般に、本発明によるアクセス権を決定するための論理を示す。セキュリティ・プロバイダ８８はユーザー資格認定９０およびロケーション情報（たとえば信頼レベル）９２をとり、その情報に基づいてそのユーザーのためのアクセス権９４を決定する。次に説明するように好ましい実施形態では、アクセス権はユーザーのプロセスの各々に関連付けられたアクセス・トークン内におかれ、各リソースに関連付けられたセキュリティ情報と比較されて、そのリソースへのアクセスを決定する。
【００３３】
制限付きトークンを使用したロケーションの識別
次に明らかになるように、本発明は好ましくはオペレーティング・システム・レベルで実装され、したがって、実質的にアクセス情報に関してすべての可能性をカバーする。例として、サーバ上の所与のファイルを保護することを考えてみる。このファイルは、リモートＳＭＢファイル・アクセス、サーバ上で実行しているスクリプトを介して、サーバ上で実行しているＦＴＰサーバを介して、プロキシ（第３のマシン）を介してなど、多くの方法でアクセスできる。本発明はシステム・レベルで動作し、実質的にファイルにアクセスするすべての方法を保護することを可能にする。
【００３４】
ここに説明された本発明の好ましいセキュリティ・モデルは、既存のＷｉｎｄｏｗｓ  ＮＴセキュリティ・モデルを強化し、拡張する。しかし、本発明をＷｉｎｄｏｗｓ  ＮＴオペレーティング・システムに限定する意図はなく、逆に、本発明は、何らかの方法で入力情報に基づいてリソースへのアクセスを限定できる任意の機構で動作し、利益を与えることが目的とされている。
【００３５】
一般に、Ｗｉｎｄｏｗｓ  ＮＴオペレーティング・システムでは、ユーザーはプロセス（およびそのスレッド）を介してシステムのリソースにアクセスすることによってタスクを実行する。簡単に説明するために、プロセスおよびそのスレッドは概念上等価と見なされ、今後は簡単にプロセスと呼ぶ。また、Ｗｉｎｄｏｗｓ  ＮＴ内ではオブジェクトによって表される、ファイル、共有メモリおよび物理デバイスを含むシステムのリソースは、本明細書では通常リソースまたはオブジェクトと呼ばれる。
【００３６】
ユーザーがＷｉｎｄｏｗｓ  ＮＴオペレーティング・システムにログオンし認証されると、セキュリティ・コンテキストがそのユーザーのためにセットアップされ、この中にはアクセス・トークン１００の構築も含まれる。図８の左側に示すように、従来のユーザー・ベースのアクセス・トークン１００は、ＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド１０２を含む。ＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド１０２は、セキュリティ識別子、すなわち、ユーザーの証明およびそのユーザーが属するグループ（たとえば編成内のグループ）を識別する１つまたは複数のグループＩＤ１０６に基づいたセキュリティ識別子（セキュリティＩＤまたはＳＩＤ）１０４を含むトークン１００はまた、そのユーザーに割り当てられた任意の特権を一覧する特権フィールド１０８を含む。たとえば、このような特権の１つは、管理レベルのユーザーに、特定のアプリケーション・プログラミング・インタフェース（ＡＰＩ）を介してシステム・クロックを設定する能力を与える場合がある。特権は、アクセス制御チェック、これは次に説明されるが、特権がない場合はオブジェクトへのアクセスを許可する前に実行されるアクセス制御チェックに優先することに注意されたい。
【００３７】
次に詳細に説明され、図９に一般に示されるように、オブジェクト１１２へのアクセスを所望するプロセス１１０は、所望するアクセスのタイプを指定し（たとえばファイル・オブジェクトへの読み取り／書き込みアクセスを得るなど）、および、カーネル・レベルでは関連付けられたトークン１００をオブジェクト・マネジャー１１４に提供する。オブジェクト１１２はそれに関連付けられたカーネル・レベルのセキュリティ記述子１１６を有し、オブジェクト・マネジャー１１４はセキュリティ記述子１１６およびトークン１００をセキュリティ機構１１８に提供する。セキュリティ記述子１１６の内容は、典型的にはオブジェクトの所有者（たとえば制作者）によって決定され、一般に（任意に）アクセス制御エントリーのアクセス制御リスト（ＡＣＬ）１２０を含み、各エントリーについて、そのエントリーに対応する１つまたは複数のアクセス権（許可されたアクションまたは拒否されたアクション）を含む。各エントリーはタイプ（拒否または許可）インジケータ、フラグ、セキュリティ識別子（ＳＩＤ）およびアクセス権をビット・マスクの形で含み、各ビットは許可に対応する（たとえば、１つのビットは読み取りアクセス、１つのビットは書き込みアクセス、など）。セキュリティ機構１１８はトークン１００内のセキュリティＩＤおよびプロセス１１０によって要求されたアクション（複数可）のタイプをＡＣＬ１２０内のエントリーと比較する。許可されたユーザーまたはグループに関して一致が発見され、所望のアクセスのタイプがそのユーザーまたはグループに許可可能な場合、オブジェクト１１２へのハンドルはプロセス１１０に戻されるが、その他の場合は、アクセスは拒否される。
【００３８】
例として、ユーザーを「会計」グループのメンバーとして識別するトークンを持つユーザーが読み取りおよび書き込みアクセスで特定のファイル・オブジェクトにアクセスしたいとする。ファイル・オブジェクトが、ＡＣＬ１２０のエントリー内で許可されたタイプの「会計」グループ識別子を有し、そのグループが読み取りおよび書き込みアクセスを使用可能にする権利を有する場合、読み取りおよび書き込みアクセスを許可するハンドルは戻されるが、その他の場合は、アクセスは拒否される。効率上の理由から、セキュリティ・チェックはプロセス１１０がまずオブジェクト１１２（作成または開く）にアクセスしようと試みたときのみ実行され、したがってそのオブジェクトに対するハンドルはそれを介して実行できるアクションを制限するように、アクセス情報のタイプを格納することに注意されたい。
【００３９】
セキュリティ識別子１１６はまた、システムＡＣＬまたはＳＡＣＬ１２１を含み、これは監査されるべきクライアント・アクションに対応するタイプ監査のエントリーを含む。各エントリー内のフラグは監査が成功したオペレーションまたは失敗したオペレーションのどちらを監視するかを示し、エントリー内のビット・マスクは監査されるべき動作のタイプを示す。エントリー内のセキュリティＩＤは、監査されているユーザーまたはグループを示す。たとえば、ファイル・オブジェクトへの書き込みアクセスを有しないグループのメンバーがそのファイルに書き込もうと試みた場合いつでも決定できるように特定のグループが監査されている状況を考えてみる。そのファイル・オブジェクトに関するＳＡＣＬ１２１は、その中にグループ・セキュリティ識別子と、適切に設定された失敗フラグおよび書き込みアクセス・ビットを有する監査エントリーを含む。その特定のグループに属するクライアントがそのファイル・オブジェクトに書き込みしようとして失敗するといつでも、そのオペレーションは記録される。
【００４０】
ＡＣＬ１２０は、（すべての権利または選択された権利に関して）グループ・ユーザーにアクセスを許可するのではなく、アクセスを拒否するためにマークされる１つまたは複数の識別子を含む場合があることに注意されたい。たとえば、ＡＣＬ１２０内にリストされた１つのエントリーは、その他の場合には「グループ3」のメンバーにオブジェクト１１２へのアクセスを許可するが、ＡＣＬ１２０内の他のエントリーは特に、「グループ24」のすべてのアクセスを拒否する場合がある。トークン１００が「グループ24」セキュリティＩＤを含んでいる場合、アクセスは「グループ3」のセキュリティＩＤの存在にかかわらず拒否されることになる。もちろん、セキュリティ・チェックは正しく機能するために、「グループ3」エントリーを介したアクセスを許可しないようにアレンジされ、その後、すべてのＤＥＮＹ（拒否）エントリーをＡＣＬ１２０の前面に置くなどによって、グループ24エントリーの「ＤＥＮＹ  ＡＬＬ（すべて拒否）」状態をチェックする。この構成（arrangement）は、グループの残りのメンバーの各々を個別にリストしてそのアクセスを許可する必要なく、グループの、１人または複数の分離したメンバーが個別にＡＣＬ１２０内で排除できるので、向上した効率を提供することが明らかであろう。
【００４１】
アクセスのタイプを指定する代わりに、発呼者はＭＡＸＩＭＵＭ＿ＡＬＬＯＷＥＤアクセスを要求することもでき、これによって、アルゴリズムは通常のＵｓｅｒＡｎｄＧｒｏｕｐｓリスト対ＡＣＬ１２０内の各々のエントリーに基づいて、許可される最大のアクセス・タイプを決定することに注意されたい。より詳しくは、アルゴリズムは所与のユーザーのための権利を蓄積してい識別子のリストをウォーク・ダウン（すなわち、種々のビット・マスクをＯＲする）。権利が一度蓄積されると、ユーザーに蓄積された権利が与えられる。しかし、ウォーク・スルーの間にユーザー識別子またはグループ識別子および要求された権利に一致する拒否エントリーが発見されると、アクセスは拒否される。
【００４２】
制限付きトークンは（制限付きまたは制限なしのいずれかの）既存のアクセス・トークンから作成され、ユーザーの通常のトークンよりも少ないアクセスを有する（すなわち、その権利および特権のサブセットを有する）。ここに使用されているように、ユーザーの「通常の」トークンは、（ユーザーまたはグループを介する）ユーザーの識別に基づいてのみアクセスを許可し、他には追加の制限がないトークンである。制限付きトークンは、ユーザーの通常のトークンがこれらのＳＩＤを介してアクセスを許可ししている場合でも、特に「ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹ」とマークされた１つまたは複数のユーザーまたはグループのセキュリティＩＤを介したリソースへのアクセスを許可されず、および／または、ユーザーの通常のトークン内にある特権を削除する場合がある。また次に説明するように、制限付きトークンが任意の制限付きセキュリティＩＤを有する場合、トークンは追加のアクセス・チェックを受け、ここで制限付きセキュリティＩＤはオブジェクトのＡＣＬ内のエントリーと比較される。
【００４３】
本発明の一態様によれば、アクセス・トークンはユーザーの識別およびユーザーが接続しているロケーションの両方に基づいて、そのユーザーのために作成される。一般に、そのロケーションの信頼性が低いと、関連付けられたプロセスがアクセスできるリソースに関して、および／または、そのトークンがこれらのリソースについて実行できるアクションに関して、そのトークンはより制限を受ける。たとえば、ＬＡＮを介して接続しているユーザーはそのユーザーのプロセスに関連付けられた通常のトークンを有する可能性があるが、一方、ＲＡＳを介して接続された同じユーザーでは、彼または彼女のプロセスはすべての特権をはぎ取られた制限付きトークンに関連付けられる可能性がある。
【００４４】
上記のように、アクセスを削減する１つの方法は、制限付きトークンの中で１つまたは複数のユーザーおよび／またはグループのセキュリティ識別子の属性を変更して、アクセスを許可するのではなくアクセスを許可できないようにすることである。ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされたセキュリティＩＤは、アクセスを許可する目的のためには効果的に無視されるが、そのセキュリティＩＤに関して「ＤＥＮＹ（拒否）」エントリーを有するＡＣＬは、依然としてアクセスが拒否される。例として、制限付きトークン１２４（図９）内のグループ2のセキュリティＩＤがＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされている場合、ユーザーのプロセスが、グループ2を許可されたものとしてリストしているＡＣＬ１２０を有するオブジェクト１１２へアクセスしようと試みたとき、このエントリーは効果的に無視され、プロセスは他の何らかのセキュリティＩＤによってアクセスを得なければならないことになる。しかし、ＡＣＬ８０が要求されたタイプのアクションに関してグループ2をＤＥＮＹとしてリストしているエントリーを含んでいる場合、一度テストされると、他のセキュリティＩＤにかかわらずアクセスは許可されない。
【００４５】
これはサーバに、ユーザーまたはグループがユーザーのロケーションに基づいてオブジェクトへアクセスすることを制限する能力を与えることが理解されるであろう。上記のように、ＩＰアドレス範囲はユーザーのロケーションに基づいて、たとえば、ローカル・マシンへ接続している場合は信頼レベル０、イントラネットまたは他の信頼できるロケーションから接続している場合は信頼レベル１、許可された電話番号からＲＡＳを介している場合はレベル２、その他の場合はレベル３と指定できる。このアドレスの範囲は次いで検査され、所定のグループをＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークする。
【００４６】
例として、それぞれ、（それらのＡＣＬに基づいて）トップ・シークレット・ファイル、機密ファイル、従業員ファイルへアクセスを許可する、「トップ・シークレット」ＳＩＤ、「機密」ＳＩＤ、および「従業員」ＳＩＤを含む通常のアクセス・トークンを有するユーザーＸとして識別されたユーザーを考えてみる。ユーザーＸが信頼レベル０であった場合、ユーザーＸの通常のトークンが使用され、そこにはロケーションに基づいた制限はない。しかし、信頼レベル１では、トップ・シークレットＳＩＤは、ユーザーＸのアクセス・トークンの中でＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされる。同様に、信頼レベル２では、トップ・シークレットＳＩＤおよび機密ＳＩＤの両方がＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされ、一方、レベル３では、トップ・シークレットＳＩＤ、機密ＳＩＤおよび従業員ＳＩＤがＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされる。セキュリティＩＤは一部のオブジェクトのＡＣＬ内では「ＤＥＮＹ」としてマークされ、その識別子を削除すると、これらのオブジェクトへのアクセスを拒否するのではなく許可することになるため、セキュリティＩＤをユーザーのトークンから削除するだけでは、オブジェクトへのアクセスを安全に削減できないことに注意されたい。さらに、このＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹセキュリティ・チェックをオフにする機構は提供されていない。
【００４７】
制限付きトークン内でアクセスを削減する別の方法は、親トークンに関連する１つまたは複数の特権を削除することである。たとえば、管理特権を伴う通常のトークンを有するユーザーは、ユーザーがローカル・マシン６０に直接接続されていない限り、ユーザーのプロセスがまったく特権を有しないか、何らかの方法で削減された特権を有する制限付きトークンで実行するように、本発明のロケーションに基づいたシステムを介して制限することができる。残る特権はまた、たとえば、ローカル（レベル０）の場合はすべての特権、レベル１の場合は一部の特権、レベル２または３の場合はまったく特権なしなど、信頼のレベルに基づいている場合があることが理解されるであろう。
【００４８】
ユーザーのロケーションに基づいてトークンのアクセスを削減するさらに別の方法は、そこに制限付きセキュリティＩＤを追加することである。制限付きセキュリティＩＤは、プロセス、リソース動作などを表す番号であり、ＧＵＩＤに接頭部または、暗号ハッシュなどを介して生成された番号を追加するなどによってユニークになっており、これらのセキュリティＩＤを他のセキュリティＩＤから区別するための情報を含むことができる。以下に説明するように、トークンが制限付きのセキュリティＩＤを含む場合、そのトークンは追加のアクセス・チェックを受け、ここで制限付きセキュリティＩＤはオブジェクトのＡＣＬ内のエントリーに対して比較される。したがって、たとえば制限付きＳＩＤは「ＲＡＳ」を指定し、これによって、オブジェクトのＡＣＬが「ＲＡＳ」エントリーを有しないかぎり、ユーザーはそのオブジェクトへのアクセスを拒否されることになる。
【００４９】
図９に示されたように、制限付きセキュリティＩＤは制限付きトークン１２４の特別なフィールド１２２に置かれ、本発明によって、プロセスがアクションを要求するロケーションを識別することができる。以下に詳細に説明されるように、少なくとも１つのユーザー（またはグループ）セキュリティＩＤおよび少なくとも１つの制限付きセキュリティＩＤがそのオブジェクトへのアクセスを許可されるように要求することによって、オブジェクトはそのロケーション（同時にユーザーまたはグループ）に基づいて選択的にアクセスを許可できる。さらに、ロケーションの各々は異なるアクセス権を許可される場合もある。
【００５０】
この設計は、ユーザーが所与のロケーションから実行を許可されていることを制御するため、ユーザーのコンテキストに重要な融通性および細分性を与える。例として、ローカル・マシンに接続しているユーザーはレベル０の信頼性、イントラネットおよび信頼できるロケーションから接続しているユーザーはレベル１の信頼性、（ＲＡＳを通じて）許可された電話番号およびインターネットから接続しているユーザーはレベル２の信頼性、および制限付きのロケーションまたは許可されていない電話番号から接続しているユーザーはレベル３の信頼性である、上記の例を考えてみる。すると、ユーザーのロケーションに基づいて（たとえば、ユーザーのＩＰアドレスから確かめられたように）、レベル０からレベル３の信頼性を、次のように実行される何らかの既定の方針に基づいて定義することができる。
【００５１】
【表２】
0004625181.tif 000003
【００５２】
既存のトークンから制限付きトークンを作成するために、ＮｔＦｉｌｔｅｒＴｏｋｅｎと名付けられたアプリケーション・プログラミング・インターフェース（ＡＰＩ）が提供され、その内容は次のとおりである。
【００５３】
【表３】
0004625181.tif 000004
【００５４】
ＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩは、ＣｒｅａｔｅＲｅｓｔｒｉｃｔｅｄＴｏｋｅｎと名付けられたＷｉｎ３２  ＡＰＩの下でラップされ、ＣｒｅａｔｅＲｅｓｔｒｉｃｔｅｄＴｏｋｅｎの内容は次のとおりである。
【００５５】
【表４】
0004625181.tif 000005
【００５６】
図８および図１０〜１１に表示されたように、これらのＡＰＩ１２６は共同して機能し、制限付きでも制限なしでも既存のトークン１００をとり、変更された（制限付き）トークン１２４をそこから作成する。ログオンしたユーザーのインスタンスに関する識別情報を含む制限付きトークンの構造は、ＰａｒｅｎｔＴｏｋｅｎＩｄ，ＲｅｓｔｒｉｃｔｅｄＳｉｄＣｏｕｎｔ、およびＲｅｓｔｒｉｃｔｅｄＳｉｄｓの３つの新しいフィールドを含む（次の表で太字で示されている）。
【００５７】
【表５】
0004625181.tif 000006
【００５８】
【表６】
0004625181.tif 000007
【００５９】
通常の（制限なしの）トークンがＣｒｅａｔｅＴｏｋｅｎ  ＡＰＩを介して作成されるとき、ＲｅｓｔｒｉｃｔｅｄＳｉｄｓフィールドもＰａｒｅｎｔＴｏｋｅｎＩｄフィールドも空であることに注意されたい。
【００６０】
制限付きトークン１２４を作成するために、このプロセスは適切なフラグ設定および／または入力フィールドの情報を伴うＣｒｅａｔｅＲｅｓｔｒｉｃｔｅｄＴｏｋｅｎ  ＡＰＩを呼び出し、これはＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩを順番に起動する。図１０のステップ１０００の初めに示すように、ＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩは、ＤＩＳＡＢＬＥ＿ＭＡＸ＿ＳＩＤＳと名付けられたフラグが設定されているかどうかをチェックする。このフラグは、新しい、制限付きトークン１２４の中にあるグループに関してすべてのセキュリティＩＤがＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとマークされていなければならないことを示す。このフラグは、各々のグループを個別に識別する必要なく、トークン内のグループ（多くのグループである可能性がある）に制限を行う便利な方法を提供する。フラグが設定されている場合、ステップ１０００はステップ１００２に分岐し、ステップ１００２では新しいトークン１２４内のグループ・セキュリティＩＤの各々について、ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹを示すビットを設定する。
【００６１】
ＤＩＳＡＢＬＥ＿ＭＡＸ＿ＳＩＤＳフラグが設定されていない場合、ステップ１０００はステップ１００４に分岐し、ＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩのＳｉｄｓＴｏＤｉｓａｂｌｅフィールド内にセキュリティＩＤが個別にリストされているかどうかをテストする。図１０のステップ１００４で示されたように、オプションのＳｉｄｓＴｏＤｉｓａｂｌｅ入力フィールドが存在するとき、ステップ１００６では、そこにリストされ、また、親トークン１００のＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド１０２内にも存在する任意のセキュリティＩＤは、新しい制限付きトークン１２４のＵｓｅｒＡｎｄＧｒｏｕｐｓフィールド１２８内でＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとして個別にマークされる。上記のようにこのようなセキュリティＩＤは、アクセスを拒否するためにのみ使用でき、アクセスを許可するためには使用できず、さらに、あとから削除または使用可能にはできない。したがって、図８に示された例では、グループ2のセキュリティＩＤは、ＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩ１２６のＳｉｄｓＴｏＤｉｓａｂｌｅ入力フィールド内にグループ2セキュリティＩＤを指定することにより、制限付きトークン１２４内でＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹとしてマークされる。
【００６２】
フィルタ・プロセスはついで図１０のステップ１０１０に続き、ここではＤＩＳＡＢＬＥ＿ＭＡＸ＿ＰＲＩＶＩＬＥＤＧＥＳと名付けられたフラグがテストされる。このフラグは同様に、新しい、制限付きトークン１２４内のすべての特権を削除すべきであることを示す、便利なショートカットとして設定できる。このように設定された場合、ステップ１０１０はステップ１０１２に分岐し、ステップ１０１２では新しいトークン１２４からすべての特権が削除される。
【００６３】
フラグが設定されていない場合、ステップ１０１０はステップ１０１４に分岐し、ここではオプションのＰｒｉｖｉｌｅｇｅｓＴｏＤｅｌｅｔｅフィールドが確認される。ＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩ１２６が呼ばれたときに存在する場合は、ステップ１０１６で、この入力フィールドにリストされ、また既存のトークン１００の特権フィールド１０８にも存在する任意の特権は、新しいトークン１２４の特権フィールド１３０から個別に削除される。図８に示された例では、「特権2」から「特権m」として示された特権は、ＮｔＦｉｌｔｅｒＴｏｋｅｎ  ＡＰＩ１２６のＰｒｉｖｉｌｅｇｅｓＴｏＤｅｌｅｔｅ入力フィールド内にこれらの特権を指定することによって、新しいトークン１２４の特権フィールド１３０から削除されている。上記のように本発明の１つの態様によれば、これは、トークン内で使用可能な特権を削減する機能を提供する。このプロセスは図１１のステップ１０２０に続く。
【００６４】
制限付きトークン１２４を作成するときに、ステップ１０２０でＲｅｓｔｒｉｃｔｉｎｇＳｉｄｓ入力フィールド内にＳＩＤが存在していた場合、親トークンが通常のトークンか、または親トークン自体が制限付きＳＩＤを有する制限付きトークンであるかどうかに関して決定が行われる。ＡＰＩ、ＩｓＴｏｋｅｎＲｅｓｔｒｉｃｔｅｄがステップ１０２２で呼び出され、親トークンのＲｅｓｔｒｉｃｔｉｎｇＳｉｄｓフィールドを（ＮｔＱｕｅｒｙＩｎｆｏｒｍａｔｉｏｎＴｏｋｅｎ  ＡＰＩを介して）照会してこれがＮＵＬＬでないかどうかを確認することによってこの問題を解決し、ここでＮＵＬＬでなかった場合、親トークンは制限付きトークンであり、ＡＰＩはＴＲＵＥ（真）を戻す。テストが満足できなかった場合、親トークンは通常のトークンでありＡＰＩはＦＡＬＳＥ（偽）を戻す。続くステップ１０２６または１０２８のために、トークン自体は制限付きであるが制限付きＳＩＤを有しない親トークン（すなわち、特権が削除されているかおよび／またはＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹ  ＳＩＤＳである場合）は、制限付きでないとして処理される可能性があることに注意されたい。
【００６５】
ステップ１０２４では、親トークンが制限付きである場合、ステップ１０２４はステップ１０２６に分岐し、ステップ１０２６では、親トークンの制限付きセキュリティＩＤフィールドと、ＡＰＩの制限付きセキュリティＩＤ入力リストの両方にある任意のセキュリティＩＤは、新しいトークン１２４の制限付きセキュリティＩＤフィールド１３２に置かれる。制限付きセキュリティＩＤが両方のリストになければならないため、制限付き実行コンテキストが、制限付きセキュリティＩＤフィールド１３２にさらなるセキュリティＩＤを追加することを阻止し、この場合、アクセスを減らすのではなく効果的にアクセスを増やすことになる。同様に、ステップ１０２６で共通なセキュリティＩＤがなかった場合、少なくとも１つの制限付きＳＩＤを新しいトークン内の元のトークンから取り去るなどによって、作成された任意のトークンはそのアクセスを増やすことなく制限されなければならない。その他の場合は、新しいトークン内の空の制限付きＳＩＤフィールドはそのトークンが制限されていないことを示し、この場合、アクセスを減らすのではなく効果的にアクセスを増やすことになる。
【００６６】
あるいは、ステップ１０２４で親トークンが通常のトークンであると判断された場合、ステップ１０２８で新しいトークン１２４のＲｅｓｔｒｉｃｔｉｎｇＳｉｄｓフィールド１３２は入力フィールド内にリストされたものに設定される。これはセキュリティＩＤを追加するが、次に詳細に説明されるように制限付きＳＩＤを有するトークンが第２のアクセス・テストを受けるため、アクセスは実際には減らされることに注意されたい。
【００６７】
最後に、ステップ１０３０も実行され、ここで新しいトークン１２４内のＰａｒｅｎｔＴｏｋｅｎＩｄ９３は既存の（親）トークンのＴｏｋｅｎＩｄに設定される。これはオペレーティング・システムに、通常は親トークン以外には許可されていないロケーションで、そのトークンの制限付きのバージョンを使用するプロセスをのちに許可するオプションを提供する。
【００６８】
特に図１２〜１４を参照して本発明の動作の説明に戻ると、図１２に表示されたように、制限付きプロセス１３４が作成され、読み取り／書き込みアクセスでファイル・オブジェクト１１０を開こうと試みている。オブジェクト１１２のセキュリティ記述子内では、ＡＣＬ１２０はそこにリストされた多くのセキュリティＩＤおよび、各ＩＤに関して許可されたタイプのアクセスを有し、ここで「ＲＯ」は読み取りのみのアクセスが許可されていることを示し、「ＷＲ」は読み取り／書き込みアクセスを示し、「ＳＹＮＣ」は同期化アクセスが許可されていることを示す。他の場合は「ＸＪｏｎｅｓ」が許可されたグループ内のメンバーシップを介してアクセスを許可されている場合でも、「ＸＪｏｎｅｓ」は特にオブジェクト１１２へのアクセスを拒否されていることに注意されたい。さらに、関連付けられたこのトークン１２４を有するプロセス９４は、このエントリーは「ＤＥＮＹ」（すなわち、ＵＳＥ＿ＦＯＲ＿ＤＥＮＹ＿ＯＮＬＹ）とマークされているため、トークン１２４内の「バスケットボール」セキュリティＩＤを介して任意のオブジェクトへのアクセスを許可されないことになる。
【００６９】
図１２に表されているように、制限付きセキュリティ・コンテキストは第１にＷｉｎｄｏｗｓ  ＮＴカーネル内で実装される。オブジェクト１１２へのアクセスを試みるために、プロセス１３４はオブジェクト・マネジャー１１４に、アクセスが所望されているオブジェクトを識別する情報および、所望されるアクセスのタイプを提供する（図１４、ステップ１４００）。オブジェクト・マネジャー１１４はこれに応答して、ステップ１４０２に表されたように、セキュリティ機構１１８と共同して機能し、トークン１２４内にリストされた（プロセス１３４と関連付けられている）ユーザーおよびグループ・セキュリティＩＤをＡＣＬ１２０内のエントリーと比較し、所望のアクセスが許可されるべきか拒否されるべきかを決定する。
【００７０】
ステップ１４０４で一般に示されているように、アクセスがリストされたユーザーまたはグループに関して許可されていない場合、セキュリティ・チェックはステップ１４１４でアクセスを拒否する。しかし、ステップ１４０４でアクセス・チェックのユーザー部分およびグループ部分の結果が許可可能なアクセスを示した場合には、セキュリティ・プロセスはステップ１４０６に分岐し、制限付きトークン１２４が任意の制限付きセキュリティＩＤを有しているかどうかを決定する。有していない場合、追加の制限はなく、ここでアクセス・チェックは完了し、ステップ１４１２において、ユーザー・アクセスおよびグループ・アクセスのみに基づいてアクセスは許可される（そのオブジェクトへのハンドルが戻される）。このようにして、通常のトークンは本質的に以前と同じようにチェックされる。しかし、ステップ１４０６によって決定されたように、トークンが制限付きセキュリティＩＤを含んでいる場合、ついでステップ１４０８によって、制限付きセキュリティＩＤをＡＣＬ１２０内のエントリーと比較することによって、第２のアクセス・チェックが実行される。ステップ１４１０でこの第２のアクセス・テストがアクセスを許可した場合、そのオブジェクトへのアクセスはステップ１４１２で許可される。そうでない場合、アクセスはステップ１４１４で拒否される。
【００７１】
図１３で論理的に示すように、トークン１２４の中に制限付きセキュリティＩＤが存在するときはいつでも、２部分からなるテストがこのように実行される。トークン１２４内のセキュリティＩＤおよび所望のアクセス・ビット１３６をオブジェクト１１２のセキュリティ記述子に対して考慮することによって、通常のアクセス・テスト（ビットごとのＡＮＤ）および制限付きセキュリティＩＤのアクセス・テストの両方は、プロセスがそのオブジェクトへのアクセスを許可されるようにアクセスを許可しなければならない。本発明に必要ではないが上記のように、通常のアクセス・テストが最初に行われ、アクセスが拒否された場合には、さらなるテストは必要ではない。トークン内にＡＣＬの識別子に一致するセキュリティＩＤがないため、またはＡＣＬエントリーが特に、その中にあるセキュリティ識別子に基づいてトークンへのアクセスを拒否したためのどちらの理由でも、アクセスは拒否されることに注意されたい。別法としては、トークンを制限付きＳＩＤの多数の組を有するように構成し、たとえば、組Ａ  ＯＲ（組Ｂ  ＡＮＤ組Ｃ）がアクセスを許可するなど、これらのＳＩＤの査定をカバーするさらに複雑なブール式を伴う場合もある。
【００７２】
このように図１２に示された例では、トークン１２４（フィールド１３２）内の制限付きＳＩＤのみが「インターネット・エクスプローラ」を識別する一方、オブジェクトのＡＣＬ１２０内には対応する制限付きＳＩＤがないため、図１２に示された例では、オブジェクト１１２へのアクセスはプロセス９４へは許可されない。ユーザーは通常のトークンで実行するプロセスを介してオブジェクトへアクセスする権利を有していたが、プロセス９４はＡＣＬ内に「インターネット・エクスプローラ」ＳＩＤ（非ＤＥＮＹ）を有するオブジェクトのみにアクセスできるようにするように、制限された。
【００７３】
アクセスのタイプを指定する代わりに、発呼者が指定されたＭＡＸＩＭＵＭ＿ＡＬＬＯＷＥＤアクセスを有する場合、これによって上記のように、アルゴリズムは最大のアクセスを決定するＡＣＬ１２０をウォーク・スルーする。制限付きトークンで、１つでも任意のタイプのユーザー・アクセスまたはグループ・アクセスが許可された場合、ユーザーおよびグループの実行に続いて許可可能なアクセス権のタイプ（複数可）は、第２の実行に関して所望のアクセスとして指定され、第２の実行はＲｅｓｔｒｉｃｔｅｄＳｉｄｓリストをチェックする。このようにして、制限付きトークンは通常のアクセスより少ないかまたは等しいアクセスを許可されることが確認される。
【００７４】
最後に、アクセス・トークンはロケーションに基づいた基準以外の基準に従ってさらに制限できることに注意されたい。実際には、制限付きトークンは、リソースへアクセスしようとしているプロセス（たとえばマイクロソフト・エクセル）の識別を含む他の基準に基づいて制限付きセキュリティ・コンテキストを設定することを可能にする。さらに、種々の基準を組み合わせてアクセス権を決定することができる。従って、たとえばユーザーがマイクロソフト・ワードではなくマイクロソフト・エクセルを介してファイルを開いている場合、ネットワーク・ファイルへのＲＡＳのアクセスが許可される場合がある。セキュリティ識別のためには事実上、ロケーションに基づいた基準と他の基準の、無限の組み合わせが可能である。
【００７５】
認証
本発明の一態様によれば、クライアントがサーバに接続しているとき、サーバはクライアントを認証し、クライアントの識別およびロケーション情報に基づいてそのユーザーのためのトークンを構築する。たとえば図１５および１６に示されているように、よく知られたタイプの認証（すなわちＮＴＬＭ）では、クライアント・ユーザ２００はユーザーＩＤを含む認証２０２をサーバ２０４に提供し、サーバ２０４は次いでドメイン・サーバ２０６と通信してユーザーの暗号化され、格納されたパスワードに基づいてそのユーザーに関して質問を作成する。図１５に表されたように、サーバ２０４はその質問をクライアント２０２に戻し、クライアントが正しく応答する場合は、そのユーザーは認証される。
【００７６】
しかし本発明によれば、ユーザーに関して通常のトークンを構築するのみではなく、上に詳細に説明されたようにユーザー情報はセキュリティ・サブ・システム／プロバイダ２１０によってロケーション情報２０８と組み合わせられ、制限付きトークン２１２を作成する。制限付きトークン２１２は、任意のクライアント・プロセス２１６のためにサーバ２０４で実行されている各プロセスと関係付けられている。
【００７７】
図１７および１８に示されたように、Ｋｅｒｂｅｒｏｓプロトコルを含む他の認証プロトコルもまた本発明と共に使用できる。Ｋｅｒｂｅｒｏｓプロトコルによれば、サーバ２２０への接続の認証はチケット２２２を介して達成される。チケット２２２は、最初はキー配布センタ（ＫＤＣ）２２６として知られているネットワーク上のチケット発行機能からクライアント２２４によって受け取られる。チケット２２２はしばらくの間再使用可能であり、これによってセッションが終わった場合でも、チケット２２２が依然として有効な間は、クライアント１３０は認証プロセスを繰り返す必要はない。
【００７８】
本発明によれば、上に詳細に説明されたように（クライアント２２４によってそこに置かれた制限を含む）チケット２２２内の情報は、サーバのセキュリティ・サブ・システム／プロバイダ２２８によってユーザーのロケーション情報２３０と組み合わせられ、制限付きトークン２３２を作成する。制限付きトークン２３２は任意のクライアント・プロセス２３６のためにサーバ２２０において実行されている各プロセス２３４と関連付けられる。
【００７９】
同様に図１９および２０は、ＳＳＬとして知られている別の認証プロトコルを示す。ＳＳＬでは、クライアント・ユーザ２４０はまず公開キーに基づいた認証を使用して証明２４６から証明ＩＤ２４２を得る。サーバ２４８が認証機関２４６を信頼していると仮定して、クライアント・ユーザ２４０は証明ＩＤ２４２を使用してサーバ２４８へのアクセスを得る。図１９に表されたように、サーバ２４８とクライアント２４０の間に往復の通信が起こり、これを介してサーバはこの証明ＩＤ２４２が正しいユーザーに属していることを証明できる。
【００８０】
証明ＩＤ２４２は、ユーザーが、サーバ２４８が接続しているネットワークでアカウントを有していると識別するユーザー情報を含む。その情報は、そのユーザーのために維持されたユーザー情報（たとえばセキュリティＩＤ、グループＩＤ特権など）を有するデータベース２５０へアクセスするために使用される。次いで、上に詳細に説明されたように本発明によればデータベース２５０からのユーザー情報は、サーバのセキュリティ・サブ・システム／プロバイダ２５４によってロケーション情報２５２と組み合わせられて、制限付きトークン２５６を作成する。制限付きトークン２５６は任意のクライアント・プロセス２６０のためにサーバ２４８において実行されている各プロセス２５８と関連付けられる。
【００８１】
これらの認証プロトコルおよび別の認証プロトコルを介して得られたユーザー情報はロケーション情報と組み合わせられて、ユーザーのリソースへのアクセスを制限することが理解されたであろう。さらに、認証のタイプ自体をユーザーのロケーションに依存させることもできる。たとえば、セキュリティを増加するためにリモート接続がＫｅｒｂｅｒｏｓまたはＳＳＬ認証を必要とし、一方、ローカル接続を介して接続しているユーザーを認証するには質疑応答認証で十分である場合もある。サーバがロケーション情報へのアクセスを有するため、サーバは特定のロケーションについて必要とされる認証のタイプを決定できる。同様に、認証のタイプはアクセス権を識別するために使用することもできる。たとえば、ＳＳＬユーザーのアクセス権は１つの方法で制限し、Ｋｅｒｂｅｒｏｓユーザーは別の方法で、ＮＴＬＭユーザーはさらに別の方法で制限することもできる。上記の方法では、制限付きトークンはユーザーの仮想的なロケーションおよび／または認証タイプに基づいて制限付きセキュリティ・コンテキストを実装する便利な機構を提供するが、他の実施形態機構も可能である。
【００８２】
本発明は種々の変形および代替の構成を可能にするが、そのうち所定の図示された実施形態が図に示され、上記に詳細に説明された。しかし、本発明を開示された具体的な形に制限する意図はなく、逆に、本発明の精神と範囲に含まれるすべての変形例、代替の構成、等価物をカバーすることが目的であることを理解されたい。
【図面の簡単な説明】
【図１】  本発明が組み入れられるコンピュータ・システムを表す構成図である。
【図２】  ユーザーがネットワークに接続する可能性のある仮想的なロケーションを一般に表す構成図である。
【図３】  本発明の一態様による、ユーザーのロケーションを決定し、そのロケーションに基づいてユーザーのアクセス・レベルを決定するために取られる一般的なステップを表す流れ図である。
【図４】  本発明の一態様による、ロケーション情報に基づいてユーザー・アクセスを確立するための種々の構成要素を一般に表す構成図である。
【図５】  本発明の一態様による、ロケーション情報に基づいてユーザーの信頼のレベルを決定するためにとられる一般的なステップを表す流れ図である。
【図６】  本発明の一態様による、ロケーション情報に基づいてユーザーの信頼のレベルを決定するためにとられる一般的なステップを表す流れ図である。
【図７】  本発明の一態様による、ユーザーのアクセス権を決定する機構を一般に表す構成図である。
【図８】  本発明の一態様による、既存のトークンから制限付きトークンを作成することを一般に表す構成図である。
【図９】  プロセスがリソースにアクセスできるかどうかを決定するための種々の構成要素を一般に表す構成図である。
【図１０】  本発明の一態様による、既存のトークンから制限付きトークンを作成するためにとられる一般的なステップを表す流れ図である。
【図１１】  本発明の一態様による、既存のトークンから制限付きトークンを作成するためにとられる一般的なステップを表す流れ図である。
【図１２】  本発明の一態様による、リソースへのアクセスを試み、関連付けられた制限付きトークンを有するプロセスを一般に表す構成図である。
【図１３】  本発明の一態様による、関連付けられた制限付きトークンを有するプロセスのオブジェクトへのアクセスを決定するための論理を一般に表す構成図である。
【図１４】  本発明の一態様による、リソースへのプロセスアクセスを許可するかどうかを決定するときにとられる一般的なステップを表す流れ図である。
【図１５】  質疑応答認証プロトコル内でクライアントとサーバの間の通信を表す図である。
【図１６】  本発明の一態様による、認証証明およびロケーション識別に基づいて制限付きトークンを作成することを表す構成図である。
【図１７】  Ｋｅｒｂｅｒｏｓ認証プロトコルに従って、サーバにおいてクライアントを認証するための通信を表す図である。
【図１８】  本発明の一態様による、認証チケットおよびロケーション識別に基づいて制限付きトークンを作成することを表す構成図である。
【図１９】  ＳＳＬプロトコルに従って、サーバにおいてクライアントを認証するための通信を表す図である。
【図２０】  本発明の一態様による、認証証明およびロケーション識別に基づいて制限付きトークンを作成することを表す構成図である。
【図１】
0004625181.tif 000008
【図２】
0004625181.tif 000009
【図３】
0004625181.tif 000010
【図４】
0004625181.tif 000011
【図５】
0004625181.tif 000012
【図６】
0004625181.tif 000013
【図７】
0004625181.tif 000014
【図８】
0004625181.tif 000015
【図９】
0004625181.tif 000016
【図１０】
0004625181.tif 000017
【図１１】
0004625181.tif 000018
【図１２】
0004625181.tif 000019
【図１３】
0004625181.tif 000020
【図１４】
0004625181.tif 000021
【図１５】
0004625181.tif 000022
【図１６】
0004625181.tif 000023
【図１７】
0004625181.tif 000024
【図１８】
0004625181.tif 000025
【図１９】
0004625181.tif 000026
【図２０】
0004625181.tif 000027