AWS CloudHSM本番運用Vol1｜hsm2m移行とKMS連携

1. 専有HSMが必要になる瞬間 — CloudHSM全体像とKMSとの使い分け

クラウド環境での暗号鍵管理において、鍵そのものの所有権と最高水準のコンプライアンス保証が求められる場面では、マネージド型のAWS KMSだけでは要件を満たせないことがあります。金融機関のPCI PINコンプライアンス、医療機関のHIPAAにおける高保証要件、政府機関のFIPS 140-3 Level 3要件など、「AWSを含む第三者が鍵に一切触れられないこと」が絶対条件となるケースが存在します。

AWS CloudHSMは、こうした要件を満たすべく設計された顧客専有・単一テナントのハードウェアセキュリティモジュール（HSM）サービスです。クラウドの柔軟性を保ちながら、鍵の所有権と制御をお客様が完全に握ることができます。本セクションでは、専有HSMが必要になる本番課題を整理したうえで、CloudHSMの全体像・KMSとの棲み分け・本記事の構成を説明します。

1-1. 専有HSMが必要になる本番課題

AWSでの暗号鍵管理の選択肢として、マネージド型のKMSが広く利用されています。しかし規制要件・鍵所有権要件・コンプライアンスレベルによっては、CloudHSMが唯一の現実的な選択肢となる場面があります。

FIPS 140-3 Level 3コンプライアンス要件

FIPS 140-3は、米国国立標準技術研究所（NIST）が策定した暗号モジュールのセキュリティ要件です。Level 1〜4の認定レベルがあり、Level 3では物理的な改ざん検知・対抗機能と、ロールベースの認証が要求されます。さらに、鍵が暗号化された形でしか外部に出ないことの保証、環境的な攻撃（温度・電圧の異常）に対するゼロ化機能も要件となります。

AWS KMSのカスタマーマネージドキーはFIPS 140-2 Level 2相当の認定を持ちますが、Level 3の認定はありません。CloudHSMのhsm2m.mediumはFIPS 140-3 Level 3の認定を取得しており（Certificate #4703）、最高水準のコンプライアンスが求められる環境で採用が進んでいます。

規制対象業界でFIPS 140-3 Level 3が要求される具体的な場面を以下に示します。

• PCI DSS / PCI PIN: PIN暗号化に使用するHSMはFIPS 140-3 Level 3以上が必須
• 国内金融庁ガイドライン: 同水準を要求するケースがある
• 米国政府機関向けFedRAMP High: HSMによる鍵保護を推奨
• NERC CIP（電力インフラ）: 重要システムの暗号化基盤にHSMを要求
• 医療機関のHIPAA高保証環境: 患者データ暗号化に専有HSMを採用

鍵の所有権要件（AWSも鍵に非接触）

AWS KMSはAWSが鍵マテリアルを管理するため、責任共有モデルの下ではAWSのインフラストラクチャがその保護を担います。これ自体は高セキュリティな設計ですが、「AWSを含む第三者が一切鍵に接触できないことを技術的に保証・証明したい」という要件には対応できません。

CloudHSMでは、お客様がCrypto Officer（CO）とCrypto User（CU）の権限体系を構築し、鍵の生成・使用・削除をすべてお客様の権限下に置きます。AWSはHSMのハードウェアを管理しますが、鍵マテリアル自体には一切アクセスできません。これは契約上の制約だけでなく、技術的な仕組みとして保証されており、AWS担当者がHSMに接続して鍵を取得する手段は存在しません。

決済・PKIルート鍵・Oracle TDE用途

PCI PINコンプライアンスでは、PIN暗号化キーの管理にFIPS 140-3準拠のHSMが要求されます。CloudHSMはPKCS#11インターフェースを通じた決済端末との連携や、PINブロック生成・変換に対応しています。決済基盤では、HSMの鍵がソフトウェアに一切エクスポートされないことが監査要件を満たすうえで重要です。

プライベートCAのルート鍵をHSMで保護することで、ルート鍵の流出リスクを最小化できます。オンプレミスのルートHSMとCloudHSMを組み合わせたオフラインルートCA設計も可能です。Oracle Database TDE（Transparent Data Encryption）のマスター鍵をCloudHSMに保管するパターンも、規制対象データベース環境で広く採用されています。

★今まさに本番課題: hsm1.medium EOL 2026-03-31

hsm1.mediumインスタンスタイプは、2026年3月31日にサポート終了（EOL）を迎えました。hsm1.mediumはFIPS 140-2 Level 3の認定を持つ旧世代のHSMで、EOL後はAWSによるサポートが提供されません。現時点でhsm1.mediumを使用中の環境では、hsm2m.mediumへの移行が急務の本番課題になっています。FIPS承認アルゴリズムリストへの掲載もEOLスケジュールに影響するため、コンプライアンス監査時に認定状況を確認しておくことが重要です。

hsm2m.mediumへの移行は、クラスター内にhsm2mインスタンスを追加し、鍵を自動同期してからhsm1を削除するという段階的なアプローチで、ダウンタイムを最小化できます。移行の詳しい手順は§4で解説します。

1-2. CloudHSMの概念と構成要素

CloudHSMを本番環境に導入するには、「クラスター」「HSMインスタンス」「クライアントSDK」の3つの概念を正確に理解することが重要です。

クラスターとHSMインスタンス

CloudHSMの基本単位は「クラスター」です。クラスターは複数のHSMインスタンスを束ねた論理的なグループで、クラスター内の鍵は全HSMインスタンス間で自動的に同期されます。アプリケーションはクラスター単位で接続し、クラスター内のどのHSMに接続しても同一の鍵セットを利用できます。

HSMインスタンスは、VPC内の特定のアベイラビリティゾーン（AZ）に配置されるハードウェアHSMデバイスです。本番環境では複数AZにHSMインスタンスを分散配置することで高可用性を確保します。クラスターへのHSMインスタンスの追加・削除は稼働中に実施でき、スケールアップ・ダウン時にアプリケーションのダウンタイムは発生しません。

単一テナント・顧客専有の意味

CloudHSMは「単一テナント」です。お客様のHSMインスタンスは他のAWSお客様と物理的に共有されません。これはマルチテナントのKMSとの本質的な違いであり、「他テナントとリソースを物理共有している状態が規制上・契約上許容できない」という要件に対応します。

HSMの初期化から権限設定まで、すべての設定はお客様が行います。AWSが事前に設定することはなく、未初期化のHSMを受け取りCO/CUの権限体系を一から構築します。このプロセスが「鍵の所有権がお客様にある」ことの技術的な根拠となります。

CloudHSMクライアントSDKの役割

アプリケーションからHSMの鍵を利用するには、CloudHSMクライアントSDKが必要です。SDKはVPC内の各EC2インスタンスにインストールし、標準的な暗号APIインターフェースでHSMに接続します。クライアントSDKはクラスター内のHSMインスタンスにロードバランスしながら接続し、HSMインスタンスの増減を意識することなくアプリケーションを動作させられます。ローカルキャッシュ機構によりHSMへのラウンドトリップを削減し、パフォーマンスを向上させることも可能です。各SDKの詳細な統合方法は§5で解説します。

1-3. KMSとCloudHSMの使い分け

KMSとCloudHSMはどちらも暗号鍵管理サービスですが、目的・コスト・運用負荷が大きく異なります。適切な使い分けが本番設計において重要です。

KMS Custom Key Storeという折衷案

KMSのAPIをそのまま使いながら、鍵のマテリアルをCloudHSMに保管する「KMS Custom Key Store」という選択肢もあります。AWSサービス（S3/RDS/EBSなど）との既存KMS統合を変えずに、鍵の所有権をCloudHSMに移せます。ただし、クラスターの管理コストとCO/CU管理の運用負荷は依然として発生するため、費用対効果を検討したうえで採用を判断します。KMS Custom Key Storeの詳細は§5で解説します。

本記事の対象読者

KMSは導入済みで、規制・監査・PKIルート鍵保護において「鍵をAWSにも触れさせない」要件に直面した本番運用エンジニアおよびセキュリティアーキテクトを主な対象読者としています。AWSアカウントの基本操作やVPC・サブネットの概念は既知として解説を進めます。

CloudHSM導入の判断フロー

専有HSMの導入検討時に役立つ判断基準を以下に示します。

1. FIPS 140-3 Level 3が必須か? → YES ならCloudHSM一択。KMSはLevel 3未対応
2. 鍵の所有権をAWSから完全に分離する必要があるか? → YES ならCloudHSM。KMSはAWSの責任共有モデル
3. PKIルート鍵・決済暗号・Oracle TDE用途か? → YES ならCloudHSMが実績あり
4. 既存のKMS統合を維持しつつ鍵を専有したい? → KMS Custom Key Storeで折衷案
5. 上記すべてNO? → KMSで十分。CloudHSMのコスト（$1,152/月〜）は不要

この判断フローに沿って確認し、CloudHSMが必要な場面に限定して導入することでコストを最適化できます。

本記事では、クラスター設計（§2）・セットアップ運用（§3）・hsm1移行（§4）・アプリ統合（§5）・セキュリティ設計（§6）・実戦パターン（§7）を体系的に解説します。

2. CloudHSM基礎 — クラスター × HSMインスタンス × マルチAZ可用性

CloudHSMは、複数のHSMインスタンスを束ねた「クラスター」を基本単位として運用します。本セクションでは、クラスターとHSMインスタンスの関係、マルチAZによる可用性設計、hsm2m.mediumのFIPS 140-3 Level 3準拠について解説します。

2-1. クラスターとHSMインスタンスの関係

AWS CloudHSMでは「クラスター」が基本的な運用単位です。クラスターは複数のHSMインスタンスを論理的にグループ化した構成で、クラスター内のすべてのHSMインスタンスが同じ暗号鍵を自動的に同期します。どのHSMインスタンスに接続しても同一の鍵操作が可能なため、アプリケーション側で同期ロジックを実装する必要はありません。

HSMインスタンスの実体

各HSMインスタンスは、顧客のVPC内の指定したサブネットにElastic Network Interface（ENI）として接続された物理的なハードウェアセキュリティモジュールです。HSM自体はAWSが管理するセキュアな物理施設に収容されていますが、VPC内のENI経由で接続するため、プライベートネットワークのセキュリティモデルを維持できます。

HSMインスタンスの主な特性は以下の通りです。

• 単一テナント: 各HSMインスタンスは1つのAWSアカウントのみに割り当てられ、他のアカウントと共有されません
• 顧客専有: HSMのファームウェアやハードウェアの管理はAWSが行いますが、HSM内部に保存される鍵にはAWSもアクセスできません
• ENI経由接続: アプリケーションサーバーはVPC内のプライベートIPを使ってHSMのENIに接続します
• 専用ハードウェア: 物理的なHSMモジュール自体が顧客に専有されるため、鍵の保護に最高水準の保証が得られます

クラスター内の鍵同期メカニズム

クラスターを初期化した後にHSMを追加すると、既存のHSMから新しいHSMへ暗号鍵が自動的に同期されます。この同期はCloudHSMのインフラ層（クラスターメンバー間の専用通信チャネル）で行われ、アプリケーション側での実装は不要です。

重要な手順として、クラスターの初期化前にHSMを複数追加しても同期は始まりません。正しい手順は次の通りです。

