AWS CloudHSM のよくある質問

HSM が AWS CloudHSM クラスターにプロビジョニングされた 1 時間 (または 1 時間未満) ごとに時間料金が課金されます。HSM が存在しないクラスターや、暗号化されたバックアップの自動ストレージは請求の対象ではありません。詳細については、AWS CloudHSM の料金ページをご覧ください。HSM についてのネットワークデータ転送や受信には別途料金がかかります。詳しくは、EC2 のデータ転送料金を確認してください。

いいえ。AWS CloudHSM に無料利用枠はありません。

いいえ。リージョンによって異なる時間料金は HSM の使用量によって変わりません。

いいえ、AWS CloudHSM のリザーブドインスタンス料金は提供していません。

はい。AWS CloudHSM の利用を開始するには、いくつかの前提条件を満たす必要があります。それには、AWS CloudHSM サービスを利用したいリージョンに仮想プライベートクラウド (VPC) があることなどが含まれます。詳細については、AWS CloudHSM ユーザーガイドを参照してください。

いいえ。ハードウェアのファームウェアは AWS で管理します。ファームウェアはサードパーティによってメンテナンスされます。また、すべてのファームウェアは、FIPS 140-2 レベル 3 コンプライアンスを満たしているかどうかについて NIST の評価を受ける必要があります。インストールできるのは、FIPS キーによって暗号化された署名済みのファームウェアのみです (AWS にはこのキーへのアクセス権がありません)。

AWS では、本番ワークロードには少なくとも 2 つの HSM を、異なる 2 つのアベイラビリティーゾーンで使用することを強くお勧めします。ミッションクリティカルなワークロードには少なくとも 3 つの HSM を、異なる 2 つの AZ で使用することをお勧めします。CloudHSM クライアントでは、HSM の障害を自動的に処理し、複数の HSM 全体でアプリケーションに対して透過的に負荷分散を行います。

AWS は CloudHSM クラスターの自動暗号化バックアップを毎日作成します。AWS では、クラスターのライフサイクルイベント (HSM の追加や削除) が発生した場合には追加のバックアップを行います。次にバックアップが行われるまでの 24 時間の間に作成され、クラスターにインポートされたキーマテリアルの耐久性については、お客様が全責任を負います。キーの耐久性を確保するために、作成されたキーが、異なる 2 つのアベイラビリティーゾーンで少なくとも 2 つの HSM と確実に同期されるようにすることを強くお勧めします。キーの同期を確認する方法の詳細については、AWS CloudHSM ユーザーガイドをご覧ください。

CloudHSM クラスターの 2 つのアベイラビリティーゾーンに最低 2 つの HSM がある場合、高可用性が自動的に設定されます。追加の設定は必要ありません。クラスター内の HSM に障害が発生した場合、HSM は自動的に交換されます。また、すべてのクライアントは更新され、処理を中断することなく新しい設定が反映されます。AWS API または SDK を使用して HSM をクラスターにさらに追加できるため、アプリケーションを中断することなく可用性を向上できます。

単一の CloudHSM クラスターには、アカウントサービスの制限に従い、最大 28 個の HSM を含めることができます。サービスの制限の詳細と、制限の引き上げをリクエストする方法については、オンラインドキュメントをご覧ください。

CloudHSM クラスターは AWS によって毎日バックアップされます。キーは、"エクスポート不可" として生成されていない限り、クラスター外にエクスポート ("ラップ") し、オンプレミスに保存することもできます。

はい、AWS CloudHSM のサービスレベルアグリーメント (SLA) はこちらで確認できます。

いいえ。サービスの一部として、HSM に対してシングルテナントアクセスを取得することになります。基盤となるハードウェアは他のお客様と共有できますが、HSM にアクセスできるのはお客様ご自身のみです。

責任の分離とロールベースのアクセスコントロールは、AWS CloudHSM の設計の特徴です。AWS には HSM に対する制限付きの認証情報があります。これにより、HSM の正常性と可用性をモニタリングして維持し、暗号化されたバックアップを確保し、監査ログを抽出して CloudWatch Logs に公開することができます。AWS は CloudHSM クラスター内のキーやデータにアクセスできず、HSM アプライアンスユーザーに許可されている操作以外は実行できません。

責任の分離および各クラスのユーザーが HSM に所有している機能に関する詳細については、AWS CloudHSM ユーザーガイドをご覧ください。

はい。AWS CloudHSM では、CloudHSM クラスターおよび個々の HSM 向けに複数の Amazon CloudWatch メトリクスが発行されます。Amazon CloudWatch コンソール、API、SDK を使用して、このようなメトリクスの取得やアラームの作成を実行できます。

各 HSM には FIPS で検証された決定論的ランダムビットジェネレーター (DRBG) が搭載されています。DRBG では、SP800-90B に準拠する真性乱数ジェネレーター (TRNG) によって HSM ハードウェアモジュール内で生成されたシード値が用いられます。

