JP5346010B2 - ポリシー管理基盤 - Google Patents

Description

本発明は、コンピュータ実行型のポリシー管理方法に関する。

コンピュータ関連企業は一般に、互いに相互作用する様々なコンピューティング・コンポーネント（ｃｏｍｐｕｔｉｎｇ ｃｏｍｐｏｎｅｎｔ）を有する。係るコンピューティング・コンポーネントは、１つまたは複数のネットワーク、アプリケーション、サービス、およびシステムを含むことがある。コンピュータ関連企業ではしばしば、個々のコンポーネントと複数のコンポーネントから成るグループとを管理および制御するためのポリシーが実装されている。例えば、あるシステムが別のシステムに対して有するアクセス権を制限するためのネットワーク・セキュリティ・ポリシーがしばしば使用される。

幾つかの事例では、ポリシーは人を、少なくともその人が個人または複数のコンピューティング・コンポーネントから成るグループと相互作用することに関して、間接的に管理および制御する。例えば、セキュリティ・ポリシーを特定のユーザと関連付けて、係るユーザがどのシステムからアクセスするかに関わらず、係るユーザが同じシステムおよびデータにアクセスできるようにすることができる。

本明細書の文脈で特に明記しない限り、本明細書では「ポリシー」は、コンピューティング・コンポーネント（または複数のコンポーネントから成るグループ）がどのようなものであるべきか、またはどのように振る舞うべきかの宣言的な記述を指すと理解すべきである。ポリシーは命令の手続き的リストではない。さらに、本明細書では「ポリシー」を、１つもしくは複数のコンポーネントの状態の述語、および／または１つもしくは複数のコンポーネントの振る舞いの述語と理解することができる。さらに、「ポリシー」は専ら、１つまたは複数のコンポーネントによって実行される動作を対象とする。一般に、ポリシーは管理すべきものを対象とする。

ポリシー・ベースの解決策はしばしば、コンピュータ関連企業における複雑性、規模およびダイナミクスを管理する中核を成している。しかし、従来のポリシー・ベースのアプローチは、様々なコンピュータ関連企業において見出される多様な特定のシナリオにわたっては不十分であり、断片化している。典型的なシナリオの例には、デプロイメント、セキュリティ、ネットワーク、および記憶装置の管理がある。

普遍的なポリシー言語は存在しない。一般に、各特定のシナリオ（例えば、データ保護またはファイアウォール）には、独自の特化したポリシー言語、構文、意味、ポリシー作成ユーザ・インタフェース、および特性を使用した独自のポリシー・ベースの解決策がある。

今日まで、様々なコンピュータ関連企業において見出される多様なシナリオを全体的に管理するための要件の全てをサポートする、普遍的なポリシー・ベースの解決策は存在しない。

本明細書では、コンピュータ環境における多様なシナリオにわたって普遍的なポリシー・ベースの解決策を提供する、ポリシー管理基盤の１つまたは複数の実装形態を説明する。ポリシー管理基盤の少なくとも１つの実装形態では、ポリシー・ベースのデータが他の階層のデータに対してどのように構造化または階層化されるかを定義する。さらに、説明した実装形態では、ポリシーの「重複」および「衝突」を決定する機構を提供する。

本概要は、選択した概念を簡潔な形で導入するために提供している。その概念は、後の［発明を実施するための形態］でさらに説明する。本［発明の概要］は、特許請求の範囲の主題の主要な特徴または本質的な特徴を特定しようとするものではなく、特許請求の範囲の主題の範囲の決定を支援するために使用しようとするものでもない。

図面全体にわたって、同様の要素および同様の機能を参照するために同じ番号を使用している。

本明細書で説明するポリシー管理基盤の１つまたは複数の実装形態をサポートする例示的なシナリオを示し、かつポリシー管理基盤の論理的構成も示す図である。 本明細書で説明する方法論的な実装形態の流れ図である。

典型的なシナリオでは、ポリシーはサービス（または、より厳密に言うと、そのサービスのモデル）を対象とし、当該ポリシーを、当該サービスを構成する様々なシステムに適用し、適合させる。対象システムに直接、変更が加えられ、または変更が試みられても、システムが当該ポリシーに従うように、または当該ポリシーとの任意の不一致が決まるように、ポリシーを対象システムに適用し、適合させる。しかし、様々なシナリオに対して多様な種類のポリシー・ベースの解決策があり、それらのシナリオの下で当該解決策を適用することができる。

本明細書では、様々なコンピュータ関連企業において見出される多様なシナリオを全体的に管理するための要件の全てをサポートする普遍的なポリシー・ベースの解決策に対する、１つまたは複数の実装形態を説明する。本明細書で説明する普遍的なポリシー・ベースの解決策は、ポリシー・ベースのデータが他の階層のデータに対してどのように構造化または階層化されるかを定義するポリシー管理基盤を提供する。

一般に、このポリシー管理基盤（すなわち、アーキテクチャ）はドメイン全体にわたって共通で共有されるポリシーの態様を利用する。より詳細には、当該基盤は多種多様のポリシーによって共通して参照される幾つかの典型的な名前空間を利用する。これらのポリシーは、（限定ではなく例として）以下のような様々なシナリオで使用される。
・ ソフトウェアデプロイメント
・ パッチング
・ 構成管理
・ 脆弱性評価
・ データ保護（バックアップ）
・ データ保持
・ 認証
・ 承認
・ 監査
・ 情報保護（ＤＲＭ）
・ 侵入検出
・ 侵入防止
・ アンチ・マルウェア
・ ファイアウォール
・ ネットワーク・アクセス保護
・ 健全性監視
・ サービス・レベル監視
・ 負荷分散
・ 在庫
・ ライセンス管理
・ 利用量測定
・ 分離境界上でのコンテクスト共有
・ タスク実行およびジョブ実行
・ 災害復旧
・ 作業負荷管理
・ リソース管理
・ オンデマンド・リソース割当て
・ 電源管理および冷却管理
・ 変更管理およびワークフロー
・ 配布管理およびリリース管理

このポリシー管理基盤は、普遍的なポリシー言語ではなく、既存のドメイン固有のポリシー・ベースの解決策を合理化し、各特定のシナリオ（例えば、データ保護またはファイアウォール）に対する解決策と協調する。この合理化は、少なくとも部分的には、特定した共通名前空間を当該基盤が利用することによって、および普遍的なメタ・ポリシーを定義することによって、達成される。

メタ・ポリシーはポリシーの振る舞いを制御する。メタ・ポリシーは、１つまたは複数のポリシーをどのように、いつ、どこで適用および管理すべきかを宣言的に記述するものである。すなわち、メタ・ポリシーはポリシーのポリシーである。

本明細書中の用語として、システムは１つまたは複数のコンピューティング・コンポーネントであり、モデルはシステム、その構成要素およびその構成要素の関係を記述し、ポリシーはシステムの見え方と振る舞い方を述べ、ポリシーはモデルに適用され、それ故、実世界のシステムに適用され、メタ・ポリシーはポリシーがどのように適用および管理されるかを記述する。

ポリシー管理基盤
図１は、本明細書で説明する１つまたは複数の実装形態に従うポリシー管理基盤１００の配置構成を示す。ポリシー管理基盤１００は、ポリシー管理システム１１０と、数層のメタ・ポリシー１２２および関連するサポート用の共通名前空間１２４を含むポリシー管理データ・モデル１２０とを含む。ポリシー管理システム１１０は、本明細書で説明するポリシー管理基盤１００に基づいてポリシー管理向けのロジックを実行する１つまたは複数のプログラム・モジュールである。ポリシー管理データ・モデル１２０は、本明細書で説明するポリシー管理基盤１００内部のデータの編成と関係を定義する。

