Amazon Web Services ブログ

AWS CloudHSM: hsm1.medium から hsm2m.medium への移行ガイド

本ブログは 2025 年 5 月 9 日に公開された Blog “How to manage migration of hsm1.medium CloudHSM clusters to hsm2m.medium” を翻訳したものです。

2024 年 8 月 20 日、AWS はAWS CloudHSM の新しいインスタンスタイプ hsm2m.medium (hsm2) の一般提供を発表しました。この新しいタイプは、以前の AWS CloudHSM インスタンスタイプ hsm1.medium (hsm1) と比較して、アメリカの連邦情報処理標準 (FIPS) 140-3 レベル 3 のサポート、非 FIPS モードでのクラスター実行機能、合計 16,666 キーのストレージ容量の増加、クライアントと CloudHSM 間の相互 TLS 認証 (mTLS) のサポートなどの追加機能を備えています。

hsm1 インスタンスタイプはサポート終了に近づいており、2025 年 12 月 1 日以降はサービスを利用できなくなります。hsm1 の廃止通知をご確認ください。

これに対応するため、2025 年 4 月から AWS は既存の hsm1 クラスターを hsm2 への自動的な移行を開始します。移行中、hsm1 クラスターは書き込み制限モードで動作します。

自動移行を利用し、移行中の処理制限に対応できる場合は、環境が自動移行の前提条件を満たしていることを確認してください。

移行をご自身で管理したい場合は、自動移行が始まる前に実施することができます。この記事では、状況と利用可能なリソースに最適な方法を選択できるよう、いくつかの移行オプションを紹介します。

移行中の高可用性を確保するために、ブルー/グリーンデプロイ戦略を使用できます。高可用性が優先事項でない場合は、書き込み処理が制限される方法と、処理にダウンタイムが発生する方法の 2 つのアプローチがあります。また、移行中に実行される処理に基づいたさまざまなユースケースとロールバック戦略についても説明します。

重要な考慮事項

hsm2 への移行を計画する際は、以下の点を考慮してください：

  • バックアップ: 必要なすべてのキーが hsm2 に移行されたことを確認するまで、hsm1 のバックアップを保持することをお勧めします。CloudHSM バックアップ保持ポリシーを設定してバックアップを管理できます。

    注意: CloudHSM はクラスターの最後のバックアップを削除しません。詳細については、AWS CloudHSM バックアップ保持ポリシーの設定をご覧ください。また、共有バックアップの操作で説明されているように、CloudHSM バックアップを他の AWS アカウントと共有することもできます。

  • 可用性とロールバック: この記事では主に 2 つの移行アプローチを紹介します。1 つは可用性を維持しますが、移行期間中に使用されるキーのタイプと AWS CloudHSM で実行される処理によっては複雑になる可能性があります。もう 1 つのアプローチはより単純ですが、短時間の可用性への影響が生じる可能性があります。可用性要件に基づいて移行プロセスを選択してください。
  • ブルー/グリーン戦略: 企業固有の方法または CloudHSM マルチクラスター構成を使用して、ブルー/グリーンデプロイ戦略を実装できます。

    注意: マルチクラスター構成は CloudHSM CLI、JCE、PKCS11 でサポートされています。

  • クライアント SDK バージョン: インスタンスタイプ hsm2 は、クライアント SDK バージョン 5.9.0 以降とのみ互換性があります。移行を開始する前にクライアント SDK をアップグレードしてください。最新バージョンの使用をお勧めします。
  • 非推奨アルゴリズム: 非推奨アルゴリズムを使用していないことを確認してください。非推奨アルゴリズムを使用している場合、バックアップを使用して hsm2 クラスターに移行することはできません。3DES を使用している場合は、hsm2 非 FIPS クラスターでのみ引き続き使用できます。Blog 「AWS CloudHSM: FIPS モードから非 FIPS モードへの 3DES キー移行ガイド」をご覧ください。
  • 既知の問題: 移行後のテストとメトリクスを必要に応じて修正するために、hsm2 の既知の問題をご確認ください。

限定的な可用性

2 つのオプションがあります。お客様主導型とお客様管理型です。要件に最も適したアプローチを選択してください。どちらのオプションでも、移行基準を満たす必要があることに注意してください。hsm2m.medium への移行の前提条件をご覧ください。

お客様主導型

