翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS CloudHSM アプリケーション統合のベストプラクティス
<a name="bp-application-integration"></a>

このセクションのベストプラクティスに従って、アプリケーションと AWS CloudHSM クラスターの統合方法を最適化します。

## クライアント SDK のブートストラップ
<a name="bp-integration-bootstrapping"></a>

クライアント SDK をクラスターに接続する前に、ブートストラップする必要があります。IP アドレスをクラスターにブートストラップするときは、可能であれば `--cluster-id` パラメーターを使用することをおすすめします。この方法では、個々のアドレスを追跡しなくても、クラスター内のすべての HSM IP アドレスが設定に入力されます。これにより、HSM がメンテナンス中であったり、アベイラビリティーゾーンが停止した場合でも、アプリケーションの初期化の回復力がさらに高まります。詳細については、[クライアント SDK をブートストラップする](cluster-connect.md#connect-how-to)を参照してください。

## 認証してオペレーションを実行
<a name="w2aab9c13b7"></a>

では AWS CloudHSM、暗号化オペレーションなどのほとんどのオペレーションを実行する前に、クラスターに対して認証する必要があります。

[**CloudHSM CLI による認証**:　CloudHSM CLI による認証は、[シングルコマンドモード](cloudhsm_cli-modes.md#cloudhsm_cli-mode-single-command) または ](cloudhsm_cli-modes.md#cloudhsm_cli-mode-interactive)インタラクティブモード のいずれかを使用して行うことができます。[CloudHSM CLI を使用して HSM にログインする](cloudhsm_cli-login.md) コマンドを使用してインタラクティブモードで認証します。シングルコマンドモードで認証するには、環境変数 `CLOUDHSM_ROLE` および `CLOUDHSM_PIN` を設定する必要があります。その方法の詳細については、「[シングルコマンドモード](cloudhsm_cli-modes.md#cloudhsm_cli-mode-single-command)」を参照してください。 AWS CloudHSM では、アプリケーションで使用されていないときは、HSM 資格情報を安全に保管することをお勧めします。

**PKCS \$111 による認証**:　PKCS \$111 では、C\$1OpenSession を使用してセッションを開いた後に C\$1Login API を使用してログインします。C\$1Login はスロット (クラスター) ごとに 1 つだけ実行する必要があります。ログインに成功したら、追加のログインオペレーションを行わなくても C\$1OpenSession を使用して追加のセッションを開くことができます。PKCS \$111 への認証の例については、「[AWS CloudHSM クライアント SDK 5 用の PKCS \$111 ライブラリのコードサンプル](pkcs11-samples.md)」を参照してください。

**JCE による認証**: AWS CloudHSM JCE プロバイダーは、暗黙的なログインと明示的なログインの両方をサポートしています。適切な方法は、ユースケースによって異なります。アプリケーションがクラスターから切断され、再認証が必要になった場合、SDK が自動的に認証を処理するため、可能な場合は Implicit Login を使用することをお勧めします。暗黙的ログインを使用すると、アプリケーションコードを制御できないインテグレーションを使用する場合でも、アプリケーションに認証情報を提供できます。ログイン方法の詳細については、「[ステップ 2: JCE プロバイダーに認証情報を提供する](java-library-install_5.md#java-library-credentials_5)」を参照してください。

**OpenSSL による認証**: OpenSSL 動的エンジンでは、環境変数を使用して認証情報を指定します。 AWS CloudHSM では、HSM 認証情報は、アプリケーションで使用しないときは安全に保存することをお勧めします。可能であれば、手動で入力しなくてもこれらの環境変数を体系的に取得して設定するように環境を設定する必要があります。OpenSSL による認証の詳細については、「[AWS CloudHSM クライアント SDK 5 用の OpenSSL Dynamic Engine をインストールする](openssl5-install.md)」を参照してください。

**KSP による認証**: キーストレージプロバイダー (KSP) で認証するには、Windows 資格情報マネージャーまたは環境変数のいずれかを使用できます。[AWS CloudHSM クライアント SDK 5 のキーストレージプロバイダー (KSP) をインストールする](ksp-library-install.md) を参照してください。

## アプリケーションのキーを効果的に管理する
<a name="bp-manage-application"></a>

**キー属性を使用してキーで実行できる操作を制御する**: キーを生成するときは、キー属性を使用して、そのキーに対する特定の種類の操作を許可または拒否する一連の権限を定義します。キーは、タスクを完了するのに必要な最小限の属性で生成することをおすすめします。たとえば、暗号化に使用する AES キーを HSM からラップアウトすることも許可しないでください。詳細については、以下のクライアント SDK の属性ページを参照してください。
+ [PKCS \$111 の主要属性](pkcs11-attributes.md)
+ [JCE キーの属性](java-lib-attributes_5.md)

**可能な場合は、キーオブジェクトをキャッシュしてレイテンシーを最小限に抑える**: キー検索オペレーションはクラスター内のすべての HSM にクエリを実行します。このオペレーションはコストがかかり、クラスター内の HSM 数に合わせて拡張できません。
+ PKCS \$111 では、 `C_FindObjects` API を使用してキーを検索します。
+ JCE では、KeyStore を使用してキーを検索します。

最適なパフォーマンスを得るには、アプリケーションの起動時にキー検索コマンド ( [KMU を使用して属性で AWS CloudHSM キーを検索する](key_mgmt_util-findKey.md)や など[CloudHSM CLI でユーザーのキーを一覧表示する](cloudhsm_cli-key-list.md)) を 1 回だけ使用し、返されたキーオブジェクトをアプリケーションメモリにキャッシュ AWS することをお勧めします。後でこのキーオブジェクトが必要になった場合は、オペレーションのたびにこのオブジェクトをクエリするのではなく、キャッシュからオブジェクトを取得する必要があります。そうすると、パフォーマンスのオーバーヘッドが大幅に増加します。

## マルチスレッドを使用してください
<a name="w2aab9c13c11"></a>

AWS CloudHSM はマルチスレッドアプリケーションをサポートしていますが、マルチスレッドアプリケーションには注意すべき点がいくつかあります。

**PKCS \$111** では、PKCS \$111 ライブラリ (呼び出し側`C_Initialize`) は 1 回だけ初期化する必要があります。各スレッドには独自のセッションを割り当てる必要があります (`C_OpenSession`)。同じセッションを複数のスレッドで使用することはお勧めしません。

**JCE **では、 AWS CloudHSM プロバイダーは 1 回だけ初期化する必要があります。SPI オブジェクトのインスタンスをスレッド間で共有しないでください。たとえば、Cipher、Signature、Digest、Mac、KeyFactory、KeyGenerator の各オブジェクトは、それぞれのスレッドのコンテキストでのみ使用してください。

## スロットリングエラーの処理
<a name="w2aab9c13c13"></a>

以下の条件下では、HSM スロットリングエラーが発生する可能性があります。
+ クラスターがピーク時のトラフィックを管理できるよう適切にスケーリングされていない。
+ メンテナンスイベント中は、クラスターのサイズが \$11 の冗長性を持たない。
+ アベイラビリティーゾーンが停止すると、クラスターで使用可能な HSM の数が減少する。

このシナリオを最適に処理する方法については、「[HSM スロットリング](troubleshoot-hsm-throttling.md)」を参照してください。

クラスターのサイズが適切でスロットリングされないように、 では、予想されるピークトラフィックを使用して環境で負荷テストを行う AWS ことをお勧めします。

## クラスターオペレーションのリトライを統合してください
<a name="w2aab9c13c15"></a>

AWS は、運用上またはメンテナンス上の理由で HSM を置き換える場合があります。このような状況に対してアプリケーションの耐障害性を高めるため、 AWS では、クラスターにルーティングされるすべてのオペレーションでクライアント側の再試行ロジックを実装することをお勧めします。置換によって失敗したオペレーションを後で再試行しても、成功することが期待されます。

## ディザスタリカバリ戦略の実装
<a name="w2aab9c13c17"></a>

イベントに対応して、トラフィックをクラスター全体またはリージョン全体から遠ざける必要がある場合があります。以下のセクションでは、そのための複数の戦略について説明します。

**VPC ピアリングを使用して別のアカウントまたはリージョンからクラスターにアクセスする**: VPC ピアリングを使用して、別のアカウントまたはリージョンから AWS CloudHSM クラスターにアクセスできます。詳細については、*VPC Peering Guide*の「[VPC ピア機能とは](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)」を参照してください。ピアリング接続を確立し、セキュリティグループを適切に設定すると、通常と同じ方法で HSM IP アドレスと通信できます。

**同じアプリケーションから複数のクラスターに接続**: クライアント SDK 5 の JCE プロバイダー、PKCS \$111 ライブラリ、および CloudHSM CLI は、同じアプリケーションから複数のクラスターへの接続をサポートします。たとえば、それぞれ異なるリージョンにある 2 つのアクティブなクラスターがある場合、アプリケーションは両方に一度に接続して、通常のオペレーションの一部としてこの 2 つのクラスター間の負荷を分散できます。アプリケーションが クライアント SDK 5 (最新の SDK) を使用していない場合、同じアプリケーションから複数のクラスターに接続することはできません。あるいは、別のクラスターを稼働させ続け、地域的な障害が発生した場合には、ダウンタイムを最小限に抑えるためにトラフィックを他のクラスターに移すこともできます。詳細については、それぞれのページを参照してください。
+ [用の PKCS \$111 ライブラリを使用した複数のスロット設定 AWS CloudHSM](pkcs11-library-configs-multi-slot.md)
+ [JCE プロバイダーを使用した複数の AWS CloudHSM クラスターへの接続](java-lib-configs-multi.md)
+ [CloudHSM CLI を使用した複数のクラスターへの接続](cloudhsm_cli-configs-multi-cluster.md)

**バックアップからのクラスターの復元**: 既存のクラスターのバックアップから新しいクラスターを作成できます。詳細については、「[でのクラスターバックアップ AWS CloudHSM](manage-backups.md)」を参照してください。

## アプリケーションのデプロイをずらす
<a name="bp-stagger-deployment"></a>

クライアントアプリケーションのデプロイと再起動には、プログレッシブウェーブベースのデプロイ、ワンボックスデプロイ、ローリングデプロイなどのずらされたデプロイ戦略に従います。このアプローチにより、変更による潜在的な影響を最小限に抑えながら、デプロイ中に本番トラフィックを処理するのに十分な容量を確保できます。