JP2022503297A - 暗号鍵管理システムのサービスインスタンスのリワイヤリング - Google Patents

Abstract

実施形態は、鍵に関連した鍵管理システム(KMS)サービスインスタンス(SI)を、リワイヤリングすることに向けられる。実施形態では、要求に応答して、１つ以上の鍵にマッピングされた第１のSIを削除する。鍵を復元するために、実施形態は、第２のSIを生成し、第２のSIを１つ以上の鍵にマッピングする。

Description

分野
一実施形態は、一般にコンピュータシステムに関し、特にコンピュータシステムにおける暗号鍵の管理に関する。

背景の情報
鍵管理サービス(KMS)は、暗号システムにおける暗号鍵の管理を提供する。管理は、鍵の生成、交換、保存、使用、暗号シュレッディング(すなわち、破壊)、および置換の機能を含む。それは、暗号プロトコル設計、鍵サーバ、ユーザ手順、および他の関連するプロトコルを含む。

KMS内の鍵は、データを暗号化および復号化し、データをそれが記憶された場所で保護するために使用される暗号素材を含む１つ以上の鍵バージョンを表す論理エンティティである。暗号化アルゴリズムの一部として処理されるとき、鍵は、暗号化中に平文をどのように暗号文に変換し、復号化中に暗号文をどのように平文に変換するかを指定する。KMSは、一般に、２種類の暗号鍵を認識する。それらは、マスター暗号鍵(MEK)およびデータ暗号鍵(DEK)である。KMSを使用してマスター暗号鍵を生成した後、ユーザは、KMSがユーザに返すデータ暗号鍵を生成するために、アプリケーションプログラミングインターフェース(API)を使用することができる。KMSは生鍵およびラップ鍵を返す。典型的には、ユーザは、ラップ鍵のみを保存する。

概要
実施形態は、鍵に関連した鍵管理システム(KMS)サービスインスタンス(SI)をリワイヤリングすることに向けられる。実施形態は、要求に応答して、１つ以上の鍵にマッピングされた第１のSIを削除する。鍵を復元するために、実施形態は、第２のSIを生成し、その第２のSIを１つ以上の鍵にマッピングする。

図１は、本発明の実施形態による鍵管理サービスの高レベルの概要を示す図である。 図２は、本発明の一実施形態によるコンピュータサーバ/システムのブロック図である。 図３は、一実施形態による、ユーザ/カスタマーがサービスインスタンスを削除するための機能のフロー図である。 図４は、一実施形態による、ユーザ/カスタマーが削除されたサービスインスタンスを復元するための機能のフロー図である。 図５は、一実施形態による、新規に作成されたサービスインスタンスを削除されたマスター暗号鍵にリワイヤするための機能のフロー図である。 図６Ａは、実施形態によるDB SCHEMA MAPテーブルのリワイヤ前後のサービスインスタンスの例を示す図である。 図６Ｂは、実施形態によるDB SCHEMA MAPテーブルのリワイヤ前後のサービスインスタンスの例を示す図である。 図６Ｃは、実施形態によるDB SCHEMA MAPテーブルのリワイヤ前後のサービスインスタンスの例を示す図である。 図７は、実施形態による、SIを管理するためのPaaSサービスマネージャ(PSM)UIのスクリーンショットである。 図８は、実施形態による、SIを強制的に削除するときのPSM UIのスクリーンショットである。 図９は、実施形態による、ユーザが鍵を管理することを可能にするSI管理コンソールのスクリーンショットである。 図１０は、実施形態による、新しいサービスインスタンスを作成または削除するためのPSM UIのスクリーンショットである。

詳細な説明
一実施形態は、サービスインスタンスの削除およびMEKへの対応するアクセスがKMSのユーザ/カスタマーによって復元され得る鍵管理サービス(KMS)である。新しいサービスインスタンスが生成され、その新しいサービスインスタンスは“削除された”MEKにマッピングされる。

