JP2009539183A - 役割ベースのアクセス制御ポリシーの資源許可ポリシーへの変換 - Google Patents

Abstract

ＡＣＬベースのアプリケーションなどの資源許可ポリシー（ＲＡＰ）に対するＲＢＡＣ「役割」を管理する役割ベースのオーサリングモデルの変換が提供される。汎用ＲＢＡＣシステムが定義され、その汎用ＲＢＡＣシステムから他の許可実施機構へのマッピングにより、ＲＢＡＣ「役割」の、資源マネージャ、例えばファイルシステム資源マネージャによって管理される資源に適用された資源許可ポリシーへの変換が可能となる。記憶機構およびオブジェクトモデルとしてＷｉｎｄｏｗｓ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｍａｎａｇｅｒを使用して、ＲＢＡＣシステムから変換されたオブジェクトタイプおよび関係を管理する実装が説明される。
【選択図】図１

Description

本発明は、役割ベースのアクセス制御（ＲＢＡＣ）ポリシーを資源許可ポリシーに変換することに関する。

大規模ネットワークを管理する際の最も難しい問題の１つは、セキュリティ管理が非常に複雑である結果として生じるものであり、管理がコンピュータおよびネットワークシステムでの重要な問題となる。この点で、許可機構が、オペレーティングシステム、アプリケーション、または資源アクセス制御が関係する任意の場所に存在する。許可は伝統的に、認証とアクセス制御の２つの別々のプロセスから構成される。認証は、「ユーザは誰であるか？」という問題に対処し、アクセス制御は、「ある資源に対して／を用いてユーザは何を行うことができるか？」という問題に対処する。

資源レベルでは、歴史的に、ネットワークは、資源許可ポリシー（ＲＡＰ）を使用して、ユーザが指定の資源に接続することが許可されているかどうかを判定してきた。例示的ＲＡＰでは、従来の分散型コンピューティングネットワークは、ドメインベースのアクセス制御リスト（ＡＣＬ）をアクセス制御のための支配的な機構として使用してきた。ＡＣＬは、資源に対するユーザのアクセス権を、データ構造内の読取り許可、書込み許可、および実行許可の点で指定するが、必然的に、今日の共有コンピューティング空間内の資源およびユーザの数が引き続き急増するにつれて管理可能性および複雑さの問題をもたらす。

厳格にオブジェクトごとにユーザアクセスを許可または取消しする、アクセス制御の従来型ＲＡＰ方法とは対照的に、ＲＡＰに対する代替は、役割ベースのセキュリティとも呼ばれる役割ベースのアクセス制御（ＲＢＡＣ）ポリシーである。ＲＢＡＣは、大規模ネットワーク応用例でのセキュリティ管理の複雑さおよびコストを低減するので、ＲＢＡＣは、アクセス制御のための顕著なモデルとなっている。ＲＢＡＣは、企業内の個々のユーザの役割に基づいて、コンピュータまたはネットワーク資源へのアクセスを規制する方法である。この文脈では、アクセスとは、ファイルの閲覧、作成、修正などの特定の作業を実行する個々のユーザの能力である。役割は、企業内の既存の役割／ラベル、例えば仕事の能力、権限、または責任に従って定義される。

適切に実装されたとき、ＲＢＡＣは、柔軟な機能、関係、および制約に従ってユーザの行動を動的に規制することにより、ユーザが許可された広範な作業を実施することを可能にする。ＲＢＡＣでは、企業の必要が発展するにつれて、あらゆるユーザについての特権を個々に更新する必要なしに、役割を容易に作成、変更、停止することができる。

したがって、ＲＢＡＣは、大部分のコンピュータシステム上の分散型アクセス制御リスト（ＡＣＬ）モデルにおいて困難である活動を可能にする。そのような活動は、各アプリケーションにわたる許可照会を含む。しかし現在のところ、ＲＢＡＣ「役割」を管理する役割ベースのオーサリングモデルを、ＡＣＬベースのアプリケーションなどの資源許可ポリシー（ＲＡＰ）、または他の許可実施機構に変換する方法はない。本発明の様々な実施形態に関して以下でより詳細に説明するように、現況技術の上記およびその他の不備に対して改良することが望ましい。

上記に鑑みて、本発明は、ＲＢＡＣ「役割」を管理する役割ベースのオーサリングモデルを、ＡＣＬベースのアプリケーションなどの資源許可ポリシー（ＲＡＰ）、または他の許可実施機構に変換するシステムおよび方法を提供する。したがって、本発明は汎用ＲＢＡＣシステムを定義し、その汎用ＲＢＡＣシステムから他の許可実施機構へのマッピングにより、ＲＢＡＣ「役割」の、資源マネージャ（例えばファイルシステム資源マネージャ）によって管理される資源に適用された資源許可ポリシーへの変換が可能となる。例示的非限定的実施形態では、記憶機構およびオブジェクトモデルとしてＷｉｎｄｏｗｓ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｍａｎａｇｅｒを使用して、ＲＢＡＣシステムから変換されたオブジェクトタイプおよび関係を管理する実装が論じられる。

本発明の他の特徴が以下で説明される。

ネットワークコンピューティング環境でＲＢＡＣポリシーをＲＡＰに変換する方法が、添付の図面を参照しながらさらに説明される。

ＲＢＡＣは、組織全体にわたる集中型許可のための新興の解決策である。ＲＢＡＣは、大部分のコンピュータシステム上の分散型ＡＣＬモデルにおいて困難である活動を可能にする。そのような活動は、各アプリケーションにわたる許可照会を含む。ＲＢＡＣポリシーシステムの利点と比較して複雑なＡＣＬ実装に対処する困難を考慮して、本発明は、ＲＢＡＣ「役割」を管理する役割ベースのオーサリングモデルを提供し、次いでそれをＡＣＬベースのアプリケーションおよび他の許可実施機構に変換することができる。このことを達成するために、本発明は、例えば既存のＲＢＡＣ概念モデルに基づいて、新しい汎用ＲＢＡＣシステムを定義する。

したがって、本発明の一態様では、本発明は、ＡＣＬなどの資源許可ポリシー構造と互換であるＲＢＡＣモデルを提供し、その結果、役割ベースのデータ構造とＡＣＬの間で変換を実施することができる。これは、ＲＢＡＣポリシーをＡＣＬベースの許可にマッピングする能力を含む。

本発明の様々な他の非限定的態様では、メンバシップグループを使用してＲＢＡＣポリシーを実装する方法が提供される。さらに、本発明の役割ベースのオーサリングツールの様々な非限定的実施形態は、コンピュータ資源の分散型役割ベースの許可のためのシステムレベル定義を作成する能力を含む。

本発明の１つの例示的非限定的Ｗｉｎｄｏｗｓ実装では、本発明のＲＢＡＣポリシー−ＡＣＬ変換能力は、Ｗｉｎｄｏｗｓ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｍａｎａｇｅｒ（ＷＡＭ）を用いた「Ｒｏｌｅｓ−ｔｏ−ＡＣＬ」変換を提供する。そのような実装では、ＷＡＭは、ＲＢＡＣシステムが使用するオブジェクトタイプおよび関係を管理するための記憶機構およびオブジェクトモデルとして使用され、資源許可ポリシーに従ってオブジェクトタイプおよび関係をＡＣＬデータ構造に変換することができる。さらに、本発明は多種多様なコンピュータシステムに適用することができ、１つの例示的非限定的実施形態では、Ｗｉｎｄｏｗｓ ＮＴＦＳファイルシステムが例示的資源マネージャとして使用される。

以下で、ＲＢＡＣポリシーを資源許可ポリシー（ＲＡＰ）に変換するシステムおよび方法が、様々な非限定的実施形態で説明される。しかし、本明細書に記載の様々な実施形態を検討した時に、本発明によるＲＢＡＣポリシーモデルからＲＡＰモデルへの変換を、既存の、または将来設計される様々なＲＢＡＣポリシーモデルにわたって実施でき、あるいは本発明に従って定義されるＲＢＡＣポリシーモデルと共に実施できることを当業者は理解することができる。同様に、ＲＢＡＣポリシーを様々なＲＡＰモデル、すなわち既存の、または将来設計される資源ごと、アプリケーションごと、またはサービスデータ構造および分析ごとに特権または許可を授与する任意のモデルに変換でき、したがって本発明は、本明細書に記載のＡＣＬベースのモデルおよび実施形態によるＲＡＰに限定されないことを理解することができる。

用語
最後に、用語に関して、用語がどのように使用されるかの文脈を考慮することに加えて、不確かさを避けるために、以下のＲＢＡＣ用語は以下を意味すると理解すべきである。

Ｓｃｏｐｅ：１組の資源、
アクセス制御リスト（ＡＣＬ）：コンピュータ資源に関するアクセス制御ポリシー、
役割定義（またはアプリケーション役割）：所与の範囲でプリンシパルに割り当てることのできる１組の許可、
役割割当て：所与の範囲での１つまたは複数のプリンシパルへの役割定義の割当て、
組織役割（または役割グループ）：所与の１組の資源（範囲）に対して同一の許可を有する１組の人々、
組織グループ：所与のコンピュータ資源の許可実施モデルに固有のセキュリティグループタイプ、および
資源グループ：特定の資源に対するグループ特有のアクセスでメンバに与えるのに使用される所与のコンピュータ資源の許可実施モデルに固有のセキュリティグループタイプ。

ＲＢＡＣポリシーを定義し、ＲＢＡＣポリシーを資源許可ポリシーに変換する
背景技術で触れたように、一般には、ＲＢＡＣモデリングは、分散型アクセス制御リスト（ＡＣＬ）モデルに勝る、時間、計算、および複雑さの節約を実現し、既存の組織の概念にマッピングされるので概念的にオーサリングするのが容易である。しかし、ＲＢＡＣ「役割」を管理する役割ベースのオーサリングモデルをＡＣＬベースのアプリケーションなどの資源許可ポリシー（ＲＡＰ）に変換する方法はない。

現況技術の上記およびその他の問題を考慮して、高レベルで、本発明のＲＢＡＣシステムは、組織的役割に基づいて権限許可コンピュータ資源の集中型管理を実現し、ユーザ役割メンバシップおよび能力に関する照会を可能にし、役割ベースの構造からＡＣＬなどの資源許可構造への変換を可能にするので有利である。

