AWS CloudHSM

初心者から実務者向けの包括的解説

AWS CloudHSM は、FIPS 140-2/140-3 Level 3 認証 ハードウェアセキュリティモジュール（HSM）をマネージドサービスとして提供し、暗号鍵の生成・保管・使用を 顧客が完全に制御 できるセキュリティサービスです。KMS とは異なり、鍵マテリアルは AWS が一切アクセスできない物理 HSM 内に保護され、PKCS#11・JCE・KSP・OpenSSL Engine を通じて暗号化・復号・署名操作を実行。金融機関・医療機関・規制業界における 高度な鍵管理・コンプライアンス を実現します。このページでは、CloudHSM の仕組み・クラスタ管理・統合方式・運用設定・BYOK パターンを体系的に解説します。

このページの目的

このページでは以下を対象としています：

• コンプライアンス担当者：FIPS 140-3・PCI-DSS・医療機関向けセキュリティ要件対応
• セキュリティアーキテクト：HSM クラスタ設計・High Availability・Backup 戦略
• DevOps・運用者：CloudHSM クラスタ初期化・キー管理・トラブルシューティング
• 開発者向け：PKCS#11・JCE・OpenSSL による統合実装
• 意思決定者向け：KMS vs CloudHSM vs オンプレミス HSM（Thales/Entrust）

2025-2026 年の CloudHSM エコシステム

• KMS XKS（External Key Store）統合深化： オンプレミス・マルチクラウド HSM 連携
• Post-Quantum Cryptography 準備： 量子耐性暗号キー生成サポート
• Cluster Auto-Scaling：マネージド HA の簡素化
• FIPS 140-3 Level 3 継続対応：最新標準コンプライアンス
• Multi-Region Key Sync：グローバル HSM クラスタ管理

定義

AWS 公式による定義：

“AWS CloudHSM is a cloud-based hardware security module (HSM) that enables you to generate and use your own encryption keys on AWS Cloud.”

顧客が鍵の完全な制御・所有権を保持し、AWS も物理的にアクセス不可なセキュリティ境界を提供。

概要

初心者向けメモ： CloudHSM は「顧客完全制御の暗号鍵 金庫」です。KMS は AWS がキー管理を担当（一定レベルのセキュリティ）だが、CloudHSM では顧客が鍵マテリアルを生成・所有し、物理 HSM 内に閉じ込める。AWS 管理者も KMS 管理者も、その鍵を見ることができません。金融・医療・政府機関など、キー管理の完全な所有権・制御が必須な環境向け。

CloudHSM は、以下を実現する高度なキー管理プラットフォームです：

