鍵管理ライフサイクルの原理（生成・ローテーション・失効）

鍵管理が解く問題：アルゴリズムでなく運用が漏れる

暗号アルゴリズムが破られて情報が漏れる事故は稀です。現実の漏洩のほとんどは、鍵の取り回し——どこに置き、どう配り、いつ替え、どう捨てるか——の失敗から起こります。AES-256 がいくら堅牢でも、その鍵が平文でログに出れば暗号は無意味になります。だから鍵には、生成から破棄までを一貫して律する**ライフサイクル（lifecycle）**という概念が要ります。

NIST SP 800-57 は鍵のライフサイクルを段階に分けて規定しています。本記事では実務で要となる生成・配布・保管・ローテーション・失効・破棄の6段階を、なぜその設計になるのかという原理から見ていきます。貫く原則は2つ。鍵を平文で晒す瞬間を最小化することと、1本漏れても被害を限定することです。

生成と配布：エントロピーと「平文を運ばない」

ライフサイクルの起点は生成です。鍵は暗号論的に安全な乱数源（CSPRNG）から生成されねばならず、ここで予測可能な乱数を使うと鍵空間が実質的に縮小し、総当たりが現実的になります。鍵生成は理想的にはHSMの内部で行い、平文の鍵が一度もメモリに載らないようにします。

次が配布です。生成した鍵を使う場所へ届ける段階ですが、ここが最も漏れやすい。平文の対称鍵をネットワークでそのまま送るのは論外で、原則として鍵を別の鍵で暗号化して運ぶ（鍵ラッピング）か、そもそも鍵を移動させない設計を採ります。後者が望ましく、鍵を HSM 内に固定し、アプリには鍵そのものでなく「鍵を指すハンドル」だけを渡せば、配布時に平文の鍵が境界外へ出ることがなくなります。

配布の三方式（安全性は下ほど高い）:

  平文配布         鍵をそのまま送る               ← 原則禁止
  ラップ配布       KEK で暗号化して送る           ← 移動が必要なら最低限これ
  非配布（参照）   鍵は HSM 内に固定、ハンドルだけ ← 望ましい

保管：鍵階層と KEK/DEK

保管の核心は鍵階層（key hierarchy）です。すべての鍵を同列に平置きするのではなく、鍵を暗号化する鍵とデータを暗号化する鍵を分けます。前者を KEK（Key Encryption Key／鍵暗号化鍵）、後者を **DEK（Data Encryption Key／データ暗号化鍵）**と呼びます。

DEK は実データを暗号化しますが、その DEK 自身を KEK でラップ（暗号化）して保管します。すると DEK は暗号化された状態でディスクや DB に置けるようになり、平文で守るべき鍵は最上位の KEK だけに集約されます。最上位の KEK（マスター鍵）だけを HSM の耐タンパ境界内に固定すれば、少数の鍵を物理保護するだけで無数の DEK を論理的に保護できます。

このラップ済み DEK を暗号文と一緒に保管する手法が**エンベロープ暗号化（envelope encryption）**です。各データに固有の DEK を割り当て、ラップした DEK を暗号文のヘッダに同梱します。復号時は KEK で DEK をアンラップし、その DEK で本体を復号する。クラウド KMS の中核機能であり、データごとに鍵を分ける設計を低コストで実現します。

ローテーション：上位鍵だけ替えれば済む理由

ローテーション（rotation）は、鍵を定期的に新しいものへ差し替える運用です。なぜ必要か。鍵は使うほど暴露面が広がり、1本の鍵で暗号化したデータ量が増えるほど、漏洩時の被害も暗号解析の手掛かりも増えるからです。暗号期間を区切って定期的に替えれば、仮に旧鍵が漏れても影響範囲がその世代に限定されます。

ここで鍵階層が効きます。ナイーブに考えると、鍵を替えるには全データを旧鍵で復号して新鍵で再暗号化する必要がありそうですが、これはペタバイト級では非現実的です。エンベロープ暗号化なら、KEK を替えるときに再ラップが必要なのはラップ済み DEK だけで済みます。

