(57)【要約】  実施形態は、マルチテナントクラウドベースのシステムにおける暗号鍵を管理することに向けられる。実施形態は、ラップされたデータ暗号鍵（ＤＥＫ）の要求をクライアントから受け取る。実施形態は、ランダムキーを生成し、クライアントに対応する暗号化コンテキストをフェッチする。実施形態は、ランダムキーとラップされたＤＥＫでエンコードされる暗号化コンテキストとを含むラップされたＤＥＫを生成する。その後、実施形態は、ラップされたＤＥＫをクライアントに返す。
2021527970.tif 000002
【特許請求の範囲】
【請求項１】
マルチテナントクラウドベースのシステムにおける暗号鍵を管理するための方法であって、
ラップされたデータ暗号鍵（Hardware Security Module：ＤＥＫ）の要求をクライアントから受け取ることと、
ランダムキーを生成することと、
前記クライアントに対応する暗号化コンテキストをフェッチすることと、
前記ランダムキーと前記ラップされたＤＥＫでエンコードされる前記暗号化コンテキストとを含む前記ラップされたＤＥＫを生成することと、
前記ラップされたＤＥＫを前記クライアントに返すことと、を含む方法。
【請求項２】
前記暗号化テキストは、前記クライアントのロケーション、前記クライアントのリージョン、および前記クライアントのテナントのうちの少なくとも一つを含む、請求項１に記載の方法。
【請求項３】
前記暗号化コンテキストは、追加の認証済みデータを含む、請求項１に記載の方法。
【請求項４】
前記ラップされたＤＥＫは、ヘッダーを含み、
前記暗号化コンテキストは、前記ヘッダーでエンコードされる、請求項１に記載の方法。
【請求項５】
前記ラップされたＤＥＫは、JavaScript Object Notation（ＪＳＯＮ）Web Encryption（ＪＷＥ）構造を含む、請求項１に記載の方法。
【請求項６】
前記ラップされたＤＥＫをアンラップする要求を受け取ることと、
前記ラップされたＤＥＫをパースすることと、
前記クライアントに基づく前記暗号化コンテキストを検証することと、
ハードウェアセキュリティモジュール(Hardware Security Module：ＨＳＭ)にあるマスター暗号鍵（Master Encryption Key：ＭＥＫ）を検証することと、
アンラップされたＤＥＫを返すこととをさらに含む、請求項１に記載の方法。
【請求項７】
前記生成する前記ラップされたＤＥＫは、初期化ベクトル（Initialization Vector：ＩＶ）および認証タグ鍵をさらに含む、請求項１に記載の方法。
【請求項８】
前記要求は、リプリゼンテーショナルステートトランスファー（Representational State Transfer：ＲＥＳＴ）アプリケーションプログラムインターフェース(Application Program Interface：ＡＰＩ)を含む、請求項１に記載の方法。
【請求項９】
プロセッサによって実行されると、前記プロセッサに、マルチテナントクラウドベースのシステムにおける暗号鍵を管理させる命令を記憶したコンピュータ可読媒体であって、
前記管理することは、
ラップされたデータ暗号鍵（ＤＥＫ）の要求をクライアントから受け取ることと、
ランダムキーを生成することと、
前記クライアントに対応する暗号化コンテキストをフェッチすることと、
前記ランダムキーと前記ラップされたＤＥＫでエンコードされる前記暗号化コンテキストとを含む前記ラップされたＤＥＫを生成することと、
前記ラップされたＤＥＫを前記クライアントに返すこととを含む、コンピュータ可読媒体。
【請求項１０】
前記暗号化テキストは、前記クライアントのロケーション、前記クライアントのリージョン、および前記クライアントのテナントのうちの少なくとも一つを含む、請求項９に記載のコンピュータ可読媒体。
【請求項１１】
前記暗号化コンテキストは、追加の認証済みデータを含む、請求項９に記載のコンピュータ可読媒体。
【請求項１２】
前記ラップされたＤＥＫは、ヘッダーを含み、
前記暗号化コンテキストは、前記ヘッダーでエンコードされる、請求項９に記載のコンピュータ可読媒体。
【請求項１３】
前記ラップされたＤＥＫは、JavaScript Object Notation（ＪＳＯＮ）Web Encryption（ＪＷＥ）構造を含む、請求項９に記載のコンピュータ可読媒体。
【請求項１４】
前記管理することは、
前記ラップされたＤＥＫをアンラップする要求を受け取ることと、
前記ラップされたＤＥＫをパースすることと、
前記クライアントに基づく前記暗号化コンテキストを検証することと、
ハードウェアセキュリティモジュール(ＨＳＭ)にあるマスター暗号鍵（ＭＥＫ）を検証することと、
アンラップされたＤＥＫを返すこととをさらに含む、請求項９に記載のコンピュータ可読媒体。
【請求項１５】
前記生成する前記ラップされたＤＥＫは、初期化ベクトル（ＩＶ）および認証タグ鍵をさらに含む、請求項９に記載のコンピュータ可読媒体。
【請求項１６】
前記要求は、リプリゼンテーショナルステートトランスファー（ＲＥＳＴ）アプリケーションプログラムインターフェース(ＡＰＩ)を含む、請求項９に記載のコンピュータ可読媒体。
【請求項１７】
１つ以上のマイクロサービスを含む中間層と、
前記中間層に結合され、１つ以上のデータベースおよび１つ以上のハードウェアセキュリティモジュールを含むデータ層とを備え、
前記１つ以上のマイクロサービスは、
ラップされたデータ暗号鍵（ＤＥＫ）の要求をクライアントから受け取り、
ランダムキーを生成し、
前記クライアントに対応する暗号化コンテキストをフェッチし、
前記ランダムキーと前記ラップされたＤＥＫでエンコードされる前記暗号化コンテキストとを含む前記ラップされたＤＥＫを生成し、
前記ラップされたＤＥＫを前記クライアントに返す、マルチテナントクラウドベースの鍵管理システム。
【請求項１８】
前記暗号化テキストは、前記クライアントのロケーション、前記クライアントのリージョン、および前記クライアントのテナントのうちの少なくとも一つを含む、請求項１７に記載のマルチテナントクラウドベースの鍵管理システム。
【請求項１９】
前記ラップされたＤＥＫは、JavaScript Object Notation（ＪＳＯＮ）Web Encryption（ＪＷＥ）構造を含む、請求項１７に記載のマルチテナントクラウドベースの鍵管理システム。
【請求項２０】
前記１つ以上のマイクロサービスは、さらに、
前記ラップされたＤＥＫをアンラップする要求を受け取り、
前記ラップされたＤＥＫをパースし、
前記クライアントに基づく前記暗号化テキストを検証し、
ハードウェアセキュリティモジュール(ＨＳＭ)にあるマスター暗号鍵（ＭＥＫ）を検証し、
アンラップされたＤＥＫを返す、請求項１７に記載のマルチテナントクラウドベースの鍵管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
分野
一実施形態は、一般にクラウドベースのコンピュータシステムに向けられ、特にクラウドベースのコンピュータシステムにおける暗号鍵の管理に向けられる。
【背景技術】
【０００２】
背景の情報
鍵管理サービス（Key Management Service：ＫＭＳ）は、暗号システムにおける暗号鍵の管理を提供する。管理は、鍵の生成、交換、保存、使用、暗号シュレッディング（すなわち、破壊）、および置換の機能を含む。それは、暗号プロトコル設計、鍵サーバ、ユーザ手順、および他の関連するプロトコルを含む。
【０００３】
ＫＭＳ内の鍵は、データを暗号化および復号化し、データをそれが記憶された場所で保護するために使用される暗号素材を含む１つ以上の鍵バージョンを表す論理エンティティである。暗号化アルゴリズムの一部として処理されるとき、鍵は、暗号化中に平文をどのように暗号文に変換し、復号化中に暗号文をどのように平文に変換するかを指定する。ＫＭＳは、一般に、２種類の暗号鍵を認識する。それらは、マスター暗号鍵(Master Encryption Key：ＭＥＫ)およびデータ暗号鍵(Data Encryption Key：ＤＥＫ)である。ＫＭＳを使用してマスター暗号鍵を生成した後、ユーザは、ＫＭＳがユーザに返すデータ暗号鍵を生成するために、ＡＰＩを使用することができる。ＫＭＳは生鍵およびラップされた鍵を返す。典型的には、ユーザは、ラップされた鍵のみを保存する。
【発明の概要】
【０００４】
概要
実施形態は、マルチテナントクラウドベースのシステムにおける暗号鍵を管理することに向けられる。実施形態は、ラップされたデータ暗号鍵（ＤＥＫ）の要求をクライアントから受け取る。実施形態は、ランダムキーを生成し、クライアントに対応する暗号化コンテキストをフェッチする。実施形態は、ランダムキーとラップされたＤＥＫでエンコードされる暗号化コンテキストとを含むラップされたＤＥＫを生成する。その後、実施形態は、ラップされたＤＥＫをクライアントに返す。
【図面の簡単な説明】
【０００５】
【図１】本発明の実施形態によるＫＭＳの高いレベルの概要を示す図である。
【図２】本発明の一実施形態によるコンピュータサーバ／システムのブロック図である。
【図３】一実施形態によるＫＭＳによってラップされたＤＥＫを生成するための機能のフロー図である。
【図４】一実施形態によるＫＭＳによってラップされたＤＥＫをアンラップするための機能のフロー図である。
【発明を実施するための形態】
【０００６】
詳細な説明
一実施形態は、ラップされたデータ暗号鍵（ＤＥＫ）のヘッダーでエンコードされ、信頼できる属性として機能するカスタムタグおよび値を含めることによって、ラップされたＤＥＫを生成する。その後、ラップされたＤＥＫをアンラップする要求を受信したとき、または、そうでなければラップされたＤＥＫへのアクセスを承認するときに、ポリシーの決定を実施することに、タグおよび値は、使用される。
【０００７】
開示されるように、ラップされたＤＥＫは、鍵管理サービス（ＫＭＳ）によって要求者（たとえば、ユーザまはたアプリケーション）に発行される。ラップされたＤＥＫは、ラップされたＤＥＫをアンラップする目的で、後でＫＭＳに返送される。要求者を承認する責任はＫＭＳにある。しかしながら、クラウド環境において、ユーザ、アプリケーション、およびラップされたＤＥＫの数は、非常に多くなる可能性がある。一例において、１００万を超える可能性のあるラップされたＤＥＫのＫＭＳによるアクセスの承認を処理するための解決策が必要である。
【０００８】
図１は、本発明の実施形態によるＫＭＳ７０の高レベルの概要を示す。複数のＫＭＳクライアント７２は、１つ以上のウェブサーバ７６からのリプリゼンテーショナルステートトランスファー（Representational State Transfer：ＲＥＳＴ）アプリケーションプログラムインターフェース(Application Program Interface：ＡＰＩ)を使用して、鍵を要求する。鍵を要求してその鍵を利用できるクライアント７２は、データベース８１を含む。一実施形態では、データベース８１は、テーブルおよびテーブルスペースに格納される機密データの暗号化を可能にする透過的データ暗号化（Transparent Data Encryption：ＴＤＥ)を含むオラクル社製のデータベースである。データが暗号化された後、このデータは、承認されたユーザまたはアプリケーションがこのデータにアクセスする際に、承認されたユーザまたはアプリケーション用に透過的に復号される。本実施形態では、データベース８１は、ＫＭＳ-ＤＢエージェント８５を含む。他の要求クライアント７２は、クラウド環境内の様々なクラウドサービス８２、様々なカスタマーアプリケーション８３、またはアカウント管理者によって操作される管理コンソール８４を含むことができる。
【０００９】
一実施形態では、１つ以上のウェブサーバ７６はクラウドベースのサーバである。実施形態では、ウェブサーバ７６は、クロスドメインアイデンティティ管理(System for Cross-Domain Identity Management：ＳＣＩＭ)のためのＲＥＳＴ ＡＰＩ７５ベースのシステムを公開する中間層コンポーネント７６によって実装される。一実施形態では、中間層７６は、データ層９２と通信するステートレスマイクロサービスのセットを含む。
【００１０】
一実施形態では、中間層７６を実装することができるマイクロサービスは、独立して配備可能なサービスである。一実施形態では、「マイクロサービス」という用語は、複雑なアプリケーションが言語に依存しないＡＰＩを使用して互いに通信する小さな独立したプロセスから構成される、ソフトウェアアーキテクチャ設計パターンを考慮している。一実施形態では、マイクロサービスは、小型で高度に切り離されたサービスであり、各々は、小型タスクを行うことに焦点を当てるであろう。一実施形態では、マイクロサービスアーキテクチャスタイルは、単一のアプリケーションを１組の小さなサービスとして開発するため、それぞれがそれ自体のプロセスで実行するため、および軽量メカニズム(例えば、ハイパーテキスト転送プロトコル(Hypertext Transfer Protocol：ＨＴＴＰ)リソースＡＰＩ)と通信するためのアプローチである。一実施形態では、マイクロサービスは、同じ機能の全部または多くを実行するモノリシックサービスと比較して、置換しやすい。さらに、各マイクロサービスは、他のマイクロサービスに悪影響を及ぼすことなく更新されるであろう。対照的に、モノリシックサービスの一部分への更新は、モノリシックサービスの他の部分に望ましくないまたは意図しない否定的な影響を与えるかもしれない。一実施形態では、マイクロサービスは、それらの能力の周辺において有益に編成されるであろう。一実施形態では、マイクロサービスのコレクションのそれぞれに対する起動時間は、それらのマイクロサービスのすべてのサービスを集合的に実行する単一のアプリケーションに対する起動時間よりもはるかに短い。いくつかの実施形態では、そのようなマイクロサービスの各々に対する起動時間は、約１秒以下であるが、そのような単一アプリケーションの起動時間は、約１分、数分、またはそれより長いかもしれない。
【００１１】
一実施形態では、中間層７６などのマイクロサービスアーキテクチャは、サービス指向アーキテクチャ(Service Oriented Architecture：ＳＯＡ)が柔軟で独立して配備可能なソフトウェアシステムを構築するための専門化(すなわち、システム内のタスクの分離)手法および実装手法を指す。マイクロサービスアーキテクチャにおけるサービスは、目的を果たすためにネットワークを介して互いに通信するプロセスである。一実施形態では、これらのサービスは、技術に捕らわれないプロトコルを使用する。一実施形態では、それらのサービスは、小さい粒度を有し、かつ、軽量プロトコルを使用する。一実施形態では、それらのサービスは独立して配備可能である。システムの機能を異なる小さなサービスに分散させることによって、システムのコヒージョンが増強され、システムの結合が低減される。これにより、システムの変更、ならびにシステムへの機能および品質の追加をいつでも容易に行うことができる。また、これは、連続的なリファクタリングを通じて、個々のサービスのアーキテクチャが出現することを可能にし、それゆえ、大きなアップフロント設計の必要性を低減するとともにソフトウェアを早期かつ連続的にリリースすることを可能にする。
【００１２】
一実施形態では、マイクロサービスアーキテクチャにおいて、アプリケーションは、サービスのコレクションとして開発され、各サービスは、それぞれのプロセスを実行し、軽量プロトコルを使用して通信する(例えば、各マイクロサービスに固有のＡＰＩ)。マイクロサービスアーキテクチャにおいて、個々のサービス/能力へのソフトウェアの分解は、提供されるサービスに応じて異なるレベルの粒度で行われてもよい。サービスは、ランタイムコンポーネント/プロセスである。各マイクロサービスは、他のモジュール/マイクロサービスと対話することができる自己内蔵モジュールである。各マイクロサービスは、他のマイクロサービスによってコンタクトされ得る、アンネームドユニバーサルポートを有する。一実施形態では、マイクロサービスのアンネームドユニバーサルポートは、マイクロサービスが慣習によって(たとえば、従来のＨＴＴＰポートとして)公開し、同じサービス内の任意の他のモジュール/マイクロサービスがマイクロサービスと対話することを可能にする標準通信チャネルである。マイクロサービスまたは任意の他の自己内蔵型機能モジュールは、一般的に「サービス」と称され得る。
【００１３】
データ層９２は、ハードウェアセキュリティモジュール(Hardware Security Module：ＨＳＭ)９４およびデータベース９５を含む。ＨＳＭは、強力な認証のためにデジタル鍵を保護および管理するとともに暗号処理を提供する物理的なコンピューティングデバイスである。これらのモジュールは、従来より、コンピュータまたはネットワークサーバに直接取り付けられるプラグインカードまたは外部装置の形態をとる。ＭＥＫはＨＳＭ９４内に常駐し、ＨＳＭ９４はＭＥＫに関わる暗号サービスを提供する。アプリケーション鍵およびすべてのメタデータは、データベース９５内に格納される。中間層７６およびデータ層９２のすべての構成要素は、いくつかの実施形態では、高可用性（High Availability：ＨＡ）および災害時リカバリー（Disaster Recovery：ＤＲ）を伴って実装される。
【００１４】
一実施形態では、中間層７６およびデータ層９２は、オラクル社製のマルチテナント、クラウドスケール、アイデンティティアクセスマネジメント(Identity Access Management：ＩＡＭ)プラットフォームであるアイデンティティクラウドサービス(Identity Cloud Service：ＩＤＣＳ)によって提供される認証サービスによって実装される。ＩＤＣＳは、認証、承認、監査、およびフェデレーションを提供する。ＩＤＣＳは、パブリッククラウド上で動作するカスタムアプリケーションおよびサービスへのアクセス、ならびにオンプレミスシステムを管理する。代替または追加の実施形態では、ＩＤＣＳはまた、公衆クラウドサービスへのアクセスを管理することもできる。例えば、ＩＤＣＳは、様々なサービス/アプリケーション/システムにわたってシングルサインオン(Single Sign On：ＳＳＯ)機能を提供するために利用され得る。ユーザおよびクライアントは、最初にＩＤＣＳに対して認証し、ＫＭＳへのアクセスに適したトークンを獲得しなければならない。境界認証は、ＩＤＣＳクラウドゲートによって実施される。ＫＭＳ ＡＰＩへの細やかなアクセスは、クライアントと管理者とを区別するために使用される適切な範囲および役割を有する認証モジュールによって実施される。ＩＤＣＳのさらなる詳細は、米国特許９,８３８,３７６に開示されており、その開示は参照により本明細書に組み込まれる。
【００１５】
図２は、本発明の一実施形態によるコンピュータサーバ/システム１０のブロック図である。単一のシステムとして示されているが、システム１０の機能は、分散システムとして実装することができる。さらに、本明細書で開示される機能は、ネットワーク上で互いに接続され得る個別のサーバまたはデバイス上で実装され得る。さらに、システム１０の１つ以上の構成要素は含まれなくてもよい。たとえば、サーバの機能のために、システム１０は、プロセッサおよびメモリを含む必要があり得るが、キーボードまたはディスプレイなど、図２に示される他の構成要素のうちの１つ以上を含まなくてもよい。システム１０の全部または一部は、いくつかの実施形態では、図１に示される構成要素のいずれかまたは全てを実装するために使用されてもよい。
【００１６】
システム１０は、情報を通信するためのバス１２または他の通信メカニズムと、情報を処理するためにバス１２に接続されたプロセッサ２２とを含む。プロセッサ２２は、汎用または専用プロセッサのいずれのタイプとしてもよい。システム１０は、情報およびプロセッサ２２によって実行されるべき命令を記憶するためのメモリ１４をさらに含む。メモリ１４は、ランダムアクセスメモリ(Random Access Memory：ＲＡＭ)、読み取り専用メモリ(Read Only Memory：ＲＯＭ)、磁気もしくは光ディスクなどの静的な記憶装置、または任意の他のタイプのコンピュータ可読媒体のうちの任意の組み合わせから構成され得る。システム１０は、ネットワークへのアクセスを提供するための、ネットワークインターフェースカードなどの通信デバイス２０をさらに含む。したがって、ユーザは、直接、またはネットワークまたは任意の他の方法を介してリモートで、システム１０とインターフェース接続することができる。
【００１７】
コンピュータ可読媒体は、プロセッサ２２によってアクセスされ得る任意の利用可能な媒体であってよく、揮発性媒体および不揮発性媒体の両方、取り外し可能媒体および取り外し不能媒体の両方、ならびに通信媒体を含む。通信媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または搬送波若しくは他のトランスポートメカニズムなどのような、変調されたデータ信号中の他のデータを含んでもよく、任意の情報配信媒体を含む。
【００１８】
プロセッサ２２は、バス１２を介して液晶ディスプレイ(Liquid Crystal Display：ＬＣＤ)などのディスプレイ２４にさらに接続される。キーボード２６およびコンピュータマウスなどのカーソル制御装置２８は、ユーザがシステム１０とインターフェース接続できるようにバス１２にさらに接続される。
【００１９】
一実施形態では、メモリ１４は、プロセッサ２２によって実行されると機能を提供するソフトウェアモジュールを記憶する。モジュールは、システム１０のオペレーティングシステム機能を提供するオペレーティングシステム１５を含む。モジュールは、ＫＭＳ機能、および本明細書で開示される他のすべての機能を提供するＫＭＳモジュール１６をさらに含む。システム１０は、より大きなシステムの一部とすることができる。したがって、システム１０は、上述したＩＤＣＳ機能などの追加機能を含むための１つ以上の追加機能モジュール１８を含むことができる。データベース１７は、モジュール１６および１８のためのセントラライズドストレージを提供するとともに、キー、パスワードなどを格納するためにバス１２に接続される。一実施形態では、データベース１７は、格納されたデータを管理するために構造化クエリ言語(Structured Query Language：ＳＱＬ)を使用することができるリレーショナルデータベース管理システム(Relational Database Management System：ＲＤＢＭＳ)である。
【００２０】
ラップされたＤＥＫのアンラッピングに関連して、既知のＫＭＳ解決策は、認証および承認を、追加の認証済みデータ（Additional Authenticated Data：ＡＡＤ）として知られているユーザ指定の属性に利用する。ＡＡＤは、Galois/Counter Mode（ＧＣＭ）などの認証暗号化モードの機能である。ＧＣＭにおいて、暗号化されたすべてのデータもまた、保護された（すなわち、認証された）インテグリティである。インテグリティが保護される（すなわち、認証される）べきであるが暗号化されていない他のデータをＡＡＤと呼ぶ。
【００２１】
しかしながら、既知の解決策では、ユーザ指定の属性は、外部ソースから一般的に受信され、要求者によって明示的に指定されなければならない。たとえば、アマゾン社製の「ＡＷＳ ＫＭＳ」では、ラップされたデータフォーマットが使用され、暗号化コンテキストのエンコードであり、ラップされたデータフォーマットにはないＡＡＤの結果をアンラップに含めることができる。任意のＡＡＤは、アンラッププロセスでラップされたＤＥＫとともにＲＥＳＴ ＡＰＩにパラメータとして提供（すなわち、オペレータ制御）される必要がある。
【００２２】
同様に、グーグル社製の「Ｃｌｏｕｄ ＫＭＳ」では、ファイルが暗号化されたときに追加の認証データが使用されたのであれば、暗号文が復号化されたときに（すなわち、ラップされた鍵そのものが提供されることなく）、同じ追加の認証データが指定されなければならない、ということをユーザは指示される。
【００２３】
既知の解決策とは対照的に、実施形態は、ラップされたデータ暗号鍵から黙示的に得られる信頼できる属性を用いてデータ暗号鍵へのアクセスを最適化することによって、ラップされたＤＥＫの承認要求の有効性を改善する。具体的には、実施形態では、ラップされたＤＥＫは、たとえば、https://tools.ietf.org/html/rfc7516で開示されている、標準のJavaScript Object Notation（ＪＳＯＮ）Web Encryption（ＪＷＥ）構造によって表される。実施形態は、カスタム属性をラップされた／暗号化されたフォーマットでエンコードする。さらに、カスタムタグおよび値は、ラップされたＤＥＫのＪＷＥ保護されたヘッダーにセットされる。ラップされたＤＥＫへのアクセスを実施するためにユーザおよびグループの情報を利用することに加えて、ラップされたＤＥＫでエンコードされたタグおよび値もまた使用される。要求者は、タグを明示的に指定する必要はない。代わりに、タグは、ラップされたＤＥＫから黙示的に取得される。タグは、ラップされたＤＥＫに追加的な承認を実施するために用いられる。
【００２４】
ＫＭＳの実施形態によってラップされたＤＥＫが構成されると、必要なタグ／値はラップされたＤＥＫでエンコードされる。したがって、セットされたタグ／値は、信頼できる機関によってセットされたと見なすことができる。
【００２５】
ＫＭＳの実施形態によってセットされたタグは、次のようなポリシーの決定を実施するために使用される：
●  所与の顧客／テナンシー用に製造（または要求）されたＤＥＫは、ＩＤＣＳのようなクラウドベースの環境において、異なる顧客／テナンシーによってアンラップされない。
●  所与のデータセンターのアプリケーションまたは管理者は、同じデータセンターで作成されて提供された、ラップされたデータの暗号化を管理できる。
●  世界中の多くの政府が施行を始めたデータの支配権、居住、およびローカリゼーションのルールの尊厳を保証および順守するため、ラップされたＤＥＫは、同じ法域でのみアンラップされる必要がある。
【００２６】
実施形態では、要求されたポリシー方針を示すラップされたＤＥＫにタグ／値を組み込むことによってホリシーの決定は実施される。タグ／値としてのラップされたＤＥＫに、ポリシーの識別子または手引きは追加で埋め込まれ得る。
【００２７】
運用時に、承認の決定のために、実施形態は、ラップされたＤＥＫからタグ情報をフェッチし、ユーザがどこからログインしているかといったことや、ユーザが所有するグループまたは管理者の特権のような、ユーザに属するタグ情報と比較する。十分に一致する場合、承認の決定は成功し、アンラッピングが許可される。
【００２８】
ラップされたＤＥＫへのアクセスを承認することを目的としたタグの組み込みおよび黙示的なフェッチングは、既存の解決策に対する技術的改善である。
【００２９】
実施形態では、REST API /admin/v1/DataEncryptionKeyGeneratorを使用してＤＥＫを作成するときに、ラップされたＤＥＫは、応答としてクライアント／ユーザに返される。ＤＥＫのアンラッピングは、ＨＳＭ９４（ＭＥＫが格納されている場所）によって実行される一方、ラップされたＤＥＫのフォーマットはＫＭＳの実施形態によって定義される。
【００３０】
ロールベースアクセス制御（Role Based Access Control：ＲＢＡＣ）および上述したような属性の使用に加えて、実施形態を使用する細かなアクセスは、ラップされたＤＥＫに黙示的に組み込まれたタグ（および値）を利用する。
【００３１】
実施形態では、以下の追加のタグが、生成されたラップされたＤＥＫに組み込まれ得る：
●  "urn:opc:kms:regionID": "uscom-central-1"
●  "urn:opc:kms:locationID": "uscom"
●  "urn:opc:kms:siID": "FF91E56E58F34CB8A806A86137966627"
【００３２】
「ＳＩＩＤ」とは、ＩＤＣＳのようなマルチテナント鍵管理クラウドソリューションでテナント（すなわち、ストライプ（stripe）またはスプライス（splice））を識別するサービスインスタンス識別子を示す。提示された（ラップされたＤＥＫ入力ペイロードから）ＳＩＩＤが現在の実行コンテキスト（すなわち、要求が向けられた場所）のＳＩＩＤと異なる場合、ラップされたＤＥＫは誤った顧客テナンシーで提示される。従って、要求は拒否される。
【００３３】
ＩＤＣＳおよびオラクルパブリッククラウドは、リージョンおよび利用可能なドメイン内にホストされる。リージョンはローカライズされた地理的領域であり、利用可能なドメインはリージョン内にある１つ以上のデータセンターである。リージョンは、いくつかの利用可能なドメインから構成される。ほとんどのリソースは、仮想クラウドネットワークのような固有のリージョンであるか、またはコンピュートインスタンスのような利用可能な固有のドメインである。
【００３４】
ラップされた鍵に組み込まれた「ｒｅｇｉｏｎＩＤ」は、リージョンに相当する。ロケーションは、リージョンの集合である。データ権限は、リージョンおよびロケーションと一致する場合と一致しない場合とがある。しかしながら、リージョンからデータ権限を導くために、外部ポリシーマッピングが考案され得る。従って、いくつかの実施形態では、鍵が製造された場所および鍵が要求／アクセスされている場所を追跡することは重要である。
【００３５】
実施形態では、実際の属性（およびそれらの値）は、実質的に問題ではない。以下に示すように、タグの検証はラップされたＤＥＫをアンラップする前に行われるため、タグの検証は最適である。
【００３６】
実施形態は、要求者がラップされたＤＥＫのアンラップを承認するか否かの承認決定評価を最適化するための既知の解決策を、承認決定に寄与し得るラップされたＤＥＫに組み込まれた属性を利用することによって改善する。これらのリソース属性（すなわち、ラップされたＤＥＫからの属性）をフェッチするための追加のステップは、それがすでにリソースに存在するため不要である。これは、それ自体が最適化である。さらに、ラップされたＤＥＫのアンラップは、ＨＳＭによって実行される暗号集約型操作である。アンラップ以前にタグを検証することによって、実施形態は、ＫＭＳインスタンスにラップされたＤＥＫを誤って示したかどうかを判断できる。これは、さらなる最適化である。
【００３７】
実施形態は、ラップされたＤＥＫを表し、オープンで相互運用可能なＤＥＫ表現構成をＫＭＳに提供するためにＪＷＥを使用する。任意のタグ／値は、ＪＷＥでエンコードされ得る。タグは、ラップされたＤＥＫを識別するために使用できる。加えて、組み込まれたタグ／値は、ラップされたＤＥＫの操作にアクセス制御を実施するために使用される。実施形態は、ラップされたＤＥＫへのアクセスを実施するために、ラップされたＤＥＫから（組み込まれたタグから）承認情報を黙示的に導く。
【００３８】
ラップされたＤＥＫは、Ａ２５６ＧＣＭ暗号化（ラッピングアルゴリズム）とともにＤＥＫの暗号化に使用されるＭＥＫ（保護されたヘッダーの子）を参照する自己記述型のエンベロープデータ構造である。構造は、JSON Web Encryption（ＪＷＥ）構造である。実施形態では、ラップされたデータ暗号鍵およびアンラップされたデータ暗号鍵（生鍵）のフォーマットは、以下の通りである：
【００３９】
【表１】
2021527970.tif 000003
2021527970.tif 000004
【００４０】
図３は、一実施形態による、ＫＭＳによってラップされたＤＥＫを生成するための機能のフロー図である。実施形態では、図３の機能は、図２のＫＭＳモジュール１６によって、または図１の中間層７６およびデータ層９２によって実装される。一実施形態では、図３（および以下の図４）のフロー図の機能は、メモリまたは他のコンピュータ可読媒体もしくは有形媒体に記憶されたソフトウェアによって実装され、プロセッサによって実行される。他の実施形態では、機能は、ハードウェア（例えば、特定用途向け集積回路(ＡＳＩＣ)、プログラマブルゲートアレイ(ＰＧＡ)、フィールドプログラマブルゲートアレイ(ＦＰＧＡ)などの使用を通じて）、またはハードウェアとソフトウェアとの任意の組合せによって提供され得る。
【００４１】
３０２において、ラップされたＤＥＫの要求がクライアントから受信され、サービスインスタンス用の（マルチテナントの実施形態では）生ＤＥＫが受信される。一般的に、生ＤＥＫは、アンラップされた鍵であり、メタデータまたはその他の情報は添付されていない。実施形態では、要求はＲＥＳＴ ＡＰＩを介して受信される。実施形態では、クライアントは、ＩＤＣＳまたは別のタイプのクラウドサービスといったマルチテナントサービスの一部である。
【００４２】
３０４において、ランダムキー「Ｋ」が生成される。
【００４３】
３０６において、リージョンＩＤ（複数の地理的リージョンを有する実施形態では）を含むＡＡＤ情報（または、より一般的には、「暗号化コンテキスト」）、サービスＩＤおよびロケーションＩＤはフェッチされる。ロケーションＩＤは、実施形態では、クライアントが要求を行っている場所を示す。
【００４４】
３０８において、３０４のランダムキーおよび３０６のＡＡＤ情報を用いて、ラップされたＤＥＫが生成される。
【００４５】
３１０において、保護されたヘッダー、暗号化された鍵、初期化ベクトル（Initialization Vector：ＩＶ）、および認証タグを含むＪＷＥ応答が生成される。ＩＶは、ランダムで予測不可能な値であり、隠されたものではなく、各暗号化の開始時に使用される。認証付き暗号モード（たとえば、ＧＣＭ）における認証タグは、データが何かしらの方法で変更されたかどうかを判断するためのチェックサムを行うための値である。データが変更されていなければ、送信タグと計算タグとは同じでなければならない。タグは、暗号化データおよびＡＡＤの両方を保護する。
【００４６】
３１２において、ラップされたＤＥＫと生ＤＥＫは、応答でクライアントに返される。
【００４７】
図４は、一実施形態によるＫＭＳによってラップされたＤＥＫをアンラップするための機能のフロー図である。実施形態では、図４の機能は、図２のＫＭＳモジュール１６によって、または図１の中間層７６およびデータ層９２によって実装される。
【００４８】
４０２において、（マルチテナントの実施形態では）サービスインスタンス用に、ラップされたＤＥＫをアンラップするための要求が受信される。実施形態では、要求は、ＲＥＳＴ ＡＰＩを介して受信され、ラップされたＤＥＫはＪＷＥの形式である。
【００４９】
４０４において、ＪＷＥ形式でのラップされたＤＥＫがパースされる。
【００５０】
４０６において、パースステータスが失敗した場合、機能は終了し、エラーメッセージが出力される。入力において構文エラーがあった場合にパースステータスが失敗する。
【００５１】
４０８において、ＡＡＤの詳細は、４１０以降の以下の機能で検証される。リージョンＩＤ、サービスＩＤ、およびロケーションＩＤなどの値は、実施形態では、クラウドベースのシステムにおいて顧客区分がセットアップされるときに管理上割り当てられる定義されたリージョン、サービスまたはロケーションのリストにこれらの値が現れるかどうかを決定することによって検証される。
【００５２】
４１０において、リージョンＩＤが検証される。有効でない場合、機能は終了し、エラーメッセージが出力される。
【００５３】
４１２において、サービスＩＤが検証される。有効でない場合、機能は終了し、エラーメッセージが出力される。
【００５４】
４１４において、ロケーションＩＤが検証される。有効でない場合、機能は終了し、エラーメッセージが出力される。
【００５５】
４１６において、ＨＳＭにあるＭＥＫは検証される。有効でない場合、機能は終了し、エラーメッセージが出力される。
【００５６】
４１８において、ＨＳＭはラップされたＤＥＫ、ＩＶおよびＡＡＤを用いてラップされたＤＥＫをアンラップする。したがって、実施形態におけるすべての検証は、ラップされたＤＥＫがアンラップされる（すなわち、ラップされた鍵が復号化される）前に行われる。
【００５７】
４２０において、アンラップされた生鍵は、クライアントに返される。
【００５８】
上記開示されるように、実施形態はＡＡＤのリージョンＩＤ、サービスＩＤおよびロケーションＩＤの値を使用するが、要求を検証することに役立つことができる他の任意のタグ／値／パラメータを使用できる。ラップされた鍵は、生成時にＡＡＤ領域に格納された適切な値を有する。これらの値は、隠されたものではないが、ＡＡＤにあるため、調べることなく、これらの値を変更することはできない。鍵がアンラップされて使用されるときに、「正しい」値が、設定データから判断され、ＡＡＤに格納された値と比較される。それらが一致しない場合、鍵は使用できない。
【００５９】
異なるポリシーは、どのアイテムが必要で、何が一致する必要があるかを判断できる。ラップされた鍵を所持するものは誰でもＡＡＤ領域を読み取ることができるため、これは主に設定エラーを検出するためのものである。しかしながら、ＡＰＩが、実行されるチェックと、構成された値の取得元とを制御する場合、これはセキュリティ対策として機能し、鍵が誤ったコンテキストで使用されることを防ぐことができる。
【００６０】
開示されるように、実施形態は、鍵のヘッダーに組み込まれたＡＡＤを有するラップされたＤＥＫを生成した。ラップされたＤＥＫをアンラップする要求を受信したときに、組み込まれたＡＡＤは、ＫＭＳによる検証に使用される。したがって、外部ＡＡＤは必要ない。
【００６１】
いくつかの実施形態が、本明細書で具体的に例示および/または説明される。しかしながら、開示された実施形態の修正および変形は、本発明の思想および意図された範囲から逸脱することなく、上記教示によって、および添付のクレームの範囲内に含まれることが理解されるであろう。
【図１】
2021527970.tif 000005
【図２】
2021527970.tif 000006
【図３】
2021527970.tif 000007
【図４】
2021527970.tif 000008
【国際調査報告】
2021527970.tif 000009
2021527970.tif 000010
2021527970.tif 000011