図示したように、ポリシー管理システム１１０およびポリシー管理データ・モデル１２０は、コンピュータ１３２のメモリ１３０内部で記憶および／または処理される。コンピュータ１３２は一般に、（メモリ１３０を含む）様々なプロセッサ可読媒体を含む。係る媒体は、コンピュータ１３２によってアクセス可能な任意の使用可能媒体であり、揮発性および不揮発性媒体と、取外し可能および取外し不能媒体の両方を含む。コンピュータ１３２は、１つまたは複数の他のネットワーク・コンピュータ１３４に接続することができる。これらのネットワーク・コンピュータはポリシーの対象ノードになることができる。

ポリシー管理基盤１００を使用して、ポリシー管理システム１１０は幾つかの目的のためにポリシー上で推論を行う。例えば、ポリシー間の衝突は、推論が必要となる一般的な状況である。例えば、アリスがファイアウォールを起動すると言い、スーパー管理者であるボブがファイアウォールを停止すると言い、これらのポリシーが同じシステムに同時に適用されれば、ポリシー管理システム１１０は（ポリシー管理基盤を使用して）衝突を検出し、アリスに彼女のポリシーが無効にされたことを通知する。逆に、アリスのポリシーが有効であり、ボブがポリシーを有効にした場合、ボブには彼がアリスに何をしたかを伝えるべきである。

適用範囲の検証は、ポリシー管理システム１１０がポリシー上で推論するための別の良い理由である。基盤を使用すると、ポリシー管理システム１１０は、ポリシーが各リソースに対して全ての時点で有効であることを検証することができる。影響分析は、ポリシー管理システム１１０がポリシー上で推論するための別の良い理由である。ある人がポリシーを変更した場合、基盤はどのシステムが影響を受けるかの判定を支援することができる。例えば、隔離されているセキュリティ・ポリシーにある人が変更を加えた場合、何人のユーザが明日の朝に企業内ネットワークにログインできなくなるか、それらのユーザのうち何人が部長であるか、ということについてである。

メタ・ポリシー階層
図示したように、ポリシー管理データ・モデル１２０は、例えば、１０個の階層的に順序付けて層状にしたメタ・ポリシーを含む（下層から上層に向かって列挙してある）。
・ 第０層：実現マッピング１４０
・ 第１層：ドメイン固有ポリシー１４１
・ 第２層：管理１４２
・ 第３層：マージおよび衝突解決１４３
・ 第４層：有効なスケジュールおよび条件１４４
・ 第５層：適用性および適応化１４５
・ 第６層：一貫性１４６
・ 第７層：ターゲッティングおよび配布１４７
・ 第８層：リリースおよび実施１４８
・ 第９層：変更および承認ワークフロー１４９

ある層のメタ・ポリシーがそれより低い番号の層のメタ・ポリシーにのみ影響しうるということを基礎として、階層の順序付けを行う。例えば、いったんターゲッティング（すなわち、第７層）を行うと、ポリシーが特定の１組のコンピュータに適用されることが分かる（ここで、「適用される」は、ある一般的な意味でのターゲッティングが該当することを意味し、様々なものが可能である）。この情報を使用して、ポリシー管理システムは、これらのコンピュータに対してのみ、適用性メタ・ポリシー（すなわち、第５層）を評価して、例えばこれらのコンピュータにはあるソフトウェアがインストールされているという理由で、ポリシーがこれらのコンピュータに適用されるかどうかを判定する。この順序付けの利益には以下が含まれる（がこれらに限らない）。
・ 処理の効率性：上の例では、ターゲッティングにより適用性を評価すべきコンピュータの数が削減される。ターゲッティングを、一般に集中データベースおよびディレクトリ内の情報に基づいて効率的に決定することができ、一方で適用性では一般に各コンピュータを訪問する必要がある。同様に、有効なスケジュールおよび条件（すなわち、第４層）は一般に、各コンピュータ上で継続的に評価されなければならない。なぜならば、コンピュータは移動可能であり、条件は、コンピュータが様々なネットワークおよび装置に接続されると、および時間が経つと、変化するからである。一般に、この評価は、ポリシーが適用可能である場合に限り、対象コンピュータ上で行われる。各管理されたコンピュータ上でローカル時間を追跡しようとすることは明らかに効率が悪く、そうするとポリシー管理システムのスケーラビリティが制限されることになるだろう。
・サーバ側のポリシー管理基盤と管理されたシステム上のローカル処理の間の作業分担：中央の基盤によって処理することができ、そうされているポリシーもあれば、ローカル・マシン上で処理することができ、そうされているポリシーもある。このように作業を分担するにはポリシーを正確に順序付けることが必要である。コンピュータが接続されているネットワーク、およびＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）スティックといった接続されている取外し可能装置のような環境条件を、中央サーバ・システム内で対象コンピュータ毎に評価しようすることは、コンピュータが断続的に切断する可能性があるので、現実的に不可能である。したがって、スタック内の階層は、サーバ上で評価すべき全てのポリシーに、管理されたシステム上で評価すべきポリシーよりも高い番号が与えられるように、順序付けられるべきである。この概念を複数の階層に汎化することができる。すなわち、１つの解決策では、変更管理、実施、およびリリースが第９層および第８層のメタ・ポリシーの制御下で行われる中央のシステムおよびデータベースをもたせることができる。ポリシーは、地球規模の複製と高可用性の特徴を提供する配布基盤にリリースされ、ターゲッティング（すなわち、第７層）はこの基盤によって処理される。それより低層のメタ・ポリシーは各管理されたノードで処理される。繰り返すが、正確な順序付けは、メタ・ポリシーの意味を保存しつつこの処理割当てを可能とするために必須である。

これらの利益は、ポリシーの適用だけでなく、衝突や適用範囲のような分析にも当てはまる。もちろん、他の実装形態では異なる１組の階層を使用してもよく、異なる要件に対処するためにそれらの階層の順序を変えてもよい。

第０層：実現マッピング
このメタ・ポリシーによって管理されるポリシーに対して、この層の各抽象概念は実環境における実現にマッピングされる。これは、（実環境が現在どのように構成されているかを見つけるための）探索と、同期（実環境が正確に設定されていない場合にどのように実環境を正確に設定するか）の仕様を通して行うことができる。例えば、ドメイン固有ポリシー（すなわち、第１層）は認証技術と呼ばれる抽象的な設定を参照することができ、実現マッピング（すなわち、第０層）はこの設定が置かれているレジストリ・キーを規定する。

１つまたは複数の実装形態では、宣言的な探索および同期の仕様を使用することができ、当該実装形態は、レジストリ・キーの設定からインストールの実行またはＶＭ（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）のデプロイまで、最も一般的な種類のポリシー項目を扱うことができる幾つかの標準エンジンを提供することができる。係る宣言的な仕様は、例えば、特定の位置を示すユニフォーム・リソース識別子と組み合わせてポリシーを受け取るべき、レジストリのようなソフトウェア・システムの仕様を含むことができる。１つまたは複数の実装形態は、スクリプト作成のような、手続き的な同期および探索をサポートすることができる。多くの場合、このマッピングは単純に、ポリシーをポリシー・コンシューマへ渡すことを記述する。