1. 最初の1台のHSMをプライベートサブネットに追加（AZ-a）
2. そのHSMを使ってクラスターを初期化（CSR署名・Crypto Officer設定）
3. 初期化が完了したクラスターに追加のHSMを別のAZに投入
4. 追加されたHSMへ自動的に鍵データが転送されて同期が完了

クライアントSDKによる接続と負荷分散

アプリケーションはCloudHSMクライアントSDKを使ってクラスター内の各HSMに接続します。現在の推奨バージョンはSDK 5で、以前のSDK 3よりもパフォーマンスと安定性が向上しています。

クライアントSDKが提供する主な機能は以下の通りです。

• クラスター内の複数HSMへのラウンドロビンまたは重み付きロードバランシング
• 障害が発生したHSMへのリクエストを他のHSMへ自動フェイルオーバー
• PKCS#11・JCE・OpenSSL Dynamic Engineなどの標準暗号APIへの変換レイヤー
• TLS相互認証によるHSMとクライアント間の通信保護

クラスターIDと分離の保証

各クラスターは一意のクラスターIDを持ち、他のクラスターやAWSアカウントから完全に分離されています。クラスター内の鍵はAWSの管理者を含む第三者がアクセスできない構造になっており、暗号鍵の所有権は完全に顧客が保持します。これが「AWSも鍵に触れない」という最高水準のコンプライアンス要件を満たすための基盤です。

クラスターのライフサイクル

クラスターの作成から廃棄までのライフサイクルを整理します。

1. クラスター作成: リージョン・VPCを指定して空のクラスターを作成
2. 最初のHSMインスタンスをプライベートサブネットに追加（AZ-a）
3. クラスター初期化: CSR（証明書署名要求）を発行し、顧客CAで署名してクラスターを初期化
4. Crypto Officer（CO）の初期化: CloudHSM CLIでCOを設定
5. 追加のHSMを別のAZのサブネットに追加（マルチAZ化）
6. クライアントSDKをアプリケーションサーバーに設定して接続テスト
7. 廃棄時: バックアップを別リージョンにコピーしてからHSMとクラスターを削除

廃棄時の注意点として、クラスターを削除するとクラスター内の鍵データも削除されます。廃棄前に必ずバックアップを確認し、長期保存が必要な鍵はエクスポート・アーカイブを行ってください。

2-2. マルチAZ可用性設計

本番CloudHSM運用において、マルチAZ構成は可用性保証の基本要件です。シングルAZ構成ではAZ障害時に鍵操作が完全に停止するため、SLA要件を持つシステムでは複数AZへの分散配置が必須となります。

基本方針: 各AZに最低1台

複数のアベイラビリティゾーン（AZ）にHSMインスタンスを分散配置します。一般的な本番構成では、最低2つのAZ（推奨は3つ）にそれぞれ1台以上のHSMを置きます。

（HSMインスタンス料金は1.60 USD/時間程度の目安。実際の料金はAWSコンソールで確認してください）

サブネット選択による配置制御

HSMを追加する際は、配置先のサブネットを指定します。異なるAZのプライベートサブネットを選ぶことで、HSMをAZ間に分散させられます。各サブネットのルートテーブルにインターネットゲートウェイへのルーティングは不要で、アプリケーションサーバーと同じプライベートVPC内に収めます。

単一AZ障害時の挙動

2台以上のHSMが異なるAZに存在する場合、単一AZが障害になっても残りのHSMが稼働し続けます。クライアントSDKは生存中のHSMへ自動フェイルオーバーし、アプリケーションの鍵操作は継続できます。

フェイルオーバー完了までの数秒間は、一時的なタイムアウトが発生します。タイムアウト値はクライアントSDKの設定ファイルで調整可能で、業務クリティカルなシステムでは短めの設定にして早期フェイルオーバーを優先させることが推奨されます。

クォーラム認証の考慮

クラスター内のHSM数と可用性の要件に応じて、クォーラム認証（M of N）の設計も必要です。例えばHSMが3台であれば「3台中2台の合意」を要求するクォーラムを設定でき、単一HSMの不正操作に対する耐性が高まります。クォーラム数が多いほど安全性が上がる一方、可用性とのトレードオフが生じるため、HSM台数と障害シナリオを考慮して適切な値を設計します。

HAコスト倍増への注意

CloudHSMはHSMインスタンス1台ごとに時間単位の料金が発生します。マルチAZ構成にすることで台数が増え、コストも比例して増加します。KMSの月額数百円〜数千円と比較すると大幅に高くなるため、CloudHSMを導入すべきケースを慎重に判断することが重要です。CloudHSMが真に必要なのは、規制要件でFIPS 140-3 Level 3の専有HSMが求められる場合や、PKIルート鍵の保護など鍵の所有権が最優先の場合に限られます。

2-3. hsm2m.medium と FIPS 140-3 Level 3

現在の本番ワークロード向け推奨インスタンスタイプはhsm2m.mediumです。旧世代のhsm1.mediumはEOLを迎えるため、早急な移行が必要です。

hsm2m.mediumの仕様

hsm2m.mediumの主な仕様は以下の通りです。

• FIPS 140-3 Level 3準拠（Cryptographic Module Validation Program Certificate #4703）
• 2025年12月のファームウェア更新によりログイン遅延とfindkey操作のパフォーマンスが大幅に改善
• FIPSモードと非FIPSモードの両方で動作可能（ユースケースに応じて選択）
• 2024年以降に新規作成したクラスターはhsm2m.mediumのみ選択可能なリージョンが多い

FIPS 140-3 Level 3の意義

FIPS 140-3 Level 3は、HSMの物理的なタンパー耐性と鍵のハードウェア隔離を要求する最高水準の認証です。金融機関・政府機関・医療機関などの規制業界で「鍵をソフトウェアレイヤーに展開しない」という監査要件を満たすために利用されます。Level 3では物理的な改ざん検出・応答（Tamper Detection and Response）が必要とされ、HSMが物理攻撃を受けた際に自動的に鍵データを消去する機能を持ちます。

以下はFIPS 140-3のレベル比較です。

hsm1.medium: EOL 2026-03-31 — 早急な移行が必要

旧世代のhsm1.mediumは、2026年3月31日にサポート終了（EOL）を迎えます。また2026年1月4日にFIPS認証リストからも外れる予定であり、コンプライアンス観点からも継続使用は困難となります。

現在hsm1.mediumを使用しているワークロードは、早急にhsm2m.mediumへの移行を計画してください。移行は既存クラスターのダウンタイムを最小化しながら実施できます（詳細な移行手順は§4で解説します）。

非FIPSモードの活用

hsm2m.mediumはFIPSモードと非FIPSモードの両方で動作可能です。非FIPSモードでは、FIPS 140-3で承認されていないアルゴリズム（楕円曲線暗号の一部など）も使用できます。規制要件でFIPSモードが必須でない場合は、非FIPSモードの選択肢も検討できます。

2-4. VPCとの統合 — プライベートサブネットとセキュリティグループ設計

CloudHSMをVPCに安全に統合するための設計ポイントをまとめます。

プライベートサブネット配置

HSMインスタンスはパブリックサブネットではなくプライベートサブネットに配置します。インターネットゲートウェイへのルーティングは不要で、アプリケーションサーバーと同じVPC内のプライベートアドレス空間に収めます。異なるVPC（例: 共有セキュリティサービスVPC）にCloudHSMを集約する場合は、VPCピアリングまたはAWS PrivateLinkを使って接続します。

セキュリティグループ設計

CloudHSMのENIに適用するセキュリティグループのインバウンドルールでは、クライアントSDKが使用するポートをアプリケーションサーバーのセキュリティグループからのみ許可します。

不要なソースIPや広すぎるCIDR範囲を許可しないことが重要です。ゼロトラスト観点から、接続元はアプリケーションサーバーのセキュリティグループIDで厳密に絞り込むことを推奨します。

NACLとの組み合わせによる多層防御

セキュリティグループに加え、サブネットレベルのネットワークACL（NACL）でも送信元を制限することで、多層防御を実現できます。HSM向けサブネットへのインバウンドはアプリケーションサーバーが属するCIDRのみに限定し、不要なアウトバウンドルールも削除することがベストプラクティスです。

また、AWS CloudTrailでHSMへの接続イベントを記録しておくと、不正アクセスの早期検出と監査証跡の確保に役立ちます。

3. セットアップ&運用 — クラスター作成 × ユーザー管理 × バックアップ × 監視

CloudHSMの本番運用では、クラスターの初期化と権限モデルの設計が最初の関門になります。本セクションでは、クラスター作成から初期化、Crypto Officer/Crypto Userの管理、バックアップと監視までの運用の流れを解説します。

3-1. クラスター作成と初期化

CloudHSMのセットアップは、クラスター作成から始まります。AWSマネジメントコンソールまたはCLIでCloudHSMクラスターを作成し、クラスターにHSMインスタンスを追加します。このプロセスには明確な順序があり、特にクラスター初期化ステップがAWSを鍵に非接触とするための根拠となります。

クラスター作成の手順

クラスター作成時には、以下の項目を設定します。

• VPCの選択: CloudHSMクラスターは、既存VPC内のプライベートサブネットに配置します。本番環境では、アプリケーションと同一VPCまたはVPCピアリング先のVPCを選択します。
• AZとサブネットの指定: 1つのAZにつき1つのサブネットを選択します。マルチAZ構成では、少なくとも2つの異なるAZにサブネットを指定します。
• HSMインスタンスの追加: クラスター作成直後はHSMが0台の状態です。最初のHSMを追加することで、クラスター初期化が実行できる状態になります。

# クラスター作成
aws cloudhsmv2 create-cluster \
  --hsm-type hsm2m.medium \
  --subnet-ids subnet-aaa111 subnet-bbb222

# 最初のHSMインスタンスを追加
aws cloudhsmv2 create-hsm \
  --cluster-id cluster-xxxxxxxx \
  --availability-zone ap-northeast-1a

HSMのステータスが UNINITIALIZED になったら、次の初期化ステップに進みます。

クラスター初期化 — AWSが鍵に非接触である根拠

クラスター初期化は、CloudHSMセキュリティモデルの核心です。この手順によって、顧客だけがHSMを管理できる状態を確立します。

# 1. クラスターCSRの取得
aws cloudhsmv2 describe-clusters \
  --filters clusterIds=cluster-xxxxxxxx \
  --query 'Clusters[0].Certificates.ClusterCsr' \
  --output text > cluster.csr

# 2. 顧客独自の証明書でCSRに署名（自己署名CAでも可）
openssl genrsa -out customer_root.key 2048
openssl req -new -x509 -days 3652 \
  -key customer_root.key \
  -out customer_root.crt \
  -subj "/CN=Customer Root CA"

openssl x509 -req -days 3652 \
  -in cluster.csr \
  -CA customer_root.crt \
  -CAkey customer_root.key \
  -CAcreateserial \
  -out cluster.crt

# 3. クラスターへの証明書登録（初期化）
aws cloudhsmv2 initialize-cluster \
  --cluster-id cluster-xxxxxxxx \
  --signed-cert file://cluster.crt \
  --trust-anchor file://customer_root.crt

