AWS CloudHSM
1. サービス概要¶
AWS CloudHSM は、ハードウェアセキュリティモジュール(HSM)を AWS 上で専用に利用できるようにした、クラウドベースのハードウェア暗号化サービスである。
従来のオンプレミスでの HSM 運用に近い形で鍵を管理・保持できるため、高いセキュリティ要件や規制準拠（PCI DSS、FIPS 140-2 レベル 3 など）に対応する用途に活用される。
主なユースケースとしては、
- 金融や保険
- 公共機関などの厳格な規制下にある機関での鍵管理
- 大規模な暗号処理（証明書発行、鍵生成、TLS/SSL セッションの終端処理など）
がある。
ユーザーが鍵を完全に所有し、AWS 側でも読み出しできない点が特徴である。
2. 主な特徴と機能¶
2.1 専用ハードウェアによる強固な鍵管理¶
CloudHSM は AWS が提供する物理的な HSM アプライアンスをユーザー専用に割り当てます。
これにより、共用基盤ではなく専有環境で鍵を保持できるため、シングルテナントかつ高いセキュリティ隔離を実現する。
- 完全な鍵管理: HSM 内の鍵はユーザーのみが制御し、AWS はアクセス不可
- 高速暗号処理: 専用ハードウェアが暗号演算を高速かつ安全に実行
2.2 FIPS 140-2 準拠¶
CloudHSM は FIPS 140-2 レベル 3 に準拠しており、高度な暗号鍵管理やハードウェアセキュリティを要する業界向けの要件を満たする。
カード決済業界の PCI DSS 要件など、厳格なコンプライアンスにも対応可能である。
2.3 スケーラビリティと可用性¶
必要に応じてクラスタを構成し、複数の CloudHSM インスタンスを展開することで、高可用性と負荷分散を実現できる。
フェイルオーバー時にも鍵が失われないように自動レプリケーションされ、ダウンタイムの短縮に貢献する。
2.4 柔軟な API サポート¶
PKCS#11 や JCE(Java Cryptography Extensions)、OpenSSL エンジンなど、業界標準の暗号 API をサポートしており、既存のアプリケーションとの統合が容易である。
これによりオンプレミスからクラウドへの移行時や、カスタム暗号ロジックの実装がスムーズに行える。
2.5 AWS Key Management Service(AWS KMS)との比較¶
CloudHSM はユーザーが鍵を完全に制御する一方、KMS は AWS によるフルマネージドでの鍵管理が可能である。
クラウドネイティブな運用性を求めるなら KMS、より厳格な鍵所有を求めるなら CloudHSM、と使い分けるケースが一般的である。
3. アーキテクチャおよび技術要素¶
- CloudHSM クラスタを作成し、VPC のサブネットに専用 HSM アプライアンスを配置
- アプリケーションサーバは PKCS#11 等の暗号 API を介し、HSM で鍵生成・暗号化・復号化を実行
- 鍵や証明書は HSM 内部に安全に保管され、AWS 側からはアクセス不可
- クラスタによって複数の HSM 間で自動的に鍵がレプリケートされ、高可用性を確保
クライアントソフトウェア(AWS CloudHSM Client)を利用することで、アプリケーションはクラウド上の HSM をローカルの HSM と同様に扱えます。
4. セキュリティと認証・認可¶
CloudHSM はハードウェアレベルでのセキュリティ保護を提供する:
- ハードウェア要塞化: 物理的に改ざんされると自動的に鍵を破棄する仕組み
- アクセスコントロール: CloudHSM 内の鍵操作はユーザーが作成するトークン認証(PKCS#11 の PIN など)を利用
- ネットワーク分離: VPC 内のプライベートサブネットに配置し、許可された EC2 やオンプレミス環境からのみアクセスを許可
5. 料金形態¶
AWS CloudHSM の料金は、主に以下の要素に基づきます:
- HSM インスタンスの時間単位料金: 稼働している HSM アプライアンス 1 台あたりの時間単位の従量課金
- クラスタ台数: 高可用性確保のために複数台を起動する場合、台数に応じた料金が加算
- データ転送料金: 通常は VPC 内通信のためコストは低いが、プライベート接続形態などで追加費用が発生する場合もあり
6. よくあるアーキテクチャ・設計パターン¶
CloudHSM を導入する代表的なパターンは以下の通りです:
- PCI DSS 準拠環境: クレジットカード情報の暗号化やトランザクション処理をクラウドで安全に行う
- SSL/TLS 終端: Web サーバの SSL 証明書を CloudHSM 内に格納し、高速な TLS ハンドシェイクを実行
- 証明書発行基盤(CA)の構築: ルート証明書を HSM 内で厳格に管理し、PKI 基盤のセキュリティを高める
- KMS 連携: CloudHSM で生成したカスタマー管理キー(CMK)を KMS にインポートし、用途によって使い分け
7. 設定・デプロイ手順（ハンズオン例）¶
- VPC とサブネットを準備し、プライベートサブネット内に CloudHSM クラスタを作成
- CloudHSM クライアントソフトウェアを EC2 インスタンスにインストール
- クラスタへ接続し、鍵生成やユーザーアカウント設定を行う
- アプリケーション側は PKCS#11/JCE/OpenSSL 等の API を通じて HSM での暗号操作を実行
- 複数台のクラスタ構成により高可用性を確認
8. 試験で問われやすいポイント¶
8.1 KMS との違い¶
- CloudHSM: ユーザーが鍵をフル制御。専用ハードウェアで FIPS 140-2 レベル 3 に準拠
- KMS: マルチテナントかつフルマネージド。AWS サービスとの統合が容易
- 使い分け: 厳格な鍵所有が必要 →CloudHSM、クラウドネイティブ運用 →KMS
8.2 セキュリティとコンプライアンス¶
- FIPS 140-2: レベル 3 に適合し、物理的改ざん対策に優れる
- PCI DSS: カード情報保護要件などの厳格な規制に対応
- 鍵所有モデル: AWS が鍵にアクセスできず、ユーザーのみが制御
8.3 アーキテクチャ設計¶
- クラスタ構成: 複数の HSM を配置して高可用性とフォールトトレランスを確保
- VPC プライベートサブネット: ネットワーク的にも隔離してリスクを最小化
- API 互換性: PKCS#11、JCE、OpenSSL など既存アプリとのインテグレーションが容易
8.4 運用管理と可用性¶
- メンテナンス: AWS がハードウェアを管理し、利用者は論理的な鍵管理に集中
- 自動フェイルオーバー: クラスタが故障しても鍵レプリケーションにより継続運用
- 監視ツール: CloudWatch などで HSM インスタンスの状態や CPU 負荷を把握
8.5 料金最適化¶
- 必要な台数のみ: 本番/ステージング環境それぞれの最小限の HSM クラスタ数を設定
- 稼働時間の制御: テスト環境で不要時は HSM を停止し、コストを抑える
- 通信コスト: 主に VPC 内通信のため低コストだが、オンプレミス接続の場合は設計を最適化
8.6 試験で頻出となる具体的な問われ方と答え¶
- Q: AWS KMS と CloudHSM の違いは？
- A: 鍵管理の方法や責任分界。CloudHSM はユーザー専用 HSM で鍵を完全所有、KMS は AWS マネージド。
- Q: FIPS 140-2 レベル 3 のメリットは？
- A: 物理的改ざんに対する耐性と厳格な暗号モジュール認証で、高いコンプライアンス要件を満たせる。
- Q: PKCS#11 を使う理由は？
- A: 多くの暗号アプリケーションとの互換性が高く、既存システムとの統合が容易になるため。
- Q: CloudHSM の運用で気をつける点は？
- A: HSM クラスタの可用性確保、VPC 内のネットワーク設計、鍵のバックアップ方針など。
- Q: クラスタを構成するメリットは？
- A: フェイルオーバーによるダウンタイムの回避、暗号処理負荷の分散、高可用性の実現。