AWS CloudHSM アプリケーション統合のベストプラクティス

このセクションのベストプラクティスに従って、アプリケーションと 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 CloudHSMJ　CE プロバイダは、暗黙的ログインと明示的ログインの両方をサポートします。適切な方法は、ユースケースによって異なります。アプリケーションがクラスターから切断され、再認証が必要になった場合、SDK が自動的に認証を処理するため、可能な場合は Implicit Login を使用することをお勧めします。暗黙的ログインを使用すると、アプリケーションコードを制御できないインテグレーションを使用する場合でも、アプリケーションに認証情報を提供できます。ログイン方法の詳細については、「ステップ 2: JCE プロバイダーに認証情報を提供する」を参照してください。

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

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

アプリケーションのキーを効果的に管理する

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

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

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

マルチスレッドを使用してください

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

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

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

スロットリングエラーの処理

以下の条件下では、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 でのクラスターのバックアップ」を参照してください。