Secret Management Review

Purpose

「鍵をコードに直書き」「漏れても失効できない」リスクを防ぐ。 シークレットのライフサイクル（生成〜配布〜失効）を点検し、最小スコープと回転可能性を確保する。

Use When

• API キー・トークン・DB 認証情報・暗号鍵を扱う機能を設計するとき
• 外部サービス連携・デプロイ設定・CI のシークレットを整理するとき
• リポジトリ・ログ・クライアントにシークレットが混入していないか確認するとき
• 公開・共有ゲート（GATE-3）の前段でシークレットを点検したいとき

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 対象シークレット: 種別（APIキー / トークン / 鍵 / パスワード）
• 保管先: どこに保存し、どこへ配布するか（環境変数 / Vault / CI）
• 利用主体: そのシークレットを使う処理・サービス・人
• 回転方針: いつ・誰が・どう失効/再発行するか（わかる範囲で）

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: シークレット管理で最も危ういのはどこか
2. 根拠: その論点をそう判断した理由
3. シークレット台帳: 種別 / 保管 / スコープ / 回転 / 漏洩時影響 の評価
4. 含意: 不適切な管理が招く影響（漏洩・横展開・失効不能）
5. 改善案: 最小スコープ化・Secrets Manager・ローテーション自動化の打ち手
6. 代替案: 短命トークン / ワークロード ID 等、長期鍵を持たない設計
7. 判断材料: 管理方針の確定に必要な人間の確認事項

Review Lens

• 目的妥当性: 各シークレットの権限スコープが用途に対して最小か
• 範囲の過不足: 不要に広い・長寿命なシークレットがないか
• 中長期リスク: 漏洩検知・失効・再発行ができるか
• LAB全体との整合性: LMS / 自動化 / B2B 展開の運用方針と整合するか
• 非エンジニア理解可能性: 「どの鍵が・何に使われ・どう守るか」を説明できるか
• 他LLM移植耐性: 判断が特定シークレット製品の前提に依存していないか

Instructions

1. 扱うシークレットを台帳化し、種別・保管先・利用主体を列挙する
2. 各シークレットの権限スコープを確認し、最小化できるものを指摘する
3. ソース・ログ・クライアント・URL への混入有無を点検する
4. ローテーション（回転）と失効の手順・所要時間を確認する
5. 漏洩時の検知・失効・影響範囲を整理する
6. 不明な点は推測せず、確認事項として明示する

Guardrails

• シークレットをコード・ログ・リポジトリに直書きする設計を許容しない
• 「とりあえず広いスコープ」を許容しない（最小スコープを促す）
• 失効・再発行手段のないシークレット配布を勧めない
• 管理方針の最終確定は人間に委ねる

LAB Cross-Check

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

施工AI（Claude Code / Cursor 等）へ渡す前に以下を確定させること。

• 要件: 確定した保管先・スコープ・ローテーション方針
• 成功条件: 最小スコープ・失効可能性が満たされたと判断する基準
• 失敗条件: シークレット漏洩・失効不能を検知する基準
• 実行範囲: 変更してよいシークレット保管・配布・CI 設定
• 影響範囲: 変更が波及するサービス・連携先
• ロールバック方針: 回転・失効が問題を起こした場合の戻し方
• コスト比較: 管理方式ごとの実装・運用コスト

Further Reading

• auth-system-design skill — 認証で使う鍵・トークンの設計
• auth-boundary-check skill — シークレットが守る権限境界の点検
• pii-handling-review skill — PII とシークレットを分けて扱う設計
• audit-log-design skill — シークレット利用・失効の監査ログ
• data-auth-principles.md — データ・認証設計の正本（SoT）