旅行会社の新規事業開発部では、年末年始の旅行シーズンに向けて、顧客情報の保護を一段強化することになりました。特に、決済に関わる情報や本人確認情報は、漏えいすると被害が大きく、取引先からも厳しい管理を求められます。
ある日、システム部門からこんな報告が来ました。
「データベース暗号化の“鍵”の管理方法を見直したい。今の管理だと、鍵が漏れたら全部終わる」
ケンイチ：
「課長、セキュリティ対策についてご相談があります。
暗号鍵の管理が一箇所に寄っていて、もし盗まれたら…と思うと怖いです。
何か良い方法はないでしょうか？」
課長：
「それならAWS CloudHSMを検討しよう。
“鍵を金庫に入れて、金庫から出さない”という発想で守れる」
ケンイチ：
「CloudHSM…ですか？ それは一体何でしょうか？」
課長：
「一言で言うと、暗号鍵をしまうための“専用の金庫（ハードウェア）”だ。
HSMはHardware Security Moduleの略で、鍵を“ソフトの中”じゃなく“専用ハードの中”で守る」
ケンイチ：
「鍵って、そんなに重要なんですか？ 暗号化していれば安心…じゃないんでしょうか？」
課長：
「暗号化は“鍵が安全”という前提で成り立つ。
分厚い扉（暗号）を作っても、合鍵（鍵）が盗まれたら意味がない。
だから鍵は“最重要資産”として別格で守る必要がある」
ケンイチ：
「なるほど…。でも、CloudHSMって“Cloud”って付いてますよね。
専用ハードの金庫ってことは、うちが機械を買って持つんですか？」
課長：
「そこが誤解ポイントだ。
Cloudの意味は『AWSのクラウド（AWSのデータセンター）の中にある』ってこと。
物理的なHSM機器はAWS側の施設に置かれる。
君たちが段ボールで機械を受け取って社内に置くわけじゃない」
ケンイチ：
「じゃあ、“AWSが持っている機械”を使うんですね。
それだとKMSと同じで、AWSにお任せ…ですか？」
課長：
「似ているようで違う。ここがCloudHSMの核心だ。
『ハードはAWSが持つ。でも中の運用はユーザーが握る』。
具体的には、HSM内のユーザーや権限、鍵の作成・バックアップ・ローテーションなどを、
自分たちのルールで管理する前提なんだ」
ケンイチ：
「なるほど…。
“金庫そのものはAWSの建物にあるけど、鍵束の管理は自分たちがやる”って感じですね？」
課長：
「その例え、かなり良い。
だから、監査や規制で『鍵の管理権限を自社で持て』と言われるケースで選ばれやすい」
ケンイチ：
「具体的には、どんなときに使うんですか？」
課長：
「例えばこうだ。
・決済や会員DBの暗号化キーを“最重要”として隔離して守りたい
・電子署名（契約書、ログ改ざん防止、コード署名）で秘密鍵を厳重に扱いたい
・取引先や監査で『鍵は専用HSMで管理』を求められる」
ケンイチ：
「似たサービスだとAWS KMSもありますよね。どっちを選べばいいんでしょうか？」
課長：
「使い分けはこう考えろ。
KMSは“AWSに管理を任せる鍵管理”。手軽で連携も広い。
CloudHSMは“自分たちで管理する鍵管理”。厳格な要件や運用ルールに合わせやすい。
たいていの暗号化はKMSで十分なことが多い」
ケンイチ：
「じゃあCloudHSMは、どんなときに必要なんですか？」
課長：
「“鍵の持ち方”に強いこだわりがあるときだ。
・『鍵の管理権限をAWSではなく自社で持ちたい』
・『特定の暗号方式や運用ルールが必須』
・『監査でHSM利用が求められる』
こういうケースだな」
ケンイチ：
「デメリットはありますか？」
課長：
「ある。CloudHSMは“金庫を持つ”ので、運用もコストも重くなる。
初期設定、冗長化、鍵の棚卸し、ローテーション…
“丸投げ”ではない。そこは覚悟が必要だ」
ケンイチ：
「分かりました。まずは要件整理からですね。何から始めればいいでしょうか？」
課長：
「順番はこうだ。
1) どのデータの鍵が最重要かを決める（決済、本人確認など）
2) 監査・取引先の要求を確認する（HSM必須か、KMSでOKか）
3) KMSで足りるか、CloudHSMが必要か判断する。必要なら小さく検証して本番だ」
| 用語 | 鍵の管理 | 強み | 向いている用途 |
|---|---|---|---|
| AWS CloudHSM | ユーザー主体で管理 | 厳格な鍵管理・カスタム運用 | 監査・規制が強い鍵管理、署名鍵 |
| AWS KMS | AWSが管理を支援 | 手軽・広く連携 | 一般的な暗号化（S3/EBS/RDS等） |
| ソフトウェア暗号化 | OS/アプリが管理 | 導入が手軽 | 開発・検証、軽めの用途 |
AWS CloudHSMを“企業名つきで明記”した公開事例は多くありません（非公開のケースもあります）。その代わり、AWS公式の説明から、CloudHSMが想定している典型用途を具体化します。
例1：決済・個人情報を扱うシステムの鍵管理を強化
決済情報や本人確認情報を扱うシステムでは、暗号鍵の管理方法が監査で問われやすくなります。CloudHSMは鍵を専用ハードウェア内で扱えるため、鍵管理を厳格化したいケースで選択肢になります。
例2：電子署名・コード署名の秘密鍵を厳重に保護
アプリや更新ファイルの改ざん防止（コード署名）では、署名に使う秘密鍵が漏れると大事故になります。CloudHSMのように鍵を守る専用機構を使うことで、秘密鍵の取り扱いを厳格にできます。
情報源：
AWS CloudHSM（ドキュメント）：https://docs.aws.amazon.com/cloudhsm/latest/userguide/intro.html
AWS CloudHSM（サービスページ）：https://aws.amazon.com/jp/cloudhsm/
AWS CloudHSMが守る“特に大事なもの”はどれ？
A：暗号鍵
B：Webサイトのデザイン
C：社員の名札
CloudHSMの“Cloud”の意味として近いのはどれ？
A：AWSのデータセンター内で使えるという意味
B：ユーザーが自宅に金庫を置くという意味
C：無料で使えるという意味
KMSとCloudHSMの違いとして近いのはどれ？
A：KMSはAWS寄りの管理、CloudHSMはユーザー寄りの管理
B：KMSはストレージ、CloudHSMは動画配信
C：KMSは検索、CloudHSMは翻訳
1-A：（暗号鍵）（暗号の“合鍵”を守る）
2-A：（AWSのデータセンター内で使える）（物理機器はAWS側）
3-A：（KMSはAWS寄りの管理、CloudHSMはユーザー寄りの管理）（役割が違う）
解説：CloudHSMは暗号鍵を専用ハードウェア内で扱い、鍵管理を厳格化したい場面で力を発揮します。ハードはAWS側にありますが、鍵の運用はユーザー寄りになる点がKMSとの大きな違いです。