AWS CloudHSM
FIPS 140-2 Level 3 認証済みのハードウェアセキュリティモジュールを専有利用し、暗号鍵の生成 / 保管 / 暗号処理をクラウド上で実行するサービス
概要
AWS CloudHSM は、専用のハードウェアセキュリティモジュール (HSM) をクラウド上で提供するサービスです。FIPS 140-2 Level 3 または FIPS 140-3 Level 3 の認証を取得した Cavium/Marvell 製の HSM アプライアンスを VPC 内に配置し、暗号鍵の生成、保管、署名、暗号化/復号をハードウェア内で完結させます。鍵素材は HSM の耐タンパー性ハードウェアから外部に取り出せず、AWS を含む誰もアクセスできません。PKCS#11、JCE (Java Cryptography Extension)、Microsoft CNG の標準インターフェイスに対応しており、既存のアプリケーションコードを最小限の変更で統合できます。
KMS との根本的な違いと選定基準
CloudHSM と KMS はどちらも暗号鍵の管理に使えますが、制御モデルとコンプライアンス要件が根本的に異なります。KMS はマルチテナントの共有 HSM 基盤上で動作し、AWS が鍵のライフサイクル管理を代行します。API は AWS 独自で、暗号化/復号/署名の操作を KMS API 経由で実行します。料金は鍵ごとの月額保管料と API 呼び出し数に基づく従量課金で、最新の単価は AWS 公式の料金ページを確認してください。CloudHSM はシングルテナントの専用 HSM を提供し、鍵の管理責任はすべてユーザーにあります。AWS は HSM のハードウェア運用のみを担当し、鍵素材には一切アクセスできません。PKCS#11 や JCE などの業界標準インターフェイスを使うため、オンプレミスの HSM からの移行が容易です。CloudHSM を選ぶべきケースは、規制要件で FIPS 140-2 または FIPS 140-3 の Level 3 認証 HSM の専有 (シングルテナント) 利用が明示的に求められる場合、鍵の完全な排他的制御が必要な場合、PKCS#11 や JCE を使う既存アプリケーションを移行する場合、SSL/TLS オフロードを HSM で行う場合です。それ以外のケースでは、運用負荷とコストの両面で KMS が合理的です。
クラスター構成と高可用性の設計
CloudHSM はクラスター単位で管理され、1 つのクラスターに複数台の HSM を配置できます (台数の上限は AWS 公式ドキュメント参照)。高可用性を確保するには、最低 2 つの AZ にそれぞれ 1 台以上の HSM を配置します。クラスター内の HSM は自動的に鍵を同期するため、1 台の HSM が障害を起こしても他の HSM で処理を継続できます。クライアント SDK はラウンドロビンで HSM にリクエストを分散し、障害検知時は自動的に正常な HSM にフェイルオーバーします。初期セットアップでは、クラスターの初期化時に生成される Crypto Officer (CO) の認証情報を安全に保管することが極めて重要です。この認証情報を紛失すると、HSM 内の鍵にアクセスする手段がなくなります。AWS はこの認証情報を保持しないため、復旧は不可能です。バックアップは CloudHSM が自動的に取得し、暗号化された状態で S3 に保管されます。バックアップからは新しいクラスターを作成して復元でき、リージョン間の扱いや制約は AWS 公式ドキュメントで確認してください。料金は HSM 1 台ごとの稼働時間に基づく時間課金で、高可用性のための複数台構成では台数分の費用がかかります (2026 年 9 月時点 / 最新の単価は AWS 公式の料金ページを確認してください)。
SSL/TLS オフロードとデータベース暗号化の実装
CloudHSM の代表的なユースケースの 1 つが SSL/TLS オフロードです。Web サーバー (Nginx、Apache) の秘密鍵を CloudHSM に格納し、TLS ハンドシェイクの署名処理を HSM 内で実行します。秘密鍵がサーバーのメモリやディスクに存在しないため、サーバーが侵害された場合でも秘密鍵そのものの漏洩リスクを抑えられます。OpenSSL エンジンまたは PKCS#11 プロバイダーを通じて Web サーバーと統合します。Oracle TDE (Transparent Data Encryption) や Microsoft SQL Server の EKM (Extensible Key Management) と連携し、データベースの暗号化鍵を CloudHSM で管理するパターンも実務で使われています。Oracle TDE では、マスター暗号化鍵を CloudHSM に格納し、テーブルスペースの暗号化鍵はマスター鍵で暗号化してデータベース内に保管します。これにより、データベースのバックアップが流出しても、CloudHSM 内のマスター鍵なしにはデータを復号できません。KMS のカスタムキーストア機能を使えば、KMS API の利便性を維持しつつ、鍵の保管先を CloudHSM にすることも可能です。KMS API で暗号化/復号を呼び出すと、裏側で CloudHSM が暗号処理を実行する構成で、KMS の使いやすさと CloudHSM のセキュリティレベルを両立できます。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトと公式ドキュメントです。最新の仕様と料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。