AWS CloudHSM入門｜KMSとの違い・専用HSMで鍵管理をハードウェアレベルで強化する実践ガイド

「KMSで暗号化しているから安全なはず」――そう思っていたら、コンプライアンス審査で「FIPS 140-2 Level 3のHSMが必要」と指摘されて焦った、というケースはクラウド移行現場では珍しくない話だ。

AWS KMSは使い勝手が良く、S3やRDSとの連携も簡単だが、鍵を保護するハードウェアはAWSとの共有テナントになる。金融機関・医療機関・PCI DSS対応が求められる決済システムでは、「鍵をハードウェアレベルで自分だけが管理したい」という要件が出てくる。その答えが AWS CloudHSM だ。

この記事では、CloudHSMの仕組み・KMSとの違い・セットアップ手順・料金・実務Tipsを、オンプレのHSM経験者にもわかりやすく解説する。CloudHSMが本当に自分の要件に必要かどうかの判断基準も示すので、導入検討の第一歩として読んでほしい。

なぜCloudHSMが必要なのか？KMSとの根本的な違い

まず「HSMとは何か」から整理する。HSM（Hardware Security Module）は、暗号鍵の生成・保管・暗号処理を専用のタンパー耐性ハードウェアで行う装置だ。物理的な攻撃が加わると自動的に鍵を消去するように設計されている。

オンプレ時代は Thales nShield や SafeNet Luna といった物理HSMをラックに刺して使うのが一般的だった。AWS CloudHSMは、その専用HSMハードウェアをAWSのデータセンターに置いてクラウドから使えるようにしたサービスだ。

KMSとCloudHSMの違いを整理する

最大の違いは「鍵の主権」だ。KMSでは鍵を保護するHSMハードウェアをAWSが管理する。クラウドセキュリティの責任共有モデル上は問題ないが、「AWSが物理的にアクセスできる状態であること自体がNG」というコンプライアンス要件がある場合、CloudHSMが必要になる。

クラウドセキュリティの責任共有モデルについての解説はこちらでも詳しく説明している。

CloudHSMが必要になる主なケース

・PCI DSS v4.0への対応: カード会員データを保護する鍵をFIPS 140-2 Level 3環境で管理する要件がある
・金融機関の監督官庁要件: 暗号鍵の管理者が自社でなければならないと明記されているケース
・医療・公共分野のHIPAA/ISMS要件: 第三者（クラウドベンダー）の鍵アクセスを排除したい
・オンプレHSMからのクラウド移行: 既存のPKCS#11ベースのアプリをそのままクラウドに持ち込みたい
・TLSオフロード: ロードバランサーの秘密鍵をHSMで保護したい

逆に言えば、一般的なWebサービスや社内システムであれば、AWS KMSで十分なケースがほとんどだ。CloudHSMはコストも運用負荷も高いため、「コンプライアンス要件がある」か「標準API（PKCS#11）を使いたい」という明確な理由がない限り、KMSを選ぶべきだ。

AWS CloudHSMの仕組みと構成

クラスター構成が基本

CloudHSMは「クラスター」という単位で管理する。クラスター内に複数のHSMインスタンス（物理HSM）を配置することで、冗長性を確保する。

重要なのは、クラスター内のHSMは鍵マテリアルを自動的に同期する点だ。オンプレのHSMでは手動でバックアップ・リストアが必要だったが、CloudHSMではクラスター内で自動複製される。

本番環境では、少なくとも異なるアベイラビリティゾーン（AZ）に2台以上のHSMを配置することが推奨される。東京リージョン（ap-northeast-1）では ap-northeast-1a・1c・1d の3つのAZが利用可能だ。

アクセス経路

アプリサーバーからCloudHSMへのアクセスは、同じVPC内に配置したENI（Elastic Network Interface）経由で行う。インターネットを経由しないプライベート通信になるため、セキュリティグループを適切に設定する必要がある。

