AWS CloudHSM

解決する課題

• 暗号鍵を AWS にも一切見せず、自分だけが完全に支配する形で管理したい
• FIPS 140 準拠の専有ハードウェアでの鍵保護を、コンプライアンスや規制で求められている
• データベースの透過的暗号化や公開鍵基盤の署名処理など、**標準の暗号ライブラリ（PKCS#11・JCE・OpenSSL 等）**から HSM を使いたい
• 自前で HSM アプライアンスを購入・設置・冗長化する運用負荷から解放されたい

AWS CloudHSM は、FIPS 140 準拠のハードウェアセキュリティモジュール（HSM）を、利用者専有の形でクラウド上にマネージド提供するサービスです。鍵の生成・保管・暗号処理をすべて HSM 内部で完結させ、鍵素材を平文で外に出さないまま、利用者が鍵を単独で完全に管理できます。

主要概念と用語

• HSM（ハードウェアセキュリティモジュール）: 暗号鍵の生成・保管・暗号処理を物理的に隔離して行う専用ハードウェア。鍵素材を外部に平文で取り出せないよう設計されている
• クラスター: 複数の HSM をまとめた論理単位。クラスター内の HSM は鍵を自動的に同期し、可用性と耐久性を高める
• 専有（シングルテナント）: HSM は利用者専用に割り当てられ、他の利用者と共有しない。マルチテナントの KMS との大きな違い
• CO（Crypto Officer）／CU（Crypto User）: HSM 内のユーザー種別。CO は HSM とユーザーの管理を、CU は実際の暗号操作（鍵の作成・暗号化・署名など）を担う
• クライアント SDK: アプリケーションが HSM と通信するためのソフトウェア。PKCS#11・JCE・OpenSSL エンジン・KSP/CNG などの標準インターフェースを提供する
• FIPS 140: 米国の暗号モジュール認証規格。CloudHSM はこの認証を受けたハードウェアで動作する
• クォーラム認証（M of N）: 重要な操作に複数の管理者の承認を必要とする仕組み。単独の管理者による不正操作を防ぐ
• KMS カスタムキーストア: KMS の鍵素材を CloudHSM クラスターに保管する連携機能。KMS の使いやすさと HSM の専有性を両立する

仕様・制限・クォータ

• 鍵の管理責任は利用者にある: 鍵の生成・バックアップ・ユーザー管理は利用者が行う。AWS は HSM のハードウェアと運用基盤を管理するが、鍵には関与しない
• VPC 内に配置される: HSM はクラスターとして利用者の VPC 内に ENI を持ち、プライベートに接続する。インターネット経由の直接アクセスはしない
• クラスターで冗長化: 単一 HSM だと可用性・耐久性に欠けるため、複数 AZ にまたがる複数 HSM でクラスターを組むのが前提。鍵はクラスター内で同期される
• 標準インターフェース対応: PKCS#11・JCE・OpenSSL・KSP/CNG といった業界標準ライブラリから利用でき、既存アプリの暗号処理を載せ替えやすい
• 対称・非対称の両方に対応: AES などの対称鍵、RSA・ECC などの非対称鍵、ハッシュ・署名・乱数生成といった一般的な暗号操作をサポートする
• バックアップ: クラスターのバックアップが定期的に取得され、暗号化された状態で保管される。リージョン間でのコピーにも対応する
• HSM の数や鍵の容量などには上限があり、要件に応じて HSM を追加したり上限緩和を申請したりする

内部の仕組み

CloudHSM の中核は「専有 HSM」と「クラスターによる鍵同期」です。利用者は VPC 内にクラスターを作成し、複数の AZ に HSM を配置します。各 HSM は FIPS 140 認証を受けた物理デバイスで、鍵の生成・保管・暗号処理をすべて内部で完結させ、鍵素材を平文で外に出しません。

クラスター内の複数 HSM は鍵を自動的に同期します。ある HSM で作成した鍵は他の HSM にも反映され、1つの HSM が障害を起こしても他の HSM が処理を継続できます。これにより、単一ハードウェアの故障に対する可用性と、鍵の耐久性を確保します。

アプリケーションはクライアント SDK を通じて HSM と通信します。PKCS#11 や JCE などの標準ライブラリ経由で暗号化・復号・署名・検証を依頼すると、実際の演算は HSM 内部で行われ、結果だけがアプリケーションに返ります。鍵そのものはアプリケーション側に渡らないため、アプリが侵害されても鍵は HSM 内に留まります。

