(57)【特許請求の範囲】
【請求項１】
マルチテナント・コンピューティング・インフラストラクチャにおける鍵管理の方法であって、
テナントごとに仮想鍵管理領域を作成することであって、
前記仮想鍵管理領域が、ハードウェア要素上で実行中のサーバを使用して作成され、セキュリティおよび検証のための階層的な信頼レベルにより、前記テナントに固有のキー材料が関連付けられた、前記仮想鍵管理領域をテナントごとに作成することと、
前記キー材料を前記テナントに提供することと、
第１のテナントに固有のキー材料によってセキュアにされた第１のデータを、第２のテナントに固有のキー材料によってセキュアにされた第２のデータから分離することと
を含む、方法。
【請求項２】
それぞれのテナントの仮想鍵管理領域が、前記マルチテナント・コンピューティング・インフラストラクチャの所与の部分と関連付けられる、請求項１に記載の方法。
【請求項３】
前記テナントに固有の前記キー材料が、１つまたは複数の管理キー・バリアントのセットがそこから導出される仮想管理キー・ブロックを含む、請求項１に記載の方法。
【請求項４】
前記テナントに固有の前記キー材料が、１つもしくは複数のデバイス・キーのセット、および１つもしくは複数のデバイス識別子のセットをさらに含み、デバイス・キーが、前記仮想管理キー・ブロックから管理キー・バリアントを導出するために使用される暗号キーであり、デバイス識別子が、前記マルチテナント・コンピューティング・インフラストラクチャ内の構成要素と関連付けられ、前記デバイス・キーの所与の１つを適用する前記仮想管理キー・ブロック内の暗号パスを決定するために使用される、請求項３に記載の方法。
【請求項５】
前記１つまたは複数の管理キー・バリアントを使用して、前記マルチテナント・コンピューティング・インフラストラクチャ内のリソースに１つまたは複数の信頼レベルを関連付けることをさらに含む、請求項４に記載の方法。
【請求項６】
所与の信頼レベル内の構成要素が、前記所与の信頼レベルよりもセキュアでない信頼レベル内の少なくとも１つのデバイスに対するセキュリティを検証する、請求項５に記載の方法。
【請求項７】
前記仮想鍵管理領域が、ブロードキャスト暗号方式を使用して作成される、請求項１に記載の方法。
【請求項８】
装置であって、
プロセッサと、
前記プロセッサによって実行されるとき、マルチテナント・コンピューティング・インフラストラクチャにおける鍵管理の方法を行うコンピュータ・プログラム命令を保持するコンピュータ・メモリとを含み、前記方法が、
テナントごとに仮想鍵管理領域を作成することであって、
前記仮想鍵管理領域が、ハードウェア要素上で実行中のサーバを使用して作成され、セキュリティおよび検証のための階層的な信頼レベルにより、前記テナントに固有のキー材料が関連付けられた、前記仮想鍵管理領域をテナントごとに作成することと、
前記キー材料を前記テナントに提供することと、
第１のテナントに固有のキー材料によってセキュアにされた第１のデータを、第２のテナントに固有のキー材料によってセキュアにされた第２のデータから分離することと
を含む、装置。
【請求項９】
それぞれのテナントの仮想鍵管理領域が、前記マルチテナント・コンピューティング・インフラストラクチャの所与の部分と関連付けられる、請求項８に記載の装置。
【請求項１０】
前記テナントに固有の前記キー材料が、１つまたは複数の管理キー・バリアントのセットがそこから導出される仮想管理キー・ブロックを含む、請求項８に記載の装置。
【請求項１１】
前記テナントに固有の前記キー材料が、１つもしくは複数のデバイス・キーのセット、および１つもしくは複数のデバイス識別子のセットをさらに含み、デバイス・キーが、前記仮想管理キー・ブロックから管理キー・バリアントを導出するために使用される暗号キーであり、デバイス識別子が、前記マルチテナント・コンピューティング・インフラストラクチャ内の構成要素と関連付けられ、前記デバイス・キーの所与の１つを適用する前記仮想管理キー・ブロック内の暗号パスを決定するために使用される、請求項１０に記載の装置。
【請求項１２】
前記方法が、前記１つまたは複数の管理キー・バリアントを使用して、前記マルチテナント・コンピューティング・インフラストラクチャ内のリソースに１つまたは複数の信頼レベルを関連付けることをさらに含む、請求項１１に記載の装置。
【請求項１３】
所与の信頼レベル内の構成要素が、前記所与の信頼レベルよりもセキュアでない信頼レベル内の少なくとも１つのデバイスに対するセキュリティを検証する、請求項１２に記載の装置。
【請求項１４】
前記仮想鍵管理領域が、ブロードキャスト暗号方式を使用して作成される、請求項８に記載の装置。
【請求項１５】
請求項１〜７の何れか1項に記載の方法の各ステップを、コンピュータに実行させる、コンピュータ・プログラム。
【請求項１６】
請求項１５に記載の前記コンピュータ・プログラムを、コンピュータ可読媒体に格納した、コンピュータ可読記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、異なる者が情報技術（ＩＴ）リソースを共用するクラウド・コンピューティングまたは他の共有展開環境において、情報をセキュアにすることに関する。より詳細には、本発明は、マルチテナント・コンピューティング・インフラストラクチャにおける鍵管理の方法に関する。
【背景技術】
【０００２】
新たに出現した情報技術（ＩＴ）配信モデルが、クラウド・コンピューティングであり、これにより、共有されるリソース、ソフトウェア、および情報は、インターネットを通じてコンピュータおよび他のデバイスにオンデマンドで提供される。クラウド・コンピューティングおよび他のこのような共有展開モデル内で複数の者がリソースを共有するとき、そのＩＴコストの強制的変化および削減（固定型から可変型へ）を実現することができる。この手法を使用すると、会社は、コンピューティングおよびストレージ容量を弾力的に拡大して、需要に合わせること、運用および資本コストを外部のデータセンタ、無料ＩＴスタッフに移して新しいプロジェクトに焦点を合わせること、およびさらに多くのことが可能である。クラウド計算リソースは一般的に、データセンタ施設の物理サーバ上にマップされた仮想サーバ、すなわちいわゆる「仮想マシン」（ＶＭ）内でアプリケーションが動作する、仮想化されたアーキテクチャを一般的に使用して、ネットワークに接続されたアプリケーションを実行する大規模サーバ・ファームに収容される。
【０００３】
新たに出現したクラウド環境は、クラウドベースのサービスをサポートするように構成されている既存のＩＴインフラストラクチャから作り出されている。既存の環境とは異なるクラウド・コンピューティングの１つの主要な特徴は、複数顧客単一展開（multi-customer single deployment）と呼ばれることもある、いわゆる「マルチテナント」サポートの要件である。この要件を満たすために、サービス・プロバイダは、クラウド・サービスの異なる顧客の利用を分離することができなければならない。実際に、一般的には企業顧客をこのようなリソースの利用から遠ざけている最も深刻な障壁の１つが、プロバイダのセキュリティ姿勢を、その独自のセキュリティ・コンプライアンス要件に関して評価する（gauge）能力である。
【０００４】
詳細には、共有環境が、保護されていないデータを、意図的にのみならず、意図的でなくとも、第三者による悪意のある攻撃、ハッキング、およびイントロスペクション（introspection）にさらすおそれを有する。サービス・プロバイダは、したがって、クラウド・リソースを共有している特定の顧客間および顧客同士の分離を維持する必要がある。したがって、このようなシステムは、基となるネットワーク、プラットフォーム、仮想化機構、またはミドルウェアにかかわらず、エンドツーエンドの信頼性および顧客データのセキュリティを確保する必要がある。これらの問題のいくつかは、データおよびリソースの分離、ならびにＶＰＮおよび他のそのようなアクセス機構の使用によって対処されることが可能であるが、多くのクラウド・データセンタは、伝統的なネットワーク分離を無効にする（negate）、およびＶＰＮキーイング技法を複雑にする非伝統的な物理ネットワーク構成を使用する。現在、顧客の仮想領域のすべての層にわたってデータ・セキュリティを提供する、単一の標準的なまたは明白な機構が設けられていない。
【０００５】
クラウド・コンピューティングおよび他の共有展開モデルを使用することを望むほとんどの会社は、会社のデータおよびアプリケーションに高い価値を付与し、それらを価値のある知的財産（ＩＰ）とみなす。上記のように、これらの企業はまた、企業に企業のアプリケーションがアクセスするデータの機密性を十分に保護する義務を負わせる、法的な、規制目的の、または独自の企業セキュリティ・ポリシー、あるいはこれらの組合せの企業セキュリティ・ポリシーを有することがある。この問題を解決する際の１つの仮定は、慎重な扱いを要するデータ、またはそのようなデータを使用する機密性の高いアプリケーション、あるいはその両方を有する顧客のニーズに応えるには、このような共有／クラウド・インフラストラクチャ内のテナントごとのデータの暗号化が必要であるということである。このために、この問題に対処するために提案された１つの手法が、パブリック・データセンタを使用することを希望する会社に、共有インフラストラクチャ内の攻撃に対する最善の防御としてその独自のデータの暗号化を外部から管理しようと試みさせることである。しかしながらこの手法は、暗号化（例えば、鍵、認証など）の管理、および認証／認可プロトコルがクラウドの顧客に大きな負担となるので、ビジネス・ワークフローを可能にするには有効なアクセスが必要とされるとき、データの実用性を低下させる。
【０００６】
さらに、共有データセンタ・プロバイダが公開鍵インフラストラクチャ（ＰＫＩ）など、既存の鍵管理システムを使用して仮想化されたデータセンタのあらゆるレベルにおいてエンドツーエンドの暗号化によるセキュリティをサポートすることに関係する複雑さは、法外なものとなっている。これは、ＰＫＩに基づく暗号化技法が、２者または２つのエンドポイント間で信頼およびセキュアな／暗号化されたデータを確立するように設計されているためである。これは、単純なデータ／メッセージ交換には十分であるかもしれないが、クラウド・インフラストラクチャに存在するより高度なワークフローでは、データが、多くのエンドポイントを越え、顧客が直接制御しない多くのサービスおよびリソースを含んでいる。さらに、ＰＫＩベースの技法を使用する試みは、多くの公開／秘密鍵ペアおよびそれらの関連するセキュリティ・ポリシーを管理する必要性のために、やはり扱いにくいものでもある。実際に、最悪の場合では、すべてのエンドポイントが、顧客のデータを扱うための個別の公開／秘密鍵ペアおよびセキュリティ・ポリシーを有する。ＰＫＩに基づく手法に伴う別の問題は、エンドツーエンドのセキュリティ・システムを更新する手段、または信頼の相対的レベルに基づいてデバイスもしくはシステム・リソースを無効にするもしくは機密扱いにする手段がないことである。このような機能を複雑な環境において必要とされる粒度のレベルで顧客に公開することもまた支持できないものとなっている。ハイブリッド環境またはマルチクラウド環境全体にわたって鍵を管理すると、こうした問題を悪化させるだけである。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】“Draft NIST Working Definition ofCloud Computing” by Peter Mell and Tim Grance, datedOctober 7, 2009
【発明の概要】
【発明が解決しようとする課題】
【０００８】
したがって、データの強力な暗号化を提供するが、共有データセンタ・プロバイダとそれらへの加入を希望する会社の双方にとってより容易に管理できる手法の必要性が依然としてある。
【課題を解決するための手段】
【０００９】
本発明の諸実施形態によれば、マルチテナント共有展開におけるテナントは、テナントの独自の異なる鍵空間を提供され、テナントはこの空間にわたって鍵管理システムを制御する。このように、仮想鍵管理領域が、テナントごとに（顧客ごとに）作成され、特定の顧客のデータが、プロバイダの（１つまたは複数の）データセンタのＩＴインフラストラクチャにおいて共同テナント化される、格納される、送信される、または仮想化されるときはいつでも、データはその顧客に固有の鍵管理材料を使用してセキュアにされるようにする。これは、テナントのデータ（すべての汎用データ、およびソフトウェア・アプリケーションを含むが、これらに限らない）の全体が、他のテナントのアプリケーションからこれを暗号で分離することによって依然としてセキュアであることを保証する。仮想鍵管理領域は、ブロードキャスト暗号化（ＢＥ）プロトコルを使用して、詳細にはそのプロトコルの複数の管理キー・バリアント方式を使用して、暗号化される。本明細書に記載するブロードキャスト暗号化に基づく仮想鍵管理システム（ＶＫＭＳ）およびプロトコルは、データのテナントごとのセキュアにされた分離を実現し、共同テナント化されたＩＴインフラストラクチャにおいて、またはその全体にわたって、リソースのいかなる組合せにわたっても使用されることが可能である。テナントと関連付けられた特定の仮想鍵管理領域（ＶＫＭＤ）内では、その後対称鍵が、各所望の信頼レベルに対して確立される（およびその特定の領域においてのみ使用される）ことが可能である。
【００１０】
前述の説明は、本発明のさらに多くの関係のある特徴のうちの一部を概説したものである。これらの特徴は、単に説明のためであると考えられるべきである。本発明の諸実施形態を異なる方法で適用することによって、または以下に述べるように実施形態を変更することによって、他の多くの有益な結果が得られる可能性がある。
【図面の簡単な説明】
【００１１】
本発明およびその利点をより完全に理解するために、次に添付の図面と併せて次の説明を参照されたい。
【図１】例示的実施形態の例示の態様を実行することができる分散データ処理環境の例示のブロック図を示す。
【図２】例示的実施形態の例示の態様を実行することができるデータ処理システムの例示のブロック図である。
【図３】開示する主題を実行することができる例示のクラウド・コンピューティング・アーキテクチャを示す図である。
【図４】この開示のブロードキャスト暗号化に基づく仮想鍵管理システム（ＶＫＭＳ）およびプロコトルを実行することができる例示のデータセンタを示す図である。
【図５】この開示による仮想鍵管理システム（ＶＫＭＳ）を含むように拡張された、図４のデータセンタを示す図である。
【図６】仮想鍵管理システム（ＶＫＭＳ）の代表的な要素をより詳細に示す図である。
【図７】代表的なＶＫＭＳ領域データ（ＶＫＭＳ−ＤＤ）データ・セットを示す図である。
【図８】ＶＫＭＳが顧客／テナントのためにＶＫＭＤを作成し、初期化する、代表的プロセスの流れを示す図である。
【図９】複数のＶＫＭ領域が適用された後の共有ＩＴリソースのプロバイダのデータセンタを示す図である。
【図１０】顧客が複数のデバイス信頼クラスまたはレベルを使用してそのアプリケーションおよびデータをプロビジョニングすることができる方法を示す代表的データセンタ・プロビジョニング戦略を示す図である。
【発明を実施するための形態】
【００１２】
次に図面を参照すると、詳細には図１〜２を参照すると、開示の例示的実施形態を実行することができるデータ処理環境の例示の図が提供されている。当然のことながら、図１〜２は、単に例示であって、開示する主題の態様または実施形態が実行される可能性のある環境に関していかなる限定も主張するまたは暗示するものではないことを理解するべきである。主題の範囲を逸脱することなく、示される環境の多くの変更が行われることが可能である。
【００１３】
クライアント−サーバ技術
次に図面を参照すると、図１は、例示的実施形態の諸態様が実行されることが可能である例示の分散データ処理システムの図形表現を示す。分散データ処理システム１００は、例示的実施形態の諸態様が実行されることが可能であるコンピュータのネットワークを含むことができる。分散データ処理システム１００は、少なくとも１つのネットワーク１０２を含み、ネットワーク１０２は、分散データ処理システム１００内で合わせて接続された様々なデバイスおよびコンピュータ間に通信リンクを提供するために使用される媒体である。ネットワーク１０２は、有線、無線通信リンク、または光ファイバケーブルなど、接続を含むことができる。
【００１４】
示した例では、サーバ１０４およびサーバ１０６は、ストレージ・ユニット１０８とともにネットワーク１０２に接続されている。さらに、クライアント１１０、１１２、および１１４もまた、ネットワーク１０２に接続されている。これらのクライアント１１０、１１２、および１１４は、例えば、パーソナル・コンピュータ、ネットワーク・コンピュータなどであってもよい。示した例では、サーバ１０４は、ブート・ファイル、オペレーティング・システム・イメージ、およびアプリケーションなどのデータを、クライアント１１０、１１２、および１１４に提供する。クライアント１１０、１１２、および１１４は、示した例ではサーバ１０４に対するクライアントである。分散データ処理システム１００は、図示していないさらなるサーバ、クライアント、および他のデバイスを含むことができる。
【００１５】
示した例では、分散データ処理システム１００は、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）プロトコル群を使用して互いと通信するネットワークおよびゲートウェイの世界規模の集合を表すネットワーク１０２を有するインターネットである。インターネットの中心には、データおよびメッセージをルーティングする多数の商用、行政用、教育用、およびその他のコンピュータ・システムからなる主要なノードまたはホスト・コンピュータ間の高速データ通信回線のバックボーンがある。当然ながら、分散データ処理システム１００は、いくつかの異なるタイプのネットワーク、例えばイントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）などを含むように実行されることもある。上述のように、図１は、一例とするものであり、開示する主題の異なる実施形態に対する構造上の制約とするものではなく、したがって、図１に示される特定の要素は、本発明の例示的実施形態が実行されうる環境に関して限定するものと考えられるべきではない。
【００１６】
次に図２を参照すると、例示的実施形態の諸態様が実行されることがある例示のデータ処理システムのブロック図が示されている。データ処理システム２００は、図１のクライアント１１０など、コンピュータの一例であり、この中に、開示の例示的実施形態のための処理を実行する、コンピュータが使用可能なコードまたは命令が置かれることが可能である。
【００１７】
次に図２を参照すると、例示的実施形態が実行されることが可能であるデータ処理システムのブロック図が示されている。データ処理システム２００は、図１のサーバ１０４またはクライアント１１０など、コンピュータの一例であり、この中に、処理を実行するための、コンピュータが使用可能なコードまたは命令が、例示的実施形態のために置かれることが可能である。この説明のための例では、データ処理システム２００が、プロセッサ・ユニット２０４と、メモリ２０６と、永続ストレージ２０８と、通信ユニット２１０と、入力／出力（Ｉ／Ｏ）ユニット２１２と、ディスプレイ２１４との間の通信を提供する通信ファブリック２０２を含む。
【００１８】
プロセッサ・ユニット２０４は、メモリ２０６にロードされることが可能であるソフトウェアの命令を実行するように機能する。プロセッサ・ユニット２０４は、特定の実行に応じて、１つまたは複数のプロセッサのセットとすることができる、またはマルチプロセッサ・コアとすることができる。さらにプロセッサ・ユニット２０４は、単一チップ上にメイン・プロセッサがセカンダリ・プロセッサと共に存在する、１つまたは複数の異種プロセッサ・システムを使用して実行されることが可能である。別の説明のための例として、プロセッサ・ユニット２０４は、同じタイプの複数のプロセッサを含んだ対称型マルチプロセッサ（ＳＭＰ）システムであってもよい。
【００１９】
メモリ２０６および永続ストレージ２０８は、記憶装置の例である。記憶装置は、一時的に、または永久的に、あるいはその両方に基づいて情報を格納することができるハードウェアのいかなる一部分でもある。これらの例ではメモリ２０６は、例えばランダム・アクセス・メモリまたは他の好適な揮発性もしくは不揮発性記憶装置であってもよい。永続ストレージ２０８は、特定の実行に応じて様々な形態をとることができる。例えば、永続ストレージ２０８は、１つまたは複数の構成要素またはデバイスを含むことができる。例えば、永続ストレージ２０８は、ハード・ドライブ、フラッシュ・メモリ、書換え可能光ディスク、書換え可能磁気テープ、または上記の何らかの組合せであってもよい。また永続ストレージ２０８によって使用される媒体は、取り外し可能であってもよい。例えば、リムーバブル・ハード・ドライブが、永続ストレージ２０８に使用されてもよい。
【００２０】
これらの例の通信ユニット２１０は、他のデータ処理システムまたはデバイスとの通信を提供する。これらの例では、通信ユニット２１０は、ネットワーク・インタフェース・カードである。通信ユニット２１０は、物理通信リンクと無線通信リンクのいずれかまたは両方を通じて通信を提供することができる。
【００２１】
入力／出力ユニット２１２は、データ処理システム２００に接続されることが可能である他のデバイスを用いたデータの入力および出力を可能にする。例えば、入力／出力ユニット２１２は、キーボードおよびマウスを通じたユーザ入力のための接続を提供することができる。さらに、入力／出力ユニット２１２は、プリンタに出力を送信することができる。ディスプレイ２１４は、情報をユーザに表示する機構を提供する。
【００２２】
オペレーティング・システムおよびアプリケーションのための命令、またはプログラムは、永続ストレージ２０８に置かれる。これらの命令は、プロセッサ・ユニット２０４による実行のために、メモリ２０６にロードされることが可能である。異なる実施形態のプロセスは、メモリ２０６などのメモリに置かれることが可能である、コンピュータにより実行される命令（computer implemented instruction）を使用して、プロセッサ・ユニット２０４によって行われることが可能である。これらの命令は、プロセッサ・ユニット２０４でプロセッサによって読み取られ、実行されることが可能であるプログラム・コード、コンピュータ使用可能プログラム・コード、またはコンピュータ可読プログラム・コードと呼ばれる。異なる実施形態のプログラム・コードは、メモリ２０６または永続ストレージ２０８など、異なる物理的または有形のコンピュータ可読媒体上で具体化されることが可能である。
【００２３】
プログラム・コード２１６は、選択的に取り外し可能であるコンピュータ可読媒体２１８上に関数形式で置かれ、プロセッサ・ユニット２０４によって実行されるように、データ処理システム２００上にロードされる、またはデータ処理システム２００に転送されることが可能である。これらの例では、プログラム・コード２１６およびコンピュータ可読媒体２１８が、コンピュータ・プログラム製品２２０を形成する。1つの例では、コンピュータ可読媒体２１８は、例えば、永続ストレージ２０８の一部であるハード・ドライブなど、記憶装置に転送するために、永続ストレージ２０８の一部であるドライブまたは他のデバイスに挿入されるまたは配置される光または磁気ディスクなど、有形の形式であってもよい。有形の形式で、コンピュータ可読媒体２１８は、データ処理システム２００に接続されるハード・ドライブ、サム・ドライブ、またはフラッシュ・メモリなど、永続ストレージの形をとることもできる。コンピュータ可読媒体２１８の有形の形式は、コンピュータ可読記憶媒体とも呼ばれる。場合によっては、コンピュータ可読媒体２１８は、取り外し可能ではないことがある。
【００２４】
あるいは、プログラム・コード２１６は、通信ユニット２１０への通信リンクを通じて、または入力／出力ユニット２１２への接続を通じて、あるいはその両方を通じて、コンピュータ可読媒体２１８からデータ処理システム２００に転送されてもよい。通信リンクまたは接続、あるいはその両方は、説明のための例では物理的なものまたは無線であってもよい。コンピュータ可読媒体は、プログラム・コードを含んだ通信リンクまたは無線伝送など、非有形の媒体の形をとることもできる。データ処理システム２００について示した様々な構成要素は、様々な実施形態が実行される可能性のある方法に構造上の制約を与えるものではない。様々な例示的実施形態は、データ処理システム２００について示した構成要素に追加の、またはそれらの代わりの構成要素を含んだデータ処理システムで実行されることが可能である。図２に示す他の構成要素は、図示した説明のための例とは異なる可能性がある。１つの例として、データ処理システム２００中の記憶装置は、データを格納することができるいかなるハードウェア装置でもある。メモリ２０６、永続ストレージ２０８、およびコンピュータ可読媒体２１８は、有形の形式の記憶装置の例である。
【００２５】
別の例では、通信ファブリック２０２を実行するためにバス・システムが使用されることがあり、システム・バスまたは入力／出力バスなど、１つまたは複数のバスで構成されることがある。当然ながら、バス・システムは、バス・システムにアタッチされた様々な構成要素またはデバイス間でデータの転送を行ういかなる好適なタイプのアーキテクチャを使用して実行されてもよい。また通信ユニットが、モデム、またはネットワーク・アダプタなど、データを送受信するために使用される１つまたは複数のデバイスを含むことがある。さらに、メモリが、例えば、メモリ２０６または通信ファブリック２０２に存在することがあるインタフェースおよびメモリ・コントローラ・ハブに見つけられるキャッシュであってもよい。
【００２６】
開示する主題の動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋、Ｃ＃、オブジェクティブＣ、もしくは同様のものなどのオブジェクト指向プログラミング言語、および伝統的な手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語のいかなる組合せで書かれることも可能である。プログラム・コードは、Ｐｙｔｈｏｎなど、インタプリタ型言語で書かれることも可能である。プログラム・コードは、すべてユーザのコンピュータ上で、スタンドアロン型ソフトウェア・パッケージとして一部をユーザのコンピュータ上で、一部をユーザのコンピュータ上でかつ一部をリモート・コンピュータ上で、またはすべてリモート・コンピュータもしくはサーバ上で、実行することができる。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）もしくはワイド・エリア・ネットワーク（ＷＡＮ）などの、任意のタイプのネットワークを通じてユーザのコンピュータに接続することができる、または（例えば、インターネット・サービス・プロバイダを使用してインターネットを通じて）外部コンピュータへの接続を行うことができる。本明細書の技法は、非伝統的なＩＰネットワークにおいて実行されることも可能である。
【００２７】
図１〜２のハードウェアは、実行に応じて変わる可能性があることが、当業者には理解されよう。フラッシュ・メモリ、同等の不揮発性メモリ、または光ディスク・ドライブなど、他の内部ハードウェアまたは周辺デバイスが、図１〜２に示されるハードウェアに加えて、またはこれに代えて使用されてもよい。また、例示的実施形態のプロセスは、開示する主題の範囲を逸脱することなく、前述のＳＭＰシステム以外の、マルチプロセッサ・データ処理システムに適用されることが可能である。
【００２８】
以下でわかるように、本明細書に記載する技法は、クライアント・マシンが、１つまたは複数のマシンのセット上で実行中の、インターネットでアクセスできるウェブベースのポータルと通信する、図１に示すような、標準的なクライアント−サーバの枠組み内で併せて動作することができる。エンド・ユーザが、ポータルにアクセスし、ポータルと対話することができるインターネットに接続可能なデバイス（例えば、デスクトップ・コンピュータ、ノートブック・コンピュータ、インターネット対応モバイル・デバイスなど）を操作する。一般的に、各クライアントまたはサーバ・マシンは、ハードウェアおよびソフトウェアを含んだ、図２に示すようなデータ処理システムであり、これらのエンティティが、インターネット、イントラネット、エクストラネット、プライベート・ネットワーク、またはその他の通信媒体もしくはリンクなどのネットワークによって互いに通信する。データ処理システムは、一般的に、１つまたは複数のプロセッサと、オペレーティング・システムと、１つまたは複数のアプリケーションと、１つまたは複数のユーティリティとを含む。データ処理システム上のアプリケーションは、ＨＴＴＰ、ＳＯＡＰ、ＸＭＬ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬのためのサポートを含むが、これらに限らない、ウェブ・サービスのためのネイティブ・サポートを提供する。ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬに関する情報は、これらの標準の開発および保守に関与しているワールド・ワイド・ウェブ・コンソーシアム（World Wide Web Consortium：Ｗ３Ｃ）から入手でき、ＨＴＴＰおよびＸＭＬに関するさらなる情報は、インターネット・エンジニアリング・タスク・フォース（Internet Engineering Task Force：ＩＥＴＦ）から入手できる。これらの標準を熟知しているものと考える。
【００２９】
ブロードキャスト暗号化
以下に説明するように、この開示の技法は、「ブロードキャスト暗号化」として知られている既知の鍵管理技法を利用する。以下の段落は、この技法に関するさらなる背景の詳細を提供する。
【００３０】
ブロードキャスト暗号化は、公開鍵暗号に代わるものである。公開鍵暗号とは異なり、ブロードキャスト暗号化は、二者が双方向の会話を常にすることなく鍵について合意することを可能にする。一般に、ブロードキャスト暗号化は、発信者がデータの特別なブロックを受信者に送信することによって機能する。特別なデータ・ブロックは、セッションまたは管理キー・ブロックと呼ばれることもあるが、これにより参加しているデバイスは、管理キーと呼ばれる鍵を計算できるようになる。管理キー・ブロックは、初期の実行においては媒体キー・ブロックと呼ばれることもある。各デバイスは、デバイスがこの計算を行うことを可能にするデバイス・キーのセットを有する。各デバイスは、異なる方法で計算を行い、デバイスの鍵が危険にさらされる場合、新しい管理キー・ブロックが作成され、それらの危険にさらされた鍵は、もはや管理キーを計算するために使用されることはない。一般的に、管理キー・ブロックは、単一の信頼される機関またはエンティティによって作成され、またこの機関またはエンティティはすべてのデバイスにその鍵を割り当てる。管理キー・ブロックは、メッセージを送信することを望む可能性があるシステム中のすべてのデバイスに配布される。メッセージを送信するには、発信者は、管理キー・ブロックを処理して管理キーを取得し、次にこれを使用してメッセージを暗号化する。メッセージに使用される管理キーは、デバイスの信頼レベルによって異なる可能性があり、このような異なる各鍵を管理キー・バリアントと呼ぶことがある。発信者は次に、暗号化されたメッセージと、管理キー・ブロックの両方を受信者に送信する。受信者は、管理キー・ブロックをその独自の方法で処理し、管理キーを取得し、メッセージを解読する。
【００３１】
ブロードキャスト暗号化方式の知られているインスタンス化が、ＩＢＭ（Ｒ）の高度なセキュア・コンテンツ・クラスタ技術（Advanced Secure Content Cluster Technology：ＡＳＣＣＴ）であり、これは例えば、顧客が自宅に娯楽コンテンツのライブラリを有することができ、そのライブラリを顧客が所有するすべてのデバイスによって自由に閲覧されるようにしたい場合に役立つ。ＡＳＣＣＴは、ブロードキャスト暗号化を使用して、デバイスのクラスタを構築し、コンテンツはこれに暗号でバインドされて、不正コピーを防止することができる。ＡＳＣＣＴは、管理キー・ブロック（ＭＫＢ）に基づいたブロードキャスト暗号化を使用する。ＡＳＣＣＴデバイスは、ネットワーク上で一連のメッセージを交換して、デバイスのクラスタを確立し、デバイスのそれぞれは、同じ管理キー・ブロックを共有する。ＡＳＣＣＴデバイスは、その一連の秘密デバイス・キーを使用してＭＫＢを処理し、それによって秘密鍵を取得し、クラスタに参加し、保護されたコンテンツにアクセスすることが可能になる。ＭＫＢとデバイス・キーの両方が、ブロードキャスト暗号化システムの管理を行うライセンス許可機関によって発行される。
【００３２】
ＡＳＣＣＴプロトコルおよびそのブロードキャスト暗号化機構を実行するデバイスは、鍵管理ブロック（ＫＭＢ）を処理することによって生成されるものとは異なる（バインド・キー（Ｋｂ）と呼ばれる）鍵でコンテンツを暗号化することによって、デバイスが保護するコンテンツを特定のエンティティ（例えば、ホームネットワークまたはクラスタ）に「バインドする」。一般的に、（媒体、デバイス、またはユーザであるかどうかにかかわらず）特定のエンティティにコンテンツをバインドする現在の手法は、暗号鍵の計算において１つのレベルの間接（one level of indirection）を介している。これらの場合、一般的に、コンテンツを暗号化する手続きは、基本的に次の通りである。まず、ＫＭＢを処理することによって、管理キー（Ｋｍ）が抽出される。次に、このコンテンツがバインドされているエンティティを一意に識別するデータ上で、一方向関数が行われる（ＩＤｂと呼ばれる）。その結果、バインド・キーＫｂ＝Ｇ（Ｋｍ，ＩＤｂ）となる。コンテンツに対するランダム・タイトル・キー（Ｋｔ）が選択され、Ｋｂを使用して暗号化される。その結果、暗号化されたタイトル・キー、すなわちＥＫｔ＝Ｅ（Ｋｂ，Ｋｔ）となる。コンテンツは、次に選択されたランダム・キーで暗号化され、結果として生じる暗号化されたコンテンツは、依然として暗号化されたタイトル・キーと関連付けられている。同じＫＭＢ、ＩＤｂ、および暗号化されたタイトル・キーにアクセスできるいかなる対応デバイスも、同じＫｂを再生し、Ｋｔを解読することによって、コンテンツを解読することができる。
【００３３】
複数のデバイス・クラス／階層（すなわち、複数管理キー／バリアント）で機能するように、このような知られているブロードキャスト暗号化方式を拡張することが提案されている。このために、「統一」ＭＫＢと呼ばれる新しい「タイプ」のＭＫＢが提案されている。ＭＫＢにより、対応デバイスがＫｍだけでなく、他の鍵も同様に計算できるようになる。これらの他の鍵は、２つのタイプの鍵、すなわち管理キー・バリアント（Ｋｍｖ１、Ｋｍｖ２など）と、記録キー（Ｋｒ１、Ｋｒ２など）とを含む。提案されるＡＳＣＣＴ拡張では、管理キー・バリアントは、法的調査（forensic）の目的で使用される鍵であり、用意されたコンテンツは、様々な同等バリエーション（equivalent variations）で書かれている。好ましくは、単一デバイスが、単一Ｋｍｖのみを計算する。記録キーは、管理キー・バリアントと同様であるが、コンテンツがローカルでクラスタに記録されているときに使用され、コンテンツは、組み込まれたバリエーション（built-in variations）を持たない。初期のＡＳＣＣＴ方式では、デバイスが、そのデバイス・キー（Ｋｄ）を使用して、管理キー（Ｋｍ）を直接導出した。この提案される拡張では、デバイスが、その管理キー・バリアントを導出することができ、そのバリアント番号を使用することから「ベース」管理キー（Ｋｍ）を導出することができる。
【００３４】
さらに、統一ＭＫＢは、管理キー・プリカーソル（Management KeyPrecursors）（Ｋｍ（−ｉ））の概念を導入する。この構成を用いて、デバイスは、（ＭＫＢサブセット設計により）セキュリティ・クラス番号「ｉ」を割り当てられ、それらの管理キー・バリアントから管理キー・プリカーソルＫｍ（−ｉ）を導出することができる。より高いセキュリティ・クラスのデバイスは、より高い「ｉ」値を割り当てられる。ベース・セキュリティ・クラスは、Ｋｍ（０）である。ベース・セキュリティ・クラスよりも高いセキュリティ・クラスのデバイスは、次に、管理キーの代わりに管理キー・プリカーソルＫｍ−１を計算することができる。「ｉ」という指数は、特定のセキュリティ・クラスを示す。より高いセキュリティ・クラスを有するデバイスは、次の一方向性関数を使用してベースＫｍ０値に至るまで、より劣るセキュリティ・クラスのデバイスのプリカーソル（すなわち、より小さい「ｉ」値を持つ管理キー・プリカーソル）を計算することができる：
Ｋｍ−（ｉ−１）＝ＡＥＳ＿Ｇ（Ｋｍ−（ｉ），ｋｃｄ）、ここでｋｃｄは鍵空間固有の定数である。
【００３５】
クラウド・コンピューティング・モデル
クラウド・コンピューティングは、最小限の経営努力またはサービスの提供者との対話で迅速にプロビジョニングし、リリースすることができる設定可能なコンピューティング・リソース（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）の共有プールへの便利で、オンデマンドのネットワーク・アクセスを可能にするためのサービス配信のモデルである。このクラウド・モデルは、２００９年１０月７日付けの、Ｐｅｔｅｒ  ＭｅｌｌおよびＴｉｍ  Ｇｒａｎｃｅによる「Draft NIST Working Definition of Cloud Computing」に、より詳細に記載され、定義されるように、少なくとも５つの特徴、少なくとも３つのサービス・モデル、および少なくとも４つの展開モデルを含むことができる。
【００３６】
詳細には、以下が、典型的な特徴である：
オンデマンドのセルフサービス：クラウドの顧客が、サービスの提供者との人的対話を必要とせず、必要に応じて自動的に、サーバ時刻およびネットワーク・ストレージのようなコンピューティング機能を一方的にプロビジョニングすることができる。
広範なネットワーク・アクセス：機能は、ネットワークを通じて利用でき、異種のシン・クライアントまたはシック・クライアントのプラットフォーム（例えば、携帯電話、ラップトップ、およびＰＤＡ）による利用を促進する標準的機構によりアクセスされる。
リソースのプール：プロバイダのコンピューティング・リソースは、マルチテナント・モデルを使用する複数の消費者に、需要に従って動的に割当ておよび再割当てされる異なる物理リソースおよび仮想リソースを供給するためにプールされる。消費者は一般的に、提供されるリソースの正確な位置について制御できないまたは知識がないという点において、位置独立（location independence）の感覚があるが、より高い抽象レベルの位置（例えば、国、州、またはデータセンタ）を指定することができることがある。
高速伸縮性：機能は、場合によっては自動的に、迅速かつ弾力的にプロビジョニングされて、速やかにスケール・アウトし、迅速に解放されて速やかにスケール・インすることができる。顧客には、プロビジョニングに利用できる機能は無制限であるように見えることが多く、いつ、いかなる量でも購入可能である。
サービスの計測：クラウド・システムは、サービスのタイプ（例えばストレージ、処理、帯域幅、およびアクティブ・ユーザ・アカウント）に適切なある抽象レベルで計測機能を活用することにより、リソースの利用を自動的に制御し、最適化する。利用されるサービスの提供者と消費者の両方に透明性（transparency）を提供して、リソースの利用を、監視、制御、および報告することができる。
【００３７】
サービス・モデルは、一般的に以下のようである：
サービスとしてのソフトウェア（Software as a Service：ＳａａＳ）：消費者に提供される機能は、クラウド・インフラストラクチャ上で実行中のプロバイダのアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザのようなシン・クライアント・インタフェースを通じて様々なクライアント・デバイスからアクセス可能である（例えば、ウェブベースの電子メール）。消費者は、限られたユーザ指定アプリケーションの構成設定の可能性を除いて、ネットワーク、サーバ、オペレーティング・システム、ストレージ、または個々のアプリケーション機能など、根底にあるクラウド・インフラストラクチャを管理または制御しない。
サービスとしてのプラットフォーム（Platform as a Service：ＰａａＳ）：消費者に提供される機能は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された消費者が作成したまたは取得したアプリケーションを、クラウド・インフラストラクチャに配備することである。消費者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージなど、根底にあるクラウド・インフラストラクチャを管理または制御しないが、配備されるアプリケーションおよび場合によってはアプリケーション・ホスト環境の設定を制御する。
サービスとしてのインフラストラクチャ（Infrastructure as aService：ＩａａＳ）：消費者に提供される機能は、処理、ストレージ、ネットワーク、ならびに消費者がオペレーティング・システムおよびアプリケーションを含むことができる任意のソフトウェアを配備し、実行することができる他の基本的コンピューティング・リソースをプロビジョニングすることである。消費者は、根底にあるクラウド・インフラストラクチャを管理または制御しないが、オペレーティング・システム、ストレージ、配備されるアプリケーションの制御、および場合によっては選択ネットワーキング構成要素（例えばホスト・ファイヤウォール）の限られた制御を行う。
【００３８】
展開モデルは一般的に以下のようである：
プライベートクラウド：クラウド・インフラストラクチャは、単に組織のために運営される。クラウド・インフラストラクチャは、この組織または第三者によって管理されることが可能であり、自社運用型（on-premises）または他社運用型（off-premises）とすることができる。
コミュニティ・クラウド：クラウド・インフラストラクチャはいくつかの組織によって共有され、共有されるもの（例えば、任務、セキュリティ要件、ポリシー、およびコンプライアンス考慮事項）を有する特定のコミュニティをサポートする。クラウド・インフラストラクチャは、この組織または第三者によって管理されることが可能であり、自社運用型または他社運用型とすることができる。
パブリック・クラウド：クラウド・インフラストラクチャは、一般の人々または大規模な企業団体に利用可能にされ、クラウド・サービスを販売する組織によって所有される。
ハイブリッド・クラウド：クラウド・インフラストラクチャは、固有のエンティティのままでありながら、データおよびアプリケーションの移植を可能にする標準化技術または独自技術（例えば、クラウド間の負荷バランシングのためのクラウド拡張（cloud bursting））によって結合された、２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）の組合せである。
【００３９】
クラウド・コンピューティング環境は、ステートレス性、疎結合性、モジュール性、および意味的相互運用性（semantic interoperability）に重点を置いたサービス指向である。クラウド・コンピューティングの中心には、相互接続されたノードのネットワークを含むインフラストラクチャがある。代表的なクラウド・コンピューティング・ノードは、上記の図２に示される通りである。詳細には、クラウド・コンピューティング・ノードには、コンピュータ・システム／サーバがあり、数多くの他の汎用または特殊用途コンピューティング・システム環境または構成で動作可能である。コンピュータ・システム／サーバと共に使用するのに適している可能性がある、よく知られているコンピューティング・システム、または環境、または構成、あるいはその組合せの例には、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドもしくはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサベースのシステム、セット・トップ・ボックス、プログラマブル家庭用電化製品、ネットワークPC、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上記のシステムもしくはデバイスなどのいずれかを含む分散クラウド・コンピューティング環境が含まれるが、これらに限定されない。コンピュータ・システム／サーバは、コンピュータ・システムによって実行される、プログラム・モジュールなどの、コンピュータ・システム実行可能命令の一般的な状況で説明されることが可能である。一般的に、プログラム・モジュールは、特定のタスクを行うまたは特定の抽象データ型を実行するルーチン、プログラム、オブジェクト、構成要素、論理、データ構造などを含むことができる。コンピュータ・システム／サーバは、タスクが、通信ネットワークを介してリンクされたリモート処理装置によって行われる、分散クラウド・コンピューティング環境で実施されることが可能である。分散クラウド・コンピューティング環境では、プログラム・モジュールが、メモリ記憶装置を含んだローカルとリモートの両方のコンピュータ・システム記憶媒体に置かれることが可能である。
【００４０】
次にさらなる背景として図３を参照して、クラウド・コンピューティング環境によって提供される機能抽象化レイヤのセットが示される。図３に示す構成要素、レイヤ、および機能は、単に例示となることを意図しており、本発明の実施形態はこれに限定されないことを、予め理解されたい。図示するように、次のレイヤおよび対応する機能が提供される：
ハードウェアおよびソフトウェア・レイヤ３００は、ハードウェア構成要素およびソフトウェア構成要素を含む。ハードウェア構成要素の例には、メインフレーム、一例ではＩＢＭ（Ｒ）のｚＳｅｒｉｅｓ（Ｒ）システム、ＲＩＳＣ（Reduced Instruction Set Computer、縮小命令セット・コンピュータ）アーキテクチャに基づくサーバ、一例ではＩＢＭのｐＳｅｒｉｅｓ（Ｒ）システム、ＩＢＭのｘＳｅｒｉｅｓ（Ｒ）システム、ＩＢＭのＢｌａｄｅＣｅｎｔｅｒ（Ｒ）システム、ストレージ・デバイス、ネットワークおよびネットワーキング構成要素が含まれる。ソフトウェア構成要素の例には、ネットワーク・アプリケーション・サーバ・ソフトウェア、一例ではＩＢＭのＷｅｂＳｐｈｅｒｅ（Ｒ）アプリケーション・サーバ・ソフトウェア、およびデータベース・ソフトウェア、一例ではＩＢＭのＤＢ２（Ｒ）データベース・ソフトウェアが含まれる。（ＩＢＭ、ｚＳｅｒｉｅｓ、ｐＳｅｒｉｅｓ、ｘＳｅｒｉｅｓ、ＢｌａｄｅＣｅｎｔｅｒ、ＷｅｂＳｐｈｅｒｅ、およびＤＢ２は、世界中の多くの管轄で登録されているインターナショナル・ビジネス・マシーンズ（International Business Machines Corporation）の商標である。
仮想化レイヤ３０２は、仮想エンティティの以下の例を提供することができる抽象化レイヤを提供する。すなわち、仮想サーバ、仮想ストレージ、仮想プライベート・ネットワークなどの仮想ネットワーク、仮想アプリケーションおよびオペレーティング・システム、ならびに仮想クライアントを提供することができる抽象化レイヤを提供する。
【００４１】
１つの例では、管理レイヤ３０４は、以下に記載する機能を提供することができる。リソース・プロビジョニングは、クラウド・コンピューティング環境内でタスクを行うために使用されるコンピューティング・リソースおよび他のリソースの動的な調達を行う。計測および価格決定は、クラウド・コンピューティング環境内でリソースが利用されるに従ってコスト追跡すること、およびこれらのリソースの消費に対して課金もしくは請求を行うことを提供する。１つの例では、これらのリソースは、アプリケーション・ソフトウェアのライセンスを含むことができる。セキュリティは、クラウド消費者およびタスクのアイデンティティ確認、ならびにデータおよび他のリソースのための保護を行う。ユーザ・ポータルは、消費者およびシステム管理者のためにクラウド・コンピューティング環境にアクセスできるようにする。サービス・レベル管理は、必要とされるサービス・レベルが満たされるように、クラウド・コンピューティング・リソース割当ておよび管理を提供する。サービス・レベル合意（ＳＬＡ）計画および履行は、ＳＬＡに従って将来必要となることが予想されるクラウド・コンピューティング・リソースの事前手配および調達を行う。
【００４２】
ワークロード・レイヤ３０６は、クラウド・コンピューティング環境がそのために利用されることがある機能の例を提供する。このレイヤから提供することができるワークロードおよび機能の例には、マッピングおよびナビゲーション、ソフトウェア開発およびライフサイクル管理、仮想教室教育配信、データ分析処理、トランザクション処理、およびこの開示に従って、仮想鍵管理システム（ＶＫＭＳ）が含まれる。
【００４３】
この開示は、クラウド・コンピューティングに関する詳細な説明を含んでいるが、本明細書で説明する教示内容の実行は、クラウド・コンピューティング環境に限定されないことを予め理解されたい。むしろ本発明の諸実施形態は、現在知られている、または将来開発される、他のいかなるタイプのコンピューティング環境とも関連して実行されることが可能である。
【００４４】
したがって、代表的なクラウド・コンピューティング環境は、フロント・エンドアイデンティティ・マネージャと、ビジネス・サポート・サービス（ＢＳＳ）機能構成要素と、運用サポート・サービス（ＯＳＳ）機能構成要素と、コンピュート・クラウド構成要素（compute cloud componen）とを含む、高レベル機能構成要素のセットを有する。アイデンティティ・マネージャは、要求中のクライアントと対話して、アイデンティティ管理を提供することを担当し、この構成要素は、ニューヨーク州アーモンク市のＩＢＭ社から入手可能であるTivoli Federated Identity Manager（ＴＦＩＭ）など、１つまたは複数の知られているシステムを用いて実行されることがある。適切な環境では、ＴＦＩＭは、他のクラウド構成要素への連合シングル・サインオン（federated single sign-on：Ｆ−ＳＳＯ）を提供するために使用されることが可能である。ビジネス・サポート・サービス構成要素は、課金サポートなど、ある管理機能を提供する。運用サポート・サービス構成要素は、仮想マシン（ＶＭ）インスタンスなど、他のクラウド構成要素のプロビジョニングおよび管理を提供するために使用される。クラウド構成要素は、主要な計算リソースを表し、これらは一般的に、クラウドを介したアクセスに利用可能にされているターゲット・アプリケーションを実行するために使用される複数の仮想マシン・インスタンスである。１つまたは複数のデータベースが、ディレクトリ、ログ、および他の作業データを格納するために使用される。これらの構成要素（フロント・エンド・アイデンティティ・マネージャを含む）のすべてが、クラウド「内」に配置されるが、これは必要条件ではない。代替的実施形態では、アイデンティティ・マネージャは、クラウドの外部で運用されてもよい。サービス・プロバイダもまた、クラウドの外部で運用されてもよい。
【００４５】
いくつかのクラウドは、非伝統的なＩＰネットワークに基づいている。したがって、例えばクラウドが、特別な単一層がＭＡＣアドレスのハッシュを使用してＩＰルーティングする２層のＣＬＯＳベースのネットワークに基づくことがある。本明細書に記載する技法は、このような非伝統的クラウドに使用されることが可能である。
【００４６】
図４は、リソースの仮想化をサポートする典型的なＩＴインフラストラクチャを示す。説明のために、共有（パブリック）リソースを提供するＩＴデータセンタは、「プロバイダ」であり、これらの共有リソースを使用してそのデータおよびアプリケーションを（あらゆる形式で）ホストする、格納する、および管理する顧客または会社は、「加入者」（または「顧客」もしくは「テナント」）である。図４では、例示の仮想マシンがホストしている環境（あるいは本明細書ではデータセンタまたは「クラウド」と呼ばれる）が示されている。この環境は、一般的にハイパーバイザ管理ＶＬＡＮ４０６を介して物理データセンタ・ネットワーク４０４に接続されたホスト・マシン（ＨＶ）４０２（例えば、サーバもしくは同様の物理マシン・コンピューティング・デバイス）を含む。明示的に示していないが、一般的にこの環境は、ロード・バランサ、ネットワーク・データ・スイッチ（例えば、トップ・オブ・ラック（top-of-rack）スイッチ）、ファイアウォールなども含む。図４に示すように、物理サーバ４０２は、それぞれ仮想化技術を使用して１つまたは複数の仮想マシン（ＶＭ）４０８を動的に提供するように構成される。このような技術は、例えばＶＭｗａｒｅ（Ｒ）またはその他から市販されている。サーバ仮想化は、当技術分野においてよく知られている技法である。図に示すように、複数のＶＭが単一のホスト・マシンに配置され、ホスト・マシンのＣＰＵ、メモリ、および他のリソースを共有し、それによって組織のデータセンタの利用を増やすことができる。この環境では、テナント・アプリケーション４１０が、ネットワーク機器４１２でホストされ、テナント・データがデータ・ストアおよびデータベース４１４に格納される。アプリケーションおよびデータ・ストアは、一般的にネットワーク管理／ストレージＶＬＡＮ４１６を介して物理データセンタ・ネットワーク４０４に接続される。集合的に、仮想マシン、アプリケーション、およびテナント・データが、加入者がアクセス可能な仮想化されたリソース管理領域４０５を表す。この領域を介して、加入者の従業員は、プロバイダによって割り振られ、物理ＩＴインフラストラクチャによって後援される、仮想化されたリソースに（様々な役割ベースの特権を使用して）アクセスし、これを管理することができる。インフラストラクチャの下部は、プロバイダがアクセス可能な管理領域４１５を示す。この領域は、プロバイダ従業員管理ポータル４１８と、ＢＳＳ／ＯＳＳ管理機能４２０と、様々なアイデンティティおよびアクセス管理機能４２２と、セキュリティ・ポリシー・サーバ４２４と、サーバ・イメージ４２８を管理するための管理機能４２６とを含む。これらの機能は、管理ＶＬＡＮ４３０を介して物理データセンタ・ネットワークにインタフェースする。プロバイダの従業員は、ＩＴデータセンタ・インフラストラクチャを管理するために使用する運用支援サービスおよびビジネス支援サービス（Operational and Business Support Services：ＯＳＳ／ＢＳＳ）にアクセスできる、専門特権（およびおそらく特定のクライアント／ネットワーク）を有する（例えば、ハードウェアおよびソフトウェアのインストール、構成、監視、技術サポート、課��など）。
【００４７】
仮想鍵管理システム（ＶＫＭＳ）
上記を背景として、次にこの開示の主題について説明する。以下でわかるように、本明細書の技法は、ＭＫＢおよび複数の管理キー・バリアントを用いたブロードキャスト暗号化に基づく仮想鍵管理システムおよびプロトコルを使用して、第三者またはパブリック（クラウド）データセンタ内で実行されているアプリケーションおよびデータの顧客のエンドツーエンドのセキュリティを支援し、このような重要な扱いを要する、個人的なデータが、共同テナント化および仮想化されることが可能となる。以下に説明するように、ブロードキャスト暗号化の管理キー・バリアントが、第三者データセンタ内で使用されて、テナントごとに（顧客ごとに）仮想鍵管理領域を作成し、特定の顧客のデータが、プロバイダのデータセンタのＩＴインフラストラクチャにおいて共同テナント化される、格納される、送信される、または仮想化されるときはいつでも、セキュリティ保護されるようにする。この手法は、顧客のデータ（汎用データと汎用アプリケーションの両方を含む）を他の顧客のデータから分離し、したがって、他のテナント（またはその他）が、データ／アプリケーション／メッセージにアクセスしようとし、これを用いて他のテナントのデータが格納される、実行される、もしくは仮想化される（例えば、同じデータベースもしくはデータ・ストアで格納される、同じウェブ・サーバ、ハイパーバイザ、ルータ内で実行されるなど）ことによる攻撃を阻止する。以下でわかるように、本明細書で使用されるブロードキャスト暗号化は、好ましくは管理キー・バリアントに割り当てられる様々な信頼レベルで、事前にブロードキャストされた（デバイスまたはアプリケーション）キーを使用して対称暗号化の単純化を提案するという点で、共同テナント化および仮想化されたデータを保護するという問題への堅牢なソリューションを提供する。この手法は、他の鍵管理システム、例えばＰＫＩなど、プロトコルおよびインタフェースを導入するという複雑さならびにデータセンタ内のアプリケーションごとの鍵ペアの生成を必要とし、必要もしくは所望され得る様々な信頼レベルを構成しない鍵管理システムを不要にする。さらに、以下でわかるように、この手法はまた、顧客が共同テナント化／共有リソース上の顧客のデータを分離するのに必要な粒度で、システムＩＴリソースを取り消すおよび分類するための統合制御を可能にする。
【００４８】
図５は、図４に関して上述したプロバイダ・インフラストラクチャに追加された仮想鍵管理システム（ＶＫＭＳ）５００の代表的な実施形態を示す。以下でわかるように、ＶＫＭＳおよびその関連プロトコルは、共同テナント化されたＩＴインフラストラクチャにおいて（およびインフラストラクチャのすべてのレベルで）リソースのいかなる組合せにも使用することができるデータのテナントごとの（およびさらにアプリケーションごとの）セキュアにされた分離を実現するために仮想化されることが可能である。本明細書のこの技法は、共有（またはクラウド）データセンタ内で使用されるＩＴシステム・インフラストラクチャのすべてのレベル（リソース）で、およびこれらの間で、これらのデータセンタ内の暗号化によるセキュリティを可能にする。このようなＩＴシステム・インフラストラクチャは、ネットワーク（例えば、スイッチ、ロード・バランサ、およびルータなど）、ストレージ（例えば、ハード・ドライブ、ネットワーク接続ストレージ、メモリなど）、ホスト・システム・ソフトウェア(例えば、アプリケーション・プロセッサ、ＣＰＵなど)、サーバ（例えば、プロキシ、アプリケーション・サーバ、ウェブ・サーバなど）、ならびにホストされるソフトウェアを含むが、これらに限定されない。上記のように、顧客またはテナント・データに適用するデータという用語は、汎用データ（送信中でも、静止でも）とソフトウェア・アプリケーションの両方を指すことがある。
【００４９】
一般的には、ＶＫＭＳが、加入者（テナント）制御鍵管理システムを仮想化し、鍵管理プロトコルを使用して、多様な共有インフラストラクチャにわたってエンドツーエンドのセキュリティを管理する。
【００５０】
ＶＫＭＳ５００が、プロバイダがアクセス可能な管理領域５１５内にハードウェア・リソースおよびソフトウェア・リソースの好ましく分離された、専用のセットを含む。一般に、ＶＫＭＳ５００は、すべての暗号キー材料（例えば、領域固有の鍵管理システム・パラメータ、構成、鍵、デバイス、および構成要素識別子など）をセキュアに管理する。ＶＫＭＳ５００は、ＶＫＭＳ領域データ５０８が格納されたＶＫＭＳ領域データ・ボールト（VKMS Domain Data Vault）５０６と関連してＶＫＭＳサービス５０４を提供する仮想鍵管理サーバ５０２を含む。サーバ５０２は単一の統合されたインスタンスとして示されているが、これは限定ではなく、サーバ（およびそのサービスおよびデータ・ボールト）は、複数の物理マシン、ネットワーク、および場所にわたって配置されることもある。
【００５１】
図６は、仮想鍵管理システム（ＶＫＭＳ）６００の代表的な要素をより詳細に示す。本明細書の用語は、例示のために使用されており、開示の主題を限定するととらえられるべきではない。
【００５２】
この開示によれば、ＶＫＭＳ（データ）領域（ＶＫＭＤ）６０２が、特定の顧客またはテナントと関連付けられる。詳細には、顧客が、そのセキュリティおよび分離要件に基づいて、ＩＴ環境に置くことを希望するアプリケーションの中で、およびデータの同じ共有の権利があるのはどれかに応じて、所望レベルの粒度を選択する。例えば、顧客が、各アプリケーションが他のものから分離され、分割されることを必要とするセキュリティ・ポリシーを有することがある。さらに他のものは、２つ以上のアプリケーションが、同じデータを共有できるようにすることがある。所望の粒度に応じて、顧客またはプロバイダは、（例えばウェブベースのインタフェースまたは構成ツールを使用して）１つまたは複数の「データ領域」を定義し、そのそれぞれが、本明細書に記載する技法を使用して他のものから分離され、セキュリティ保護されることが可能である。顧客が、２つ以上のＶＫＭＤを有することができる。各ＶＫＭＤデータ領域は、その独自の一意のＶＫＭＤ識別子（ＶＫＭＤ−ＩＤ）６０４を有し、これは、ＶＫＭＤのための一意（ユニバーサル一意、または少なくとも所与のＶＫＭＳ内で一意）の識別子である。各ＶＫＭＤは、仮想管理鍵ブロック（ＶＭＫＢ）６０８、（仮想デバイス、機器、アプリケーション、クライアント・デバイス、サーバ・デバイス、データベース、ソフトウェア構成要素、ストレージ媒体、ＩＴリソースなどのための）デバイス・キー６１０を確立するのに必要とされる構成およびパラメータを含んだ関連ＶＫＭＳ領域データ（ＶＫＭＳ−ＤＤ）６０６を有し、これらはＶＫＭＳ内の特定のデータ領域と一意に関連付けられる。したがって、ＶＫＭＤとＶＫＭＳ−ＤＤのセットとの間に１対１のマッピングが存在する。一般的に、また以下でわかるように、ＶＫＭＳ−ＤＤ６０６は、ＶＫＭＤを開始し、構成するのに使用される暗号化パラメータのセットを含む。
【００５３】
ＶＫＭＳはまた、ＶＫＭＳ領域データ・ボールト（ＶＫＭＳ−ＤＤＶ）６１２を含み、これは、１つまたは複数のＶＫＭＤ（すなわち、ＶＫＭＳが管理するすべてのＶＫＭＤ）のために、ＶＭＫＢ６０８、デバイス・キー６１０などの暗号化材料を収容するために使用されるセキュアなリポジトリであるＶＫＭＳ構成要素である。複数のボールトがあってもよい。ＶＫＭＳサーバ（ＶＫＭＳ−Ｓ）６１４は、共有されるＩＴ環境全体にセキュアにされた信頼の基点（root of trust）を提供する、高度にセキュアなホスト・システム（ハードウェアおよびソフトウェア）である。その基本機能は、１つまたは複数のＶＫＭＳデータ領域（およびその対応するデータ）を管理し、それぞれを他のものから分離することである。仮想管理鍵ブロック（ＶＭＫＢ）６１６は、（上述のように）特定の仮想データ領域（すなわち、ＶＫＭＤ）の管理キー・バリアント（Ｋｍｖ）を導出するために単に「機能する」ように（すなわち、暗号「解除される」または解読可能となるように）設計された管理キー・ブロック（ＭＫＢ）である。デバイス識別子（デバイスＩＤ）６１６は、プロバイダのＩＴインフラストラクチャ内にある各個々のアーキテクチャ構成要素と関連付けられる一意の識別子である。デバイスＩＤは、ＶＫＭＳサーバによって作成され、割り当てられる。好ましくはデバイスＩＤは、デバイスが関連（仮想）管理キー・ブロック（ＶＭＫＢ）から導出することができる最高のＫｍｖバリアントとなるものを示す「信頼」レベルのインジケータを含む。デバイスＩＤ６１６は、（仮想）管理キー・ブロック（ＶＫＭＢ）内の正確な暗号パスを決定して、それらのデバイス・キーを適切に適用するために使用される。「デバイスＩＤ」を割り当てられる、および「デバイスＩＤ」を受信する、ＩＴデータセンタ内のデバイスは、ハードウェア・デバイス（例えば、アプリケーション・サーバ、ネットワーク・ルータおよびスイッチ、クライアント端末、ストレージ・アレイなど）、ハードウェア機器（例えば、ストレージ機器、エンドポイント監視装置、侵入防止装置、ストレージおよびアプリケーション・サーバ機器など）、仮想デバイス（例えば、仮想ネットワーク・ルータおよびスイッチ、仮想ストレージ、仮想ＣＰＵなど）、ミドルウェア、プラットフォーム、ソフトウェア構成要素、ハイパーバイザ、仮想プラットフォーム、アプリケーション、アプリケーション・データ・ストアおよびデバイス（実在と仮想の両方）を含むが、これらに限定されない。構成要素ＩＤがＩＴインフラストラクチャのハードウェア構成要素とソフトウェア構成要素の両方を含めた、より一般的な用語として見られることが可能であるとき、デバイスＩＤを使用する代わりとして、構成要素ＩＤが参照されてもよい。構成要素ＩＤは、ほとんどのクラウド・コンピューティング機能がこのように提供されるように、より小さい単位のソフトウェア（サービス）によって使用されることが可能である。ＶＫＭＳサーバは、ＶＫＭＤを用いて各デバイスにデバイスＩＤをセキュアに作成し、割り振り、提供する。最終的に、デバイス・キー６１０は、関連仮想管理キー・ブロック（ＶＭＫＢ）から管理キー・バリアントを暗号で導出するためにＶＫ��Ｓの各デバイスによって割り当てられ、使用される、一意のセットの暗号キーである。
【００５４】
動作において、ＶＫＭＳサーバは、ＶＫＭＤを用いて各デバイスにデバイスＩＤをセキュアに作成し、割り振り、提供する。ＶＫＭＳサーバはまた、（「パス」導出のための）関連デバイスＩＤとともに管理キー・バリアント（Ｋｍｖ）を暗号「解除する」ために使用されるデバイス・キーを設計する。ＶＫＭＳサーバは、ＶＫＭＤ内で各デバイスにデバイス・キーをセキュアに作成し、割り振り、提供する。
【００５５】
図７は、代表的なＶＫＭＳ  ＤＤを示す。暗号パラメータは、一般的に、ＶＫＭＳが（ＶＫＭＳによってこの特定の領域にバインドされたデータを識別するために同様に使用される）一意のＶＫＭＤ−ＩＤを作成する際に直接または間接的に使用することができる加入者が要求する領域ＩＤである、ＩＤｖｄｏｍａｉｎと、暗号ブロック連鎖（ＣＢＣ）暗号化または解読チェーンの初めに使用される初期化ベクトル、ｉｖ０と、非対称暗号化方式（ＡＥＳ）ハッシング関数によって使用するハッシュ初期化子、ｈ０と、補助デバイス・キーおよび処理キーの計算に使用される、機密のアダプテーション固有の（confidential, adaptation-specific）シード・レジスタ（例えば、１２８ビット値）初期化子、ｓ０と、計算された記録キーに使用される、機密のアダプテーション固有の定数、ｒ０と、タイトル・キー・ブロックからタイトル・キーを計算するために使用される、機密のアダプテーション固有の定数、ｔ０と、計算される管理キーおよび管理キー・プリカーソルに使用される、鍵変換データ、機密のアダプテーション固有の定数を表す、Ｋｃｄとを含む。ＶＫＭＳ−ＤＤに含まれることがあるいくつかの追加の構成パラメータを表に示す。
【００５６】
図８は、ＶＭＫＳが顧客（テナント）／加入者のために、仮想鍵管理領域（ＶＫＭＤ）を作成し、初期化する方法を示す。上記のように、顧客が、１つまたは複数のＶＫＭＤを有する可能性があるが、各顧客のＶＫＭＤは、別の顧客のために作成された仮想鍵管理領域と必ずしも異ならない。より一般的には、顧客のＶＫＭＤは、その顧客に固有のものである。典型的な顧客またはテナントが、単一のＶＫＭＤを確立する。しかしながら、より大きいエンティティが、異なるラインのビジネスに別個のＶＫＭＤを作成し、法的考慮に対処する、またはそれらの組織内の異なるグループに対して別個のセキュリティ・ポリシーに対応する（accommodate）ことができる。
【００５７】
ルーチンは加入者Ａが、例えばその固定ＩＴリソースおよび管理コストを削減するために、パブリック「クラウド」プロバイダＡ（例えば、クラウド・データセンタ）の共有ＩＴリソースを利用することに決めるステップ８００から始まる。ステップ８０２において、加入者Ａは、（例えば、何らかのサービス・ライセンス契約またはＳＬＡにより）プロバイダＡとの取引を開始し、これにより加入者Ａがそのアプリケーションおよび非構造化データをプロバイダの共有インフラストラクチャに展開することが許可される（ＳＬＡがアプリケーションおよびデータの共有または共同テナント化を許可することを意味する）。これは、知られているビジネス・プロセスおよびモデルである。ステップ８０４において、プロバイダＡのＶＫＭＳサーバが、加入者にＶＫＭＤ識別子（ＶＫＭＤ−ＩＤ）を割り振り、返す。上記のように、ＶＫＭＤ−ＩＤは、その加入者アカウントと関連付けられ、ＶＫＭＤ−ＤＤＶ内に格納するためにＶＫＭＤ固有のデータと関連付けられることが可能である。限定ではないが、図７に示す表を参照して、ＶＫＭＤ−ＩＤは、加入者がＶＫＭＳ−ＤＤの一部として提供したIDvdomainとすることができる、またはIDvdomainから導出される、または（例えば、ＶＫＭＳ内の一意性を保証するＵＲＩ命名規則の一部として）IDvdomainを含むことができる。さらに、他のデータが、限定ではないが、ＶＫＭＳ−ＤＤ、デバイスＩＤ、デバイス・キー、ＶＫＭＢ、任意のアソシエーション、ＶＫＭＤメタデータなどの、ＶＫＭＤ−ＩＤと関連付けられることが可能である。この例のシナリオでは、アカウントあたり単に１つのＶＫＭＤがあると仮定されるが、プロバイダが、アカウントあたり複数のＶＫＭＤを管理する手段をサポートすることができ、いずれの場合にも、ＶＫＭＳサーバは、次に追加のＶＫＭＤ−ＩＤおよび関連ＶＫＭＳ−ＤＤ、デバイスＩＤ、デバイス・キー、および各ＶＫＭＤのＶＫＭＢを作成する／追跡することになる。
【００５８】
ルーチンは次にステップ８０６に進み、加入者Ａが、領域固有のＶＫＭＳ−ＤＤのその所望のセットをプロバイダＡに送信するためにセキュアな手段を配列し、そのＶＫＭＳ−ＤＤボールト内にＶＫＭＳ−ＤＤをセキュアに格納し、それを加入者ＡのＶＫＭＤ−ＩＤに関連付ける。このセキュアな手段は、加入者とプロバイダとの間で事前に確立された機構に従うことになり、任意の便利な方法により行われることが可能である。したがって、例えばＶＫＭＳ−ＤＤ（またはそのある部分）は、加入者とプロバイダとの間の事前に同意済みのプロセスに従って、プロバイダのＩＴインフラストラクチャに向かわない「アウト・オブ・バンド」交換（例えば、宅配業者などによる配達）により提供されてもよい。または、交換は、「イン・バンド」交換により実行されてもよく、これによりＶＫＭＳ−ＤＤは、加入者からプロバイダのセキュアなＶＫＭＳサービス・エンドポイントまで、インターネットを通じて電子メッセージまたはアプリケーション・プログラミング・インタフェース（ＡＰＩ）によりセキュアに（例えば、ノンス、デジタル署名、暗号によって）送信される。
【００５９】
加入者からプロバイダへＶＫＭＳ−ＤＤを運ぶために使用される手段にかかわらず、ＶＫＭＳ−ＤＤはいくつかの暗号鍵によって暗号化され、署名されるべきである。この点において、加入者のＶＫＭＳ−ＤＤのいかなる人的処理も、両当事者によって高度にセキュアな管理アクションとみなされるべきであり、このようなデータを処理する権限がある人々だけが、そうすることを許可される。当業者は認識するように、開示する主題は、Ｋｍｖ（鍵）を使用する暗号化技法によりＶＫＭＤが確立された後の、プロバイダのインフラストラクチャ内の加入者のデータのセキュリティを構成しようとするにすぎない。リソースおよび人間の行為者もしくはこれらの管理ソフトウェアが、これらが導出しなければならない様々なＫｍｖを使用してデータ（メッセージ・データを含む）を暗号化する、および解読することができることを証明することによって、これらの「信頼」を確立する。したがって、このシステムにおけるすべての認可は、顧客が顧客のデバイスＩＤにアクセスし、これを利用して、割り当てられた信頼レベルで特定のアクションを行うために正しいＫｍｖレベルを導出することができるため、暗黙的である。上記のように、好ましくは加入者のＶＫＭＳ−ＤＤは、いかなる電子的伝送または手動／物理的伝送中においても、暗号化される、または物理的に保護される、あるいは暗号化されかつ物理的に保護される。必要に応じて、さらなるセキュリティ対策がとられて、プロバイダの信頼される従業員および／または加入者のみが、プロバイダのＶＫＭＳのセキュアなＶＫＭＳ−ＤＤボールト内のデータの伝送およびさらなるインストール中に、ＶＫＭＤ初期化データを処理することを許可されることを保証することができる。
【００６０】
図８に戻ると、ステップ８０８において、ＶＫＭＳ−ＤＤがプロバイダＡでＶＫＭＳ−ＤＤＶにインストールされると、プロバイダＡのＶＫＭＳサーバは、加入者が提供したＶＫＭＳ−ＤＤを使用して、ＶＫＭＤに含まれる必要のある最大数の「デバイス」（いわゆる、「必須デバイス（Necessary Device）」）を表すために、正確な寸法および構造（例えば、本明細書に具体化されるように、ＮＮＬツリーのＭＫＢの「Ｎ」ツリーの寸法、奥行き、幅など）を有するＶＭＫＢを生成する。このように、仮想管理鍵ブロック（ＶＭＫＢ）は、十分な「デバイスＩＤ」（および関連デバイス・キー）をその内部で符号化することを保証するために十分な「パス」を有して設計される。詳細には、以下にさらに詳細に示すように、ＭＫＢは、様々な「クラス」レベルの十分な数の「デバイスＩＤ」をサポートして、これらを、対応する加入者のアプリケーションおよびデータを格納する、実行する、または送信するために割り振られるまたはプロビジョニングされることが可能であるプロバイダのＩＴデータセンタ・インフラストラクチャ内のすべての「必須」デバイス（例えば、ネットワーク、ストレージ、ホスト・システム・ハードウェア、サーバ、ホストされるソフトウェア・アプリケーション／サービスなど）に十分に分配し、割り当てるように生成される。ＭＫＢはまた、加入者がそれらの「他社運用型」サーバ、アプリケーション、サービス、およびデバイス（例えば、コンピュータ、携帯電話など）に割り当てる（送信する、およびインストールする）ことを可能にするために、加入者に割り当てるのに十分な数のデバイスＩＤを供給するように生成されることも可能である。ＶＫＭＳサーバはまた、以下にさらに詳細に説明するように、ＶＭＫＢ内の十分な「ノード」が、所望の「信頼」クラス（またはレベル）のそれぞれに割り振られることを保証する。以下でわかるように、これらのクラスまたはレベルのそれぞれは、所与のデバイスＩＤに割り当てられた信頼レベルに一致する正確なＫｍｖ値を含むように、暗号で符号化（cryptographically encoded）される。ＶＭＫＢ（そのＶＫＭＤ用）の構築を求める加入者の要求は、ＶＫＭＤ−ＤＤを使用して加入者から伝えられ、これらの要求は、図７の表に示すように、例えば暗号、暗号強度、鍵の長さ、ＭＫＢツリーの深さ、サブツリーのデバイス「信頼」クラス割り振りなどを含むことができる。ＶＫＭＤ−ＤＤが、ＶＫＭＳの許可された制約内であることを確かなものにするために、ＶＭＫＢ構築に影響を及ぼすプロバイダ要件（例えば、暗号、鍵の長さ、深さ、デバイスＩＤのその数、および「信頼レベル」など）はよく知られており、プロバイダから（１人または複数の）加入者へ伝えられる。
【００６１】
ステップ８１０において、ＶＭＫＳサーバは、ＶＭＫＢをＶＫＭＳ−ＤＤＶに格納し、ＶＫＭＤ−ＩＤを使用してＶＫＭＤにこれを関連付ける。好ましくは、ＶＫＭＳサーバはまた、デバイスＩＤの完全なセット、およびそれらの関連デバイス・キーを格納し、ＶＫＭＤ−ＩＤを使用してこれらをＶＫＭＳ−ＤＤＶに格納する。必要に応じて、プロバイダは、そのインフラストラクチャ・デバイス／構成要素に割り当てられたデバイスＩＤを、複数のＶＫＭＤに使用することができるように、または新しいデバイスＩＤが、各ＶＫＭＤに対して割り当てられ、送信されるように、ＶＫＭＳを設計することができる。これは、ＶＫＭＳサーバはそのインフラストラクチャ「デバイス」のためのデバイスＩＤ／鍵を一度作成するだけでよいが、その後、すべてのＶＫＭＤのために作成するすべてのＶＭＫＢにデバイスＩＤ（すなわち、パス）のこの固定セットを含む（構成する）ことを意味する。
【００６２】
ＶＭＫＳサーバが、このようにして複数のＶＭＫＤを作成すると、ＶＭＫＳサーバは次に、所与のＶＭＫＢ領域にプロビジョニングされるインフラストラクチャ構成要素だけに、ＶＭＫＢデバイス・キーおよびＩＤをインストールする。図９は、複数のＶＫＭ領域が適用された後の共有ＩＴリソースのプロバイダのデータセンタを示す。
【００６３】
ＶＭＫＢは、次に例として説明するプロビジョニング戦略を使用するＶＭＫＳサーバによって生成される。この例示のシナリオでは、作成されるいかなるＶＫＭＢにも符号化される必要のある７つ（７）のデバイス信頼クラス（またはレベル）があると仮定される。これは、この例のＶＫＭＳが作成するＶＭＫＢが、７つの可能な管理キー・バリアント（Ｋｍｖ）または「デバイス信頼クラス」（すなわち、ＫＭＶ６〜ＫＭＶ０として表される）を有することを意味する。この場合、最も信頼されるデバイスは、管理キー・バリアント「信頼クラス６」、または単に「クラス６」（ＭＫＶ６として表される）を導出することができるデバイスＩＤを割り当てられるが、あまり信頼されないデバイスは、より低い管理キー・バリアント「クラス５」（ＭＫＶ５として表される）と関連付けられるデバイスＩＤを割り当てられ、そのデバイスＩＤが「クラス０」デバイス（ＭＫＶ０として表される）に関連付けられる最も信頼されないデバイスまで、同様である。図１０は、プロバイダと加入者の両方の構成要素に７つ（７）の「信頼」レベルを割り当てるためのサンプル・プロビジョニング戦略を示す。当然ながら、このシナリオは、単に例示的なものであるにすぎず、開示する技法を限定するととらえられるべきではない。図は、例示の「７」「デバイス」（信頼）クラス・レベルが、関連するアーキテクチャ構成要素に適切な信頼度に基づいてどのように割り当てられるかを示す。レベルが高くなるほど、構成要素はより信頼される。所与のデバイス・クラス・レベルの構成要素は、それらの下のすべてのデバイス処理レベルのセキュリティを検証し、それによって、クラス階層が低いデバイスのために、インフラストラクチャのどこでもセキュリティ障害を検出することができる、セキュリティおよび検証のための階層化システムを提供することができる。好ましくは、プロビジョニング戦略はまた、ＶＫＭＳ領域キー（すなわち、デバイス・キー）、デバイスＩＤ、およびＶＭＫＢなどをプロビジョニングする方法を、詳細には、特定の管理キー・バリアント（設計による）へのアクセスと関連付けられた（暗号で導出された）「信頼」に基づいて述べる。
【００６４】
したがって、図１０に示すように、デバイス・クラス・レベルＫＭＶ０が、加入者の顧客アプリケーションおよびデバイスに割り振られる。最も信頼されない役割の人々が、次にこれらのリソースにアクセスすることができるようにされてもよい。デバイス・クラス・レベルＫＭＶ１が、加入者の従業員アプリケーションおよびデバイスに割り振られる。より信頼される役割の人々が、次にこれらのリソース（ならびにあまりセキュアでない下のクラスのリソース）にアクセスすることができるようにされてもよい。デバイス・クラス・レベルＫＭＶ２が、加入者の管理アプリケーションに割り振られる。アカウントおよびリソースを管理することを許可された人々が、これらのリソースにアクセスすることを許可される。プロバイダ構成要素は、やはり単に一例として図のように、さらなるデバイス・クラス・レベルに割り当てられ、割り振られる。
【００６５】
当然ながら、図１０に示す例示の戦略は、本開示を限定するととらえられるべきではない。信頼のより少ないまたはより多い層が存在することがあり、一般的に信頼の基点（図示せず）が存在することになる。図に示すように、プロバイダのインフラストラクチャを使用して、加入者は、それぞれが他のものから分離される粒度を制御して、加入者のアプリケーションおよびデータを容易にプロビジョニングすることができる。
【００６６】
次に、領域固有の（すなわち、ＶＫＭＤ固有の）ＶＭＫＢ、デバイスＩＤ、および関連デバイス・キーが、加入者のデータを実行する、管理する、操作する、格納する、および処理するために割り振られた（プロバイダによってプロビジョニングされた）「デバイス」に割り当てられ、インストールされる方法の様々な３つ（３）の異なるプロバイダ・オプションについて説明する。加入者は、ＶＫＭＤの「所有者」である。次のオプションは、図１０に示すプロビジョニング戦略が採用された、すなわち、プロバイダが、そのインフラストラクチャの構成要素に割り当てられる「デバイス」信頼クラス・レベルを事前に確立したと仮定する。どのオプションが実行されるかにかかわらず、次の仮定が行われる。第１に、ＶＫＭＳサーバは、デバイスＩＤおよびデバイス・キーが決して別のデバイスと関連付けられることのないように（位置、または他のシステム識別子との関連性により）追跡を行う。第２に、ＶＫＭＳサーバは、これらのデバイスＩＤを（好ましくは電子的に）各デバイス／構成要素にセキュアに送信する。理想的にはこれは、セキュアなネットワークを通じて行われ、デバイスＩＤは、暗号化によりセキュアにされ、およびデジタル署名／ハッシングにより改ざん防止機能付きにされ、各受信デバイス（または構成要素）が、その安全性を確認し、デバイスＩＤを解読できるようにする。さらに、デバイスＩＤを受信する各デバイス／構成要素が（必要に応じてデバイスＩＤを確認し、解読した後）、直接自身のストレージ、またはセキュアにアクセスすることができる他のストレージ内の、セキュアな位置内にこのＩＤをセキュアに格納することができる。
【００６７】
第１のオプションは、プロバイダ・デバイスへの予め決定されたプロビジョニングを提供する。この手法では、プロバイダのＶＫＭＳサーバは、特定の加入者のデータ処理およびストレージのニーズに対処するためにどの「デバイス」をプロビジョニングしている必要があるかを「予め決定する」ことができる。これは、ＳＬＡなどに関して伝えられてもよい。プロバイダはまた、特定の加入者がプロバイダに「スケール変更」して対処できることを求める、拡張性要件、ピーク使用需要、または他の特別なイベント需要など、他の情報を知ることもできる。これらは、ＳＬＡに記載される、または「アウト・オブ・バンド」通信でプロバイダに伝えられてもよい。好ましくは、ＶＫＭＳプロバイダは、これらの要求をＶＫＭＤ−ＤＤＶに「格納する」、およびこれらをそのＶＫＭＤ−ＩＤを使用して加入者に関連付けるようにＶＫＭＳサーバを構成することができる。
【００６８】
第２のオプションは、プロバイダ・デバイスへの「オンデマンド」プロビジョニングを提供する。この手法では、事前に計画し、加入者のリソース・ニーズについてプロバイダへの要求を伝えるにもかかわらず、プロバイダは、「オンデマンド」プロビジョニングを実行することができる。このオプションは、プロバイダのインフラストラクチャ（例えば、一般的なプロビジョニング・システム、ＯＳＳシステム、パフォーマンス・モニタなど）が適宜に構成されていなければならないことを除いて、前のオプションと同様である。このオプションはまた、フェイル・オーバー・シナリオで使用されてもよく、プロバイダのデータセンタ内のモニタリング・デバイス／ソフトウェアが、特定のＶＫＭＤに割り当てられた特定のデバイス（または多くの場合、デバイスのセット）上の障害を検出する。このような場合、ＶＭＫＳサーバは、障害によって影響を受ける関連加入者からのデータを一時的にまたは永久的にセキュリティ保護するために使用することができるさらなるデバイスＩＤおよび鍵をプロビジョニングすることができる。このオプションはまた、変更管理動作中に使用されてもよい。したがって、例えば、プロバイダが特定のＶＫＭＤに割り当てられたデバイス／リソースに保守または更新を行っている場合、プロバイダはＶＭＫＳサーバにさらなるデバイスＩＤおよびキーを動的にプロビジョニングさせることができ、これを使用して関連加入者からのデータを一時的に処理し、セキュアにすることができる。
【００６９】
第３のオプションは、加入者デバイスへのプロビジョニングを提供する。プロバイダ（すなわち、図１０のＫｍｖクラス３〜６）について説明されたデバイスＩＤ、キー、およびＶＭＫＢの上述の静的／予め決定された割当ておよび「オンデマンド」割当ては、外部加入者デバイス／クライアント（すなわち、図１０のＫｍｖクラス０〜２）にこれらの材料を提供するために、同様に実行されることが可能である。このオプションでは、加入者は好ましくは、単にその（プロバイダ外部の）ＩＤおよびキー材料（Ｋｍｖクラス０〜２のデバイスのセットのキー材料）に対するプロビジョニング・サービスを提供する中心の「信頼される」サービス（少なくともＫｍｖクラス２の信頼を有してセキュリティ保護されている）を有する。
【００７０】
変形として、ＶＫＭＳサーバは、所与のＩＴ環境のセキュリティ構造に対する、または１つもしくは複数の共有環境に展開された複数のクラスの顧客もしくはアプリケーションに対する、集中制御を許可することができる。
【００７１】
サービス・プロバイダは、取り消し、更新など、ＶＫＭＤのためのライフサイクル動作を実行することができる。したがって、例えばプロバイダは、顧客がＶＫＭＤからいくつかのデバイスＩＤ（またはデバイス・クラス全体）を削除して、それらがＭＫＢの様々な管理キー・バリアントを使用して保護されるデータにもはやアクセスできないようにするために使用することができる「取り消し」サービスを提供することができる。１つの実施形態では、「高信頼」のデバイスは、このような「取り消し」アクション、または他の許可されるアクションを承認するのに必要とされる資格情報を用いて確立される。これらの取り消しは、その後、「更新」が行われるまで、そのＶＫＭＤのためにＶＫＭＳによって蓄積されてもよい、または、個々の取り消しが、その受信時に行われてもよい。更新は、定期的に行われる、または高信頼クラスに属し、したがってそのような認可特権を与えられたデバイスを使用している顧客による直接的な認可された要求によって行われてもよい。（管理機能を行うことができる）このタイプのデバイスは、プロバイダとの合意によって、または構成／セットアップの一部として、確立されることが可能であり、このようなデバイスのためにＶＫＭＤ内に特定の「信頼レベル」が確立されてもよい。より一般的には、ＶＫＭＳは、（おそらく顧客またはテナントとともに確立された確立済みスケジュールに反して）所与のＶＫＭＤのためにＭＫＢを定期的に「更新する」ことができる。このように、新しいＭＫＢは、ＶＫＭＤのためにＶＫＭＳによって作成され、その領域に加わるすべてのデバイスに分配されることになる。既存のメッセージまたは新しいメッセージが次に、新しいＭＫＢを搬送する（押し出す）ために使用されてもよい、またはいくつかのインジケータが、参加デバイスに送信されて、これらのデバイスが次に、プロバイダが提供するサービスから新しいＭＫＢを引き出してもよい。上記は、サービス・プロバイダによって、またはサービス・プロバイダと関連して実行されることがある一般的なＶＫＭＤライフサイクル動作の例にすぎない。他のこのようなライフサイクル・サービスは、これらに限定ではないが、ＶＫＭＤの無効化（一時的）または閉鎖／終了（永久的）、ＶＫＭＤ情報をアーカイブするためのサービス、ＶＫＭＤ−ＤＤの一部（例えば、暗号アルゴリズムおよびそれらの要素）の変更を許可するサービス（このようなそれぞれの変更は一般的に発生した変化のインジケータで何らかのタイプの更新を強制する）、プロバイダがＶＫＭＤのためにＭＫＢ内のさらなる信頼されるサービスを提供する（これは、ＭＫＢがすべての信頼レベルで「自己署名」され、有効な（失効していない）デバイスＩＤを有する任意のメンバ・デバイスによって検証されるので、可能である）、などを含む。
【００７２】
ブロードキャスト暗号化に使用される管理キー・ブロックを生成するための技法は、多様であってもよい。好ましくは、キー・ブロックは、ＮＮＬツリーおよび他の高度な技法を使用して生成されるが、単純な行−列ルックアップを用いる旧来のマトリクスベースの技法も同様に使用することができる。
【００７３】
本明細書の主題は、従来の技術に優る重要な利点を有する。上に説明した手法により、マルチテナント共有展開におけるテナントは、テナント独自の異なる鍵空間を提供され、このキー・スペースでテナントは鍵管理システムを制御する。このように、仮想鍵管理領域が、テナントごとに（顧客ごとに）作成され、特定の顧客のデータがプロバイダの（１つまたは複数の）データセンタのＩＴインフラストラクチャにおいて共同テナント化される、格納される、送信される、または仮想化されるときはいつでも、特定の顧客のデータは、その顧客に固有の鍵管理材料を使用してセキュリティ保護されるようにする。これは、テナントのデータ（すべての汎用データ、およびソフトウェア・アプリケーションを含むが、これらに限らない）の全体が、他のテナントのアプリケーションからこれを暗号で分離することによって依然としてセキュアであることを保証する。好ましくは、仮想鍵管理領域は、ブロードキャスト暗号化（ＢＥ）プロトコルの管理キー・バリアントを使用して確立される。このプロトコルは、データのテナントごとのセキュアにされた分離を実現し、共同テナント化されたＩＴインフラストラクチャのすべてのレベルで、またはすべてのレベル全体で、リソースのいかなる組合せにわたっても使用することができる。この手法を使用すると、各テナントが、（ＶＫＭＳ−ＤＤに記述されているように）顧客独自の構成およびパラメータを表す一意の（または「カスタムの」）仮想鍵管理領域を作成し、初期化することができる。特定のＶＫＭＳデータ領域（ＶＫＭＤ）内で、ブロードキャスト暗号化管理キー・バリアントを使用して、顧客が次に、デバイス信頼クラスの所望のセットをセットアップし、実施することができる。
【００７４】
説明したように、上述の機能は、独立した手法、例えばプロセッサによって実行されるソフトウェアベースの機能として実装されてもよい、または、上述の機能は、管理されるサービス（ＳＯＡＰ／ＸＭＬインタフェースによるウェブ・サービスを含む）として利用できてもよい。本明細書に記載する特定のハードウェアおよびソフトウェア実行詳細は、単に例示のためであり、記載する主題の範囲を限定するものではない。
【００７５】
より一般的に、開示する主題のコンテキスト内のコンピューティング・デバイスは、それぞれハードウェアおよびソフトウェアを含んだ（図２に示すような）データ処理システムであり、これらのエンティティが、インターネット、イントラネット、エクストラネット、プライベート・ネットワーク、またはその他の通信媒体もしくはリンクなどのネットワークを通じて互いに通信する。データ処理システム上のアプリケーションは、ウェブおよび他の知られているサービスおよびプロトコルのためのネイティブ・サポートを提供し、特に、ＨＴＴＰ、ＦＴＰ、ＳＭＴＰ、ＳＯＡＰ、ＸＭＬ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬのためのサポートを含むが、これらに限らない。ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩ、およびＷＳＦＬに関する情報は、これらの標準の開発および保守に関与しているワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）から入手でき、ＨＴＴＰ、ＦＴＰ、ＳＭＴＰ、およびＸＭＬに関するさらなる情報は、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）から入手できる。これらの知られている標準およびプロトコルに熟知していることが想定される。
【００７６】
さらにより一般的には、本明細書に記載する主題は、完全にハードウェア実施形態、完全にソフトウェア実施形態、またはハードウェア要素とソフトウェア要素の両方を含んだ実施形態の形をとることができる。好ましい実施形態では、仮想鍵管理サーバ（ＶＫＭＳ）は、ソフトウェアで実装され、ソフトウェアは、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むが、これらに限定されない。さらに、ＶＫＭＳおよび関係機能は、コンピュータまたは任意の命令実行システムによって、またはこれに関連して使用されるプログラム・コードを提供する、コンピュータが使用可能またはコンピュータ可読の非一時的媒体からアクセスできるコンピュータ・プログラム製品の形をとることができる。この説明の目的で、コンピュータが使用可能またはコンピュータ可読の媒体は、命令実行システム、装置、またはデバイスによって、またはこれに関連して使用されるプログラムを収容する、または格納することができるいかなる装置とすることもできる。媒体は、電子、磁気、光、電磁気、赤外線、または半導体システム（または装置またはデバイス）とすることができる。コンピュータ可読媒体の例には、半導体またはソリッド・ステート・メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、硬質磁気ディスク、および光ディスクが含まれる。光ディスクの現在の例には、コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク読み取り／書き込み（ＣＤ−ＲＷ）、およびＤＶＤが含まれる。ストレージ・デバイスは、ＳＤカードなど、取り外し可能媒体を含むことができる。コンピュータ可読媒体は、有形の、非一時的アイテムである。これらのデバイスのいずれも、ＶＭＫＳによって保護される情報を格納するために使用可能である。
【００７７】
いかなるクラウド・データセンタ・リソースも、本明細書に記載するようにＶＫＭＳ構成要素をホストすることができる
【００７８】
コンピュータ・プログラム製品は、記載する機能の１つまたは複数を実行するためのプログラム命令（またはプログラム・コード）を有する製品であってもよい。そうした命令またはコードは、リモートのデータ処理システムからネットワークを通じてダウンロードされた後、データ処理システムのコンピュータ可読記憶媒体に格納されてもよい。または、そうした命令もしくはコードは、サーバ・データ処理システムのコンピュータ可読記憶媒体に格納され、リモート・システム内のコンピュータ可読記憶媒体で使用されるように、リモート・データ処理システムにネットワークを通じてダウンロードされるように構成されてもよい。
【００７９】
代表的実施形態では、仮想鍵管理システムの構成要素は、特殊用途コンピューティング・プラットフォームで、好ましくは、１つまたは複数のプロセッサによって実行されるソフトウェアで実装される。ソフトウェアは、１つまたは複数のプロセッサと関連付けられる１つまたは複数のデータ・ストアまたはメモリに保持され、ソフトウェアは、１つまたは複数のコンピュータ・プログラムとして実行されることが可能である。集合的に、この特殊用途のハードウェアおよびソフトウェアが、上述の機能を含む。
【００８０】
さらに、本明細書に提供するフレームワーク機能は、既存のクラウド・コンピュート管理ソリューションへの付属物または拡張として実装されることが可能である。
【００８１】
本明細書に記載する技法は、仮想クライアント−サーバ環境において使用されることが可能である。
【００８２】
上記は、本発明のいくつかの実施形態によって行われる動作の特定の順序を記載しているが、このような順序は例示であることを理解すべきであり、代替的実施形態は、異なる順序で動作を行う、いくつかの動作を組み合わせる、いくつかの動作を重ね合わせる、などが可能である。明細書中の所与の実施形態への言及は、記載した実施形態は特定の特徴、構造、または特性を含むことができるが、すべての実施形態が必ずしもこの特定の特徴、構造、または特性を含むとは限らないことを示す。
【００８３】
最後に、システムの所与の構成要素を個別に説明したが、機能の一部は所与の命令、プログラム・シーケンス、コード部分などにおいて結合される、または共有される可能性があることを、当業者は理解するであろう。
【００８４】
発明について説明したが、次に特許請求の内容は以下の通りである。
【図１】
0006537455.tif 000002
【図２】
0006537455.tif 000003
【図３】
0006537455.tif 000004
【図４】
0006537455.tif 000005
【図５】
0006537455.tif 000006
【図６】
0006537455.tif 000007
【図７】
0006537455.tif 000008
【図８】
0006537455.tif 000009
【図９】
0006537455.tif 000010
【図１０】
0006537455.tif 000011