物理的な実現をドメイン固有ポリシーから切り離す１つの利点は、影響を受けた機能が特定のシステム上で実装される方法とは独立に、ドメイン固有ポリシーを抽象的に表現できることである。これは、ポリシーを、異なる実装形態を有する新しいバージョンのシステムに容易に適応させうることを意味する。例えば、セキュリティ・ポリシーは複雑な表現を含むことがあるが、コンピュータ・システムを、セキュリティ関連の設定が別々の位置、恐らくレジストリではなくデータベースに見出されるように修正すると、複雑なセキュリティ・ポリシー自体ではなく比較的単純な実現メタ・ポリシーのみを修正しなければならない。これは、異なる専門性を有する人達がポリシーの別々の部分を保守できることも意味する。例えば、セキュリティの専門家は認証に関するポリシーを指定することができ、セキュリティの複雑性をほとんど理解していない下位のスタッフ・メンバは、ソフトウェアのバージョンアップ時に物理的な実現メタ・ポリシーを編集することができる。また、単純に別の実現マッピングのメタ・ポリシーを適用することによって、単一のドメイン固有ポリシーを、別の実現を有する別のシステムに適用するように容易に調整できることも意味する。もちろん、全てのこれらの利益は、異なるシステムまたは異なるバージョンのシステムが一貫した意味を有して、したがってドメイン固有ポリシーを有意に適用できる場合に限り得られる。

第１層：ドメイン固有ポリシー
この層は、様々なドメイン固有ポリシーの仕様を詳細に記述する。この層自体はメタ・ポリシーではない。この層は（メタ・ポリシーの定義である）ポリシーのポリシーではなく、１つまたは複数の実際のポリシーである。１つまたは複数の実装形態では、ポリシーが体系化される。各ドメイン固有ポリシーの詳細が表現される限り、その詳細を表現する厳密な方法は実装形態の詳細次第である。

第２層：管理
多くのポリシーはポリシー・コンシューマに渡され、結果としてポリシーはポリシー・コンシューマによって実施される。したがって、ポリシー管理基盤の実装形態では、ポリシーがポリシー・コンシューマに渡った後は当該ポリシーを管理する必要はない。ポリシー・コンシューマの例には、リソース・マネージャ（例えば、ファイル・システム内のアクセス制御）またはサービス（例えば、バックアップ）がある。

しかし、リソース・マネージャがポリシーを認識しないために実施されないポリシーもある。例えば、幾つかのＯＳ（ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）はブラックリストのソフトウェアの実行を防止できない。なぜならば、ＯＳはそのようなことを行うための機構を提供しないからである。ポリシーが技術的に実施可能であっても、当該ポリシーを、実施されないが監視されるとして記録しておくことが望ましいであろう。なぜならば、厳密な実施は所与の状況に対しては重圧となり過ぎる場合があるからである。例えば、ミッション・クリティカルなサーバの構成が適合しなくなると、ＩＴスタッフは、構成の変更には妥当だが未知の理由があったかもしれないので、構成の復元前に変更の原因を調査したいかもしれない。そして、例えば、システムが保守中またはサービス中であるとき、一時的にポリシーの実施を無効にすることが望ましい場合もある。

ポリシー管理基盤の実装形態では、単に実施義務をポリシー・コンシューマに渡すのではなく、この層のデータを使用してポリシーを明示的に管理する。このメタ・ポリシーは有効なポリシーをどのように管理すべきかを定義する。例えば、このメタ・ポリシーは、ポリシー準拠の検証、非準拠に対する応答（例えば、是正処置、警告、レポート）を引き起こして、保守のためにポリシーを一時的に無効化するスケジュールまたはイベントを管理することができ、許容パラメータを調整することができる。

ポリシー管理基盤内部で、このメタ・ポリシー層は一般的な管理用の下位基盤を管理されたノードに提供する。この一般的な管理用の下位基盤は準拠監視、改善、レポートおよび警告を提供する。

第３層：マージおよび衝突解決
数個のポリシーが衝突することは珍しいことではない。同じ管理ドメインの複数のポリシーが同じシステム上の全く同じリソースに同時に有効である場合もある。以下は、係る衝突の例である。
・ 部署の管理者がファイアウォールを停止しようとし、セキュリティ管理者が当該ファイアウォールを起動しようとする。
・ アプリケーションがファイアウォールを停止する必要があり、セキュリティ管理者が当該ファイアウォールを起動しようとする。
・ ２つのアプリケーションが、ＯＳの設定に関して衝突する要求を行う。
・ セキュリティ・ポリシーが再起動を要する構成変更を緊急に行おうとし、サービス中のウィンドウ・ポリシーが作業時間中の再起動を禁止する。

このメタ・ポリシーは、ポリシーをマージし、かつ／または衝突を解決するためのアプローチを定義する。一般に、このアプローチは「ＲＳＯＰ（Ｒｅｓｕｌｔａｎｔ Ｓｅｔ ｏｆ Ｐｏｌｉｃｉｅｓ）の計算」と呼ばれることがある。明らかな衝突に直面した場合、このメタ・ポリシーはこの明らかな衝突に対する解決（またはＲＳＯＰ）を定義することができる。以下は、可能な解決オプションの幾つかの例である。
・ マージ・ポリシー不要：このオプションは、一般的なメタ・ポリシーで表現できない複雑な解決アルゴリズムをリソース・マネージャが有する場合にも使用される。
・ 明示的な委譲：マスタ管理者が全てのものを所有する場合、その管理者は明示的に権限を委譲し、衝突に対するマージ・ポリシーを指定する。
・ 発行者権限（「ストライプ・オン・ザ・ショルダー（ｓｔｒｉｐｅｓ ｏｎ ｔｈｅ ｓｈｏｕｌｄｅｒ）」：委譲連鎖を追跡できない場合に有用である。
・ 特異性：最大スコープ（企業のポリシーを優先）または最小スコープ（最も具体的 なポリシーを優先）で定義されたポリシーを使用。
・ 最も限定的なポリシーまたは最も限定的でないポリシーを優先。
・ 妥当な範囲またはスケジュールの共通部分の計算（例えば、あるサーバが４つのサービスをホストし、各サービスがサービス中のウィンドウを伴うとき、当該サーバはそれらのサービス中のウィンドウの共通部分を得る）。
・ 警告：ポリシーのマージは試みず、ＩＴスタッフに衝突を警告する。

このメタ・ポリシーにより、明らかなポリシーの衝突に関与する他の複雑性を取り扱うことができる。例えば、ポリシー・マージの粒度を解決する必要があるかもしれない。完全なポリシーの１つを無効とすることによって衝突を解決することができる。あるいは、システムはステートメント毎に優先するポリシーを選択することができる。

第４層：有効なスケジュールおよび条件
様々なポリシーが様々な時点で有効であることは普通である。例えば、ＨＲ（Ｈｕｍａｎ Ｒｅｓｏｕｒｃｅｓ）スタッフは、作業時間中はＨＲアプリケーションにアクセスすることができるが、夜にはアクセスできない。このメタ・ポリシーは、ポリシーに対する有効なスケジュールを定義する。このメタ・ポリシーは、カレンダで表現したスケジュールに対する共通のスキーマを定義する。例えば午前９時から午後５時の作業時間スケジュールを作業日のスケジュールと組合せ、祝日のスケジュールに入る日を除外することによって、複数のスケジュールを合成できるようにすることが有用な実施である。