KEK ローテーション（実データに触れない）:

  旧KEK でアンラップ → DEK（平文、HSM 内） → 新KEK で再ラップ
       ↑ 動くのはラップ済みDEKのみ。実データは旧DEKのまま据え置き

DEK が暗号化している実データには一切触れず、最上位の鍵だけを差し替えられる。これがエンベロープ暗号化の運用上の最大の利点です。一方で DEK 自体を替えたい場合（DEK の暗号期間が来た、あるいは漏洩疑いがある場合）は、そのデータの再暗号化が避けられません。だからこそ、頻繁に替える層（KEK）と、替えると高くつく層（DEK）を分離しておく設計が効いてきます。

失効と破棄：捨てるタイミングを誤らない

鍵が漏洩した、あるいは暗号期間が満了した場合、その鍵を**失効（revocation）**させます。失効とは「以後その鍵での新規暗号化・署名を禁止する」状態への移行であり、即座の物理破棄とは区別されます。

ここが鍵管理の機微です。失効した鍵を直ちに消してはいけない場合があります。その鍵で暗号化された過去データがまだ存在するなら、復号のために旧鍵を保持し続ける必要があるからです。したがって失効鍵は「新規使用は禁止、復号専用に分離保管」という中間状態を経ます。署名鍵の場合は逆で、漏洩した署名鍵は失効情報を検証側へ伝播させる必要があり、その仕組みは証明書失効リスト（CRL）や OCSP として公開鍵基盤（PKI）に組み込まれています。

最終段階が**破棄（destruction）**です。鍵を本当に消す方法には2系統あります。

**暗号的消去（cryptographic erasure / crypto-shredding）**は強力です。データ本体を1バイトも触らず、その復号に必要な鍵を破棄するだけで、暗号文を解読不能な乱雑バイト列へと変えます。テラバイト級のディスクをゼロ埋めする代わりに、数十バイトの鍵を消すだけで瞬時に「論理的に消去」できる。これが成立するのは、データごとに鍵を分けてある（エンベロープ暗号化で DEK を分離してある）からこそで、鍵分離の設計が破棄段階で利いてくる好例です。

バックアップと鍵分離：可用性とのトレードオフ

鍵保護を突き詰めると可用性と衝突します。HSM のゼロ化や災害で鍵そのものを失うと、暗号化されたデータは永久に読めなくなる——これは漏洩と同じくらい深刻な事故です。だから鍵はバックアップを取りますが、平文でコピーを増やせば暴露面が広がる。両立の答えが、バックアップ自体を別の鍵で暗号化し、その鍵を元データから分離保管することです。

設計判断として、バックアップ用の鍵は本番の DEK とは別系統で管理し、ローテーション周期も独立させるのが定石です。本番鍵を頻繁に替えても、過去のバックアップは当時の鍵世代でしか復号できないため、バックアップ鍵の世代管理は本番以上に長い保持期間を要します。「漏洩を防ぐための鍵分離」と「読めなくなる事故を防ぐためのバックアップ」は対立する要求であり、信頼境界を分けることでのみ両立します。

まとめ

鍵管理ライフサイクルの本質は、鍵を平文で晒す瞬間を最小化し、1本漏れても被害をその世代に限定することに尽きます。生成は CSPRNG と HSM 内で、配布は移動させない設計を最優先に。保管では KEK/DEK の鍵階層を組み、最上位の鍵だけを物理保護に集約します。

エンベロープ暗号化は、この階層を運用に効かせる要です。ローテーションでは KEK の差し替えだけで実データの再暗号化を回避でき、破棄では暗号的消去で大量データを瞬時に無効化できる——いずれもデータごとに鍵を分けてあるからこそ成立します。失効鍵は即破棄せず復号専用に分離保管し、暗号化バックアップとその鍵は異なる信頼境界に置く。鍵保護の物理的土台はHSM と鍵保護の原理、鍵を含む機密情報の運用論はシークレット管理、鍵で何を守るかの基礎は暗号の基礎を合わせて参照してください。