したがって、図１に示されるように、本発明は、ＲＢＡＣ集中型記憶モデルＲＢＡＣ＿ＤＢを含むＲＢＡＣシステムを提供する。集中型記憶モデルＲＢＡＣ＿ＤＢの主な属性は、本発明のすべてのポリシー定義をそこに格納できることである。ポリシーは必ずしも、中央主宰管理者によって定義される必要はない（管理モデルの委任が存在することができる）。さらに、ポリシーは必ずしも、中央ストアでオーサリングされる必要はない。分散型実装は、オーサリングを他のポリシーストアに配布することができるが、ポリシーは、最終的には中央ストアと同期される。図１のＲＢＡＣシステムでは、アプリケーション資源許可ポリシーのアプリケーション許可が定義され、それがアプリケーション役割にマッピングされ、またはその逆である。図示されるように、資源のセット、例えばＦｉｌｅ Ｓｅｒｖｅｒ ＦＳＲＶのＦｉｌｅ Ｓｈａｒｅ ＦＳが範囲Ｓと定義され、Ｏｒｇａｎｉｚａｔｉｏｎａｌ（または「Ｅｎｔｅｒｐｒｉｓｅ」）役割ＥＲが、企業役割ＥＲに与えられた資源グループＲＧ、役割定義ＲＤ中のユニバーサルユーザグループＵＧ、ならびに範囲Ｓおよび許可（役割割当てＲＡ）によって定義される。役割定義ＲＤ、Ｓｃｏｐｅ Ｓ、およびＲｏｌｅ Ａｓｓｉｇｎｍｅｎｔ ＲＡに基づく企業役割ＥＲの定義より、ＲＢＡＣシステムは、必要に応じて、限定はしないがＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙグループなどの識別管理システムＩＭＳのグループＵＧおよびＲＧを作成することができ、ＡＣＬなどの資源ポリシーを構成することができる。

図２は、ファイル共有アプリケーションまたはファイルサーバＦＳＲＶの資源ＦＳＩが範囲Ｓ１と定義される例に適用される、ＲＢＡＣ集中型記憶モデルＲＢＡＣ＿ＤＢの一例を示す。この例では、資源のセットＦＳＩに＼＼Ｓｅｒｖｅｒ＼Ｓｈａｒｅと名前が付けられ、セキュリティ識別子（ＳＩＤ）を有し、＼＼Ｓｅｒｖｅｒ＼Ｓｈａｒｅに対して、ＡｃｃｅｓｓＭａｓｋ：０ｘ１Ｆ０１ＦＦが、名前Ｓａｌｅｓ Ｄｏｃｓを有する範囲Ｓ１と定義される。次いで、対応するＥｎｔｅｒｐｒｉｓｅ Ｒｏｌｅ ＥＲ１が、企業役割ＥＲ１に与えられる資源グループ、役割定義ＲＤ１中のユニバーサルユーザグループ、ならびに範囲Ｓ１および役割割当てＲＡに関して定義される。有利には、役割定義ＲＤ１、Ｓｃｏｐｅ Ｓ１、およびＲｏｌｅ Ａｓｓｉｇｎｍｅｎｔ ＲＡ１に基づく企業役割ＥＲ１の定義より、ＲＢＡＣシステムは、必要に応じて、限定はしないがＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ ＡＤのＡｃｔｉｖｅ ＤｉｒｅｃｔｏｒｙグループＵＧ１およびＲＧ１などの識別管理システムＩＭＳのグループＵＧ１およびＲＧ１を作成することができる。したがって、本発明は、必要に応じて、本発明のＲＢＡＣシステムの組織的役割のレンズを通じて、ＡＣＬなどの資源ポリシーを構成するのに使用することができる。

図３は、本発明のファイルシステム実施形態に従って資源許可ポリシーデータ構造に変換される（すなわち、ファイルシステムが、要求された資源を含む場合）、本発明のＲＢＡＣポリシー構造の例示的非限定的流れ図を示す。３００で、ファイルシステムに関するファイルの各許可レベルについて役割が定義される（カスタムレベルが可能である）。３１０で、資源識別子（例えばファイル共有、ディレクトリ、またはファイル）によって範囲が定義される。３２０で、最新のデータに従って役割または範囲を更新することができる。このことは、メンバシップグループが３２０ａで変化したときにメンバシップグループを更新することを含むことができ、組織的許可レベルが３２０ｂで発展したときの役割定義許可変更を含むことができる。次いで３３０で、こうした構造を、資源に対して設定される基礎となるＡＣＬ（すなわちファイルシステムＡＣＬ）にマッピングすることができる。ファイルシステム資源の状況で図３が説明されるが、ネットワークコンピューティング環境内の任意の種類の資源、アプリケーション、またはサービスを求める要求の許可に概念を拡張することができる。

アプリケーション統合
図４に示されるように、本発明のＲＢＡＣモデルおよびストア４００によれば、特定のアプリケーションについて、まず許可プリミティブが、役割、すなわちＥｎｔｅｒｐｒｉｓｅ Ｒｏｌｅ ＥＲ、ファイル共有ＦＳなどのＡｐｐｌｉｃａｔｉｏｎ Ｒｅｓｏｕｒｃｅに関してＲＢＡＣシステム内で定義され、次いで、範囲Ｓを介してＲＢＡＣシステムに追加される。次いで、Ｅｎｔｅｒｐｒｉｓｅ Ｒｏｌｅ ＥＲは、Ｅｎｔｅｒｐｒｉｓｅ Ｒｏｌｅ ＥＲに関連する役割割当ておよび役割定義に従って範囲Ｓ内のアクセスを許可される。

アプリケーション役割定義
許可管理および照会を集中型で行うことを可能にするために、各アプリケーションタイプについての許可もＲＢＡＣシステムに入力される。このことは、アプリケーション内の役割に対応する許可セットとして定義されたアプリケーション役割に関して行われる。Ｗｉｎｄｏｗｓファイルシステムを使用する非限定的例では、本発明は、（例えば、先進ＡＣＬエディタＵＩ上で利用可能な）オペレーションＦｕｌｌ Ｃｏｎｔｒｏｌ、Ｍｏｄｉｆｙ、Ｒｅａｄ＆Ｅｘｅｃｕｔｅ、Ｒｅａｄ ａｎｄ Ｗｒｉｔｅに関して、現行ファイルシステムＥｘｐｌｏｒｅｒ ＵＩ許可レベルのそれぞれについて役割を定義する。Ｗｉｎｄｏｗｓファイルシステム許可レベル以外の許可のカスタムセットをアプリケーション役割定義と定義することもできることを理解することができる。

資源範囲定義
役割に割り当てるべき資源の各セットについて、本発明による範囲が、資源識別子に関して定義される。ファイルシステム実施例では、資源はファイル共有、ディレクトリ、またはファイルである。資源識別子は、資源までのフルパス名でよい。範囲を、複数のサーバにまたがる資源を含めてより広く定義することもできる。Ｗｉｎｄｏｗｓファイルシステム実施例では、例えば、そのような範囲をファイル共有のユーザプリンシパル名（ＵＰＮ）のコンマ区切りリストに関して定義することができる。

範囲の名前は、範囲資源を含む物理的コンテナまでの経路に基づくことができる。図２のファイルシステム実施例では、上述のように、そのような範囲名は、「＼＼Ｓｅｒｖｅｒ＼Ｓｈａｒｅ」でよく、必要ならこれを、＼＼ｆｏｌｄｅｒ＼ｆｉｌｅなど、ファイルまでより細かく宣言することができる。範囲名は、「Ｓａｌｅｓ Ｄｏｃｓ」など、資源を効率的に記述する任意の名前でよく、このことは、販売組織内の各サーバ上に複数の文書がまたがる範囲についてより有用である可能性があり、すなわち、そのような名前を組織構造および運用特性により良好に対応付けることができる。

図２の例は、単一ファイル共有ＦＳ１を含む範囲を使用する。その範囲名は「資源グループ」を付加するのに使用され、次いでそれが、各役割をポピュレートするのに使用される。複数のファイル共有またはディレクトリが使用されている場合、範囲を定義するファイル共有、ファイル、またはディレクトリのリストを範囲オブジェクトＳ１内に維持することができる。

資源の各セット（範囲）について、資源の管理者は、ＲＢＡＣシステムが、実際の資源許可を設定することによって許可を管理することを可能にし、トラステッド許可サービスアカウントがその許可を更新することを可能にする。本発明の例示的実施形態では、範囲がファイル共有またはディレクトリに対して、指定のファイル共有またはディレクトリ内またはその下のその資源のすべて（ファイルおよびディレクトリ）と共に適用される場合、そのようなファイル共有またはディレクトリは、デフォルトで指定のファイル共有またはディレクトリの許可を継承するように設定される。

Ｒｏｌｅ−ｔｏ−ＡＣＬ変換
以下のアクションは、上記で定義されたトラステッド許可サービスアカウント内のドメインコントローラまたはドメインサーバ上で動作するＲＢＡＣ−ＡＣＬ変換システムによって実施される：Ｓｃｏｐｅ Ｃｒｅａｔｉｏｎと、Ｏｒｇａｎｉｚａｔｉｏｎａｌ Ｒｏｌｅ Ｃｒｅａｔｉｏｎと、Ｍｅｍｂｅｒｓｈｉｐ ＣｈａｎｇｅおよびＲｏｌｅ−Ｄｅｆｉｎｉｔｉｏｎ Ｐｅｒｍｉｓｓｉｏｎ Ｃｈａｎｇｅを含むＰｏｌｉｃｙ Ｕｐｄａｔｅ。様々な非限定的実装特有の詳細が以下で説明される例示的実施形態に組み込まれるが、コンピューティングプラットフォームまたは任意任意の特定の資源許可ポリシーモデルとは無関係に本発明を適用できることを理解することができる。

範囲作成
新しい範囲が作成されたとき、本発明のＲＢＡＣシステムは、アプリケーション内の各役割定義についてユーザグループを作成する。したがって、Ｗｉｎｄｏｗｓファイルシステム実施例では、ＲＢＡＣシステムは、各アプリケーション役割定義Ｆｕｌｌ Ｃｏｎｔｒｏｌ、Ｍｏｄｉｆｙ、Ｒｅａｄ＆Ｅｘｅｃｕｔｅ、Ｒｅａｄ ａｎｄ Ｗｒｉｔｅについてグループを作成する。こうしたグループには、コンピュータ資源に関する許可が授与され、したがって、グループは、コンピュータ資源に固有の許可実施モデルによってサポートされるセキュリティグループである。例えば、Ｗｉｎｄｏｗｓシステムでは、こうしたグループは、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙドメインローカルグループでよい。こうしたグループは、「Ｓｃｏｐｅ１−ｆｕｌｌ−ｃｏｎｔｒｏｌ」などの範囲および許可を記述する名前を有する。こうしたグループは、組織的役割に関する許可を定義する（伝統的に、こうしたグループは資源グループと呼ばれる）。資源グループ関係に対する各役割定義について、本発明のＲＢＡＣシステムは、ＲＢＡＣシステムのデータストア内に役割割当てオブジェクトを作成する。これにより、資源グループのメンバを返す、範囲ベースのアプリケーション役割メンバシップ照会が可能となる。次いで、Ｏｒｇａｎｉｚａｔｉｏｎａｌ Ｒｏｌｅに、こうしたグループ内のメンバシップを介して範囲に対する許可が割り当てられる。