CloudHSM Client SDKをEC2インスタンスにインストールすることで、PKCS#11・JCE（Java）・OpenSSL Dynamic Engineなどの標準APIでHSMにアクセスできる。

CloudHSMのセットアップ手順

1. クラスターの作成

まずVPCとサブネットを用意した上で、マネジメントコンソールまたはAWS CLIでクラスターを作成する。

# AWS CLI でクラスターを作成する
aws cloudhsmv2 create-cluster \
  --hsm-type hsm1.medium \
  --subnet-ids subnet-xxxxxxxxxx subnet-yyyyyyyyyy \
  --region ap-northeast-1

# 作成されたクラスターIDを確認
aws cloudhsmv2 describe-clusters \
  --filters clusterIds=cluster-xxxxxxxxxx \
  --region ap-northeast-1

2. HSMインスタンスの起動

クラスターが作成されたら、最初のHSMインスタンスを起動する。

# クラスターにHSMを追加する
aws cloudhsmv2 create-hsm \
  --cluster-id cluster-xxxxxxxxxx \
  --availability-zone ap-northeast-1a \
  --region ap-northeast-1

# HSMの状態確認（ACTIVE になるまで数分かかる）
aws cloudhsmv2 describe-hsm \
  --cluster-id cluster-xxxxxxxxxx \
  --hsm-id hsm-xxxxxxxxxx

初回のみ、証明書署名リクエスト（CSR）を発行してクラスターを初期化する「クラスター初期化」という手順が必要だ。これはAWSコンソールのウィザードに従うのが確実で、自社のCA証明書で署名するか、自己署名証明書を使う形になる。

3. EC2インスタンスにCloudHSM Client SDKをインストール

アプリを実行するEC2インスタンス（Amazon Linux 2023の場合）にクライアントをインストールする。

# CloudHSMリポジトリの追加と Client SDK 5 のインストール
sudo yum install -y https://s3.amazonaws.com/cloudhsmv2-software/CloudHsmClient/EL8/cloudhsm-pkcs11-latest.el8.x86_64.rpm

# 設定ファイルでHSMのIPアドレスを指定
sudo /opt/cloudhsm/bin/configure-pkcs11 -a 

# HSMへの接続テスト
/opt/cloudhsm/bin/pkcs11-tool --module /opt/cloudhsm/lib/libcloudhsm_pkcs11.so --list-slots

接続後は、Crypto User（CU）アカウントを作成し、PKCS#11ライブラリ経由で鍵生成・暗号化処理を行う。

Linuxサーバー上でのOpenSSLの基礎操作については、姉妹サイトLinuxMaster.JPで詳しく解説している。

CloudHSMの料金（2026年時点）

CloudHSMの料金体系はシンプルで、HSMインスタンスの稼働時間に対して課金される。

KMSの月額料金（カスタマーマネージドキー1本 = $1）と比べると、CloudHSMのコストは大幅に高い。このコストが正当化されるのは、コンプライアンス上の要件がある場合や、大量の暗号処理でKMSのAPIコスト（$0.03/10,000リクエスト）を上回るケースに限られる。

応用・実務Tips

KMSカスタムキーストアとの連携

CloudHSMの強力な機能のひとつが、AWS KMSのカスタムキーストアとして使える点だ。通常のKMSと同じAPIでS3・RDS・EBSの暗号化ができながら、実際の鍵はCloudHSM内に格納される。

# KMSにカスタムキーストアを作成する
aws kms create-custom-key-store \
  --custom-key-store-name MyHSMKeyStore \
  --cloud-hsm-cluster-id cluster-xxxxxxxxxx \
  --trust-anchor-certificate file://CustomerCA.crt \
  --key-store-password 

# カスタムキーストアを接続状態にする
aws kms connect-custom-key-store \
  --custom-key-store-id cks-xxxxxxxxxx

# カスタムキーストア内にCMKを作成する
aws kms create-key \
  --origin AWS_CLOUDHSM \
  --custom-key-store-id cks-xxxxxxxxxx \
  --description "MyApp-DataKey-HSM"