ここで重要なのは、CSRへの署名を顧客のCAキーで行う点です。AWSはこの署名プロセスに関与しません。HSMはこの署名済み証明書を検証し、以降は顧客CAを信頼する状態に設定されます。AWSであってもHSMに対して認証できないことが、このステップによって保証されます。

初期化後、HSMのステータスが INITIALIZED から ACTIVE に変わります。以降はCloudHSM CLIまたはマネジメントコンソールでユーザーを管理します。

CloudHSM CLI によるユーザー管理の開始

CloudHSM CLIは旧来のCloudhsmMgmtUtilを置き換えるツールです。インタラクティブモードとコマンドラインモードの両方をサポートします。

# CloudHSM CLIのインタラクティブモード起動
cloudhsm-cli interactive

# クラスターへの接続確認
> cluster info show

# ユーザー一覧の確認
> user list

初期起動後、まずデフォルトの管理者（admin）でログインし、パスワードを変更してから本番用ユーザーを作成します。

3-2. Crypto Officer / Crypto User 権限モデル

CloudHSMの権限モデルは、役割を明確に分離した最小権限設計に基づいています。主なロールはCrypto Officer（CO）とCrypto User（CU）の2種類です。

Crypto Officer（CO）の役割と設定

Crypto Officerはユーザー管理の管理者です。COが実行できる操作は次のとおりです。

• 新規ユーザー（CO/CU）の作成と削除
• 他ユーザーのパスワード変更
• クォーラム認証ポリシーの管理

COは暗号操作（鍵の生成・署名・暗号化）を直接実行できません。これにより、管理権限と暗号操作権限を明確に分離できます。

初期COはHSM初期化直後のデフォルトユーザー admin です。本番環境ではまずCOのパスワードを変更し、その後に運用COを追加することを推奨します。

# CloudHSM CLIでCOを作成（インタラクティブモード）
> user create --username prod-co-01 --role crypto-officer

# パスワードの変更
> user change-password --username prod-co-01

本番運用では、COを複数人配置し、Crypto Officerの認証情報を別々に管理します。単一COへの依存は、担当者の離職・不在時に権限管理の停止リスクを招きます。

クォーラム認証（M of N）の設計

クォーラム認証を有効にすると、特定の操作に複数のCO承認が必要になります。たとえばM=2、N=3（3名中2名の承認）を設定すると、1名のCO認証情報が漏洩しても不正な操作を防げます。

クォーラム認証の設計における注意点は次のとおりです。

• クォーラム認証は一度有効にすると、クラスター削除以外で無効に戻せません
• 設定変更には、定足数を満たすCOの同時認証が必要です
• 本番環境への適用は、設計と運用体制を十分に検討してから行います

クォーラム認証を使わない場合でも、COを複数設置し、認証情報を分離して管理することが重要です。

Crypto User（CU）の管理

Crypto Userはアプリケーションが暗号操作に使用するユーザーです。CUが実行できる操作は次のとおりです。

• 鍵の生成・削除・エクスポート（設定による）
• 暗号化・復号・署名・検証
• 自分が所有する鍵の他CUへの共有

COはCUを作成できますが、CUの鍵を操作できません。これにより、管理者がデータにアクセスできない設計を実現します。

# CUの作成例（COでログインした状態で実行）
> user create --username app-cu-01 --role crypto-user

# ユーザー一覧確認
> user list

アプリケーションごとに専用のCUを作成し、鍵の所有範囲を最小化することがベストプラクティスです。たとえば、ウェブアプリ用CU・バッチ処理用CU・PKI用CUを分離します。

3-3. バックアップとリストア

CloudHSMは自動バックアップ機能を提供します。このバックアップにはHSM上の鍵が含まれており、クラスターが不意に削除された場合でも鍵を復元できます。

自動バックアップの仕組み

CloudHSMは24時間ごとに自動バックアップを作成します。バックアップはAWS所有のS3バケットに保存されますが、そのバックアップ自体もHSMが生成した鍵で暗号化されています。AWSはバックアップの内容にアクセスできません。

自動バックアップの主な特徴は次のとおりです。

• 保管料は無料（S3の保管コストをAWSが負担）
• バックアップの保持期間は7日間（デフォルト）から365日間まで設定可能
• バックアップには、クラスター内のすべてのHSMで同期された鍵が含まれます

# バックアップ一覧の確認
aws cloudhsmv2 describe-backups \
  --filters attribute.clusterId=cluster-xxxxxxxx

手動バックアップ

定期バックアップに加え、重要な変更（ユーザー追加・鍵の大量生成）の直前または直後に手動バックアップを作成することを推奨します。

# 手動バックアップの作成
aws cloudhsmv2 create-backup \
  --cluster-id cluster-xxxxxxxx \
  --tag-list Key=purpose,Value=pre-maintenance

クロスリージョンコピーとリストア

DR（災害対応）のため、バックアップを別リージョンにコピーできます。

# バックアップのクロスリージョンコピー
aws cloudhsmv2 copy-backup-to-region \
  --backup-id backup-xxxxxxxx \
  --destination-region ap-northeast-1

バックアップからのリストアは、新規クラスターへの適用という形で行います。既存の顧客CA証明書が保存されていれば、クラスター初期化なしに鍵を復元できます。

# バックアップからのクラスター作成（リストア）
aws cloudhsmv2 create-cluster \
  --hsm-type hsm2m.medium \
  --source-backup-id backup-xxxxxxxx \
  --subnet-ids subnet-aaa111 subnet-bbb222

リストア後のクラスターは、バックアップ取得時点のCO・CU設定と鍵をそのまま引き継ぎます。

3-4. 監視とログ

CloudHSMの監視は、HSMインスタンスの健全性とすべての管理操作の監査ログが中心です。

CloudTrailとの連携

CloudHSMのAPIコール（クラスター作成・HSM追加・バックアップ・初期化）はすべてCloudTrailに記録されます。CloudHSM CLIでのユーザー管理操作も、別途CloudWatch Logsに転送できます。

CloudWatch Logsへの監査ログ送信を有効にするには、CloudHSMクラスターにIAMロールを付与します。コンソールでは「クラスター > ログ転送」から有効化します。

HSM健全性の監視

本番環境では、CloudWatchアラームでHSMの状態を定常監視することを推奨します。

推奨アラーム設定例：

{
  "AlarmName": "CloudHSM-UnhealthyHSM",
  "MetricName": "HsmUnhealthy",
  "Threshold": 1,
  "ComparisonOperator": "GreaterThanOrEqualToThreshold",
  "EvaluationPeriods": 1,
  "Period": 60,
  "TreatMissingData": "breaching"
}

監視体制として、HSMの不健全アラームをSNSでPagerDutyまたはOpsgenieに連携し、即時対応体制を整えることを推奨します。1台のHSMが不健全になっても他のHSMで処理を継続できますが、残りのHSMへの負荷増加と可用性リスクを早期に検知することが重要です。

4. hsm1.medium → hsm2m.medium 移行（EOL 2026-03-31）

hsm1.mediumインスタンスタイプは2026年3月31日にサポート終了（EOL）を迎えます。本セクションでは、EOLスケジュール、hsm2m.mediumへの移行手順、ダウンタイムを最小化する方法を解説します。

4-1. EOLスケジュールと影響範囲

hsm1.mediumは2026年3月31日をもってサポート終了（EOL）となりました。AWS CloudHSMチームは、EOL以降のhsm1.mediumに対する新機能追加・セキュリティアップデートを停止しています。

EOL背景 — FIPS認証の変遷

hsm1.mediumはFIPS 140-2 Level 3に準拠したハードウェアです。このhsm1.mediumが保持するFIPS 140-2認証は、米国国立標準技術研究所（NIST）のCMVP（Cryptographic Module Validation Program）において2026年1月4日に歴史的リスト（Historical List）へ移行します。歴史的リストへ移った認証は新規のコンプライアンス審査での参照に適さないとされるため、FIPS 140-2認証に依存した新規調達・審査での利用が困難になっています。

一方、hsm2m.mediumはFIPS 140-3 Level 3（Certificate #4703）に準拠した次世代ハードウェアです。FIPS 140-3はFIPS 140-2の後継規格であり、より厳格なセキュリティ要件と試験方法を定義しています。

hsm1.mediumとhsm2m.mediumの差異

移行を検討するうえで、hsm1.mediumとhsm2m.mediumの違いを把握しておくことが重要です。

hsm2m.mediumは2025年12月のファームウェアアップデートで、ログインレイテンシとFindKey操作のパフォーマンスが大幅に改善されました。短命なセッションを多用するワークロードや、大量の鍵を保持するクラスターでは、hsm2mへ移行することで性能向上の恩恵を受けられます。

影響を受けるワークロードの整理

EOL以降もすでに稼働しているhsm1.mediumインスタンスがすぐに停止されるわけではありません。ただし以下のワークロードでは、早急な移行を優先的に検討します。

• PCI DSS、HIPAA、FedRAMPなどの規制要件でFIPS 140-3の取得が明示されている環境
• 新規の監査・認証取得を予定している環境
• AWS Marketplace製品や外部セキュリティ製品との統合を更新・追加する予定がある環境
• AWSサポートへのエスカレーションが将来必要になる可能性が高い本番環境

既存稼働環境でFIPS 140-2の要件を満たせる場合は、AWSから送付される最終廃止通知を確認しながら計画的に移行を進めることが現実的なアプローチです。

4-2. hsm2mへの移行手順

hsm1.mediumからhsm2m.mediumへの移行は、同一クラスター内での段階的な置き換えで実現します。既存クラスターにhsm2m.mediumインスタンスを追加すると、クラスター内の鍵は自動的に同期されるため、アプリケーション側への影響を最小限に抑えながら移行できます。

移行前準備チェックリスト

移行作業を開始する前に、以下の項目を確認します。

① クラスターバックアップの確認・取得

既存クラスターの最新バックアップを確認します。AWS CloudHSMは自動バックアップ機能を提供していますが、移行前には手動で最新状態を確認します。

# 最新バックアップの確認（READYステータスのもの）
aws cloudhsmv2 describe-backups \
  --filters clusterIds=<cluster-id> \
  --query 'Backups[?State==`READY`].[BackupId,CreateTimestamp]' \
  --output table

最新バックアップが24時間以上前の場合は、次の自動バックアップが完了するまで待機するか、移行作業前に書き込みを一時停止して状態を安定させます。

② クライアントSDKバージョンの確認

hsm2m.mediumにはAWS CloudHSM Client SDK 5以降が必要です。SDK 3（旧バージョン）を利用している場合は、SDK 5への移行も並行して実施します。

# CloudHSM CLIのバージョン確認（Linux）
cloudhsm-cli --version

# PKCS#11ライブラリの配置確認
ls -la /opt/cloudhsm/lib/libcloudhsm_pkcs11.so*

③ ネットワーク・セキュリティグループの確認

新しいhsm2m.mediumインスタンスが配置されるサブネットで、HSMのポート（2223/2225/2226）が許可されていることを確認します。

移行手順

ステップ1 — 既存クラスターへのhsm2m.medium追加

既存クラスターに、別のアベイラビリティゾーンへhsm2m.mediumを追加します。まず追加可能なサブネット一覧を確認します。

# クラスター情報とサブネット一覧を確認
aws cloudhsmv2 describe-clusters \
  --filters clusterIds=<cluster-id> \
  --query 'Clusters[0].{SubnetMapping:SubnetMapping,Hsms:Hsms[*].[AvailabilityZone,HsmType,State]}' \
  --output json

