// シス担のミカタ
クラウドセキュリティ

HSM（Hardware Security Module） えいちえすえむ

暗号鍵管理PKIKMSFIPS 140-2耐タンパー性電子署名
HSMについて教えて

簡単に言うとこんな感じ！

暗号の「鍵」を超厳重な金庫の中で管理・使用する専用ハードウェアだよ。鍵が外に出ないまま暗号処理もその中でやっちゃうから、たとえハッカーがサーバーに侵入しても鍵を盗めないんだ！

HSMとは

HSM（Hardware Security Module）とは、暗号鍵の生成・保管・使用をハードウェアレベルで安全に行うための専用デバイスです。ソフトウェアだけで鍵を管理する場合、OSやアプリケーションが侵害されると鍵も一緒に盗まれるリスクがありますが、HSMは物理的に保護された「閉じた環境」の中だけで鍵を扱うため、外部から鍵そのものを取り出すことができません。

HSMの最大の特徴は耐タンパー性（tamper resistance）です。物理的に開封・解析しようとすると自動的に内部データを消去する仕組みが備わっており、サーバーラックに差し込むカード型や、ネットワーク経由で利用するアプライアンス型など様々な形態で提供されています。金融機関でのATM暗号処理、認証局（CA）の証明書署名、クラウド上の鍵管理サービスのバックエンドなど、「信頼の根拠（Root of Trust）」が求められる場面で広く使われています。

近年はクラウドプロバイダーがHSMをマネージドサービスとして提供する形態（AWS CloudHSM、Azure Dedicated HSM など）も普及しており、オンプレミスにハードウェアを置かなくてもHSMレベルのセキュリティを利用できる環境が整ってきています。

HSMの仕組みと主な機能

機能内容
鍵生成HSM内部の真性乱数生成器（TRNG）を使い、予測困難な鍵を生成
鍵保管生成した鍵はHSM外に出ず、暗号化された状態で内部に保持
暗号処理暗号化・復号・署名・検証をHSM内部で完結させる
アクセス制御認証されたオペレーターのみが操作可能。ロールベースで権限管理
耐タンパー応答物理解析を検知すると鍵を自動消去（Zeroization）
監査ログ鍵の使用履歴を改ざんできない形で記録

「鍵は金庫の外に出ない」が核心

HSMを理解するうえで最も重要なのは「鍵がデバイスの外に平文では絶対に出ない」という原則です。たとえばデータを復号したいとき、アプリケーションは「このデータを復号してください」とHSMにリクエストを送り、HSMが内部で復号して平文のデータだけを返します。鍵自体はHSMの外へ渡りません。

FIPS 140-2/140-3 認定レベル

HSMの信頼性は米国政府標準のFIPS 140-2（または後継のFIPS 140-3）という規格で認定されます。

レベル要件の概要
Level 1ソフトウェア要件のみ。物理保護は問わない
Level 2封印シールや施錠など、改ざんの証拠が残る物理保護
Level 3改ざん検知・応答機能（開封で鍵消去）。本格HSMはここ以上
Level 4最高レベル。あらゆる物理攻撃を検知・無効化

金融・医療・政府調達ではLevel 3以上が求められることが多く、クラウド事業者もLevel 3認定HSMを採用しています。

歴史と背景

  • 1970年代: IBMがATM向けに暗号処理専用ハードウェアを開発。これがHSMの原型とされる
  • 1990年代: PKI（公開鍵基盤）の普及とともに、認証局が秘密鍵を保護するためHSMを採用し始める
  • 2001年: NIST（米国国立標準技術研究所）がFIPS 140-2を策定。HSMの評価基準が標準化される
  • 2000年代中盤〜: PCIデータセキュリティ基準（PCI DSS）がHSM使用を推奨し、クレジットカード業界で急速普及
  • 2010年代: クラウド移行の波の中で、AWS・Azure・GCPがマネージドHSMサービスを相次ぎ提供開始
  • 2019年: FIPS 140-3策定。ISO/IEC 19790との整合が図られ国際標準との統合が進む
  • 現在: ゼロトラストアーキテクチャの浸透により、鍵管理の厳格化需要がさらに拡大中

オンプレHSM vs クラウドHSM vs KMS

HSMにはいくつかの導入形態があり、自社のニーズや運用体制によって選択が変わります。

HSM 導入形態の比較 オンプレHSM （自社設置型） ✔ 完全な物理的制御 ✔ 規制上の独立性 ✘ 高い初期コスト ✘ 運用・保守が必要 ✘ スケールしにくい 例）SafeNet Luna Thales nShield クラウドHSM （専有型マネージド） ✔ FIPS Level 3認定 ✔ 物理管理が不要 ✔ 規制対応しやすい ✘ 比較的コスト高 ✘ クラウド依存 例）AWS CloudHSM Azure Dedicated HSM クラウドKMS （共有型鍵管理） ✔ 低コスト・即時利用 ✔ 他サービスと連携容易 ✔ 運用負荷が最小 ✘ HSMは共有インフラ ✘ 詳細制御は限定的 例）AWS KMS Azure Key Vault コスト: 高 ／ 自由度: 最大 コスト: 中 ／ 自由度: 大 コスト: 低 ／ 自由度: 中

実務上のポイント： PCI DSS準拠や金融規制対応など「鍵の占有管理が義務付けられる」ケースではクラウドHSM（専有型）、コスト重視・スタートアップ・社内システムの暗号化程度であればKMSで十分なことが多いです。

関連する規格・RFC

規格・RFC番号内容
FIPS 140-2 / 140-3暗号モジュールのセキュリティ要件（HSMの認定基準）
PCI DSS v4.0クレジットカード情報保護基準。鍵管理にHSM使用を推奨
PKCS#11HSMとアプリケーションをつなぐ標準API（Cryptoki）
RFC 5958非対称鍵のフォーマット標準（HSMで生成した鍵の表現に関連）
ISO/IEC 19790FIPS 140-3の国際標準版。暗号モジュール要件の国際的枠組み
Common Criteria (ISO 15408)HSM製品のセキュリティ評価に使われる国際基準

関連用語

  • KMS（Key Management Service） — クラウド上で暗号鍵をマネージドで管理するサービス。バックエンドにHSMを使うことが多い
  • PKI（Public Key Infrastructure） — 公開鍵暗号を活用した認証基盤。認証局の秘密鍵保護にHSMが不可欠
  • ゼロトラストセキュリティ — すべてのアクセスを検証するセキュリティモデル。鍵管理の厳格化と密接に関連
  • TLS/SSL — HTTPS通信を支える暗号プロトコル。サーバー証明書の秘密鍵をHSMで保護するケースがある
  • 電子署名 — データの真正性を保証する技術。署名用の秘密鍵をHSMで管理するのがベストプ