CloudHSM が解決する課題 {#課題}

1. キー管理の完全な所有権・コンプライアンス

課題：金融機関・医療機関は「顧客が生成した鍵を AWS も見てはいけない」という規制要件 CloudHSM の解決：顧客が鍵生成・AWS は物理アクセス不可

2. FIPS 140-3 Level 3 コンプライアンス

課題：高度なセキュリティ認証が必要（医療・金融・軍事） CloudHSM の解決：FIPS 140-3 Level 3 認証、改ざん検出・環境監視組み込み

3. オンプレミス HSM → クラウド への移行

課題：既存 HSM インフラをクラウドに置き換えたい CloudHSM の解決：Thales・Entrust HSM と同等のセキュリティ、AWS 統合

主な特徴 {#特徴}

1. FIPS 140-2/140-3 Level 3 認証

• Level 2：暗号化・デジタル署名レベル
• Level 3：物理セキュリティ・改ざん検出・リモートアクセス制限
• CloudHSM は Level 3 で、最高レベル

2. Multi-HSM Cluster（High Availability）

【HA 構成】
Primary HSM ────→ レプリケーション
Secondary HSM 1 → 自動フェイルオーバー
Secondary HSM 2 → 冗長性確保

3. 顧客完全制御・AWS の一切のアクセス不可

鍵マテリアル: HSM 内に保護
  ├─ 生成: 顧客（CloudHSM クライアント）
  ├─ 使用: 顧客アプリケーション
  └─ 削除: 顧客のコマンド

AWS の権限:
  ├─ ✓ インフラ管理（ハードウェア交換等）
  └─ ✗ 鍵の参照・使用・コピー

4. Protocol 多様性

• PKCS#11: 標準インターフェース（OpenSSL・Java 互換）
• JCE: Java Cryptography Extension
• KSP: Windows Cryptographic Service Provider
• OpenSSL Engine: OpenSSL コマンドライン互換

アーキテクチャ {#アーキテクチャ}

【図1】CloudHSM Cluster アーキテクチャ

graph TB
    subgraph "AWS VPC"
        App["アプリケーション<br/>EC2/Lambda"]
        Client["CloudHSM Client<br/>PKCS#11"]
        ENI1["ENI 1<br/>HSM 1"]
        ENI2["ENI 2<br/>HSM 2"]
        ENI3["ENI 3<br/>HSM 3"]
    end

    subgraph "CloudHSM Cluster"
        HSM1["HSM 1<br/>Primary"]
        HSM2["HSM 2<br/>Secondary"]
        HSM3["HSM 3<br/>Secondary"]
    end

    App -->|Connect| Client
    Client -->|PKCS#11| ENI1
    Client -->|Replicate| ENI2
    Client -->|Replicate| ENI3

    ENI1 --> HSM1
    ENI2 --> HSM2
    ENI3 --> HSM3

    HSM1 <-->|Sync| HSM2
    HSM1 <-->|Sync| HSM3

【図2】キー操作パイプライン

sequenceDiagram
    participant App as Application
    participant Client as CloudHSM Client
    participant HSM as HSM Device

    App->>Client: 1. Init Session
    Client->>HSM: Establish TLS Connection

    App->>Client: 2. Generate Key
    Client->>HSM: Generate Keypair
    HSM-->>Client: Key Handle（鍵参照）

    App->>Client: 3. Encrypt Data
    Client->>HSM: Encrypt（暗号化実行）
    HSM-->>Client: Ciphertext（暗号文）

    App->>Client: 4. Decrypt Data
    Client->>HSM: Decrypt（復号実行）
    HSM-->>Client: Plaintext（平文）

    App->>Client: 5. Delete Key
    Client->>HSM: Delete Keypair
    HSM-->>Client: OK

HSM Cluster・HA {#cluster}

クラスタ構成

3 HSM（Primary × 1 + Secondary × 2）で High Availability を実現。

【単一 HSM】
├─ 単一障害点あり
└─ 保守・アップデート時にダウン

【3-HSM Cluster】
├─ Primary HSM が故障 → Secondary に自動フェイルオーバー
├─ 保守中も他の HSM で継続動作
├─ 同期レプリケーション → 整合性保証
└─ 推奨構成（本番環境）

クラスタ初期化

# クラスタ作成
aws cloudhsm create-cluster \
  --subnet-ids subnet-12345678 \
  --security-group-ids sg-12345678 \
  --region us-east-1

# HSM 追加
aws cloudhsm create-hsm \
  --cluster-id cluster-abc123 \
  --availability-zone us-east-1a

# クラスタ初期化（Cluster Officer パスワード設定）
aws cloudhsm initialize-cluster \
  --cluster-id cluster-abc123 \
  --signed-cert path/to/signed-cert.pem

ユーザータイプ（CryptoUser/CryptoOfficer） {#usertype}

Precrypto Officer

HSM ファームウェア・パーティション初期化など、クラスタレベル管理。

Crypto Officer

ユーザー・ロール管理、キーの作成・削除許可。

Crypto User

キー操作（暗号化・復号・署名）のみ実行。

ロールベースアクセス制御

Partition Policy
  ├── Crypto Officer
  │   ├─ ✓ ユーザー管理
  │   ├─ ✓ キー管理ポリシー設定
  │   └─ ✓ 監査ログ確認
  │
  └── Crypto User
      ├─ ✓ キー暗号化・復号
      ├─ ✓ 署名生成
      └─ ✗ キー削除・ユーザー管理

PKCS#11・JCE・KSP・OpenSSL {#protocols}

PKCS#11（標準インターフェース）

// PKCS#11 による鍵生成・暗号化例
#include <pkcs11.h>

CK_SESSION_HANDLE hSession;
CK_MECHANISM mechanism = { CKM_RSA_PKCS_KEY_PAIR_GEN, NULL, 0 };

// キーペア生成
CK_RV rv = C_GenerateKeyPair(hSession, &mechanism,
                             publicKeyTemplate, publicKeyCount,
                             privateKeyTemplate, privateKeyCount,
                             &hPublicKey, &hPrivateKey);

// 暗号化
CK_MECHANISM encMechanism = { CKM_RSA_PKCS, NULL, 0 };
C_EncryptInit(hSession, &encMechanism, hPublicKey);
C_Encrypt(hSession, plaintext, plaintextLen,
          ciphertext, &ciphertextLen);

JCE（Java Cryptography Extension）

// JCE による鍵生成・署名例
import com.cavium.provider.CaviumProvider;
import java.security.KeyPairGenerator;
import java.security.Signature;

Security.addProvider(new CaviumProvider);

// 鍵ペア生成
KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA", "Cavium");
kpg.initialize(2048);
KeyPair keyPair = kpg.generateKeyPair;

// 署名生成
Signature sig = Signature.getInstance("SHA256withRSA", "Cavium");
sig.initSign(keyPair.getPrivate);
sig.update(data);
byte[] signature = sig.sign;

OpenSSL Engine

# OpenSSL で CloudHSM キーを使用
openssl engine -t cloudshm

# 証明書署名要求（CSR）生成
openssl req -new -engine cloudhsm \
  -keyform engine -key slotId:keyLabel \
  -out request.csr

キー生成・管理・ローテーション {#keymanagement}

キー生成パターン

パターン 1：CloudHSM で生成

最も安全: 鍵が HSM を離れない
  └─ CloudHSM クライアント → HSM で生成 → 暗号化

パターン 2：外部で生成 → CloudHSM にインポート

BYOK（Bring Your Own Key）
  └─ 顧客が生成したキー → CloudHSM にインポート
     ただし、インポート時は TLS で暗号化

キーローテーション戦略

【キー有効期限管理】
キー作成日: 2026-04-26
有効期限: 2027-04-25
  ├─ 1 年前警告（2026-04-25）
  ├─ 新キー生成開始
  └─ 段階的切り替え

【オンライン ローテーション】
1. 新キー生成
2. 新キーを使用開始（段階的）
3. 旧キー使用禁止
4. 旧キー削除

KMS XKS（External Key Store）統合 {#xks}

KMS XKS の仕組み

KMS が CloudHSM に外部委譲：

アプリケーション
  │
  ├─ KMS API: GenerateDataKey
  │   └─ KMS: CloudHSM に委譲
  │       └─ CloudHSM: 実際の暗号化実行
  │
  └─ Plaintext Data Key 取得（アプリが暗号化実行）

セットアップ

# KMS Custom Key Store 作成（CloudHSM バックアップ）
aws kms create-custom-key-store \
  --custom-key-store-name my-hsm-store \
  --cloud-hsm-cluster-id cluster-abc123 \
  --key-store-password <password> \
  --region us-east-1

# カスタムキー作成
aws kms create-key \
  --origin CUSTOM_KEY_STORE \
  --custom-key-store-id cks-abc123 \
  --region us-east-1

メリット

• ✓ KMS API の利便性 × CloudHSM のセキュリティ
• ✓ 既存 AWS サービス（S3・RDS）統合
• ✓ オンプレミス HSM への段階的移行パス

Backup・Restore・DR {#backup}

クラスタバックアップ

# バックアップ作成
aws cloudhsm create-backup \
  --cluster-id cluster-abc123 \
  --region us-east-1

# バックアップ一覧
aws cloudhsm describe-backups \
  --region us-east-1

ディザスターリカバリ

シナリオ 1：クラスタ全体喪失

元クラスタ（3 HSM）
  ├─ 1 つの HSM に障害
  ├─ Backup 作成（最新）
  └─ 新クラスタから復元

シナリオ 2：キー紛失

キーは Backup に保持
  └─ 新クラスタ復元 → 鍵復活

マルチリージョン DR

【Primary Region】
├─ CloudHSM Cluster（Active）
└─ Backup 転送 → Secondary Region

【Secondary Region】
└─ Backup から復元可能
   （フェイルオーバー時）

主要ユースケース {#usecases}

1. 金融機関向けキー管理：PCI-DSS コンプライアンス、顧客が鍵完全制御
2. 医療機関向け HIPAA 対応：FIPS 140-3、改ざん検出保証
3. データセンター間の証明書・キー同期：マルチリージョン HA
4. オンプレミス HSM からのクラウド移行：互換 API（PKCS#11）で段階的移行
5. エンタープライズ PKI：階層的 CA・証明書署名
6. API キー・認証情報の安全な保管：顧客完全制御

設定・操作の具体例 {#cli}

1. クラスタ作成・初期化

# VPC・Subnet 準備
VPC_ID="vpc-12345678"
SUBNET_ID="subnet-12345678"
SG_ID="sg-12345678"

# クラスタ作成
CLUSTER_ID=$(aws cloudhsm create-cluster \
  --subnet-ids $SUBNET_ID \
  --security-group-ids $SG_ID \
  --region us-east-1 \
  --query 'Cluster.ClusterId' \
  --output text)

# HSM 追加（3 台）
for i in {1..3}; do
  aws cloudhsm create-hsm \
    --cluster-id $CLUSTER_ID \
    --availability-zone us-east-1a \
    --region us-east-1
done

# クラスタ初期化
aws cloudhsm initialize-cluster \
  --cluster-id $CLUSTER_ID \
  --signed-cert file://path/to/cert.pem \
  --region us-east-1

2. CloudHSM クライアント インストール・設定

# Amazon Linux 2
sudo yum install -y cloudhsm-client cloudhsm-client-pkcs11

# HSM ホスト情報設定
sudo vim /opt/cloudhsm/etc/cloudhsm_client.cfg
# 出力: SERVER host-ip-address PORT 7002

# クライアント開始
sudo systemctl start cloudhsm-client
sudo systemctl status cloudhsm-client

3. PKCS#11 での鍵操作

# キーペア生成テスト
pkcs11-tool --module /opt/cloudhsm/lib/libcloudhsm_pkcs11.so \
  -l -c slot0user -p password \
  --keypairgen --key-type rsa:2048 \
  --label my-rsa-key

# 鍵リスト表示
pkcs11-tool --module /opt/cloudhsm/lib/libcloudhsm_pkcs11.so \
  -l -c slot0user -p password \
  --list-objects

4. Terraform IaC（クラスタ作成）

resource "aws_cloudhsm_cluster" "main" {
  subnet_ids = [aws_subnet.main.id]
  security_group_ids = [aws_security_group.cloudhsm.id]
}

resource "aws_cloudhsm_v2_cluster" "main" {
  hsm_type   = "hsm1.medium"
  subnet_ids = [aws_subnet.main.id, aws_subnet.secondary.id]
}

resource "aws_cloudhsm_v2_hsm" "hsm1" {
  cluster_id  = aws_cloudhsm_v2_cluster.main.id
  subnet_id   = aws_subnet.main.id
  az          = "us-east-1a"
}

resource "aws_cloudhsm_v2_hsm" "hsm2" {
  cluster_id  = aws_cloudhsm_v2_cluster.main.id
  subnet_id   = aws_subnet.secondary.id
  az          = "us-east-1b"
}

セキュリティ・監査 {#security}

ロギング・監査証跡

CloudHSM イベント:
├── ユーザー認証（成功・失敗）
├── キー操作（生成・削除・暗号化）
├── パーティション管理
└── HSM ファームウェア更新

ログ出力先:
├── CloudWatch Logs
├── CloudTrail（AWS API 呼び出し）
└── HSM 内部ログ（保護・改ざん不可）

FIPS 140-3 コンプライアンス検証

【認証内容】
✓ 暗号アルゴリズム（AES・RSA・ECDSA）
✓ 物理セキュリティ（改ざん検出・環境監視）
✓ キー管理プロセス
✓ リモートアクセス制限
✓ 運用セキュリティ

【検証方法】
aws cloudhsm describe-clusters --query 'Clusters[0].CertificateInformation'

類似サービス比較 {#comparison}

ベストプラクティス {#bestpractices}

✅ 推奨

✓ クラスタは最低 3 HSM（HA 構成）
✓ 定期バックアップ（毎日）
✓ マルチリージョン DR 計画
✓ キーローテーション ポリシー実装
✓ CloudWatch・CloudTrail ロギング有効化
✓ 定期的なセキュリティ監査

❌ アンチパターン

× 単一 HSM 構成（本番環境）
× バックアップなし
× キー管理ポリシー不定義
× ロギング無効化
× コスト削減名目での削減（セキュリティ機能）

トラブルシューティング {#troubleshooting}

近年の動向 {#latest}

1. KMS XKS 統合深化：より多くの AWS サービスが External Key Store サポート
2. Post-Quantum Cryptography：量子耐性暗号キー生成サポート検討
3. Multi-Region Cluster：グローバルクラスタ同期・自動フェイルオーバー
4. Managed Backup：自動バックアップ・保持ポリシー
5. Enhanced Monitoring：AWS Native メトリクス・ダッシュボード

学習リソース・参考文献 {#resources}

公式ドキュメント

1. AWS CloudHSM User Guide
2. CloudHSM API Reference
3. FIPS 140-2/140-3 標準
4. PKCS#11 Specification
5. AWS CloudHSM Best Practices
6. KMS Custom Key Store
7. CloudHSM vs KMS
8. Thales Luna HSM

実装例・ロードマップ {#roadmap}

Week 1-2：設計・セットアップ

• Day 1-3: VPC・ネットワーク設計
• Day 4-7: クラスタ作成・初期化
• Day 8-10: CloudHSM クライアント インストール
• Day 11-14: パイロット運用（単一キー）

Week 3-4：本番化

• Day 15-17: キーローテーション ポリシー策定
• Day 18-21: バックアップ・DR テスト
• Day 22-28: セキュリティ監査・ペネトレーションテスト

実装チェックリスト {#checklist}

【設計フェーズ】
☐ キー管理ポリシー定義
☐ ネットワーク設計（VPC・Subnet・SG）
☐ HA・DR 戦略検討
☐ コンプライアンス要件整理

【セットアップ】
☐ VPC・HSM Subnet 作成
☐ CloudHSM クラスタ作成（3 HSM）
☐ Cluster Officer パスワード設定
☐ CloudHSM クライアント インストール

【運用準備】
☐ キー生成テスト
☐ PKCS#11 統合テスト
☐ バックアップ・復元テスト
☐ CloudWatch・CloudTrail ロギング

【本番運用】
☐ ローテーション スケジュール
☐ セキュリティ監査実施
☐ インシデント対応計画
☐ スタッフトレーニング

コスト・プライシング {#pricing}

【クラスタ構成費】
HSM 1 台: $1,500-2,000/月
最低構成（3 HSM）: $4,500-6,000/月

【転送料金】
Data Transfer: 通常の AWS 料金

【初期セットアップ】
初期構成・テスト: 含まれず（人的コスト）

まとめ {#summary}

AWS CloudHSM は、顧客が暗号鍵の完全な所有権・制御を持つ エンタープライズグレードのキー管理ソリューションです。FIPS 140-3 Level 3 認証・Hardware-Based セキュリティ・Protocol 多様性により、金融・医療・規制業界のコンプライアンス要件を満たしながら、AWS のスケーラビリティ・可用性を享受できます。

核心ポイント

1. 顧客完全制御：鍵生成から削除まで、すべて顧客が実行
2. FIPS 140-3 Level 3：物理セキュリティ・改ざん検出保証
3. HA・マルチリージョン対応：3-HSM Cluster で高可用性
4. Protocol 多様性：PKCS#11・JCE・OpenSSL 互換
5. KMS XKS 統合：AWS サービス標準インターフェース活用