対象のアベイラビリティゾーンにhsm2m.mediumを追加します。

# hsm2m.mediumをクラスターに追加
aws cloudhsmv2 create-hsm \
  --cluster-id <cluster-id> \
  --availability-zone <target-az> \
  --ip-address <ip-address>

HSMの作成には通常3〜5分かかります。ステータスを確認します。

# 作成中のHSMステータスを確認
aws cloudhsmv2 describe-hsm \
  --hsm-id <new-hsm2m-id> \
  --query 'Hsm.State'
# "ACTIVE" になれば追加完了

ステップ2 — 鍵の自動同期確認

CloudHSMクラスター内のHSMインスタンスは、鍵マテリアルを自動的に同期します。hsm2m.mediumがクラスターに追加されてACTIVEになれば、既存のhsm1.mediumが保持していた鍵がhsm2m.mediumにも複製されています。

# クラスター内のHSM一覧とタイプを確認
aws cloudhsmv2 describe-clusters \
  --filters clusterIds=<cluster-id> \
  --query 'Clusters[0].Hsms[*].[HsmId,AvailabilityZone,HsmType,State]' \
  --output table

hsm1.mediumとhsm2m.mediumの両方がACTIVE状態になれば、鍵の同期が完了しています。

ステップ3 — アプリケーション接続の段階的切り替え

CloudHSM Client SDK 5は、クラスター内の複数HSMに対してラウンドロビンで接続します。hsm2m.mediumがACTIVEになった時点から、アプリケーションは自動的にhsm2m.mediumも使用するようになります。

追加後の並行稼働期間中は、アプリケーションのログとCloudTrailを監視し、hsm2m.mediumへの暗号操作が正常に記録されることを確認します。

# CloudTrailで最新の暗号操作を確認（例: GenerateRandom）
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=GenerateRandom \
  --max-results 5 \
  --query 'Events[*].[EventTime,Resources[0].ResourceName]' \
  --output table

ステップ4 — hsm1.mediumインスタンスの削除

アプリケーションがhsm2m.mediumへ正常に接続していることを確認した後、hsm1.mediumを削除します。

# hsm1.mediumインスタンスの削除
aws cloudhsmv2 delete-hsm \
  --cluster-id <cluster-id> \
  --hsm-id <hsm1-medium-hsm-id>

複数AZでの段階移行（推奨構成）

本番環境では複数のアベイラビリティゾーンにHSMを配置することが多いです。複数AZにhsm1.mediumが存在する場合は、AZごとに順次移行を進めます。

# AZ-aにhsm2m追加 → 同期確認 → AZ-aのhsm1削除
aws cloudhsmv2 create-hsm \
  --cluster-id <cluster-id> \
  --availability-zone ap-northeast-1a \
  --ip-address 10.0.1.10

# AZ-aのhsm2mがACTIVEになり、アプリ正常稼働を確認してからhsm1削除
aws cloudhsmv2 delete-hsm \
  --cluster-id <cluster-id> \
  --hsm-id <az-a-hsm1-id>

# 同様にAZ-cへのhsm2m追加→削除を繰り返す
aws cloudhsmv2 create-hsm \
  --cluster-id <cluster-id> \
  --availability-zone ap-northeast-1c \
  --ip-address 10.0.2.10

一度に全AZのhsm1を削除するのは避け、1AZずつ順次実施することでリスクを局所化します。

4-3. 互換性とダウンタイム最小化

クライアントSDKの互換性マトリックス

hsm2m.mediumへの移行を成功させるには、アプリケーション側のSDKバージョンが対応していることが前提です。

SDK 3（旧世代）を継続利用しているアプリケーションがある場合は、hsm2m.medium移行に先立ってSDK 5へのアップグレードを実施します。SDK 3とSDK 5はAPIが異なるため、アプリケーション側の設定ファイルや初期化コードの変更が必要になります。

ゼロダウンタイム移行のポイント

CloudHSMクラスター内では鍵が自動同期されるため、hsm2m.mediumを追加してからhsm1.mediumを削除するまでの並行稼働期間中、両方のHSMが同じ鍵マテリアルを保持します。この仕組みを活用することで、アプリケーションへの影響なしに移行を完了できます。

[並行稼働期間のイメージ]

クラスター内
  ┌────────────────────────────────────────────┐
  │ hsm1.medium (ACTIVE) ←鍵自動同期→ hsm2m.medium (ACTIVE) │
  │ Client SDK 5がラウンドロビンで両方に接続│
  └────────────────────────────────────────────┘
  ↓
  hsm2mへの暗号操作が正常に記録されたことを確認
  ↓
  hsm1.mediumを削除（クラスターはhsm2mのみに）

並行稼働期間は最低でも24〜48時間を確保します。この期間中に以下を確認します。

1. アプリケーションのエラーログ: SDK 5の接続エラーや暗号操作エラーがないことを確認
2. CloudTrailの暗号操作ログ: hsm2m.mediumのHSM IDで操作が記録されていることを確認
3. CloudWatchメトリクス: CloudHsmUnhealthyHsmCountが0を維持していることを確認

# CloudWatchでHSM健全性を確認
aws cloudwatch get-metric-statistics \
  --namespace CloudHSM \
  --metric-name CloudHsmUnhealthyHsmCount \
  --dimensions Name=ClusterId,Value=<cluster-id> \
  --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 3600 \
  --statistics Maximum \
  --output table

2025-12ファームウェアの改善内容

2025年12月のファームウェアアップデートにより、hsm2m.mediumに以下の改善が加えられました。

• ログインレイテンシの改善: セッション確立時のレイテンシが大幅に削減され、短命なセッションを多用するワークロードでの性能が向上しました。Lambda関数からの呼び出しや、リクエストごとにセッションを開閉するアーキテクチャで恩恵を受けられます。
• FindKey操作の高速化: 大量の鍵を保持するクラスターでの鍵検索操作が高速化されました。鍵の数が数千以上に達しているクラスターでも、より安定したレスポンスタイムが期待できます。

これらの改善はhsm2m.mediumの既存インスタンスにも適用されており、hsm1からhsm2mへ移行することで性能向上の恩恵を受けられます。

移行後確認手順

hsm1.mediumをすべて削除した後、以下の確認を実施します。

# クラスター内のHSM一覧を確認（hsm1が含まれていないこと）
aws cloudhsmv2 describe-clusters \
  --filters clusterIds=<cluster-id> \
  --query 'Clusters[0].Hsms[*].[HsmId,HsmType,State]' \
  --output table

# CloudHSM CLIでHSM情報を確認（FIPS 140-3 Level 3の動作確認）
cloudhsm-cli hsm info

# 最新バックアップが取得されていることを確認
aws cloudhsmv2 describe-backups \
  --filters clusterIds=<cluster-id> \
  --query 'Backups[?State==`READY`] | [0].[BackupId,CreateTimestamp]' \
  --output table

アプリケーション側の暗号操作（署名・復号・鍵生成）がエラーなく完了することを本番トラフィックで確認し、移行完了とします。

5. アプリ統合 — PKCS#11 × JCE × OpenSSL × KMS Custom Key Store

CloudHSMの鍵をアプリケーションから利用するには、標準的な暗号APIに対応したSDKを使います。本セクションでは、PKCS#11・JCE・OpenSSL Dynamic Engineの統合方式と、KMS Custom Key Storeによる連携を解説します。

5-1. PKCS#11 / JCE / OpenSSL Dynamic Engine

CloudHSMの鍵をアプリケーションから利用する際のSDKは、言語・ランタイムによって異なります。CloudHSM Client SDK 5（現行推奨）はPKCS#11・JCEの両インターフェースをサポートし、Linux・Windowsの主要な実行環境に対応しています。

PKCS#11統合

PKCS#11（Cryptographic Token Interface Standard）は、HSMなどの暗号デバイスを抽象化する標準C APIです。CloudHSMが提供するPKCS#11ライブラリを読み込むことで、C/C++・Python（python-pkcs11）・Node.js（pkcs11js）など多くの言語からHSMの鍵を操作できます。

インストール（Linux）

# CloudHSM Client SDK 5のPKCS#11ライブラリをインストール
sudo yum install -y cloudhsm-pkcs11

# ライブラリパスを確認
ls /opt/cloudhsm/lib/libcloudhsm_pkcs11.so

スロット設定とC_Initializeフロー

PKCS#11では、HSMクラスターが「スロット」として見えます。CloudHSMでは、クラスターに対応するスロットが1つ割り当てられます。アプリケーションは C_Initialize → C_OpenSession → C_Login → 鍵操作 → C_CloseSession → C_Finalize の順で処理します。

/* PKCS#11初期化フロー（概略） */
CK_FUNCTION_LIST_PTR pFunctionList;
CK_SESSION_HANDLE hSession;
CK_SLOT_ID slots[10];
CK_ULONG slotCount = 10;

C_GetFunctionList(&pFunctionList);

/* 初期化（OSレベルのロック機構を利用） */
CK_C_INITIALIZE_ARGS initArgs = {NULL, NULL, NULL, NULL, CKF_OS_LOCKING_OK, NULL};
pFunctionList->C_Initialize(&initArgs);

/* スロット一覧を取得（存在するスロットのみ） */
pFunctionList->C_GetSlotList(CK_TRUE, slots, &slotCount);

/* セッションオープン（読み書き可能なシリアルセッション） */
pFunctionList->C_OpenSession(slots[0], CKF_SERIAL_SESSION | CKF_RW_SESSION,
  NULL, NULL, &hSession);

/* Crypto UserのPINでログイン */
CK_CHAR userPin[] = "CryptoUserPassword";
pFunctionList->C_Login(hSession, CKU_USER, userPin, sizeof(userPin) - 1);

CloudHSM固有の属性指定

標準PKCS#11属性に加え、本番では以下の属性を明示することが重要です。CKA_EXTRACTABLE=FALSE により鍵のエクスポートを禁止し、CKA_TOKEN=TRUE でHSM上に永続保存します。CKA_SENSITIVE=TRUE により鍵素材の平文取り出しを防止できます。これらは鍵生成時の属性テンプレートで指定します。

JCE Provider統合

JavaアプリケーションからCloudHSMの鍵を使うには、CloudHSM JCE Providerを利用します。JCEは標準のJava Cryptography Extension APIであり、既存Javaコードをほぼ変更せずHSMの鍵に切り替えられます。

インストール

# CloudHSM JCEプロバイダーをインストール
sudo yum install -y cloudhsm-jce

# JARファイルのパスを確認
ls /opt/cloudhsm/java/cloudhsm-jce-*.jar

Java Security設定（Providerの登録）

# /etc/java/security/java.security に追加するか、
# アプリ起動時に Security.addProvider() を呼び出す
security.provider.1=com.amazonaws.cloudhsm.jce.provider.CloudHsmProvider

JCEプロバイダーを使った鍵生成と暗号化

import com.amazonaws.cloudhsm.jce.provider.CloudHsmProvider;
import java.security.KeyGenerator;
import java.security.Security;
import javax.crypto.Cipher;
import javax.crypto.SecretKey;

// プロバイダー登録
Security.addProvider(new CloudHsmProvider());