図１は、本発明の実施形態によるKMS７０の高レベルの概要を示す。複数のKMSクライアント７２は、１つ以上のウェブサーバ７６からのリプリゼンテーショナルステートトランスファー（representational state transfer：REST）アプリケーションプログラムインターフェース(API)を使用して、鍵を要求する。鍵を要求してその鍵を利用できるクライアント７２は、データベース８１を含む。一実施形態では、データベース８１は、テーブルおよびテーブルスペースに格納される機密データの暗号化を可能にする透過的データ暗号化（Transparent Data Encryption：TDE)を含むオラクル社製のデータベースである。データが暗号化された後、このデータは、許可されたユーザまたはアプリケーションがこのデータにアクセスする際に、それらによって透過的に復号される。本実施形態では、データベース８１は、KMS-DBエージェント８５を含む。他の要求クライアント７２は、クラウド環境内の様々なクラウドサービス８２、様々なカスタマーアプリケーション８３、または図１に示すKMSを含むクラウドシステム全体のユーザまたはカスタマーとも称されるアカウント管理者によって操作される管理コンソール８４を含むことができる。

一実施形態では、１つ以上のウェブサーバ７６はクラウドベースのサーバである。実施形態では、ウェブサーバ７６は、クロスドメインアイデンティティ管理(SCIM)のためのREST API７５ベースのシステムを公開する中間層コンポーネント７６によって実装される。一実施形態では、中間層７６は、データ層９２と通信するステートレスマイクロサービスのセットを含む。

一実施形態では、中間層７６を実装することができるマイクロサービスは、独立して配備可能なサービスである。一実施形態では、「マイクロサービス」という用語は、複雑なアプリケーションが言語に依存しないAPIを使用して互いに通信する小さな独立したプロセスから構成される、ソフトウェアアーキテクチャ設計パターンを考慮している。一実施形態では、マイクロサービスは、小型で高度に切り離されたサービスであり、各々は、小型タスクを行うことに焦点を当てるであろう。一実施形態では、マイクロサービスアーキテクチャスタイルは、単一のアプリケーションを１組の小さなサービスとして開発するためのアプローチであり、それぞれがそれ自体のプロセスで実行され、軽量メカニズム(例えば、ハイパーテキスト転送プロトコル(HTTP)リソースAPI)と通信する。一実施形態では、マイクロサービスは、同じ機能の全部または多くを実行するモノリシックサービスと比較して、置換しやすい。さらに、各マイクロサービスは、他のマイクロサービスに悪影響を及ぼすことなく更新されるであろう。対照的に、モノリシックサービスの一部分への更新は、モノリシックサービスの他の部分に望ましくないまたは意図しない否定的な影響を与えるかもしれない。一実施形態では、マイクロサービスは、それらの能力の周辺において有益に編成されるであろう。一実施形態では、マイクロサービスのコレクションのそれぞれに対する起動時間は、それらのマイクロサービスのすべてのサービスを集合的に実行する単一のアプリケーションに対する起動時間よりもはるかに短い。いくつかの実施形態では、そのようなマイクロサービスの各々に対する起動時間は、約１秒以下であるが、そのような単一アプリケーションの起動時間は、約１分、数分、またはそれより長いかもしれない。

一実施形態では、中間層７６などのマイクロサービスアーキテクチャは、サービス指向アーキテクチャ(SOA)が柔軟で独立して配備可能なソフトウェアシステムを構築するための専門化(すなわち、システム内のタスクの分離)手法および実装手法を指す。マイクロサービスアーキテクチャにおけるサービスは、目的を果たすためにネットワークを介して互いに通信するプロセスである。一実施形態では、これらのサービスは、技術に捕らわれないプロトコルを使用する。一実施形態では、それらのサービスは、小さい粒度を有し、かつ、軽量プロトコルを使用する。一実施形態では、それらのサービスは独立して配備可能である。システムの機能を異なる小さなサービスに分散させることによって、システムのコヒージョンが増強され、システムの結合が低減される。これにより、システムの変更、システムへの機能および品質の追加をいつでも容易に行うことができる。また、これは、連続的なリファクタリングを通じて、個々のサービスのアーキテクチャが出現することを可能にし、それゆえ、大きなアップフロント設計の必要性を低減するとともにソフトウェアを早期かつ連続的にリリースすることを可能にする。