お客様が、AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (AWS CLI) から hsm1 クラスターの移行を開始することができ、AWS が移行プロセスを管理します。hsm1.medium から hsm2m.medium への移行の詳細な手順に従ってください。このアプローチは、ユーザーやキーの作成や削除などの書き込み処理を頻繁に実行しない場合に適しています。移行中、hsm1 クラスターは制限付き書き込みモードになり、移行が完了するまで書き込み処理は拒否されます。アプリケーションによる書き込み処理がある場合、移行中はそれらが失敗します。読み取り処理は影響を受けません。ロールバックが必要な場合は、AWS によって管理されます。必要に応じて、移行開始から 24 時間以内にロールバックすることができます。お客様主導型の移行プロセスは、設定変更が不要なため簡単です。移行中に書き込み処理が必要な場合は、お客様管理型オプションを選択することができます。

お客様管理型

このアプローチは、移行を実行するために短時間のダウンタイムをスケジュールできる場合に適しています。このプロセスでは、最新の hsm1 バックアップを使用して新しい hsm2 クラスターを作成します。hsm2 クラスターに hsm1 クラスターと同じ数の HSM を追加した後、アプリケーションを停止し、CloudHSM クライアントライブラリを hsm2 用に再設定して、アプリケーションを再起動します。

  • バックアップから hsm2 クラスターを作成する: CloudHSM は少なくとも 24 時間ごとにクラスターの定期的なバックアップを作成します。より最新のバックアップが必要な場合は、AWS CloudHSM でのクラスターバックアップの手順に従ってバックアップを開始してください。クラスター作成時にバックアップ保持ポリシーを作成した場合、そのポリシーによってバックアップが削除されるまでの保持期間が決まります。デフォルトは 90 日です。

    バックアップを特定したら、CloudHSM コンソールまたは AWS CLI からhsm2 クラスターを作成します。コンソールの場合、HSM タイプとして hsm2m.medium を選択し、クラスターソースとして既存のバックアップからクラスターを復元を選択し、hsm1 の指定されたバックアップを選択します。

  • 高可用性のためのクラスターの更新: 新しい hsm2 クラスターには 1 つの HSM インスタンスしかありません。ここで hsm1 と同じ数のインスタンスをこのクラスターに追加できます。CloudHSM クラスターへの HSM の追加を参照してください。ワークロードに基づいて、高可用性を確保するためにクラスターにさらに HSM を追加します。これは、クラスターがベストプラクティスに従っていることを確認するのに良い機会です。
  • クライアント SDK の再設定: メンテナンスウィンドウ中に、CloudHSM クライアント SDK と統合されているアプリケーションを停止し、適切なクライアント SDK を新しい hsm2 クラスターと通信するように再設定してから、アプリケーションを再起動します。SDK を再設定するには、クライアント SDK のブートストラップを参照してください。既存のアプリケーションを停止して再設定する代わりに、hsm2 と通信するように CloudHSM クライアントを設定した新しいアプリケーションインスタンスを起動し、古いアプリケーションインスタンスを廃止する方法もあります。
  • アプリケーションの監視: アプリケーションの健全性メトリクスとログを監視して、新しい hsm2 クラスターに対する処理が成功していることを確認します。エラーが増加した場合は、hsm1 クラスターにロールバックし、AWS サポートに支援を求めることができます。
  • ロールバック: hsm2 クラスターと通信するようにアプリケーションを設定したのと同様に、hsm1 クラスターと通信するようにアプリケーションを再設定することでロールバックできます。
  • hsm1 クラスターの削除: 新しい hsm2 クラスターに満足したら、コスト削減のために hsm1 クラスターを削除できます。この操作によりバックアップが作成され保持されます。(CloudHSM はクラスターの最後のバックアップを削除しません。)

高可用性

移行中に CloudHSM クラスターの高可用性が必要な場合、AWS はブルー/グリーンデプロイ方法論に従うことをお勧めします。ブルー/グリーンデプロイの基本的な考え方は、異なるバージョンのサービスやアプリケーションを実行している 2 つの同一環境間でトラフィックを切り替えることです。ブルー環境は本番トラフィックを処理している現在のバージョンのクラスターを表します (hsm1)。グリーン環境はサービスの異なるバージョンのクラスターを実行し、並行してステージングされます (hsm2)。グリーン環境の準備とテストが完了したら、本番トラフィックをブルーからグリーンにリダイレクトします。問題が特定された場合は、トラフィックをブルー環境に戻すことでロールバックできます。