// CloudHSM上にAES-256鍵を生成
KeyGenerator keyGen = KeyGenerator.getInstance("AES", "CloudHsmProvider");
keyGen.init(256);
SecretKey aesKey = keyGen.generateKey();

// AES-GCMによる暗号化
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding", "CloudHsmProvider");
cipher.init(Cipher.ENCRYPT_MODE, aesKey);
byte[] ciphertext = cipher.doFinal(plaintext);

KeyStoreによる鍵ラベル管理

import java.security.KeyStore;

// HSMのKeyStoreを開く（認証はHSM ClusterID経由で解決）
KeyStore ks = KeyStore.getInstance("CloudHSM", "CloudHsmProvider");
ks.load(null, null);

// ラベルで既存鍵を参照
java.security.Key existingKey = ks.getKey("myRsaKeyLabel", null);

Kotlin・Scalaでも同じJCEプロバイダーが動作します。JVM標準のKeyStore APIを通じて操作するため、既存Javaアプリのコード変更を最小限に抑えられます。

OpenSSL Dynamic Engine統合

CloudHSM OpenSSL Dynamic EngineはOpenSSLのエンジンAPIにフックし、RSA秘密鍵の操作をHSMで実行させます。主な用途はNginx・ApacheのTLSオフロードです。

インストール

# CloudHSM Client SDK 5のPKCS#11パッケージをインストール後、
# OpenSSL Engineライブラリのパスを確認
ls /opt/cloudhsm/lib/libcloudhsm_openssl_engine.so

Nginxへの組み込み

# /etc/nginx/nginx.conf — ssl_certificate_key にエンジン参照を指定
ssl_certificate  /etc/ssl/certs/server.crt;
ssl_certificate_key engine:cloudhsm:cloudhsm-rsa-private-key-label;

ApacheへのOpenSSL Engine設定

SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile "engine:cloudhsm:label=myRsaKey"
SSLOpenSSLConfCmd  Engine "/opt/cloudhsm/lib/libcloudhsm_openssl_engine.so"

秘密鍵がHSM外に出ない設定のため、OSやファイルシステムが侵害されてもTLS秘密鍵の漏洩を防止できます。OpenSSLエンジンをサポートするHAProxyなどでも同様に統合できます。

CloudHSM Client SDK 3からSDK 5への移行

SDK 5への移行は、既存のPKCS#11・JCEコードとの互換性を維持しながら、パッケージを入れ替えるだけで対応できるケースがほとんどです。

5-2. KMS Custom Key Store連携

KMS Custom Key Store（CloudHSMバックエンド）は、AWS KMSのAPIをそのまま使いながら、暗号鍵の実体をCloudHSMクラスター上に保管する仕組みです。KMSの豊富なサービス統合（S3/EBS/RDS/SageMaker等）を活かしながら、鍵の所有権と専有HSMの保証を両立できます。

KMS Custom Key Storeの仕組み

KMS Custom Key Storeを作成すると、KMSとCloudHSMクラスター間に専用の信頼チャネルが確立されます。KMS APIでのCMK作成・使用時、実際の暗号演算はCloudHSMクラスター上のHSMで実行されます。KMSのAPI・CloudTrail監査ログ・IAMポリシーはそのまま有効で、アプリケーション側のコード変更は不要です。

前提条件

• CloudHSMクラスターが ACTIVE 状態であること
• kmsuser Crypto UserがCloudHSMクラスターに作成済みであること
• クラスターの信頼アンカー証明書（cluster_cert.crt）を取得済みであること

カスタムキーストアの作成手順

# Step 1: CloudHSMクラスターのIDを確認
aws cloudhsmv2 describe-clusters \
  --query "Clusters[].ClusterId"

# Step 2: KMSカスタムキーストアを作成
aws kms create-custom-key-store \
  --custom-key-store-name "my-cloudhsm-key-store" \
  --cloud-hsm-cluster-id "cluster-xxxxxxxxxxxxxxxxx" \
  --trust-anchor-certificate file://cluster_cert.crt \
  --key-store-password "kmsuser-password"

# Step 3: カスタムキーストアをKMSに接続
aws kms connect-custom-key-store \
  --custom-key-store-id "cks-xxxxxxxxxxxxxxxxx"

# 接続状態の確認（CONNECTEDになるまで数十秒待機）
aws kms describe-custom-key-stores \
  --custom-key-store-id "cks-xxxxxxxxxxxxxxxxx" \
  --query "CustomKeyStores[].ConnectionState"

カスタムキーストア上でのCMK作成と利用

# カスタムキーストア上にCMKを作成
aws kms create-key \
  --origin CUSTOM_KEY_STORE \
  --custom-key-store-id "cks-xxxxxxxxxxxxxxxxx" \
  --description "CloudHSM-backed CMK for production" \
  --key-usage ENCRYPT_DECRYPT \
  --key-spec SYMMETRIC_DEFAULT

# 作成したCMKでデータを暗号化（通常のKMS APIと同じ操作）
aws kms encrypt \
  --key-id "arn:aws:kms:ap-northeast-1:123456789012:key/xxxxx" \
  --plaintext fileb://data.bin \
  --output text \
  --query CiphertextBlob | base64 --decode > encrypted.bin

# S3サーバーサイド暗号化にカスタムキーストアCMKを指定
aws s3api put-object \
  --bucket my-bucket \
  --key myfile.txt \
  --server-side-encryption aws:kms \
  --ssekms-key-id "arn:aws:kms:ap-northeast-1:123456789012:key/xxxxx" \
  --body myfile.txt

RDS・EBSなどのサービスでも、通常のKMS CMKと同じ手順でカスタムキーストアCMKを指定できます。

カスタムキーストアの制限事項

クラスター接続断が発生するとCMKを使う全暗号化・復号が停止するため、CloudHSMクラスターのマルチAZ配置が不可欠です。

5-3. PKI・署名・暗号化での利用

CloudHSMは、TLSオフロード・コード署名・Oracle TDE・プライベートCAのルート鍵保護など、高いセキュリティ保証が求められる場面で幅広く活用されます。

コード署名

HSM上にRSAキーペアを生成し、OpenSSLのPKCS#11エンジン経由でコード署名に利用できます。

# PKCS#11ツールでHSM上にRSA 4096鍵ペアを生成
pkcs11-tool --module /opt/cloudhsm/lib/libcloudhsm_pkcs11.so \
  --login --login-type user --pin CryptoUserPassword \
  --keypairgen --mechanism RSA-PKCS-KEY-PAIR-GEN \
  --key-type rsa:4096 \
  --label "code-signing-key" --token-label "CloudHSM"

# CSR生成（OpenSSLのPKCS#11エンジン経由）
openssl req -engine pkcs11 \
  -key "pkcs11:token=CloudHSM;object=code-signing-key;type=private" \
  -new -out code-signing.csr \
  -subj "/CN=CodeSigningCA/O=Example Corp"

署名鍵に CKA_EXTRACTABLE=FALSE を設定することで、秘密鍵の漏洩リスクを排除できます。

Oracle TDE（Transparent Data Encryption）のマスター鍵保護

Oracle DatabaseのTDEマスター鍵をCloudHSMで保護する構成では、sqlnet.ora にPKCS#11ライブラリパスを指定し、以下の操作でHSM上にTDEマスター鍵を設定します。

-- Oracle SQL*Plus でのHSMウォレット初期化
ADMINISTER KEY MANAGEMENT USE CLIENT SECRET IDENTIFIED BY "CryptoUserPassword"
  WITH WALLET PATH "/opt/oracle/dbs/hsm_wallet";

-- CloudHSMバックのTDEマスター鍵を設定
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "CryptoUserPassword"
  WITH BACKUP USING "tde_master_key_backup";

TDE鍵がHSM内に保管されることで、データベースファイルとマスター鍵が物理的に分離され、PCI DSS・HIPAAなどの規制要件を満たしやすくなります。

プライベートCAのルート鍵保護

自己管理のPKIでは、OpenSSLとPKCS#11エンジンを組み合わせることで、HSM上のルート鍵を使った証明書発行が可能です。

# HSM上のCA鍵でCSRに署名（OpenSSLのPKCS#11エンジン経由）
openssl ca -engine pkcs11 \
  -keyform engine \
  -keyfile "pkcs11:object=root-ca-key;type=private" \
  -cert /etc/ssl/root-ca.crt \
  -in server.csr \
  -out server.crt \
  -days 365

ルートCA秘密鍵に CKA_EXTRACTABLE=FALSE を設定することで、鍵の物理的な漏洩リスクをゼロにできます。ACM Private CAと組み合わせる場合は、KMS Custom Key StoreのCMKを利用することでKMSレベルの統合も実現できます。

アプリケーション統合方式の選択まとめ

6. セキュリティ・コンプライアンス・コスト設計

CloudHSMは最高水準の鍵保護を提供する一方、運用コストと責任モデルを正しく理解する必要があります。本セクションでは、FIPS 140-3 Level 3準拠の詳細、CloudTrail統合による監査、鍵の所有権モデル、コスト構造と最適化を解説します。

6-1. FIPS 140-3 Level 3認定の詳細

FIPS 140-3 Level 3とは何か

FIPS 140-3（Federal Information Processing Standard Publication 140-3）は、暗号モジュールのセキュリティ要件を定めたNISTの標準規格です。2019年に策定され、前身のFIPS 140-2から要件が強化されています。セキュリティレベルは1〜4があり、Level 3は以下の要件を満たす必要があります。

• 物理的な改ざん検知および対抗機能（ベゼルの強化・改ざん明示エビデンス）
• 役割ベースの認証（Crypto Officer/Crypto Userの権限分離）
• 鍵が暗号化された形でしか外部に出ない設計（非特定な内部鍵の秘匿）
• 環境的な攻撃への対抗（温度・電圧の異常でゼロ化が動作）
• EFP（Environmental Failure Protection）またはEFT（Environmental Failure Testing）

CloudHSMのhsm2m.mediumはFIPS 140-3 Level 3の認定を取得しており、認定番号はCertificate #4703です。これはパブリッククラウドのサービスとして取得できる最高レベルのHSM認定です。

hsm2m.mediumのFIPS認定状況

2025年12月にファームウェアのアップデートが実施され、login latencyの改善やfindkey処理のパフォーマンス向上が含まれています。FIPSモードで動作するhsm2m.mediumは、NIST CMVP（Cryptographic Module Validation Program）のアクティブリストに掲載されており、監査時に認定証明書番号を提示できます。

旧世代のhsm1.mediumはFIPS 140-2 Level 3の認定を持ちます。EOL（2026-03-31）以降は認定の有効性の確認が必要になります。コンプライアンス要件がある環境では、hsm2m.mediumへの早期移行が推奨されます。

非FIPSモードの選択

CloudHSMはFIPSモードと非FIPSモードを選択できます。FIPSモードでは、FIPS承認のアルゴリズムのみが使用可能で、非承認アルゴリズムは利用できません。コンプライアンス要件がない環境では非FIPSモードを選択し、より広いアルゴリズムセットを利用できます。

本番のコンプライアンス要件がある環境では、クラスター作成時にFIPSモードを有効化します。クラスター初期化後はFIPSモードを変更できないため、設計段階でモードを確定しておくことが重要です。

規制業界での具体的な位置づけ

