シークレット管理と動的クレデンシャル

なぜ静的・長命シークレットが危険なのか

データベースのパスワード、API キー、クラウドのアクセスキー——これらを設定ファイルや環境変数、ましてやソースコードへベタ書きすると、**静的（値が変わらない）かつ長命（無期限あるいは長期間有効）**なシークレットが生まれます。これが事故の温床です。理由は三つの性質に集約されます。

第一に、漏洩しても有効であり続ける。Git 履歴に紛れたキーや、ログに吐き出されたトークンは、消したつもりでもどこかに残り、何ヶ月も有効なまま放置されます。攻撃者にとって長命シークレットは「拾った瞬間からいつでも使える鍵」です。第二に、誰がいつ使ったか追えない。同じパスワードを多数のサーバーやサービスが共有していると、漏洩源の特定（attribution）が原理的にできません。第三に、ローテーションが痛い。共有された静的シークレットを更新するには、それを使う全箇所を同時に切り替えねばならず、運用上ほぼ実施されません。結果として「変えられないから変えない」鍵が増殖します。

静的・長命シークレットの攻撃面
  有効期間が無限 → 漏洩 1 回で恒久的な侵害
  共有されている → 漏洩源の特定が不能
  ローテ困難     → 実際には更新されず古い鍵が残り続ける
  保管場所が分散 → コード・設定・CI・チャット…どこに何があるか不明

この問題への根本的な答えが、シークレットを一元管理する専用システム（HashiCorp Vault に代表される秘密管理基盤）と、動的クレデンシャルという考え方です。

静的シークレットの保管：暗号化と最小権限

まず、避けられない静的シークレット（外部 SaaS の API キーなど）をどう保管するか。原則は二つです。保管時暗号化（encryption at rest）で、ストレージが盗まれても中身が読めないようにすること。そして最小権限のアクセス制御で、各アプリ・各人が必要なパスだけを読めるようにし、すべての読み取りを監査ログに残すことです。

秘密管理基盤は、シークレットを平文のまま保存しません。値はマスター鍵（あるいはそこから派生する鍵）で暗号化され、暗号文だけがバックエンドストレージ（etcd・Consul・クラウドの KV など）に置かれます。重要なのは、ストレージ層は暗号文しか持たないという分離です。ストレージ管理者やバックアップを盗んだ攻撃者は、復号鍵を持たない限りシークレットを得られません。この鍵をどう守るかが後述のシール／アンシールの主題です。

動的クレデンシャル：都度発行と短命化

静的シークレットの危険を構造から取り除くのが**動的クレデンシャル（dynamic secrets）**です。発想を転換します——シークレットをあらかじめ作って保管するのではなく、要求された瞬間に、その要求者専用の短命な認証情報を生成する。

仕組みはこうです。秘密管理基盤は、対象バックエンド（データベース・クラウド IAM・PKI など）に対する管理者権限（root 相当のクレデンシャル）を一つだけ保持します。アプリが「DB の読み取り権限が欲しい」と要求すると、基盤はその管理者権限を使ってバックエンド側にその場で新しいユーザー（あるいはトークン）を作成し、短い TTL を付けてアプリへ返します。アプリはそれを使い、TTL が切れると基盤が**バックエンドからそのユーザーを削除（失効）**します。

動的クレデンシャルの発行フロー
  1. アプリが基盤へ認証（後述のアイデンティティで本人確認）
  2. 「db/creds/readonly で資格情報をくれ」と要求
  3. 基盤が DB の管理者接続で  CREATE USER v-app-xxx ... を実行
  4. 生成した user/password を TTL=1h のリース付きで返す
  5. アプリは 1 時間それを使う
  6. リース満了 → 基盤が DROP USER v-app-xxx を実行し失効

この設計の効能は決定的です。漏洩しても TTL ぶんしか使えないため攻撃の窓が秒〜時間単位に縮まり、各要求者に固有の資格情報が割り当たるため漏洩源を特定でき、そもそも保管しないため「盗む対象の山」自体が存在しません。静的シークレットの三つの弱点が、原理から消えます。

リースと自動ローテーション

動的クレデンシャルの時間軸を管理するのが**リース（lease）**です。発行された資格情報には必ず TTL（および延長可能な上限 max TTL）が紐づき、基盤はリースの満了時刻を内部で台帳管理します。満了が近づいてもアプリがまだ必要なら、**更新（renew）でリースを延ばせます。逆に処理が早く終われば、明示的な取り消し（revoke）**で即座に失効させられます。

ここにローテーションが自然に組み込まれます。動的クレデンシャルは新しい要求のたびに新しい値が出るので、短い TTL で運用すること自体が継続的なローテーションになります。一方、どうしても動的化できない**静的シークレットには「ローテーション機能」**が用意され、基盤が定期的にバックエンド側のパスワードを書き換え、新しい値だけをアプリに渡します。アプリは値を直接知らず、基盤越しに取得するため、人手を介さず鍵が回り続けます。