これにより、既存のKMS依存のアプリを改修せずにHSM鍵管理に移行できる。

TLSオフロードへの応用

Webサーバーの秘密鍵をCloudHSMに格納し、TLSハンドシェイクをHSM上で処理することで、「秘密鍵が一切ディスクに出ない」構成が実現できる。nginx や Apache でOpenSSL Dynamic Engineを使う構成が代表的だ。

オンプレHSMからの移行パターン

既存のThales・SafeNetのHSMからCloudHSMへの移行は、同じPKCS#11標準APIをサポートしているため、アプリのソースコードを変更せずにHSMを差し替えられるケースが多い。ただし、既存HSMに格納された鍵マテリアルの移行は慎重な計画が必要だ。鍵のエクスポート形式（PKCS#8/wrapped key）の互換性を事前に確認すること。

クラウドセキュリティの設計思想として、外部からの侵入を前提に内部で多層防御を組む「ゼロトラスト」の考え方も組み合わせると効果的だ。ゼロトラストセキュリティ入門の記事と合わせて読んでほしい。

また、暗号鍵と並んで重要なパスワード・APIキーの管理については、AWS Secrets Manager入門も参考になる。

暗号・鍵管理の基礎からセキュリティの本質を学びたい場合は、姉妹サイトSecurityMasters.TOKYOの解説も参考にしてほしい。

よくあるトラブルと対処法

【重大】クラスターを削除するとデータが消える

CloudHSMのクラスターを削除すると、その中の鍵マテリアルはすべて失われる。これは物理HSMと同じ仕様だ。クラスターを消す前に、必ず鍵のバックアップ（クラスターのクローン）を別途作成すること。

AWSコンソールの「クラスター」削除ボタンには確認画面があるが、Terraformやスクリプトで自動化している場合は誤操作が起きやすい。IaCのstate管理とDeletion Protectionを必ず設定する。

HSMが1台だとSPOFになる

HSMが1台のクラスターは、そのHSMが障害を起こすと暗号処理が全停止する。本番環境では必ず異なるAZに2台以上のHSMを配置し、クラスター内で鍵が自動同期されている状態を維持すること。

コンソールの「クラスター」ステータスが「DEGRADED」になったら、追加のHSMを早急に起動して修復する。

クライアントSDKのバージョン不整合

CloudHSM Client SDK 5（推奨）と旧SDK 3・4では設定ファイルの場所や起動方法が異なる。既存ドキュメントやブログ記事に古いSDKのコマンドが混在しているため、必ずAWS公式ドキュメントの最新版を参照すること。

セキュリティグループの設定ミス

CloudHSMのENIへのアクセスには、TCP 2223～2225ポートを許可する必要がある。EC2インスタンスのセキュリティグループにこのルールが抜けていると、クライアントSDKがHSMに接続できずタイムアウトする。

本記事のまとめ

・AWS CloudHSMはKMSの上位互換ではない: 用途が違うツールだ。コンプライアンス要件（FIPS 140-2 Level 3）またはPKCS#11標準API利用が必要な場合のみ選ぶ
・鍵の主権がポイント: CloudHSMではAWSは鍵マテリアルにアクセスできない。これがコンプライアンス要件を満たす根拠になる
・本番は2台・2AZ構成が必須: 1台はSPOF。月額コストは約$1,670～を見込む
・KMSカスタムキーストアで既存アプリと連携: S3・RDS等との連携はKMS APIを経由できるため、アプリ側の改修が最小限になる
・鍵のバックアップ設計を最初に決める: クラスター削除 = 鍵消滅のリスクがある。IaCのstate管理と削除保護を必ず設定する

CloudHSMは「必要な人には必須、不要な人には過剰」なサービスだ。要件を正確に読み解いて、KMSで済むのかCloudHSMが必要なのかを判断してほしい。KMSの詳細な使い方はAWS KMS入門の記事で解説しているので、比較しながら読むとより理解が深まる。