多くのポリシーは、周囲の状態に対する述語として表現される条件を含む。例えば、ＨＲスタッフは、会社の自分のデスクトップに強力な証明書（例えば、スマートカード）でログオンするとＨＲアプリケーションにアクセスでき、ラップトップを企業内ネットワークに接続するとあるデフォルトのプリンタを使用でき、家で接続すると違うデフォルトのプリンタに接続することができる。係る条件に対する共通のスキーマを使用するのではなく、当該条件を名前空間上の論理表現として定義することができる。これらの条件はポリシー中の状態述語のように見える。これらの条件をこのメタ・ポリシーに対して抽出するとき、条件の汎化単位を、ドメイン固有ポリシー言語全体にわたって再利用するために表現することができる。例えば、「強く認証されている」をこのメタ・ポリシーに置くことによって、強い認証に依存する全てのドメイン・ポリシーを、ドメイン固有言語を解析することなく特定することができる。

第５層：適用性および適応化
適用性メタ・ポリシーは、ポリシーがどの対象システムに実際に適用されるかを決定することによってターゲッティングを改良する。例えば、ＳＱＬポリシーはＳＱＬを有するマシンにのみ適用されるべきである。これは、システム管理者が様々な種類のシステムを含むサービスをポリシーの対象とすることができるので、有用である。この状況では、管理システムは適用性メタ・ポリシーを使用して、この不均一な構造内部でポリシーがどこに適用されるかを決める。管理システムはまた、ポリシーを自己適応的にする。例えば、以前は有効でなかったポリシーが、ＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）装置をラップトップに差し込んだときに適用可能となることができる。

このメタ・ポリシーはまた、限定的な形のモデル適応化をサポートすることができる。ポリシー選択は、幾つかの関連ポリシー、例えば、ファイル・サーバ上のデータ保護向けのポリシー、データベース・サーバ向けのポリシー、メール・サーバ向けのポリシーがあるときに使用される。これらの幾つかのポリシーが一貫するように設計され、１つのサービス内で共に適用されることを目的とする場合、基盤の実装形態では、（ａ）適用性メタ・ポリシーをポリシー毎に定義し、かつ／または（ｂ）それらのポリシーを、サービスで対象となるコンテナ・ポリシーに共にグループ化することができる。適用性メタ・ポリシーは全体としてポリシー適応化メタ・ポリシーを定義する。

モデル適応化は、モデルを実世界に適合させる。ポリシーと無関係に、探索サービスは、どのインスタンスが所与のシステム上にあり、どのインスタンスがローカル・モデルにおいて正確なインスタンスと関係を作成するかを見つける。メタ・ポリシーは、ポリシーがどのようにモデル・インスタンスに適応されるかを定義する。例えば、マシン上には複数のＳＱＬインスタンスがあることがあり、健全性監視ポリシーはＳＱＬインスタンス毎にインスタンス化される。

第６層：一貫性
一般的なやり方では、システム・ポリシーは通常はトランザクション・セマンティックスなしに適用される。その理由の例は以下である。
・ 当該ポリシーを得るシステムはトランザクションをサポートしない。
・ ポリシーは多数の位置で多数のコンピュータ・システムにデプロイされるので、分散トランザクションを地球規模で行うことは極めて困難であると考えられる。
・ コンピュータ・システムには断続的に切断されるものがある。それらのコンピュータ・システムにより、ポリシーの他のコンピュータへのデプロイメントが停滞するであろうため、それらのコンピュータ・システムは分散トランザクションには参加することができない。
・ 協調的なデプロイメントは必要ではなく、各コンピュータ・システムへのベスト・エフォート型のデプロイメントで十分である。

しかし、ポリシーの適用を、トランザクション・セマンティックスを伴って行うことが必要となる場合もある。その理由の例は以下である。
・ 幾つかのポリシーは、漸進的に適用するとシステムが一時的に一貫性のない状態になるので、原子的単位として実質的に単一の時点でデプロイしなければならない内部的に一貫した集合体を形成する。
・ 幾つかのポリシーは、部分的に適用するとシステムが一貫性のない状態になるので、全て一緒に適用されなければならないかまたは全く適用してはならない、内部的に一貫した集合体を形成する。
・ ポリシー適用は別システムにおけるトランザクションの一部でなければならない。例えば、ポリシーがデータベース・クラスタ内の動作の変更を規定すると、その変更はデータベース・トランザクションと調和する必要があるかもしれない。

一貫性メタ・ポリシー層は、どの一貫性要件をポリシーが有するかを、一貫性不要、単一コンピュータ内部での原子的適用、別システム内のトランザクションとの調和、幾つかのコンピュータにわたる原子的適用のようなオプションとともに規定する。

第７層：ターゲッティングおよび配布
ポリシーはしばしば選択的にコンピュータ・システムを対象とし、配信が制御される。以下は、２つの一般的な種類のターゲッティングの例である。
・ 管理グループが均一であると見なされる（「１つのものとしての多数（ｍａｎｙ−ａｓ−ｏｎｅ」管理）。グループはしばしばディレクトリ・サービスに基づくが、管理ツールがコンピュータ・システムの特徴または構成の一覧を取得する「一覧ベースの」ターゲッティング、コンピュータＩＤのリストが明示的に列挙される「列挙的ターゲッティング」、またはそれらの組合せのような、他のソースから入ってくる任意のグループ化もまた有用である。
・ サービス・モデルは不均一と考えられるシステムの構造から構成され、ポリシーはサービス内の各システムに知的に適用される。

ターゲッティングは適用性と協調して行われる。例えば、ＳＱＬを有する本部の全てのシステムにポリシーが適用される場合、この層を使用して、当該ポリシーの対象が本部内の全てのシステムとなり、適用性メタ・ポリシーにその対象グループをＳＱＬシステムへ浸透させるように、実装形態を作成することができる。しかし、ポリシーが全ての製造ＳＱＬシステムに適用される場合、適用性規則によってシステムが製造かまたはテストかを発見できないかもしれず、したがって、ターゲッティングのメタ・ポリシーは製造システムのグループを特定するために使用され、ポリシーをＳＱＬシステムに浸透させる適用性メタ・ポリシーと組み合わされる。

この層はまた、「午前６時までにこれをターゲットに届けよ」または「６時間毎かつネットワーク・ログオン時にポリシーをリフレッシュせよ」というような配布ポリシーを含む。より複雑な配布ポリシーでは、「ローミングしているユーザが、訪問しているサーバ上では利用できないロケールで大規模なソフトウェア・パッケージを必要とする場合、当該パッケージを長距離ネットワークを介して転送せず、そのユーザが通常の場所に戻るまで待機せよ」と述べることができる。しかし、このメタ・ポリシーは、どの配布ポイントをサーバが使用すべきか、帯域幅の割当て、または圧縮技法のような、詳細な配布規則を含む必要はない。これらは、パッケージではなく配布ファブリックに対する、配布上の詳細である。このメタ・ポリシーはスケジュール、優先度および割当量に着目する。

コンピュータ・システムをポリシーの対象とすることに加えて、他の要素、すなわち、ユーザまたはユーザ・グループ、ソフトウェア・アプリケーション、データベース内のデータまたはドキュメント・システムもしくはメール・システム内のドキュメントを対象とするポリシーが多数ある。任意の時点で、これらの対象システムはコンピュータ・システム上に存在するか、またはコンピュータ・システムの制御下にある。そうでない場合、これらの対象システムは、コンピュータ・ベースのポリシーによってカバーされず、本発明の範囲外である。しかし、ポリシーの対象を明示的にコンピュータ・システムとするのではなく、直接、目的のオブジェクトとすることが好ましい。その理由は以下の２つである。