以下では、本発明のＷｉｎｄｏｗｓ実装に関する例示的非限定的最適化を説明する。そのような実装では、範囲内の資源は、（理想的には）すべての１つのドメイン内であり、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（ＡＤ）Ｄｏｍａｉｎ Ｌｏｃａｌ Ｇｒｏｕｐは、そのような目的にかなうものである。必須ではないがドメインローカルグループが好ましい。ユーザがそのドメイン内のサーバにログオンし、かつ別のドメインにログオンしていないときに、ドメインローカルグループがユーザのトークンに追加されるだけだからである。これにより、ＳＩＤが不要であるときにログオン時間をスローダウンさせることになるＳＩＤがログオントークンに追加されることが防止される。

さらに、そのような実装では、組織的役割に範囲内の対応する役割定義が割り当てられるまで、資源グループを作成しないことが好ましい。グループを作成した後、本発明のＲＢＡＣシステムは、適切な許可管理ＡＰＩ（例えば、Ｗｉｎｄｏｗｓでは、ＮＴＭａｒｔａまたはＭＡＣＬとなる）を呼び出して、範囲内の資源に関する適切な許可をグループに授与する。ファイルシステム実施例では、次いでアクセス制御エントリ（ＡＣＥ）が、各資源グループ（Ｆｕｌｌ Ｃｏｎｔｒｏｌ、Ｍｏｄｉｆｙなど）について、例えば範囲内の資源に追加される。次いで、各グループに与えられた許可、例えばアクセスマスクが、資源グループに対応する各役割定義のＡｃｃｅｓｓＭａｓｋプロパティから取り出される。

本発明のＷｉｎｄｏｗｓ実装の別の例示的非限定的最適化では、セキュリティ記述子のＳｅｃｕｒｉｔｙ Ｄｅｓｃｒｉｐｔｏｒ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ（ＳＤＤＬ）表現が、その対応する役割定義と共に格納される。

組織的役割作成
役割から資源範囲および許可への双方向照会をサポートするために、上述のように、各組織的役割がＲＢＡＣシステムで定義される。各組織的役割について、本発明のＲＢＡＣシステムは、組織の識別管理システム内の「組織グループ」（例えばＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ Ｕｎｉｖｅｒｓａｌ Ｇｒｏｕｐ）と、ＲＢＡＣシステムストア内の組織的役割オブジェクトを作成する。組織グループは組織的役割のメンバを含み、ＲＢＡＣシステム内の組織的役割オブジェクトにリンクされる。

組織グループは、コンピュータ資源に固有の許可実施モデルによってサポートされるセキュリティグループでなければならないが、グループのメンバシップは、任意のシステムのメンバシップオブジェクト内で別々に管理することができる。そのようなメンバシップの例は、限定はしないが、ドメインセキュリティグループおよびＥメール配布リストを含む。本発明のＲＢＡＣシステムは、必要なセキュリティグループとそのようなメンバシップリストを同期することができる。

本発明の任意選択の態様では、ビジネス論理をオペレーティングシステム（ＯＳ）アクセス制御リスト（ＡＣＬ）プリミティブで取り込むことを可能にすることにより、主概念を超えてＲＢＡＣシステムを拡張することができるが、本発明をＥメールグループ、例えばＤｉｓｔｒｉｂｕｔｉｏｎ Ｌｉｓｔ（ＤＬ）に拡張することもできる。

新しい役割が本発明のＲＢＡＣシステムで作成されるとき、役割を作成した管理者により、上記で定義される役割定義に関する許可が新しい役割に割り当てられる。ＲＢＡＣシステムでは、指定の役割定義および範囲に関する役割割当てオブジェクトを介して、組織的役割に範囲に対するアプリケーション役割が割り当てられる。

組織的役割への各役割割当てについて、本発明のＲＢＡＣシステムは、組織グループを指定の範囲および役割定義に合致する資源グループに割り当て、それによって役割におけるユーザに、役割定義で定義される許可を授与する。

ポリシー更新
本発明のＲＢＡＣシステムは、限定はしないが以下で説明されるメンバシップまたは役割の許可を変化することを含む、ポリシー更新を行う能力をサポートする。

メンバシップ変更
本発明のＲＢＡＣシステムは、組織的役割に対するメンバシップ変更をサポートし、それが、組織的役割に対応する組織グループ、すなわち組織の識別管理システムに格納される。任意選択で、ＲＢＡＣシステムの実装は、基礎となるグループを抽象化し、組織グループを役割として公開することを選ぶことができる。

役割定義許可変更
範囲内の役割について許可が変更されるとき、管理者は通常、組織的役割に割り当てられたアプリケーション役割を追加または除去することによってそれを行う。この場合、本発明のＲＢＡＣシステムは、役割から追加または除去されているアプリケーション役割定義に対応する資源グループに組織グループを追加し、またはその資源グループから組織グループを除去する。

アプリケーション役割定義が追加または削除されているとき、上述のように、対応する資源グループを作成または削除する必要がある（例えば、資源範囲定義を参照）。アプリケーション役割定義が変更されている場合、コンピュータ資源に関する許可が更新され、（上記の範囲作成のセクションで論じたように）更新後の資源グループのセットに、コンピュータ資源に関する適切な許可が与えられる。

本発明の例示的実装は、上述の詳細なステップに従う図５の流れ図に従って動作する。５００で、本発明のＲＢＡＣシステムに関するアプリケーション役割が定義される。５１０で、本発明のＲＢＡＣシステムに従って資源範囲が定義される。５２０で、各範囲および各役割についてグループが定義される。５３０で、作成されたグループに許可が与えられる。５４０で、例えばファイルシステムのディレクトリ、フォルダなどに対する、基礎となる資源許可ポリシーを実行するために、５００から５３０に従ってそのように定義されたＲＢＡＣポリシーをシステム内のＡＣＬにマッピングすることができる。

例示的非限定的ＡｚＭａｎ実装
以下では、Ｗｉｎｄｏｗｓ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｍａｎａｇｅｒ（ＡｚＭａｎ）をＲＢＡＣシステムストアとして使用する本発明の例示的非限定的実装を説明する。ＷｉｎｄｏｗｓサーバのＡｚＭａｎは、役割ベースのセキュリティの管理のためのインフラストラクチャを提供し、役割ベースのセキュリティの管理をよりスケーラブルにし、柔軟にし、かつ実装するのを容易にする。ＡｚＭａｎを使用して、役割ならびにそうした役割が実行することのできる作業を定義することができる。他の役割から特徴を継承するために役割をネスト化することができ、アプリケーショングループを定義することができる。さらに、ＡｚＭａｎは、スクリプトの使用が許可を動的に修正することを可能にし、セキュリティ論理を、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙに格納することのできるセキュリティポリシー内に包み込むことを可能にする。ＡｚＭａｎはまた、アクセスチェックを実行するために、使用するのが容易なＡＰＩを含む。

この点で、ＡｚＭａｎは、本発明に従って説明したのと類似のＲＢＡＣ概念モデルを提供し、記憶機構および管理インターフェースも提供する。したがって、ＡｚＭａｎフレームワークを活用して、役割ベースのポリシー構造をＡＣＬベースのポリシー構造に変換するＲｏｌｅ−ｔｏ−ＡＣＬ実装を提供することができる。そのように行う際に、ＲＢＡＣシステムで使用される概念が、以下の例示的非限定的マッピングと共に実装される。

Ｏｒｇａｎｉｚａｔｉｏｎａｌ Ｒｏｌｅ（または役割グループ）：ＡｚＭａｎアプリケーショングループオブジェクト
Ｓｃｏｐｅ：ＡｚＭａｎ Ｓｃｏｐｅオブジェクト
Ｒｏｌｅ−ｄｅｆｉｎｉｔｉｏｎ（またはアプリケーション役割）：ＡｚＭａｎ Ｒｏｌｅ−Ｄｅｆｉｎｉｔｉｏｎ ｏｂｊｅｃｔ
Ｒｏｌｅ−ａｓｓｉｇｎｍｅｎｔ：ＡｚＭａｎ Ｒｏｌｅ Ａｓｓｉｇｎｍｅｎｔオブジェクト
注：ＡｚＭａｎアプリケーショングループを静的に定義することができ、または実行時に計算することができる。

現在説明しているＡｚＭａｎ実装についてのセットアップに関して、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（ＡＤ）アカウントが作成され、次いでそれがトラステッド許可サービスで使用され、資源上のＡＤおよびＡＣＬでの役割メンバシップが更新される。次いで、このＡＤアカウントが、資源上のＡＣＬを更新するために各資源サーバにログオンする。次いで、ＡｚＭａｎストアオブジェクトが作成され、トラステッド許可サービスがＰｏｌｉｃｙ Ｒｅａｄｅｒ ＡｚＭａｎ管理役割に割り当てられる。

Ａｚｍａｎ実装でのアプリケーション初期化に関して、アプリケーションが、ＮＴＦＳ資源マネージャ用のＡｚＭａｎで定義される。ＮＴＦＳオペレーションがＡｚＭａｎオペレーションにマッピングされる。アクセスマスクへの変換のプロセスを単純化するために、各許可を、対応するアクセスマスクと同数にすることができる。ＮＴＦＳ ＡＣＬエディタでの各許可レベル（Ｆｕｌｌ Ｃｏｎｔｒｏｌ、Ｍｏｄｉｆｙなど）について、ＡｚＭａｎ役割定義が定義され、対応するアクセスマスクが、役割定義オブジェクト上のＡｐｐｌｉｃａｔｉｏｎＤａｔａプロパティに格納される。

Ａｚｍａｎ実装での範囲作成に関して、各範囲について、ＡｚＭａｎ範囲がＮＴＦＳ ＡｚＭａｎアプリケーションで定義される。範囲内のファイル共有およびディレクトリＵＮＣのリストをＡｚＭａｎ範囲オブジェクトのＡｐｐｌｉｃａｉｔｏｎＤａｔａプロパティで保持することができる。