一実施形態では、マイクロサービスアーキテクチャにおいて、アプリケーションは、サービスのコレクションとして開発され、各サービスは、それぞれのプロセスを実行し、軽量プロトコルを使用して通信する(例えば、各マイクロサービスに固有のAPI)。マイクロサービスアーキテクチャにおいて、ソフトウェアは、提供されるサービスに応じて異なるレベルの粒度で、個々のサービス/能力に分解することができる。サービスは、ランタイムコンポーネント/プロセスである。各マイクロサービスは、他のモジュール/マイクロサービスと対話することができる自己内蔵モジュールである。各マイクロサービスは、他のマイクロサービスによってコンタクトされ得る、アンネームドユニバーサルポートを有する。一実施形態では、マイクロサービスのアンネームドユニバーサルポートは、マイクロサービスが慣習によって(たとえば、従来のHTTPポートとして)公開し、同じサービス内の任意の他のモジュール/マイクロサービスがそれと対話することを可能にする標準通信チャネルである。マイクロサービスまたは任意の他の自己内蔵型機能モジュールは、一般的に「サービス」と称され得る。

データ層９２は、ハードウェアセキュリティモジュール(HSM)９４およびデータベース９５を含む。HSMは、強力な認証のためにデジタル鍵を安全にし、かつ、管理するとともに暗号処理を提供する物理的なコンピューティングデバイスである。これらのモジュールは、従来より、コンピュータまたはネットワークサーバに直接取り付けられるプラグインカードまたは外部装置の形態をとる。MEKはHSM９４およびHSM９４内に常駐して、MEKに関わる暗号サービスを提供する。アプリケーション鍵およびすべてのメタデータは、データベース９５内に格納される。中間層７６およびデータ層９２のすべての構成要素は、いくつかの実施形態では、高可用性（high availability：HA）および災害時リカバリー（disaster recovery：DR）を伴って実装される。

一実施形態では、データベース９５は、オラクル社製のリレーショナルデータベース管理システム(RDMS)データベースで実装される。オラクルデータベースのコンテキストでは、スキーマオブジェクトは論理データ記憶構造である。オラクルデータベースは、別個のスキーマを各データベースユーザと関連付ける。スキーマは、スキーマオブジェクトの集合を備える。スキーマオブジェクトの例は、表、ビュー、シーケンス、同義語、インデックス、クラスタ、データベースリンク、スナップショット、手順、関数またはパッケージを含む。一方、非スキーマオブジェクトは、ユーザ、役割、コンテキストまたはディレクトリオブジェクトを含み得る。

スキーマオブジェクトは、それらの情報を記憶するディスク上の物理ファイルと１対１の対応関係を有していない。しかしながら、オラクルデータベースは、データベースのテーブルスペース内にスキーマオブジェクトを論理的に格納する。各オブジェクトのデータは、テーブルスペースのデータファイルのうちの１つまたは複数に物理的に含まれる。いくつかのオブジェクト(テーブル、インデックス、およびクラスタなど)について、データベース管理者は、オラクルRDBMSがオブジェクトのためにテーブルスペースのデータファイル内にどのくらいのディスク空間を割り当てるかを指定することができる。スキーマとテーブルスペースとの間には必要な関係はない。すなわち、テーブルスペースは、異なるスキーマからのオブジェクトを含むことができ、単一のスキーマのためのオブジェクトは、異なるテーブルスペース内に存在することができる。

一実施形態では、中間層７６およびデータ層９２は、オラクル社製のマルチテナント、クラウドスケール、アイデンティティアクセスマネジメント(IAM)プラットフォームであるアイデンティティクラウドサービス(IDCS)によって提供される認証サービスによって実装される。IDCSは、認証、承認、監査、およびフェデレーションを提供する。IDCSは、パブリッククラウド上で動作するカスタムアプリケーションおよびサービスへのアクセス、ならびにオンプレミスシステムを管理する。代替または追加の実施形態では、IDCSはまた、公衆クラウドサービスへのアクセスを管理することもできる。例えば、IDCSは、様々なサービス/アプリケーション/システムにわたってシングルサインオン(SSO)機能を提供するために利用され得る。ユーザおよびクライアントは、最初にIDCSに対して認証し、KMSアクセスに適したトークンを獲得しなければならない。境界認証は、IDCSクラウドゲートによって実施される。KMS APIへの細やかなアクセスは、クライアントと管理者とを区別するために使用される適切な範囲および役割を有する認可モジュールによって実施される。IDCSのさらなる詳細は、例えば米国特許９,８３８,３７６に開示されており、その開示は参照により本明細書に組み込まれる。

