AWS はじめの一歩
セキュリティ

AWS CloudHSM で実現する専用鍵管理 - FIPS 140-3 Level 3 準拠の暗号化

専有の HSM インスタンスで FIPS 140-3 Level 3 準拠の鍵管理を実現する。KMS との使い分けと、KMS カスタムキーストアによる両者の統合を紹介します。

約 5 分で読めます執筆 / 編集: あわしろ

CloudHSM の概要

CloudHSM は専用のハードウェアセキュリティモジュール (HSM) で暗号鍵を管理するサービスです。KMS がマルチテナントの共有 HSM を使用するのに対し、CloudHSM は専有の HSM インスタンスを提供します。現行世代のインスタンスタイプは hsm2m.medium で、FIPS モードのクラスターは FIPS 140-3 Level 3 の検証を受けています (証明書 #4703・2026 年 8 月時点)。旧世代 hsm1.medium が取得していた FIPS 140-2 Level 3 (証明書 #4218) は 2026 年 1 月 4 日に CMVP の historical list へ移行したため、認証水準を根拠に監査へ説明する場合は現行世代の 140-3 側を参照します。クラスターは作成時に FIPS モードと非 FIPS モードのどちらかを選び、作成後にモードを変更できません (非 FIPS モードを選べるのは hsm2m.medium のみ)。バックアップもモードをまたいで復元できないため、モードの選択は初期設計で確定させる必要があります。hsm2m.medium は 1 クラスターで最大 16,666 個の鍵を保管でき、クライアントと HSM 間の相互 TLS (mTLS) に対応します。接続には Client SDK 5 (5.9.0 以降) を使います。HSM 内で鍵が生成・保管され、鍵素材は HSM の外部に平文でエクスポートされることはありません。AWS スタッフも鍵にアクセスできない設計であり、鍵の完全な所有権はユーザーに帰属します。FIPS モードのクラスターは PCI PIN、PCI-3DS、SOC 2 の要件に対応するため、金融、医療、政府機関のコンプライアンス要件を扱う構成では FIPS モードを選びます。

KMS との使い分け

KMS は大半のユースケースに適しており、運用負荷が低く、AWS サービスとの統合が豊富です。KMS も CloudHSM の FIPS モードも FIPS 140-3 Level 3 の検証済み HSM で鍵を保護するため (2026 年 8 月時点)、「検証レベルが高いほうを選ぶ」という整理は現在は成り立ちません。選定は次の 5 つの軸で行います。第 1 は単一テナントでの専有が必要かどうかで、CloudHSM は自分だけが使う HSM を占有し、KMS は AWS が運用する共有 HSM フリートを使います。第 2 は暗号処理を直接制御する必要があるかどうかで、CloudHSM は PKCS#11、JCE、CNG/KSP、OpenSSL の標準インターフェースからアプリケーションが HSM を直接操作でき、KMS は KMS API 経由の操作に限られます。第 3 は鍵のカストディ、つまり誰が鍵素材を保持し誰が鍵の利用者を作るかで、CloudHSM では HSM ユーザーの作成も鍵のライフサイクルも利用者側の責任になり、AWS は鍵素材に触れません。第 4 はコンプライアンス固有の要件で、監査上の要求が専有ハードウェアや独自の鍵階層に及ぶ場合は CloudHSM が前提になります。第 5 は運用責任と可用性で、KMS は可用性とパッチ適用を AWS が担う一方、CloudHSM はクラスター設計、バックアップ、認証情報の管理を利用者が担います。KMS カスタムキーストアは両者の利点を組み合わせ、KMS の API と統合性を維持しながら、鍵の保管先を CloudHSM にします。スループット面では、KMS の対称鍵操作に共有のリクエストレートクォータがあり、既定は多くのリージョンで毎秒 10,000 リクエスト、東京、オハイオ、シンガポール、シドニー、フランクフルト、ロンドンで毎秒 20,000 リクエスト、バージニア北部、オレゴン、アイルランドで毎秒 100,000 リクエストです (2026 年 8 月時点の公式ドキュメント記載値)。RSA 鍵や ECC 鍵などの非対称鍵操作は別枠で毎秒 1,000 リクエスト、AWS CloudHSM キーストアと外部キーストアの鍵は毎秒 1,800 リクエストで、この 2 つは引き上げ申請ができません。CloudHSM 側の 1 台あたりの処理性能は公表されていないため、必要なスループットは自分のワークロードで実測し、HSM の台数で調整します。

クラスター設計と高可用性

CloudHSM クラスターは複数の AZ に HSM インスタンスを配置し、鍵の自動同期で高可用性を確保します。最低 2 つの AZ に HSM を配置する構成が推奨され、1 つの HSM が障害を起こしても別の AZ の HSM で処理を継続します。クライアント SDK はクラスター内の HSM にラウンドロビンでリクエストを分散し、障害時は自動的にフェイルオーバーします。HSM のバックアップは自動的に暗号化されて S3 に保存され、クラスターの復元やリージョン間のコピーに使用します。PKCS#11、JCE、OpenSSL の標準インターフェースでアプリケーションから暗号化操作を実行でき、既存のアプリケーションコードの変更を最小限に抑えられます。

代表的なユースケース

CloudHSM の主要なユースケースとして、SSL/TLS オフロード、データベース暗号化 (TDE)、コード署名とドキュメント署名、プライベート認証局 (CA) の鍵保管、金融トランザクションの署名 (PCI DSS 準拠)、トークナイゼーションがあります。SSL/TLS オフロードでは Web サーバーの秘密鍵を HSM に格納し、OpenSSL エンジン経由で署名処理を委譲することで、EC2 インスタンスのメモリから秘密鍵を排除します。Oracle TDE や Microsoft SQL Server TDE と統合し、データベースの暗号化鍵を HSM で保護する構成も一般的です。AWS Private CA と連携して CA の秘密鍵を CloudHSM に保管し、証明書発行時の署名処理を HSM で実行する構成により、CA 鍵の漏洩リスクを低減できます。

CloudHSM の料金と運用上の注意点

料金 (2026 年 8 月時点・バージニア北部 / 東京) の課金軸は HSM インスタンスの稼働時間だけで、保管する鍵の数や HSM ユーザーの数では変わりません。単価は hsm2m.medium 1 台あたりバージニア北部で 1.60 USD/時、東京で 1.81 USD/時です。1 時間未満の稼働も 1 時間として課金されます。月 730 時間換算では 1 台構成で約 1,168 USD / 約 1,321 USD、高可用性のために 2 つの AZ へ 2 台配置すると約 2,336 USD / 約 2,643 USD になります。HSM を含まない空のクラスターとバックアップの保管には料金がかからず、データ転送は別建てで課金されます。無料枠とリザーブド購入による割引はありません。KMS はカスタマー管理キー 1 個あたり月額 1 USD、リクエスト 1 万件あたり 0.03 USD が基本で、月 20,000 リクエストの無料枠もあります (GenerateDataKeyPair 系や非対称鍵の操作は無料枠の対象外)。固定費の差が大きいため、CloudHSM は専有 HSM や固有のコンプライアンス要件がある範囲に限定して使います。運用上の注意点として、Crypto Officer (CO) の認証情報を紛失するとクラスター内の鍵に永久にアクセスできなくなるため、認証情報の安全な保管が不可欠です。HSM ユーザーの管理 (CU: Crypto User、CO: Crypto Officer) は AWS IAM とは独立した仕組みであり、HSM 内部のユーザー管理コマンドで行います。クラスターの初期化は、発行した証明書を Linux なら /opt/cloudhsm/etc/ に配置して設定ファイルの名前を合わせたうえで、CloudHSM CLI (Client SDK 5) の cluster activate を実行し、初期 admin パスワードを設定して admin (CO) を有効化する流れです。その後 CO として CU を作成し、アプリケーションに鍵操作を許可します。旧世代の CloudHSM Management Utility (CMU) と Key Management Utility (KMU) は Client SDK 3 と hsm1.medium 専用のツールで、現行世代では使えません。

専用 HSM が必要になる場面

多くの暗号化の用途は、マネージドな鍵管理サービスで十分に対応できます。それでも専用の HSM が必要になるのは、特定の要件がある場合です。規制やコンプライアンスで、定められた認証水準を満たす専用のハードウェアでの鍵管理が求められるケースが代表的です。また、鍵を自社が完全に占有・管理し、クラウド事業者を含む第三者が一切触れられない状態を保証したい場合にも、専用 HSM が選択肢になります。独自の暗号処理や、特定の業界標準への準拠が必要な場面もあります。こうした厳格な要件がある部分に絞って専用 HSM を使い、それ以外は managed なサービスで賄う、という使い分けが現実的です。

まとめ

CloudHSM は専有のハードウェアセキュリティモジュールで暗号鍵を管理し、FIPS 140-3 Level 3 の検証を前提にした厳格なコンプライアンス要件に対応するサービスです。KMS カスタムキーストアで KMS API から CloudHSM の鍵を操作でき、PKCS#11 や JCE の標準インターフェースで既存アプリケーションとの統合も容易です。固定費が高いため、専有性や鍵カストディの要件が明確な範囲に限定して採用し、認証情報管理と高可用性設計を慎重に計画することが重要です。

参考資料 (AWS 公式)

本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。

本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。

関連するサービス

AWS CloudHSM 専門専用のハードウェアセキュリティモジュールで暗号鍵を管理するサービスAWS KMS 定番データの暗号化に使う鍵を安全に作成・管理できるマネージド暗号鍵サービスAWS Private Certificate Authority 専門プライベート証明書の発行・管理を行うマネージド認証局サービス

関連する記事

AWS Private CA で構築するプライベート PKI - 証明書の自動発行とローテーションプライベート認証局を構築し、内部サービス間の mTLS 証明書を自動発行する。証明書のライフサイクル管理と CRL の設計を紹介します。AWS Nitro Enclaves で実現する機密データ処理 - 隔離環境での暗号化と認証Nitro Enclaves の隔離環境で機密データを処理し、KMS との統合とアテステーションで暗号鍵のアクセスを制御する手法を紹介します。AWS Payment Cryptography で実現するクラウド決済処理 - 暗号鍵管理と PIN 検証Payment Cryptography による決済用暗号鍵の管理、PIN ブロックの暗号化・復号、PCI DSS 準拠を解説します。

同じテーマの記事

IAM Access Analyzer で検出する過剰なアクセス権限 - 外部アクセスと未使用権限の分析IAM ロールの未使用権限を CloudTrail ベースで検出し、最小権限ポリシーを自動生成する。外部アクセスの検出と CI/CD へのカスタムポリシーチェック組み込みまでを解説します。AWS Certificate Manager で自動化する SSL/TLS 証明書管理 - 発行からローテーションまでACM によるパブリック証明書の無料発行、DNS 検証、自動更新、ALB ・ CloudFront へのデプロイを解説します。AWS Artifact でコンプライアンスレポートを取得 - 監査対応と契約管理SOC・PCI DSS・ISO の監査レポートをオンデマンドで取得し、BAA や GDPR DPA を Organizations 全体に一括適用する手順を紹介します。監査の自動化 - AWS Audit Manager でコンプライアンス証跡を継続的に収集するAWS Audit Manager を使った監査証跡の自動収集を解説。フレームワーク (SOC 2、PCI DSS、GDPR 等) に基づく自動評価、エビデンスの一元管理、監査レポートの生成を紹介します。AWS アカウント ID の 12 桁に隠された構造 - なぜ 12 桁なのか、何が読み取れるのかAWS アカウント ID が 12 桁の数字である理由、ARN の構造に埋め込まれた設計意図、アカウント ID から推測できる情報とセキュリティ上の注意点を雑学的に解説します。AWS アカウントのルートユーザーはなぜ危険なのか - 権限分離の設計思想と封印の実践AWS ルートユーザーが IAM では制限できない特権を持つ理由、ルートユーザーでしかできない操作の一覧、MFA の設定方法、Organizations のルートアクセス管理による封印戦略を解説します。証明書管理と HTTPS 化 - AWS Certificate Manager による TLS 証明書の自動運用AWS Certificate Manager (ACM) を使った TLS/SSL 証明書の発行・自動更新・デプロイを解説。CloudFront ・ ALB ・ API Gateway との統合、DNS 検証、プライベート CA の活用まで紹介します。CloudTrail はすべてを見ている - API 呼び出しの記録メカニズムとフォレンジック調査の実践CloudTrail が AWS API 呼び出しを記録する仕組み、管理イベントとデータイベントの違い、CloudTrail Lake による SQL 分析、セキュリティインシデント発生時のフォレンジック調査手法を解説します。

内容が近い記事 / サービス

ハードウェアセキュリティモジュール - AWS CloudHSM による暗号鍵の専有管理AWS CloudHSM による暗号鍵の専有管理を解説。単一テナント HSM の占有、PKCS#11 や JCE による直接制御、鍵カストディ、KMS との選定軸、hsm2m.medium 世代への移行、TLS オフロードや Oracle TDE 統合を紹介します。AWS CloudHSMFIPS 140-2 Level 3 認証済みのハードウェアセキュリティモジュールを専有利用し、暗号鍵の生成・保管・暗号処理をクラウド上で実行するサービスAWS の暗号化とデータ主権 - KMS から Nitro Enclaves までハードウェアレベルの分離を実現AWS KMS、CloudHSM、Nitro Enclaves によるハードウェアレベルの暗号化とデータ主権の確保を解説し、他社クラウドとの設計差異を比較します。KMS の暗号鍵はどこに保存されているのか - エンベロープ暗号化と HSM の仕組みKMS のマスターキーが FIPS 140-2 認定の HSM 内に保存される仕組み、エンベロープ暗号化でデータキーを二重に保護する設計、キーローテーションの内部動作を解説します。