コンピューティングプロセスのための最小特権アクセスの付与
実施形態は、既存のオペレーティングシステムの上部で動作して、どのようなリソースがアプリケーションによってアクセス可能であるのか及びどのようなAPIをアプリケーションがコールすることができるのかを制御するように構成することができるセキュリティインフラストラクチャーを提供する。デフォルトにより最小特権を可能にするために、現在のスレッドの識別情報及び現在のスレッドのコールチェーンコンテキストの双方を考慮することにより、セキュリティ判定が行われる。現在のスレッドコンテキストがキャプチャされ、そのコピーが作成されて、セキュリティチェックを非同期に実行するのに使用される。システムにおけるあらゆるスレッドは、関連付けられる識別情報を有する、特定のリソースへのアクセスを得るために、現在のスレッド上のすべてのコーラーが分析されて、各コーラー及び各スレッドがそのリソースにアクセスできることが確かめられる。各コーラー及び各スレッドがそのリソースにアクセスすることができるときにのみ、コーラーにはそのリソースへのアクセスが与えられる。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、コンピューティングプロセスのための最小特権アクセスの付与に関する。
【背景技術】
【0002】
[0001]デバイスは、リソース、アプリケーション等へのアクセスを制御するセキュリティインフラストラクチャーで構成される場合がある。現在、移動デバイスでは、トラスト(trust)がコード識別情報に基づいて個々のアプリケーションに割り当てられる。セキュリティインフラストラクチャーは、どのようなアプリケーションがデバイス上で動作し得るのか、どのようなアプリケーションをロックアウトすることができるのか、どのようなアプリケーションをどのようなコンテキストで動作させることができるのか、及びこのようなアプリケーションがどのようなリソースにアクセスすることができるのかを判断する。現在のトラストレベルは、未署名のモジュールについて「トラステッド(信頼できる、trusted)」、「ノーマル」、及び「アントラステッド(信頼できない、untrusted)」を含む。アプリケーション又はモジュールは、トラステッド証明書、又はトラステッド証明書ストアにチェーンする証明書で署名を受けることができる。この場合、そのモジュールはトラステッドであるとみなされ、したがって、そのモジュールのどのコードも、システム上のすべての特権を有するAPI及びリソースにアクセスすることができる。トラスト判定は、コーラー(caller)のアプリケーショントラストレベルに基づく。
【発明の概要】
【発明が解決しようとする課題】
【0003】
[0002]しかしながら、上述した現在のセキュリティモデルにはいくつかの問題がある。スレッドがシステムの複数の保護されたサーバーライブラリ(PSL)サーバーを通じてマイグレーションするとき、コールチェーンの直接のコール側プロセスがシステムリソースへのアクセスに対するパーミッションを有することが可能であるが、コールチェーンコンテキスト全体を検査することによって、リソースがアクセス可能であるべきでないことが明らかにされる場合がある。このようなセキュリティは、セキュリティ判定が常に直接のコーラーのコンテキストにのみ基づいている場合に強制することができない。また、現在のセキュリティモデルは、低い特権を有するアプリケーションがシステムサービスをコールする場合において異なる識別情報に偽装することにも備えておらず、システムサービスは、コーラーのコンテキスト又はそれ自身のコンテキストのいずれかに基づいて要求を処理するように求められる。またさらに、非同期アクセス要求について、現在のセキュリティモデルは、コーラーのコンテキストが完全に利用可能でないことがあり得る場合において2次スレッドのセキュリティチェックに備えていない。
【0004】
[0003]本出願は、本発明が行ったこれらの検討事項及び他の検討事項に関するものである。
【課題を解決するための手段】
【0005】
[0004]この概要は、詳細な説明でさらに後述する概念のうちの選択したものを簡略化した形態で紹介するために設けられている。この概要は、特許請求される主題の重要な特徴も本質的な特徴も特定するように意図されたものではなく、また、特許請求される主題の範囲を決定することを助けるものとして意図されたものでもない。
【0006】
[0005]デフォルトによる最小特権を可能にするために、現在のスレッドの識別情報及び現在のスレッドのコールチェーンコンテキストの双方を考慮することによってセキュリティ判定を行う実施の形態が提供される。現在のスレッドコンテキストがキャプチャされ、そのコピーが作成されて、セキュリティチェックを非同期に実行するのに使用される。システムにおけるあらゆるスレッドが、関連付けられる識別情報を有する。最初に、この識別情報は、親プロセスから導出される。しかしながら、スレッドの寿命の間、この識別情報はスレッドの任意の偽装に基づいて変化し得ることが可能である。
【0007】
[0006]これらの特徴及び利点並びに他の特徴及び利点は、以下の詳細な説明を読み、関連付けられる図面をレビューすることによって明らかになるであろう。上述の一般的な説明も以下の詳細な説明も、例示にすぎず、特許請求される本発明を限定するものではないことが理解されるべきである。
【図面の簡単な説明】
【0008】
【図1】[0007]本発明の一実施形態によるセキュリティ識別子(SID)100を示す図である。
【図2】[0008]本発明の一実施形態によるセキュリティトークン構造体200のレイアウトを示す図である。
【図3】[0009]本発明の一実施形態によるセキュリティ記述子のレイアウト300の簡略化された図である。
【図4】[0010]本発明の一実施形態によるアクセス制御リスト(ACL)400を示す図である。
【図5】[0011]本発明の一実施形態によるアクセス制御エントリ(ACE)500のための構造体を示す図である。
【図6】[0012]本発明の一実施形態によるセキュリティ記述子(SD)600のための構造レイアウトを示す図である。
【図7】[0013]本発明の一実施形態によるスレッド700のトークンリストのためのアレンジメントを示す図である。
【図8】[0014]本発明の一実施形態によるPSLコール800におけるスレッドのためのコールスタックリストを示す図である。
【図9】[0015]本発明の一実施形態によるスレッド900のための、偽装リストとコールスタックリストとの間のリンク900を示すブロック図である。
【図10】[0016]本発明の一実施形態によるメッセージキューシステム1000を示す図である。
【図11】[0017]本発明の実施形態を実施することができるコンピューティング環境を示す図である。
【発明を実施するための形態】
【0009】
[0018]実施形態は、既存のオペレーティングシステムの上部で動作して、どのようなリソースがアプリケーションによってアクセス可能であるのか及びどのようなAPIをアプリケーションがコールすることができるのかを制御するように構成することができるセキュリティインフラストラクチャーを提供する。デフォルトにより最小特権を可能にするために、現在のスレッドの識別情報及び現在のスレッドのコールチェーンコンテキストの双方を考慮することにより、セキュリティ判定が行われる。現在のスレッドコンテキストがキャプチャされ、そのコピーが作成されて、セキュリティチェックを非同期に実行するのに使用される。システムにおけるあらゆるスレッドは、関連付けられる識別情報を有する、最初に、この識別情報は、親プロセスから導出されるが、スレッドの寿命の間、この識別情報は、スレッドが行う任意の偽装に基づいて変化し得ることが可能である。
【0010】
[0019]実施形態は、どのようなコール又はアプリケーションが要求しているのかを分析するだけでなく、そのコールがどこから生じたものであるのかも分析する。実施形態は、エンドユーザー又はエンドオペレーターが自身の制御下にない場合がある異なるアプリケーションをインストールすることができるようにオープンエンドであるシステムのためのセキュリティインフラストラクチャーも提供することができる。したがって、スレッドがアクセスする権限を有しないリソースから該スレッドが誤ってアクセスされることに基づいてセキュリティ問題が発生することを防止するために、システムにおけるすべてのスレッドは、デフォルトにより最小特権で動作することができる。それどころか、特定のリソースにアクセスするときは、各コーラー及び各スレッドがそのリソースにアクセスすることができることを確認するために、現在のスレッドのすべてのコーラーが分析される。各コーラー及び各スレッドがそのリソースへアクセスすることができるときにのみ、そのコーラーには、そのリソースへのアクセスが与えられる。
【0011】
[0020]本発明の実施形態は、どのリソースがアプリケーションによりアクセス可能であるのか及びアプリケーションがどのようなAPIをコールすることができるのかを制御するためのセキュリティインフラストラクチャーを提供するデータ構造体を使用して実施することができる。このデータ構造体は、次の要素、すなわち、セキュリティ識別子(SID)、セキュリティトークン、セキュリティ記述子(SD)、アクセス制御リスト(ACL),及びアクセス制御エントリ(ACE)を含む。
【0012】
[0021]図1は、本発明の一実施形態によるセキュリティ識別子(SID)100を示す。SID100は、システム内で一意のIDを定義し、特定のスレッドがどのようなアカウントで動作しているのかを指定する可変長データ構造体110である。SID100は、ユーザーアカウントのようなものであると考えることもできる。例えば、或る人がコンピューターにログオンしたとき、さまざまなユーザーアカウントが、適切なログオンパスワードを使用してアクセス可能になる場合がある。ユーザーアカウントは、コンピューターにログオンしている人を識別する。SID100は、単にスレッド又はプロセスを識別するアカウントである。SID100は、特定のデバイス内においてのみ一意である。しかしながら、当業者は、本明細書における本発明の実施形態の説明を分析した後、グローバルセキュリティ識別子を使用することができることを認識する。
【0013】
[0022]デスクトップ上において、SID100を、個々のユーザーアカウント、一定のシステムアカウント、及び一定のユーザーグループに割り当てることができる。WINDOWS(登録商標)CEオペレーティングシステムにおけるアカウントは、例えば、デスクトップのWINDOWS(登録商標)オペレーティングシステムに関して使用されるものと必ずしも同じ定義であるとは限らないことに留意されたい。それにもかかわらず、当業者は、何がアカウントを構成するのかを理解する。本明細書では、SID100は、アカウントデータベース内のエントリにマッピングされる、例えばWINDOWS(登録商標)CEオペレーティングシステムといったオペレーティングシステム全体にわたって一意の識別子であるものと仮定される。アカウントデータベース内のエントリは、どのような基本特権及び拡張特権が特定のアカウント(別称SID)に割り当てられているのかを指定する。
【0014】
[0023]図2は、本発明の一実施形態によるセキュリティトークン構造体200のレイアウトを示す。セキュリティトークン200は、識別情報のセット及びそれらの識別情報に割り当てられた特権の集合を定義するのに使用される。通常、セキュリティトークン200は、プロセス、スレッド、同期のようなランタイムオブジェクト及びメッセージキュー内の個々のメッセージに関連付けられる。セキュリティトークン200は、この構造体のバージョン202、フラグ204、オフセット206、直接グループ(immediate group)の個数207、及びグループIDの総数208を識別するためのフィールドを含む。セキュリティトークン200の構造体は、プライマリオーナーSID210、グループSID(複数可)212、基本特権(basic privilege)214、及び拡張特権(extended privilege)216も記憶することができる。
【0015】
[0024]プライマリSID210及びグループSID(複数可)212は、このセキュリティトークン200を有するオブジェクトに関連付けられる識別情報を定義する。基本特権214及び拡張特権216は、どのような特権が、このセキュリティトークン200に関連付けられたオブジェクトに許可されるのかを定義する。基本特権214は、セキュリティトークン200において指定された識別情報に有効な特権のセットである。同様に、拡張特権216は、セキュリティトークン200におけるSIDのリストについて定義されたカスタム特権(custom privilege)である。
【0016】
[0025]基本セキュリティトークン構造体200は、このセキュリティトークン200に関連付けられるプライマリSID210及びグループSID212並びにこのセキュリティトークン200に関連付けられる拡張特権216等のセキュリティトークン200のための拡張(オプション)データへのオフセットポインタ206を有する。セキュリティトークン200における個々の各SID210、212は、SDが指定されたオブジェクトに、所与のセキュリティトークン200が所望のアクセスを行うことができるか否かを判断するために、AccessCheck(アクセスチェック)APIコールにおいて使用される。また、セキュリティトークン200における基本特権[[212]]214及び拡張特権[[214]]216は、所与のセキュリティトークン200が特権を必要としていたか否かを判断するために、PrivilegeCheck(特権チェック)APIコールにおいて使用される。API及びセキュリティトークン200の使用は、本明細書の以下で説明するトークンAPIの論述を参照してより詳細に論述される。
【0017】
[0026]アカウントの文字列表現が作成され、この文字列表現は、セキュリティトークン構造体200で使用されるDWordにマッピングされる。その場合、セキュリティトークン200は、システムにおける読み出されたスレッドに関連付けられるオブジェクトである。したがって、あらゆるスレッドは、特定のセキュリティトークン200で開始する。セキュリティトークン200は、この特定のスレッドが、特定のアカウントIDを有する特定のチャンバーに属することを示すと共に該スレッドが一定のグループのメンバであることも示す識別情報のリストを有する基本トークン構造体220を含む。各セキュリティトークン200は、セットによって表される。したがって、セキュリティトークン構造体は、構造体及び複数のセットを含む。第1のセットはオーナーセットである。それは、一意のIDがシステム内の各チャンバー又はシステム内の各アカウントに与えられることを意味する。その場合、ゼロ個又は1つ以上のグループメンバーシップであるグループアカウントIDが存在する可能性がある。それらのグループアカウントIDは、拡張トークンデータ222において与えられる。
【0018】
[0027]デスクトップ用のセキュリティトークン構造体も同様である。例えば、デスクトップをリセットするために定義された特権又はドライバーをインストールするために定義された特権が存在する可能性がある。したがって、特定のコーラーが特定の特権セットを有する場合、そのコーラーのみが、そのAPIコールを行うことができ、そのコーラーのみがデバイスをリセットするか又はドライバーをインストールすることができる。これらは特有の特権である。基本特権は1つのDWordのみとすることができ、それによって、そのDWordは基本特権[[212]]214に結び付けられ、そして、拡張トークンデータ222の一部である任意の個数の拡張特権[[214]]216が存在し得る。
【0019】
[0028]多くの特権214、216が存在し得るが、特権214、216は、アクセスチェックがリソースについて動作するように正確に機能する。したがって、特定のAPIが特定の特権を必要とする場合、又は特定のAPIが、特定のコーラーが特定の特権を有することを必要とする場合、コンタクトチェーン内のあらゆるコーラーがその特定の特権を有しなければならない。すべてのコーラーがその特権を有するときにのみ、そのコールは通過することが許可される。あらゆるトークンは、基本トークン構造体220と少なくとも同程度の情報を有するべきである。
【0020】
[0029]拡張トークン構造体222はオプションの設定である。したがって、一例として、アカウントは、1つ又は複数のグループのメンバである場合がある。したがって、拡張トークン構造体222は可変サイズを有し、すなわちサイズは固定でないのに対して、基本トークン構造体のサイズは固定である。セキュリティトークン200は、あらゆるプロセスに関連付けられ、それゆえ、プロセス内のあらゆるスレッドは、開始時にそのセキュリティトークン200を受け取るか又は複製する。セキュリティトークン200が異なるサーバーにマイグレーションするとき、セキュリティトークン200は変化する可能性がある。マイグレーションされたセキュリティトークン200は、そのサーバーのセキュリティトークンとインターセクトされる。実際のデータ構造体は変化しない。
【0021】
[0030]図3は、本発明の一実施形態によるセキュリティ記述子のレイアウト300の簡略化された図を示す。セキュリティ記述子300は、パーミッションをリソースに関連付けるのに使用されるデータ構造体である。特定のリソースについて、セキュリティ記述子300は、どのようなアカウントが、そのリソースに対してどのようなアクセスを有するのかを定義し、その特定のオブジェクトに関するすべてのルールを定義する。通常、オブジェクトのためのセキュリティ記述子300は、オーナーSID320、グループSID330、及び関連付けられるACL340を定義する。
【0022】
[0031]これらのすべてはオプションのエントリであるので、SD300は、オーナーSID320、グループSID330、及びACL340が構造体の最後にリストされた可変サイズの構造体として定義される。バージョンフィールド310及びフラグフィールド312は、どのような値がSD300に含まれるのかを指定するためにSD構造体300内に設けられる。フィールド314も、SD構造体300の合計サイズを定義するために設けられる。
【0023】
[0032]セキュリティトークン(すなわち、図2の200)とセキュリティ記述子300との間の関係によって、アクセス権の制御が決まる。スレッドがリソースにアクセスするとき(例えば、ファイルである写真が例えば/windows/myphotos/に作成される)、[[.]][[That]]そのコールは最終的にはサーバーに入り、サーバーは、コーラーがこのリソースにアクセスすることができるか否かを判断する。サーバーは、そのコールから、リソースへのアクセス権を定義するセキュリティ記述子300を構築する。したがって、サーバーが、だれがこのリソースにアクセスすることができるのかを識別するセキュリティ記述子300を一旦有すると、サーバーは、コーラーのセキュリティトークン(すなわち、図2の200)を見て、コーラーの識別情報を決定する。次に、サーバーは、セキュリティ記述子において定義された識別情報がACEのうちの1つにあるか否かを判断しようと試みる。セキュリティ記述子で定義された識別情報がACEのうちの1つにある場合、サーバーは、その識別情報のアクセス権が何であるのかを判断する。その識別情報のアクセスが拒否される場合、そのコールは拒否される。その識別情報のアクセスが読み出し(read)と書いてある場合、読み出しパーミッションのみがこのコーラーに与えられる。
【0024】
[0033]したがって、コールとそのコールを受け取った特定のリソースとの間のインターセクションをセキュリティトークンを使用して識別しなければならず、その識別情報がどのようなパーミッションをセキュリティ記述子300において有するのかを判断しなければならない。オペレーティングシステム内では、多数のアカウントIDを設けることができる。プロセス内部で動作を開始するあらゆるスレッドが、そのプロセスのためのアカウントIDを有するトークンを継承する。スレッドは、サービスの異なるフィールドをコールするとき、トークンが更新される。
【0025】
[0034]図4は、本発明の一実施形態によるアクセス制御リスト(ACL)400を示す。ACL400はアクセス制御エントリ(ACE)の集合である。ACEは、ACEヘッダー420、422及びACEに関連付けられるSID430、432を含む。ACEは、どのようなアクセス権が所与のSIDについて定義されているのかを識別する。図4では、ACL400は、リビジョンフィールド402、未使用のフィールド404、構造体の合計サイズを定義するフィールド406、ACLの最後におけるACEの個数を定義するフィールド408、及び第2の未使用フィールド410を含む。ACEの個数は事前に定義されていないので、ACL400は可変長構造体である。
【0026】
[0035]各ACEは、アカウントIDと、そのアカウントIDがそのオブジェクトに対してどのようなパーミッションを有するのかとを指定する。例えば、或る特定のACEは、アカウントID取得(account ID get)とすることができ、アクセスは、その特定のオブジェクトの読み出し専用である。別の特定のACEは、アカウントIDアドミニストレーターアクセス読み出し/書き込み(account ID administrator access read/write)とすることができ、これはすべての異なるACEの集合を提供し、それらのACEのそれぞれは、特定のアカウントについて、どのようなアクセスがこのリソースについて指定されているのかを定義する。
【0027】
[0036]デスクトップ上では、ACEは、各エントリについて異なるアクセス権を提供する。これらの異なるアクセス権は、Allow(許可)、Deny(拒否)、及びAudit(監査)を含む。WINDOWS(登録商標)CEオペレーティングシステムでは、権利は、所与のACEについて付与される。デフォルトの戻り値は、必要とされるアクセスマスクを有するACEがACL内にないときの「拒否」である。
【0028】
[0037]図5は、本発明の一実施形態によるアクセス制御エントリ(ACE)500のための構造体を示す。各ACE500は、どのようなタイプのアクセスがこのACE510によっていずれの識別情報(SIDによって与えられる)520に対して許可されているのかを定義する。SID520は可変長データアイテムであるので、ACE500も可変長構造体である。ACE500に関連付けられるSIDデータ520は、ACE構造体500の最後において開始する。ACE500は、フラグのフィールド530、構造体の合計サイズを識別するためのフィールド532、及びマスクフィールド534も含む。
【0029】
[0038]図6は、本発明の一実施形態によるセキュリティ記述子(SD)600のための構造レイアウトを示す。セキュリティ記述子(SD)600はヘッダー610を含む。SDヘッダー610は、SD600のバージョン、フラグ、及びサイズを識別する。SD600は、次に、オーナーセキュリティ識別子(SID)620及びグループセキュリティ識別子(SID)630を含む。残りのデータは、アクセス制御リスト(ACL)640を形成する。ACL640は、ACLヘッダー642及び1つ又は複数のアクセス制御エントリ(ACE)650を含む。ACLヘッダー642は、ACE650のバージョン、サイズ、及び個数を識別する。各ACE650は、ACEヘッダー652及び関連付けられるセキュリティ識別子(SID)654を含む。
【0030】
[0039]本発明の一実施形態によるセキュリティインフラストラクチャーは、プロセス又はスレッドが作成されるときに、セキュリティ記述子、セキュリティ識別子、アクセス制御リスト、及びアクセス制御エントリによって提供される。例えば、プロセストークンは、不変であり、プロセスが作成されるときに割り当てられる。デフォルトにより、セキュリティが設けられていない場合、すべてのプロセスは(トークン特権について)等しく扱われ、プロセスには、事前に定義されたシステムトークンが割り当てられる。これが、セキュリティが有効にされていないシステム上でのデフォルトの振る舞いである。このようなシステムでは、トラスト境界は、ユーザーモードとカーネルモードとの間の移行ポイントである。
【0031】
[0040]プロセストークンは、場合によっては、
・アカウントデータベース内のIDにマッピングされるexeエビデンス(パス、ハッシュ、証明書)、
・アカウントデータベース内の所与のアカウントのための基本特権、
・アカウントデータベース内の所与のアカウントのための拡張特権、
・コーラートークンに基づくグループIDのリスト、
のようないくつかのデータポイントの組み合わせとすることができる。
【0032】
[0041]所与の実行可能ファイル(executable)のエビデンスである最初の情報は、セキュアなローダーコンポーネントによって求められ、この文書の範囲外のものである。この特徴の目的で、エビデンスはアカウントデータベース内のIDにマッピングされるものと仮定する。これを前提として、OSは、アカウントデータベース内のアカウント情報からトークンを作成する。このトークンは、プロセスが作成されるときにプロセスオブジェクトに関連付けられ、プロセスの寿命の間中不変のままである。
【0033】
[0042]スレッドが作成されるとき、スレッドトークンが作成され、スレッドオブジェクトに関連付けられる。デフォルトにより、スレッドトークンは、スレッドのオーナープロセスに関連付けられるトークンと同一である。プロセストークンとスレッドトークンとの間の主な相違は、スレッドトークンは、スレッドの寿命を通じて変化する可能性があるのに対して、プロセストークンは、プロセスの寿命を通じて不変のままであるということである。例えば、スレッドトークンは、以下のときに変化する可能性がある。
【0034】
・所与のトークンを偽装するコール:このコールは、コール側のスレッドのアクティブトークンを、そのコールでImpersonate(偽装)に渡されるセキュリティトークンに変化させる。
【0035】
・前の偽装をリバート(revert)するコール:このコールは、スレッドトークンを偽装コール前のトークンに更新する。
【0036】
・現在のプロセスを偽装するコール:このコールは、現在のスレッドトークンを、現在のアクティブプロセスのスレッドトークンとなるように更新する。
【0037】
・APIコールからのスレッド復帰:APIコールの復帰のとき、カーネルは、スレッドが復帰している復帰元のPSLコンテキストに関連付けられるすべてのスレッドトークンを自動的に削除する。この場合、スレッドに関連付けられる現在のトークンも、APIコール前のトークンに更新される。
【0038】
[0043]図7は、本発明の一実施形態によるスレッド700のトークンリストのためのアレンジメントを示す。所与のスレッドのための複数のトークンを管理するために、トークンリスト700が設けられる。トークンリスト700は、スレッドに関連付けられるすべてのトークンのリンクリストである。スレッドのための現在のアクティブトークン710は、常に、トークンリスト700の先頭のトークンノードである。換言すれば、トークンリスト700は、リストに最後に追加されたトークンがスレッドの現在のトークンであるLIFOキュー(別称スタック)のように振舞う。現在のスレッドに対するすべてのアクセスチェック及び特権チェックは、その特有のトークンのみと、そのスレッドの現在のコンテキストとを使用してハンドリングされる。加えて、スレッドがAPIコールから復帰すると、カーネルは、保護されたサーバーライブラリ(PSL)712のコンテキストにおいて偽装コールによってこのリストに追加されたあらゆるトークンノードを自動的に削除する。この自動的なリバートによって、APIコール時のあらゆる特権リークが防止される。
【0039】
[0044]例えば、WINDOWS(登録商標)CEといったオペレーティングシステムでは、スレッドは、対応するAPIコールをハンドリングするサーバープロセス内に移行することによってAPIコールを行うことができる。各スレッドは、関連付けられるトークンを、そのトークンについて定義された識別情報/特権のセットと共に有するので、APIサーバーは、APIコールが現在のスレッド上で許可されるか否かを判定するのに、スレッドの現在の特権を考慮する必要がある。APIサーバーがAPIコールを完了するのに使用することができるトークンには2つの可能なトークンがある。
【0040】
・コーラーのトークン:この場合、APIサーバーは、CeAccessCheck(GetCurrentToken(), …)をコールする。これは、APIコールが高い特権を有するチャンバーから低い特権を有するチャンバー内へ入る場合に、潜在的なセキュリティリスクになる。実際には、高い特権という概念も低い特権という概念もない。しかしながら、この論述の目的で、高い特権チャンバーは、低い特権チャンバーのすべての特権及びいくつかの追加の特権を有するものと仮定する。
【0041】
・現在のプロセストークン:この場合、APIサーバーは、現在のスレッドのトークンが現在のプロセス(APIサーバーのトークン)となるように更新されるCeAccessCheck(ImpersonateCurrentProcess(), …)をコールする。これも、APIコールが低い特権を有するチャンバーから高い特権を有するチャンバー内へ入る場合に、潜在的なセキュリティリスクになる。
【0042】
[0045]あらゆるスレッドが、最初にオーナープロセストークン720で開始する。したがって、オーナープロセストークン720は、スレッド700のためのトークンレイアウトを示す図7の下部にリストされている。スレッドは、異なるコーラーから又はメッセージキューから非同期にトークンを受け取ることができる。さらに、スレッドがそのトークンに基づいてリソースにアクセスしたいとき。スレッドは、プロセストークンを使用したくないが、代わりに、自身の識別情報を変更したい。したがって、スレッドは、APIのうちの1つをコールしてそのAPIを偽装することができる。このAPIは、そのトークンをトークンリストの最上部にプッシュする。したがって、スレッドがトークンをコールし、そのトークンを偽装するときはいつでも、そのトークンはリストの最上部になる。図7では、偽装されたトークン730が、オーナープロセストークン720の上に示されている。図7には、N個の偽装されたトークン730〜750のチェーンが示されている。
【0043】
[0046]スレッドがアクセスするどのリソースも、最上部のトークン750、すなわち現在のトークン710内のトークンに対してチェックされる。偽装が起動されるときはいつでも、偽装トークン750が、常にオーナープロセストークン720とインターセクトされる。したがって、スレッドがリソースにアクセスするときはいつでも、オーナープロセストークン720は、そのリソースにおいてアクセス権を提示しなければならず、偽装されただけのトークン750も、そのリソースにアクセス可能でなければならない。このように、スレッドは、異なるサーバーへ移行しているときに異なるサーバーにAPIコールを行うことができる。加えて、コンタクトチェーン上にいくつかのサーバーが存在する場合、すべてのサーバーは、そのリソースにアクセス可能でなければならない。
【0044】
[0047]3つのすべてのチェックが検証された場合、スレッドへのアクセスが許可される。重要なことに、このプロセスは、個々の特権を提供することとは異なる。例えば、動作が現在のトークン750にのみ基づいている場合でかつ現在のトークン750が、より高い特権を偶然有する場合には、それによって、特権が昇格される。逆に、動作がコーラーのトークン720にのみ基づいている場合には、その動作は、高い特権サーバーから低い特権サーバーへマイグレーションされたものである。したがって、どちらの場合にも、個々の特権のみが使用されるとき、特権の可能な昇格に起因してセキュリティリスクがもたらされる。
【0045】
[0048]一旦APIコールが完了し、APIコールが復帰されると、トークンは、あらゆる特権反復(iteration of privilege)のリークを防止するためにサーバー内で行われる任意の偽装によってリバートされる。したがって、APIコールが復帰するときは、たとえサーバーが、自身が偽装したトークンをリバートするのを忘れても、サーバーは自動的にリバートされる。このように、クライアントも、自身がAPIコール前に何であろうとも、APIコールがそのトークンを返すときは、APIコール前のものに常にリバートして戻る。
【0046】
[0049]ご覧のように、コーラーのスレッドトークンのみ又は現在のプロセススレッドトークンのみを使用する場合にはセキュリティ問題が存在する。この問題を解決するために、本発明者らは、所与のスレッドによるリソースに対するアクセスをチェックするときに以下のことを考慮することを提案している。
【0047】
・スレッドの現在のトークンに関連付けられるすべての識別情報がリソースにアクセス可能であるべきである。
【0048】
・現在のスレッドコールスタック内のすべてのチャンバーに関連付けられるすべての識別情報(偽装境界まで)がリソースにアクセス可能であるべきである。
【0049】
・そのスレッドに関する保存されたコンテキストに関連付けられるすべての識別情報がリソースにアクセス可能であるべきである。このチェックは、主として、アクセスチェックが、コール側スレッド以外の異なるスレッド内のコーラーのために実行されるときに使用される。
【0050】
[0050]この変更は、アクセス/特権が所与のスレッド及びオブジェクトについてどのようにチェックされるのかに影響を与える。コードが任意のオブジェクトにアクセスするには、スレッドの現在のトークン750及びAPIサーバーのトークン、すなわちオーナープロセス/スレッドトークン720の双方が、そのオブジェクトにアクセス可能であるべきである。コードが任意の特権を取得するには、スレッドの現在のトークン750及びAPIサーバーのトークン720(この例では)がその特権セットを有するべきである。その結果、スレッドの現在のトークン750は、現在のスレッドのコールスタックチェーン700と常に組み合わせられるので、コードは、デフォルトにより、常に最小アクセス/特権セットで動作する。これによって、アクセス/特権チェックを現在のスレッドに対して実行するときに、コーラーのトークン720のみ又は現在のプロセストークン750のみのいずれかを使用することから生じるセキュリティ問題をハンドリングするセキュアなプロセスが提供される。トークンAPIのいくつかの論述が、本明細書において表1を参照して以下で提供される。
【0051】
【表1】
【0052】
[0051]以下の説明は、コア偽装API及びアクセスチェックAPIについてのものである。表1にリストされた最初のトークンはCeCreateToken(pToken, flags)であり、(pToken, flags)フィールドはトークン構造体へのポインタ及びフラグを提供する。トークンへのハンドルが返される。
【0053】
[0052]CeImpersonateTokenは、任意のアプリケーションが所与のトークンを偽装するのに使用することができる。これは、コーラーのために非同期コールを実行するのにも使用される。このAPIのための実施は、このトークンを現在のスレッドのトークンリストのためのスタックの最上部にプッシュし、このトークンをそのスレッドの現在のトークンにすることである。このAPIコールは、現在のプロセストークンを、このAPIコールへの指定されたトークンと常にマージし、マージされたトークンは現在のスレッドのトークンとして扱われる。
【0054】
[0053]加えて、(現在のプロセストークンによって与えられた)現在のプロセス識別情報は、トークン識別情報の過去のもの(the passed)に暗黙的に追加される。これを行う主な理由は、コーラーがこのAPIコールで任意の特権を取得することを防止するためである。換言すれば、このAPIは、降格することに制限されるか、又は多くとも現在のプロセスと同じ特権を有する。これによって、デフォルトにより最小特権レベルでのコード実行が可能になる。その使用法は次の通りである。すなわち、APIコール時に、現在のスレッドのトークンはスタッシュされ、そのAPIコールをコール時のコーラーのコンテキストで実行するためにAPIサーバーいおいて非同期スレッドによって後に使用される。
【0055】
[0054]CeImpersonateCurrentProcess(void)トークンは、現在のスレッドのトークンが更新される場合にはTRUEを返し、そうでない場合にはFALSEを返す。CeRevertToSelfトークンは、現在のスレッドのトークンリストのトークンを「ポップ」するのに使用される。通常、これは、CeImpersonateTokenAPIコール又はCeImpersonateCurrentProcessAPIコールを介して行われたあらゆるトークン偽装をAPIサーバーがアンドゥーするのに使用される。CeImpersonateCurrentProcessトークンは、現在のスレッドのためのトークンリストを現在のプロセストークンにトランケートするのに使用される。これは、現在のプロセストークンを現在のスレッドのトークンリストの先頭に効果的に「プッシュ」する。
【0056】
[0055]CeAccessCheckトークンは、3つの引数を取り込む。第1の引数は、アクセスを要求しているオブジェクトのためのパーミッションセットを表すSDである。第2の引数は、オブジェクトへのアクセスを要求する識別情報であるトークンである。第3の引数は、オブジェクトへの所望のアクセスである。CeAccessCheckトークンは、所与のトークンにおける各アカウントについて及び所与のSDにリストされた各ACEについて所与のアクセスをチェックするのに使用される。このAPIは、所与のトークンにおける各アカウントについて及び所与のSDにリストされた各ACEについて所与のアクセスをチェックする。
【0057】
[0056]CePrivilegeCheckトークンは、所与のトークンにおける所与の特権アクセスをチェックする。このAPIは、所与のトークンにおける所与の特権アクセスをチェックする。APIが成功するには、(pPrivilegesアレイで指定された)すべての所与の特権が、トークンの基本特権リスト又は拡張特権リスト内に存在しなければならない。
【0058】
[0057]CeGetProcessAccount(hProcess)トークンは、所与のプロセスに関連付けられるオーナーアカウントを返す。CeGetThreadAccount(hThread)トークンは、所与のスレッドに関連付けられるオーナーアカウントを返す。CeGetOwnerAccount(hToken)トークンは、所与のトークンに関連付けられるオーナーアカウントを返す。CeGetGroupAccount(hToken, idx)トークンは、トークンのハンドル及びグループアカウントのインデックスを使用して、所与のトークンに関連付けられるグループアカウントを返す。GetCurrentToken (void)トークンは、疑似ハンドルをスレッドの現在のトークンに提供する。
【0059】
[0058]図8は、本発明の一実施形態によるPSLコール800のためのスレッドのためのコールスタックリストを示す。動作中、カーネルは、スレッドごとにそのスレッドと共にコールスタック構造体のリストを保持する。PSLコール及びPLSコール復帰ごとに、スレッドのためのコールスタックリスト800が更新される。図8では、4つのコールスタック810、820、830、840が示されている。最後のコールスタック840は、最上部にあり、現在のコールスタックである。PLSコールエントリ時に、新しいコールスタックが追加される。APIコール復帰時には、最上部のコールスタック構造体が削除される。コールスタック構造体800は、スレッドがマイグレーションした1つのPSLサーバーに対応する。
【0060】
[0059]図9は、本発明の一実施形態によるスレッドのための、偽装リストとコールスタックリストとの間のリンク900を示すブロック図である。コールスタック構造体と同様に、スレッドのためのトークンは、トークンリストの最上部に、現在の偽装を有するリスト内に保持される。図9には、4つのコールスタック910、920、930、940が示されている。最後のコールスタック940は、最上部にあり、現在のコールスタックである。PSLコールにわたって特権リークがないことを確実にするために、カーネルは、現在のスレッドのための偽装リストと現在のスレッドのためのコールスタックリストとの間のリンクを保持する。各偽装ノードは、その偽装コールが発生したコールスタック構造体に関連付けられる。
【0061】
[0060]したがって、図9では、アプリケーションに属するスレッドがPSLサーバーS1 910にマイグレーションしている。PSLサーバーS1は、偽装APIをコールし、その結果、偽装ノード912が偽装リストに追加され、関連付けられるコールスタックS1が、偽装ノードT1 912においてマーキングされる。次に、PSLサーバーS1がPSLサーバーS2 920にマイグレーションする。S2は、偽装コールを行わない。次に、スレッドが、同じコールでS3 930にマイグレーションし、S3サーバーが偽装トークンをコールするとき。新しい偽装ノード932がトークンリストに追加され、関連付けられるコールスタック構造体S3 930がT2 932に記される。
【0062】
[0061]リソースチェックは、スレッドの寿命の異なる段階で実行される。例えば、S1 910からのアクセスチェックを考える。この場合、リソースは、スレッドがS1プロセス910にマイグレーションしたときにアクセスについてチェックを受けることになる。以下のチェックが実行される。
【0063】
・トークンT1におけるすべての識別情報がリソースにアクセス可能であるべきである。
【0064】
・プロセスS1に関連付けられるトークンにおけるすべての識別情報がリソースにアクセス可能であるべきである。
【0065】
[0062]次に、S2 920からのアクセスチェックを考える。この場合、リソースは、スレッドがS1 910プロセスを介してS2 920プロセスにマイグレーションしたときにアクセスについてチェックを受けることになる。この場合、以下のチェックが実行される。
【0066】
・トークンT1におけるすべての識別情報は、リソースにアクセス可能であるべきである。
【0067】
・プロセスS2に関連付けられるトークンにおけるすべての識別情報がリソースにアクセスできるべきである。
【0068】
・プロセスS1に関連付けられるトークンにおけるすべての識別情報がリソースにアクセスできるべきである。
【0069】
[0063]S3 930からのアクセスチェックを実行する際、スレッドは、S1 910を介しS2 920を介してプロセスS3 930にマイグレーションする。アクセスチェックは、S3 930からコールされたものである。以下のチェックが実行される。
【0070】
・トークンT2におけるすべての識別情報がリソースにアクセス可能であるべきである。
【0071】
・プロセスS3に関連付けられるトークンにおけるすべての識別情報がリソースにアクセス可能であるべきである。
【0072】
[0064]この場合、たとえスレッドのフルコンテキストがプロセスS2 920及びS1 910をそのコールチェーンに有していても、S3 930はトークンを偽装し、偽装はコールスタックチェーンを効果的に切断するので、アクセスチェックは、これらのプロセスに対して行われないことに留意されたい。
【0073】
[0065](コールスタックの最上部940としてリストされた)現在のプロセスからのアクセスチェックを実行する際、スレッドコールスタックチェーン900におけるS3プロセス930と現在のプロセス940との間にもはやトークン偽装はない。以下のチェックが実行される。
【0074】
・トークンT2におけるすべての識別情報がリソースにアクセス可能であるべきである。
【0075】
・コールスタックチェーンにおける現在のプロセス対プロセスS3に関連付けられるトークンにおけるすべての識別情報がリソースにアクセス可能であるべきである。
【0076】
[0066]したがって、アクセスチェックの基本ルールは、現在のスレッドのためのトークンリストの先頭のトークンである現在のトークンがリソースにアクセス可能であるべきか否か、及び偽装をコールした現在のプロセスから最後のプロセスまでのすべてのプロセス(現在のプロセス及び最後のプロセスを含む)がリソースにアクセス可能であるべきか否かを含む。
【0077】
[0067]CeGetAcccessMaskAPIは、所与のSDのトークンに割り当てられた最大アクセスを返すために提供することができる。このようなAPIは、3つの引数、すなわち
・アクセスをチェックしたい識別情報のリストを有するトークン
・所与のリソースのための異なるIDに関連付けられるACEをリストするセキュリティ記述子
・所与のSD及びトークンの組み合わせに関する最大アクセスセットを返す[出力]パラメーター([out] parameter)
を使用して実施することができる。
【0078】
[0068]このAPIの実施は簡単である。すなわち、トークンにおける各IDについて、SD内にAllow ACEが存在するか否かを判断するチェックが実行される。存在する場合、そのACEに関連付けられるアクセスマスクが、返されるアクセスマスク値に追加される。このステップは、現在のスレッドコンテキストの各トークンについて(最後の偽装まで)繰り返され、すべてのトークンにおいて設定されたそのアクセスマスクのみを返す。CeAccessCheckとは異なり、このAPIコールは、SD内のすべてのACEをスキャンして、一致するIDを有するすべてのアクセスマスクの和集合をトークンから得る必要があることに留意されたい。
【0079】
[0069]加えて、CeDuplicateTokenAPIは、以下の引数を取り込むことによって提供することができる。
【0080】
・コーラーがコピーしようと試みているソーストークンへのハンドル
・コール側プロセス内の新しくコピーされたトークンオブジェクトのコピーのトークンオブジェクトへのハンドルへの[出力]ポインタ
[0070]図10は、本発明の一実施形態によるメッセージキューシステム1000を示す。メッセージキュー1010は、本発明の一実施形態によるクライアント1020のプロセスとサーバー1030のプロセスとの間の非同期メッセージングを提供する。このメッセージキュー1010によって、クライアント1020は、メッセージキュー1010の書き込み側をオープンすることが可能になり、サーバー1030は、メッセージキュー1010の読み出し側をオープンすることが可能になる。クライアント1020及びサーバー1030は、メッセージ及び他のデータをメッセージキュー1010にポストすることができる。複数のメッセージキュー1010を設けることができ、このようなメッセージキュー1010は非同期に動作する。したがって、クライアント1020がメッセージを書き込み、その後去ると、クライアント1020は、肯定応答も、どのタイプの信号も待つことはない。サーバー1030は、その後、メッセージを取り出し、リトリーブしたメッセージに基づいて或る動作を実行することができる。サーバー1030がメッセージを取り出すとき、サーバー1030は、そのメッセージを書き込んだ時点においてそのメッセージを実際に保持するスレッドのセキュリティクレデンシャルを有しなければならない。コンタクトは、サーバー1030がそのメッセージを読み出す時までに変化する可能性があり、したがって、サーバー1030がメッセージを読み出すとき、サーバーが実際にコンタクトスナップショットにアクセスすることができ、そのスナップショットを偽装し、その後、メッセージを作成して結果を返信することができるように、コンタクトスナップショットのコピーが作成されてメッセージと共に書き込まれていなければならない。
【0081】
[0071]メッセージ及びそのメッセージを送信した者の識別情報を、サーバー1030がそれらのために動作することができるように、サーバー1030に非同期に渡すプロセスに加えて、メッセージ及びそのメッセージのポスターの識別情報、並びにメッセージがポストされた時点で存在するメッセージのポスターのセキュリティコンタクト全体も、プロセスの一部である。このように、よりセキュアな判定をその後になって行うことができる。しかしながら、当業者は、本発明が、本明細書で説明したようなメッセージキューを使用することに限定されるよう意図されていないことを認識する。それどころか、スレッドのためのコンタクトチェーンをサーバーに提供するための他の技法も可能である。
【0082】
[0072]プロセスが開始するとき、そのプロセスには或る識別情報が割り当てられ、そのプロセスにおけるスレッドのそれぞれにその識別情報が与えられる。スレッドがシステム上の他のプロセスにマイグレーションするとき、これらのスレッドは、該スレッドに関するセキュリティ判定が開始されるときに、それらの識別情報のすべてをインターセクトしてスレッドのアクセス特権を求めることができるように、それらの他のプロセスの識別情報を累積する。さらに、プロセスは、どの特定のサーバーにも特有のものでないように意図されている。それどころか、どのサーバーもこのモデルを使用することができる。例えばWINDOWS(登録商標)オペレーティングシステム上では、データトークンが入力される場合、特定の特権、すなわち偽装特権が存在しなければならない。偽装の結果、最悪の場合に権利が降格されることから、偽装は許可される。
【0083】
[0073]例えばデスクトップ上での複数のコーラーを伴うシナリオでは、アプリケーションが、オペレーティングシステムによってエクスポートされるファイル作成(create file)又は他の任意のAPIをコールするとき、スレッドは、カーネルモードにおいてユーザーの境界で停止し、カーネル内部の別のスレッドが、そのAPIのための動作をスピンオフして実行し、その後、そのコールをスレッドに返す。したがって、スレッドは、デスクトップ上において、実際には或るプロセスから別のプロセスに移行することになる。それに対して、WINDOWS(登録商標)CEオペレーティングシステム上では、アプリケーションがAPIコールを行うとき、スレッドは、実際にはサーバープロセスに移行する。
【0084】
[0074]通常、サーバープロセスは、クライアントよりも高い特権である。したがって、アプリケーションがレジスタオープンキーをコールして、レジストリをオープンし、その特定のレジストリが、低い特権アプリケーションが読み出すことができない保護されたキーである場合、スレッド上のそのコール及びそのスレッドは、レジストリAPIを実際に実施するサーバープロセスにマイグレーションする。そのサーバープロセスがアクセスキーを携行している場合、これは、コーラーのセキュリティコンタクトが考慮されていないので、その同じ種類の振る舞いとなる。一方、コーラーのセキュリティコンタクトが現在のセキュリティコンタクトと比較される場合、その保護されたリソースへのアクセスは拒否される。
【0085】
[0075]Windows Mobile(登録商標)オペレーティングシステムのスレッドは実際にマイグレーションし、セキュリティコンタクト情報はスレッドと共に保持されなければならないので、デスクトップWINDOWS(登録商標)オペレーティングシステムとWindows Mobile(登録商標)オペレーティングシステムとは異なる。その時になって初めて、コンタクト全体に基づいてリソースへのアクセスがいつ要求されたのかの判定を行うことができる。デスクトップの場合、ユーザーモードからカーネルモードへ移行する時点で、現在のスレッドコンタクトをコピーしなければならず、その後、カーネルスレッド上で、コーラーが移行され、動作は、あたかもそのコーラーのために完了されたかのように完了される。動作が一旦完了されると、元のセキュリティコンタクトへ戻る移行が実行され、その結果がコーラーに返される。
【0086】
[0076]特定のスレッドのためのセキュリティコンタクトは、シリアル化及びデシリアル化される。例えばWindows Mobile(登録商標)オペレーティングシステムでは、データベースレコードを更新することができる者及び編集することができる者を制限するように、データベースレコードが保護される。セキュリティを提供するために、レコードのセキュリティコンタクトがレコードと共に保存される。したがって、例えば、レコードを更新するコールが行われたとき、コーラーが、要求されたデータベースオペレーションを実行するのに十分なアクセスを有するか否かを調べるために、そのレコードのセキュリティコンタクト及びコーラーも伝達することができる。このプロセスを成し遂げるために、データベースは永続的であることから、セキュリティコンタクトは、オフラインデータベースにおいて処理可能でなければならない。したがって、Windows Mobile(登録商標)オペレーティングシステムを実行しているデバイスが設定され、そのデバイスが復帰するときは、データベースレコードが同じコンタクトをまだ保存しているか否かの判断が行われる。コーラーが識別されたとき、そのコンタクトチェーン内のすべてのアカウントが求められ、その後、ファイルとして保存される。新しいコールが行われたとき、コーラーがコンタクトチェーン内のアカウントのサブセットであることを保証するために、ファイルが再び構築され、保存されたファイルと比較される。
【0087】
[0077]アプリケーションがサーバーをコールした場合、サーバーは、或るスレッドにおいて動作を実行する。異なるスレッドでは、すべてのリソースがコーラーのためにアクセスされるように、コーラーを偽装することができる。クライアントからのセキュリティコンタクトのスナップショットは、基本的には、送信者の名称、現在のコンタクトチェーン内のすべてのコーラー、どのようなアカウント又は異なるアカウントがコンタクトチェーン内にあるのか、及び異なるサーバーへのマイグレーションが行われたか否かを読み出すことを含む。例えば、アプリケーション4RXEは、或るサーバーをコールしており、その時、その同じスレッドが別のサーバーをコールする可能性がある。したがって、複数のサーバーがコンタクトチェーン上に存在する可能性がある。しかしながら、それらのどの1つも、適切にアクセス可能でなければならない。したがって、コンタクトスナップショットがとられたとき、現在コンタクトにあるすべてのアカウントがキャプチャされなければならない。
【0088】
[0078]特に、スレッドがシステムを通じてマイグレーションするとき、スレッドは異なるサーバーを通過して異なる権利を有するので、そのスレッドのセキュリティコンタクトは変化する。それらの権利のすべてのインターセクションを求めなければならない。セキュリティ判定を行うには、一時点のスナップショットをとることができる必要がある。換言すれば、セキュリティチェックが行われるとき、チェックを非同期又は後に実行することができるように、検証されるすべてのIDが保存される必要がある。
【0089】
[0079]上述したシステム及びコンポーネントは、ネットワーク接続環境、分散環境、又は他のコンピューター実施される環境の一部として実施することができる。これらのシステム及びコンポーネントは、有線通信ネットワーク、無線通信ネットワーク、及び/又はそれらの通信ネットワークの組み合わせを介して通信することができる。デスクトップコンピューター、ラップトップ、ハンドヘルド、又は他のスマートデバイスを含む複数のクライアントコンピューティングデバイスがこのシステムとインターラクトすることができかつ/又はこのクライアントコンピューティングデバイスをこのシステムの一部として含めることができる。代替的な実施形態では、所望の実施態様に従ってさまざまなコンポーネントを組み合わせかつ/又は構成することができる。他の実施形態及び構成も利用可能である。
【0090】
[0080]次に図11を参照して、以下の論述は、本発明の実施形態を実施することができる適したコンピューティング環境の簡潔で一般的な説明を提供するように意図されている。本発明は、パーソナルコンピューターのオペレーティングシステム上で動作するプログラムモジュールと共に実行されるプログラムモジュールの一般的なコンテキストで説明されるが、当業者は、本発明が、他のタイプのコンピューターシステム及びプログラムモジュールと組み合わせて実施することもできることを認識するであろう。
【0091】
[0081]一般に、プログラムモジュールには、特定のタスクを実行するか又は特定の抽象データタイプを実施するルーチン、プログラム、コンポーネント、データ構造体、及び他のタイプの構造体が含まれる。その上、当業者は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースの民生用電子機器又はプログラマブル民生用電子機器、ミニコンピューター、メインフレームコンピューター等を含む他のコンピューターシステム構成で本発明を実施することができることを認識するであろう。本発明は、タスクが、通信ネットワークを通じてリンクされたリモート処理デバイスによって実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールをローカルメモリストレージデバイス及びリモートメモリストレージデバイスの双方に配置することができる。
【0092】
[0082]次に図11を参照して、本発明の実施形態の実例となる動作環境を説明する。図11に示すように、コンピューター1100には、汎用のデスクトップコンピューター、ラップトップコンピューター、ハンドヘルドコンピューター、又は1つ又は複数のアプリケーションプログラミングを実行することができる他のタイプのコンピューターが含まれる。コンピューター1100は、少なくとも1つの中央処理装置1108(「CPU」)、ランダムアクセスメモリ1118(「RAM」)及び読み出し専用メモリ(「ROM」)1120を含むシステムメモリ1112、並びにメモリをCPU1108に結合するシステムバス1110を含む。スタートアップ中等にコンピューター内のエレメント間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システムが、ROM1120内に記憶される。コンピューター1100は、オペレーティングシステム1132、アプリケーションプログラム、及び他のプログラムモジュールを記憶するためのマスストレージデバイス1114をさらに含む。
【0093】
[0083]マスストレージデバイス1114は、バス1110に接続されたマスストレージコントローラ(図示せず)を通じてCPU1108に接続される。マスストレージデバイス1114及びそれに関連付けられるコンピューター可読媒体は、コンピューター1100のための不揮発性ストレージを提供する。本明細書に含まれるコンピューター可読媒体の説明は、ハードディスク又はCD−ROMドライブ等のマスストレージデバイスを指すが、コンピューター可読媒体は、コンピューター1100がアクセス又は利用することができる任意の利用可能な媒体とすることができることが当業者によって認識されるべきである。
【0094】
[0084]限定ではなく例として、コンピューター可読媒体には、コンピューターストレージ媒体及び通信媒体を含めることができる。コンピューターストレージ媒体には、コンピューター可読命令、データ構造体、プログラムモジュール、又は他のデータ等の情報の記憶のための任意の方法又は技術で実施される揮発性及び不揮発性の着脱可能及び着脱不能な媒体が含まれる。コンピューターストレージ媒体には、RAM、ROM、EPROM、EEPROM、フラッシュメモリ、若しくは他のソリッドステートメモリ技術、CD−ROM、デジタル多用途ディスク(「DVD」)、若しくは他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、若しくは他の磁気ストレージデバイス、又は所望の情報を記憶するのに使用することができかつコンピューター1100がアクセスすることができる他の任意の媒体が含まれるが、これらに限定されるものではない。
【0095】
[0085]本発明のさまざまな実施形態によれば、コンピューター2は、例えばローカルネットワーク、インターネット等のネットワーク1104を通じたリモートコンピューターへの論理接続を使用してネットワーク接続環境で動作することができる。コンピューター1100は、バス1110に接続されたネットワークインターフェースユニット1116を通じてネットワーク1104に接続することができる。ネットワークインターフェースユニット1116は、他のタイプのネットワーク及びリモートコンピューティングシステムに接続するのに利用することもできることが認識されるべきである。コンピューター1100は、キーボード、マウス等(図示せず)を含む複数の他のデバイスからの入力を受け取って処理するための入出力コントローラー1122も含むことができる。同様に、入出力コントローラー1122は、表示スクリーン、プリンタ、又は他のタイプの出力デバイスに出力を提供することもできる。
【0096】
[0086]上記で簡略的に述べたように、ワシントン州レドモンドのマイクロソフト社(Microsoft Corporation)が提供しているWINDOWS(登録商標)オペレーティングシステム等、ネットワーク接続されたパーソナルコンピューターのオペレーションを制御するのに適したオペレーティングシステム1132を含めて、複数のプログラムモジュール及びデータファイルをコンピューター1100のマスストレージデバイス1114及びRAM1118に記憶することができる。マスストレージデバイス1114及びRAM1118は、1つ又は複数のプログラムモジュールも記憶することができる。特に、マスストレージデバイス1114及びRAM1118は、クライアントアプリケーションプログラム1140及び他のソフトウェアアプリケーション1142を記憶することができる。図11に示すようなコンピューター1100は、図1〜図10で説明したような本発明の実施形態によるセキュリティインフラストラクチャーを提供する命令を実行するように構成することができる。
【0097】
[0087]本発明のさまざまな実施形態は、(1)コンピューター実施されるアクト若しくはコンピューティングシステム上で動作するプログラムモジュールのシーケンスとしてかつ/又は(2)コンピューティングシステム内の相互接続されたマシン論理回路若しくは回路モジュールとして実施できることが認識されるべきである。この実施は、本発明を実施するコンピューティングシステムの性能要件に応じた選択の問題である。したがって、関係したアルゴリズムを含む論理オペレーションは、オペレーション、構造デバイス、アクト、又はモジュールとさまざまに呼ぶことができる。これらのオペレーション、構造デバイス、アクト、及びモジュールは、本出願で述べられた特許請求の範囲内に挙げられた本発明の趣旨及び範囲から逸脱することなく、ソフトウェア、ファームウェア、専用デジタルロジック、及びそれらの任意の組み合わせで実施できることが当業者によって認識される。
【0098】
[0088]本発明を、さまざまな例示の実施形態に関して説明してきたが、当業者は、次の特許請求の範囲の範囲内においてそれらの実施形態に多くの変更を行えることを理解する。したがって、本発明の範囲が上記説明によっていかなる形においても限定されることは意図されておらず、それよりむしろ、専ら次の特許請求の範囲を参照することによって判断されることが意図されている。
【技術分野】
【0001】
本発明は、コンピューティングプロセスのための最小特権アクセスの付与に関する。
【背景技術】
【0002】
[0001]デバイスは、リソース、アプリケーション等へのアクセスを制御するセキュリティインフラストラクチャーで構成される場合がある。現在、移動デバイスでは、トラスト(trust)がコード識別情報に基づいて個々のアプリケーションに割り当てられる。セキュリティインフラストラクチャーは、どのようなアプリケーションがデバイス上で動作し得るのか、どのようなアプリケーションをロックアウトすることができるのか、どのようなアプリケーションをどのようなコンテキストで動作させることができるのか、及びこのようなアプリケーションがどのようなリソースにアクセスすることができるのかを判断する。現在のトラストレベルは、未署名のモジュールについて「トラステッド(信頼できる、trusted)」、「ノーマル」、及び「アントラステッド(信頼できない、untrusted)」を含む。アプリケーション又はモジュールは、トラステッド証明書、又はトラステッド証明書ストアにチェーンする証明書で署名を受けることができる。この場合、そのモジュールはトラステッドであるとみなされ、したがって、そのモジュールのどのコードも、システム上のすべての特権を有するAPI及びリソースにアクセスすることができる。トラスト判定は、コーラー(caller)のアプリケーショントラストレベルに基づく。
【発明の概要】
【発明が解決しようとする課題】
【0003】
[0002]しかしながら、上述した現在のセキュリティモデルにはいくつかの問題がある。スレッドがシステムの複数の保護されたサーバーライブラリ(PSL)サーバーを通じてマイグレーションするとき、コールチェーンの直接のコール側プロセスがシステムリソースへのアクセスに対するパーミッションを有することが可能であるが、コールチェーンコンテキスト全体を検査することによって、リソースがアクセス可能であるべきでないことが明らかにされる場合がある。このようなセキュリティは、セキュリティ判定が常に直接のコーラーのコンテキストにのみ基づいている場合に強制することができない。また、現在のセキュリティモデルは、低い特権を有するアプリケーションがシステムサービスをコールする場合において異なる識別情報に偽装することにも備えておらず、システムサービスは、コーラーのコンテキスト又はそれ自身のコンテキストのいずれかに基づいて要求を処理するように求められる。またさらに、非同期アクセス要求について、現在のセキュリティモデルは、コーラーのコンテキストが完全に利用可能でないことがあり得る場合において2次スレッドのセキュリティチェックに備えていない。
【0004】
[0003]本出願は、本発明が行ったこれらの検討事項及び他の検討事項に関するものである。
【課題を解決するための手段】
【0005】
[0004]この概要は、詳細な説明でさらに後述する概念のうちの選択したものを簡略化した形態で紹介するために設けられている。この概要は、特許請求される主題の重要な特徴も本質的な特徴も特定するように意図されたものではなく、また、特許請求される主題の範囲を決定することを助けるものとして意図されたものでもない。
【0006】
[0005]デフォルトによる最小特権を可能にするために、現在のスレッドの識別情報及び現在のスレッドのコールチェーンコンテキストの双方を考慮することによってセキュリティ判定を行う実施の形態が提供される。現在のスレッドコンテキストがキャプチャされ、そのコピーが作成されて、セキュリティチェックを非同期に実行するのに使用される。システムにおけるあらゆるスレッドが、関連付けられる識別情報を有する。最初に、この識別情報は、親プロセスから導出される。しかしながら、スレッドの寿命の間、この識別情報はスレッドの任意の偽装に基づいて変化し得ることが可能である。
【0007】
[0006]これらの特徴及び利点並びに他の特徴及び利点は、以下の詳細な説明を読み、関連付けられる図面をレビューすることによって明らかになるであろう。上述の一般的な説明も以下の詳細な説明も、例示にすぎず、特許請求される本発明を限定するものではないことが理解されるべきである。
【図面の簡単な説明】
【0008】
【図1】[0007]本発明の一実施形態によるセキュリティ識別子(SID)100を示す図である。
【図2】[0008]本発明の一実施形態によるセキュリティトークン構造体200のレイアウトを示す図である。
【図3】[0009]本発明の一実施形態によるセキュリティ記述子のレイアウト300の簡略化された図である。
【図4】[0010]本発明の一実施形態によるアクセス制御リスト(ACL)400を示す図である。
【図5】[0011]本発明の一実施形態によるアクセス制御エントリ(ACE)500のための構造体を示す図である。
【図6】[0012]本発明の一実施形態によるセキュリティ記述子(SD)600のための構造レイアウトを示す図である。
【図7】[0013]本発明の一実施形態によるスレッド700のトークンリストのためのアレンジメントを示す図である。
【図8】[0014]本発明の一実施形態によるPSLコール800におけるスレッドのためのコールスタックリストを示す図である。
【図9】[0015]本発明の一実施形態によるスレッド900のための、偽装リストとコールスタックリストとの間のリンク900を示すブロック図である。
【図10】[0016]本発明の一実施形態によるメッセージキューシステム1000を示す図である。
【図11】[0017]本発明の実施形態を実施することができるコンピューティング環境を示す図である。
【発明を実施するための形態】
【0009】
[0018]実施形態は、既存のオペレーティングシステムの上部で動作して、どのようなリソースがアプリケーションによってアクセス可能であるのか及びどのようなAPIをアプリケーションがコールすることができるのかを制御するように構成することができるセキュリティインフラストラクチャーを提供する。デフォルトにより最小特権を可能にするために、現在のスレッドの識別情報及び現在のスレッドのコールチェーンコンテキストの双方を考慮することにより、セキュリティ判定が行われる。現在のスレッドコンテキストがキャプチャされ、そのコピーが作成されて、セキュリティチェックを非同期に実行するのに使用される。システムにおけるあらゆるスレッドは、関連付けられる識別情報を有する、最初に、この識別情報は、親プロセスから導出されるが、スレッドの寿命の間、この識別情報は、スレッドが行う任意の偽装に基づいて変化し得ることが可能である。
【0010】
[0019]実施形態は、どのようなコール又はアプリケーションが要求しているのかを分析するだけでなく、そのコールがどこから生じたものであるのかも分析する。実施形態は、エンドユーザー又はエンドオペレーターが自身の制御下にない場合がある異なるアプリケーションをインストールすることができるようにオープンエンドであるシステムのためのセキュリティインフラストラクチャーも提供することができる。したがって、スレッドがアクセスする権限を有しないリソースから該スレッドが誤ってアクセスされることに基づいてセキュリティ問題が発生することを防止するために、システムにおけるすべてのスレッドは、デフォルトにより最小特権で動作することができる。それどころか、特定のリソースにアクセスするときは、各コーラー及び各スレッドがそのリソースにアクセスすることができることを確認するために、現在のスレッドのすべてのコーラーが分析される。各コーラー及び各スレッドがそのリソースへアクセスすることができるときにのみ、そのコーラーには、そのリソースへのアクセスが与えられる。
【0011】
[0020]本発明の実施形態は、どのリソースがアプリケーションによりアクセス可能であるのか及びアプリケーションがどのようなAPIをコールすることができるのかを制御するためのセキュリティインフラストラクチャーを提供するデータ構造体を使用して実施することができる。このデータ構造体は、次の要素、すなわち、セキュリティ識別子(SID)、セキュリティトークン、セキュリティ記述子(SD)、アクセス制御リスト(ACL),及びアクセス制御エントリ(ACE)を含む。
【0012】
[0021]図1は、本発明の一実施形態によるセキュリティ識別子(SID)100を示す。SID100は、システム内で一意のIDを定義し、特定のスレッドがどのようなアカウントで動作しているのかを指定する可変長データ構造体110である。SID100は、ユーザーアカウントのようなものであると考えることもできる。例えば、或る人がコンピューターにログオンしたとき、さまざまなユーザーアカウントが、適切なログオンパスワードを使用してアクセス可能になる場合がある。ユーザーアカウントは、コンピューターにログオンしている人を識別する。SID100は、単にスレッド又はプロセスを識別するアカウントである。SID100は、特定のデバイス内においてのみ一意である。しかしながら、当業者は、本明細書における本発明の実施形態の説明を分析した後、グローバルセキュリティ識別子を使用することができることを認識する。
【0013】
[0022]デスクトップ上において、SID100を、個々のユーザーアカウント、一定のシステムアカウント、及び一定のユーザーグループに割り当てることができる。WINDOWS(登録商標)CEオペレーティングシステムにおけるアカウントは、例えば、デスクトップのWINDOWS(登録商標)オペレーティングシステムに関して使用されるものと必ずしも同じ定義であるとは限らないことに留意されたい。それにもかかわらず、当業者は、何がアカウントを構成するのかを理解する。本明細書では、SID100は、アカウントデータベース内のエントリにマッピングされる、例えばWINDOWS(登録商標)CEオペレーティングシステムといったオペレーティングシステム全体にわたって一意の識別子であるものと仮定される。アカウントデータベース内のエントリは、どのような基本特権及び拡張特権が特定のアカウント(別称SID)に割り当てられているのかを指定する。
【0014】
[0023]図2は、本発明の一実施形態によるセキュリティトークン構造体200のレイアウトを示す。セキュリティトークン200は、識別情報のセット及びそれらの識別情報に割り当てられた特権の集合を定義するのに使用される。通常、セキュリティトークン200は、プロセス、スレッド、同期のようなランタイムオブジェクト及びメッセージキュー内の個々のメッセージに関連付けられる。セキュリティトークン200は、この構造体のバージョン202、フラグ204、オフセット206、直接グループ(immediate group)の個数207、及びグループIDの総数208を識別するためのフィールドを含む。セキュリティトークン200の構造体は、プライマリオーナーSID210、グループSID(複数可)212、基本特権(basic privilege)214、及び拡張特権(extended privilege)216も記憶することができる。
【0015】
[0024]プライマリSID210及びグループSID(複数可)212は、このセキュリティトークン200を有するオブジェクトに関連付けられる識別情報を定義する。基本特権214及び拡張特権216は、どのような特権が、このセキュリティトークン200に関連付けられたオブジェクトに許可されるのかを定義する。基本特権214は、セキュリティトークン200において指定された識別情報に有効な特権のセットである。同様に、拡張特権216は、セキュリティトークン200におけるSIDのリストについて定義されたカスタム特権(custom privilege)である。
【0016】
[0025]基本セキュリティトークン構造体200は、このセキュリティトークン200に関連付けられるプライマリSID210及びグループSID212並びにこのセキュリティトークン200に関連付けられる拡張特権216等のセキュリティトークン200のための拡張(オプション)データへのオフセットポインタ206を有する。セキュリティトークン200における個々の各SID210、212は、SDが指定されたオブジェクトに、所与のセキュリティトークン200が所望のアクセスを行うことができるか否かを判断するために、AccessCheck(アクセスチェック)APIコールにおいて使用される。また、セキュリティトークン200における基本特権[[212]]214及び拡張特権[[214]]216は、所与のセキュリティトークン200が特権を必要としていたか否かを判断するために、PrivilegeCheck(特権チェック)APIコールにおいて使用される。API及びセキュリティトークン200の使用は、本明細書の以下で説明するトークンAPIの論述を参照してより詳細に論述される。
【0017】
[0026]アカウントの文字列表現が作成され、この文字列表現は、セキュリティトークン構造体200で使用されるDWordにマッピングされる。その場合、セキュリティトークン200は、システムにおける読み出されたスレッドに関連付けられるオブジェクトである。したがって、あらゆるスレッドは、特定のセキュリティトークン200で開始する。セキュリティトークン200は、この特定のスレッドが、特定のアカウントIDを有する特定のチャンバーに属することを示すと共に該スレッドが一定のグループのメンバであることも示す識別情報のリストを有する基本トークン構造体220を含む。各セキュリティトークン200は、セットによって表される。したがって、セキュリティトークン構造体は、構造体及び複数のセットを含む。第1のセットはオーナーセットである。それは、一意のIDがシステム内の各チャンバー又はシステム内の各アカウントに与えられることを意味する。その場合、ゼロ個又は1つ以上のグループメンバーシップであるグループアカウントIDが存在する可能性がある。それらのグループアカウントIDは、拡張トークンデータ222において与えられる。
【0018】
[0027]デスクトップ用のセキュリティトークン構造体も同様である。例えば、デスクトップをリセットするために定義された特権又はドライバーをインストールするために定義された特権が存在する可能性がある。したがって、特定のコーラーが特定の特権セットを有する場合、そのコーラーのみが、そのAPIコールを行うことができ、そのコーラーのみがデバイスをリセットするか又はドライバーをインストールすることができる。これらは特有の特権である。基本特権は1つのDWordのみとすることができ、それによって、そのDWordは基本特権[[212]]214に結び付けられ、そして、拡張トークンデータ222の一部である任意の個数の拡張特権[[214]]216が存在し得る。
【0019】
[0028]多くの特権214、216が存在し得るが、特権214、216は、アクセスチェックがリソースについて動作するように正確に機能する。したがって、特定のAPIが特定の特権を必要とする場合、又は特定のAPIが、特定のコーラーが特定の特権を有することを必要とする場合、コンタクトチェーン内のあらゆるコーラーがその特定の特権を有しなければならない。すべてのコーラーがその特権を有するときにのみ、そのコールは通過することが許可される。あらゆるトークンは、基本トークン構造体220と少なくとも同程度の情報を有するべきである。
【0020】
[0029]拡張トークン構造体222はオプションの設定である。したがって、一例として、アカウントは、1つ又は複数のグループのメンバである場合がある。したがって、拡張トークン構造体222は可変サイズを有し、すなわちサイズは固定でないのに対して、基本トークン構造体のサイズは固定である。セキュリティトークン200は、あらゆるプロセスに関連付けられ、それゆえ、プロセス内のあらゆるスレッドは、開始時にそのセキュリティトークン200を受け取るか又は複製する。セキュリティトークン200が異なるサーバーにマイグレーションするとき、セキュリティトークン200は変化する可能性がある。マイグレーションされたセキュリティトークン200は、そのサーバーのセキュリティトークンとインターセクトされる。実際のデータ構造体は変化しない。
【0021】
[0030]図3は、本発明の一実施形態によるセキュリティ記述子のレイアウト300の簡略化された図を示す。セキュリティ記述子300は、パーミッションをリソースに関連付けるのに使用されるデータ構造体である。特定のリソースについて、セキュリティ記述子300は、どのようなアカウントが、そのリソースに対してどのようなアクセスを有するのかを定義し、その特定のオブジェクトに関するすべてのルールを定義する。通常、オブジェクトのためのセキュリティ記述子300は、オーナーSID320、グループSID330、及び関連付けられるACL340を定義する。
【0022】
[0031]これらのすべてはオプションのエントリであるので、SD300は、オーナーSID320、グループSID330、及びACL340が構造体の最後にリストされた可変サイズの構造体として定義される。バージョンフィールド310及びフラグフィールド312は、どのような値がSD300に含まれるのかを指定するためにSD構造体300内に設けられる。フィールド314も、SD構造体300の合計サイズを定義するために設けられる。
【0023】
[0032]セキュリティトークン(すなわち、図2の200)とセキュリティ記述子300との間の関係によって、アクセス権の制御が決まる。スレッドがリソースにアクセスするとき(例えば、ファイルである写真が例えば/windows/myphotos/に作成される)、[[.]][[That]]そのコールは最終的にはサーバーに入り、サーバーは、コーラーがこのリソースにアクセスすることができるか否かを判断する。サーバーは、そのコールから、リソースへのアクセス権を定義するセキュリティ記述子300を構築する。したがって、サーバーが、だれがこのリソースにアクセスすることができるのかを識別するセキュリティ記述子300を一旦有すると、サーバーは、コーラーのセキュリティトークン(すなわち、図2の200)を見て、コーラーの識別情報を決定する。次に、サーバーは、セキュリティ記述子において定義された識別情報がACEのうちの1つにあるか否かを判断しようと試みる。セキュリティ記述子で定義された識別情報がACEのうちの1つにある場合、サーバーは、その識別情報のアクセス権が何であるのかを判断する。その識別情報のアクセスが拒否される場合、そのコールは拒否される。その識別情報のアクセスが読み出し(read)と書いてある場合、読み出しパーミッションのみがこのコーラーに与えられる。
【0024】
[0033]したがって、コールとそのコールを受け取った特定のリソースとの間のインターセクションをセキュリティトークンを使用して識別しなければならず、その識別情報がどのようなパーミッションをセキュリティ記述子300において有するのかを判断しなければならない。オペレーティングシステム内では、多数のアカウントIDを設けることができる。プロセス内部で動作を開始するあらゆるスレッドが、そのプロセスのためのアカウントIDを有するトークンを継承する。スレッドは、サービスの異なるフィールドをコールするとき、トークンが更新される。
【0025】
[0034]図4は、本発明の一実施形態によるアクセス制御リスト(ACL)400を示す。ACL400はアクセス制御エントリ(ACE)の集合である。ACEは、ACEヘッダー420、422及びACEに関連付けられるSID430、432を含む。ACEは、どのようなアクセス権が所与のSIDについて定義されているのかを識別する。図4では、ACL400は、リビジョンフィールド402、未使用のフィールド404、構造体の合計サイズを定義するフィールド406、ACLの最後におけるACEの個数を定義するフィールド408、及び第2の未使用フィールド410を含む。ACEの個数は事前に定義されていないので、ACL400は可変長構造体である。
【0026】
[0035]各ACEは、アカウントIDと、そのアカウントIDがそのオブジェクトに対してどのようなパーミッションを有するのかとを指定する。例えば、或る特定のACEは、アカウントID取得(account ID get)とすることができ、アクセスは、その特定のオブジェクトの読み出し専用である。別の特定のACEは、アカウントIDアドミニストレーターアクセス読み出し/書き込み(account ID administrator access read/write)とすることができ、これはすべての異なるACEの集合を提供し、それらのACEのそれぞれは、特定のアカウントについて、どのようなアクセスがこのリソースについて指定されているのかを定義する。
【0027】
[0036]デスクトップ上では、ACEは、各エントリについて異なるアクセス権を提供する。これらの異なるアクセス権は、Allow(許可)、Deny(拒否)、及びAudit(監査)を含む。WINDOWS(登録商標)CEオペレーティングシステムでは、権利は、所与のACEについて付与される。デフォルトの戻り値は、必要とされるアクセスマスクを有するACEがACL内にないときの「拒否」である。
【0028】
[0037]図5は、本発明の一実施形態によるアクセス制御エントリ(ACE)500のための構造体を示す。各ACE500は、どのようなタイプのアクセスがこのACE510によっていずれの識別情報(SIDによって与えられる)520に対して許可されているのかを定義する。SID520は可変長データアイテムであるので、ACE500も可変長構造体である。ACE500に関連付けられるSIDデータ520は、ACE構造体500の最後において開始する。ACE500は、フラグのフィールド530、構造体の合計サイズを識別するためのフィールド532、及びマスクフィールド534も含む。
【0029】
[0038]図6は、本発明の一実施形態によるセキュリティ記述子(SD)600のための構造レイアウトを示す。セキュリティ記述子(SD)600はヘッダー610を含む。SDヘッダー610は、SD600のバージョン、フラグ、及びサイズを識別する。SD600は、次に、オーナーセキュリティ識別子(SID)620及びグループセキュリティ識別子(SID)630を含む。残りのデータは、アクセス制御リスト(ACL)640を形成する。ACL640は、ACLヘッダー642及び1つ又は複数のアクセス制御エントリ(ACE)650を含む。ACLヘッダー642は、ACE650のバージョン、サイズ、及び個数を識別する。各ACE650は、ACEヘッダー652及び関連付けられるセキュリティ識別子(SID)654を含む。
【0030】
[0039]本発明の一実施形態によるセキュリティインフラストラクチャーは、プロセス又はスレッドが作成されるときに、セキュリティ記述子、セキュリティ識別子、アクセス制御リスト、及びアクセス制御エントリによって提供される。例えば、プロセストークンは、不変であり、プロセスが作成されるときに割り当てられる。デフォルトにより、セキュリティが設けられていない場合、すべてのプロセスは(トークン特権について)等しく扱われ、プロセスには、事前に定義されたシステムトークンが割り当てられる。これが、セキュリティが有効にされていないシステム上でのデフォルトの振る舞いである。このようなシステムでは、トラスト境界は、ユーザーモードとカーネルモードとの間の移行ポイントである。
【0031】
[0040]プロセストークンは、場合によっては、
・アカウントデータベース内のIDにマッピングされるexeエビデンス(パス、ハッシュ、証明書)、
・アカウントデータベース内の所与のアカウントのための基本特権、
・アカウントデータベース内の所与のアカウントのための拡張特権、
・コーラートークンに基づくグループIDのリスト、
のようないくつかのデータポイントの組み合わせとすることができる。
【0032】
[0041]所与の実行可能ファイル(executable)のエビデンスである最初の情報は、セキュアなローダーコンポーネントによって求められ、この文書の範囲外のものである。この特徴の目的で、エビデンスはアカウントデータベース内のIDにマッピングされるものと仮定する。これを前提として、OSは、アカウントデータベース内のアカウント情報からトークンを作成する。このトークンは、プロセスが作成されるときにプロセスオブジェクトに関連付けられ、プロセスの寿命の間中不変のままである。
【0033】
[0042]スレッドが作成されるとき、スレッドトークンが作成され、スレッドオブジェクトに関連付けられる。デフォルトにより、スレッドトークンは、スレッドのオーナープロセスに関連付けられるトークンと同一である。プロセストークンとスレッドトークンとの間の主な相違は、スレッドトークンは、スレッドの寿命を通じて変化する可能性があるのに対して、プロセストークンは、プロセスの寿命を通じて不変のままであるということである。例えば、スレッドトークンは、以下のときに変化する可能性がある。
【0034】
・所与のトークンを偽装するコール:このコールは、コール側のスレッドのアクティブトークンを、そのコールでImpersonate(偽装)に渡されるセキュリティトークンに変化させる。
【0035】
・前の偽装をリバート(revert)するコール:このコールは、スレッドトークンを偽装コール前のトークンに更新する。
【0036】
・現在のプロセスを偽装するコール:このコールは、現在のスレッドトークンを、現在のアクティブプロセスのスレッドトークンとなるように更新する。
【0037】
・APIコールからのスレッド復帰:APIコールの復帰のとき、カーネルは、スレッドが復帰している復帰元のPSLコンテキストに関連付けられるすべてのスレッドトークンを自動的に削除する。この場合、スレッドに関連付けられる現在のトークンも、APIコール前のトークンに更新される。
【0038】
[0043]図7は、本発明の一実施形態によるスレッド700のトークンリストのためのアレンジメントを示す。所与のスレッドのための複数のトークンを管理するために、トークンリスト700が設けられる。トークンリスト700は、スレッドに関連付けられるすべてのトークンのリンクリストである。スレッドのための現在のアクティブトークン710は、常に、トークンリスト700の先頭のトークンノードである。換言すれば、トークンリスト700は、リストに最後に追加されたトークンがスレッドの現在のトークンであるLIFOキュー(別称スタック)のように振舞う。現在のスレッドに対するすべてのアクセスチェック及び特権チェックは、その特有のトークンのみと、そのスレッドの現在のコンテキストとを使用してハンドリングされる。加えて、スレッドがAPIコールから復帰すると、カーネルは、保護されたサーバーライブラリ(PSL)712のコンテキストにおいて偽装コールによってこのリストに追加されたあらゆるトークンノードを自動的に削除する。この自動的なリバートによって、APIコール時のあらゆる特権リークが防止される。
【0039】
[0044]例えば、WINDOWS(登録商標)CEといったオペレーティングシステムでは、スレッドは、対応するAPIコールをハンドリングするサーバープロセス内に移行することによってAPIコールを行うことができる。各スレッドは、関連付けられるトークンを、そのトークンについて定義された識別情報/特権のセットと共に有するので、APIサーバーは、APIコールが現在のスレッド上で許可されるか否かを判定するのに、スレッドの現在の特権を考慮する必要がある。APIサーバーがAPIコールを完了するのに使用することができるトークンには2つの可能なトークンがある。
【0040】
・コーラーのトークン:この場合、APIサーバーは、CeAccessCheck(GetCurrentToken(), …)をコールする。これは、APIコールが高い特権を有するチャンバーから低い特権を有するチャンバー内へ入る場合に、潜在的なセキュリティリスクになる。実際には、高い特権という概念も低い特権という概念もない。しかしながら、この論述の目的で、高い特権チャンバーは、低い特権チャンバーのすべての特権及びいくつかの追加の特権を有するものと仮定する。
【0041】
・現在のプロセストークン:この場合、APIサーバーは、現在のスレッドのトークンが現在のプロセス(APIサーバーのトークン)となるように更新されるCeAccessCheck(ImpersonateCurrentProcess(), …)をコールする。これも、APIコールが低い特権を有するチャンバーから高い特権を有するチャンバー内へ入る場合に、潜在的なセキュリティリスクになる。
【0042】
[0045]あらゆるスレッドが、最初にオーナープロセストークン720で開始する。したがって、オーナープロセストークン720は、スレッド700のためのトークンレイアウトを示す図7の下部にリストされている。スレッドは、異なるコーラーから又はメッセージキューから非同期にトークンを受け取ることができる。さらに、スレッドがそのトークンに基づいてリソースにアクセスしたいとき。スレッドは、プロセストークンを使用したくないが、代わりに、自身の識別情報を変更したい。したがって、スレッドは、APIのうちの1つをコールしてそのAPIを偽装することができる。このAPIは、そのトークンをトークンリストの最上部にプッシュする。したがって、スレッドがトークンをコールし、そのトークンを偽装するときはいつでも、そのトークンはリストの最上部になる。図7では、偽装されたトークン730が、オーナープロセストークン720の上に示されている。図7には、N個の偽装されたトークン730〜750のチェーンが示されている。
【0043】
[0046]スレッドがアクセスするどのリソースも、最上部のトークン750、すなわち現在のトークン710内のトークンに対してチェックされる。偽装が起動されるときはいつでも、偽装トークン750が、常にオーナープロセストークン720とインターセクトされる。したがって、スレッドがリソースにアクセスするときはいつでも、オーナープロセストークン720は、そのリソースにおいてアクセス権を提示しなければならず、偽装されただけのトークン750も、そのリソースにアクセス可能でなければならない。このように、スレッドは、異なるサーバーへ移行しているときに異なるサーバーにAPIコールを行うことができる。加えて、コンタクトチェーン上にいくつかのサーバーが存在する場合、すべてのサーバーは、そのリソースにアクセス可能でなければならない。
【0044】
[0047]3つのすべてのチェックが検証された場合、スレッドへのアクセスが許可される。重要なことに、このプロセスは、個々の特権を提供することとは異なる。例えば、動作が現在のトークン750にのみ基づいている場合でかつ現在のトークン750が、より高い特権を偶然有する場合には、それによって、特権が昇格される。逆に、動作がコーラーのトークン720にのみ基づいている場合には、その動作は、高い特権サーバーから低い特権サーバーへマイグレーションされたものである。したがって、どちらの場合にも、個々の特権のみが使用されるとき、特権の可能な昇格に起因してセキュリティリスクがもたらされる。
【0045】
[0048]一旦APIコールが完了し、APIコールが復帰されると、トークンは、あらゆる特権反復(iteration of privilege)のリークを防止するためにサーバー内で行われる任意の偽装によってリバートされる。したがって、APIコールが復帰するときは、たとえサーバーが、自身が偽装したトークンをリバートするのを忘れても、サーバーは自動的にリバートされる。このように、クライアントも、自身がAPIコール前に何であろうとも、APIコールがそのトークンを返すときは、APIコール前のものに常にリバートして戻る。
【0046】
[0049]ご覧のように、コーラーのスレッドトークンのみ又は現在のプロセススレッドトークンのみを使用する場合にはセキュリティ問題が存在する。この問題を解決するために、本発明者らは、所与のスレッドによるリソースに対するアクセスをチェックするときに以下のことを考慮することを提案している。
【0047】
・スレッドの現在のトークンに関連付けられるすべての識別情報がリソースにアクセス可能であるべきである。
【0048】
・現在のスレッドコールスタック内のすべてのチャンバーに関連付けられるすべての識別情報(偽装境界まで)がリソースにアクセス可能であるべきである。
【0049】
・そのスレッドに関する保存されたコンテキストに関連付けられるすべての識別情報がリソースにアクセス可能であるべきである。このチェックは、主として、アクセスチェックが、コール側スレッド以外の異なるスレッド内のコーラーのために実行されるときに使用される。
【0050】
[0050]この変更は、アクセス/特権が所与のスレッド及びオブジェクトについてどのようにチェックされるのかに影響を与える。コードが任意のオブジェクトにアクセスするには、スレッドの現在のトークン750及びAPIサーバーのトークン、すなわちオーナープロセス/スレッドトークン720の双方が、そのオブジェクトにアクセス可能であるべきである。コードが任意の特権を取得するには、スレッドの現在のトークン750及びAPIサーバーのトークン720(この例では)がその特権セットを有するべきである。その結果、スレッドの現在のトークン750は、現在のスレッドのコールスタックチェーン700と常に組み合わせられるので、コードは、デフォルトにより、常に最小アクセス/特権セットで動作する。これによって、アクセス/特権チェックを現在のスレッドに対して実行するときに、コーラーのトークン720のみ又は現在のプロセストークン750のみのいずれかを使用することから生じるセキュリティ問題をハンドリングするセキュアなプロセスが提供される。トークンAPIのいくつかの論述が、本明細書において表1を参照して以下で提供される。
【0051】
【表1】
【0052】
[0051]以下の説明は、コア偽装API及びアクセスチェックAPIについてのものである。表1にリストされた最初のトークンはCeCreateToken(pToken, flags)であり、(pToken, flags)フィールドはトークン構造体へのポインタ及びフラグを提供する。トークンへのハンドルが返される。
【0053】
[0052]CeImpersonateTokenは、任意のアプリケーションが所与のトークンを偽装するのに使用することができる。これは、コーラーのために非同期コールを実行するのにも使用される。このAPIのための実施は、このトークンを現在のスレッドのトークンリストのためのスタックの最上部にプッシュし、このトークンをそのスレッドの現在のトークンにすることである。このAPIコールは、現在のプロセストークンを、このAPIコールへの指定されたトークンと常にマージし、マージされたトークンは現在のスレッドのトークンとして扱われる。
【0054】
[0053]加えて、(現在のプロセストークンによって与えられた)現在のプロセス識別情報は、トークン識別情報の過去のもの(the passed)に暗黙的に追加される。これを行う主な理由は、コーラーがこのAPIコールで任意の特権を取得することを防止するためである。換言すれば、このAPIは、降格することに制限されるか、又は多くとも現在のプロセスと同じ特権を有する。これによって、デフォルトにより最小特権レベルでのコード実行が可能になる。その使用法は次の通りである。すなわち、APIコール時に、現在のスレッドのトークンはスタッシュされ、そのAPIコールをコール時のコーラーのコンテキストで実行するためにAPIサーバーいおいて非同期スレッドによって後に使用される。
【0055】
[0054]CeImpersonateCurrentProcess(void)トークンは、現在のスレッドのトークンが更新される場合にはTRUEを返し、そうでない場合にはFALSEを返す。CeRevertToSelfトークンは、現在のスレッドのトークンリストのトークンを「ポップ」するのに使用される。通常、これは、CeImpersonateTokenAPIコール又はCeImpersonateCurrentProcessAPIコールを介して行われたあらゆるトークン偽装をAPIサーバーがアンドゥーするのに使用される。CeImpersonateCurrentProcessトークンは、現在のスレッドのためのトークンリストを現在のプロセストークンにトランケートするのに使用される。これは、現在のプロセストークンを現在のスレッドのトークンリストの先頭に効果的に「プッシュ」する。
【0056】
[0055]CeAccessCheckトークンは、3つの引数を取り込む。第1の引数は、アクセスを要求しているオブジェクトのためのパーミッションセットを表すSDである。第2の引数は、オブジェクトへのアクセスを要求する識別情報であるトークンである。第3の引数は、オブジェクトへの所望のアクセスである。CeAccessCheckトークンは、所与のトークンにおける各アカウントについて及び所与のSDにリストされた各ACEについて所与のアクセスをチェックするのに使用される。このAPIは、所与のトークンにおける各アカウントについて及び所与のSDにリストされた各ACEについて所与のアクセスをチェックする。
【0057】
[0056]CePrivilegeCheckトークンは、所与のトークンにおける所与の特権アクセスをチェックする。このAPIは、所与のトークンにおける所与の特権アクセスをチェックする。APIが成功するには、(pPrivilegesアレイで指定された)すべての所与の特権が、トークンの基本特権リスト又は拡張特権リスト内に存在しなければならない。
【0058】
[0057]CeGetProcessAccount(hProcess)トークンは、所与のプロセスに関連付けられるオーナーアカウントを返す。CeGetThreadAccount(hThread)トークンは、所与のスレッドに関連付けられるオーナーアカウントを返す。CeGetOwnerAccount(hToken)トークンは、所与のトークンに関連付けられるオーナーアカウントを返す。CeGetGroupAccount(hToken, idx)トークンは、トークンのハンドル及びグループアカウントのインデックスを使用して、所与のトークンに関連付けられるグループアカウントを返す。GetCurrentToken (void)トークンは、疑似ハンドルをスレッドの現在のトークンに提供する。
【0059】
[0058]図8は、本発明の一実施形態によるPSLコール800のためのスレッドのためのコールスタックリストを示す。動作中、カーネルは、スレッドごとにそのスレッドと共にコールスタック構造体のリストを保持する。PSLコール及びPLSコール復帰ごとに、スレッドのためのコールスタックリスト800が更新される。図8では、4つのコールスタック810、820、830、840が示されている。最後のコールスタック840は、最上部にあり、現在のコールスタックである。PLSコールエントリ時に、新しいコールスタックが追加される。APIコール復帰時には、最上部のコールスタック構造体が削除される。コールスタック構造体800は、スレッドがマイグレーションした1つのPSLサーバーに対応する。
【0060】
[0059]図9は、本発明の一実施形態によるスレッドのための、偽装リストとコールスタックリストとの間のリンク900を示すブロック図である。コールスタック構造体と同様に、スレッドのためのトークンは、トークンリストの最上部に、現在の偽装を有するリスト内に保持される。図9には、4つのコールスタック910、920、930、940が示されている。最後のコールスタック940は、最上部にあり、現在のコールスタックである。PSLコールにわたって特権リークがないことを確実にするために、カーネルは、現在のスレッドのための偽装リストと現在のスレッドのためのコールスタックリストとの間のリンクを保持する。各偽装ノードは、その偽装コールが発生したコールスタック構造体に関連付けられる。
【0061】
[0060]したがって、図9では、アプリケーションに属するスレッドがPSLサーバーS1 910にマイグレーションしている。PSLサーバーS1は、偽装APIをコールし、その結果、偽装ノード912が偽装リストに追加され、関連付けられるコールスタックS1が、偽装ノードT1 912においてマーキングされる。次に、PSLサーバーS1がPSLサーバーS2 920にマイグレーションする。S2は、偽装コールを行わない。次に、スレッドが、同じコールでS3 930にマイグレーションし、S3サーバーが偽装トークンをコールするとき。新しい偽装ノード932がトークンリストに追加され、関連付けられるコールスタック構造体S3 930がT2 932に記される。
【0062】
[0061]リソースチェックは、スレッドの寿命の異なる段階で実行される。例えば、S1 910からのアクセスチェックを考える。この場合、リソースは、スレッドがS1プロセス910にマイグレーションしたときにアクセスについてチェックを受けることになる。以下のチェックが実行される。
【0063】
・トークンT1におけるすべての識別情報がリソースにアクセス可能であるべきである。
【0064】
・プロセスS1に関連付けられるトークンにおけるすべての識別情報がリソースにアクセス可能であるべきである。
【0065】
[0062]次に、S2 920からのアクセスチェックを考える。この場合、リソースは、スレッドがS1 910プロセスを介してS2 920プロセスにマイグレーションしたときにアクセスについてチェックを受けることになる。この場合、以下のチェックが実行される。
【0066】
・トークンT1におけるすべての識別情報は、リソースにアクセス可能であるべきである。
【0067】
・プロセスS2に関連付けられるトークンにおけるすべての識別情報がリソースにアクセスできるべきである。
【0068】
・プロセスS1に関連付けられるトークンにおけるすべての識別情報がリソースにアクセスできるべきである。
【0069】
[0063]S3 930からのアクセスチェックを実行する際、スレッドは、S1 910を介しS2 920を介してプロセスS3 930にマイグレーションする。アクセスチェックは、S3 930からコールされたものである。以下のチェックが実行される。
【0070】
・トークンT2におけるすべての識別情報がリソースにアクセス可能であるべきである。
【0071】
・プロセスS3に関連付けられるトークンにおけるすべての識別情報がリソースにアクセス可能であるべきである。
【0072】
[0064]この場合、たとえスレッドのフルコンテキストがプロセスS2 920及びS1 910をそのコールチェーンに有していても、S3 930はトークンを偽装し、偽装はコールスタックチェーンを効果的に切断するので、アクセスチェックは、これらのプロセスに対して行われないことに留意されたい。
【0073】
[0065](コールスタックの最上部940としてリストされた)現在のプロセスからのアクセスチェックを実行する際、スレッドコールスタックチェーン900におけるS3プロセス930と現在のプロセス940との間にもはやトークン偽装はない。以下のチェックが実行される。
【0074】
・トークンT2におけるすべての識別情報がリソースにアクセス可能であるべきである。
【0075】
・コールスタックチェーンにおける現在のプロセス対プロセスS3に関連付けられるトークンにおけるすべての識別情報がリソースにアクセス可能であるべきである。
【0076】
[0066]したがって、アクセスチェックの基本ルールは、現在のスレッドのためのトークンリストの先頭のトークンである現在のトークンがリソースにアクセス可能であるべきか否か、及び偽装をコールした現在のプロセスから最後のプロセスまでのすべてのプロセス(現在のプロセス及び最後のプロセスを含む)がリソースにアクセス可能であるべきか否かを含む。
【0077】
[0067]CeGetAcccessMaskAPIは、所与のSDのトークンに割り当てられた最大アクセスを返すために提供することができる。このようなAPIは、3つの引数、すなわち
・アクセスをチェックしたい識別情報のリストを有するトークン
・所与のリソースのための異なるIDに関連付けられるACEをリストするセキュリティ記述子
・所与のSD及びトークンの組み合わせに関する最大アクセスセットを返す[出力]パラメーター([out] parameter)
を使用して実施することができる。
【0078】
[0068]このAPIの実施は簡単である。すなわち、トークンにおける各IDについて、SD内にAllow ACEが存在するか否かを判断するチェックが実行される。存在する場合、そのACEに関連付けられるアクセスマスクが、返されるアクセスマスク値に追加される。このステップは、現在のスレッドコンテキストの各トークンについて(最後の偽装まで)繰り返され、すべてのトークンにおいて設定されたそのアクセスマスクのみを返す。CeAccessCheckとは異なり、このAPIコールは、SD内のすべてのACEをスキャンして、一致するIDを有するすべてのアクセスマスクの和集合をトークンから得る必要があることに留意されたい。
【0079】
[0069]加えて、CeDuplicateTokenAPIは、以下の引数を取り込むことによって提供することができる。
【0080】
・コーラーがコピーしようと試みているソーストークンへのハンドル
・コール側プロセス内の新しくコピーされたトークンオブジェクトのコピーのトークンオブジェクトへのハンドルへの[出力]ポインタ
[0070]図10は、本発明の一実施形態によるメッセージキューシステム1000を示す。メッセージキュー1010は、本発明の一実施形態によるクライアント1020のプロセスとサーバー1030のプロセスとの間の非同期メッセージングを提供する。このメッセージキュー1010によって、クライアント1020は、メッセージキュー1010の書き込み側をオープンすることが可能になり、サーバー1030は、メッセージキュー1010の読み出し側をオープンすることが可能になる。クライアント1020及びサーバー1030は、メッセージ及び他のデータをメッセージキュー1010にポストすることができる。複数のメッセージキュー1010を設けることができ、このようなメッセージキュー1010は非同期に動作する。したがって、クライアント1020がメッセージを書き込み、その後去ると、クライアント1020は、肯定応答も、どのタイプの信号も待つことはない。サーバー1030は、その後、メッセージを取り出し、リトリーブしたメッセージに基づいて或る動作を実行することができる。サーバー1030がメッセージを取り出すとき、サーバー1030は、そのメッセージを書き込んだ時点においてそのメッセージを実際に保持するスレッドのセキュリティクレデンシャルを有しなければならない。コンタクトは、サーバー1030がそのメッセージを読み出す時までに変化する可能性があり、したがって、サーバー1030がメッセージを読み出すとき、サーバーが実際にコンタクトスナップショットにアクセスすることができ、そのスナップショットを偽装し、その後、メッセージを作成して結果を返信することができるように、コンタクトスナップショットのコピーが作成されてメッセージと共に書き込まれていなければならない。
【0081】
[0071]メッセージ及びそのメッセージを送信した者の識別情報を、サーバー1030がそれらのために動作することができるように、サーバー1030に非同期に渡すプロセスに加えて、メッセージ及びそのメッセージのポスターの識別情報、並びにメッセージがポストされた時点で存在するメッセージのポスターのセキュリティコンタクト全体も、プロセスの一部である。このように、よりセキュアな判定をその後になって行うことができる。しかしながら、当業者は、本発明が、本明細書で説明したようなメッセージキューを使用することに限定されるよう意図されていないことを認識する。それどころか、スレッドのためのコンタクトチェーンをサーバーに提供するための他の技法も可能である。
【0082】
[0072]プロセスが開始するとき、そのプロセスには或る識別情報が割り当てられ、そのプロセスにおけるスレッドのそれぞれにその識別情報が与えられる。スレッドがシステム上の他のプロセスにマイグレーションするとき、これらのスレッドは、該スレッドに関するセキュリティ判定が開始されるときに、それらの識別情報のすべてをインターセクトしてスレッドのアクセス特権を求めることができるように、それらの他のプロセスの識別情報を累積する。さらに、プロセスは、どの特定のサーバーにも特有のものでないように意図されている。それどころか、どのサーバーもこのモデルを使用することができる。例えばWINDOWS(登録商標)オペレーティングシステム上では、データトークンが入力される場合、特定の特権、すなわち偽装特権が存在しなければならない。偽装の結果、最悪の場合に権利が降格されることから、偽装は許可される。
【0083】
[0073]例えばデスクトップ上での複数のコーラーを伴うシナリオでは、アプリケーションが、オペレーティングシステムによってエクスポートされるファイル作成(create file)又は他の任意のAPIをコールするとき、スレッドは、カーネルモードにおいてユーザーの境界で停止し、カーネル内部の別のスレッドが、そのAPIのための動作をスピンオフして実行し、その後、そのコールをスレッドに返す。したがって、スレッドは、デスクトップ上において、実際には或るプロセスから別のプロセスに移行することになる。それに対して、WINDOWS(登録商標)CEオペレーティングシステム上では、アプリケーションがAPIコールを行うとき、スレッドは、実際にはサーバープロセスに移行する。
【0084】
[0074]通常、サーバープロセスは、クライアントよりも高い特権である。したがって、アプリケーションがレジスタオープンキーをコールして、レジストリをオープンし、その特定のレジストリが、低い特権アプリケーションが読み出すことができない保護されたキーである場合、スレッド上のそのコール及びそのスレッドは、レジストリAPIを実際に実施するサーバープロセスにマイグレーションする。そのサーバープロセスがアクセスキーを携行している場合、これは、コーラーのセキュリティコンタクトが考慮されていないので、その同じ種類の振る舞いとなる。一方、コーラーのセキュリティコンタクトが現在のセキュリティコンタクトと比較される場合、その保護されたリソースへのアクセスは拒否される。
【0085】
[0075]Windows Mobile(登録商標)オペレーティングシステムのスレッドは実際にマイグレーションし、セキュリティコンタクト情報はスレッドと共に保持されなければならないので、デスクトップWINDOWS(登録商標)オペレーティングシステムとWindows Mobile(登録商標)オペレーティングシステムとは異なる。その時になって初めて、コンタクト全体に基づいてリソースへのアクセスがいつ要求されたのかの判定を行うことができる。デスクトップの場合、ユーザーモードからカーネルモードへ移行する時点で、現在のスレッドコンタクトをコピーしなければならず、その後、カーネルスレッド上で、コーラーが移行され、動作は、あたかもそのコーラーのために完了されたかのように完了される。動作が一旦完了されると、元のセキュリティコンタクトへ戻る移行が実行され、その結果がコーラーに返される。
【0086】
[0076]特定のスレッドのためのセキュリティコンタクトは、シリアル化及びデシリアル化される。例えばWindows Mobile(登録商標)オペレーティングシステムでは、データベースレコードを更新することができる者及び編集することができる者を制限するように、データベースレコードが保護される。セキュリティを提供するために、レコードのセキュリティコンタクトがレコードと共に保存される。したがって、例えば、レコードを更新するコールが行われたとき、コーラーが、要求されたデータベースオペレーションを実行するのに十分なアクセスを有するか否かを調べるために、そのレコードのセキュリティコンタクト及びコーラーも伝達することができる。このプロセスを成し遂げるために、データベースは永続的であることから、セキュリティコンタクトは、オフラインデータベースにおいて処理可能でなければならない。したがって、Windows Mobile(登録商標)オペレーティングシステムを実行しているデバイスが設定され、そのデバイスが復帰するときは、データベースレコードが同じコンタクトをまだ保存しているか否かの判断が行われる。コーラーが識別されたとき、そのコンタクトチェーン内のすべてのアカウントが求められ、その後、ファイルとして保存される。新しいコールが行われたとき、コーラーがコンタクトチェーン内のアカウントのサブセットであることを保証するために、ファイルが再び構築され、保存されたファイルと比較される。
【0087】
[0077]アプリケーションがサーバーをコールした場合、サーバーは、或るスレッドにおいて動作を実行する。異なるスレッドでは、すべてのリソースがコーラーのためにアクセスされるように、コーラーを偽装することができる。クライアントからのセキュリティコンタクトのスナップショットは、基本的には、送信者の名称、現在のコンタクトチェーン内のすべてのコーラー、どのようなアカウント又は異なるアカウントがコンタクトチェーン内にあるのか、及び異なるサーバーへのマイグレーションが行われたか否かを読み出すことを含む。例えば、アプリケーション4RXEは、或るサーバーをコールしており、その時、その同じスレッドが別のサーバーをコールする可能性がある。したがって、複数のサーバーがコンタクトチェーン上に存在する可能性がある。しかしながら、それらのどの1つも、適切にアクセス可能でなければならない。したがって、コンタクトスナップショットがとられたとき、現在コンタクトにあるすべてのアカウントがキャプチャされなければならない。
【0088】
[0078]特に、スレッドがシステムを通じてマイグレーションするとき、スレッドは異なるサーバーを通過して異なる権利を有するので、そのスレッドのセキュリティコンタクトは変化する。それらの権利のすべてのインターセクションを求めなければならない。セキュリティ判定を行うには、一時点のスナップショットをとることができる必要がある。換言すれば、セキュリティチェックが行われるとき、チェックを非同期又は後に実行することができるように、検証されるすべてのIDが保存される必要がある。
【0089】
[0079]上述したシステム及びコンポーネントは、ネットワーク接続環境、分散環境、又は他のコンピューター実施される環境の一部として実施することができる。これらのシステム及びコンポーネントは、有線通信ネットワーク、無線通信ネットワーク、及び/又はそれらの通信ネットワークの組み合わせを介して通信することができる。デスクトップコンピューター、ラップトップ、ハンドヘルド、又は他のスマートデバイスを含む複数のクライアントコンピューティングデバイスがこのシステムとインターラクトすることができかつ/又はこのクライアントコンピューティングデバイスをこのシステムの一部として含めることができる。代替的な実施形態では、所望の実施態様に従ってさまざまなコンポーネントを組み合わせかつ/又は構成することができる。他の実施形態及び構成も利用可能である。
【0090】
[0080]次に図11を参照して、以下の論述は、本発明の実施形態を実施することができる適したコンピューティング環境の簡潔で一般的な説明を提供するように意図されている。本発明は、パーソナルコンピューターのオペレーティングシステム上で動作するプログラムモジュールと共に実行されるプログラムモジュールの一般的なコンテキストで説明されるが、当業者は、本発明が、他のタイプのコンピューターシステム及びプログラムモジュールと組み合わせて実施することもできることを認識するであろう。
【0091】
[0081]一般に、プログラムモジュールには、特定のタスクを実行するか又は特定の抽象データタイプを実施するルーチン、プログラム、コンポーネント、データ構造体、及び他のタイプの構造体が含まれる。その上、当業者は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースの民生用電子機器又はプログラマブル民生用電子機器、ミニコンピューター、メインフレームコンピューター等を含む他のコンピューターシステム構成で本発明を実施することができることを認識するであろう。本発明は、タスクが、通信ネットワークを通じてリンクされたリモート処理デバイスによって実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールをローカルメモリストレージデバイス及びリモートメモリストレージデバイスの双方に配置することができる。
【0092】
[0082]次に図11を参照して、本発明の実施形態の実例となる動作環境を説明する。図11に示すように、コンピューター1100には、汎用のデスクトップコンピューター、ラップトップコンピューター、ハンドヘルドコンピューター、又は1つ又は複数のアプリケーションプログラミングを実行することができる他のタイプのコンピューターが含まれる。コンピューター1100は、少なくとも1つの中央処理装置1108(「CPU」)、ランダムアクセスメモリ1118(「RAM」)及び読み出し専用メモリ(「ROM」)1120を含むシステムメモリ1112、並びにメモリをCPU1108に結合するシステムバス1110を含む。スタートアップ中等にコンピューター内のエレメント間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システムが、ROM1120内に記憶される。コンピューター1100は、オペレーティングシステム1132、アプリケーションプログラム、及び他のプログラムモジュールを記憶するためのマスストレージデバイス1114をさらに含む。
【0093】
[0083]マスストレージデバイス1114は、バス1110に接続されたマスストレージコントローラ(図示せず)を通じてCPU1108に接続される。マスストレージデバイス1114及びそれに関連付けられるコンピューター可読媒体は、コンピューター1100のための不揮発性ストレージを提供する。本明細書に含まれるコンピューター可読媒体の説明は、ハードディスク又はCD−ROMドライブ等のマスストレージデバイスを指すが、コンピューター可読媒体は、コンピューター1100がアクセス又は利用することができる任意の利用可能な媒体とすることができることが当業者によって認識されるべきである。
【0094】
[0084]限定ではなく例として、コンピューター可読媒体には、コンピューターストレージ媒体及び通信媒体を含めることができる。コンピューターストレージ媒体には、コンピューター可読命令、データ構造体、プログラムモジュール、又は他のデータ等の情報の記憶のための任意の方法又は技術で実施される揮発性及び不揮発性の着脱可能及び着脱不能な媒体が含まれる。コンピューターストレージ媒体には、RAM、ROM、EPROM、EEPROM、フラッシュメモリ、若しくは他のソリッドステートメモリ技術、CD−ROM、デジタル多用途ディスク(「DVD」)、若しくは他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、若しくは他の磁気ストレージデバイス、又は所望の情報を記憶するのに使用することができかつコンピューター1100がアクセスすることができる他の任意の媒体が含まれるが、これらに限定されるものではない。
【0095】
[0085]本発明のさまざまな実施形態によれば、コンピューター2は、例えばローカルネットワーク、インターネット等のネットワーク1104を通じたリモートコンピューターへの論理接続を使用してネットワーク接続環境で動作することができる。コンピューター1100は、バス1110に接続されたネットワークインターフェースユニット1116を通じてネットワーク1104に接続することができる。ネットワークインターフェースユニット1116は、他のタイプのネットワーク及びリモートコンピューティングシステムに接続するのに利用することもできることが認識されるべきである。コンピューター1100は、キーボード、マウス等(図示せず)を含む複数の他のデバイスからの入力を受け取って処理するための入出力コントローラー1122も含むことができる。同様に、入出力コントローラー1122は、表示スクリーン、プリンタ、又は他のタイプの出力デバイスに出力を提供することもできる。
【0096】
[0086]上記で簡略的に述べたように、ワシントン州レドモンドのマイクロソフト社(Microsoft Corporation)が提供しているWINDOWS(登録商標)オペレーティングシステム等、ネットワーク接続されたパーソナルコンピューターのオペレーションを制御するのに適したオペレーティングシステム1132を含めて、複数のプログラムモジュール及びデータファイルをコンピューター1100のマスストレージデバイス1114及びRAM1118に記憶することができる。マスストレージデバイス1114及びRAM1118は、1つ又は複数のプログラムモジュールも記憶することができる。特に、マスストレージデバイス1114及びRAM1118は、クライアントアプリケーションプログラム1140及び他のソフトウェアアプリケーション1142を記憶することができる。図11に示すようなコンピューター1100は、図1〜図10で説明したような本発明の実施形態によるセキュリティインフラストラクチャーを提供する命令を実行するように構成することができる。
【0097】
[0087]本発明のさまざまな実施形態は、(1)コンピューター実施されるアクト若しくはコンピューティングシステム上で動作するプログラムモジュールのシーケンスとしてかつ/又は(2)コンピューティングシステム内の相互接続されたマシン論理回路若しくは回路モジュールとして実施できることが認識されるべきである。この実施は、本発明を実施するコンピューティングシステムの性能要件に応じた選択の問題である。したがって、関係したアルゴリズムを含む論理オペレーションは、オペレーション、構造デバイス、アクト、又はモジュールとさまざまに呼ぶことができる。これらのオペレーション、構造デバイス、アクト、及びモジュールは、本出願で述べられた特許請求の範囲内に挙げられた本発明の趣旨及び範囲から逸脱することなく、ソフトウェア、ファームウェア、専用デジタルロジック、及びそれらの任意の組み合わせで実施できることが当業者によって認識される。
【0098】
[0088]本発明を、さまざまな例示の実施形態に関して説明してきたが、当業者は、次の特許請求の範囲の範囲内においてそれらの実施形態に多くの変更を行えることを理解する。したがって、本発明の範囲が上記説明によっていかなる形においても限定されることは意図されておらず、それよりむしろ、専ら次の特許請求の範囲を参照することによって判断されることが意図されている。
【特許請求の範囲】
【請求項1】
実行可能命令を含むコンピューター可読媒体であって、該実行可能命令は、実行されると、
関連付けられるサブジェクトのための一意の識別子を定義し、該関連付けられるサブジェクトに関連付けられるアカウントを指定するためのセキュリティ識別子(100)を設けるステップと、
前記一意の識別子をアカウントデータベース内のエントリにマッピングするステップであって、前記セキュリティ識別子(100)に割り当てられた基本特権(214)及び拡張特権(216)を求める、マッピングするステップと、
前記関連付けられるサブジェクトのマイグレーションに沿って関連付けられるサブジェクトの識別子(210、212)を蓄積するステップと、
前記セキュリティ識別子(100)に割り当てられた前記基本特権(214)及び前記拡張特権(216)を求めることに基づいて、識別情報(210、212)のセット及び該識別情報のセットに割り当てられた特権の集合を定義するためのセキュリティトークン(200)を作成するステップと、
前記関連付けられるサブジェクトの前記蓄積された識別子(210、212)のすべて及び前記特権(214、216)の集合をインターセクトすることによって前記関連付けられるサブジェクトのアクセス特権を求めるステップと
によって、関連付けられるサブジェクトによるリソースへのアクセスを制御するためのセキュリティインフラストラクチャーを提供する、実行可能命令を含むコンピューター可読媒体。
【請求項2】
前記関連付けられるサブジェクトは、プロセス又はプロセスのスレッドを含む、請求項1に記載のコンピューター可読媒体。
【請求項3】
前記関連付けられるサブジェクトのアクセス特権(214、216)を求める前記ステップは、前記リソースへのアクセスを付与する前に、前記現在の関連付けられるサブジェクトのコールチェーンコンテキストをキャプチャするステップと、前記現在の関連付けられるサブジェクトを分析して、前記コールチェーンにおける蓄積された各前記識別情報(210、212)及び各前記関連付けられるサブジェクトが、前記要求されたリソースにアクセスすることができることを検証するステップとをさらに含み、それによって、デフォルトにより最小特権を可能にする、請求項1に記載のコンピューター可読媒体。
【請求項4】
前記セキュリティトークン(200)と前記セキュリティ記述子(300)との間の関係が、要求されたリソースへの前記関連付けられるサブジェクトによるアクセス権の制御を決定する、請求項1に記載のコンピューター可読媒体。
【請求項5】
アクセス特権(214、216)を求める前記ステップは、セキュリティトークン(200)における各前記セキュリティ識別子(100)を使用して、セキュリティトークンが、セキュリティ記述子(300)によって指定されたリソースへのアクセスを要求したか否かを判断し、前記コンタクトチェーン内のあらゆるコーラーが、要求されたリソースへのアクセスを付与する特権を有するときにのみ、前記要求されたリソースへのアクセスが付与される、請求項1に記載のコンピューター可読媒体。
【請求項6】
前記リソースへのアクセス権を定義するセキュリティ記述子(300)を構築するステップと、
前記セキュリティトークン(200)に従って前記関連付けられるサブジェクトを識別するステップと、
前記セキュリティ記述子(300)において定義された前記識別情報(320、330)が前記セキュリティ記述子におけるアクセス制御エントリ(500)に含まれるか否かを判断するステップと、
前記アクセス制御エントリに基づいて前記識別情報に利用可能なアクセス権を求めるステップと、
前記求めたアクセス権に従って前記識別情報(320、330)にアクセス権を付与するステップと
をさらに含む、請求項1に記載のコンピューター可読媒体。
【請求項7】
関連付けられるサブジェクトに関係するすべてのトークンのリスト(200)をセキュリティトークンリスト(700)内に保持するステップをさらに含み、現在のアクティブトークン(710)は、常に前記セキュリティトークンリストの先頭にあり、現在の関連付けられるサブジェクトに対するすべてのアクセスチェック及び特権チェックは、関連付けられるサブジェクトがアクセスを要求するリソースを前記セキュリティトークンリスト(700)の先頭の前記現在のアクティブセキュリティトークンと比較することにより、前記現在のアクティブセキュリティトークン(710)及び前記関連付けられるサブジェクトの現在のコンテキストを使用してハンドリングされる、請求項1に記載のコンピューター可読媒体。
【請求項8】
クライアント側(1020)において、関連付けられるサブジェクトのセキュリティコンテキストをメッセージキューに書き込むステップと、前記サーバー側(1030)において、前記メッセージキューから前記関連付けられるサブジェクトの前記セキュリティコンテキストを非同期にリトリーブするステップと、及び偽装される前記関連付けられるサブジェクトの前記リトリーブしたセキュリティコンテキストをコピーすることによって前記関連付けられるサブジェクトを偽装するステップとをさらに含む、請求項1に記載のコンピューター可読媒体。
【請求項9】
関連付けられるサブジェクトの現在のセキュリティトークン(710)に関連付けられるすべての識別情報(210、212)が要求リソースにアクセスすることができるときに、前記要求されたリソースへのアクセスを付与するステップをさらに含み、現在の関連付けられるサブジェクトのコールスタック(800)におけるすべてのチャンバーに関連付けられるすべての識別情報は、前記要求リソースにアクセスすることができ、前記関連付けられるサブジェクトのための保存されたコンテキストに関連付けられるすべての識別情報は、前記要求されたリソースにアクセスすることができる、請求項1に記載のコンピューター可読媒体。
【請求項10】
オフライン処理用に、オフラインデータベース内にセキュリティコンタクトを記憶するステップをさらに含む、請求項1に記載のコンピューター可読媒体。
【請求項11】
セキュリティインフラストラクチャーであって、
関連付けられるサブジェクトのための一意の識別子を定義し、該関連付けられるサブジェクトに関連付けられるアカウントを指定するためのセキュリティ識別子(100)と、
前記セキュリティ識別子(100)に割り当てられた基本特権(214)及び拡張特権(216)を求めることに基づいて、識別情報のセット及び該識別情報のセットに割り当てられた特権の集合を定義するためのセキュリティトークン(200)と、
要求されたリソースにアクセスすることができるアカウント及び前記プロセスに関するルールを定義するためのセキュリティ記述子と、
アクセス制御リスト(400)であって、該アクセス制御リストは、セキュリティ識別子(100)のアクセス権を識別するための少なくとも1つのアクセス制御エントリ(500)を含む、アクセス制御リスト(400)と
を備える、セキュリティインフラストラクチャー。
【請求項12】
前記セキュリティトークン(200)は、前記構造体のバージョン(202)、フラグ(204)、オフセット(206)、直接グループの個数(207)、及びグループ識別子の総数(208)を識別するためのフィールドを含む、請求項11に記載のセキュリティインフラストラクチャー。
【請求項13】
前記セキュリティトークン(200)は、プライマリオーナーセキュリティ識別子(210)、グループセキュリティ識別子(212)、基本特権(214)、及び拡張特権(216)をさらに含む、請求項12に記載のセキュリティインフラストラクチャー。
【請求項14】
前記プライマリセキュリティ識別子(210)及び前記グループセキュリティ識別子(212)は、前記セキュリティトークン(200)の関連付けられるサブジェクトの識別情報を定義する、請求項13に記載のセキュリティインフラストラクチャー。
【請求項15】
前記基本特権(214)は、前記セキュリティトークン(200)において指定された前記識別情報に有効な特権のセットを含む、請求項13に記載のセキュリティインフラストラクチャー。
【請求項16】
前記拡張特権(216)は、前記セキュリティトークン(200)においてセキュリティ識別子(100)について定義されたカスタム特権を含む、請求項13に記載のセキュリティインフラストラクチャー。
【請求項17】
関連付けられるサブジェクトに最小特権を付与するための方法であって、
関連付けられるサブジェクトのための一意の識別子を定義し、該関連付けられるサブジェクトに関連付けられるアカウントを指定するためのセキュリティ識別子(100)を設けるステップと、
前記一意の識別子をアカウントデータベース内のエントリにマッピングするステップであって、前記セキュリティ識別子(100)に割り当てられた基本特権(214)及び拡張特権(216)を求める、マッピングするステップと、
前記関連付けられるサブジェクトのマイグレーションに沿って関連付けられるサブジェクトの識別子(210、212)を蓄積するステップと、
前記セキュリティ識別子(100)に割り当てられた前記基本特権(214)及び前記拡張特権(216)を求めることに基づいて、識別情報(210、212)のセット及び該識別情報のセットに割り当てられた特権の集合を定義するためのセキュリティトークン(200)を作成するステップと、
前記関連付けられるサブジェクトの前記蓄積された識別子(210、212)のすべて及び前記特権(214、216)の集合をインターセクトすることによって前記関連付けられるサブジェクトのアクセス特権を求めるステップと、
を含む、コンピューター可読媒体。
【請求項18】
前記関連付けられるサブジェクトのアクセス特権(214、216)を求める前記ステップは、前記リソースへのアクセスを付与する前に、現在の関連付けられるサブジェクトのコールチェーンコンテキストをキャプチャするステップと、前記現在の関連付けられるサブジェクトを分析して、前記コールチェーンにおける蓄積された各識別情報(210、212)及び各関連付けられるサブジェクトが、前記要求されたリソースにアクセスすることができることを検証するステップとをさらに含み、それによって、デフォルトにより最小特権を可能にする、請求項17に記載の方法。
【請求項19】
クライアント側(1020)において、関連付けられるサブジェクトのセキュリティコンテキストをメッセージキューに書き込むステップと、
前記サーバー側(1030)において、前記メッセージキューから前記関連付けられるサブジェクトの前記セキュリティコンテキストを非同期にリトリーブするステップと、
偽装される前記関連付けられるサブジェクトの前記リトリーブしたセキュリティコンテキストをコピーすることによって前記関連付けられるサブジェクトを偽装するステップと、
前記コピーしたセキュリティコンテキスト(750)を分析するステップであって、前記要求リソースへのアクセス権を定義するセキュリティ記述子(300)を構築する、分析するステップと、
前記セキュリティトークン(200)に従って前記関連付けられるサブジェクトを識別するステップと、
前記セキュリティ記述子(300)に定義された前記識別情報(320、330)が該セキュリティ記述子のアクセス制御エントリ(500)に含まれるか否かを判断するステップと、
前記アクセス制御エントリ(500)に基づいて前記識別情報(320、330)に利用可能なアクセス権を求めるステップと
をさらに含む、請求項1に記載の方法。
【請求項20】
関連付けられるサブジェクトの現在のセキュリティトークン(710)に関連付けられるすべての識別情報(210、212)が要求リソースにアクセスすることができるときに、前記要求されたリソースへのアクセスを付与するステップをさらに含み、現在の関連付けられるサブジェクトのコールスタック(800)のすべてのチャンバーに関連付けられるすべての識別情報は、前記要求リソースにアクセスすることができ、前記関連付けられるサブジェクトの保存されたコンテキストに関連付けられるすべての識別情報は、前記要求されたリソースにアクセスすることができる、請求項1に記載の方法。
【請求項1】
実行可能命令を含むコンピューター可読媒体であって、該実行可能命令は、実行されると、
関連付けられるサブジェクトのための一意の識別子を定義し、該関連付けられるサブジェクトに関連付けられるアカウントを指定するためのセキュリティ識別子(100)を設けるステップと、
前記一意の識別子をアカウントデータベース内のエントリにマッピングするステップであって、前記セキュリティ識別子(100)に割り当てられた基本特権(214)及び拡張特権(216)を求める、マッピングするステップと、
前記関連付けられるサブジェクトのマイグレーションに沿って関連付けられるサブジェクトの識別子(210、212)を蓄積するステップと、
前記セキュリティ識別子(100)に割り当てられた前記基本特権(214)及び前記拡張特権(216)を求めることに基づいて、識別情報(210、212)のセット及び該識別情報のセットに割り当てられた特権の集合を定義するためのセキュリティトークン(200)を作成するステップと、
前記関連付けられるサブジェクトの前記蓄積された識別子(210、212)のすべて及び前記特権(214、216)の集合をインターセクトすることによって前記関連付けられるサブジェクトのアクセス特権を求めるステップと
によって、関連付けられるサブジェクトによるリソースへのアクセスを制御するためのセキュリティインフラストラクチャーを提供する、実行可能命令を含むコンピューター可読媒体。
【請求項2】
前記関連付けられるサブジェクトは、プロセス又はプロセスのスレッドを含む、請求項1に記載のコンピューター可読媒体。
【請求項3】
前記関連付けられるサブジェクトのアクセス特権(214、216)を求める前記ステップは、前記リソースへのアクセスを付与する前に、前記現在の関連付けられるサブジェクトのコールチェーンコンテキストをキャプチャするステップと、前記現在の関連付けられるサブジェクトを分析して、前記コールチェーンにおける蓄積された各前記識別情報(210、212)及び各前記関連付けられるサブジェクトが、前記要求されたリソースにアクセスすることができることを検証するステップとをさらに含み、それによって、デフォルトにより最小特権を可能にする、請求項1に記載のコンピューター可読媒体。
【請求項4】
前記セキュリティトークン(200)と前記セキュリティ記述子(300)との間の関係が、要求されたリソースへの前記関連付けられるサブジェクトによるアクセス権の制御を決定する、請求項1に記載のコンピューター可読媒体。
【請求項5】
アクセス特権(214、216)を求める前記ステップは、セキュリティトークン(200)における各前記セキュリティ識別子(100)を使用して、セキュリティトークンが、セキュリティ記述子(300)によって指定されたリソースへのアクセスを要求したか否かを判断し、前記コンタクトチェーン内のあらゆるコーラーが、要求されたリソースへのアクセスを付与する特権を有するときにのみ、前記要求されたリソースへのアクセスが付与される、請求項1に記載のコンピューター可読媒体。
【請求項6】
前記リソースへのアクセス権を定義するセキュリティ記述子(300)を構築するステップと、
前記セキュリティトークン(200)に従って前記関連付けられるサブジェクトを識別するステップと、
前記セキュリティ記述子(300)において定義された前記識別情報(320、330)が前記セキュリティ記述子におけるアクセス制御エントリ(500)に含まれるか否かを判断するステップと、
前記アクセス制御エントリに基づいて前記識別情報に利用可能なアクセス権を求めるステップと、
前記求めたアクセス権に従って前記識別情報(320、330)にアクセス権を付与するステップと
をさらに含む、請求項1に記載のコンピューター可読媒体。
【請求項7】
関連付けられるサブジェクトに関係するすべてのトークンのリスト(200)をセキュリティトークンリスト(700)内に保持するステップをさらに含み、現在のアクティブトークン(710)は、常に前記セキュリティトークンリストの先頭にあり、現在の関連付けられるサブジェクトに対するすべてのアクセスチェック及び特権チェックは、関連付けられるサブジェクトがアクセスを要求するリソースを前記セキュリティトークンリスト(700)の先頭の前記現在のアクティブセキュリティトークンと比較することにより、前記現在のアクティブセキュリティトークン(710)及び前記関連付けられるサブジェクトの現在のコンテキストを使用してハンドリングされる、請求項1に記載のコンピューター可読媒体。
【請求項8】
クライアント側(1020)において、関連付けられるサブジェクトのセキュリティコンテキストをメッセージキューに書き込むステップと、前記サーバー側(1030)において、前記メッセージキューから前記関連付けられるサブジェクトの前記セキュリティコンテキストを非同期にリトリーブするステップと、及び偽装される前記関連付けられるサブジェクトの前記リトリーブしたセキュリティコンテキストをコピーすることによって前記関連付けられるサブジェクトを偽装するステップとをさらに含む、請求項1に記載のコンピューター可読媒体。
【請求項9】
関連付けられるサブジェクトの現在のセキュリティトークン(710)に関連付けられるすべての識別情報(210、212)が要求リソースにアクセスすることができるときに、前記要求されたリソースへのアクセスを付与するステップをさらに含み、現在の関連付けられるサブジェクトのコールスタック(800)におけるすべてのチャンバーに関連付けられるすべての識別情報は、前記要求リソースにアクセスすることができ、前記関連付けられるサブジェクトのための保存されたコンテキストに関連付けられるすべての識別情報は、前記要求されたリソースにアクセスすることができる、請求項1に記載のコンピューター可読媒体。
【請求項10】
オフライン処理用に、オフラインデータベース内にセキュリティコンタクトを記憶するステップをさらに含む、請求項1に記載のコンピューター可読媒体。
【請求項11】
セキュリティインフラストラクチャーであって、
関連付けられるサブジェクトのための一意の識別子を定義し、該関連付けられるサブジェクトに関連付けられるアカウントを指定するためのセキュリティ識別子(100)と、
前記セキュリティ識別子(100)に割り当てられた基本特権(214)及び拡張特権(216)を求めることに基づいて、識別情報のセット及び該識別情報のセットに割り当てられた特権の集合を定義するためのセキュリティトークン(200)と、
要求されたリソースにアクセスすることができるアカウント及び前記プロセスに関するルールを定義するためのセキュリティ記述子と、
アクセス制御リスト(400)であって、該アクセス制御リストは、セキュリティ識別子(100)のアクセス権を識別するための少なくとも1つのアクセス制御エントリ(500)を含む、アクセス制御リスト(400)と
を備える、セキュリティインフラストラクチャー。
【請求項12】
前記セキュリティトークン(200)は、前記構造体のバージョン(202)、フラグ(204)、オフセット(206)、直接グループの個数(207)、及びグループ識別子の総数(208)を識別するためのフィールドを含む、請求項11に記載のセキュリティインフラストラクチャー。
【請求項13】
前記セキュリティトークン(200)は、プライマリオーナーセキュリティ識別子(210)、グループセキュリティ識別子(212)、基本特権(214)、及び拡張特権(216)をさらに含む、請求項12に記載のセキュリティインフラストラクチャー。
【請求項14】
前記プライマリセキュリティ識別子(210)及び前記グループセキュリティ識別子(212)は、前記セキュリティトークン(200)の関連付けられるサブジェクトの識別情報を定義する、請求項13に記載のセキュリティインフラストラクチャー。
【請求項15】
前記基本特権(214)は、前記セキュリティトークン(200)において指定された前記識別情報に有効な特権のセットを含む、請求項13に記載のセキュリティインフラストラクチャー。
【請求項16】
前記拡張特権(216)は、前記セキュリティトークン(200)においてセキュリティ識別子(100)について定義されたカスタム特権を含む、請求項13に記載のセキュリティインフラストラクチャー。
【請求項17】
関連付けられるサブジェクトに最小特権を付与するための方法であって、
関連付けられるサブジェクトのための一意の識別子を定義し、該関連付けられるサブジェクトに関連付けられるアカウントを指定するためのセキュリティ識別子(100)を設けるステップと、
前記一意の識別子をアカウントデータベース内のエントリにマッピングするステップであって、前記セキュリティ識別子(100)に割り当てられた基本特権(214)及び拡張特権(216)を求める、マッピングするステップと、
前記関連付けられるサブジェクトのマイグレーションに沿って関連付けられるサブジェクトの識別子(210、212)を蓄積するステップと、
前記セキュリティ識別子(100)に割り当てられた前記基本特権(214)及び前記拡張特権(216)を求めることに基づいて、識別情報(210、212)のセット及び該識別情報のセットに割り当てられた特権の集合を定義するためのセキュリティトークン(200)を作成するステップと、
前記関連付けられるサブジェクトの前記蓄積された識別子(210、212)のすべて及び前記特権(214、216)の集合をインターセクトすることによって前記関連付けられるサブジェクトのアクセス特権を求めるステップと、
を含む、コンピューター可読媒体。
【請求項18】
前記関連付けられるサブジェクトのアクセス特権(214、216)を求める前記ステップは、前記リソースへのアクセスを付与する前に、現在の関連付けられるサブジェクトのコールチェーンコンテキストをキャプチャするステップと、前記現在の関連付けられるサブジェクトを分析して、前記コールチェーンにおける蓄積された各識別情報(210、212)及び各関連付けられるサブジェクトが、前記要求されたリソースにアクセスすることができることを検証するステップとをさらに含み、それによって、デフォルトにより最小特権を可能にする、請求項17に記載の方法。
【請求項19】
クライアント側(1020)において、関連付けられるサブジェクトのセキュリティコンテキストをメッセージキューに書き込むステップと、
前記サーバー側(1030)において、前記メッセージキューから前記関連付けられるサブジェクトの前記セキュリティコンテキストを非同期にリトリーブするステップと、
偽装される前記関連付けられるサブジェクトの前記リトリーブしたセキュリティコンテキストをコピーすることによって前記関連付けられるサブジェクトを偽装するステップと、
前記コピーしたセキュリティコンテキスト(750)を分析するステップであって、前記要求リソースへのアクセス権を定義するセキュリティ記述子(300)を構築する、分析するステップと、
前記セキュリティトークン(200)に従って前記関連付けられるサブジェクトを識別するステップと、
前記セキュリティ記述子(300)に定義された前記識別情報(320、330)が該セキュリティ記述子のアクセス制御エントリ(500)に含まれるか否かを判断するステップと、
前記アクセス制御エントリ(500)に基づいて前記識別情報(320、330)に利用可能なアクセス権を求めるステップと
をさらに含む、請求項1に記載の方法。
【請求項20】
関連付けられるサブジェクトの現在のセキュリティトークン(710)に関連付けられるすべての識別情報(210、212)が要求リソースにアクセスすることができるときに、前記要求されたリソースへのアクセスを付与するステップをさらに含み、現在の関連付けられるサブジェクトのコールスタック(800)のすべてのチャンバーに関連付けられるすべての識別情報は、前記要求リソースにアクセスすることができ、前記関連付けられるサブジェクトの保存されたコンテキストに関連付けられるすべての識別情報は、前記要求されたリソースにアクセスすることができる、請求項1に記載の方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【公表番号】特表2011−526387(P2011−526387A)
【公表日】平成23年10月6日(2011.10.6)
【国際特許分類】
【出願番号】特願2011−516585(P2011−516585)
【出願日】平成21年6月24日(2009.6.24)
【国際出願番号】PCT/US2009/048461
【国際公開番号】WO2009/158405
【国際公開日】平成21年12月30日(2009.12.30)
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
【公表日】平成23年10月6日(2011.10.6)
【国際特許分類】
【出願日】平成21年6月24日(2009.6.24)
【国際出願番号】PCT/US2009/048461
【国際公開番号】WO2009/158405
【国際公開日】平成21年12月30日(2009.12.30)
【出願人】(500046438)マイクロソフト コーポレーション (3,165)
【Fターム(参考)】
[ Back to top ]