実施形態では、KMSは、SIのための水平分割をサポートする。したがって、各SIは、１つ以上のDBインスタンスにわたって作成された専用のスキーマに関連付けられる。プリモディアル（primordial）DBは、ログインディテイルに加えて、どのSIスキーマがどのDBインスタンスに存在するかということに関する情報を含む中央DBである。それもまた、SIからテナントへのマッピングも持続する。

図２は、本発明の一実施形態によるコンピュータサーバ/システム１０のブロック図である。単一のシステムとして示されているが、システム１０の機能は、分散システムとして実装することができる。さらに、本明細書で開示される機能は、ネットワーク上で互いに接続され得る個別のサーバまたはデバイス上で実装され得る。さらに、システム１０の１つ以上の構成要素は含まれなくてもよい。たとえば、サーバの機能のために、システム１０は、プロセッサおよびメモリを含む必要があり得るが、キーボードまたはディスプレイなど、図２に示される他の構成要素のうちの１つ以上を含まなくてもよい。システム１０の全部または一部は、いくつかの実施形態において、図１に示されるコンポーネントのいずれかまたは全てを実装するために使用されてもよい。

システム１０は、情報を通信するためのバス１２または他の通信メカニズムと、情報を処理するためにバス１２に接続されたプロセッサ２２とを含む。プロセッサ２２は、汎用または専用プロセッサのいずれのタイプとしてもよい。システム１０は、情報およびプロセッサ２２によって実行されるべき命令を記憶するためのメモリ１４をさらに含む。メモリ１４は、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、磁気もしくは光ディスクなどの静的な記憶装置、または任意の他のタイプのコンピュータ可読媒体のうちの任意の組み合わせから構成され得る。システム１０は、ネットワークへのアクセスを提供するための、ネットワークインターフェースカードなどの通信デバイス２０をさらに含む。したがって、ユーザは、直接、またはネットワークまたは任意の他の方法を介してリモートで、システム１０とインターフェース接続することができる。

コンピュータ可読媒体は、プロセッサ２２によってアクセスされ得る任意の利用可能な媒体であってよく、揮発性媒体および不揮発性媒体の両方、取り外し可能媒体および取り外し不能媒体、通信媒体を含む。通信媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または搬送波若しくは他のトランスポートメカニズムなどのような、変調されたデータ信号中の他のデータを含んでもよく、任意の情報配信媒体を含む。

プロセッサ２２は、バス１２を介して液晶ディスプレイ(LCD)などのディスプレイ２４にさらに接続される。キーボード２６およびコンピュータマウスなどのカーソル制御装置２８は、ユーザがシステム１０とインターフェース接続できるようにバス１２にさらに接続される。

一実施形態では、メモリ１４は、プロセッサ２２によって実行されると機能を提供するソフトウェアモジュールを記憶する。モジュールは、システム１０のオペレーティングシステム機能を提供するオペレーティングシステム１５を含む。モジュールは、KMS機能、および本明細書で開示される他のすべての機能を提供するKMSモジュール１６をさらに含む。システム１０は、より大きなシステムの一部とすることができる。したがって、システム１０は、上述したIDCS機能などの追加機能を含むための１つ以上の追加機能モジュール１８を含むことができる。データベース１７は、モジュール１６および１８のためのセントラライズドストレージを提供するとともに、キー、パスワードなどを格納するためにバス１２に接続される。一実施形態では、データベース１７は、格納されたデータを管理するために構造化クエリ言語(SQL)を使用することができるリレーショナルデータベース管理システム(RDBMS)である。

前述したように、KMSにおいてユーザによって作成された鍵(すなわち、「MEK」)は、ユーザの機密データのすべてを暗号化するために使用されるので、必須の役割を果たす。鍵は、図１のHSM９４のようなデータストアまたはデータベーススキーマの形態でハードウェアベースのパーシスタントストアに格納される。ユーザのデータが暗号化されている限り、暗号化データへのアクセスはもはや利用可能ではないので、ユーザは鍵を失わないようにする必要がある。オラクルパブリッククラウド(OPC)では、ユーザは、彼らのクラウドアカウントのための複数のKMSインスタンスを作成することができる。サービスインスタンスは、カスタマーが鍵にアクセスすることを可能にするAPIである。SIが生成されると、新しいSI ユニフォームリソースロケーター（Uniform Resource Locator：URL)が生成され、このURLは、ユーザがそこから鍵を管理することができるSI管理コンソールUIとして機能する。