この記事では、2 つのブルー/グリーンアプローチについて説明します。アプローチ 1 では、ロードバランサーを使用してブルー構成とグリーン構成間のトラフィックをルーティングします。アプローチ 2 では、CloudHSM のマルチクラスター構成を使用し、アプリケーションコードの変更が必要です。それぞれに労力とコストの面で長所と短所があります。

アプリケーションにすでにマルチクラスター構成を実装している場合は、アプローチ 2 に従うことができます。そうでない場合は、アプローチ 1 をお勧めします。

これらのアプローチのいずれかを実装する際に覚えておくべき重要なことがいくつかあります。

  • お客様管理型で説明したように、hsm1 バックアップから hsm2 クラスターを作成する必要があります。
  • 移行中に書き込み処理をサポートする必要がある場合は、ブルークラスターとグリーンクラスター間でデータが同期していることを確認するための追加プロセスを実行する必要があります。さまざまなシナリオについて学び、それに応じて計画するには、ユースケースを参照してください。

アプローチ 1

このアプローチでは、2つの別々だが同一のクライアント環境を作成します。一方の環境（ブルー）は現在のアプリケーションと hsm1 クラスターに接続するクライアント SDK を実行します。もう一方の環境（グリーン）は同じアプリケーションを実行しますが、クライアント SDK は hsm2 クラスターと通信するように構成されています。その後、Application Load Balancer (ALB) などのロードバランサーを使用して、ALB の重み付けターゲットグループルーティング機能またはロードバランサーの同等の機能を使用して、ブルーとグリーン間でトラフィックを選択的にルーティングします。

最初はアプリケーショントラフィックの小さな割合をグリーンに向けることから始めることができます。グリーンが良好に動作し安定していることが確認できたら、トラフィックをグリーンに移行し、ブルーをシャットダウンします。

Figure 1: Blue/green migration architecture

図 1: ブルー/グリーン移行アーキテクチャ

図 1 に示す移行アーキテクチャの手順は次のとおりです：

  1. お客様管理型で説明したように、hsm1 バックアップから hsm2 クラスターを作成します。新しいクラスターを既存の CloudHSM クラスターと同じアベイラビリティーゾーンに作成してください。これがグリーン環境になります。
  2. グリーン環境に新しいアプリケーションインスタンスを起動し、新しい hsm2 クラスターに接続するように構成します。
  3. 新しいクライアントインスタンスを ALB の新しいターゲットグループに追加します。
  4. 次に、ALB の重み付けターゲットグループルーティング機能を使用して、新しく構成された環境にトラフィックをルーティングします。
    1. 各ターゲットグループの重みは 0 から 999 までの値です。重み付けターゲットグループを持つリスナールールに一致するリクエストは、これらのターゲットグループに重みに基づいて分散されます。
    2. 詳細については、Application Load Balancer でのブルー/グリーンデプロイのファインチューニングを参照してください。

カナリアデプロイパターンに従って、hsm2 クラスター統合アプリケーションを広く利用可能にする前に、ユーザーのサブセットにロールアウトすることができます。その間、hsm1 統合アプリケーションはほとんどのユーザーにサービスを提供します。最初に、ブルーターゲットグループの重みを 90、グリーンを 10 に設定すると、ALB はトラフィックの 90% をブルーターゲットグループに、10% をグリーンにルーティングします。

グリーンへの処理が成功していることを確認するためにアプリケーションをモニタリングします（モニタリングを参照）。グリーンからのレスポンスに満足したら、ブルーとグリーンの重みを 0 と 100 に更新して完全にグリーンに切り替え、その後ブルーをシャットダウンできます。

DNS 重み付け分散などの代替アプローチについては、AWS でのブルー/グリーンデプロイを参照してください

アプローチ 2

このアプローチでは、hsm1 と hsm2 の両方のクラスターと通信する単一のアプリケーション環境を使用します。ブルー環境とグリーン環境間でトラフィックを移行するために、CloudHSM のマルチクラスター構成を使用します。これにより、単一のクライアント SDK が 2 つ以上の CloudHSM クラスターと通信できるようになります。アプリケーションコードは、ブルークラスターとグリーンクラスターの両方と通信するように変更する必要があります。この記事では、以下の図 2 に示す JCE SDK マルチクラスター構成を使用します。

Figure 2: Multi-cluster migration architecture

図 2: マルチクラスター移行アーキテクチャ