管理者は意図を直接、ユーザ、アプリケーションまたはドキュメントの観点から表すことができ、ポリシー管理システムに、ポリシーを正しい１つまたは複数のコンピュータ・システムに送信する機械的な側面を処理させることができる。これにより管理が簡略化され、レポートおよび分析を有意な言葉で表すことが可能となる。

ユーザ、ソフトウェア・アプリケーション、データおよびドキュメントはしばしば移動可能であり、コンピュータ・システムのネットワーク上で移動し、これらのコンピュータ・システムと一時的かつ薄弱な関係にある。目的のオブジェクトの観点からポリシーのターゲッティングを表現すると、ポリシー管理システムは、正しいコンピュータ・システム上でのポリシーの適用と除去を動的に扱うことができる。

第８層：リリースおよび実施
この層では、ポリシーが所与の日時（例えば、４月４日の午前６時）に適用され、有効期限切れの日付を提供できることが規定される。有効なスケジュールと同様だが、リリースおよび実施のスケジュールは別の目的を果たす。この層は、中央管理組織から推進されるリリース管理に集中し、一方で、有効なスケジュールはポリシー・エンジンによってローカルに解釈され、無期限に有効であることができる。リリース管理は、リッチな管理機能を提供し、その機能には、バージョン管理、監査ログ、ロールバック、および複雑なリリース・ポリシーが含まれる。例えば、新しいポリシーを適用するには再起動、したがってサービス割込みが必要である場合、このメタ・ポリシーは保守ウィンドウを規定することができる。このパッチングに対する共通のリリース・ポリシーは、例えば、「２月２０日から２月２５日までの間の任意の時点で変更を適用するが、ユーザに許可を求めること。変更が２月２５日の真夜中までに行われなかった場合、それ以降の最初の機会にその変更の適用を強制すること」である。

弟３層〜第８層は、全体的なポリシー管理基盤の少なくとも１つの実装形態から成るポリシー配信下位基盤を備える。この下位基盤は、スケジューリングおよびターゲッティング、ならびに大量のペイロードに対する効率的で効果的な伝送を含む。この分散サービスはファブリック内と管理されたノード上の両方に構成要素を有する。管理されたノード上では、この下位基盤は適用性および適用化、ならびにポリシー・マージ（ＲＳＯＰ）を扱う。配信サービスはポリシーを管理されたノードに格納し、当該ポリシーをポリシー・コンシューマに、そのコンシューマが望む任意の形態で渡す。１つまたは複数の実装形態では、この配信サービスは、ポリシーが到着したときに実行されていないサービス、アプリケーションの変更の通知、再起動、および他の例外状況を扱う。

第９層：変更および承認ワークフロー
このメタ・ポリシーは、ポリシーの変更を定義、レビュー、承認、およびデプロイするワークフローを定義する。例えば、このメタ・ポリシーは、例えば範囲、対象、影響、問題のドメインに基づいて誰がポリシー変更を承認できるかを特定する。このメタ・ポリシーはまた、例えば、１次承認者が利用できない場合に他の誰が承認するかを特定することができる。このメタ・ポリシーはまた、例えば、どのタイプの影響分析および衝突分析が必要かを特定することができる。

ポリシー管理基盤内部で、このメタ・ポリシー層はポリシーのライフサイクルを管理する。この層での管理は構成管理データベース（ＣＭＤＢ）と、人間が関与するワークフローとに依存する。ＣＭＤＢは、システムまたは企業内のコンピューティング・コンポーネント、およびこれらのコンポーネント間の関係についての全ての関連情報を含むデータベースである。

他の階層順序付け
このポリシー管理基盤におけるメタ・ポリシーのデータ階層順序付けは、（特に衝突解決のケースでは）様々なメタ・ポリシーの関係を定義する際に貴重な利点をもたらす。しかし、上で提供したものはポリシー管理基盤の１つの実装形態の順序付けに過ぎない。所与の状況に応じて、他のメタ・ポリシーの順序付けが望ましいこともある。

例えば、多数のポリシー・エンジンが有効なスケジュールおよび条件、ならびにマージおよび衝突解決メタ・ポリシーを処理することが全く可能である。このことにより、階層の再配置を正当化することもできるだろう。しかし、これらの機能を一般的な基盤の一部として含めることも依然として望ましいであろうか？このロジックを当該基盤に実装することによって、この能力が欠けているポリシー・コンシューマにロジックを追加することができる。例えば、レジストリとファイアウォールは有効なスケジュールを理解しなくともよい。ポリシー基盤は、作業時間および非作業時間に対して異なるファイアウォール・ポリシーを適用することができる。

しかし、ポリシー基盤をサポートするポリシー・エンジンの場合は、第３層および第４層を管理層（すなわち、第２層）より下の「ポリシー・コンシューマ」分類へ移動させた別の階層構成とすることが望ましいかもしれない。実際には、これを、全てのポリシーを通すスケジュールおよびマージのメタ・ポリシーをもたせることによって達成することができる。

共通名前空間のサポート
図示したように、ポリシー管理データ・モデル１００はまた、関連するサポート用の共通名前空間１２０を含む。係る名前空間の例には、リソース・マネージャによって使用される、スケジュール、ディレクトリ・サービス、システム定義モデル（ＳＤＭ）、および名前空間が含まれる。本明細書で使用するとき、共通名前空間により、ポリシーの多く（または全て）によって共有され、したがってメタ・ポリシーの全てによって共有される共通のコンテクストが提供される。

スケジュール
スケジュールは、多くの目的のためにポリシー・システム（および他所）において使用される。スケジュールに対して、このポリシー管理基盤は共通のスキーマ、スキーマに対する共通のサービスおよび共通の記憶を定義する。以下は係る定義の例である。
・ 有効なスケジュールによってポリシーは、例えば、「ボブはこれらのファイルに作業時間中にアクセスできる」または「このマシンは土曜日の午前３時から４時の間は使用不可となる場合がある」または「主要な取引時間中はこのサービスは要求の９５％に対して３秒未満で応答すべきである」と述べることができる。
・ リリースおよび実施スケジュールは、例えば、「このポリシーは５月１日に有効となる」と述べる。
・ 配信スケジュールは、例えば、「このポリシーは５月１日の午前８時までに配信し、ユーザに提供して承認させ、５月５日の午後８時までにインストールすべきである」と述べる。
・ 監視スケジュールは、例えば、「ネットワーク・ログオン時、ＵＳＢ装置の差込み後、または毎日午前３時に、このポリシーへの準拠を検証すること」と述べる。
・ 定期スケジュールは、期間、すなわち、「祝日を除く毎週月曜日から金曜日の９時から５時」または「当期の最終作業日」のような、原則として時間軸上のブール関数を定義する。スケジュール・サービスによって提供される基本的な機能は、「この時点はこのスケジュールに含まれるか？」である。スケジュールは、様々な方法、すなわち、和集合、積集合、等で構成することができる。スケジュールは期間に基づくが、サービスはスケジュール周りの通知イベントを発行することができる。
・ イベント・スケジュールは、「毎日午前３時」、「ネットワーク・ログオン時」、「ＵＳＢ装置の差込み後」または「３回ログインに失敗した後」のようなイベントのパターンを定義する。イベント・スケジュールを和集合としてのみ合成することができるが、イベント・スケジュールと期間スケジュールとの積集合を取ることができる。ジッタ、すなわち、「ＲＡＮＤ（１５分）の遅延を伴った午前９時」を含む幾つかの高度な機能もありうる。