AWS CloudHSM には、物理的および論理的な不正使用を検知して応答するメカニズムがあり、これによりハードウェアのキー削除 (ゼロ化) がトリガーされます。ハードウェアは物理的な防壁が突破された場合、不正使用を検知するように設計されています。また、HSM は総当たり方式でのログイン攻撃からも保護されています。管理者または Crypto Officer (CO) 認証情報を用いた HSM へのアクセスが規定回数以上失敗すると、HSM は管理者/CO をロックアウトします。同様に、Crypto User (CU) 認証情報を用いた HSM へのアクセスが規定回数以上失敗すると、そのユーザーはロックアウトされ、CO または管理者によるロック解除が必要になります。

Amazon では、可用性およびエラー条件に対応するため、HSM およびネットワークのモニタリングとメンテナンスを行っています。HSM で障害が発生するかネットワーク接続が失われた場合、HSM は自動的に交換されます。AWS CloudHSM API、SDK、CLI ツールを使用して個々の HSM の状態をチェックすることができます。また、AWS サービスヘルスダッシュボードを使用すれば、いつでもサービス全体の状態をチェックできます。

AWS CloudHSM クラスターに HSM が 1 つしかない場合、最新の毎日のバックアップ以降に作成されたキーが失われる可能性があります。2 つ以上の HSM を備えた AWS CloudHSM クラスターは、片方の HSM に障害が発生してもキーを失うことがないように別々のアベイラビリティーゾーンに配置するのが理想的です。詳細については、「ベストプラクティス」を参照してください。

Amazon にはユーザーのキーや認証情報へのアクセス権がありませんので、認証情報を紛失した場合にキーを回復させることはできません。

AWS CloudHSM は、連邦情報処理規格 (FIPS) 140-2 レベル 3 で検証されたハードウェア上に構築されています。CloudHSM で使用されるハードウェアの FIPS 140-2 セキュリティプロファイルと、CloudHSM が実行するファームウェアに関する情報は、「コンプライアンス」ページで確認できます。

はい。CloudHSM では FIPS 140-2 レベル 3 で検証された HSM が提供されます。CloudHSM ユーザーガイドのクラスターの HSM の身元と正当性の確認に記載されている手順に従って、NIST セキュリティポリシー (1 つ上の質問に記載) で指定されているものと同じモデルのハードウェアで正規の HSM が使用されていることを確認できます。

AWS CloudHSM は常に FIPS 140-2 モードで動作します。これは、CloudHSM ユーザーガイドに記載されているように、CLI ツールを使用して確認できます。getHsmInfo コマンドを実行すると、FIPS モードのステータスが表示されます。

はい。AWS CloudTrail は、お客様のアカウントで行われた AWS API コールを記録します。AWS CloudTrail で生成される AWS API コールの履歴を利用して、セキュリティ分析、リソース変更の追跡、コンプライアンス監査を実行できます。AWS CloudTrail の詳細については、CloudTrail のホームページをご覧ください。CloudTrail を有効にするには、CloudTrail の AWS マネジメントコンソールにアクセスしてください。

AWS CloudTrail には、HSM デバイスに関するものやアクセスログは含まれません。このようなイベントは、AWS CloudWatch Logs により AWS アカウントに直接配信されます。詳細については、AWS CloudHSM ユーザーガイドをご覧ください。

CloudHSM を対象とするコンプライアンスプログラムの詳細については、「AWS コンプライアンス」サイトをご覧ください。AWS の他のサービスとは異なり、AWS CloudHSM に関するコンプライアンス要件は大抵の場合、別の監査プログラムの一部としてではなく、FIPS 140-2 レベル 3 のハードウェア認定自体によって満たされます。

FIPS 140-2 レベル 3 は、ドキュメントの署名、支払い、SSL 証明書のための公開認証局のオペレーションなど、特定のユースケースの要件を規定しています。

AWS CloudHSM を対象とするコンプライアンスレポートを確認するには、コンプライアンスプログラムによる AWS 対象範囲内のサービスに関するデータを確認してください。無料のセルフサービスオンデマンドコンプライアンスレポートを作成するには、AWS Artifact を使用します。

AWS CloudHSM が提供する HSM の FIPS 検証のみに関心がある場合は、FIPS 検証をご覧ください。

パフォーマンスは、EC2 インスタンスの設定、データサイズ、および追加のアプリケーション負荷によって異なる場合があります。パフォーマンスを向上させるために、クラスターに HSM インスタンスを追加できます。アプリケーションの負荷テストを行って、スケーリングの必要性を判断することをお勧めします。

詳細については、AWS CloudHSM ユーザーガイドのパフォーマンスページを参照してください。

キーストレージとクラスター容量の詳細については、「AWS CloudHSM クォータ」を参照してください。

直接的にはサポートされていません。カスタムキーストアで AWS Key Management Service を使用して、CloudHSM クラスターで生成および保存されたキーを使うことによって Amazon RDS データを保護することもできます。

複数のサードパーティーベンダーが AWS CloudHSM を信頼できるルートとして支持しています。これは、CloudHSM クラスターで基盤となるキーを作成して保存しながら、選択したソフトウェアソリューションを利用できることを意味します。

