このトピックでは、KMSで CMK (Customer Master Key) の自動ローテーションを使用する方法について説明します。

キーバージョン

CMK では、複数のキーバージョンがサポートされます。 各キーバージョンは、独立して生成されたキーを指します。 複数のキーバージョン間に依存関係はありません。 KMS は、新しいキーバージョンを生成することにより、CMK を自動的にローテーションします。

キーバージョンには 2 つのタイプがあります。
  • プライマリキーバージョン
    • CMK のプライマリキーバージョンとは、有効な暗号化キーを指します。 各 CMK のプライマリキーバージョンは、常に 1 つだけ存在します。
    • GenerateDataKey や Encrypt のような API を呼び出す際 、KMS は指定された CMK のプライマリキーバージョンを使用して、対象ののプレーンテキストを暗号化します。
    • PrimaryKeyVersion 属性を確認するには、 DescribeKey API を呼び出します。
  • 非プライマリキーバージョン
    • CMKの非プライマリキーバージョンとは、有効化されていない暗号化キーを指します。 各 CMKは、任意の数の非プライマリキーバージョンを持つことができます。
    • それぞれの非プライマリキーバージョンは、以前はプライマリキーバージョンであり、有効な暗号化キーとして機能するために使用されていました。
    • 新しいプライマリキーバージョンが作成されても、KMS はデータを解読するために使用できる非プライマリキーバージョンを削除または無効化しません。
注 Encrypt API を呼び出すと、指定された CMK の主キーバージョンが使用されます。 Decrypt API を呼び出すと、暗号文の暗号化に使用されたキーバージョンが選択されます。
キーバージョンは、次のいずれかの方法で生成できます。
  • CMK を作成する

    CMK を作成するには、CreateKey API を呼び出します。 [オリジン] パラメーターを Aliyun_KMS に設定すると 、KMS は最初のキーバージョンを生成して主キーバージョンとして設定します。

  • 自動ローテーションポリシーを実行する

    自動ローテーションポリシーを設定すると、KMS はポリシーを定期的に実行して新しいキーバージョンを生成します。

自動キーローテーション

キーローテーションポリシーを設定する

CMK を作成する CreateKey API の呼び出し時に、CMKの自動ローテーションポリシーを指定できます。 現在適用されている自動ローテーションポリシーを更新するには、 UpdateRotationPolicy API を呼び出します。 UpdateRotationPolicy API の呼び出し時に、次のパラメーターを設定する必要があります。
  • EnableAutomaticRotation ：自動ローテーションを有効にするかどうかを指定します。
  • RotationInterval ：自動ローテーションの期間を指定します。
自動ローテーションポリシー情報を表示するには、 DescribeKey API を呼び出します。 以下のポリシー関連パラメーターが表示されます。
  • AutomaticRotation：自動ローテーションが有効かどうかを示します。 無効の場合、自動ローテーションが有効になっていないことを示します。 有効の場合、自動ローテーションが有効であることを示します。 停止中の場合、自動ローテーションは有効になっていますが、停止されていることを示します。 詳細については、「CMK ステータスが自動ローテーションに与える影響」をご参照ください。
  • RotationInterval ：自動ローテーションの期間を示します。

自動ローテーションポリシーの実行

自動ローテーションが有効になっている場合、KMS は次の式を使用して次のローテーション時刻を計算します。 
${NextRotationTime} = ${LastRotationTime} + ${RotationInterval}
パラメーターは以下ののとおりです。
  • LastRotationTime ：最後のキーバージョンが作成された時刻を指定します。 LastRotationDate のパラメーターの値を確認するには、DescribeKey API を呼び出します。
  • NextRotationTime ：KMS が次のローテーションタスクを実行して新しいキーバージョンを作成する時刻を指定します。 NextRotationDate パラメーターの値を確認するには、DescribeKey API を呼び出します。
重要 自動ローテーションポリシーの RotationInterval パラメーターを更新すると、NextRotationTime の計算値が過去の時刻になる場合があります。 その場合でも、自動ローテーションポリシーの実行には影響しません。 KMS は、スケジュールに従って新しいキーバージョンを作成します。 NextRotationTimeの計算値が現在の時刻より前の場合、KMS は直ちに自動ローテーションポリシーを実行します。

CMK ステータスが自動ローテーションに与える影響

新しいキーバージョンを作成できるのは、CMK のステータスが有効 ( KeyState パラメーターが有効) な場合のみです。 以下の点に注意する必要があります。
  • CMK のステータスが無効または削除待ちの場合は、自動ローテーションポリシーを更新するAPI UpdateRotationPolicy を呼び出さないでください。
  • 自動ローテーションの有効化後に CMK のステータスが無効または 削除待ち になった場合、KMS は自動ローテーションの実行を一時停止します。 DescribeKey API を呼び出すと、 自動ローテーションパラメーターは停止中と表示されます 。 CMK のステータスが有効になると、自動ローテーションポリシーは再び有効になります。

制限事項

次のキーは、複数のキーバージョンをサポートしていません。
  • サービス管理キー：特定のクラウドサービス用に KMS によって管理されるデフォルトキー。 これらのキーは、特定のクラウドサービスのユーザーに属し、ユーザーデータの基本的な暗号化保護を提供するために使用されます。
  • Bring Your Own Keys (BYOK)：KMSにインポートしたキー。 詳細については、「キーマテリアルのインポート」をご参照ください. インポートしたキーのオリジンパラメーターの値が外部の場合、KMS はキーマテリアルを生成せず、キーのローテーションタスクを開始しません。

上記のキータイプは、バージョンベースのキーローテーションをサポートしていません。 KMS は複数の BYOK バージョンをサポートしていません。 まず、ユーザーは BYOK の永続性とライフサイクルを強力に制御できるため、管理が難しくなり、エラーが発生しやすくなります。 たとえば、オンプレミスのキー管理機能が必要であり、またオンプレミスとクラウド機能の間でデータを同期する必要があります。さらにキーマテリアルを削除する際に猶予期間は提供されません。 BYOK の複数のバージョンを維持することは複雑であるため、はるかにリスクが高くなります。 つぎに、プライマリキーと非プライマリキーの両方のバージョンが異なる時期に使用できなくなる場合があります。 たとえば、キーバージョンが KMS によって削除されたり、キーバージョンの有効期限が切れた際に再びインポートされたりすると、CMK と保護されたデータの同期や、システムの整合性の保証ができなくなります。