Overview
鍵管理(Key Management)とは、暗号鍵の生成から廃棄に至るまでのライフサイクル全体を安全に管理するプロセスおよび技術の総称です。暗号技術がどれほど強力であっても、暗号鍵の管理が不適切であれば、暗号システム全体の安全性が崩壊します。鍵管理は暗号セキュリティの中核をなす要素であり、情報セキュリティにおいて最も重要な運用課題の一つです。
現代のIT環境では、TLS/SSL通信、データベース暗号化、ディスク暗号化、デジタル署名、API認証など、あらゆる場面で暗号鍵が使用されています。クラウドサービスの普及やマイクロサービスアーキテクチャの浸透に伴い、管理すべき暗号鍵の数は爆発的に増加しており、組織的かつ自動化された鍵管理の仕組みが不可欠となっています。
鍵管理の国際標準としてNIST SP 800-57(Recommendation for Key Management)が広く参照されており、鍵の種類や用途に応じた管理方針、暗号アルゴリズムの選定基準、鍵の有効期間の設定方法などが体系的に定義されています。
Details
鍵のライフサイクル
暗号鍵は以下の段階を経て管理されます。各段階において適切なセキュリティ対策を講じることが重要です。
- 鍵生成(Generation):暗号論的に安全な乱数生成器(CSPRNG)を使用し、十分なエントロピーを持つ鍵を生成します。鍵の品質は暗号システム全体の安全性を左右するため、予測可能な値やシード値の使用は厳禁です。
- 鍵配送(Distribution):生成された鍵を正当な利用者に安全に届けるプロセスです。鍵交換プロトコル(Diffie-Hellman、TLSハンドシェイクなど)やPKIを用いた暗号化配送が一般的です。
- 鍵保管(Storage):使用中および待機中の鍵を安全に保管します。HSM(Hardware Security Module)やソフトウェアキーストア、暗号化されたデータベースなどが使用されます。
- 鍵利用(Usage):鍵を実際の暗号処理に使用する段階です。用途の制限(暗号化専用、署名専用など)やアクセス制御を適切に設定します。
- 鍵更新(Rotation):定期的に新しい鍵に切り替えるプロセスです。鍵の使用期間が長期化すると漏洩リスクが高まるため、計画的なローテーションが必要です。
- 鍵廃棄(Destruction):不要になった鍵を完全に消去するプロセスです。メモリからの安全な削除や、バックアップを含むすべてのコピーの確実な破棄が求められます。
KMS(Key Management Service)
クラウド環境における鍵管理の主流となっているのがKMS(Key Management Service)です。代表的なサービスとして以下があります。
- AWS KMS:AWSのマネージドサービスで、CMK(Customer Master Key)を中心とした階層的な鍵管理を提供します。CloudTrailとの連携により鍵の使用履歴を完全に監査できます。エンベロープ暗号化により、データキーをCMKで保護する二層構造を実現します。
- Azure Key Vault:Microsoftのクラウド鍵管理サービスで、鍵、シークレット、証明書を一元管理します。FIPS 140-2 Level 2認定のHSMバックエンドを備え、Azure ADと連携したきめ細かなアクセス制御が可能です。
- HashiCorp Vault:オープンソースベースのシークレット管理ツールで、マルチクラウド環境やオンプレミス環境でも利用可能です。動的シークレット生成、リース管理、暗号化as-a-Service(Transit Secret Engine)など、高度な機能を提供します。
HSM(Hardware Security Module)
HSMは暗号鍵の生成・保管・暗号処理を専用ハードウェア内で行う物理デバイスです。鍵がHSMの外部に出ることがないため、ソフトウェアベースの鍵管理よりも高い安全性を実現します。FIPS 140-2/140-3やCommon Criteriaなどの国際認証を取得したHSMが、金融機関や政府機関で広く使用されています。代表的な製品にはThales Luna HSM、Entrust nShield、AWS CloudHSMなどがあります。
鍵エスクローと鍵ラッピング
鍵エスクロー(Key Escrow)とは、暗号鍵のコピーを信頼できる第三者機関に預託する仕組みです。鍵の所有者が鍵を紛失した場合や、法執行機関による合法的なアクセスが必要な場合に備えて使用されます。ただし、プライバシーの観点から議論が多い手法でもあります。
鍵ラッピング(Key Wrapping)とは、暗号鍵を別の鍵(KEK: Key Encryption Key)で暗号化して保護する技術です。NIST SP 800-38Fで標準化されたAES Key Wrapアルゴリズムが広く使用されています。KMSのエンベロープ暗号化も鍵ラッピングの一形態です。
職務分掌(Separation of Duties)
鍵管理における職務分掌は、単一の個人が暗号鍵のライフサイクル全体を制御できないようにする組織的な管理手法です。鍵の生成者、使用者、管理者の役割を分離し、複数人の承認を必要とする仕組み(M-of-Nコントロール)を導入することで、内部犯行や誤操作によるリスクを低減します。
Security Measures
- 01HSMの活用:重要な暗号鍵(ルートCA鍵、マスターキーなど)はHSMに保管し、鍵がハードウェア外部に出ないようにします。FIPS 140-2 Level 3以上の認証を取得したHSMの使用を推奨します。クラウド環境ではCloudHSMやDedicated HSMサービスを活用してください。
- 02定期的な鍵ローテーションの実施:暗号鍵には明確な有効期限を設定し、自動化されたローテーションポリシーを導入します。NIST SP 800-57の推奨に従い、鍵の種類と用途に応じた適切なローテーション間隔を設定してください。対称鍵は1〜2年、非対称鍵は2〜3年が一般的な目安です。
- 03職務分掌の徹底:鍵の生成、配布、使用、廃棄の各プロセスに対して異なる担当者を割り当て、単一の個人がすべての権限を持つことを防ぎます。M-of-Nコントロール(例:5人中3人の承認が必要)を導入し、重要な鍵操作には複数人の承認を必須とします。
- 04安全な鍵バックアップ:鍵のバックアップは暗号化された状態で、物理的に異なる場所に保管します。鍵分割(Secret Sharing)を用いて、Shamirの秘密分散法などにより単一のバックアップからは鍵を復元できない仕組みを構築します。バックアップの定期的な復元テストも重要です。
- 05鍵アクセスの監査とログ管理:すべての鍵操作(生成、読み取り、使用、削除)を監査ログに記録し、異常なアクセスパターンを検知する仕組みを導入します。AWS CloudTrail、Azure Monitor、SIEM連携などを活用し、リアルタイムでの監視体制を構築してください。
- 06鍵管理ポリシーの策定と教育:組織全体の鍵管理ポリシーを文書化し、開発者・運用者向けのセキュリティ教育を定期的に実施します。ソースコードやリポジトリへの鍵のハードコーディング禁止、環境変数やKMSの活用方法など、具体的なガイドラインを整備してください。
Incidents
📋 Heartbleed脆弱性による秘密鍵漏洩(2014年)
2014年4月に公表されたOpenSSLのHeartbleed脆弱性(CVE-2014-0160)は、TLS Heartbeat拡張のバッファオーバーリード脆弱性により、サーバーメモリ上の情報が最大64KBずつ繰り返し読み取り可能となるものでした。この脆弱性を悪用すると、サーバーの秘密鍵、セッション鍵、ユーザーのパスワードやCookieなどが漏洩する可能性がありました。
実際にカナダ歳入庁では約900件の社会保険番号が流出し、複数の大手サービスがサーバー証明書の失効と再発行を余儀なくされました。この事件は、秘密鍵がメモリ上に平文で存在するリスクと、HSMを使用してメモリ空間を分離することの重要性を改めて示しました。全世界のWebサーバーの約17%が影響を受けたとされています。
📋 UberのAWSアクセスキーGitHub漏洩事件(2016年)
2016年、Uberのエンジニアが社内のGitHubリポジトリにAWSのアクセスキーをハードコーディングしてコミットしていたことが発覚しました。攻撃者はこのアクセスキーを利用してUberのAWS S3バケットにアクセスし、約5,700万人分のドライバーおよび乗客の個人情報(氏名、メールアドレス、電話番号、運転免許証番号)を窃取しました。
Uberは情報漏洩の事実を1年以上隠蔽し、攻撃者に10万ドルの口止め料を支払っていたことも後に判明し、社会的な信頼を大きく損ないました。この事件は、ソースコード中にクレデンシャルを含めることの危険性と、シークレット管理ツール(Vault、AWS Secrets Managerなど)の導入の重要性を広く認識させる契機となりました。
📋 Marriott International大規模情報漏洩事件(2018年)
2018年11月、Marriott Internationalは子会社Starwood Hotels & Resortsの予約データベースから約5億件の顧客情報が漏洩したことを公表しました。調査の結果、2014年からの4年間にわたり攻撃者がシステムに不正アクセスしていたことが判明しました。
この事件では暗号化鍵の管理体制に重大な問題がありました。顧客のパスポート番号やクレジットカード情報の一部は暗号化されていましたが、復号に必要な鍵が同一サーバー上に保管されていたため、暗号化が実質的な防御として機能しませんでした。暗号化データと鍵の物理的な分離が行われていなかった点が、被害を拡大させた根本原因の一つです。GDPRに基づき約1億2400万ドルの制裁金が科されました。