しかしながら、一部のKMSは、ユーザがMEKを削除することを可能にする。例えば、オラクル社製のKMSでは、鍵は削除され得る。しかしながら、鍵が削除される前に、KMSは以下の警告を提供する。「鍵をペンディングデリーション状態にすると、その鍵で暗号化されているものが直ちにアクセス不能となります。また、いずれのリソースに対しても鍵を割り当てることができず、またはいずれのリソースに対する鍵の割り当て解除もできず、あるいは、鍵を更新することができません。鍵が削除されると、すべての鍵素材およびメタデータが不可逆的に破壊されます。鍵を削除する前に、その鍵によって現在暗号化されているリソースに対して新しい鍵を割り当てるか、または別の方法でデータを保存してください。鍵が永続的に削除される前にあなたがその鍵の使用を復元することを望む場合、あなたは、その削除をキャンセルすることができます。」
しかしながら、ユーザのサービスインスタンス(SI)の偶発的な削除が生じた場合、ユーザは、暗号化データが解読不能になるという重大な結果に直面するであろう。したがって、一般に、ユーザが以前に作成したすべてのMEKを削除しない限り、通常のKMS SI削除は許可されない。いくつかの公知のシステムでは、MEKが存在するサービスインスタンスを削除する唯一の方法は、「Force Delete」を選択することによるものである。これは、カスタマー管理者ジェスチャーによって、または管理者コンソール８４を使用したPSM UIへのログインを介して行うクラウドアカウント削除の一部として、開始することができる。

図３は、一実施形態による、ユーザ/カスタマーがサービスインスタンスを削除するための機能のフロー図である。実施形態では、図３の機能は、図２のKMSモジュール１６によって、または図１の中間層７６およびデータ層９２によって実装される。一実施形態では、図３(ならびに以下の図４および５)のフロー図の機能は、メモリまたは他のコンピュータ可読媒体もしくは有形媒体に記憶されたソフトウェアによって実装され、プロセッサによって実行される。他の実施形態では、機能は、ハードウェア(例えば、特定用途向け集積回路(ASIC)、プログラマブルゲートアレイ(PGA)、フィールドプログラマブルゲートアレイ(FPGA)などの使用を通じて)、またはハードウェアとソフトウェアの任意の組み合わせによって実行され得る。図３の機能は、公知のオラクル KMSに対応するものである。開示される機能のために、実施形態では、KMSプリモディアルDBおよびサービスインスタンスDBの両方が動作中であると仮定する。

３０１において、ユーザ/カスタマーは、PaaSサービスマネージャツール(PSM)ユーザインターフェース(UI)にログインするか、またはPSMレストAPIを使用する。PSMは、ユーザがオラクルクラウド内の様々なプラットフォームサービスのライフサイクルを管理することを可能にするコマンドラインインターフェース(CLI)を提供する。CLIは、オラクルジャバクラウドサービス、オラクルデータベースクラウドサービスインスタンス、およびオラクルMySQLクラウドサービスのインスタンスの作成および管理、またはオラクルアプリケーションコンテナークラウドサービスのアプリケーションの作成および管理を含む、共通のPaaSフィーチャーをサポートするためにこれらのAPIを呼び出すPaaS REST API上のシンラッパーである。CLIはまた、クラウド環境のプロビジョニングおよび削除を自動化するPaaSツールであるオラクル クラウドスタックマネージャをサポートする。管理コンソール８４は、PSM UIにアクセスするために実施形態において使用され得る。

実施形態において、「KMS コンソール」と称される別のサービスインスタンス固有のコンソールは、サービス管理者が鍵を管理および操作することを可能にする。PSM管理者コンソール８４は、ユーザをPSM管理者コンソールからKMSコンソールに導くSI URLリンクを提供する。PSM管理者コンソールは、テナント/カスタマーのための複数のKMSサービスインスタンスの管理に向けられたものであり、一方、KMS コンソールは、１つのサービスインスタンスに対する鍵のみの管理を可能にする。

