概要前提条件クラスターの書き込み制限モード移行の開始移行のロールバックロールバック後のデータ同期

hsm1.medium から hsm2m.medium への移行

AWS CloudHSM クラスターを hsm1.medium から hsm2m.medium に移行できます。このトピックでは、前提条件、移行プロセス、ロールバック手順について説明します。

移行を開始する前に、アプリケーションが高可用性対応のクラスターをアーキテクチャーの推奨事項に従っていることを確認してください。これにより、プロセス中のダウンタイムを回避できます。

hsm1.medium から hsm2m.medium への移行プロセスの概要

移行は、AWS CloudHSM コンソール、AWS CLI、または AWS CloudHSM API のいずれからでも開始できます。どこから開始しても、AWS CloudHSM クラスターの移行は modify-cluster API エンドポイントを使用します。移行が開始されると、クラスター全体が書き込み制限モードになります。詳細については、クラスターの書き込み制限モードを参照してください。

影響を最小限に抑えるため、AWS CloudHSM は HSM を hsm1.medium から hsm2m.medium へ 1 台ずつ順次切り替えます。置き換え後の HSM は同じ IP アドレスを維持するため、移行中も移行後も設定変更は不要です。

移行は次の手順で実行されます。

最初の HSM を移行する前に、AWS CloudHSM はクラスター全体のフルバックアップを作成します。
このバックアップを使用して、AWS CloudHSM は最初の HSM を置き換えるために、要求されたタイプ (hsm2m.medium) の新しい HSM を作成します。
次の HSM を移行する前にも、AWS CloudHSM はクラスター全体の新しいフルバックアップを作成します。
AWS CloudHSM は、クラスター内のすべての HSM について、これら 3 と 4 の手順を繰り返し、HSM を 1 台ずつ順番に移行します。
各 HSM の移行には、約 30 分かかります。

AWS CloudHSM は、移行プロセス全体を通してクラスターのヘルスをモニタリングし、検証を実行します。エラーの増加が検出された場合、または検証チェックが失敗した場合、AWS CloudHSM は移行を自動的に停止し、クラスターを元の HSM タイプに戻します。移行開始後 24 時間以内であれば、手動でロールバックすることも可能です。ロールバックを実行する前に、HSM タイプのロールバックに関する考慮事項を参照してください。

hsm2m.medium に移行するための前提条件

既存の AWS CloudHSM クラスターが hsm2m.medium に移行するには、次の要件を満たしている必要があります。検証チェックのいずれかの条件を満たさない場合、AWS CloudHSM は自動的にクラスターを元の HSM タイプに戻します。

既知の移行に関する問題の一覧については、AWS CloudHSM クラスターの変更に関する既知の問題を参照してください。

過去 7 日間:
- すべてのクライアント接続で SDK 5.9 以降が使用されている。
  - ECDSA Verify を実行する場合、すべてのクライアント接続が SDK 5.13 以上を使用している。
- AWS CloudHSM インスタンスで、サポート対象の機能のみが使用されており、非推奨機能が使用されていない。詳細については、「非推奨通知」を参照してください。
- 過去 7 日以内に、クラスター内の少なくとも 1 台の HSM に対して、SDK を使用した接続が行われている。
クラスターが ACTIVE 状態である。
クラスターに含まれる HSM が 27 台以下である。
移行中に HSM オペレーションのエラーレートが増加しない。

注記

トークンキーのワークロードを持つお客様が移行できなかった以前の制限は解除されました。

クラスターの書き込み制限モード

クラスターの移行を開始すると、クラスターは書き込み制限モードになります。HSM の状態を変更する可能性のあるオペレーションは拒否されます。読み取りオペレーションはすべて影響を受けません。

移行中、アプリケーションが次のオペレーションを実行しようとすると、HSM からエラーが返されます。

トークンキーの生成および削除 (セッションキーのワークロードは引き続き動作します)。
ユーザーの作成、削除、変更のすべて。
クォーラムオペレーション。
キー属性の変更など、HSM 内のキーの変更。
mTLS の登録。

AWS CloudHSM は、移行中にクラスターを MODIFY_IN_PROGRESS 状態にします。この期間中は、クラスターに HSM を追加したり、クラスターから HSM を削除したりすることはできません。

移行の開始