暗号化バックエンドとシール／アンシール

すべての暗号文は最終的に**マスター鍵（master key）で守られ、そのマスター鍵自身を暗号化キー（unseal key／root key）が守る、という鍵の階層になっています。問題は——その一番上の鍵をどこに置くか。ディスクに平文で置けば、ディスクを盗まれた時点で全シークレットが復号されます。これを避けるのがシール（seal）／アンシール（unseal）**の機構です。

シール状態とは、秘密管理基盤が起動直後にいる状態で、ストレージの暗号文は読めても復号鍵がメモリ上に存在しないため、何のシークレットも返せません。マスター鍵を復元してメモリに載せ、要求に応答できる状態にする操作がアンシールです。肝は、アンシール鍵を一人の手に委ねない設計にあります。

ここで使われるのが**シャミアの秘密分散（Shamir's Secret Sharing）**です。原理は多項式補間です。秘密 S を切片（定数項）に持つ次数 t−1 の多項式を作り、その曲線上の点を n 個配って「鍵シェア」とします。次数 t−1 の多項式を一意に決めるにはちょうど t 個の点が要るので、しきい値 t 個のシェアが集まれば S を補間で復元でき、t 個未満では情報理論的に何も分からない。たとえば「5 枚配って 3 枚揃えば復元（n=5, t=3）」とすれば、3 人の鍵保持者が合意して初めてアンシールでき、2 枚以下を盗んでも無意味です。

シャミア秘密分散（n=5, t=3 の例）
  秘密 S を切片に持つ次数 2 の多項式 f(x) を作る
  シェア = 曲線上の点 (1,f(1)) (2,f(2)) … (5,f(5)) を各人へ配布
  復元   = 任意の 3 点があればラグランジュ補間で f(0)=S を一意に決定
  防御   = 2 点以下では候補多項式が無限にあり S を特定できない

実運用では人手のアンシールは事故りやすいので、**自動アンシール（auto-unseal）**が使われます。マスター鍵の保護を、クラウドの KMS や HSM（ハードウェアセキュリティモジュール）に委譲し、起動時にそれらへ「ラップ解除」を依頼してメモリへ載せます。鍵は HSM の外へ平文で出ない、という境界が信頼の根になります。

アイデンティティと認証：そもそも誰に出すのか

動的クレデンシャルは強力ですが、「正しい要求者にしか発行しない」という入口が崩れれば全部無意味です。ここで問われるのがワークロードのアイデンティティです。アプリへ「基盤に認証するための鍵」を渡すと、結局その鍵が長命シークレットになってしまう——いわゆる**ブートストラップ問題（secret zero）**です。

解は、プラットフォームが保証する身元を使うことです。Kubernetes の ServiceAccount トークン、クラウドのインスタンスメタデータ／IAM ロール、SPIFFE/SPIRE が発行するワークロード証明書などは、そのワークロードが本当にその環境で動いていることをプラットフォームが署名つきで証明します。基盤はその署名を検証して身元を確認し、初めて動的クレデンシャルを発行します。こうして「最初の一つの秘密」を人手で配らずに済ませ、信頼の連鎖をプラットフォームの根まで遡れるようにします。

設計をつなぐ実務原則

• TTL は短く、ただし取り直しを前提に：短命化はリース更新／再発行の堅牢性とセットでなければ、可用性を落とす自爆装置になる。
• すべてを監査する：誰がいつ何を読んだ・発行したを残す。動的クレデンシャルの要求者固有性は、監査ログがあって初めて漏洩源特定に活きる。
• シークレットをコードから締め出す：CI/リポジトリへの混入をスキャンで検知し、漏れた鍵は即ローテ・即失効する（/devops/dependency-scanning/）。
• 信頼の起点を分散する：アンシール鍵・root トークンを一点に集めない。秘密分散のしきい値設計と人手運用の分離が要。

まとめ

• 設定やコードへ埋め込んだ静的・長命シークレットは、無期限に有効で漏洩源も追えずローテも困難で、攻撃面が時間とともに広がり続ける。
• 動的クレデンシャルは、要求のたびに要求者固有の短命資格情報を都度発行し、リース満了で基盤が下流から自動失効させる。漏洩しても TTL ぶんしか悪用できない。
• リースが TTL・更新・取り消しを管理し、短 TTL の発行が継続的ローテーションになる。動的化できない静的シークレットには自動ローテーション機能を当てる。
• すべての暗号文はマスター鍵で守られ、その鍵はシール状態でメモリ外に置かれる。アンシールはシャミアの秘密分散で、しきい値ぶんのシェアが揃って初めて復元でき、一人では復元できない。
• 入口のワークロードのアイデンティティ（secret zero の解消）と監査ログがそろって、動的クレデンシャルの安全性は初めて実効的になる。