Alibaba Cloud Key Management Service (KMS) 1.0 を使用している場合、パフォーマンスとユーザーエクスペリエンスを向上させるために、リソースを同じリージョン内の KMS 3.0 ソフトウェアキー管理インスタンスまたはハードウェアキー管理インスタンスに移行できます。移行後、キーと認証情報は KMS インスタンスに保存されます。キーはリージョン内で一意であり、認証情報はそのリージョン内の Alibaba Cloud アカウントと KMS インスタンス内で一意です。このトピックでは、KMS 1.0 から KMS 3.0 インスタンスにリソースを移行する方法について説明します。
移行する理由
より良いプロダクトエクスペリエンスを提供するため、Alibaba Cloud は 2025 年 3 月 30 日 00:00:00 (GMT+8) から KMS 1.0 のサポートと修正の終了 (EOSF) フェーズを開始する予定です。その後、KMS 1.0 は 2025 年 9 月 30 日 00:00:00 (GMT+8) にサポート終了 (EOS) フェーズに入ります。ビジネスの中断を防ぐため、KMS 1.0 リソースをできるだけ早く KMS 3.0 インスタンスに移行してください。KMS 3.0 インスタンスに移行すると、次の利点があります。
移行の影響
ビジネスへの影響
移行は、ビジネスの以下の側面に影響します。
サービスの可用性: KMS の移行では、コントロールプレーン操作とデータプレーン操作が分離されます。移行プロセス自体は、ビジネス運用に影響しません。認証情報の呼び出し、クラウドプロダクトの暗号化、およびアプリケーションの暗号化は通常どおり機能し続けます。
重要移行のタイムウィンドウ中、キー、認証情報、または KMS インスタンスに対してコントロールプレーン操作を実行することはできません。これらの操作には、リソースの作成、変更、または削除が含まれます。この制限により、データ整合性の問題による移行の失敗が防止されます。移行はオフピーク時間に実行することをお勧めします。
Terraform の互換性: Terraform を使用して KMS を管理している場合、移行後にリソースにインスタンス ID プロパティが追加されます。後続のコントロールプレーン操作を実行する際にリソースがリリースされるのを防ぐため、移行完了後に Terraform の構成を変更する必要があります。詳細については、「移行後の Terraform シナリオでの構成の変更」をご参照ください。
移行は、ビジネスの以下の側面には影響しません。
SDK の互換性: 移行後、カスタムアプリケーションは、コードやアプリケーションに変更を加えることなく、既存のソフトウェア開発キット (SDK) を引き続き使用できます。ビジネスの暗号化と復号に Function Compute などの他のプロダクトの SDK を使用している場合、それらの SDK を変更する必要はありません。これにより、効率的でスムーズ、かつシームレスな移行が保証されます。
パフォーマンスへの影響: 移行前にパブリックネットワーク経由でキーと認証情報にアクセスしていた場合、移行後も既存の SDK を引き続き使用できます。パフォーマンスは変わりません。パフォーマンスを向上させるには、パブリックネットワークアクセスから VPC アクセスに切り替えることができます。切り替え後、パフォーマンスはインスタンスタイプによって異なります。
アクセスコントロールポリシー: 移行後も、既存のアクセスコントロールポリシーを変更することなく引き続き使用できます。
その他の影響:
移行後、対称キーと非対称キーのバージョン ID が変更されます。カスタムアプリケーションにキーバージョン ID に基づく検証ロジックがある場合は、移行前にこのロジックを評価して削除する必要があります。そうしないと、キーバージョン ID の変更により、アプリケーションの検証が失敗します。
説明OpenAPI を使用している場合、古いキーバージョン ID で行われた呼び出しは移行後も成功します。ビジネスコードを変更する必要はありません。
コストへの影響
KMS 3.0 インスタンスの課金ロジックは KMS 1.0 とは異なります。移行する前に、KMS 3.0 インスタンスに関連するコストを理解しておく必要があります。詳細については、「サブスクリプション課金」および「従量課金」をご参照ください。
キー移行に関する注意事項
KMS は、カスタマーマスターキー (CMK) のメタデータとキーマテリアルを移行します。メタデータには、キー ID、キーステータス、削除保護、エイリアス、タグが含まれます。このデータは移行後も変更されません。
サービスキー
サービスキーを移行する必要はありません。通常どおり使用し続けることができます。ログイン後、新しいコンソールでサービスキーを表示できます。サービスキーは、サーバー側の暗号化を構成するときにクラウドプロダクトによって自動的に作成されます。そのエイリアスは alias/acs/<CloudProduct> の形式です。
カスタマーマスターキー
有効化 状態のキーのみが移行可能です。Disabled や Schedule Deletion などの他の状態のキーは移行できません。
保護レベル: ソフトウェア
次の表に、移行可能なインスタンスタイプを示します。
重要Bring Your Own Key (BYOK): 移行はサポートされています。KMS はキーマテリアルを直接移行します。手動でアップロードする必要はありません。
マルチバージョンキー: 移行はサポートされています。KMS はすべてのキーバージョンを移行します。
キーで自動ローテーションが有効になっている場合、バージョンの一貫性を確保するために移行前に手動で無効にする必要があります。詳細については、「キーの自動ローテーション」をご参照ください。
ハードウェアキー管理インスタンスでは、キーはデータベースまたは HSM に保存できます。ハードウェアキー管理インスタンスに移行されたキーは、データベースに保存されたキーがローテーションをサポートするため、デフォルトでデータベースに保存されます。この設定は変更できません。
移行するキー仕様
ソフトウェアキー管理インスタンス
ハードウェアキー管理インスタンス
Aliyun_AES_256 (単一バージョン)
√
√
Aliyun_AES_256 (マルチバージョン)
√
√
RSA_2048 (単一バージョン)
√
×
EC_P256 (単一バージョン)
√
×
EC_P256K (単一バージョン)
√
×
保護レベル: HSM
重要中国本土のキーのみが移行可能です。中国本土以外のキーは移行できません。移行できないキーがある場合は、お問い合わせください。
BYOK: 移行はサポートされていません。
マルチバージョンキー: 一部のキータイプで移行がサポートされています。KMS はすべてのキーバージョンを移行します。
キーで自動ローテーションが有効になっている場合、バージョンの一貫性を確保するために移行前に手動で無効にする必要があります。詳細については、「キーの自動ローテーション」をご参照ください。
ハードウェアキー管理インスタンスでは、キーはデータベースまたは HSM に保存できます。ハードウェアキー管理インスタンスに移行されたキーは、データベースに保存されたキーがローテーションをサポートするため、デフォルトでデータベースに保存されます。この設定は変更できません。
次の表に、移行可能なインスタンスタイプを示します。
移行するキー仕様
ソフトウェアキー管理インスタンス
ハードウェアキー管理インスタンス
Aliyun_AES_256 (単一バージョン)
√
√
Aliyun_AES_256 (マルチバージョン)
√
√
Aliyun_SM4 (単一バージョン)
×
√
Aliyun_SM4 (マルチバージョン)
×
√
RSA_2048 (単一バージョン)
√
√
EC_P256 (単一バージョン)
√
√
EC_P256K (単一バージョン)
√
√
RSA_3072 (単一バージョン)
√
√
EC_SM2 (単一バージョン)
×
√
認証情報移行に関する注意事項
すべてのタイプの認証情報が移行可能です。
KMS 3.0 では、認証情報は単一リージョン内の Alibaba Cloud アカウントと KMS インスタンス内で一意である必要があります。KMS 1.0 で複数の認証情報が同じ名前を持つ場合、または移行先の KMS 3.0 インスタンスに同じ名前の認証情報が既に存在する場合、移行はサポートされません。
KMS は、認証情報のメタデータとすべてのバージョンを移行します。メタデータには、認証情報名、ステータス、タグが含まれます。このデータは移行後も変更されません。
自動ローテーションが有効になっている認証情報は移行できます。バージョンの一貫性を確保するために、移行前に自動ローテーションを手動で無効にする必要があります。
認証情報を移行する際には、それを暗号化するマスターキーも移行する必要があります。
システム管理キーで暗号化された認証情報は移行できます。ただし、移行後、これらの認証情報ではデータバックアップ機能はサポートされません。データバックアップ機能の詳細については、「ディザスタリカバリ管理」をご参照ください。
移行するリソースをすばやく確認する
このメソッドは、移行可能なキーのみを表示します。移行できないキーについては、移行後にレガシーコンソールで残りのキーを表示し、Alibaba Cloud テクニカルサポートに連絡して支援を求めることができます。
レガシー Key Management Service コンソールにログインします。左側のナビゲーションウィンドウで、[移行ツール] をクリックします。
[移行] ボタンが利用可能な場合、現在のリージョンに移行するキーまたは認証情報があることを示します。
重要データはリージョンごとに表示されます。リソースを見落とさないように、すべてのリージョンのデータを確認してください。
[未移行のキー]、[移行済みのキー]、[未移行の認証情報]、および [移行済みの認証情報] 列の数字をクリックして、特定のキー ID と認証情報名を表示します。
適切な KMS 3.0 インスタンスの選択
適切な KMS 3.0 インスタンスを選択するために、以下の側面を評価します。
ビジネスニーズの評価: キーを移行できるインスタンスタイプに基づいて、適切な KMS インスタンスを選択します。
パフォーマンスニーズの評価: ビジネスにおけるデータ暗号化および復号操作の頻度を考慮します。たとえば、ビジネスが毎日多くの注文を処理する高トラフィックの E コマースプラットフォームである場合、ユーザーの支払い情報 (銀行カード番号や支払いパスワードなど) や注文データを暗号化する必要があります。高い QPS を持つ KMS インスタンスが必要になる場合があります。この場合、2,000 または 4,000 QPS をサポートする KMS インスタンスを選択して、暗号化および復号操作が迅速に完了し、トランザクションの遅延や失敗を回避できるようにします。
コンプライアンスニーズの評価: ビジネスが FIPS 認証に準拠する必要がある場合、ハードウェアキー管理インスタンスを購入する必要があります。
コスト予算の評価: KMS インスタンスは、サブスクリプションと従量課金の 2 つの課金方法を提供します。従量課金方法は、ビジネスがクラウドプロダクトの暗号化のためだけに KMS を使用する場合にのみ推奨されます。他のすべてのシナリオでは、サブスクリプションインスタンスの使用をお勧めします。