# Secret Management Review

> シークレット（APIキー・トークン・認証情報・暗号鍵）の保管・配布・スコープ・ローテーション・漏洩対策をレビューする。外部連携・デプロイ設定・公開の前に使う。

- Skill: `thinkyou0714/secret-management-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/secret-management-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/secret-management-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/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

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動処理用のシークレットが過剰スコープでないか |
| データ / 認証 / ログ | — | シークレットがログ・外部送信に混入していないか |
| 実装 / 運用フロー | — | ローテーション・失効の運用手順があるか |
| 非エンジニア理解可能性 | — | 鍵の用途と保護を関係者に説明できるか |
| 会員共有 / 再利用耐性 | — | 管理方針が他機能・他環境に転用できるか |
| 他LLM移植耐性 | — | 判断が特定シークレット製品に依存していないか |

状態は 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](../../../src/lab-data-auth/rules/data-auth-principles.md) — データ・認証設計の正本（SoT）