ＡｚＭａｎ実装での組織的役割に関して、各組織的役割について、ＡｚＭａｎグローバルアプリケーショングループが作成される。ＡＤユニバーサルグループがＡｚＭａｎグローバルアプリケーショングループに割り当てられる。組織的役割が割り当てられる各アプリケーション役割について、ＲＢＡＣシステムは、アプリケーション定義の役割定義（すなわちＦｕｌｌ Ｃｏｎｔｒｏｌ、Ｍｏｄｉｆｙなど）にリンクするＡｚＭａｎ Ｒｏｌｅ−Ａｓｓｉｇｎｍｅｎｔオブジェクトを作成する。

各ＡｚＭａｎ役割割当てについて、ＲＢＡＣシステムは、ＡｚＭａｎ、すなわちＡｚＭａｎグローバルアプリケーショングループ内の組織的役割のリストを列挙し、さらに各役割についてＲｏｌｅＡｓｓｉｇｎｍｅｎｔを列挙することすることにより、上記で定義した資源グループにＡＤユニバーサルグループを割り当てる。各ＲｏｌｅＡｓｓｉｇｍｎｅｎｔは、範囲および役割定義を識別する。次いで、ＲＢＡＣシステムは、現在説明している実装でのＡｚＭａｎアプリケーショングループに対するメンバとして識別したＡＤユニバーサルグループを、各役割割当てオブジェクトで識別された範囲および役割定義に合致する資源グループに割り当てる。

ＡｚＭａｎ実装のメンバシップに関して、組織的役割に対するメンバシップ変更が、組織的役割に対応するＡＤユニバーサルグループに格納される。ＲＢＡＣシステムは、これを抽象化し、またはＡＤグループを公開し、ＡｚＭａｎアプリケーショングループはＡＤユニバーサルグループのうちの少なくとも１つを含む。

ＡｚＭａｎ実装の許可変化に関して、許可変化が上記のように管理され、追加のタスクが、ＡｚＭａｎグローバルグループの割当てをＡｚＭａｎ役割割当てに追加または除去し、組織的役割許可が追加、削除、または変更されるとき、ＡｚＭａｎ役割定義を追加、削除、または更新する。

補足的状況−ＡＣＬベースのシステム
アクセス制御リスト（ＡＣＬ）は、各ユーザがファイルディレクトリや個々のファイルなどの特定のシステムオブジェクトに対してどのアクセス権を有するかをコンピュータシステムに伝える、テーブルなどのデータ構造である。各オブジェクトは、そのアクセス制御リストを識別するセキュリティ属性を有する。リストは、アクセス特権またはアクセス特権の明示的拒否を伴う、各システムユーザについてのエントリを有する。最も一般的な特権は、ファイル（またはディレクトリ内のすべてのファイル）を読み取る能力、ファイルに書き込む能力、およびファイルを実行する能力（ファイルが実行可能ファイルまたはプログラムである場合）を含む。様々なオペレーティングシステムは、各オペレーティングシステムによって異なるように実装されたアクセス制御リストを使用する。

Ｗｉｎｄｏｗｓでは、一般に、アクセス制御リスト（ＡＣＬ）が各システムオブジェクトと関連付けられる。各ＡＣＬは、ユーザまたはユーザのグループの名前からなる１つまたは複数のアクセス制御エントリ（ＡＣＥ）を有する。ユーザはまた、「プログラマ」や「テスタ」などの役割名でもよい。こうしたユーザ、グループ、または役割のそれぞれについて、アクセス特権が、アクセスマスクと呼ばれるビットの文字列で記述される。一般に、システム管理者またはオブジェクト所有者は、オブジェクトに関するアクセス制御リストを作成する。

図６に反映されるように、ＡＣＬ６００ａ、６００ｂ、６００ｃ、．．．、６００Ｎは、１つまたは複数のアクセス制御エントリ（ＡＣＥ）を含む。例えばＡＣＬ６００ａはＡＣＥ１、ＡＣＥ２、．．．、ＡＣＥＮを含む。ＡＣＬは、主ないくつかの権利を許可／拒否するＡＣＥのリストである。ＡＣＬの各ＡＣＥを資源ごとにマッピングすることができ、それによって各資源は、その資源に適用されるＡＣＬからのＡＣＥのリストを有する。例えば、図示されるように、ＡＣＬ６００ａのＡＣＥ１、ＡＣＥ２、およびＡＣＥＮが、コンピューティングシステムのサブコンポーネントＳ１、Ｓ２、．．．、ＳＮの様々な資源にマッピングされる。例えば、サブコンポーネントＳ１は第１サーバでよく、Ｓ２は第２サーバでよく、以下同様である。資源ｒ１、ｒ２、ｒ３がサブコンポーネントＳ１と関連付けられ、資源ｒ４、ｒ５、ｒ６がサブコンポーネントＳ２と関連付けられ、資源ｒｘ、ｒｙ、ｒＮがサブコンポーネントＳＮと関連付けられる。しかし、資源をシステム内でサブグループ化することができ、点線で示されるように、ＡＣＬのＡＣＥをコンピューティングシステムの個々の資源にマッピングすることができ、ＡＣＬから、対応するＡＣＥに基づく資源ベースのポリシーに変換される。

補足的状況−ＮＩＳＴ ＲＢＡＣ標準
１つの非限定的例示的ＲＢＡＣポリシーモデルとして、米国標準技術研究所（ＮＩＳＴ）は、ＲＢＡＣ標準（すなわち、ＩｎｔｅｒＮａｔｉｏｎａｌ Ｃｏｍｍｉｔｔｅｅ ｆｏｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ Ｓｔａｎｄａｒｄｓ（ＩＮＣＩＴＳ）Ｄｅｓｉｇｎａｔｉｏｎ：ＩＮＣＩＴＳ ３５９）を有し、それについての概要が以下のように与えられる。ＮＩＳＴ標準は、いくつかの一般に受け入れられるＲＢＡＣ特徴と、基準モデルで拒否されるＲＢＡＣ特徴に関する機能とを定義する仕様基準モデルを含む。ＮＩＳＴ標準は、ＲＢＡＣ Ｒｅｆｅｒｅｎｃｅ ＭｏｄｅｌとＲＢＡＣ Ｓｙｓｔｅｍ ａｎｄ Ａｄｍｉｎｉｓｔｒａｔｉｖｅ Ｆｕｎｃｔｉｏｎａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎの２つの部分からなり、それらが以下で詳細に説明される。

ＲＢＡＣ Ｒｅｆｅｒｅｎｃｅ Ｍｏｄｅｌは、基本的ＲＢＡＣ要素のセット（すなわち、ユーザ、役割、許可、オペレーション、およびオブジェクト）および関係を、この標準に含まれるタイプおよび機能として定義する。ＲＢＡＣ基準モデルは２つの目的を果たす。まず、基準モデルは、標準に含まれるＲＢＡＣ機能の範囲を定義する。これは、すべての準拠ＲＢＡＣシステムに含まれる特徴の最小限のセット、役割階層の各側面、静的制約関係の各側面、および動的制約関係の各側面を識別する。第２に、基準モデルは、機能仕様を定義する際に使用するために、要素セットおよび機能によって言語を提供する。

ＲＢＡＣ ＳｙｓｔｅｍおよびＡｄｍｉｎｉｓｔｒａｔｉｖｅ Ｆｕｎｃｔｉｏｎａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎは、ＲＢＡＣシステムの必要な特徴を指定する。こうした特徴は、管理オペレーション、管理検討、およびシステムレベル機能という３つのカテゴリに分類される。管理オペレーションは、ＲＢＡＣ要素および関係を作成、削除、および維持する（例えばユーザ役割割当てを作成および削除する）能力を提供する管理インターフェースおよび関連するセマンティクスのセットによって機能を定義する。管理検討特徴は、ＲＢＡＣ要素および関係に対して照会オペレーションを実行する能力を提供する管理インターフェースおよび関連するセマンティクスのセットによって機能を定義する。システムレベル機能は、役割活動化／非活動化、役割活動化に関する制約の実施を含めるためのユーザセッションの作成、およびアクセス判断の計算のための特徴を定義する。

ＲＢＡＣ基準モデルは、Ｃｏｒｅ ＲＢＡＣ、Ｈｉｅｒａｒｃｈｉｃａｌ ＲＢＡＣ、Ｓｔａｔｉｃ Ｓｅｐａｒａｔｉｏｎ ｏｆ Ｄｕｔｙ Ｒｅｌａｔｉｏｎｓ、およびＤｙｎａｍｉｃ Ｓｅｐａｒａｔｉｏｎ ｏｆ Ｄｕｔｙ Ｒｅｌａｔｉｏｎｓという４つのモデルコンポーネントによって定義される。各モデル構成要素は、以下のサブコンポーネントによって定義される：１組の基本要素セット、こうした要素セットに関係する１組のＲＢＡＣ関係（有効な割当てを示すカルテシアン積のサブセットを含む）、およびある要素セットからの所与のインスタンスに対して設定された、別の要素からメンバのインスタンスを生み出す１組のＭａｐｐｉｎｇ Ｆｕｎｃｔｉｏｎ。

コアＲＢＡＣは、Ｒｏｌｅ−Ｂａｓｅｄ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍを完全に達成するために、ＲＢＡＣ要素、要素セット、および関係の最小限の集合を定義する。これは、多くのＲＢＡＣシステムで基本的と考えられる、ユーザ役割割当てと許可役割割当ての関係を含む。さらに、コアＲＢＡＣは、コンピュータシステム内のユーザのセッションの一部として役割活動化の概念を導入する。コアＲＢＡＣは、任意のＮＩＳＴ準拠ＲＢＡＣシステムで必要であるが、他のコンポーネントは、互いに独立であり、別々に実装することができる。全体としてのＲＢＡＣモデルは、本質的に、役割に割り当てられている個々のユーザと、役割に割り当てられている許可によって定義される。したがって、役割は、個々のユーザおよび許可間の多対多関係を命名するための手段である。さらに、コアＲＢＡＣモデルは、１組のセッション（ＳＥＳＳＩＯＮＳ）を含み、各セッションは、ユーザと、ユーザに割り当てられる役割の活動化されたサブセットとの間のマッピングである。