このソリューションは、マルチクラスター構成を使用した基本的なブルー/グリーンデプロイ手順を使用し、移行中に実行される CloudHSM での処理のタイプに基づく一般的なユースケース向けに設計されています。また、ブルークラスターとグリーンクラスター間でキーを同期する方法とロールバックする方法についても説明します。

hsm1 バックアップから hsm2 クラスターを作成する

お客様管理型で説明したように、hsm1 バックアップから hsm2 クラスターを作成します。新しいクラスターを既存の CloudHSM クラスターと同じアベイラビリティーゾーンに作成してください。これがグリーン環境になります。

ブルーとグリーンの両方と通信するようにアプリケーションを変更する

このステップでは、マルチクラスター構成を使用してブルーとグリーンの両方と通信するようにアプリケーションを変更します。マルチクラスター構成を使用する場合、デフォルトの設定ファイルを使用する代わりに、コード内で CloudHSM プロバイダーを構成する必要があります。

アプリケーションコードで、2 つのプロバイダーをインスタンス化します。providerHsm1 はブルークラスターを指し、providerHsm2 はグリーンクラスターを指します。次に、これらのプロバイダーを使用してブルーとグリーン間でトラフィックを切り替えるようにビジネスロジックを更新します。

  • 以下の例のようにプロバイダーをインスタンス化します。詳細な説明は CloudHSM CLI を使用した複数のクラスターへの接続 を参照してください。以下を置き換えてください。
    • <hsmCAFilePath>: クラスターを 初期化 するために使用した hsm1 トラストアンカー証明書のファイルパス
    • <hsm1ClusterID>: hsm1 クラスターの一意のクラスター ID
    • <hsm2ClusterID>: hsm2 クラスターの一意のクラスター ID
    CloudHsmProviderConfig hsm1Config = CloudHsmProviderConfig.builder() 
.withCluster( 
CloudHsmCluster.builder() 
.withHsmCAFilePath(<hsmCAFilePath>)
.withClusterUniqueIdentifier("<hsm1ClusterID>")
.withServer(CloudHsmServer.builder().withHostIP(hsm1HostName).build()) 
.build()) 
.build();
CloudHsmProvider providerHsm1 = new CloudHsmProvider(hsm1Config);

   if (Security.getProvider(provider1.getName()) == null) {.  
                 Security.addProvider(provider1);
     }

CloudHsmProviderConfig hsm2Config = CloudHsmProviderConfig.builder() 
.withCluster( 
CloudHsmCluster.builder() 
.withHsmCAFilePath(<hsmCAFilePath>)
.withClusterUniqueIdentifier("<sm2ClusterID>")
.withServer(CloudHsmServer.builder().withHostIP(hsm2HostName).build()) 
.build()) 
.build();

CloudHsmProvider providerHsm2 = new CloudHsmProvider(hsm2Config);

if (Security.getProvider(provider2.getName()) == null) { 
              Security.addProvider(provider2);
}
  • それぞれのプロバイダーを使用してブルーとグリーンに処理を振り分けます。 
    Cipher cipher1 = Cipher.getInstance("AES/GCM/NoPadding", providerHsm1);

Cipher cipher2 = Cipher.getInstance("AES/GCM/NoPadding", providerHsm2);

グリーンに切り替えてブルーをシャットダウンする

アプリケーションをモニタリングして、グリーンでの処理が成功していることを確認します。モニタリングセクションを参照してください。グリーンからのレスポンスに満足したら、アプリケーションコードを更新して完全にグリーンに切り替えることができます。

モニタリング

hsm2 への移行中は、アプリケーションが期待通りに動作していることを確認し、エラーが増加した場合にロールバックできるようにアプリケーションをモニタリングすることが重要です。アプリケーションログと CloudHSM クライアント SDK ログを使用してアプリケーションをモニタリングできます。

注意： hsm2 には今後のリリースで修正される既知の問題がいくつかあります。現在の既知の問題とその解決状況のリストについては、AWS CloudHSM hsm2m.medium インスタンスの既知の問題を参照してください。

ユースケース

移行中に CloudHSM クラスターで実行する処理のタイプに応じて、ブルークラスターとグリーンクラスター間でデータが同期されていることを確認するために追加のプロセスを実行する必要があります。これにより、移行中に書き込み処理が実行された場合に、ブルーとグリーンのクラスターが不整合状態になるスプリットブレインシナリオを回避できます。

読み取り専用処理

