概要
どれほど強力な暗号アルゴリズムを使っても、鍵の管理がずさんであれば暗号化は無意味になります。鍵管理（Key Management） は暗号鍵の生成・保管・使用・ローテーション・失効・破棄という一連のライフサイクルを安全に運用する仕組みです。KMS（Key Management Service） はこれをソフトウェア／クラウドサービスとして提供し、HSM（Hardware Security Module） は鍵をハードウェアレベルで保護します。SC試験では暗号アルゴリズムそのものより「鍵をどう守り、どう運用するか」という管理面が問われます。
仕組みと動作原理
鍵のライフサイクル
暗号鍵は生成された瞬間から破棄されるまで、常に漏洩・不正利用のリスクにさらされています。ライフサイクル全体を管理することが鍵管理の本質です。
| フェーズ | 内容 | 主なリスク |
|---|---|---|
| 生成（Generation） | 十分なエントロピーを持つ乱数から鍵を生成 | 乱数品質が低いと鍵が推測可能に |
| 保管（Storage） | 鍵をアプリケーションコードや平文設定から隔離して保護 | ソースコード・環境変数への直書き |
| 配布（Distribution） | 必要なサービス・利用者にのみ安全に鍵を渡す | 鍵の平文でのメール送付・共有ドライブ保存 |
| 利用（Usage） | 暗号化・復号・署名などの操作に鍵を使用 | 過剰な権限を持つ主体による濫用 |
| ローテーション（Rotation） | 定期的に新しい鍵へ切り替える | 長期間同一鍵を使い続けることによる漏洩時の被害拡大 |
| 失効（Revocation） | 漏洩や退職等が発生した鍵を即座に無効化 | 失効プロセスの遅延・手順不備 |
| 破棄（Destruction） | 不要になった鍵を復元不可能な形で完全に削除 | バックアップ等への鍵の残存 |
なぜ鍵をローテーションするのか
同一の鍵を使い続けると、以下のリスクが蓄積します。
- 漏洩時の被害範囲が拡大：長期間使われた鍵ほど、暗号化された過去データの量が多く、漏洩時の影響が大きい
- 鍵の推測・解析リスク：同一鍵で暗号化されたデータ量が増えるほど暗号解析の材料が増える
- コンプライアンス要件：PCI DSSなど多くの基準が定期的な鍵ローテーションを要求
ローテーション時は、旧鍵で暗号化済みのデータをすぐに再暗号化する必要はなく、新旧の鍵を一定期間並存させる（旧鍵は復号のみ許可）運用が一般的です。
HSM（Hardware Security Module）の役割
HSMは鍵の生成・保管・暗号演算を行う専用のハードウェア装置です。ソフトウェアだけで鍵を扱う方式と比べて、以下の点で保護レベルが高くなります。
| 特性 | 内容 |
|---|---|
| 鍵の非搬出性 | 秘密鍵はHSM内部で生成され、平文の形では外部に一切出力されない |
| 耐タンパー性 | 物理的にこじ開けようとすると内部の鍵を自動消去する仕組みを持つ |
| FIPS 140-2/3認証 | 米国政府標準の暗号モジュールセキュリティ要件に基づく第三者認証 |
| 専用処理性能 | 大量の暗号演算（署名・復号）を高速に処理できる |
HSMはルート認証局（Root CA）の秘密鍵管理、決済システムの鍵管理、コード署名など、鍵が漏洩した場合の被害が壊滅的なユースケースで使われます。
クラウドKMSとオンプレHSMの違い
クラウドプロバイダが提供するKMS（AWS KMS・Azure Key Vault・Google Cloud KMSなど）は、内部的にHSMを利用しつつ、鍵管理をサービスとして抽象化したものです。
| 観点 | オンプレHSM | クラウドKMS |
|---|---|---|
| 導入コスト | 高い（専用機器の購入・設置） | 低い（従量課金） |
| 運用負荷 | 自社で物理的・論理的に管理 | プロバイダが基盤を管理 |
| 鍵の専有度 | 完全専有（マルチテナントなし） | 共有HSM上に論理分離（プランにより専有HSMも選択可） |
| 鍵の持ち出し | 不可能（設計上） | 不可能（KMS外に平文鍵は出ない） |
| スケーラビリティ | 台数分の物理制約あり | 容易にスケール |
| 監査・アクセス制御 | 自社で構築が必要 | IAM・CloudTrail等と統合済み |
エンベロープ暗号化（Envelope Encryption）
大量のデータをHSM/KMSで直接暗号化すると、演算負荷や通信コストの点で非効率です。そこで鍵を階層化し、実データは高速なローカル鍵で暗号化し、そのローカル鍵だけをKMSで保護する方式が使われます。
1. アプリケーションがKMSに「データキー生成」を要求
2. KMSがデータキー（平文）＋そのデータキーをルートキーで暗号化した暗号化データキーを返す
3. アプリケーションは平文データキーでデータを暗号化し、暗号化データキーと一緒に保存
4. 平文データキーはメモリ上で使い終わったら破棄（保存しない）
5. 復号時：暗号化データキーをKMSに送って復号を依頼 → 平文データキーを得てデータを復号この方式により、ルートキー（マスターキー）はKMS/HSMの外に一切出ることなく、大量データの暗号化を高速に行えます。ルートキーをローテーションする際も、データキー自体を再暗号化するだけで済み、実データの再暗号化は不要です。
SC試験での頻出ポイント
- 鍵の非搬出性：HSM内で生成された秘密鍵は平文の形で外部に出力されない設計になっている
- エンベロープ暗号化の目的：大量データの暗号化性能とルートキー保護を両立させる階層構造
- 鍵ローテーションと再暗号化の関係：ローテーション時に過去データすべてを即座に再暗号化する必要はなく、新旧鍵を並存させる運用が現実的
- クラウドKMSでも鍵は平文で取得できない：KMS外への鍵の持ち出しはAPI設計上できない（復号・署名等の演算をKMS内で完結させる）
- ルートCA/ルートキーの保護レベル：被害が壊滅的になる最上位の鍵ほど、HSM・オフライン保管など強固な保護が必要
よくある誤問・ひっかけパターン
誤り① 「クラウドKMSは鍵をクラウド事業者が自由に見られるので危険」→ 誤。KMSは暗号演算をサービス内部で完結させる設計であり、平文鍵をAPI経由で取得することはできません。事業者側の運用者もアクセス制御・監査ログの対象です。
誤り② 「鍵をローテーションしたら過去に暗号化したデータはすぐに読めなくなる」→ 誤。一般的な運用では旧鍵を復号用として一定期間保持し、新規の暗号化にのみ新鍵を使います。即座にデータが読めなくなるわけではありません。
誤り③ 「エンベロープ暗号化は単に二重に暗号化しているだけで意味がない」→ 誤。目的は「性能」と「鍵保護」の両立です。実データは高速なローカル鍵で暗号化し、そのローカル鍵だけをHSM/KMSで守ることで、大量データでもマスターキーを外部に晒さずに済みます。
関連用語
- PKIと証明書管理 — ルートCAの秘密鍵保護にHSMが使われる代表例
- ハイブリッド暗号 — セッション鍵と長期鍵を使い分ける発想はエンベロープ暗号化と共通
- クラウドセキュリティ設計 — クラウドKMSはクラウドセキュリティ設計の中核要素の一つ
重要キーワード
| 用語 | 説明 |
|---|---|
| KMS | 鍵の生成・保管・ローテーションをサービスとして提供する鍵管理システム |
| HSM | 鍵をハードウェアレベルで保護する耐タンパー性を持つ専用装置 |
| エンベロープ暗号化 | データキーで実データを暗号化し、データキー自体をルートキーで保護する階層構造 |
| ルートキー（マスターキー） | 他の鍵（データキー）を暗号化・保護するための最上位の鍵 |
| 鍵ローテーション | 漏洩時の被害範囲を限定するため定期的に鍵を新しいものへ切り替える運用 |
| FIPS 140-2/3 | 暗号モジュールのセキュリティ要件を定めた米国政府標準・認証制度 |