PCI DSS（Payment Card Industry Data Security Standard）のPINセキュリティ要件では、PIN暗号化デバイスとして承認されたFIPS 140-3 Level 3以上のHSMを要求します。CloudHSMのhsm2mはPCI PINコンプライアンスに対応しています。

その他、医療分野のHIPAA高保証環境、政府機関向けFedRAMP High準拠、財務省・金融庁規制への対応、電力インフラのNERC CIPなど、さまざまな規制環境でFIPS 140-3 Level 3認定が評価されます。コンプライアンス監査では、hsm2m.mediumのCMVP Certificate #4703を根拠として提示できます。

6-2. CloudTrail統合と監査ログ

CloudHSM管理操作のCloudTrail記録

CloudHSMのAWS管理操作（クラスターの作成・削除・タグ付け・バックアップ操作など）はCloudTrailに自動で記録されます。CloudTrailのデータイベントとして、CloudHSMのAPI呼び出しが証跡に残るため、「誰が・いつ・何をしたか」を監査できます。

CloudTrail証跡はS3バケットに保存され、AWS Config・Security Hubと組み合わせることで、CloudHSMリソースへの変更検知と自動アラートを実現できます。重要なリソースへの変更（クラスターの削除・セキュリティグループ変更）は、CloudWatch Alarmsでリアルタイム通知を設定することが推奨されます。

HSM内部操作のログ

CloudHSM内部での暗号操作（鍵の生成・削除・使用）やCO/CUの操作は、CloudHSMクライアントSDKを通じてCloudWatch Logsに記録できます。管理操作（CloudTrailに記録）と暗号操作（CloudWatch Logsに記録）の2種類のログを分離して管理し、それぞれの監査要件に対応します。

CloudWatch Logs Insightsを使って、特定の鍵への操作・特定ユーザーによる操作・エラーパターンを検索・分析できます。コンプライアンス要件に応じてログの保存期間を設定し、審査証跡を長期保持します。

KMS Custom Key Storeとの統合監査

KMS Custom Key Storeを使用する場合、KMS APIの呼び出しはCloudTrailのKMSデータイベントとして記録され、その裏でCloudHSMに対する操作が発生します。両方のログを相関させることで、アプリケーション層からHSM操作層までのend-to-endな監査が可能です。Security Hubと連携してFindingsを集約し、一元的なセキュリティ監視基盤に組み込めます。

監査ログ設計のベストプラクティス

コンプライアンス対応の監査ログ設計では、以下の点を考慮します。

• CloudTrail証跡はマルチリージョン有効化し、S3バケットのオブジェクトロック（WORM）で改ざん防止
• HSMの暗号操作ログは最低1年保持（PCI DSS要件）、コンプライアンス次第では7年保持
• CloudWatch Logs Metric Filterで異常な鍵削除・CO権限変更を検知しアラート
• AWS Config Rulesで「CloudHSMクラスターのバックアップが取得されているか」を継続監視

6-3. 鍵の所有権と責任共有モデル

お客様が完全に所有する鍵

CloudHSMの最大の特徴は、鍵の所有権がお客様にあることです。AWSはHSMのハードウェアインフラストラクチャを管理しますが、鍵マテリアルそのものには一切アクセスできません。これは技術的な仕組みとして保証されており、AWS担当者がHSMに接続して鍵を取得する手段は存在しません。

CloudHSMを初めて使用する際、AWSはまだ初期化されていないHSMを提供します。お客様がクラスターを初期化し、Crypto OfficerとCrypto Userを設定して、はじめてHSMが使用可能な状態になります。このプロセスにAWSは関与せず、CO/CU設定後の鍵管理はすべてお客様の責任となります。

Crypto Officer（CO）とCrypto User（CU）の権限体系

CloudHSMでは、ユーザーの役割を明確に分離します。

• マスターユーザー（precrypto user）: クラスター初期化直後のみ存在。最初のCO作成に使用
• Crypto Officer（CO）: ユーザーの作成・削除・パスワード変更などの管理操作を担当。暗号操作は不可
• Crypto User（CU）: 鍵の生成・使用・削除など暗号操作を担当。ユーザー管理は不可
• Appliance User（AU）: クラスター内のHSM間で鍵同期を行う特殊ユーザー（AWSが管理）

この権限分離は「管理権限を持つ人が暗号操作もできる」状態を防ぎ、デュアルコントロールの原則を実現します。コンプライアンス要件が高い環境では、CO権限とCU権限を別の担当者に付与し、相互牽制を確保します。クォーラム認証（M of N）を設定することで、単一担当者による不正操作を防止できます。

鍵消失リスクとバックアップ責任

CloudHSMの鍵はHSMのメモリ内に存在します。クラスター内の全HSMインスタンスが失われた場合、鍵は消失します。これはKMSとの本質的な違いであり、バックアップ責任はお客様にあります。

CloudHSMは自動バックアップを提供しており、バックアップはAWS所有のS3バケットに保存されます（ストレージコスト無料）。ただし、バックアップ管理・リストア手順・別リージョンへのコピーはお客様の運用責任です。本番環境では定期バックアップが正常に取得されていることを確認し、定期的なリストアテストでバックアップの有効性を検証します。

バックアップ運用でよくある失敗例として「バックアップは取れていたが、リストア手順を一度も検証していなかった」というケースがあります。年1回以上の実際のリストア訓練（本番と同じ手順でのクラスター復元）を実施し、手順書の有効性を確認することが重要です。重要な鍵をCloudHSMへ移行する前に、バックアップと暗号化マテリアルの適切な保護計画を立てておくことが推奨されます。

6-4. コスト構造と最適化

hsm2m.mediumのコスト構造

CloudHSMの主なコスト要素はHSMインスタンスの時間課金です。hsm2m.mediumは1台あたり約$1.60/時間（東京リージョン/2026年6月時点）です。月間換算では1台あたり約$1,152（30日換算）となり、KMSのカスタマーマネージドキー（$1/月/キー + API呼び出し）と比較すると大幅に高コストです。

バックアップはAWSが自動で取得し、ストレージコストはAWSが負担します。データ転送コストも基本的には発生しません。HSMインスタンスの時間課金が実質的なすべてのコストです。

高可用性（HA）構成時のコスト

本番環境での高可用性確保のため、複数のAZにHSMを分散配置する場合、台数分だけコストが増加します。最小のHA構成（2台・2AZ）では約$2,304/月、3台構成（3AZ）では約$3,456/月となります。

CloudHSMのHA構成ではHSM台数に比例してコストが増加するため、「どこまでの可用性が必要か」を明確に定義することが重要です。全AZに配置するのではなく、必要な可用性要件と予算のバランスを取ります。

コスト最適化の指針

開発・検証環境では、必要なときだけHSMを起動しテスト後に削除する「オンデマンド利用」を検討します。ただし、HSMの初期化・CO/CU設定の手間が毎回発生するため、IaC（Terraform等）を活用した自動化で効率化します。

KMSとの費用対効果比較でCloudHSMが合理的になるのは、FIPS 140-3 Level 3コンプライアンス要件がある場合、または鍵の所有権要件が規制・契約上で義務付けられている場合です。それ以外の暗号化ニーズにはKMSが適しています。

KMSとのコスト比較例

月10,000回のAPI呼び出し＋10キー管理の場合、KMSは約$10.10/月ですが、CloudHSMは$1,152/月〜となります。コスト差は大きいため、CloudHSMの採用はコンプライアンス要件・鍵所有権要件がある場合に限定し、一般的な暗号化にはKMSを使うのが現実的な設計です。PKIルート鍵の永続保管（低頻度使用）では、オンプレミスHSMの導入・維持コストと比較すると、CloudHSMのほうが運用コストを抑えられるケースもあります。

マルチリージョン・マルチアカウント展開時のコスト

複数リージョンにクラスターを展開する場合、各リージョンでHSMインスタンスの課金が発生します。DR（ディザスタリカバリ）要件でセカンダリリージョンにもHSMを配置する設計では、コストが倍増します。バックアップの別リージョンコピー機能を活用し、常時稼働のHSMはプライマリリージョンのみに限定することでコストを抑えながらDR対応できます。

Organizations環境でのマルチアカウント展開では、各アカウントが独自のCloudHSMクラスターを持つ場合、アカウント数に比例してコストが増加します。共有インフラ（セキュリティ専用アカウント）にCloudHSMを集約し、他アカウントはネットワーク経由でアクセスする設計も検討できます。ただし、HSMへの接続はVPC内に限られるため、VPC PeeringやTransit Gatewayとの組み合わせが必要です。

CloudHSMのセキュリティ設計まとめ

本セクションの内容を踏まえた、CloudHSM運用の主要ポイントを整理します。

• FIPS 140-3 Level 3（Certificate #4703）: 規制業界の最高水準コンプライアンスに対応
• CloudTrail + CloudWatch Logs: 管理操作と暗号操作の2層監査で証跡を完備
• CO/CU分離: デュアルコントロールで鍵の不正操作を防止
• バックアップ: 自動バックアップ（無料）＋定期リストアテストで鍵消失リスクを最小化
• コスト: $1,152/月〜（1台）/ 要件がない用途にはKMSが適切

セキュリティアーキテクチャ上の注意点

CloudHSMを本番運用する際に忘れやすいセキュリティ上の注意点を以下に示します。

• HSMのセキュリティグループは必要最小限のポートのみ許可（デフォルトはポート2223-2225）
• COパスワードの紛失はクラスター再作成（全鍵消失）に直結するため、パスワード管理を厳重に
• hsm2mではFIPSモードでもAES-GCMのIVを顧客が指定する「IVとして0を使う」誤実装に注意
• KMS Custom Key Store利用時は「KMS CMKとCloudHSMが乖離するバグ」のリリースノートを随時確認

セキュリティ設計・コスト最適化・コンプライアンス対応の3点を押さえることで、CloudHSMの本番運用が安定します。

§7では、これらの知識を実際のユースケースに適用した統合パターンを解説します。

7. 実戦統合パターン — PKI・暗号化ユースケース

本セクションでは、CloudHSMを実際の本番システムに組み込む代表的な統合パターンを、既存のセキュリティ基盤との連携を含めて解説します。

7-1. KMS Custom Key Store連携 — KMSの利便性とHSM鍵所有権を両立する

KMS Custom Key Storeは、CloudHSMクラスターをバックエンドとしてKMSキーを作成する機能です。KMS APIの利便性を維持しながら、鍵の実体をCloudHSMに保管できます。

KMS Custom Key Storeのメリットは次のとおりです。

• KMS APIのインターフェース（S3/EBS/Secrets Manager等との統合）をそのまま利用できます
• 鍵の実体（鍵素材）はCloudHSMに保管され、AWSは鍵に非接触の状態を維持できます
• 既存のKMSポリシーやIAM設定を変更せずに移行できます

カスタムキーストアの作成手順は次のとおりです。

# 1. CloudHSMクラスター証明書の取得
aws cloudhsmv2 describe-clusters \
  --filters clusterIds=cluster-xxxxxxxx \
  --query 'Clusters[0].Certificates.ClusterCertificate' \
  --output text > cluster_cert.pem

# 2. KMSカスタムキーストアの作成
aws kms create-custom-key-store \
  --custom-key-store-name my-cloudhsm-keystore \
  --cloud-hsm-cluster-id cluster-xxxxxxxx \
  --trust-anchor-certificate file://cluster_cert.pem \
  --key-store-password <cu-password>