上のリストにおける最後の２つのスケジュール（定期スケジュールとイベント・スケジュール）は非常に異なるスキーマと意味をもつ。このポリシー管理基盤を使用すると、当該スキーマにより、参照を介した合成が可能となる。

ディレクトリ・サービス
多くのポリシー機能は、一般にはディレクトリ・サービスで維持されるユーザ、コンピュータ・システム、組織単位、および他のエンティティの識別を参照する。ディレクトリ・サービスは、ある種のナビゲーション機能および問合せ機能を提供する名前付け構造およびアプリケーション・プログラミング・インタフェースを提供し、これらの機能は業界規模の標準に基づくか独自のものであることができる。ポリシーおよびメタ・ポリシーはこのディレクトリ内のエンティティを参照することができ、ポリシー管理基盤は必要な時点でその参照を解決する。例えば、ポリシーの対象が標準的なディレクトリ構造内のＯＵのような管理グループである場合、ディレクトリはそのＯＵに含まれるシステムのリストを提供でき、したがって、ポリシー基盤は、管理グループのターゲッティングによって暗示されるシステムのターゲッティングを推定することができる。

システム定義モデル
管理システムは、システム定義モデル（ＳＤＭ）で定義されるモデルによって記述される。本モデルはシステムの構成要素とそれらの関係、一般的な型と実際のインスタンスの両方を記述する。一般に、モデルの２つの特性、すなわち、現在の状態（「である」）と望ましい状態（「であるべき」）がある。他のモデルでは、他の特性があり、それには履歴、予想負荷および予想状態、提示されたバージョンおよび仮説のバージョンが含まれる。本モデルは、アクセス制御に使用される役割定義を含むことができる。モデルはまたリソースを含む。リソースに対する名前パターン（例えば、＊．ｔｍｐ）は各リソース・マネージャによって表現され、定義される。

リソース・マネージャ
リソース・マネージャは、ポリシーの対象であることが多いリソースを管理するサービスである。各リソース・マネージャは独自の特徴と名前空間を有する。ポリシーはリソースを参照することができる。例えば、ファイル・システムはファイルを管理するリソース・マネージャであり、これらのファイルは、一般に階層的なディレクトリ構造、ファイル名、および型を指定する拡張子を含む名前パターンを通して特定される。各ファイルは、サイズおよび最終更新日のような追加の属性を有する。ＭｉｃｒｏｓｏｆｔのＳＱＬ Ｓｅｒｖｅｒのような関係データベースもまた、テーブル、インデックス、プロシージャ、および他のリソースを管理するリソース・マネージャであり、これらのリソースは異なる名前付け構造で特定され、異なる特徴を有する。リソース・マネージャの名前付け構造はポリシーおよびメタ・ポリシーの仕様に対して重要である。例えば、従来のファイル・システム内のファイルを参照するポリシーまたはメタ・ポリシーは、Ｗｏｒｄ文書型の全てのファイルを示すために「＊．ｄｏｃ」という表現を使用することができるが、係る表現はＳＱＬ Ｓｅｒｖｅｒのリソース・サーバに対しては妥当でないだろう。

方法論的実装
図２は、ポリシー管理基盤１００のコンテクストにおけるポリシー管理の方法２００を示す。この方法２００は、図１に示す様々な構成要素のうちの１つまたは複数によって実行される。さらに、この方法２００をソフトウェア、ハードウェア、ファームウェア、またはそれらの組合せで実行することができる。

図２のブロック２０２で、ポリシー管理システム１１０は複数のメタ・ポリシーを生成する。メタ・ポリシーは、１つまたは複数の対象コンピューティング・ノードに対するポリシーの適用を制御する。メタ・ポリシーを生成するとき、システムはそれらを階層構造で編成する。少なくとも１つの実装形態では、メタ・ポリシー階層は、図１に示し上述したポリシー管理基盤１００に示すように編成される。

図２のブロック２０４で、ポリシー管理システム１１０は、複数の実ポリシーのデータを層状の複数のメタ・ポリシーのコンテクストで分析する。それを行う際、システムはポリシーの「重複」および「衝突」の存在および位置を決定する。「重複」は、同一のポリシー・ドメイン内で２つ以上のポリシーが同じオブジェクトを参照し、同時に同じコンピュータ・システム上で同じ条件下で有効であるときに生じる。例えば、あるポリシーが企業領域内の全てのコンピュータ・システムを対象とし作業時間中に有効であり、かつ別のポリシーが同じコンピュータ・システムを対象とし全ての時点で有効である場合、これらの２つのポリシーは重複する。逆に、あるポリシーが作業時間中に有効であり別のポリシーが非作業時間中に有効である場合は、それらのポリシーは重複しない。

システムは、重複を発見するためにポリシーのドメイン固有な詳細を知る必要はなく、その詳細は、メタ・ポリシーとリソース・マネージャの名前空間とを分析することによって完全に決まる。「衝突」は、２つのポリシーが重複し、衝突するステートメントを記述するときに生じる。例えば、あるポリシーではファイアウォールが作業時間中に停止されていると記述され、別のポリシーではファイアウォールが全ての時点で起動されていると記述される場合、これらのポリシーは衝突する。逆に、あるポリシーではファイアウォールが作業時間中に起動されていると記述され、別のポリシーではポリシーが全ての時点で起動されていると記述される場合は、これらのポリシーは重複していても衝突はしない。

システムは、衝突を発見するためにポリシーのドメイン固有な詳細を知る必要はない。なぜならば、衝突はポリシーの意味によって決まるからである。例えば、ファイアウォールの設定は２つの相互に排反する値をもつブール値であるので、ファイアウォールの起動状態と停止状態は衝突すると容易に決定されるが、あるポリシーではボブがファイルへの読取りアクセス権を有することが記述され、別の重複するポリシーではボブがファイルへのフル・アクセス権を有することが記述される場合、これらのポリシーは衝突しない。なぜならば、「フル」アクセス権は「読取り」アクセス権を含み、そのことはファイル・システムのアクセス権の意味を理解するシステムによってのみ決定することができ、その分析はアクセス制御のポリシー・ドメインに固有であるからである。このため、衝突の分析および検出は、ドメインにとらわれないメタ・ポリシーのみを見る汎用目的の重複検出システムを介して実装することができ、重複を特定した後に、ドメイン固有の衝突分析システムが、重複するポリシーが実際に衝突するかどうかを判定することができる。

ポリシーとメタ・ポリシーを、適用範囲の完全性のために分析することもできる。例えば、あるポリシーが作業時間中に有効で別のポリシーが非作業時間中に有効である場合、作業時間と非作業時間の間の２つのポリシーが完全な適用範囲を提供する。逆に、あるポリシーが名前パターン「＊．ｄｏｃ」にマッチする全てのファイルに適用され、別のポリシーが名前パターン「＊．ｘｌｓ」にマッチする全てのファイルに適用される場合、これらの２つのポリシーはファイル・システムの完全な適用範囲を提供しない。なぜならば、これらの２つの名前パターンのいずれにもマッチしないファイルが存在するからである。適用範囲の検出は、ドメイン固有ポリシーの詳細の理解が不要で、メタ・ポリシーとリソース・マネージャの名前空間との分析を介してのみ行われるという点で、重複検出と類似している。

