概要
暗号鍵の管理は、データ保護の根幹を担う重要な要素です。金融機関や医療機関など、コンプライアンス要件が厳しい環境では、暗号鍵を専用のハードウェアで管理し、鍵へのアクセスを厳密に制御する必要があります。
AWS CloudHSM は、AWS クラウド上で専用のハードウェアセキュリティモジュール（HSM）を利用できるサービスです。FIPS 140-3 レベル 3 の認証を受けた HSM（HSM タイプ hsm2m.medium。FIPS モードのクラスターの場合）を使用し、暗号鍵の生成・保管・暗号化処理を安全に実行できます。AWS KMS と異なり、HSM の完全な制御権をユーザーが保持するため、より厳格なコンプライアンス要件に対応できます。
本記事では、CloudHSM の基本概念を理解し、クラスターの作成からコンソールでの状態確認までを体験します。
注意: CloudHSM は、起動した HSM 1 台ごとに、削除するまで時間単位で課金されるサービスです。本記事では主にコンソールでの確認と概念の理解に重点を置いています。実際にクラスターを作成する場合は、料金を十分に確認のうえ、不要になったら速やかにクラスターを削除してください。
クラウドおさる今回は、暗号鍵を専用のハードウェアで守る CloudHSM でござる。KMS との違いを押さえてから、クラスターを作って中身を確かめていくでござるよ。
この記事のメリット
- CloudHSM と AWS KMS の違いを理解し、適切なサービスを選択できるようになる
- HSM クラスターのアーキテクチャと高可用性の仕組みを把握できる
- FIPS 140 レベル 3 の意味とコンプライアンス要件との関係を理解できる
- CloudHSM クラスターの作成手順と初期化の流れを把握できる
- CloudHSM のユースケースと利用時の注意点を理解できる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
クラウドおさるとひさん、AWS CloudHSM とはどんなサービスでござるか？ 名前からして、ハードウェアの匂いがするでござるが……
土肥CloudHSM は、AWS クラウド内で専用の HSM（Hardware Security Module）インスタンスを利用できるサービスだよ。HSM っていうのは、暗号鍵の生成、保管、暗号化・復号処理を行う専用のハードウェアデバイスのことなんだ。
クラウドおさる専用のハードウェアを使うのでござるな。どんな場面で使われるのでござる？
土肥主なユースケースはこんな感じだよ。
- SSL/TLS 処理のオフロード（Web サーバーの暗号化処理を HSM に委任）
- 認証局（CA）のプライベートキー保護
- Oracle TDE（Transparent Data Encryption）の暗号鍵管理
- コード署名やドキュメント署名
- 単一テナントの専用 HSM で、鍵を自分で専有・管理することが求められるコンプライアンス要件への対応
クラウドおさる暗号鍵の管理なら、AWS KMS もあったはずでござる。何が違うのでござるか？
土肥いい質問だね。CloudHSM と AWS KMS はどちらも暗号鍵の管理に使うんだけど、制御レベルとユースケースが違うんだ。比較するとこうなるよ。
| 比較項目 | AWS CloudHSM | AWS KMS |
|---|---|---|
| HSM の管理 | ユーザーが専有・管理 | AWS がマルチテナントで管理 |
| 認証レベル | FIPS 140-3 レベル 3（hsm2m.medium。FIPS モードのクラスター） | FIPS 140-3 レベル 3（KMS の HSM） |
| 鍵へのアクセス制御 | ユーザーが完全に制御 | キーポリシーで制御（IAM ポリシー・グラントも併用できる） |
| 対応する暗号アルゴリズム | 対称鍵、非対称鍵、ハッシュなど幅広い | 対称鍵、非対称鍵（AES、RSA、ECC 等） |
| API / SDK | PKCS#11、JCE、CNG / KSP | AWS SDK / CLI |
| 料金 | HSM 単位の時間課金（高コスト） | キーごとの月額料金とリクエスト料金（一般に CloudHSM より低コスト） |
| 可用性の責任 | ユーザーがクラスター構成を管理 | AWS が可用性を管理 |
| カスタム暗号処理 | 可能 | 限定的 |
クラウドおさるCloudHSM のほうがバナナも多く飛ぶうえに、管理も自分でやらねばならぬのでござるな。どういうときに選ぶのでござるか？
土肥一般的なユースケースでは AWS KMS で十分対応できるんだ。CloudHSM は、専用 HSM の利用が必須のコンプライアンス要件がある場合や、HSM に対する完全な制御が必要な場合に選択するんだよ。KMS の HSM も FIPS 140-3 レベル 3 の認証を受けているから、「レベル 3 の HSM で鍵を守りたい」というだけなら KMS で満たせるんだ。
クラウドおさるなるほど、猿山でいえば、ふだんの鍵は長老会の共同金庫（KMS）に預け、掟で「自分専用の金庫を持て」と決まっている品だけ専用金庫（CloudHSM）にしまう、という使い分けでござるな。CloudHSM のアーキテクチャは、どうなっているのでござる？
土肥CloudHSM では、複数の HSM を「クラスター」として管理するんだ。クラスターの特徴はこんな感じだよ。
- クラスターは VPC 内に作成し、サブネットを指定して HSM を配置する
- 高可用性のため、複数の AZ にまたがって HSM を配置することが推奨される
- クラスター内の HSM 間で自動的に鍵の同期が行われる
- アプリケーションは CloudHSM クライアントを介して HSM にアクセスする
クラウドおさるアプリケーションからアクセスするには、クライアントが要るのでござるな。
土肥そうだよ。アプリケーションから CloudHSM を利用するには、EC2 インスタンスに CloudHSM クライアントをインストールするんだ。クライアントは以下の暗号化インターフェースを提供してくれるよ。
| インターフェース | 対応言語・環境 | 用途 |
|---|---|---|
| PKCS#11 | C/C++ | 汎用的な暗号化ライブラリ |
| JCE（Java Cryptography Extension） | Java | Java アプリケーション |
| CNG / KSP | Windows | Windows アプリケーション |
| OpenSSL Dynamic Engine | Linux | SSL/TLS オフロード |
クラウドおさるいろいろな言語や環境に対応しているのでござるな！ ところで、さっきから出てくる FIPS 140 のレベル 3 とは何でござるか？
土肥FIPS 140 は、暗号モジュールのセキュリティ要件を定めた米国政府の標準規格なんだ。今の版は FIPS 140-3 だよ。認証にはレベルがあって、CloudHSM の今の HSM タイプ hsm2m.medium は FIPS 140-3 レベル 3 の認証を受けているんだ。以前の HSM タイプ hsm1.medium は FIPS 140-2 レベル 3 の認証だったけど、その証明書は 2026 年 1 月 4 日に履歴リストへ移ったから、hsm2m.medium への移行が勧められているよ。
クラウドおさる今から使うなら FIPS 140-3 のほうでござるな。レベル 3 の HSM は、物理的にはどう守られているのでござる？
土肥CloudHSM の HSM は、HSM 筐体への物理的なアクセスや改ざんの試みを検出して、鍵を自動的に消去する仕組みを備えているんだ。金融機関や医療機関が求めるような厳しい要件にも対応できるよ。
クラウドおさる物理的にこじ開けようとしたら鍵が消えるのでござるか。猿山のバナナ倉庫も、こじ開けられたら中身が消える仕掛けなら、夜の見回り当番がずいぶん楽になるでござる。
実践
前提条件
- リージョン:
ap-northeast-1（東京） - IAM ユーザーまたはロールに CloudHSM の操作権限があること
- 以下のリソースが作成済みであること
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| VPC | cloudhsm-lab-vpc | クラスターを置く VPC |
| サブネット | ap-northeast-1a と ap-northeast-1c のプライベートサブネット | HSM を配置するサブネット（2 つの AZ） |
コストに関する注意: CloudHSM クラスターに HSM を追加すると、時間単位で課金が発生します。本記事では HSM を追加せず、クラスターの作成までを行います（HSM が 0 台のクラスターには HSM の時間料金はかかりません）。
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| CloudHSM クラスター | basic-cloudhsm-cluster | HSM クラスター |
| セキュリティグループ | CloudHSM が自動作成 | HSM へのアクセス制御 |
ステップ1: CloudHSM コンソールへの移動
- AWS マネジメントコンソールにログインし、リージョンが
ap-northeast-1（東京）であることを確認します - 上部の検索バーに
CloudHSMと入力し、表示された「CloudHSM」を選択します
ステップ2: クラスターの作成
- 「クラスターを作成」をクリックします。作成は「クラスター設定」→「バックアップ保持」→「タグ」→「確認」の 4 ステップです
- ステップ 1「クラスター設定」で以下を設定します
- VPC:
cloudhsm-lab-vpcを選択します - AZ とサブネット:
ap-northeast-1aとap-northeast-1cの欄で、それぞれのプライベートサブネットを選択します（サブネットは ID で表示されます。ap-northeast-1dの欄は空のままにします）。高可用性のため、少なくとも 2 つの AZ を選択することが推奨されます - HSM タイプ: デフォルトの
hsm2m.mediumのまま（東京リージョンでは、旧タイプのhsm1.mediumは選べません） - クラスターモード: デフォルトの「FIPS 以外」のまま。FIPS で検証されたキーとアルゴリズムだけに制限したい場合は「FIPS」を選びます
- ネットワークタイプ: デフォルトの
IPv4のまま - クラスターソース: デフォルトの「新しいクラスター」のまま
- 「続行」をクリックします。ステップ 2「バックアップ保持」は、デフォルト（90 日）のまま「続行」をクリックします
- ステップ 3「タグ」で「タグの追加」をクリックし、キー
Name、値basic-cloudhsm-clusterを入力して「続行」をクリックします - ステップ 4 で内容を確認し、「クラスターの作成」をクリックします
- ステータスが「作成中」から「未初期化」に変わるまで待ちます（今回は 1 分ほどでした）
ステップ3: クラスターの詳細確認
- クラスター ID をクリックして詳細画面を確認します
- 以下の情報が表示されます
- クラスター ID: クラスターの一意の識別子
- 状態: クラスターの状態（今は「未初期化」）
- VPC: クラスターが作成された VPC
- セキュリティグループ: CloudHSM が自動作成したセキュリティグループ
- バックアップ保持期間・HSM タイプ・モード・AZ とサブネット: 作成時に選んだ設定
- HSM を追加すると、ここにクラスター内の HSM の一覧も表示されるようになります
ステップ4: セキュリティグループの確認
- クラスター詳細画面の「セキュリティグループ」に表示されているセキュリティグループ ID（
cloudhsm-cluster-<クラスター ID>-sg）をクリックします。EC2 コンソールのセキュリティグループの画面が開きます - 「インバウンドルール」タブで、自動作成されたルールを確認します
- TCP ポート
2223〜2225を、送信元「このセキュリティグループ自身」から許可するルールが 1 本あります（アウトバウンドも同じく、自分自身へのポート2223〜2225だけです） - つまり、このセキュリティグループが付いているもの同士でしか通信できません。アプリケーション（EC2 インスタンス）からクラスターに接続するには、このセキュリティグループを EC2 インスタンスにも付けるか、アプリケーション側のセキュリティグループからのインバウンドを追加します
クラウドおさるクラスターを作っただけでは、アプリケーションからはまだつながらぬのでござる。自動で作られたセキュリティグループは「仲間内だけ」の許可なので、アプリケーション側を仲間に入れて初めて道が通るのでござるな。
ステップ5: HSM の初期化（概念の確認）
実際の運用では、クラスター作成後に以下の手順で初期化を行います。ここでは手順の概要を確認します。
- CSR（証明書署名リクエスト）の取得: クラスターの CSR をダウンロードし、HSM の真正性を確認する
- 自己署名証明書の作成: CSR に署名し、証明書を作成してクラスターに適用する
- HSM の初期化: 最初の HSM をクラスターに追加する
- Crypto Officer（CO）パスワードの設定: CloudHSM クライアントを使用して HSM のパスワードを設定する
- Crypto User（CU）の作成: アプリケーションが使用するユーザーを作成する
CloudHSM のユーザー管理は IAM とは独立しており、HSM 内部で管理されます。主なユーザータイプは以下のとおりです。
| ユーザータイプ | 役割 |
|---|---|
| Precrypto Officer（PRECO） | 初期パスワード変更用の一時ユーザー |
| Crypto Officer（CO） | ユーザー管理（作成・削除・パスワード変更） |
| Crypto User（CU） | 暗号鍵の作成・削除・暗号化・復号の実行 |
| Appliance User（AU） | クラスター内の HSM 同期（AWS が管理） |
クラウドおさるHSM のユーザーは IAM とは別に、HSM の内部で管理されるのでござる。IAM の権限を整えただけで鍵まで使えると思い込むと、つまずくでござるぞ。
まとめ
- AWS CloudHSM は、AWS クラウド上で専用の HSM を利用できるサービスである
- FIPS 140-3 レベル 3 認証の HSM（hsm2m.medium）を使用し、厳格なコンプライアンス要件に対応できる。FIPS で検証されたキーとアルゴリズムだけに絞るならクラスターを FIPS モードで作る（モードは作成後に変更できない。本記事の実践は「FIPS 以外」のモード）
- CloudHSM はユーザーが HSM を専有・管理し、AWS KMS は AWS がマルチテナントで管理するという違いがある
- 一般的なユースケースでは AWS KMS で十分であり、CloudHSM は専用 HSM が必須の場合に選択する
- クラスターは VPC 内に作成し、複数の AZ にまたがる配置で高可用性を実現する
- アプリケーションからは PKCS#11、JCE、CNG などのインターフェースを介してアクセスする
- CloudHSM のユーザー管理は IAM とは独立しており、HSM 内部で管理される
- 時間単位で課金されるため、不要なクラスターは速やかに削除する
参照先
- AWS CloudHSM とは
- AWS CloudHSM クラスター
- HSM ユーザー
- CloudHSM クライアント
- AWS CloudHSM と AWS KMS の比較
- AWS CloudHSM のコンプライアンス検証
- AWS CloudHSM クラスターモード
- AWS Key Management Service でのデータ保護
- AWS KMS のキーポリシー
