翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
このセクションのベストプラクティスに従って、アプリケーションと AWS CloudHSM クラスターの統合方法を最適化します。
クライアント SDK のブートストラップ
クライアント SDK をクラスターに接続する前に、ブートストラップする必要があります。IP アドレスをクラスターにブートストラップするときは、可能であれば --cluster-id パラメーターを使用することをおすすめします。この方法では、個々のアドレスを追跡しなくても、クラスター内のすべての HSM IP アドレスが設定に入力されます。これにより、HSM がメンテナンス中であったり、アベイラビリティーゾーンが停止した場合でも、アプリケーションの初期化の回復力がさらに高まります。詳細については、クライアント SDK をブートストラップするを参照してください。
認証してオペレーションを実行
では AWS CloudHSM、暗号化オペレーションなどのほとんどのオペレーションを実行する前に、クラスターに対して認証する必要があります。
CloudHSM CLI による認証: CloudHSM CLI による認証は、シングルコマンドモード または インタラクティブモード のいずれかを使用して行うことができます。CloudHSM CLI を使用して HSM にログインする コマンドを使用してインタラクティブモードで認証します。シングルコマンドモードで認証するには、環境変数 CLOUDHSM_ROLE および CLOUDHSM_PIN を設定する必要があります。その方法の詳細については、「シングルコマンドモード」を参照してください。 AWS CloudHSM では、アプリケーションで使用されていないときは、HSM 資格情報を安全に保管することをお勧めします。
PKCS #11 による認証: PKCS #11 では、C_OpenSession を使用してセッションを開いた後に C_Login API を使用してログインします。C_Login はスロット (クラスター) ごとに 1 つだけ実行する必要があります。ログインに成功したら、追加のログインオペレーションを行わなくても C_OpenSession を使用して追加のセッションを開くことができます。PKCS #11 への認証の例については、「AWS CloudHSM クライアント SDK 5 用の PKCS #11 ライブラリのコードサンプル」を参照してください。
JCE による認証: AWS CloudHSM JCE プロバイダーは、暗黙的なログインと明示的なログインの両方をサポートしています。適切な方法は、ユースケースによって異なります。アプリケーションがクラスターから切断され、再認証が必要になった場合、SDK が自動的に認証を処理するため、可能な場合は Implicit Login を使用することをお勧めします。暗黙的ログインを使用すると、アプリケーションコードを制御できないインテグレーションを使用する場合でも、アプリケーションに認証情報を提供できます。ログイン方法の詳細については、「ステップ 2: JCE プロバイダーに認証情報を提供する」を参照してください。
OpenSSL による認証: OpenSSL 動的エンジンでは、環境変数を使用して認証情報を指定します。 AWS CloudHSM では、HSM 認証情報は、アプリケーションで使用しないときは安全に保存することをお勧めします。可能であれば、手動で入力しなくてもこれらの環境変数を体系的に取得して設定するように環境を設定する必要があります。OpenSSL による認証の詳細については、「AWS CloudHSM クライアント SDK 5 用の OpenSSL Dynamic Engine をインストールする」を参照してください。
KSP による認証: Windows 認証情報マネージャーまたは環境変数を使用して、キーストレージプロバイダー (KSP) で認証できます。「」を参照してくださいAWS CloudHSM クライアント SDK 5 のキーストレージプロバイダー (KSP) をインストールする。
アプリケーションのキーを効果的に管理する
キー属性を使用してキーで実行できる操作を制御する: キーを生成するときは、キー属性を使用して、そのキーに対する特定の種類の操作を許可または拒否する一連の権限を定義します。キーは、タスクを完了するのに必要な最小限の属性で生成することをおすすめします。たとえば、暗号化に使用する AES キーを HSM からラップアウトすることも許可しないでください。詳細については、以下のクライアント SDK の属性ページを参照してください。
可能な場合は、キーオブジェクトをキャッシュしてレイテンシーを最小限に抑える: キー検索オペレーションはクラスター内のすべての HSM にクエリを実行します。このオペレーションはコストがかかり、クラスター内の HSM 数に合わせて拡張できません。
PKCS #11 では、
C_FindObjectsAPI を使用してキーを検索します。JCE では、KeyStore を使用してキーを検索します。
最適なパフォーマンスを得るには、アプリケーションの起動時にキー検索コマンド ( KMU を使用して属性で AWS CloudHSM キーを検索するや などCloudHSM CLI でユーザーのキーを一覧表示する) を 1 回だけ使用し、返されたキーオブジェクトをアプリケーションメモリにキャッシュ AWS することをお勧めします。後でこのキーオブジェクトが必要になった場合は、オペレーションのたびにこのオブジェクトをクエリするのではなく、キャッシュからオブジェクトを取得する必要があります。そうすると、パフォーマンスのオーバーヘッドが大幅に増加します。
マルチスレッドを使用してください
AWS CloudHSM はマルチスレッドアプリケーションをサポートしていますが、マルチスレッドアプリケーションには注意すべき点がいくつかあります。
PKCS #11 では、PKCS #11 ライブラリ (呼び出し側C_Initialize) は 1 回だけ初期化する必要があります。各スレッドには独自のセッションを割り当てる必要があります (C_OpenSession)。同じセッションを複数のスレッドで使用することはお勧めしません。
JCE では、 AWS CloudHSM プロバイダーは 1 回だけ初期化する必要があります。SPI オブジェクトのインスタンスをスレッド間で共有しないでください。たとえば、Cipher、Signature、Digest、Mac、KeyFactory、KeyGenerator の各オブジェクトは、それぞれのスレッドのコンテキストでのみ使用してください。
スロットリングエラーの処理
以下の条件下では、HSM スロットリングエラーが発生する可能性があります。
クラスターがピーク時のトラフィックを管理できるよう適切にスケーリングされていない。
メンテナンスイベント中は、クラスターのサイズが +1 の冗長性を持たない。
アベイラビリティーゾーンが停止すると、クラスターで使用可能な HSM の数が減少する。
このシナリオを最適に処理する方法については、「HSM スロットリング」を参照してください。
クラスターのサイズが適切でスロットリングされないように、 AWS では、予想されるピークトラフィックで環境で負荷テストを行うことをお勧めします。
クラスターオペレーションのリトライを統合してください
AWS は、運用上またはメンテナンス上の理由で HSM を置き換える場合があります。このような状況に対してアプリケーションに回復力を持たせるために、 AWS では、クラスターにルーティングされるすべてのオペレーションにクライアント側の再試行ロジックを実装することをお勧めします。置換によって失敗したオペレーションを後で再試行しても、成功することが期待されます。
ディザスタリカバリ戦略の実装
イベントに対応して、トラフィックをクラスター全体またはリージョン全体から遠ざける必要がある場合があります。以下のセクションでは、そのための複数の戦略について説明します。
VPC ピアリングを使用して別のアカウントまたはリージョンからクラスターにアクセスする: VPC ピアリングを使用して、別のアカウントまたはリージョンから AWS CloudHSM クラスターにアクセスできます。詳細については、VPC Peering Guideの「VPC ピア機能とは」を参照してください。ピアリング接続を確立し、セキュリティグループを適切に設定すると、通常と同じ方法で HSM IP アドレスと通信できます。
同じアプリケーションから複数のクラスターに接続: クライアント SDK 5 の JCE プロバイダー、PKCS #11 ライブラリ、および CloudHSM CLI は、同じアプリケーションから複数のクラスターへの接続をサポートします。たとえば、それぞれ異なるリージョンにある 2 つのアクティブなクラスターがある場合、アプリケーションは両方に一度に接続して、通常のオペレーションの一部としてこの 2 つのクラスター間の負荷を分散できます。アプリケーションが クライアント SDK 5 (最新の SDK) を使用していない場合、同じアプリケーションから複数のクラスターに接続することはできません。あるいは、別のクラスターを稼働させ続け、地域的な障害が発生した場合には、ダウンタイムを最小限に抑えるためにトラフィックを他のクラスターに移すこともできます。詳細については、それぞれのページを参照してください。
バックアップからのクラスターの復元: 既存のクラスターのバックアップから新しいクラスターを作成できます。詳細については、「でのクラスターバックアップ AWS CloudHSM」を参照してください。