図２のブロック２０６で、システムは複数のメタ・ポリシーを実ポリシーに適用する。それを行う際、システムは、衝突および／または重複が存在すると決定されるときのＲＳＯＰ（Ｒｅｓｕｌｔａｎｔ Ｓｅｔ ｏｆ Ｐｏｌｉｃｉｅｓ）の計算を促進する。システムは、（図１で示し、上述した）ポリシー管理基盤１００の順序階層および順位階層によるデータ階層化を利用して、ポリシーの影響を決定する。

システムによって実行されるＲＳＯＰ計算の促進には実際のＲＳＯＰ計算自体を含めることができ、あるいは、システムは対象ポリシーをポリシー・コンシューマに送信して、ポリシー・コンシューマが結果として得られたＲＳＯＰの計算を行うようにすることができる。

図２のブロック２０８で、ポリシー管理システム１１０は結果のポリシーをポリシー・コンシューマに配布し、ポリシー・コンシューマは処理済みのポリシーのうちの少なくとも１つを１つまたは複数の対象コンピューティング・ノードに適用するように構成される。ポリシー・コンシューマは処理済みのポリシーを、ポリシー・コンシューマのドメイン固有の詳細にマッピングすることができる。

後記
本明細書で説明した技法を、プログラム・モジュール、汎用目的および特殊目的のコンピューティング・システム、ネットワーク・サーバおよび機器、専用電子機器およびハードウェア、ファームウェア、１つもしくは複数のコンピュータ・ネットワークの一部、またはそれらの組合せを含む（がこれらに限らない）多数の方法で実装することができる。さらに、他の実装形態では、ＰＣ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ）、サーバ・コンピュータ、ハンドヘルド装置またはラップトップ装置、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、プログラム可能消費家電、無線電話および無線機器、汎用目的および特殊目的の装置、ＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、ネットワークＰＣ、シン・クライアント、シック・クライアント、セット・トップ・ボックス、ミニ・コンピュータ、メインフレーム・コンピュータ、上記システムまたは装置のいずれかを含む分散コンピューティング環境、および同種のものの任意の組合せのような（これらは例であって限定ではない）、公知なコンピューティング・システム、環境、および／または構成を使用してもよい。

１つまたは複数の上述の実装形態を構造的特徴および／または方法論的ステップに特有な言葉で説明したが、本明細書で説明した特定の例示的な特徴またはステップをもたない他の実装形態を実施することができることは理解されよう。むしろ、特定の例示的な特徴およびステップは１つまたは複数の実装形態のうちの好ましい形態として開示されている。幾つかの事例では、例示的な実装形態の記述を明確にするために公知な特徴を省略または簡略化してあったかもしれない。さらに、理解を容易にするため、幾つかの方法ステップを別々のステップとして区別してあるが、これらの別々に区別したステップは必ずしもそれらの性能に応じた順序であると解釈すべきではない。

Claims (20)

1. コンピュータ実行可能命令を格納するコンピュータ読み取り可能な記憶媒体であって、
   前記コンピュータ実行可能命令は、コンピュータによって実行されると、
   １つまたは複数のオブジェクトに対するより高い階層のメタ・ポリシーの適用が、前記１つまたは複数のオブジェクトの前記より高い階層のメタ・ポリシーに従属する１つまたは複数のより低い階層のメタ・ポリシーの対応する影響を制限するように、メタ・ポリシーの階層化された序列に編成される複数のメタ・ポリシーを生成するステップであって、各メタ・ポリシーは、１つまたは複数の対象コンピューティング・ノードへのポリシーの適用を制御する、ステップと、
   ポリシーおよびメタ・ポリシーによって共有される共通のコンテクストを提供するために共通名前空間を使用するステップであって、前記共通名前空間のそれぞれは、対応するファイル拡張子によって定義される、ステップと、
   各ポリシーのドメイン固有な詳細を知ることなく前記ポリシーの１つまたは複数の重複を判定するために前記共通名前空間についての前記メタ・ポリシーのコンテクストで前記ポリシーを分析するステップであって、それぞれの重複は、ポリシー・ドメイン内の複数のポリシーが同一のコンピュータシステム上の１つまたは複数の同一のオブジェクトについて同時に有効であるときに生じる、ステップと、
   前記共通名前空間を使用する複数のオブジェクトを対象にするポリシーの完全性を判定するために、各ポリシーのドメイン固有な詳細を知ることなく前記共通名前空間についての前記メタ・ポリシーのコンテクストで前記ポリシーを分析するステップと、
   各ポリシーのドメイン固有な詳細に基づいて前記ポリシーの１つまたは複数の重複における１つまたは複数の衝突を判定するステップであって、各衝突は、複数の重複ポリシーが１つまたは複数の同一のオブジェクトに関する衝突するポリシーのステートメントを記述するときに生じる、ステップと、
   前記複数のメタ・ポリシーを前記ポリシーに適用することによって、１つまたは複数の重複あるいは１つまたは複数の衝突の少なくとも１つについてのＲＳＯＰ（Resultant Set of Policies）を計算するステップと、
   を備える方法を前記コンピュータに実行させることを特徴とするコンピュータ読み取り可能な記憶媒体。