移行中に読み取り処理のみを実行する必要がある場合（つまり、トークンキーを作成しない場合）、クラスター間のデータは一貫性が保たれます。アプローチ 1 またはアプローチ 2 のブルー/グリーンデプロイ方法に従って、完全にグリーンに切り替えることができます。

作成/削除処理

移行中にトークンキーを作成する必要がある場合、クラスターへの読み取り処理が成功することを確認するために、ブルークラスターとグリーンクラスターを同期する必要があります。

  • ブルーへの書き込み: 最初は、作成処理をブルーに向け、読み取り処理をブルーとグリーンの両方に向けることができます。この場合、新しく作成されたキーをグリーンに複製する必要があります。CloudHSM CLI の key replicate コマンドを使用してキーを同期できます。キーの複製を参照してください。
  • グリーンへの書き込み: グリーンクラスターの読み取り機能に自信を持った後、アプリケーションをグリーンクラスターに対する書き込み処理に切り替え始めることができます。この場合、まだブルーとグリーンの両方から読み取っている場合は、CloudHSM CLI の replicate コマンドを使用してキーをブルーに複製できます。キーの複製を参照してください。

キーの複製

同じバックアップから作成された CloudHSM クラスター間でキーを複製するには、マルチクラスター構成を使用した CloudHSM CLI を使用します。

ステップ 1: マルチクラスターの構成

マルチクラスター構成にブルークラスターとグリーンクラスターを追加します。CloudHSM CLI を使用した複数のクラスターへの接続を参照してください。

ステップ 2: ソースから宛先へのキーの複製

キーの所有者とキーが共有されているユーザーが宛先に存在することを確認してください。また、処理を実行する 暗号ユーザー (Crypto User, CU) または管理者は、両方のクラスターにサインインする必要があります。

以下の例のように、key replicate コマンドを実行して、ブルーからグリーンへ、またはその逆にキーを複製します。

  • hsm1 のキーを一覧表示: 
    crypto_user@cluster-<hsm1ClusterID> > key list --cluster-id cluster-<hsm1ClusterID>
  • hsm2 のキーを一覧表示: 
    crypto-user@cluster-<hsm1ClusterID> > key list --cluster-id cluster-<hsm2ClusterID>
  • キーの複製: 
    crypto_user@cluster-<hsm1ClusterID> > key replicate \
--filter attr.label=example-aes-2 \
--source-cluster-id cluster-<hsm1ClusterID> \
--destination-cluster-id cluster-<hsm2ClusterID>

ロールバック

ロールバックの複雑さは、移行の段階と作成されたキーによって異なります。通常、移行中であっても移行後であっても、新しいキー属性などの hsm2 固有の機能を使用していなければ、ロールバックは簡単です。移行中にロールバックが必要な場合は、アプリケーションを hsm1 クラスターに戻すことができます。このアプローチにより、読み取りと書き込みは hsm1 だけで行われるようになり、ロールバックが完了します。hsm2 でのみキーを作成した場合は、それらを hsm1 に複製し直すことができます。

もう一つのロールバックシナリオは、キーを hsm1 クラスターに複製し直せない場合です。これは、アプリケーションを完全に hsm2 に移行し、3,300 個以上のキー（hsm1 の制限）を作成した場合や、hsm2 固有の機能を使用している場合に発生する可能性があります。このシナリオでは、アプリケーションを変更して、読み取り処理は hsm1 と hsm2 の両方のクラスターに対して行い（キーが hsm2 にのみ存在する場合があるため）、書き込み処理は hsm1 でのみ行うマルチクラスター設定に戻す必要があります。この場合、両方のクラスターと通信を続け、複製できないキーが不要になり、クラスターを縮小できるようになるまで同期を維持することをお勧めします。

まとめ

この記事では、AWS CloudHSM クラスターの hsm1.medium を hsm2m.medium に移行するための戦略について説明しました。一般的に使用されるブルー/グリーンデプロイと AWS CloudHSM が提供するオプションについて検討しました。また、一般的なユースケース、よくある落とし穴を避けるための手順、およびロールバックオプションについても説明しました。

この記事に関する質問がある場合は、AWS サポートにお問い合わせください。

Roshith Alankandy

Roshith は、オーストラリアを拠点とする AWS のセキュリティコンサルタントです。セキュリティ、リスク、コンプライアンスのガイダンスを提供し、お客様のクラウド導入を加速させるお手伝いをしており、暗号化を専門としています。仕事以外では、家族と過ごしたり、サッカーをしたりすることを楽しんでいます。

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。