コアＲＢＡＣは、ユーザ（ＵＳＥＲＳ）、役割（ＲＯＬＥＳ）、オブジェクト（ＯＢＳ）、オペレーション（ＯＰＳ）、および許可（ＰＲＭＳ）と呼ばれる５つの基本データ要素を含む。ユーザとは一般に人間を指すが、概念としては、何らかの方式で人間の代わりに働くマシン、ネットワーク、またはインテリジェント自律エージェントを含むように、ユーザおよびユーザの証明書の概念を拡張することができる。役割は、組織のコンテキスト内のジョブ機能であり、権限および責任に関する関連するセマンティクスが、役割に割り当てられたユーザに関して協議される。許可は、１つまたは複数のＲＢＡＣ保護オブジェクトに対するオペレーションを実行するための承認である。オペレーションは、ユーザに関する何らかの機能を呼出し時に実行するプログラムの実行可能イメージである。ＲＢＡＣが制御するこのタイプのオペレーションおよびオブジェクトは、それが実装されるシステムのタイプとは無関係である。例えば、ファイルシステム内では、オペレーションは読取り、書込み、および実行を含むことができ、データベース管理システム内では、オペレーションは挿入、削除、追加、および更新を含むことができる。任意のアクセス制御機構の目的は、システム資源（すなわち保護されたオブジェクト）を保護することである。アクセス制御の初期のモデルと適合して、オブジェクトは、情報を含み、または受け取るエンティティである。

各セッションは、あるユーザの、恐らくは多くの役割へのマッピングであり、すなわち、ユーザはセッションを確立し、そのセッションの間、ユーザは、ユーザに割り当てられる役割のあるサブセットを活動化する。各セッションは単一のユーザと関連付けられ、各ユーザは１つまたは複数のセッションと関連付けられる。関数ｓｅｓｓｉｏｎ＿ｒｏｌｅｓは、セッションによって活動化された役割を与え、関数ｓｅｓｓｉｏｎ＿ｕｓｅｒｓは、セッションに関連するユーザを与える。ユーザにとって利用可能な許可は、すべてのユーザのセッションにわたって現在アクティブである役割に割り当てられた許可である。

ＨｉｅｒａｒｃｈｉｃａｌＲＢＡＣコンポーネントは、役割階層に関する関係を追加する。階層は、役割間の上下関係を定義する部分的順序であり、それによって上層レベルの役割が、下層レベルの許可を獲得し、下層レベルの役割が上層レベルのユーザを獲得する。さらに、Ｈｉｅｒａｒｃｈｉｃａｌ ＲＢＡＣは、許可ユーザと許可された許可の役割のセットの概念を導入することにより、単純なユーザおよび許可役割割当てに優先する。

階層は、組織の権限および責任の線を反映するように役割を構造化する自然な手段である。役割階層は、役割の間の継承関係を定義する。継承は、許可によって記述されてきた。すなわち、ｒ２のすべての特権がｒ１の特権でもある場合、ｒ１は役割ｒ２を「継承」する。ある分散型ＲＢＡＣ実装では、役割許可は集中型で管理されないが、役割階層は集中型で管理される。こうした場合、役割階層はユーザ制約関係によって管理され、ｒ１について許可されたすべてのユーザがｒ２についても許可される場合、役割ｒ１は役割ｒ２を「含む」。しかし、ユーザ包含は、ｒ１のユーザが（少なくとも）ｒ２のすべての特権を有することを暗示するが、ｒ１およびｒ２に関する許可継承は、ユーザ割当てについて何も暗示しないことに留意されたい。

この標準は、一般役割階層と限定役割階層という２つのタイプの役割階層を認識する。一般役割階層は、役割階層として働くための任意の部分的順序に関するサポートを提供し、許可の複数の継承および役割間のユーザメンバシップの概念を含む。限定役割階層は、制限を課し、その結果、より単純なツリー構造が得られる（すなわち、役割は１つまたは複数の直系の先祖を有することができるが、単一の直系の子孫に制限される）。

一般役割階層は、複数の継承の概念をサポートし、複数の継承は、２つ以上の役割ソースから許可を継承し、２つ以上の役割ソースからユーザメンバシップを継承する能力を提供する。

第３モデルコンポーネントであるＳｔａｔｉｃ Ｓｅｐａｒａｔｉｏｎ ｏｆ Ｄｕｔｙ（ＳＳＤ）Ｒｅｌａｔｉｏｎは、ユーザ割当てに関して役割間の排他性関係を追加する。役割ベースのシステムへの関心の競合が、競合する役割に関連する許可に対する権限をユーザが得る結果として生じる可能性がある。この形態の関心の競合を防止する一手段は、ＳＳＤを介するものであり、すなわち、ユーザの役割への割当てに関する制約を実施することである。役割階層のデューティ関係と継承関係の静的分離に関する不整合の可能性のために、ＳＳＤ関係モデルコンポーネントは、役割階層の存在と不在の両方における関係を定義する。静的制約は、多種多様な形態を取ることができる。一般的な例は、役割のセットに関して、互いに素なユーザ割当てを定義するＳＳＤである。

第４モデルコンポーネントであるＤｙｎａｍｉｃ Ｓｅｐａｒａｔｉｏｎ ｏｆ Ｄｕｔｙ （ＤＳＤ）Ｒｅｌａｔｉｏｎｓは、ユーザのセッションの一部として活動化される役割に関して排他性関係を定義し、ＤＳＤの組織特有のポリシーを実施する能力を提供する。

ＳＳＤとＤＳＤを比較すると、ＳＳＤ関係は、ユーザの全許可空間に関する制約を定義し、それを課す。ＳＳＤ関係は、１組の役割に割り当てることのできるユーザに関する制約を課すことにより、ユーザに対して利用可能にすることができる潜在的許可の数を削減する。ＤＳＤ関係は、ＳＳＤ関係と同様に、ユーザが利用可能な許可を制限するように意図されるものである。しかし、ＤＳＤ関係は、こうした制限が課される状況により、ＳＳＤ関係とは異なる。ＤＳＤ Ｒｅｌａｔｉｏｎモデルコンポーネントは、ユーザのセッション内で、またはユーザのセッションにわたって活動化することのできる役割に関する制約を課すことによってユーザの許可空間にわたる許可の可用性を制限するＤＳＤプロパティを定義する。ＤＳＤプロパティは、実行される役割に応じて各ユーザが様々なレベルの許可を様々な時間に有する点で、最小特権の原理に対する拡張サポートを提供する。こうしたプロパティは、デューティの性能のために必要とされる時間を超えて許可が存続しないことを保証する。この最小特権の態様はしばしば、トラストの適時取消しと呼ばれる。他のＳＳＤとＤＳＤの違いも存在し、理解できるように、許可の動的取消しはデューティの動的分離の機構なしには幾分複雑となる可能性があり、したがって、便宜上、過去においては一般に無視されてきた。

例示的ネットワーク環境および分散型環境
コンピュータネットワークの一部として配置することができ、または分散コンピューティング環境内に配置することのできる任意のコンピュータまたは他のクライアントまたはサーバと共に本発明を実装できることを当業者は理解することができる。この点で、本発明は、任意の数のメモリまたは記憶装置と、任意の数の記憶装置またはボリュームにわたって行われる任意の数のアプリケーションおよびプロセスとを有する任意のコンピュータシステムまたは環境に関連し、その任意のコンピュータシステムまたは環境を、本発明によるアクセスポリシーモデルにわたって変換するプロセスと共に使用することができる。本発明は、リモートまたはローカルストレージを有する、ネットワーク環境または分散コンピューティング環境内に配置されたサーバコンピュータおよびクライアントコンピュータを有する環境に適用することができる。本発明はまた、リモートまたはローカルサービスおよびプロセスと共に情報を生成、受信、および送信するためのプログラミング言語機能、解釈および実行機能を有するスタンドアロンコンピューティング装置にも適用することができる。

分散コンピューティングは、コンピューティング装置およびシステムの間の交換によってコンピュータ資源およびサービスの共有を実現する。こうした資源およびサービスは、情報の交換、ファイルなどのオブジェクトのためのキャッシュストレージおよびディスクストレージを含む。分散コンピューティングはネットワーク接続性を活用し、クライアントがその集合的パワーを活用して、企業全体に利することを可能にする。この点で、様々な装置が、本発明のアクセスポリシーモデルにわたって変換を実施するシステムおよび方法を関係させることのできるアプリケーション、オブジェクト、または資源を有することができる。

図７Ａは、例示的ネットワーク環境または例示的分散コンピューティング環境の略図を与える。分散コンピューティング環境はコンピューティングオブジェクト１０ａ、１０ｂなど、およびコンピューティングオブジェクトまたは装置１１０ａ、１１０ｂ、１１０ｃなどを含む。こうしたオブジェクトは、プログラム、メソッド、データストア、プログラマブルロジックなどを含むことができる。オブジェクトは、ＰＤＡ、オーディオ／ビデオ装置、ＭＰ３プレーヤ、パーソナルコンピュータなどの同一または異なる装置の各部分を含むことができる。各オブジェクトは、通信ネットワーク１４によって別のオブジェクトと通信することができる。このネットワークは、それ自体、図７Ａのシステムにサービスを提供する他のコンピューティングオブジェクトおよびコンピューティング装置を含むことができ、それ自体、複数の相互接続されたネットワークを表すことができる。本発明の一態様によれば、各オブジェクト１０ａ、１０ｂなど、または１１０ａ、１１０ｂ、１１０ｃは、本発明によるＲＢＡＣポリシーモデルからＲＡＰモデルに変換するシステムおよび方法と共に使用するのに適したＡＰＩ、または他のオブジェクト、ソフトウェア、ファームウェア、および／またはハードウェアを利用することのできるアプリケーションを含むことができる。

１１０ｃなどのオブジェクトを別のコンピューティング装置１０ａ、１０ｂなど、または１１０ａ、１１０ｂなどの上でホストすることができることも理解することができる。したがって、図示される物理的環境は、接続された装置をコンピュータとして示すことがあるが、そのような図示は例示的なものに過ぎず、別法として、ＰＤＡ、テレビジョン、ＭＰ３プレーヤなどの様々なデジタル装置、インターフェース、ＣＯＭオブジェクトなどのソフトウェアオブジェクトを含む物理的環境を図示または記述することができる。

分散コンピューティング環境をサポートする様々なシステム、構成要素、およびネットワーク構成が存在する。例えば、優先またはワイヤレスシステム、ローカルネットワーク、あるいは広範に分散したネットワークでコンピューティングシステムを互いに接続することができる。現在のところ、ネットワークの多くは、広範に分散したコンピューティングのためのインフラストラクチャを提供し、多数の異なるネットワークを包含するインターネットに結合される。本発明によるアクセスポリシーモデルにわたって変換するために行われる例示的通信のために任意のインフラストラクチャを使用することができる。