クラスター移行プロセスでは、クラスター内の HSM を 1 台ずつ順番に置き換えていきます。所要時間は、クラスター内の HSM の台数に依存します。平均して HSM 1 台あたり約 30 分かかります。クラスター内の各 HSM の HSM タイプをモニタリングすることで、何台の HSM が新しいタイプへ移行済みかを確認し、進行状況を追跡できます。

Console

HSM タイプを変更するには (コンソール)

AWS CloudHSM コンソール (https://console.aws.amazon.com/cloudhsm/home) を開きます。
変更するクラスターの ID の横のラジオボタンを選択します。
[アクション] メニューから、Modify HSM Type を選択し、目的の HSM タイプを選択します。

この手順を実行すると、クラスターは MODIFY_IN_PROGRESS 状態になります。移行が完了すると、クラスターは ACTIVE 状態に戻ります。

AWS CLI

HSM タイプを変更するには (AWS CLI)

コマンドラインプロンプトで、 modify-cluster コマンドを実行します。クラスター ID と目的の HSM タイプを指定します。


$ aws cloudhsmv2 modify-cluster --cluster-id <cluster ID> --hsm-type <HSM Type>
                                                 
 
 {
     "Cluster": {
         "BackupPolicy": "DEFAULT",
         "BackupRetentionPolicy": {
             "Type": "DAYS",
             "Value": 90
          },
         "VpcId": "vpc-50ae0636",
         "SubnetMapping": {
             "us-west-2b": "subnet-49a1bc00",
             "us-west-2c": "subnet-6f950334",
             "us-west-2a": "subnet-fd54af9b"
         },
         "SecurityGroup": "sg-6cb2c216",
         "HsmType": "hsm2m.medium",
         "HsmTypeRollbackExpiration": 1730383180.000,
         "Certificates": {},
         "State": "MODIFY_IN_PROGRESS",
         "Hsms": [],
         "ClusterId": "cluster-igklspoyj5v",
         "ClusterMode": "FIPS",
         "CreateTimestamp": 1502423370.069
     }
 }

この手順を実行すると、クラスターは MODIFY_IN_PROGRESS 状態になります。移行が完了すると、クラスターは ACTIVE 状態に戻ります。

AWS CloudHSM API

HSM タイプを変更するには (AWS CloudHSM API)

ModifyCluster リクエストを送信します。クラスターの ID と目的の HSM タイプを指定します。

この手順を実行すると、クラスターは MODIFY_IN_PROGRESS 状態になります。移行が完了すると、クラスターは ACTIVE 状態に戻ります。

移行のロールバック

AWS CloudHSM は、移行全体を通してエラーレートの上昇をモニタリングし、継続的に検証チェックを実行します。サービス品質の低下や検証の失敗を検出した場合、AWS CloudHSM はクラスターを元の HSM タイプに自動的にロールバックします。ロールバック中は、クラスター内の各 HSM に対して次の処理が行われます。

AWS CloudHSM は、その HSM の移行開始時に取得したバックアップを使用します。
すべての HSM が元のタイプに戻るまで、HSM を 1 台ずつ順番に置き換えます。
ロールバック処理の全期間を通じて、クラスターは書き込み制限モードのまま維持されます。

移行開始から 24 時間以内であれば、移行をロールバックできます。ロールバックの期限を確認するには:

describe-clusters コマンドを実行します。
HsmTypeRollbackExpiration の値を探します。このタイムスタンプはロールバックの期限です。

ロールバックする場合は、この期限までにロールバックしてください。ロールバックでは、元の HSM タイプの最新のバックアップが使用されます。

警告

移行完了後のロールバックには注意が必要です。移行を完了した後に AWS CloudHSM を使用して新しいキーやユーザーを作成している場合、ロールバックによってデータが失われる可能性があります。ロールバック後のデータ損失を軽減する方法については、ロールバック後のデータ同期を参照してください。

Console

HSM タイプをロールバックするには (コンソール)

AWS CloudHSM コンソール (https://console.aws.amazon.com/cloudhsm/home) を開きます。
ロールバックしたいクラスターの ID を選択します。
[アクション] メニューから、Modify HSM Type を選択し、元の HSM タイプを選択します。

この手順を実行すると、クラスターは ROLLBACK_IN_PROGRESS 状態になります。ロールバックが完了すると、クラスターは ACTIVE 状態に戻ります。

AWS CLI

HSM タイプをロールバックするには (AWS CLI)

コマンドラインプロンプトで、 modify-cluster コマンドを実行します。クラスター ID と元の HSM タイプを指定します。


$ aws cloudhsmv2 modify-cluster --cluster-id <cluster ID> --hsm-type <HSM Type>
                                
{
 "Cluster": {
     "BackupPolicy": "DEFAULT",
     "BackupRetentionPolicy": {
         "Type": "DAYS",
         "Value": 90
      },
     "VpcId": "vpc-50ae0636",
     "SubnetMapping": {
         "us-west-2b": "subnet-49a1bc00",
         "us-west-2c": "subnet-6f950334",
         "us-west-2a": "subnet-fd54af9b"
     },
     "SecurityGroup": "sg-6cb2c216",
     "HsmType": "hsm1.medium",
     "HsmTypeRollbackExpiration": 1730383180.000,
     "Certificates": {},
     "State": "ROLLBACK_IN_PROGRESS",
     "Hsms": [],
     "ClusterId": "cluster-igklspoyj5v",
     "ClusterMode": "FIPS",
     "CreateTimestamp": 1502423370.069
 }
}

この手順を実行すると、クラスターは ROLLBACK_IN_PROGRESS 状態になります。ロールバックが完了すると、クラスターは ACTIVE 状態に戻ります。

AWS CloudHSM API

HSM タイプをロールバックするには (AWS CloudHSM API)

ModifyCluster リクエストを送信します。クラスターの ID と元の HSM タイプを指定します。

この手順を実行すると、クラスターは ROLLBACK_IN_PROGRESS 状態になります。ロールバックが完了すると、クラスターは ACTIVE 状態に戻ります。

ロールバック後のデータ同期

移行中、HSM は書き込み制限モードであるため、HSM の状態を変更することはできません。この期間中 (クラスターが MODIFY_IN_PROGRESS の間) にロールバックを行うと、クラスターの内容は元のクラスターと完全に同一の状態になります。

クラスターが ACTIVE 状態に戻ると、書き込み制限モードは解除されます。ACTIVE 状態の間にキーやユーザーを作成し、その後ロールバックを実行した場合、そのキーやユーザーはロールバック後のクラスターには存在しません。

ユーザーの同期に対応するには、CloudHSM CLI を使用したユーザー管理で、ロールバック後のクラスター上に不足しているユーザーを再作成します。これは、user replicate コマンドが hsm2m.medium から hsm1.medium へのユーザー同期をサポートしていないため、ユーザーを手動で再作成する必要があるためです。詳細については、ユーザーレプリケートに関する既知の問題を参照してください。

キーの同期に対応するには、key replicate コマンドを使用して、2 つのクラスター間でキーをレプリケートします。CloudHSM CLI をインストールしていない場合は、AWS CloudHSM コマンドラインインターフェイス (CLI) の使用開始の手順を参照してください。

ロールバック後にキーを同期するには

ロールバック完了後、次の手順に従います。ここでは以下の用語を使用します。

cluster-1: ロールバック後のクラスター (現在 hsm1.medium)
cluster-2: 新たに作成する一時的な hsm2m.medium クラスター

cluster-1 の最新の hsm2m.medium バックアップを使用して、新しい hsm2m.medium クラスター (cluster-2) を作成します。


aws cloudhsmv2 create-cluster --hsm-type hsm2m.medium \
                                --subnet-ids <subnet ID 1> <subnet ID 2> <subnet ID N> \
                                --source-backup-id <backup ID>
                                --mode <FIPS>

cluster-2 に HSM を作成します。


aws cloudhsmv2 create-hsm --cluster-id <cluster-2 ID>

cluster-2 で、レプリケーションが必要なキーを一覧表示します。
```
cloudhsm-cli key list --cluster-id <cluster-2 ID>
```

cluster-2 から cluster-1 へ、各キーをレプリケートします。


cloudhsm-cli key replicate --source-cluster-id <cluster-2 ID> \
                        --destination-cluster-id <cluster-1 ID> \
                        --filter attr.label=<key ID>

コピーが必要なすべてのキーについて、手順 4 を繰り返します。

cluster-2 の HSM を削除します。


aws cloudhsmv2 delete-hsm --cluster-id <cluster-2 ID> --hsm-id <HSM ID>

cluster-2 を削除します。


aws cloudhsmv2 delete-cluster --cluster-id <cluster-2 ID>

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

HSM クラスタータイプの移行

HSM ユーザー