# 3. カスタムキーストアへの接続
aws kms connect-custom-key-store \
  --custom-key-store-id <keystore-id>

# 接続状態の確認
aws kms describe-custom-key-stores \
  --custom-key-store-id <keystore-id> \
  --query 'CustomKeyStores[0].ConnectionState'
# 出力: "CONNECTED"

# 4. カスタムキーストア上のKMSキー作成
aws kms create-key \
  --origin AWS_CLOUDHSM \
  --custom-key-store-id <keystore-id> \
  --description "CloudHSM-backed CMK"

接続済みのカスタムキーストア上で作成したKMSキーは、S3のサーバーサイド暗号化（SSE-KMS）・EBSのボリューム暗号化・Secrets Managerのシークレット暗号化など、既存のKMS統合サービスをそのまま利用できます。

KMS Custom Key Storeの主な制限事項は次のとおりです。

• 非対称キー（RSA/ECC）は自動ローテーション非対応（手動ローテーションのみ）
• CloudHSMクラスターが停止すると、カスタムキーストアも利用不可になります
• 1つのカスタムキーストアあたりの接続は1クラスターのみです

7-2. PKIユースケース — プライベートCAとACM Private CA連携

プライベートCAのルート鍵をCloudHSMで保護するパターン

社内PKI基盤を構築する際、ルートCA秘密鍵の保護は最優先事項です。CloudHSMを利用することで、ルートCA鍵をHSM外部に持ち出せない状態で管理できます。

OpenSSLのエンジン設定でCloudHSMを利用する場合、次のような手順で証明書を発行します。

# CloudHSM PKCS#11対応のOpenSSL Engineを使うための環境変数設定
export CLOUDHSM_PIN="<cu-user>:<cu-password>"

# HSMにRSA鍵を生成（鍵素材はHSM外に出ない）
openssl genrsa \
  -engine cloudhsm \
  -keyform engine \
  2048 -out hsm:root-ca-key

# HSM内の鍵でCSRを作成
openssl req \
  -engine cloudhsm \
  -keyform engine \
  -new \
  -key hsm:root-ca-key \
  -out root_ca.csr \
  -subj "/CN=Private Root CA/O=MyOrg"

# 自己署名でルートCA証明書を発行
openssl x509 \
  -engine cloudhsm \
  -keyform engine \
  -req \
  -in root_ca.csr \
  -signkey hsm:root-ca-key \
  -days 3650 \
  -out root_ca.crt

この構成では、秘密鍵（hsm:root-ca-key）がHSM外に出ることなく証明書を発行できます。ルートCA鍵の漏洩リスクをハードウェアで封じ込める最も確実な方法です。

ACM Private CAとCloudHSMの関係

ACM Private CA（プライベートCA）は、AWSが提供するマネージドPKIサービスです。ACM Private CAのルートCAは、AWS側のHSMに保管されます。

CloudHSMと組み合わせるパターンは次のとおりです。

• 社内プライベートCAの下位CAをACM Private CAで構成し、ルートCAのみCloudHSMで保護します
• ACM Private CAのOCSP（オンライン証明書ステータスプロトコル）と組み合わせ、発行した証明書の失効管理を自動化します

PKI設計において、CloudHSMをルートCA鍵の保護に限定し、日常の証明書発行はACM Private CAに委任する構成は、コストと運用負荷のバランスに優れています。

7-3. TLS/SSLオフロードとデータベース暗号化

TLS終端のオフロード — Nginx・Apache・ELB

CloudHSMを使ったTLSオフロードは、TLS秘密鍵をHSM内で保護しつつ、Webサーバーがそれを参照してTLSハンドシェイクを行う構成です。

Nginxの場合、CloudHSM SDKのOpenSSL Dynamic Engineを経由して秘密鍵を参照します。

# /etc/nginx/nginx.conf（抜粋）
ssl_engine cloudhsm;
ssl_certificate /etc/nginx/certs/server.crt;
ssl_certificate_key "engine:cloudhsm:tls-server-key";

本番環境でのTLSオフロード設計のポイントは次のとおりです。

• HSMを複数AZに配置し、クライアントSDKのロードバランシングを有効にします
• TLSハンドシェイクはHSMへのネットワーク往復を要するため、レイテンシ要件を事前に測定します
• スループットが高い場合はHSMインスタンス数を増やして並列処理能力を確保します

Oracle Database TDE（Transparent Data Encryption）

Oracle DatabaseのTDEマスター暗号鍵をCloudHSMで管理する構成は、PCI DSSや金融規制に対応するデータベース暗号化の代表的なパターンです。

Oracle側の設定（概要）は次のとおりです。

1. OracleのExternal Keystoreを設定し、CloudHSM PKCS#11ライブラリを参照させます
2. TDEマスター鍵をHSM上で生成します
3. TDEが有効なTablespaceを作成し、データを暗号化します

-- TDE External Keystore (PKCS#11) の設定例
ADMINISTER KEY MANAGEMENT
  SET KEYSTORE OPEN
  IDENTIFIED BY EXTERNAL STORE;

ADMINISTER KEY MANAGEMENT
  SET KEY
  USING TAG 'cloudhsm-tde-key'
  IDENTIFIED BY EXTERNAL STORE;

Oracle TDEのマスター鍵がHSM上にある場合、DBAがデータファイルを直接コピーしても復号できません。物理的なメディア盗難リスクを排除できます。

SQL Server EKMによるTDE

SQL Serverも同様にEKM（Extensible Key Management）プロバイダー経由でCloudHSMと連携できます。SQL Server on EC2とCloudHSMの組み合わせで、HSMバックTDEを実現します。設定の基本手順は次のとおりです。

1. CloudHSM Client SDKをEC2インスタンスにインストール
2. SQL Server向けEKMプロバイダーDLLをインストール
3. SQL ServerにCREATECRYPTOGRAPHIC PROVIDERを実行してCloudHSMを登録
4. EKM KEY（Asymmetric Key）をCloudHSM上の鍵に紐付け
5. DATABASE ENCRYPTION KEYを作成してTDEを有効化

マスター鍵がHSM外に出ないため、DBAによるデータベースファイルへの不正アクセスリスクを低減できます。

7-4. 既存セキュリティ基盤との連携と設計パターン

KMS Custom Key Store経由のサービス統合アーキテクチャ

既存のAWSサービス統合（S3 SSE-KMS/EBS/RDS/Secrets Manager）をCloudHSMバック鍵に移行する際の統合アーキテクチャについて説明します。

移行の基本ステップは次のとおりです。

1. CloudHSMクラスターを作成し、既存VPCに配置します
2. KMS Custom Key Storeを作成してCloudHSMクラスターに接続します
3. 新しいCMKをCustom Key Store上に作成します
4. S3バケット・EBSボリューム・Secrets Managerシークレット等の暗号化キーを段階的に切り替えます

S3のSSE-KMSキー切り替え例：

# 既存バケットのSSE-KMSキーをCustom Key Store上のCMKに変更
aws s3api put-bucket-encryption \
  --bucket my-secure-bucket \
  --server-side-encryption-configuration '{
 "Rules": [{
"ApplyServerSideEncryptionByDefault": {
  "SSEAlgorithm": "aws:kms",
  "KMSMasterKeyID": "arn:aws:kms:ap-northeast-1:123456789012:key/<cloudhsm-backed-key-id>"
}
 }]
  }'

マルチアカウントでの鍵基盤設計

大規模組織では、CloudHSMクラスターを専用のセキュリティアカウントに集中配置し、他のワークロードアカウントはKMS Custom Key Store経由で利用する設計が有効です。

この設計のメリットは次のとおりです。

• HSMの管理権限をセキュリティチームに集約できます
• ワークロードアカウントはKMS APIで透過的に利用できます（CloudHSMを直接意識しません）
• セキュリティアカウントのCloudTrailで全鍵操作を一元監査できます

SOC/SIEM連携

SOC/SIEM連携では、CloudTrail Lakeを使ってCloudHSM関連のAPIコール（DescribeClusters・InitializeCluster・DeleteBackup）を専用のダッシュボードで監視します。異常なバックアップ削除や未認証の初期化試行をリアルタイムで検知する体制を整えることで、HSMインフラの完全性を保証できます。

KMSセキュリティ基盤との連携については、既存のAWS Security 本番運用 Vol3（KMS・シークレット管理）を参照することで、Custom Key Store設計の位置づけをより明確に理解できます。

8. 詰まりポイントとアンチパターン・まとめ

CloudHSMの本番運用では、専有HSMならではの落とし穴が存在します。本セクションでは、現場で頻出する詰まりポイントとアンチパターン、そして次のステップを示します。

8-1. よくある詰まりポイント

CloudHSMの本番運用で現場エンジニアが実際に遭遇する詰まりポイントを7件まとめます。HSM固有のユーザー権限モデルと手順の複雑さが多くの問題の根本原因です。

詰まりポイント1: CO・CU権限の混同による鍵操作失敗

症状: Crypto Officerとしてログインした状態で暗号化や鍵生成を試みると、権限エラーが発生する。

原因: CloudHSMにはCrypto Officer（CO）とCrypto User（CU）という2種類のユーザーロールがあり、役割が厳密に分離されています。COはユーザー管理（ユーザーの作成・削除・パスワード変更）を担当し、暗号操作は一切できません。CUが鍵の生成・暗号化・署名などの暗号操作を担当します。

対処: アプリケーションからHSMを操作する際はCUアカウントを使用し、COアカウントはユーザー管理専用として分離してください。COアカウントをアプリケーションに持たせることは権限過多であり、セキュリティリスクにもなります。

詰まりポイント2: クォーラム認証の設計ミス

症状: HSM上での重要操作（CO削除・クォーラム設定変更など）が1名の操作者だけで完了してしまう、または逆にクォーラム人数を満たせず操作が永続的にブロックされる。

原因: クォーラム認証（M of N）の設定が実運用体制と合っていない。

対処: M of Nの「N」（総承認者数）は実際に鍵に常時アクセスできる人数で設定し、「M」はセキュリティポリシーと運用体制のバランスで決定します。例えば担当者が3名であれば「3中2」が現実的です。担当者が退職・異動してクォーラムを満たせなくなると復旧が困難になるため、後継者を含めた設計が不可欠です。

詰まりポイント3: hsm1.medium EOL未対応による突然の停止リスク

症状: 2026年3月31日以降にhsm1.mediumのHSMがサポート対象外となり、セキュリティアップデートが止まる。FIPSコンプライアンス審査で認証取得ができなくなる。

原因: hsm1.mediumのEOLを見落としており、移行計画が策定されていない。

対処: AWSコンソール（CloudHSM > クラスター > HSMインスタンスタイプ）でhsm1.mediumが残っていないか確認し、残っていれば直ちにhsm2m.mediumへの移行計画を立ててください。移行はゼロダウンタイムで実施できます（§4参照）。

詰まりポイント4: マルチAZ未設定でのHSM障害による鍵アクセス不能

症状: 単一AZのHSM1台だけで構成していたところ、そのAZが障害になり鍵操作が完全に停止する。