ホームネットワーキング環境では、電力線、データ（ワイヤレスと有線の両方）、音声（例えば電話）、エンターテイメント媒体などの固有のプロトコルをそれぞれサポートすることのできる、少なくとも４つの異なるネットワーク移送媒体が存在する。光スイッチやアプライアンスなどのホーム制御装置は、接続性のために電力線を使用することができる。データサービスは、ブロードバンド（例えばＤＳＬまたはケーブルモデム）として家庭に進入することができ、ワイヤレス（例えばＨｏｍｅＲＦまたは８０２．１１Ｂ）接続性または有線（例えばＨｏｍｅ ＰＮＡ、Ｃａｔ ５、イーサネット（登録商標）、さらには電力線）接続性を使用して家庭内でアクセス可能である。ボイストラフィックは、有線（例えばＣａｔ ３）またはワイヤレス（例えば携帯電話）として家庭に進入することができ、例えばＣａｔ ３配線を使用して家庭内で配布することができる。エンターテイメント媒体または他のグラフィカルデータは、サテライトまたはケーブルを介して家庭に進入することができ、通常は同軸ケーブルを使用して家庭内で配布される。ＩＥＥＥ１３９４およびＤＶＩも媒体装置のクラスタ用のデジタル相互接続である。こうしたネットワーク環境と、プロトコル標準として出現する可能性のある、または既に出現しているその他のすべてを相互接続して、イントラネットなどのネットワークを形成することができ、それをＧＳＭネットワーク環境やインターネットなどの広域ネットワークによって外部世界に接続することができる。手短に言えば、データの格納および伝送のための様々な異なるソースが存在し、したがって、さらに言えば、コンピューティング装置は、本発明によるアクセスポリシーモデルにわたる変換中に、プログラムオブジェクトに付随してアクセスまたは使用されるデータなどのデータを共有する方式を必要とする。

インターネットは一般に、コンピュータネットワーキングの技術分野で周知の伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）プロトコル群を使用するネットワークおよびゲートウェイの集合を指す。インターネットは、ユーザがネットワークを介して対話し、情報を共有することを可能にするネットワーキングプロトコルを実行するコンピュータによって相互接続された、地理的に分散したリモートコンピュータネットワークのシステムと述べることができる。このような広範囲にわたる情報の共有のために、インターネットなどのリモートネットワークは、これまでのところ一般には、開発者が専用のオペレーションまたはサービスを実行するために本質的に無制限にソフトウェアアプリケーションを設計することのできるオープンシステムとして発展してきた。

したがって、ネットワークインフラストラクチャにより、クライアント／サーバ、ピアツーピア、またはハイブリッドアーキテクチャなどのネットワークトポロジのホストが可能となる。「クライアント」とは、無関係の別のクラスまたはグループのサービスを使用するクラスまたはグループのメンバである。したがって、コンピューティングにおいて、クライアントは、別のプログラムによって提供されるサービスを要求するプロセス、すなわち大雑把に言えば１組の命令またはタスクである。クライアントプロセスは、他のプログラムまたはサービス自体についての動作詳細を「認識」する必要なしに、要求したサービスを利用する。クライアント／サーバアーキテクチャ、特にネットワークシステムでは、クライアントは通常、別のコンピュータ、例えばサーバによって提供される共有ネットワーク資源にアクセスするコンピュータである。図７Ａでは、一例を挙げると、コンピュータ１１０ａ、１１０ｂなどをクライアントとみなすことができ、コンピュータ１０ａ、１０ｂなどをサーバとみなすことができ、サーバ１０ａ、１０ｂなどがデータを維持し、次いでそのデータがクライアントコンピュータ１１０ａ、１１０ｂなどに複写されるが、状況に応じて、任意のコンピュータをクライアント、サーバ、またはその両方とみなすことができる。こうしたコンピューティング装置のいずれも、本発明によるＲＢＡＣモデルからＲＡＰモデルへの変換に関係する可能性のあるデータを処理している可能性があり、または本発明によるＲＢＡＣモデルからＲＡＰモデルへの変換に関係する可能性のあるサービスまたはタスクを要求している可能性がある。

サーバは一般に、インターネットなどのリモートまたはローカルのネットワークを介してアクセス可能なリモートコンピュータシステムである。クライアントプロセスは第１のコンピュータシステムでアクティブにすることができ、サーバプロセスは第２のコンピュータシステムでアクティブにすることができ、それらが通信媒体を介して互いに通信し、したがって分散機能が提供され、複数のクライアントがサーバの情報収集能力を利用することが可能となる。本発明のアクセスポリシーモデルにわたって変換する技法に従って利用されるどんなソフトウェアオブジェクトも複数のコンピューティング装置またはオブジェクトにわたって分散させることができる。

クライアントとサーバは、プロトコル層で提供される機能を利用して互いに通信することができる。例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ワールドワイドウェブ（ＷＷＷ）すなわち「ウェブ」に関連して使用される一般的なプロトコルである。通常、インターネットプロトコル（ＩＰ）アドレスなどのコンピュータネットワークアドレス、またはＵｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）などの他の参照を使用して、サーバまたはクライアントコンピュータを互いに識別することができる。ネットワークアドレスをＵＲＬアドレスと呼ぶことができる。通信媒体を介して通信を実現することができ、例えば高容量通信用のＴＣＰ／ＩＰ接続を介してクライアントとサーバを互いに結合することができる。

したがって、図７Ａは、本発明を利用することのできる、サーバがネットワーク／バスを介してクライアントコンピュータと通信する例示的なネットワーク環境または分散環境を示す。より詳細には、いくつかのサーバ１０ａ、１０ｂなどが、通信ネットワーク／バス１４は、ＬＡＮ、ＷＡＮ、イントラネット、インターネットなどでよい通信ネットワーク／バス１４を介して、ポータブルコンピュータ、ハンドヘルドコンピュータ、シンクライアント、ネットワーク式アプライアンスなど、またはＶＣＲ、ＴＶ、オーブン、ライト、ヒータなどの他の装置などのいくつかのクライアントまたはリモートコンピューティング装置１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどと相互接続される。したがって、あるアクセスポリシーモデルから別のアクセスポリシーモデルに変換することがそれに関連して望ましい任意のコンピューティング装置に本発明を適用できることが企図される。

例えば通信ネットワーク／バス１４がインターネットであるネットワーク環境では、サーバ１０ａ、１０ｂなどは、クライアント１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどがＨＴＴＰなどのいくつかの周知のプロトコルのいずれかを介して通信することができるウェブサーバでよい。分散コンピューティング環境の特徴として、サーバ１０ａ、１０ｂなどは、クライアント１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどとして働くこともできる。

上述のように、通信は適宜、有線またはワイヤレスでよい。クライアント装置１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどは、通信ネットワーク／バス１４を介して通信することがあり、または通信しないことがあり、それらに関連する独立な通信を有することがある。例えば、ＴＶまたはＶＣＲの場合、その制御に対するネットワーク態様が存在することがあり、または存在しないことがある。各クライアントコンピュータ１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなど、およびサーバコンピュータ１０ａ、１０ｂなどは、様々なアプリケーションプログラムモジュールまたはオブジェクト１３５ａ、１３５ｂ、１３５ｃなどを備えることがあり、様々なタイプの記憶素子またはオブジェクトに対する接続またはアクセスを備えることがあり、それらにわたってファイルまたはデータストリームを格納することができ、またはそれらに対してファイルまたはデータストリームの部分をダウンロードし、送信し、または移動することができる。コンピュータ１０ａ、１０ｂ、１１０ａ、１１０ｂなどのうちの任意の１つまたは複数は、本発明に従って処理または保存されるデータを格納するデータベースまたはメモリ２０などのデータベース２０または他の記憶素子の保守および更新の任を担うことができる。したがって、本発明は、クライアントコンピュータ１１０ａ、１１０ｂなど、および他の類似のデバイス、ならびにデータベース２０と対話することのできるコンピュータネットワーク／バス１４およびサーバコンピュータ１０ａ、１０ｂなどにアクセスすることができ、対話することができるクライアントコンピュータ１１０ａ、１１０ｂなどを有するコンピュータネットワーク環境で使用することができる。

例示的コンピューティング装置
上述のように、本発明は、コンピューティング装置のアクセスポリシーモデルにわたって変換することが望ましい任意の装置に適用される。しかし、前述のように、ハンドヘルド装置、ポータブル装置、およびその他のコンピューティング装置と、すべての種類のコンピューティングオブジェクト、すなわち装置がアクセス制御に関するポリシーモデルにわたって変換することを望む可能性のある任意の場所（例えば、携帯電話などのポータブル装置を介するＧＳＭネットワーク）が、本発明と共に使用されるように企図されることを理解されたい。したがって、図７Ｂで記述される以下の汎用リモートコンピュータは一例に過ぎず、ネットワーク／バス相互運用性および対話を有する任意のクライアントで本発明を実装することができる。したがって、非常にわずかな、または最小のクライアント資源が含まれるネットワークホストサービスの環境、例えば、アプライアンス内に配置されたオブジェクトなどのクライアント装置が単にネットワーク／バスに対するインターフェースとして働くネットワーク環境で本発明を実装することができる。

必須ではないが、装置またはオブジェクト向けのサービスの開発者が使用するために、オペレーティングシステムを介して本発明を部分的に実装することができ、かつ／または本発明の構成要素と共に動作するアプリケーションソフトウェア内に本発明を含めることができる。ソフトウェアは、クライアントワークステーション、サーバ、他の装置などの１つまたは複数のコンピュータによって実行中のプログラムモジュールなどのコンピュータ実行可能命令の一般的な状況で記述することができる。本発明を他のコンピュータシステム構成およびプロトコルと共に実施できることを当業者は理解されよう。

したがって、図７Ｂは、本発明を実装することのできる適切なコンピューティングシステム環境１００ａの一例を示すが、上記で明らかにしたように、コンピューティングシステム環境１００ａはコンピューティング装置のための適切なコンピューティング環境の一例に過ぎず、本発明の使用法または機能の範囲について何らかの制限を示唆するものではない。例示的動作環境１００ａに示される構成要素のいずれか１つあるいはその組合せに関して、コンピューティング環境１００ａが何らかの依存関係または要件を有するものと解釈すべきでもない。

図７Ｂを参照すると、本発明を実装する例示的リモート装置は、コンピュータ１１０ａの形態の汎用コンピューティング装置を含む。コンピュータ１１０ａの構成要素は、限定はしないが、処理装置１２０ａと、システムメモリ１３０ａと、システムメモリを含む様々なシステム構成要素を処理装置１２０ａに結合するシステムバス１２１ａとを含むことができる。システムバス１２１ａは、様々なバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のいずれでもよい。

