シークレット情報の管理

構成図「鍵を手元に置く？ 置かない？」。ブロック6個、つながり4本。 枠: ❌ 手元に鍵を置く（ブロック3個）、金庫へ保管・配布を集約（ブロック3個）。 【ブロック】 - .env に平文で保存: PCの中に鍵が居座る - 紛失・誤コミットで流出: 漏れたら全員に影響 - 鍵の更新が大変: 全員に配り直し - 取得権限を絞る: 人とプログラムのID - 必要なときに取得: 取得後も秘密として扱う - 交換手順を自動化: 発行元・金庫・利用側 【図の符号】墨の囲み枠=守られた内側 【流れ】 - ❌ 手元に置く世界: .env に平文で保存 → 紛失・誤コミットで流出 → 鍵の更新が大変 - 金庫へ集約する: 取得権限を絞る → 必要なときに取得 → 交換手順を自動化

シーケンス図「都度取得の流れ」。参加者4人、ステップ11個。 【参加者】（左から右） - 開発者 / アプリ: ローカル or 本番 - 認証基盤: 本人確認の窓口 - Secrets Manager: クラウドの鍵の金庫 - 外部サービス: DB / 外部API 【流れ】（上から下へ） ── ① 取得のための認証 ── 1. 開発者 / アプリ → 認証基盤: SSOや実行IDで認証 2. 認証基盤 → 開発者 / アプリ: 一時的な資格情報を発行（応答） ── ② 必要なときに鍵を取り出す ── 3. 開発者 / アプリ → Secrets Manager: シークレットを指定して取得 4. Secrets Manager → 開発者 / アプリ: API キー・DB パスワードを返す（応答） 5. 開発者 / アプリ（自身で処理）: 取得した秘密を必要な範囲で使う ── ③ 鍵を使ってサービスを呼ぶ ── 6. 開発者 / アプリ → 外部サービス: 取得した鍵で接続 7. 外部サービス → 開発者 / アプリ: 応答を返す（応答） ── ④ 鍵を入れ替えるとき（運用） ── 8. 開発者 / アプリ → 外部サービス: 発行元で新しい鍵を準備 9. 開発者 / アプリ → Secrets Manager: 新しい鍵を金庫へ保存 10. 開発者 / アプリ（自身で処理）: 再取得・切替を確認 11. 開発者 / アプリ → 外部サービス: 旧鍵を失効し、拒否を確認