AWS は HSM のハードウェア交換や基盤の運用を担いますが、HSM 内のユーザーや鍵は利用者だけが管理します。AWS の運用担当者であっても鍵素材を取り出せない設計になっており、これが「鍵を AWS にも見せない」という CloudHSM の最大の特徴を支えています。

設計パターン / ベストプラクティス

• 複数 AZ・複数 HSM で冗長化する: 可用性と耐久性のため、最低でも2台以上の HSM を別 AZ に配置してクラスターを組む
• まず KMS で足りるか検討する: 多くの暗号化要件はマネージドで安価な KMS で満たせる。専有 HSM や独自ライブラリ連携が必須のときだけ CloudHSM を選ぶ
• KMS カスタムキーストアで両取りする: KMS の使いやすさと AWS サービス統合を保ちつつ、鍵素材を専有 HSM に置きたい場合は KMS カスタムキーストア連携を使う
• ユーザー権限を CO と CU で分離する: 管理操作と暗号操作の権限を分け、最小権限で運用する
• クォーラム認証を有効化する: 鍵の削除やユーザー管理など重要操作に複数管理者の承認を要求し、単独の不正・誤操作を防ぐ
• バックアップを保全する: クラスターバックアップを確実に保管し、必要に応じてリージョン間コピーで災害対策とする

運用・監視

• クラスターと HSM の健全性を監視する: HSM の台数・状態を定期的に確認し、障害が起きた HSM はクラスターから外して新しい HSM を追加する
• 監査ログを取得する: HSM 内の操作はログとして記録でき、CloudWatch Logs などに集約して誰がどの操作を行ったかを追跡する
• API 操作を監査する: クラスターや HSM の作成・削除といった管理 API は CloudTrail に記録される。鍵そのものの操作ログとは別物である点に注意する
• バックアップの取得状況を確認する: 自動バックアップが想定どおり取得・保管されているかを定期的に検証する
• クライアント SDK のバージョンを保つ: SDK や HSM のソフトウェアは更新され、古い構成は互換性や脆弱性の問題を生むため、計画的に更新する

コスト

• HSM ごとに時間課金: 稼働している HSM の台数と稼働時間に応じて料金が発生する。冗長化のために台数を増やすほど費用も積み上がる
• 常時稼働が前提: HSM は鍵を保持し続けるため基本的に止められず、稼働分の課金が継続する。KMS のようなリクエスト単価とは課金モデルが異なる
• KMS との比較で割高になりやすい: マネージドかつ安価な KMS に比べ、専有ハードウェアである CloudHSM は単価が高い。専有性が本当に必要かをコスト面でも見極める
• 台数設計がコストを左右する: 可用性要件と費用のバランスで HSM 台数を決める。過剰な冗長化は無駄なコストになる

セキュリティ

• 鍵を AWS にも見せない: 鍵素材は HSM 内で生成・保管され、平文で外に出ない。AWS の運用担当者も鍵を取り出せず、利用者が単独で支配する
• FIPS 140 準拠ハードウェア: 認証済みの物理 HSM で動作し、規制・コンプライアンス要件に応えやすい
• ユーザーと操作の分離: CO と CU でユーザー種別を分け、IAM とは別に HSM 内部でのアクセス制御を行う
• クォーラム認証で多重承認: 重要操作に複数管理者の承認を要求し、単独管理者による不正を防ぐ
• VPC 内のプライベート接続: HSM は VPC 内に閉じており、ネットワーク経路を限定して外部からの到達面を絞る
• 監査ログで証跡を残す: HSM 内の操作ログを集約し、暗号操作の監査と異常検知に使う

関連サービス・比較

CloudHSM は専有 HSM を直接扱うサービス、KMS は鍵管理をマネージドに代行するサービスで、抽象度と責任分界が大きく異なります。両者の違いを整理します。

ハンズオン / CLI例

# CloudHSM クラスターを作成（VPC 内のサブネットを指定）
aws cloudhsmv2 create-cluster \
  --hsm-type hsm1.medium \
  --subnet-ids subnet-aaaa1111 subnet-bbbb2222 \
  --region ap-northeast-1

# 作成したクラスターの状態を確認
aws cloudhsmv2 describe-clusters --region ap-northeast-1

# クラスターに HSM を追加（冗長化のため別 AZ に配置）
aws cloudhsmv2 create-hsm \
  --cluster-id <クラスターID> \
  --availability-zone ap-northeast-1c \
  --region ap-northeast-1

# クラスターのバックアップ一覧を確認
aws cloudhsmv2 describe-backups --region ap-northeast-1