コンピュータ１１０ａは通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体はコンピュータ１１０ａでアクセスすることができる入手可能などんな媒体でもよい。例えば、限定はしないが、コンピュータ可読媒体は、コンピュータ記憶媒体と通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、他のデータなどの情報の格納のための任意の方法または技術で実装された不揮発性媒体と揮発性媒体の両方、取外し可能媒体と取外し不能媒体の両方を含む。コンピュータ記憶媒体は、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、またはその他のメモリ技術、ＣＤＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）、または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気記憶装置、あるいは所望の情報を格納するのに使用することができ、コンピュータ１１０ａでアクセスすることのできる他の任意の媒体を含む。通信媒体は通常、コンピュータ可読命令、データ構造、プログラムモジュール、あるいは他のデータを、搬送波や他の移送機構などの被変調データ信号として実施し、任意の情報配信媒体を含む。

システムメモリ１３０ａは、読取り専用メモリ（ＲＯＭ）やランダムアクセスメモリ（ＲＡＭ）など、揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動時などにコンピュータ１１０ａ内の要素間で情報を転送する助けとなる基本ルーチンを含む基本入出力システム（ＢＩＯＳ）をメモリ１３０ａに格納することができる。メモリ１３０ａは通常、処理装置１２０ａから即座にアクセス可能であり、かつ／または処理装置１２０ａによって現在操作されているデータおよび／またはプログラムモジュールも含む。例えば、限定はしないが、図１に、メモリ１３０ａは、オペレーティングシステム、アプリケーションプログラム、他のプログラムモジュール、およびプログラムデータも含むことができる。

コンピュータ１１０ａは、他の取外し可能／取外し不能な、揮発性／不揮発性のコンピュータ記憶媒体も含むことができる。例えば、コンピュータ１１０ａは、取外し不能な不揮発性の磁気媒体を読み書きするハードディスクドライブ、取外し可能な不揮発性の磁気ディスクを読み書きする磁気ディスクドライブ、およびＣＤ−ＲＯＭや他の光学媒体などの取外し可能な不揮発性の光ディスクを読み書きする光ディスクドライブを含むことができる。例示的動作環境で使用することができる他の取外し可能／取外し不能な、揮発性／不揮発性のコンピュータ記憶媒体は、限定はしないが、磁気テープカセット、フラッシュメモリカード、デジタルバーサタイルディスク、デジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどを含む。ハードディスクドライブは通常、インターフェースなどの取外し不能メモリインターフェースを介してシステムバス１２１ａに接続され、磁気ディスクドライブおよび光ディスクドライブは通常、インターフェースなどの取外し可能メモリインターフェースによってシステムバス１２１ａに接続される。

ユーザは、キーボードや、一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイスなどの入力装置を介して、コマンドおよび情報をコンピュータ１１０ａに入力することができる。他の入力装置は、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどを含むことができる。これらの入力装置や他の入力装置はしばしば、システムバス１２１ａに結合されるユーザ入力１４０ａおよび関連するインターフェースを介して処理装置１２０ａに接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することもできる。グラフィックスサブシステムもシステムバス１２１ａに接続することもできる。モニタまたは他のタイプのディスプレイ装置も出力インターフェース１５０ａなどのインターフェースを介してシステムバス１２１ａに接続され、出力インターフェース１５０ａはビデオメモリと通信することができる。モニタに加えて、コンピュータは、スピーカやプリンタなどの他の周辺出力装置も含むことができ、その周辺出力装置は、出力インターフェース１５０ａを介して接続することができる。

コンピュータ１１０ａは、リモートコンピュータ１７０ａなどの１つまたは複数の他のリモートコンピュータへの論理接続を使用して、ネットワーク環境または分散環境で動作することができ、１つまたは複数の他のリモートコンピュータは、装置１１０ａとは異なる媒体能力などの能力を有する。リモートコンピュータ１７０ａは、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の共通ネットワークノード、あるいは他の任意のリモート媒体消費または伝送装置でよく、コンピュータ１１０ａに関して上記で述べた要素のいずれかまたはすべてを含むことができる。図７Ｂに示される論理接続は、ローカルエリアネットワーク（ＬＡＮ）や広域ネットワーク（ＷＡＮ）などのネットワーク１７１ａを含むが、他のネットワーク／バスも含むことができる。そのようなネットワーキング環境は、家庭、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的なものである。

ＬＡＮネットワーキング環境で使用されるとき、コンピュータ１１０ａは、ネットワークインターフェースまたはアダプタを介してＬＡＮ１７１ａに接続される。ＷＡＮネットワーキング環境で使用する際、コンピュータ１１０ａは通常、インターネットなどのＷＡＮを介して通信を確立するネットワークコンポーネント（ネットワークカードモデムなど）または他の手段を含む。ネットワークに接続するための手段は内蔵または外付けでよく、入力１４０ａのユーザ入力インターフェースまたは他の適切な機構を介してシステムバス１２１ａに接続することができる。ネットワーク環境では、コンピュータ１１０ａに関して示されるプログラムモジュールまたはその各部分をリモートメモリ記憶装置に格納することができる。図示および説明されるネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段を使用できることを理解されよう。

例示的分散コンピューティングフレームワークまたはアーキテクチャ
様々な分散コンピューティングフレームワークがパーソナルコンピューティングとインターネットの収束に照らして開発されてきており、かつ開発されつつある。個人ユーザおよびビジネスユーザは一様に、アプリケーションおよびコンピューティング装置のためのシームレスに相互相互運用可能かつウェブ使用可能なインターフェースを備え、コンピューティング活動がますますウェブブラウザまたはネットワーク指向となっている。

例えば、ＭＩＣＲＯＳＯＦＴ（登録商標）の管理コードプラットフォーム、すなわち．ＮＥＴは、サーバ、ウェブベースのデータストレージなどのビルディングブロックサービス、およびダウンロード可能装置ソフトウェアを含む。一般的には、．ＮＥＴプラットフォームは、（１）コンピューティング装置の範囲全体が共に働くようにし、コンピューティング装置上のすべてに対してユーザ情報を自動的に更新および同期させる能力、（２）ＨＴＭＬではなくＸＭＬをより多く使用することによって可能となる、ウェブページに関する対話機能の向上、（３）例えばＥメールなどの様々なアプリケーション、Ｏｆｆｉｃｅ ．ＮＥＴなどのソフトウェアの管理のための、中央開始地点からユーザへの製品およびサービスのカスタマイズ化されたアクセスおよび送達を特徴とするオンラインサービス、（４）アクセスの効率および容易さ、ならびにユーザおよび装置間の情報の同期を向上させる集中型データストレージ、（５）Ｅメール、ファックス、電話などの様々な通信媒体を統合する能力、（６）開発者に関して、再利用可能モジュールを作成し、それによって生産性を向上させ、プログラミングエラーの数を低減する能力、および（７）他のクロスプラットフォームおよび言語統合機能も提供する。

コンピューティング装置上に常駐するアプリケーションプログラミングインターフェース（ＡＰＩ）などのソフトウェアに関連していくつかの例示的実施形態を本明細書で説明したが、本発明の１つまたは複数の部分をオペレーティングシステム、または「ミドルマン」オブジェクト、制御オブジェクト、ハードウェア、ファームウェア、中間言語命令またはオブジェクトなどを介して実装することもでき、それによって、本発明によるポリシーモデルにわたって変換する方法を、．ＮＥＴコードなどの管理コードによって使用可能にされる言語およびサービスのすべて、および他の分散コンピューティングフレームワークの中に含めることもでき、その中でサポートすることもでき、またはそれを介してアクセスすることもできる。

例えば、アプリケーションおよびサービスが本発明のポリシーモデルにわたって変換するシステムおよび方法を使用することを可能にする適切なＡＰＩ、ツールキット、ドライバコード、オペレーティングシステム、コントロール、スタンドアロン型またはダウンロード可能ソフトウェアオブジェクトなど、本発明を実装する複数の方式がある。本発明は、ＡＰＩ（または他のソフトウェアオブジェクト）の観点ならびに本発明によるダウンロードされたプログラムを受け取るソフトウェアまたはハードウェアオブジェクトの観点から本発明の使用を企図する。したがって、本明細書に記載の本発明の様々な実装は、完全にハードウェアである態様、部分的にハードウェア、部分的にはソフトウェアである態様、ならびにソフトウェアの態様を有することができる。

上述のように、本発明の例示的実施形態を様々なコンピューティング装置およびネットワークアーキテクチャに関連して説明したが、基礎となる概念を、あるアクセスポリシーモデルから別のアクセスポリシーモデルに変換することが望ましい任意のコンピューティング装置またはシステムに適用することができる。例えば、本発明のアルゴリズムおよびハードウェア実装を、装置の別々のオブジェクトとして設けられた、別のオブジェクトの部分として設けられた、再利用可能制御として設けられた、サーバからダウンロード可能オブジェクトとして設けられた、装置またはオブジェクトとネットワークの間の「ミドルマン」として設けられた、分散オブジェクトとして、ハードウェアとして設けられた、メモリ内に設けられた、上記のいずれかの組合せとして設けられたコンピューティング装置のオペレーティングシステムに適用することができる。例示的プログラミング言語、名前、および例は本明細書で様々なの選択肢の代表として選ばれるものであって、こうした言語、名前、および例は限定的なものであることが意図されるわけではない。本発明の様々な実施形態によって達成されるのと同一の機能、類似の機能、または等価な機能を達成するオブジェクトコードおよび用語を提供する多数の方式があることを当業者は理解されよう。

上述のように、本明細書に記載の様々な技法をハードウェアまたはソフトウェア、あるいは適切な場合はその両方の組合せと共に実装することができる。したがって、本発明の方法および機器、またはそのいくつかの態様または部分は、フロッピィディスケット、ＣＤ−ＲＯＭ、ハードドライブ、または他の任意の機械可読記憶媒体などの有形媒体内に実施されたプログラムコード（すなわち命令）の形態を取ることができ、プログラムコードがコンピュータなどのマシンにロードされ実行されたときに、そのマシンが本発明を実施するための装置となる。プログラム可能コンピュータ上のプログラムコード実行のケースでは、コンピューティング装置は一般に、プロセッサ、プロセッサで読取り可能な記憶媒体（揮発性および不揮発性のメモリおよび／または記憶素子を含む）、少なくとも１つの入力装置、および少なくとも１つの出力装置を含む。例えばデータ処理ＡＰＩ、再利用可能制御などを使用することによって本発明のポリシーモデルにわたって変換する方法を実装または利用することのできる１つまたは複数のプログラムは、コンピュータと通信するために高水準の手続き型プログラミング言語またはオブジェクト指向プログラミング言語で実装されることが好ましい。しかし、望むならアセンブリ言語または機械語でプログラムを実装することもできる。いずれにしても、言語はコンパイル型言語またはインタプリタ型言語でよく、ハードウェア実装と組み合わせることができる。

