翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
でのキー同期と耐久性の設定 AWS CloudHSM
このトピックでは AWS CloudHSM、 のキー同期設定、お客様がクラスターでキーを操作する際に直面する一般的な問題、およびキーをより耐久性の高いものにするための戦略について説明します。
概念
- Token keys
-
キー生成、インポート、またはラップ解除オペレーション中に作成する永続キー。 は、クラスター全体でトークンキーを AWS CloudHSM 同期します。
- Session keys
-
クラスター内の 1 つのハードウェアセキュリティモジュール (HSM) にのみ存在するエフェメラルキー。 AWS CloudHSM は、クラスター間でセッションキーを同期しません。
- Client-side key synchronization
-
キーの生成、インポート、またはアンラップ操作中に作成したトークンキーをクローンするクライアント側のプロセス。少なくとも 2 つの HSM を用いてクラスターを実行することで、トークンキーの耐久性を高めることができます。
- Server-side key synchronization
-
クラスター内のすべての HSM に対して定期的にキーをクローンします。管理は必要ありません。
- Client key durability settings
-
キーの耐久性に影響するクライアント上に構成した設定。[Client SDK 5] と [Client SDK 3] では動作が異なります。
-
クライアント SDK 5 では、この設定を使用して、単一の HSM クラスターを実行します。
-
クライアント SDK 3 では、この設定を使用して、キー作成オペレーションを成功させるために必要な HSM の数を指定します。
-
キーの同期について
AWS CloudHSM は、キー同期を使用して、クラスター内のすべての HSMs でトークンキーのクローンを作成します。キーの生成、インポート、またはアンラップ操作中、トークンキーを永続キーとして作成します。クラスターを通してこれらのキーを配信するには、CloudHSM はクライアント側とサーバー側の両方にキーの同期を提供します。
キー同期の目標(サーバー側とクライアント側の両方)は、新しいキーを作成した後、できるだけ迅速にクラスター全体に、それを配信することです。これは、新しいキーを使用するために実行する後続の呼び出しが、クラスター内の利用可能な HSM にルーティングされる可能性があるため重要です。作成した呼び出しが キーなしで HSM にルーティングされた場合、呼び出しは失敗します。キー作成操作の後に実行される後続の呼び出しをアプリケーションで再試行するように指定することで、これらのタイプの障害を軽減できます。同期に必要な時間は、クラスターやその他の無形オブジェクト上のワークロードによって異なります。 CloudWatch メトリクスを使用して、この種の状況でアプリケーションが採用するタイミングを決定します。詳細については、「 CloudWatch メトリクス」を参照してください。
クラウド環境でのキー同期の課題は、キーの耐久性です。1 つの HSM でキーを作成し、多くの場合、それらのキーを使ってすぐに開始します。キーがクラスター内の別のHSMに複製される前に、その上にキーを作成する HSM に障害が発生した場合は、キーで暗号化されたいかなるものに対するキー および アクセスを失います。このリスクを軽減するために、client-side synchronization を提供します。クライアント側の同期は、キーの生成、インポート、またはアンラップ操作中に作成したキーをクローンするクライアント側のプロセスです。クローニングキーの作成時にクローンを作成すると、キーの耐久性が向上します。もちろん、1 つの HSM を用いてクラスター内のキーのクローンを作成することはできません。キーの耐久性を高めるために、最低 2 つの HSM を使用するようにクラスターを構成することをお勧めします。クライアント側の同期と 2 つの HSM を持つクラスターで、クラウド環境におけるキーの耐久性の課題に対応できます。
クライアントキーの耐久性設定の操作
キーの同期は主に自動プロセスですが、クライアント側のキーの耐久性設定を管理できます。クライアント側のキーの耐久性設定は、クライアント SDK 5 とクライアント SDK 3 では異なる動作をします。
-
クライアント SDK 5 では、最低 2 つの HSM を用いてクラスターを実行することを求める key availability quorums のコンセプトを紹介します。クライアント側のキーの耐久性設定を使用して、2 つの HSM 要件をオプトアウトできます。quorums のさらなる詳細については、Client SDK 5 の概念 を参照してください。
-
Client SDK 3 では、クライアント側のキーの耐久性設定を使用して、オペレーション全体を成功と見なすためにキーの作成を成功させる必要がある HSM の数を指定します。
クライアント SDK 5 では、キーの同期は完全自動プロセスです。キー可用性クォーラムを用いて、アプリケーションがキーを使用できるようになる前に、新しく作成されたキーがクラスター内の 2 つの HSM 上に存在している必要があります。キーの可用性クォーラムを使用するには、クラスターに最低 2 つの HSM が必要です。
クラスター構成がキーの耐久性要件を満たしていない場合、トークンキーを作成または使用しようとすると、ログに次のエラーメッセージが表示されて失敗します。
Key <key handle>
does not meet the availability requirements - The key must be available on at least 2 HSMs before being used.
クライアント構成設定を使用して、キーの可用性クォーラムをオプトアウトできます。たとえば、単一の HSM を用いてクラスターの実行をオプトアウトしたい場合があります。
Client SDK 5 の概念
- Key Availability Quorum
-
AWS CloudHSM は、アプリケーションがキーを使用する前にキーが存在する必要があるクラスター内の HSMs の数を指定します。最低 2 つの HSM を持つクラスターが必要です。
クライアントキーの耐久性設定の管理
クライアントキーの耐久性設定を管理するには、Client SDK 5 用の構成ツールを使用する必要があります。
[Client SDK 3] では、キーの同期は主に自動プロセスですが、クライアントキーの耐久性設定を使用してキーの耐久性を高めることができます。オペレーション全体を成功と見なすためにキーの作成を引き継ぐ必要がある HSM の数を指定します。クライアント側の同期では、選択した設定に関係なく、クラスター内のすべての HSM にキーのクローンするために、ベストエフォートの試行を行います。この設定では、指定した HSM の数の上にキーの作成が強制されます。値を指定し、システムがその数の HSM にキーをレプリケートできない場合、不要なキーマテリアルは自動的にクリーンアップされ、再試行できます。
重要
クライアントキーの耐久性設定を設定しない場合 (またはデフォルト値の 1 を使用する場合)、キーが失われる恐れがあります。サーバーサイドサービスがそのキーを別の HSM に複製する前に現在の HSM に障害が発生した場合、キーマテリアルは失われます。
キーの耐久性を最大化するには、クライアント側の同期のために少なくとも 2 つの HSM を指定することを検討してください。HSM をいくつ指定しても、クラスター上のワークロードは変わりません。クライアント側の同期では、クラスター内のすべての HSM に対して常にベストエフォート型のキーのクローンが試行されます。
推奨事項
-
Minimum: クラスターあたり 2 つの HSM
-
Maximum: クラスター内の HSM の総数より 1 少ない
クライアント側の同期に失敗すると、クライアントサービスは作成された可能性があり、不要になった可能性のある不要なキーをクリーンアップします。このクリーンアップは、常に機能するとは限らないベストエフォート対応です。クリーンアップが失敗した場合は、不要なキーマテリアルを削除する必要があります。さらなる詳細については、Key Synchronization Failures を参照してください。
クライアントキーの耐久性のための設定ファイルの設定
クライアントキーの耐久性設定を指定するには、cloudhsm_client.cfg
を編集します。
クライアント設定ファイルを編集するには
-
cloudhsm_client.cfg
を開きます。Linux :
/opt/cloudhsm/etc/
cloudhsm_client.cfg
Windows :
C:\ProgramData\Amazon\CloudHSM\data\
cloudhsm_client.cfg
-
ファイルの
client
ノードで、キー作成オペレーションを成功させるために がキーを正常に作成 AWS CloudHSM する必要がある HSMsの最小数の値を追加してcreate_object_minimum_nodes
指定します。"create_object_minimum_nodes" :
2
注記
[key_mgmt_util (KMU)]コマンドラインツール]には、クライアントキーの耐久性の追加設定があります。詳細については、KMU とクライアント側の同期 を参照してください。
設定リファレンス
これらは、cloudhsm_client.cfg
の抜粋中に示されるクライアント側の同期プロパティです:
{
"client": {
"create_object_minimum_nodes" : 2
,
...
},
...
}
- create_object_minimum_nodes
-
キーの生成、キーのインポート、またはキーアンラップ操作が成功したと見なすために必要な HSM の最小数を指定します。設定されると、デフォルトは、[1] になります。つまり、キーがオペレーション作成するたびに、クライアント側のサービスはクラスター内のすべての HSM でキーを作成しようとしますが、成功を返すためには、クラスター内の HSM 上で single key の生成を必要とするだけです。
KMU とクライアント側の同期
[key_mgmt_util (KMU)] コマンドラインツールを使用してキーを作成する場合は、オプションのコマンドラインパラメータ (-min_srv
) を使って、キーのクローンを作成する HSM の数を limit します。コマンドラインパラメータと値を設定ファイルで指定すると、 は 2 つの値の LARGER を AWS CloudHSM 優先します。
詳細については、次のトピックを参照してください。
クローンされたクラスター間でのキーの同期
クライアント側とサーバー側の同期は、同じ クラスターの中でキーを同期させるためだけのためにあります。クラスターのバックアップを別のリージョンにコピーする場合は、クラスタ間でのキーを同期のために[cloudhsm_mgmt_util(CMU)] 中の [syncKey] コマンドを使用できます。クローンクラスタは、クロスリージョンの冗長性のため、または災害対策プロセスを簡素化するために使用できます。さらなる詳細については、syncKey を参照してください。