３０２において、ユーザは、１つ以上の対応するMEKによるSIの削除を示す。MEKは、実施形態において最初に削除される必要はない。３０３において、ユーザがSIの強制的な削除を望むことをユーザーが確かめるためのプロンプトが生成される。ユーザが「No」で応答する場合、３０６において、SI削除は失敗する。そうでなければ、３０４において、SIが削除され、対応するSIユニフォームリソースロケータ(URL)はアクセス不能である。上述したように、SIの削除はまた、ユーザがもはや、いずれの対応する、格納されたMEKにもアクセスできないことを意味する。しかしながら、状況によっては、ユーザは、上述の警告にもかかわらず、彼らのSIを「偶発的に」削除するであろう。

図３の機能性の結果として、ユーザが、例えばPSM UIまたはPSM Rest APIを通じて彼らのKMS SIを削除した後、ユーザは、削除されたサービスインスタンスにマッピングされたDB スキーマに逆らって問い合わせるために、SIのHSM鍵にアクセスすることも、KMSコンソールにアクセスすることもできないであろう。いくつかの実施形態におけるSIの削除動作の一部として、次のことがいえる。

・SIステータスは、KMSデータベース９５(図１)のSERVICE_INSTANCEデータベーステーブルにおいてSOFT_TERMINATEDとしてマークされるであろう。

・削除されたサービスインスタンスに対応するDB SCHEMA MAPテーブルの行は、STALEとしてマークされるであろう。

・削除されたKMSサービスインスタンスのDBスキーマならびにHSM鍵は、完全なパージングが起こる前に３０日間保持されるであろう。

したがって、実施形態において、実際のＭＥＫは予め定めた期間が経過するまで削除されないため、機能はユーザに対して、削除されたＫＭＳサービスインスタンスのため、３０日以内に（実施形態における図３の機能性から）彼らのＫＭＳサービスインスタンスＫＭＳ鍵アーティファクトへのアクセスを取り戻すことを提供する。以下に開示されるように、ユーザは新しいKMS SIを作成し、削除されたKMSサービスインスタンスDBスキーマは、新たに作成されたKMS SIにリワイヤされる。

実施形態は、ユーザが、鍵へのアクセスを復元することを可能にし、ゆえに、強制的なサービスインスタンスの削除後に鍵管理オペレーションを再度、インスタンス化することを可能にする、リワイヤリング自動化フレームワークに向けられる。このフレームワークは、削除されたサービスインスタンスの古い鍵を新しいサービスインスタンスに関連付ける。それは、キーがHSMから永久に削除されてから、定まった日数以内に実行されるべきであり、これらの鍵を取り戻す方法は存在しない(例えば、３０日)。

図４は、一実施形態による、削除されたSIをユーザ/カスタマーが復元するための機能のフロー図である。実施形態では、図４の機能は、図２のKMSモジュール１６によって、または図１の中間層７６およびデータ層９２によって実装される。図４の機能は、実施形態において図３の機能の後に起こる。

４０１において、ユーザは、削除されたMEKを復元するためのサービス要求(SR)を作成する。４０２において、運用チームエンジニアであり得る開発およびオペレーション（デブオプス（devops））エンジニアは、SRに取り組み、ユーザに新しいSIを作成するよう要求する。実施形態では、追加のオプションは、PSM管理者コンソールに公開され、ユーザが新しいSIを作成するときはいつでも、バックエンドで新しいスキーマを作成することを選択することができるか、または削除された古いサービスインスタンスのスキーマでこの新しいサービスインスタンスをワイヤアップすることを選択することができるようになる。この機能性は自動化することもできる。４０３において、ユーザは新しいSIを作成する。

図５は、一実施形態による、新規に作成されたSIを削除されたMEKにリワイヤリングするための機能のフロー図である。実施形態では、図５の機能は、図２のKMSモジュール１６によって、または図１の中間層７６およびデータ層９２によって実装される。実施形態において、図５の機能は図４の機能の後に起こる。