本発明の方法および装置は、電気配線またはケーブル、光ファイバ、あるいは他の任意の形態の伝送などの、何らかの伝送媒体を介して伝送されるプログラムコードの形で実施された通信を介して実施することでき、プログラムコードが、ＥＰＲＯＭ、ゲートアレイ、プログラマブルロジックデバイス（ＰＬＤ）、クライアントコンピュータなどのマシンで受信され、ロードされ、実行されるとき、マシンは本発明を実施する機器になる。汎用プロセッサ上に実装されるとき、プログラムコードがプロセッサと組み合わさり、本発明の機能を起動するように動作する固有の装置を提供する。さらに、本発明に関連して使用される任意の記憶技法は常にハードウェアとソフトウェアの組合せでよい。

様々な図の好ましい実施形態と共に本発明を説明したが、本発明から逸脱することなく、他の類似の実施形態を使用することができ、あるいは本発明と同じ機能を実施するために記載の実施形態に修正および追加を行うことができることを理解されたい。例えば、本発明の例示的ネットワーク環境がピアツーピアネットワーク環境などのネットワーク環境の状況で説明されたが、本発明はそれに限定されず、有線であってもワイヤレスであっても、ゲーミングコンソール、ハンドヘルドコンピュータ、ポータブルコンピュータなどの任意のコンピューティング装置または環境に本願に記載の方法を適用でき、通信を介して接続され、ネットワークを介して対話する任意の数のそのようなコンピューティング装置に本願に記載の方法を適用できることを当業者は理解されよう。さらに、特にワイヤレスネットワーク装置の数が引き続き急増するにつれて、ハンドヘルド装置オペレーティングシステムおよび他のアプリケーション特有のオペレーティングシステムを含む様々なコンピュータプラットフォームが企図されることが強調されるべきである。

例示的実施形態は、特定のプログラミング言語構成の状況で本発明を使用することを参照するが、本発明はそのように限定されるわけではなく、本発明を任意の言語で実施して、ポリシーモデルにわたって変換する方法を提供するこことができる。さらに、本発明を複数の処理チップまたは装置内に、または複数の処理チップにわたって実装することができ、ストレージを複数の装置にわたって同様に実施することができる。したがって、本発明が何らかの単一の実施形態に限定されるべきではなく、添付の特許請求の範囲による広さおよび範囲で解釈されるべきである。

本発明に従って定義されたＲＢＡＣシステムの概要のブロック図である。 本発明に従って定義されたＲＢＡＣシステムに関する役割の例示的作成のブロック図である。 本発明によるＲＢＡＣポリシーの作成、ＲＢＡＣポリシーの更新、およびＲＡＰ構造への変換を示す例示的流れ図である。 本発明のＲＢＡＣポリシー定義によるアプリケーション資源に基づく企業役割および範囲の関係を示すブロック図である。 本発明によるＲＢＡＣポリシーの作成、および本発明によるアクセス制御リスト（ＡＣＬ）への対応する自動変換の例示的非限定的流れ図である。 ＡＣＬを使用する権限システム内のアクセス制御エントリ（ＡＣＥ）の資源ごとのアプリケーションを示す例示的ブロック図である。 本発明を実装することのできる例示的ネットワーク環境を表すブロック図である。 本発明を実装することのできる例示的非限定的コンピューティングシステム環境を表すブロック図である。

Claims (21)

1. ネットワークコンピューティング環境内で役割ベースのアクセス制御ポリシーをオーサリングする方法であって、
   少なくとも１つの範囲を定義するステップであって、各範囲が、前記ネットワークコンピューティング環境内の１組の資源を表すステップ（５１０）と、
   所与の範囲内のプリンシパルに割り当てられる１組の許可をそれぞれ含む、少なくとも１つのアプリケーション役割を定義するステップ（５００）と、および
   組織識別管理システム内のプリンシパルの少なくとも１つの資源グループを定義するステップであって、前記少なくとも１つの資源グループのメンバのそれぞれが、前記少なくとも１つの範囲のうちの範囲と前記少なくとも１つのアプリケーション役割のうちのアプリケーション役割とに従って、特定の資源へのアクセスのために指定されるステップ（５２０）と
   を含む方法。
2. 前記資源グループの対応する範囲およびアプリケーション役割に基づいて前記少なくとも１つの資源グループに対する許可を授与または拒否するステップをさらに含む請求項１に記載の方法。
3. 前記少なくとも１つの範囲、前記少なくとも１つのアプリケーション役割、および前記少なくとも１つの資源グループを、資源許可ポリシーモデルに対応する許可に変換するステップをさらに含む請求項１に記載の方法。
4. 前記少なくとも１つの範囲、前記少なくとも１つのアプリケーション役割、および前記少なくとも１つの資源グループを、資源許可ポリシーモデルに対応するデータ構造に変換するステップをさらに含む請求項１に記載の方法。
5. 前記少なくとも１つの範囲、前記少なくとも１つのアプリケーション役割、および前記少なくとも１つの資源グループを変換し、アクセス制御リスト（ＡＣＬ）およびアクセス制御エントリ（ＡＣＥ）に基づいて資源許可ポリシーモデルのＡＣＬおよびＡＣＥデータ構造に変換するための変換情報を形成するステップをさらに含む請求項４に記載の方法。
6. ＡＣＬおよびＡＣＥに基づく資源許可ポリシーモデルがＷｉｎｄｏｗｓ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｍａｎａｇｅｒ（ＡｚＭａｎ）である請求項５に記載の方法。
7. 前記情報を前記ネットワークコンピューティング環境のアクセス制御リスト（ＡＣＬ）およびアクセス制御エントリ（ＡＣＥ）データ構造に伝播するステップをさらに含む請求項５に記載の方法。
8. プリンシパルの前記少なくとも１つの資源グループを定義する前記ステップが、前記ネットワークコンピューティング環境内で動作する組織に関連する既存のメンバシップグループを選択するステップを含む請求項１に記載の方法。
9. 前記既存のメンバシップグループが変化したときに前記少なくとも１つの資源グループを更新するステップをさらに含む請求項８に記載の方法。
10. プリンシパルの前記少なくとも１つの資源グループを定義する前記ステップが、前記組織に関連するＥメールグループまたは配布リストを選択するステップを含む請求項９に記載の方法。
11. 前記少なくとも１つの範囲のうちの範囲が、オペレーティングシステムのファイルシステムによって編成される１つまたは複数のファイル、フォルダ、または他のオブジェクトの集合として定義される請求項１に記載の方法。
12. 範囲に関連する１組の資源が変化したとき、前記少なくとも１つの範囲を更新するステップをさらに含む請求項１に記載の方法。
13. 請求項１に記載の方法を実施するコンピュータ実行可能命令を有するコンピュータ実行可能インターフェースモジュールを含むアプリケーションプログラミングインターフェース。
14. ネットワークコンピューティング環境内でアクセスを制御する役割ベースのアクセス制御ポリシーデータを格納するコンピュータ可読媒体であって、
    少なくとも１つの範囲を表す範囲データを含む第１データ構造であって、各範囲が、前記ネットワークコンピューティング環境内の１組の資源を表す第１データ構造（３１０）と、
    所与の範囲内のプリンシパルに割り当てられる１組の許可をそれぞれ含む、少なくとも１つのアプリケーション役割を定義する役割データを含む第２データ構造（３００）と、
    組織識別管理システム内のプリンシパルの少なくとも１つの資源グループを定義するグループデータを含む第３データ構造であって、前記少なくとも１つの資源グループのメンバのそれぞれに、前記少なくとも１つの範囲のうちの範囲と前記少なくとも１つのアプリケーション役割のうちのアプリケーション役割とに従って、特定の資源へのアクセスが授与または拒否される第３データ構造とを含み、
    前記第１、第２、および第３データ構造が、資源６００ａ〜Ｎごとに許可ポリシーを適用する資源許可ポリシーに関連するデータ構造への所定のマッピング機能に従ってマッピング可能であるコンピュータ可読媒体。
15. 前記資源許可ポリシーが、アクセス制御リスト（ＡＣＥ）データ構造を基本資源権限として含む資源許可ポリシーである請求項１４に記載のコンピュータ可読媒体。
16. 前記第１、第２、および第３データ構造をオーサリングするコンピュータ実行可能モジュールをさらに含む請求項１４に記載のコンピュータ可読媒体。
17. 前記第１、第２、および第３データ構造を前記資源許可ポリシーに関連する前記データ構造に変換するコンピュータ実行可能モジュールをさらに含む請求項１４に記載のコンピュータ可読媒体。
18. 前記第１、第２、および第３データ構造を前記資源許可ポリシーに関連する前記許可に変換するコンピュータ実行可能モジュールをさらに含む請求項１４に記載のコンピュータ可読媒体。
19. 資源許可ポリシーに基づく権限を含むネットワークコンピューティング環境内で実施されるべき役割ベースのアクセス制御ポリシーを作成するオーサリングツールであって、
    前記ネットワークコンピューティング環境内の１組の資源をそれぞれ表す、少なくとも１つの範囲を定義する手段（５１０）と、
    所与の範囲内のプリンシパルに割り当てられる１組の許可をそれぞれ含む、少なくとも１つのアプリケーション役割を定義する手段（５００）と、
    組織識別管理システム内のプリンシパルの少なくとも１つの資源グループを定義する手段であって、前記少なくとも１つの資源グループのメンバのそれぞれが、前記少なくとも１つの範囲のうちの範囲と前記少なくとも１つのアプリケーション役割のうちのアプリケーション役割とに従って、特定の資源へのアクセスのために指定される手段（５２０）と
    を含むオーサリングツール。
20. 前記資源グループの対応する範囲およびアプリケーション役割に基づいて前記少なくとも１つの資源グループに対する許可を授与または拒否する手段をさらに含む請求項１９に記載のオーサリングツール。
21. 前記少なくとも１つの範囲、前記少なくとも１つのアプリケーション役割、および前記少なくとも１つの資源グループを、前記資源許可ポリシーモデルに対応する許可に変換する手段をさらに含む請求項２０に記載のオーサリングツール。

Images