ハードウェアセキュリティモジュール - AWS CloudHSM による暗号鍵の専有管理
AWS CloudHSM による暗号鍵の専有管理を解説。単一テナント HSM の占有、PKCS#11 や JCE による直接制御、鍵カストディ、KMS との選定軸、hsm2m.medium 世代への移行、TLS オフロードや Oracle TDE 統合を紹介します。
暗号鍵管理の要件と CloudHSM の位置づけ
暗号鍵の管理は情報セキュリティの根幹です。AWS で鍵素材をハードウェアに閉じ込める選択肢には AWS KMS (Key Management Service) と AWS CloudHSM の 2 つがあり、2026 年 8 月時点では KMS も CloudHSM の FIPS モードの現行世代も FIPS 140-3 Level 3 の検証を受けた HSM (Hardware Security Module) の上で鍵素材を扱います。KMS は FIPS 140-3 Security Level 3 検証済みの HSM 群で鍵を保護し、平文の鍵素材が HSM の境界外に出ることも、ディスクに書き出されることもありません。CloudHSM の FIPS モードクラスターも、後述する hsm2m.medium 世代で FIPS 140-3 Level 3 の検証を取得しています。したがって「検証レベルが高いほうを選ぶ」という以前の整理は、現在の選定判断には使えません。 現在の違いは、鍵専用ハードウェアを占有するかどうか、鍵をどこまで自分の手で直接制御するか、そして鍵のカストディ (管理主体) を誰が持つかにあります。CloudHSM が提供するのは単一テナントの汎用 HSM で、クラスター内の鍵の生成・保存・使用はすべて HSM 内部で完結します。ユーザーとロールの管理は IAM の外側にある HSM 自身の認証基盤で行うため、その分だけ利用者が負う責任範囲も広がります。AWS はハードウェアのプロビジョニング、パッチ適用、暗号化バックアップの保管を担いますが、HSM 内の鍵にはアクセスできず、データプレーンの通信内容も AWS からは見えません。一方の KMS はマルチテナントのマネージドサービスで、鍵の作成やローテーション、可用性の確保をサービス側が引き受けます。コンプライアンス要件や社内ポリシーが「鍵専用ハードウェアの占有」や「鍵素材の所在と管理主体の明示」を求める場合に、CloudHSM が候補になります。
hsm2m.medium 世代への移行と FIPS 検証の現況
CloudHSM の HSM タイプは世代交代の途中にあります。以下は 2026 年 8 月時点の状況です。新世代の hsm2m.medium は 2024 年 8 月 20 日に一般提供が開始され、旧世代の hsm1.medium は 2025 年 4 月以降どのリージョンでも新規クラスターを作成できなくなりました。2026 年 1 月からは CloudHSM 側による自動移行が始まっており、hsm1.medium のサポート終了日は 2026 年 3 月 31 日として告知されています。FIPS 検証も世代で分かれます。hsm1.medium は FIPS 140-2 Level 3 の証明書 #4218 で検証されていましたが、2026 年 1 月 4 日に CMVP の historical リストへ移動しました。hsm2m.medium は FIPS 140-3 Level 3 の証明書 #4703 で検証されています。 hsm2m.medium では設計も変わりました。クラスター作成時に FIPS モードと非 FIPS モードを選択でき、この設定は作成後に変更できません。鍵容量はクラスター合計で 16,666 個、うち非対称鍵は最大 3,333 個までを保管できます。クライアントと HSM の間は相互 TLS で認証され、利用には Client SDK 5.9.0 以降が必要です。移行経路は 2 つ用意されています。CloudHSM が管理する移行にオプトインして既存クラスターを世代交代させる方法と、hsm1.medium のバックアップから hsm2m.medium のクラスターを新規に作成し、切り替えてから旧クラスターを削除する方法です。前者を選ぶ場合は、直近 7 日間のすべての接続が Client SDK 5.9 以上 (ECDSA の Verify を実行している場合は 5.13 以上) であること、クラスターが ACTIVE であること、HSM が 27 台以下であることが前提条件として求められます。なお、バックアップは FIPS モードと非 FIPS モードをまたいで復元できません。世代については hsm1.medium のバックアップを FIPS モードの hsm2m.medium クラスターへ復元する一方向だけが可能で、hsm2m.medium のバックアップを hsm1.medium クラスターへ戻すことはできません。したがって、非 FIPS モードで運用してきたクラスターを FIPS モードへ差し替えるといった経路は取れません。
クラスター構成と標準 API
CloudHSM はクラスター単位で管理します。クラスターを作成するときに自分の AWS アカウントの VPC とサブネットを指定し、HSM を 1 台追加するたびに、CloudHSM が指定したサブネットへ ENI (Elastic Network Interface) を配置します。HSM の実体は CloudHSM が所有する別の VPC の中にあり、アプリケーションはこの ENI を経由して HSM と通信します。「HSM が自分の VPC 内に置かれる」と説明されることがありますが、正確には自分のサブネットに現れるのはネットワークインターフェイスだけです。HSM と対応する ENI は同じ AZ に配置されるため、AZ ごとにサブネットを 1 つ用意し、2 つ以上の AZ に HSM を分散させる構成が推奨されます。クラスター内の HSM 間では鍵が自動的に同期されるため、1 台の HSM が失われても残りの HSM で鍵を使い続けられます。 アプリケーション側は Client SDK 5 を導入して HSM を利用します。PKCS#11 ライブラリは PKCS#11 バージョン 2.40 に準拠しており、C/C++ のアプリケーションや HSM 対応のミドルウェアから鍵を扱えます。Java 向けには JCE (Java Cryptography Extension) のプロバイダーフレームワーク上に構築されたプロバイダーが提供され、Java アプリケーションから HSM 上の鍵を操作できます。Windows 向けには CNG プロバイダーと KSP (Key Storage Provider) が提供され、OpenSSL 経由の利用には OpenSSL Dynamic Engine と OpenSSL Provider が用意されています。いずれも業界標準のインターフェイスであるため、既存アプリケーションの改修は接続設定と鍵の指定に留まることが多く、暗号処理のコードを書き直す必要はほとんどありません。クライアントソフトウェアは VPC 内の EC2 インスタンスに導入するのが一般的ですが、HSM の ENI に到達できる環境であれば EC2 である必要はありません。クラスター作成時に生成されるセキュリティグループを使って、クライアントから HSM への通信を許可します。
KMS との使い分け - 5 つの選定軸
FIPS の検証レベルで両者を振り分けられなくなった現在、選定は次の 5 つの軸で判断します。 第 1 の軸は単一テナント占有です。CloudHSM は自分専用の HSM を時間単位で占有し、そのハードウェア上の鍵は自分のクラスターにしか存在しません。KMS は AWS が運用するマルチテナントの HSM フリートを共有します。第 2 の軸は直接制御です。PKCS#11 や JCE、CNG/KSP、OpenSSL を通じて HSM のメカニズムを直接呼び出す必要がある場合、あるいは既存のミドルウェアが HSM 接続を前提に設計されている場合は CloudHSM が適します。KMS の操作は KMS の API と各 AWS サービスとの統合を通じて行います。 第 3 の軸は鍵カストディです。CloudHSM ではユーザーとロールを自分で作成し、バックアップの取得や復元も自分の運用として設計します。KMS の標準キーストアでは、鍵素材の保管と冗長化を AWS が引き受けます。両者の中間として、KMS にはキーストアの選択肢が 3 種類あります。現行ドキュメントの呼称では、通常の「標準キーストア」に加えて、鍵素材を自分の CloudHSM クラスターに置きながら操作は KMS の API で行う「AWS CloudHSM キーストア」と、AWS の外部にある鍵管理基盤に鍵素材を置く「外部キーストア」があります。S3 や EBS、RDS といった AWS サービスのサーバー側暗号化と自前の HSM を組み合わせたい場合は、この AWS CloudHSM キーストアを経由するのが標準的な経路になります。 第 4 の軸はコンプライアンス固有要件です。要件が「FIPS 140-3 Level 3 の検証済みモジュール」だけを指しているなら、KMS 単体でも満たせます。差が出るのは、要件が単一テナント性や鍵の物理的な占有、特定の監査スキームでの HSM 運用を指定している場合です。CloudHSM の FIPS モードのクラスターは PCI PIN、PCI-3DS、SOC2 の要件充足に利用できると案内されています。また KMS では中国リージョンの HSM が OSCCA の認証であり CMVP の検証ではないなど、地域によって前提が変わる点も確認が必要です。 第 5 の軸は運用責任と可用性の担保です。KMS では可用性、パッチ適用、スケールをサービス側が担います。CloudHSM では HSM の台数設計、AZ 分散、バックアップからの復元手順、そして Client SDK と HSM 世代の追随を利用者が担います。料金構造も後述のとおり大きく異なるため、この 5 軸に照らして「占有と直接制御が本当に要件なのか」を確認してから CloudHSM を選ぶことが実務的な順序です。
TLS オフロードとデータベース暗号化
CloudHSM の代表的なユースケースが TLS/SSL オフロードです。Web サーバー (Nginx、Apache) の TLS 秘密鍵を CloudHSM 内に保持し、TLS ハンドシェイク時の秘密鍵操作を HSM 内で実行します。秘密鍵がサーバーのメモリやディスクに展開されないため、サーバーが侵害されても秘密鍵そのものが持ち出されるリスクを避けられます。Nginx や Apache では OpenSSL Dynamic Engine として CloudHSM を設定する構成が公式に案内されており、Java の Tomcat では JSSE 経由での TLS オフロード手順が用意されています。 データベース暗号化では、Oracle TDE (Transparent Data Encryption) のマスター暗号鍵を CloudHSM で管理できます。Oracle Database 側の設定で PKCS#11 ライブラリとして CloudHSM クライアントを指定することで、データベースの暗号化鍵が HSM の内部で保護されます。このほか、Windows Server を認証局として構成し、CA の秘密鍵を HSM に保持する使い方にも公式の設定手順が用意されています。いずれのケースも、鍵を HSM から出さないという性質が価値の中心にあり、アプリケーション側は標準 API を通じて鍵を参照するだけで済みます。
CloudHSM の料金
ここに示す単価は 2026 年 8 月時点のバージニア北部リージョンと東京リージョンの値で、月額は 1 か月を 730 時間として換算しています。 まず課金の軸を整理します。CloudHSM の課金対象は、クラスターにプロビジョニングされている HSM の稼働時間だけです。1 時間に満たない端数も 1 時間分として課金され、単価はリージョンによって異なります。ユーザー数や保管している鍵の数では単価は変わりません。これに加えて、HSM との間のネットワークデータ転送は通常のデータ転送料金として別建てで課金されます。逆に、HSM が 1 台も入っていないクラスターと、CloudHSM が自動で取得する暗号化バックアップの保管には料金がかかりません。 単価は hsm2m.medium 1 台あたり、バージニア北部で 1 時間 1.60 USD、東京で 1 時間 1.81 USD です。730 時間換算では 1 台あたりバージニア北部が約 1,168 USD、東京が約 1,321 USD になります。高可用性のために 2 つの AZ へ 1 台ずつ配置する構成では、バージニア北部で月額約 2,336 USD、東京で月額約 2,643 USD です。リージョンによって単価が違うため、見積もりでは対象リージョンの値を個別に確認してください。 最小課金と無料枠については、CloudHSM に無料利用枠はなく、リザーブドインスタンスのような前払い割引も提供されていません。一方で、検証用のクラスターなど常時稼働が不要な用途では、使わない期間に HSM を 0 台まで減らし、バックアップから復元して再開する運用がコスト対策として案内されています。KMS 側の料金は鍵 1 個あたり月 1 USD (時間単位で按分) と、リクエスト 1 万件あたり 0.03 USD が基本で、月 20,000 リクエストの無料枠が全リージョン合算で適用されます。ただし GenerateDataKeyPair と GenerateDataKeyPairWithoutPlaintext、および非対称鍵に対する Sign、Verify、Encrypt、Decrypt、GetPublicKey は無料枠の対象外です。AWS CloudHSM キーストアを使う構成では両方の料金が積み上がります。KMS の公式料金ページに掲載されている例では、鍵 1 個と約 199 万件の課金対象リクエスト、そして 2 台の HSM を 31 日間稼働させた場合の合計が月額 2,387.77 USD となっており、このうち 2,380.80 USD が HSM の稼働料金です。専有 HSM のコストが構成全体を支配することが、この内訳から読み取れます。
専有管理に伴う運用責任
CloudHSM は、暗号鍵を完全に自社の管理下に置ける点が最大の特徴ですが、それは同時に、鍵の可用性とバックアップに対する責任も自社が負うことを意味します。マネージドな鍵管理サービスでは、鍵の冗長化やバックアップをサービス側が引き受けますが、専有する HSM では、その設計を自分たちで行う必要があります。鍵を失えば、暗号化したデータを復号できなくなるため、クラスターを複数の AZ に冗長配置し、鍵を安全にバックアップする運用が不可欠です。 責任範囲は鍵の可用性だけではありません。HSM 上のユーザーとロールは IAM の外側で管理するため、認証情報の発行と失効、権限の棚卸しも自前の手順として整備する必要があります。バックアップは FIPS モードと非 FIPS モードをまたいで復元できず、世代も hsm1.medium から hsm2m.medium への一方向に限られるという制約があるため、災害復旧の手順は現在使っている世代とモードを前提に書いておかなければなりません。さらに、hsm1.medium から hsm2m.medium への移行のように、HSM 世代と Client SDK のバージョンに追随する作業も定期的に発生します。完全な制御を得る代わりに、それを維持する責任が生じます。専有管理を選ぶ際は、この運用負担を引き受ける体制があるかを見極めることが重要です。
まとめ - CloudHSM の活用指針
AWS CloudHSM は、暗号鍵を単一テナントのハードウェアで占有管理したい場合に選ぶサービスです。KMS も CloudHSM も FIPS 140-3 Level 3 の検証を受けた HSM を使う世代へ移行しているため、検証レベルの高低で選ぶ判断はすでに成り立ちません。判断軸は、ハードウェアの占有、PKCS#11 や JCE などによる直接制御、鍵カストディの所在、コンプライアンス要件が単一テナント性まで指定しているか、そして運用責任を引き受けられるか、の 5 点です。鍵素材を自分のクラスターに置きつつ AWS サービスとの統合を保ちたい場合は、KMS の AWS CloudHSM キーストアという中間解も検討できます。HSM タイプは hsm2m.medium が現行世代であり、hsm1.medium は 2026 年 3 月 31 日にサポートを終了する告知が出ているため、既存クラスターを運用している場合は移行状況の確認が先に立ちます。料金は 2 台構成で月額約 2,336 USD (バージニア北部) から約 2,643 USD (東京) と相応の水準になるため、上記の 5 軸に照らして要件を確認した上で導入を判断することを推奨します (2026 年 8 月時点)。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。