５０１において、自動化スクリプトが実行される。一実施形態では、デブオプスは、「オラクル」ユーザの役割を用いて中間層で管理者ノードにログインすることによって、自動化スクリプトを実行する。他の実施形態では、自動化スクリプトは、自動的に実行され得る。５０２において、自動化スクリプトは、デブオプスによって与えられるすべての入力パラメータとともにadmin-cliを呼び出す。Admin-cliは、KMS中間層内のAdminノードにおいてデブオプスエンジニアによって実行されるコマンドラインインターフェースである。admin-cliの目的は、コマンドラインからの、削除されたSI名および新たに作成されたSI名を受け入れて、それらを自動化処理に渡すことである。

擬似コードの一実施形態による擬似コードは、以下のとおりである。
# 削除されたＳＩを新たなＳＩでリワイヤするスクリプト
setupenv_config() {
// 自動化のためのブートトラップ構成を設定
}
get_input() {
// コマンドラインからSI名及び新たに作成したSI名を削除
}
perform_rewire() {
// リワイヤの準備
// リワイヤ要求の構築
}
execute_rewire_cli() {
//削除されたSI名および新しく作成されたSI名を渡し、オートリワイヤジャバサービスcliを呼び出す。[図５の項目５０４を参照]
}
flush_global_cache() {
// リワイヤが成功すれば、その後、削除されたSI参照オブジェクトをglobal_cacheから除去する。
}
５０４において、admin-cliは、新たに生成されたSIにデータベース９５内の削除されたSIスキーマを指定させることによってリワイヤリングエグゼキューションを実行する。５０３において、自動化スクリプトはリワイヤリングの成功後にdbSchemaMapオブジェクト上に選択的なキャッシュフラッシュを行う。SIが削除されるとき、そのリファレンスドSIデータオブジェクトはグローバルキャッシュから除去される(すなわち、フラッシュされる)。

５１１において、ユーザはPSM UIにアクセスする。５１２において、ユーザは、図３からの新しいSI URLを使用してKMSコンソールUIを起動する。５１３において、ユーザは、削除されたSI MEKを見ることができ、それは、MEKが現在利用可能であることを示している。

図６Ａ～Ｃは、実施形態による、DB SCHEMA MAPテーブルのリワイヤリング前後のサービスインスタンスの例を示す。