AWS CloudHSM クライアントライブラリは、AWS が提供するソフトウェアパッケージです。これにより、アプリケーションと CloudHSM クラスター間で通信できるようになります。

いいえ。クライアントと HSM の間の通信すべては、エンドツーエンドで暗号化されています。AWS 側から通信を確認あるいは傍受することはできず、クラスターのアクセス認証情報を認識することはできません。

CloudHSM ユーザーガイドの手順をご覧ください。

いいえ、CloudHSM ツールは、安全な相互認証済みのチャネルを使用して、CloudHSM クライアントライブラリにより CloudHSM クラスターと直接通信します。AWS ではクライアント、ツール、HSM 間のどの通信も確認できません。エンドツーエンドで暗号化されているからです。

サポートされているオペレーティングシステムの全体一覧については、オンラインドキュメントをご覧ください。

CloudHSM クライアントライブラリを実行しているホスト、または CLI ツールを使用しているホストのネットワークは、CloudHSM クラスター内の HSM すべてに到達可能である必要があります。

CloudHSM クラスターと HSM の作成、修正、削除を実行し、そのステータスを取得できます。AWS CloudHSM API で実行できることは、AWS で制限付きアクセスを使用して実行できるオペレーションに限られています。API から HSM のコンテンツにアクセスしたり、ユーザー、ポリシー、その他の設定を修正したりすることはできません。API の詳細については CloudHSM ドキュメント、SDK の詳細については「AWS での構築ツール」ページをご覧ください。

まず、必要とするアルゴリズムとモードが AWS CloudHSM でサポートされていることを確認してください。必要に応じて、お客様のアカウントマネージャーが機能のリクエストを出すこともできます。次に、キーローテーション戦略を決めてください。AWS CloudHSM の詳細な移行ガイドも公開しました。これで、AWS CloudHSM の使用を開始する準備が整いました。

ローテーション戦略はアプリケーションのタイプによって異なります。一般的な例を以下にあげます。

• Signin のためのプライベートキー: 一般的に、HSM へのプライベートキーは中間証明書に対応し、この中間証明書はオフラインエンタープライズルートによって署名されます。キーのローテーションは新しい中間証明書の発行で行います。AWS CloudHSM でのOpenSSL を用いた新規プライベートキーの作成と対応する CSR の生成。次に、同じオフラインエンタープライズルートを用いて CSR に署名をします。この新規証明書は、証明書チェーンを自動的には検証しないパートナーに登録する必要がある可能性があります。その後は、新規リクエスト (ドキュメント、コード、その他の証明書など) はすべて新規証明書に対応する新規プライベートキーを登録します。元のプライベートキーからの署名の検証は、対応するパブリックキーで継続して行えます。取り消しの必要はありません。このプロセスは、SignIn キーの使用停止またはアーカイブを行う場合のものと似ています。
• Oracle 透明的データ暗号化: ウォレットの転送は、まずハードウェアキーストア (元の HSM) からソフトウェアキーストアに切り替え、それからハードウェアキーストア (AWS CloudHSM) に戻して行います。注意: Amazon RDS を使用している場合は、上記のよくある質問「AWS CloudHSM は Amazon RDS Oracle TDE をサポートしていますか?」を参照してください。
• エンベロープ暗号化に対する対照キー: エンベロープ暗号化とは、HSM でのひとつのキーが、アプリケーションホストの多くのデータキーを暗号化/復号化するキーアーキテクチャを言います。お客様はおそらくすでにキーローテーションプロセスをお持ちで、データキーを古いラッピングキーで復号し、これらの新しいラッピングキーで再度暗号化されていると思います。移行に際して唯一異なるのは、新しいラッピングキーが、元の HSM ではなく、AWS CloudHSM で作成、使用されることです。すでにキーローテーションツールとプロセスをお持ちでない場合、これを作成する必要があります。

アプリケーションとユースケースは場合によって異なります。一般的なシナリオに対する解決策は、CloudHSM の移行ガイドで説明されています。さらに不明な点がある場合、サポートケースを開いて、アプリケーションの詳細、お使いの HSM のタイプ、お使いのキーのタイプ、それらのキーがエクスポート可能かどうかをお伝えください。適切な移行パス決定のお手伝いをさせていただきます。

いいえ。ただし、必要な更新やハードウェアの障害が発生した場合、AWS がメンテナンスを行う必要がある場合があります。影響が予想される場合は、Personal Health Dashboard を使って事前に通知するように尽力いたします。

高可用性のためにクラスターを設計するのはお客様の責任であることにご注意ください。AWS では CloudHSM クラスターに関して、複数の HSM を別々のアベイラビリティーゾーンで使用するように構成することが強く推奨されています。推奨されるベストプラクティスの詳細については、オンラインドキュメントをご覧ください。

一般的な問題の解決策は、「トラブルシューティングガイド」で見つけることができます。それでも問題が解決しない場合は、AWS サポートにお問い合わせください。