Key Management Service (KMS) のシークレットはリージョン固有のリソースです。あるリージョンに関する移行通知を受け取った場合、サービスの中断を避けるために、できるだけ早くシークレットを移行先リージョンに移行してください。移行方法はシークレットの種類によって異なります。
| シークレットの種類 | 移行の要否 | 方法 |
|---|---|---|
| 汎用シークレット (KMS インスタンス内) | はい | バックアップと復元を使用した移行 |
| 汎用シークレット (KMS インスタンス外) | はい | API を使用して移行先リージョンでシークレットを再作成 |
| RAM シークレット | 移行は非対応 — 削除して再作成 | 移行元リージョンで削除し、移行先リージョンで作成 |
| ApsaraDB RDS シークレット | いいえ | ApsaraDB RDS インスタンスはリージョン固有であり、シークレットは自動的に追従 |
| ECS シークレット | いいえ | Elastic Compute Service (ECS) インスタンスはリージョン固有であり、シークレットは自動的に追従 |
汎用シークレット
制限事項
移行中は、移行が完了し、移行元のシークレットを削除するまで、移行元のリージョンでシークレットに対する操作を実行しないでください。例えば、シークレットのメタデータの変更や、新しいシークレットバージョンの作成 (例:
PutSecretValueの呼び出し) を行わないでください。移行後、シークレットとそのバージョンの作成タイムスタンプは、移行元リージョンと移行先リージョンで異なります。これはサービスに影響しません。
KMS インスタンス内の汎用シークレットの移行
KMS インスタンス内に作成された汎用シークレットの場合は、バックアップと復元を使用して移行します。詳細については、「バックアップ」をご参照ください。
KMS インスタンス外の汎用シークレットの移行
旧バージョンの KMS では、KMS インスタンスを購入しなくても汎用シークレットを作成できました。このタイプのシークレットは「KMS インスタンス外」と見なされます。KMS 3.0 では、汎用シークレットを作成する前に KMS インスタンスを購入する必要があります。
以下の手順に従って、API 呼び出しを介して移行先リージョンでシークレットを再作成します。
ステップ 1:移行元リージョンでのシークレット詳細のクエリと保存
移行元リージョンで以下の API を呼び出し、シークレットの再作成に必要なすべての情報を取得します。
| API | 主要なパラメーター | 目的 |
|---|---|---|
DescribeSecret | FetchTags を true | シークレットのメタデータ (名前、種類、タグ、説明、拡張設定) を取得 |
ListSecretVersionIds | IncludeDeprecated を true | 非推奨のものを含むすべてのシークレットバージョンを取得 |
GetSecretValue | バージョンごとに 1 回呼び出し | 各バージョンのシークレット値と値の型を取得 |
ListSecretVersionIds の応答に含まれる VersionIds は作成時間順にソートされていません。続行する前に、ローカルでソートしてください。
例えば、ListSecretVersionIds が 3 つのバージョンを返した場合、それらを作成時間順にソートします。
| バージョン | 作成日時 | ステージ |
|---|---|---|
| v1 | 2023 年 1 月 1 日 | 001 (初期バージョン) |
| v2 | 2023 年 5 月 1 日 | ACSPrevious |
| v3 | 2023 年 11 月 1 日 | ACSCurrent |
ステップ 2:移行先リージョンへのアプリケーションの移行
ご利用のアプリケーションを移行先リージョンに移動します。
移行先リージョンでアプリケーションの認証情報を作成します。
Resource Access Management (RAM) ユーザーまたは RAM ロールの AccessKey ペアを使用する場合:移行先リージョンで RAM ユーザーまたは RAM ロールを作成し、
AliyunKMSSecretAdminAccessポリシーをアタッチします。詳細については、「RAM ユーザーの作成と権限付与」および「RAM ロールの作成とポリシーのアタッチ」をご参照ください。アプリケーションアクセスポイント (AAP) のクライアントキーを使用する場合:まず KMS インスタンスを購入し、次に移行先リージョンでクライアントキーを作成します。詳細については、「AAP の作成」をご参照ください。
ご利用のアプリケーションでエンドポイントと認証情報の設定を更新します。
KMS エンドポイントと KMS インスタンスのエンドポイントは異なります。使用する SDK に基づいてエンドポイントを設定してください。詳細については、「SDK リファレンス」をご参照ください。
ステップ 3:移行先リージョンでのシークレットの作成
移行先リージョンで KMS インスタンスを購入します。詳細については、「インスタンスの選択」および「KMS インスタンスの購入と有効化」をご参照ください。
KMS インスタンスでキーを作成し、シークレットを暗号化します。詳細については、「キー管理の概要」をご参照ください。
以下の API を呼び出して、同一のメタデータ、バージョン、値を持つシークレットを再作成します。
API 設定内容 CreateSecretDescribeSecretから取得した値をsecretName、secretType、Tags、Description、ExtendedConfigに使用します。VersionIdには、初期バージョン (この例では v1) を使用します。SecretDataとSecretDataTypeには、初期バージョンのGetSecretValueから取得した値を使用します。PutSecretValue残りの各バージョンを保存します。この例では、v2 と v3 に対してそれぞれ 1 回ずつ呼び出します。 UpdateSecretVersionStage各バージョンのステージを設定します。この例では、v1 → 001、v2 →ACSPrevious、v3 →ACSCurrentとなります。両方のリージョンで
DescribeSecretを呼び出し、シークレットに関する情報が同じであることを確認します。
ステップ 4:アプリケーションの検証
移行先リージョンでアプリケーションをテストし、シークレットにアクセスでき、期待どおりに動作することを確認します。
ステップ 5:移行元リージョンでのシークレットの削除
移行先リージョンでアプリケーションが正しく動作することを確認した後、移行元リージョンでシークレットを削除します。詳細については、「汎用シークレットの管理と使用」をご参照ください。
シークレットを削除する前に、ActionTrail を使用してシークレットへの最近の API 呼び出しを確認してください。シークレット関連のイベントには、GetSecretValue、DescribeSecret、ListSecretVersionIds、PutSecretValue、UpdateSecret、UpdateSecretVersionStage、UpdateSecretRotationPolicy、RestoreSecretが含まれます。詳細については、「ActionTrail を使用した KMS イベントのクエリ」および「KMS の監査イベント」をご参照ください。
RAM シークレット
移行はサポートされていません。1 つの RAM ユーザーは KMS 内に 1 つの RAM シークレットしか持つことができません。RAM シークレットを新しいリージョンに移動するには、移行元リージョンで削除し、移行先リージョンで新しく作成する必要があります。
KMS から RAM シークレットを削除する前に、そのシークレットが使用されていないことを確認してください。KMS から RAM シークレットを削除しても、関連付けられた AccessKey ペアは削除されません。
ApsaraDB RDS シークレット
移行は必要ありません。ApsaraDB RDS インスタンスはリージョン固有のリソースであるため、関連付けられたシークレットを個別に移行する必要はありません。
ECS シークレット
移行は必要ありません。Elastic Compute Service (ECS) インスタンスはリージョン固有のリソースであるため、関連付けられたシークレットを個別に移行する必要はありません。