図６Ａは、ワイヤリング前のテーブルを示す--スキーマネーム６０２（すなわち、スキーマネームの最後が「６９３」で終わる）を指し示す、GLOBAL_KMS.DB_SCHEMA_MAPテーブル(すなわち、６０１の「stale」）において削除されたKMS SIの状態である。図６Ｂは、スキーマ名６０４を指し示し(すなわち、スキーマネームの最後が「６９４」で終わる)、新しいKMS SIが作成された(すなわち、６０３の「inuse」)後のテーブルを示す。図６Ｃは、自動化スクリプトが実行された後の予期される状態を示し、６０５で削除の準備が整っている、以前のSIスキーマ名６０２を指し示す(すなわち、再マッピングされる)新しいSI６０３を示す。

図７は、実施形態による、SIを管理するためのPSMUIのスクリーンショットである。アクティブサービスインスタンスが７０１に示されており、ユーザは、追加的なサービスインスタンスを作成するためにボタン７０２を選択することができる。

図８は、実施形態による、SIを強制的に削除するときのPSM UIのスクリーンショットである。８０１において、図３の３０３に対する削除後チェックボックスを含む警告がユーザに提示される。

図９は、実施形態による、ユーザが鍵を管理することを可能にするSI管理コンソールのスクリーンショットである。さらに、図９は、新しいSIがリワイヤされた後にユーザが以前に「削除された」MEKのすべてを見ることができるように、図５の５１３に関連してユーザに提供される。

図１０は、実施形態による、新しいサービスインスタンスを作成または削除するためのPSM UIのスクリーンショットである。１００１において、ユーザは、他のオプションと同様に、選択されたサービスインスタンスを削除することができる。

いくつかの実施形態が、本明細書で具体的に例示および/または説明される。しかしながら、開示された実施形態の修正および変形は、本発明の思想および意図された範囲から逸脱することなく、上記教示によって、および添付のクレームの範囲内に含まれることが理解されるであろう。

Claims (20)

1. 鍵に関連した鍵管理システム(KMS)サービスインスタンス(SI)をリワイヤリングする方法であって、
   要求に応答して、１つ以上の鍵にマッピングされる第１のSIを削除し、
   第２のSIを生成し、
   前記第２のSIを前記１つ以上の鍵にマッピングする、方法。
2. 前記第１のSIは、データベーススキーマにマッピングされ、ユーザが前記鍵を管理することを可能にするユニフォームリソースロケータ(URL)に関連付けられる、請求項１に記載の方法。
3. 前記第１のSIを削除することにより、前記ユーザによる前記鍵へのアクセスが削除される、請求項２に記載の方法。
4. 前記鍵はマスター暗号化鍵(MEK)を含み、ハードウェアセキュリティモジュール(HSM)に格納される、請求項１に記載の方法。
5. 前記第２のSIを前記１つ以上の鍵にマッピングすることは、前記第２のSIを前記データベーススキーマにマッピングすることを含む、請求項２に記載の方法。
6. 前記第１のSIを削除することに応答して、前記鍵は、所定時間の経過後に削除される、請求項１に記載の方法。
7. 前記マッピングは、前記KMSの中間層によって実装され、前記中間層は、１つ以上のマイクロサービスによって実装される、請求項１に記載の方法。
8. 鍵管理システム(KMS)であって、
   １つ以上のマイクロサービスを含む中間層と、
   中間層に結合され、１つ以上のハードウェアセキュリティモジュール(HSM)および１つ以上のデータベースを含むデータ層とを備え、
   前記中間層は、第１の要求に応答して、１つ以上の鍵にマッピングされる第１のサービスインスタンス(SI)を削除し、第２の要求に応答して、第２のSIを生成し、前記第２のSIを前記１つ以上の鍵にマッピングするように適合される、鍵管理システム。
9. 前記第１のSIは、前記データベースのデータベーススキーマにマッピングされ、ユーザが前記鍵を管理することを可能にするユニフォームリソースロケーター（URL）に関連付けられる、請求項８に記載の鍵管理システム。
10. 前記第１のSIを削除することにより、前記ユーザによる前記鍵へのアクセスが削除される、請求項９に記載の鍵管理システム。
11. 前記鍵は、マスター暗号鍵(MEK)を含み、前記HSMに格納される、請求項８に記載の鍵管理システム。
12. 前記１つ以上の鍵に前記第２のSIをマッピングすることは、前記第２のSIを前記データベーススキーマにマッピングすることを含む、請求項９に記載の鍵管理システム。
13. 前記第１のSIの削除に応答して、前記鍵は、所定時間の経過後に削除される、請求項８に記載の鍵管理システム。
14. １つ以上のプロセッサによって実行されると、前記プロセッサに、鍵に関連する鍵管理システム(KMS)サービスインスタンス(SI)をリワイヤさせる命令を記憶した非一時的なコンピュータ可読媒体であって、
    前記リワイヤすることは、
    要求に応答して、１つ以上の鍵にマッピングされる第１のSIを削除し、
    第２のSIを生成し、
    前記第２のSIを前記１つ以上の鍵にマッピングすることを含む、コンピュータ可読媒体。
15. 前記第１のSIがデータベーススキーマにマッピングされ、ユーザが前記鍵を管理することを可能にするユニフォームリソースロケータ(URL)に関連付けられる、請求項１４に記載のコンピュータ可読媒体。
16. 前記第１のSIを削除することにより、前記ユーザによる前記鍵へのアクセスが削除される、請求項１５に記載のコンピュータ可読媒体。
17. 前記鍵は、マスター暗号化鍵(MEK)を含み、ハードウェアセキュリティモジュール(HSM)に格納される、請求項１４に記載のコンピュータ可読媒体。
18. 前記１つ以上の鍵に前記第２のSIをマッピングすることは、前記第２のSIを前記データベーススキーマにマッピングすることを含む、請求項１５に記載のコンピュータ可読媒体。
19. 前記第１のSIを削除することに応答して、前記鍵は、所定時間の経過後に削除される、請求項１４に記載のコンピュータ可読媒体。
20. 前記マッピングが前記KMSの中間層によって実装され、前記中間層は１つ以上のマイクロサービスによって実装される、請求項１４に記載のコンピュータ可読媒体。

Images