2. 前記１つまたは複数の対象コンピューティング・ノードに対する前記ＲＳＯＰをポリシー・コンシューマに配布するステップをさらに備えることを特徴とする請求項１に記載のコンピュータ読み取り可能な記憶媒体。
3. 前記生成するステップは、前記複数のメタ・ポリシーを表す多層のデータ・モデルを生成するステップを備えることを特徴とする請求項１に記載のコンピュータ読み取り可能な記憶媒体。
4. 前記計算するステップは、前記ポリシーの前記複数のメタ・ポリシーの影響を決定することを含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記憶媒体。
5. 前記計算するステップは、前記ポリシーをポリシー・コンシューマに送信し、それによって前記ポリシー・コンシューマが少なくとも部分的に前記ＲＳＯＰを計算できるようにするステップを備えることを特徴とする請求項１に記載のコンピュータ読み取り可能な記憶媒体。
6. 前記複数のオブジェクトは、前記共通名前空間を使用するファイルシステムのファイルを含むことを特徴とする請求項１に記載のコンピュータ読み取り可能な記憶媒体。
7. 前記複数のメタ・ポリシーおよび前記ポリシーは、スケジューリング、ディレクトリ・サービス、システム定義モデル、またはそれらの組合せのための共通名前空間を使用することを特徴とする請求項１に記載のコンピュータ読み取り可能な記憶媒体。
8. 前記複数のメタ・ポリシーおよび前記ポリシーは、１つまたは複数のリソース・マネージャによって使用される共通名前空間を使用することを特徴とする請求項１に記載のコンピュータ読み取り可能な記憶媒体。
9. 前記生成するステップは、前記複数のメタ・ポリシーを表すデータ・モデルを生成するステップであって、前記データ・モデルは、管理層と、マージおよび衝突層とを備える少なくとも２つの複数のデータ層を有する、ステップを備えることを特徴とする請求項１に記載のコンピュータ読み取り可能な記憶媒体。
10. コンピュータ実行可能命令を格納するコンピュータ読み取り可能な記憶媒体であって、
    前記コンピュータ実行可能命令は、コンピュータによって実行されると、
    複数のメタ・ポリシーを生成するステップであって、メタ・ポリシーは１つまたは複数の対象コンピューティング・ノードへのポリシーの適用を制御し、前記生成するステップは、前記複数のメタ・ポリシーを表すデータ・モデルを生成することを備え、前記データ・モデルは、最も高い層から最も低い層の序列に構成される複数のデータ階層を有し、より高い層は、前記１つまたは複数の対象コンピューティング・ノードのより低い層の影響を制限し、前記複数のデータ階層は、
    ポリシーの適用性および適応化に関するデータを格納する適用性および適応化のメタ・ポリシー層であって、対象コンピューティング・ノードの新たなハードウェアデバイスのインストレーションに適合する前記ポリシーの以前機能していなかったポリシーを少なくともアクティベートする、適用性および適応化のメタ・ポリシー層と、
    ポリシーの一貫性に関するデータを格納する、前記適用性および適応化のメタ・ポリシー層に隣接する一貫性のメタ・ポリシー層と、
    ターゲッティングおよび配布ポリシーに関するデータを格納する、前記一貫性のメタ・ポリシー層に隣接するターゲッティングおよび配布のメタ・ポリシー層と、
    ポリシーの配信に関するデータを格納する、前記ターゲッティングおよび配布のメタ・ポリシー層に隣接するリリースおよび実施のメタ・ポリシー層であって、ユーザがポリシーを対象コンピューティング・ノードに適用することを促進するためのタイム・ウィンドウと、前記ポリシーが前記タイム・ウィンドウの有効期限切れの際に前記ユーザからの入力なしで適用されることを少なくとも規定する、リリースおよび実施のメタ・ポリシー層と、
    ポリシーのライフサイクルに関するデータを格納する、前記リリースおよび実施のメタ・ポリシー層に隣接する変更および承認ワークフローのメタ・ポリシー層と
    を備える、ステップと、
    ポリシーおよびメタ・ポリシーによって共有される共通のコンテクストを提供するために共通名前空間を使用するステップと、
    前記ポリシーの１つまたは複数の重複を判定するために前記メタ・ポリシーおよび前記共通名前空間のコンテクストでポリシーを分析するステップであって、それぞれの重複は、ポリシー・ドメイン内の複数のポリシーが同一のコンピュータシステム上の１つまたは複数の同一のオブジェクトについて同時に有効であるときに生じる、ステップと、
    前記ポリシーの１つまたは複数の重複における１つまたは複数の衝突を判定するステップであって、各衝突は、複数の重複ポリシーが１つまたは複数の同一のオブジェクトに関する衝突するポリシーのステートメントを記述するときに生じる、ステップと、
    前記複数のメタ・ポリシーを前記ポリシーに適用することによって、１つまたは複数の重複あるいは１つまたは複数の衝突の少なくとも１つについてのＲＳＯＰ（Resultant Set of Policies）を計算するステップと、
    を備える方法を前記コンピュータに実行させることを特徴とするコンピュータ読み取り可能な記憶媒体。
11. 前記一貫性のメタ・ポリシー層は、前記対象コンピューティング・ノード上で一貫性のない状態が発生することを防止するために、少なくとも２つのポリシーが前記対象コンピューティング・ノード上の原子的単位として同時にデプロイされることを少なくとも規定することを特徴とする請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
12. 前記ターゲッティングおよび配布のメタ・ポリシー層は、前記対象コンピューティング・ノードが指定された場所から離れてローミングするときに、前記対象コンピューティング・ノードがネットワークを介してソフトウェアパッケージをダウンロードすることを少なくとも禁止することを特徴とする請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
13. 前記変更および承認ワークフローのメタ・ポリシー層は、前記ポリシーの少なくとも１つへの変更に対する１次承認者および２次承認者を少なくとも識別することを特徴とする請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
14. コンピュータによって実行される、ポリシー管理方法であって、
    前記方法は、
    複数のメタ・ポリシーを生成するステップであって、メタ・ポリシーは、１つまたは複数の対象コンピューティング・ノードへのポリシーの適用を制御する、ステップと、
    １つまたは複数のオブジェクトに対するより高い階層のメタ・ポリシーの適用が、前記１つまたは複数のオブジェクトの前記より高い階層のメタ・ポリシーに従属する１つまたは複数のより低い階層のメタ・ポリシーの対応する影響を制限するように、前記複数のメタ・ポリシーをメタ・ポリシーのヒエラルキーに編成するステップであって、各メタ・ポリシーは、１つまたは複数の対象コンピューティング・ノードへのポリシーの適用を制御する、ステップと、
    ポリシーおよびメタ・ポリシーによって共有される共通のコンテクストを提供するために共通名前空間を使用するステップであって、前記共通名前空間は、前記ポリシーおよびメタ・ポリシーによって影響を受けるファイルのファイル拡張子によって定義される、ステップと、
    各ポリシーのドメイン固有な詳細を知ることなく前記ポリシーの１つまたは複数の重複を判定するために前記共通名前空間についての前記メタ・ポリシーを分析するステップであって、それぞれの重複は、ポリシー・ドメイン内の複数のポリシーが同一のコンピュータシステム上の１つまたは複数の同一のオブジェクトについて同時に有効であるときに生じる、ステップと、
    各ポリシーのドメイン固有な詳細に基づいて前記ポリシーの１つまたは複数の重複における１つまたは複数の衝突を判定するステップであって、各衝突は、複数の重複ポリシーが１つまたは複数の同一のオブジェクトに関する衝突するポリシーのステートメントを記述するときに生じる、ステップと、
    前記複数のメタ・ポリシーを前記ポリシーに適用することによって、１つまたは複数の重複あるいは１つまたは複数の衝突の少なくとも１つについてのＲＳＯＰ（Resultant Set of Policies）を計算するステップと、
    を備えることを特徴とする方法。
15. 前記計算するステップは、前記ポリシーの前記複数のメタ・ポリシーの影響を判定することを含むことを特徴とする請求項１４に記載の方法。
16. 前記計算するステップは、ポリシーをポリシー・コンシューマに送信し、それによって前記ポリシー・コンシューマが少なくとも部分的に前記ＲＳＯＰを計算できるようにするステップを備えることを特徴とする請求項１４に記載の方法。
17. 前記共通名前空間は、１つまたは複数のリソース・マネージャによって使用されることを特徴とする請求項１４に記載の方法。
18. 前記複数のメタ・ポリシーおよび前記ポリシーは、スケジューリング、ディレクトリ・サービス、システム定義モデル、またはそれらの組合せのための共通名前空間を使用することを特徴とする請求項１４に記載の方法。
19. 重複および適用範囲に対して共通名前空間を分析するためのインストールサービスを提供するステップをさらに備えることを特徴とする請求項１４に記載の方法。
20. 前記データ・モデルは、
    ポリシー管理に関するデータを格納する、ポリシー管理のメタ・ポリシー層と、
    ポリシーのマージおよび衝突解決に関するデータを格納する、マージおよび衝突解決のメタ・ポリシー層と、
    ポリシーに対する有効なスケジュールおよび条件を定義するデータを格納する、有効なスケジュールおよび条件のメタ・ポリシー層と、
    ポリシーの適用性および適応化に関するデータを格納する、適用性および適応化のメタ・ポリシー層と、
    ポリシーの一貫性に関するデータを格納する、一貫性のメタ・ポリシー層と、
    ポリシーのターゲッティングおよび配布に関するデータを格納する、ターゲッティングおよび配布のメタ・ポリシー層と、
    ポリシーの配信に関するデータを格納する、リリースおよび実施のメタ・ポリシー層と、
    ポリシーのライフサイクルに関するデータを格納する、変更および承認ワークフローのメタ・ポリシー層と
    を備える複数データ階層のうちの少なくとも２つを有することを特徴とする請求項１４に記載の方法。

Images