なぜローカルに秘密を置かないのか
いちばん手軽なのは、API キーや DB パスワードを手元の .env ファイルに書く方法。でもそれは、パソコンの中に『むき出しの鍵』を置いている状態です。紛失や誤コミット1つで漏れ、共有の鍵なら全員・全システムに影響が及びます。
各ブロックや矢印をクリックすると、その仕組みの説明がここに表示されます。
手元の鍵は紛失・誤コミットで漏れる — 更新も全員の手作業になる
この図をテキストで読む
構成図「鍵を手元に置く？ 置かない？」。ブロック6個、つながり4本。 枠: ❌ 手元に鍵を置く（ブロック3個）、✅ 鍵を持たない（ブロック3個）。 【ブロック】 - .env に平文で保存: PCの中に鍵が居座る - 紛失・誤コミットで流出: 漏れたら全員に影響 - 鍵の更新が大変: 全員に配り直し - SSOで本人確認: パスワードは持たない - 必要なときだけ取得: メモリ上だけで使う - 一括で更新・失効: 中央で差し替え 【図の符号】青の囲み枠=境界の囲み / 橙の囲み枠=守られた内側 【流れ】 - ❌ 手元に置く世界: .env に平文で保存 → 紛失・誤コミットで流出 → 鍵の更新が大変 - ✅ 鍵を持たない世界: SSOで本人確認 → 必要なときだけ取得 → 一括で更新・失効
都度SSOで金庫から取り出す
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
シーケンス図「都度取得の流れ」。参加者4人、ステップ8個。 【参加者】（左から右） - 開発者 / アプリ: ローカル or 本番 - SSO: 本人確認の窓口 - Secrets Manager: クラウドの鍵の金庫 - 外部サービス: DB / 外部API 【流れ】（上から下へ） ── ① 本人確認（パスワードは持たない） ── 1. 開発者 / アプリ → SSO: SSOでログイン（aws sso login など） 2. SSO → 開発者 / アプリ: 一時的な資格情報を発行（応答） ── ② 必要なときに鍵を取り出す ── 3. 開発者 / アプリ → Secrets Manager: シークレットを指定して取得 4. Secrets Manager → 開発者 / アプリ: API キー・DB パスワードを返す（応答） 5. 開発者 / アプリ（自身で処理）: メモリ上（process.env）に展開 ── ③ 鍵を使ってサービスを呼ぶ ── 6. 開発者 / アプリ → 外部サービス: 取り出した鍵で接続 7. 外部サービス → 開発者 / アプリ: 応答を返す（応答） ── ④ 鍵を入れ替えるとき（運用） ── 8. Secrets Manager（自身で処理）: 中央で鍵をローテーション
手間は 5SLAB の仕組みで最小化
SSO は一度ログインすれば一定時間使い回せ、鍵の取得や外部サービスへの接続は aws-dev-tunnel などのスキル1コマンドにまとめてあります。本番では起動時に自動で鍵が注入されるので、普段はシークレットの存在を意識せずに開発できます。
押さえておきたい用語
- シークレット
- SSO（シングルサインオン） この用語の解説を読む
- シークレットマネージャ
- .env
- 一時的な資格情報
- ローテーション
『ログインと守りの基本』を読み終えました。
認証・認可・MFA・SSO を区別して使い分け、自社のログイン周りの守りを点検できるようになります。