原因: シングルAZ・シングルHSM構成での可用性過信。CloudHSMにはRDSのマルチAZ自動フェイルオーバーのような自動化された冗長化は含まれません。顧客が自ら複数AZへのHSM配置を設計する必要があります。

対処: 本番環境では必ず異なるAZに最低2台のHSMを配置します。コスト増を理由にシングルAZ構成を選択する場合は、障害時にサービスが完全停止することを事前に受け入れた上で判断してください。

詰まりポイント5: PKCS#11初期化手順の抜け漏れ

症状: PKCS#11ライブラリを呼び出すと「CKR_TOKEN_NOT_RECOGNIZED」などの初期化エラーが発生する。

原因: CloudHSMクライアントSDKのインストール後に必要な設定ファイルの配置・証明書登録・クラスターID設定などの手順が不完全。

対処: AWS公式ドキュメント（CloudHSM Client SDK 5 PKCS#11 Setup）の手順を1ステップずつ確認し、特にconfigure-pkcs11コマンドの実行と接続先クラスターIDの設定を漏れなく実施してください。SDK 5ではconfigure-dynによる設定も必要です。

詰まりポイント6: KMS Custom Key Store削除時の鍵消失リスク

症状: KMS Custom Key Storeを削除したところ、KMSのCMK（カスタマーマネージドキー）でアクセスしていた暗号化データが復号できなくなる。

原因: Custom Key StoreはCloudHSM上の鍵をKMS CMKとして利用する仕組みです。Custom Key StoreやCloudHSMクラスターを削除すると、KMS CMKの暗号化マテリアルが消滅し、そのCMKで暗号化されたすべてのデータが永続的に復号不能になります。

対処: KMS Custom Key Storeを使ったCMKで暗号化したデータを持つ場合は、CloudHSMクラスターのバックアップを長期保存し、削除前にそのCMKでの暗号化データが存在しないことを確認してください。

詰まりポイント7: バックアップからのリストア手順の誤り

症状: CloudHSMバックアップから新しいクラスターをリストアしたが、鍵が使えない。アプリケーションからHSMへの接続が失敗する。

原因: バックアップからリストアしたクラスターは新しいクラスターIDを持ちます。クライアントSDKの設定ファイルが古いクラスターIDを参照したままになっているケースが多いです。また、リストア後にはCrypto OfficerとCrypto Userの認証情報（パスワード）が必要です。

対処: リストア後は新しいクラスターIDをクライアントSDKの設定ファイルに反映し、接続テストを実施してから本番トラフィックを切り替えます。CO/CUのパスワードはAWS Secrets Managerなど安全な鍵管理システムで別途保管してください。

8-2. アンチパターン → 正解

CloudHSM運用でよくあるアンチパターンと推奨される代替策を表形式で整理します。

アンチパターン詳説: シングルAZ構成の落とし穴

クラウドサービスを利用している感覚で「AWSが可用性を担保してくれるはず」と思い込み、HSMを1台だけ配置するケースは散見されます。CloudHSMはマネージドサービスですが、クラスター内のHSM台数と配置はお客様自身の責任です。シングルAZに1台だけのHSMは、AZ障害で即座に鍵操作が停止します。KMSと違い、CloudHSMは可用性設計を顧客自身で行う必要があることを必ず理解してください。

アンチパターン詳説: CO権限の誤使用

CloudHSMのCO（Crypto Officer）とCU（Crypto User）の役割分担は、COが暗号操作を一切実行できない点が重要です。COでセッションを確立しようとした場合、暗号APIの呼び出しが失敗します。アプリケーションのHSM接続には必ずCUアカウントを使用し、COアカウントはAWS Secrets Managerなどで厳重に保管します。

アンチパターン詳説: KMS代替としての安易なCloudHSM導入

CloudHSMの月次コストはHSM台数に比例し、2AZ×各1台でも月額約2,300ドルになります。KMSのCMKが月額1ドル以下であることを考えると、コスト差は明らかです。CloudHSMが本当に必要なケースは「FIPS 140-3 Level 3の専有HSMが規制・監査で明示的に求められる場合」「PKIルート鍵など鍵の物理的所有権が最優先の場合」に絞られます。KMSのCustomer Managed Key・Key Policy・SCP・Multi-Region Keyの組み合わせを先に十分に検討することをお勧めします。

8-3. まとめと次のステップ

本記事では、AWS CloudHSMの専有HSM/鍵管理本番運用について、以下のトピックを解説しました。

Vol1のまとめ

• CloudHSM基礎: クラスター・HSMインスタンス・クラスターメンバー間の鍵自動同期・クライアントSDK（§2）
• マルチAZ可用性設計: 各AZへのHSM分散配置・コスト倍増の注意点・クォーラム設計（§2）
• hsm2m.medium: FIPS 140-3 Level 3準拠・hsm1.medium EOL 2026-03-31の早急な移行必要性（§2・§4）
• セットアップ&運用: クラスター初期化・CO/CU権限管理・バックアップ・監視（§3）
• hsm1→hsm2m移行: ゼロダウンタイム移行手順・クライアントSDK 5・2025-12ファームウェア改善（§4）
• アプリ統合: PKCS#11/JCE/OpenSSL Dynamic Engine・KMS Custom Key Store連携（§5）
• セキュリティ・コンプライアンス: FIPS 140-3の意義・KMSとの使い分け・コスト構造（§6）
• 実戦統合パターン: KMS Custom Key Store・PKIルート鍵保護・TLS/Oracle TDE・既存セキュリティ基盤連携（§7）

AWS CloudHSMが提供する価値

CloudHSMの本質的な価値は「AWSも触れない完全顧客専有の暗号鍵基盤」にあります。FIPS 140-3 Level 3準拠の専有HSMが求められる規制業界、PKIルート鍵保護、決済暗号（PCI PIN）など、最高水準の鍵所有権保証が必要なワークロードに最適です。

KMSとの使い分けを迷う場合は「鍵の所有権と物理的専有が規制・監査で明示的に求められるか」を判断基準にしてください。そうでない場合はKMSのCMKとKey Policy・SCPの組み合わせで大半のセキュリティ要件を満たせます。

Vol2予告

次回Vol2では、以下のより高度なトピックを扱う予定です。

• KMS Custom Key Storeを使った高度なアーキテクチャパターン（自動ローテーション・マルチリージョン）
• 大規模CloudHSMクラスターの運用自動化（Terraform / CloudFormation）
• Oracle TDE・コード署名・PKI CAのCloudHSM統合実装の詳細
• マルチアカウント・マルチリージョンでのCloudHSMクラスター設計

103記事達成の節目となるVol1をご覧いただきありがとうございます。Vol2でさらに深い実装知識をお届けします。

CloudHSM導入・運用チェックリスト

本番稼働前に以下の項目を必ず確認してください。

よくある質問（FAQ）

Q1: CloudHSMとKMS Custom Key Storeは何が違いますか？

CloudHSMはHSMハードウェアを顧客が直接操作する専有サービスです。鍵の生成・管理・削除はすべて顧客責任です。KMS Custom Key Storeは、CloudHSM上の鍵をKMS CMKのバックエンドとして利用する連携機能です。Custom Key Storeを使うと、KMS APIの利便性とCloudHSMの専有保護を両立できます。ただし、Custom Key Store削除時は暗号マテリアルが消滅するため、削除前の確認が必須です。

Q2: CloudHSMのフェイルオーバーはKMSのように自動ですか？

いいえ、CloudHSMには自動フェイルオーバー機能はありません。クラスター内の複数HSMへの負荷分散と接続先の自動選択はクライアントSDKが行いますが、「どのAZに何台配置するか」は顧客の設計責任です。AZ障害時に鍵操作が継続できるよう、必ず複数AZにHSMを分散配置してください。

Q3: FIPS 140-3 Level 3は規制対応で必須ですか？

規制や業界標準によって異なります。日本のFISC（金融情報システムセンター）ガイドラインや金融庁要件では、HSM利用が「推奨」または「必須」とされるケースがあります。一方、多くの一般的なシステムではKMSのCustomer Managed Keyと適切なポリシーで十分です。「規制文書でHSMまたはFIPS Level 3が明示されているか」が選択の判断基準です。

Q4: クライアントSDK 5への移行は難しいですか？

SDK 3からSDK 5への移行は設定ファイルのパスと認証方法の変更が主な作業です。PKCS#11/JCEのAPIは同一なため、アプリケーション側のコード変更はほぼ不要です。ただし、クラスターIPアドレスではなくAWS CloudHSM管理エンドポイントを使用する点が異なります。テスト環境で動作確認してから本番移行することをお勧めします。

Q5: マルチリージョンでCloudHSMを使うにはどうすればよいですか？

CloudHSMのバックアップは手動でリージョン間コピーが可能です。DR用途では、別リージョンにバックアップからリストアした新しいクラスターを起動します。ただし、リージョン間でHSMクラスターをリアルタイム同期する機能はないため、DR時のRTO（回復時間目標）には数十分〜数時間の復旧時間を見込む設計が必要です。Vol2ではマルチリージョン設計のベストプラクティスを詳しく解説します。

Q6: CloudHSMのコストを削減する方法はありますか？

CloudHSMはHSMインスタンス数と稼働時間に比例した課金です。開発・テスト環境では稼働時間を最小限に抑えるため、使用しない時間帯にHSMを削除し、バックアップから再起動する運用が有効です。ただし、本番環境ではHA要件上、複数HSMの常時稼働が必要です。コスト最適化よりも、「KMSで代替できないワークロードか否か」の見極めが最大の節約ポイントです。

Q7: CloudHSMとAWS Secrets Managerを一緒に使う場合の注意点は？

CloudHSMで暗号化した鍵マテリアルやCO/CUパスワードをSecrets Managerで保管するパターンは一般的です。ただし、Secrets Managerの暗号化にはKMS CMKが使われます。CloudHSM-backed KMS Custom Key StoreのCMKでSecrets Managerを暗号化すると、CloudHSMが停止した場合にSecrets Manager内のCO/CUパスワード自体にもアクセスできなくなる循環依存が生まれます。CO/CUパスワードの保管先は、CloudHSM-backed CMKではないKMS CMKで暗号化したSecrets Managerを推奨します。

CloudHSM vs KMS 意思決定チャート

以下の質問を順番に確認し、最初に「YES」となった時点でその選択肢を採用してください。

1. 規制・監査でFIPS 140-3 Level 3専有HSMが明示的に求められるか？
   → YES: CloudHSMを採用する
   → NO: 次の質問へ

2. 鍵の物理的専有権（AWSも触れない保証）が必須要件か？
   → YES: CloudHSMを採用する
   → NO: 次の質問へ

3. PKIルート認証局（Root CA）の秘密鍵を保護する必要があるか？
   → YES: CloudHSMを採用する（KMSではルートCA鍵のエクスポートが制御しにくい）
   → NO: 次の質問へ

4. PCI PIN・HSM暗号処理（PIN Block生成など）が要件か？
   → YES: CloudHSMを採用する
   → NO: KMSのCustomer Managed Key + Key Policy + SCP で要件を満たす可能性が高い

この判断チャートに当てはまらないケースでCloudHSMを検討している場合は、コストと運用負荷（月額2,300 USD〜・CO/CU管理・バックアップ・クォーラム設計はすべて顧客責任）を踏まえて慎重に評価することをお勧めします。