シークレット情報の管理
パスワードや API キーは手元に置かず、SSO で本人確認して金庫から都度取り出す
パスワードや API キーは手元の .env に書かず、クラウドの金庫に預けます。使うときは SSO で本人確認し、必要な鍵だけをメモリ上に取り出して使います。
- .env は接続先など非機密の設定だけに使う
- 取り出しは記録に残り、誰がいつ使ったか追える
- 更新・失効は金庫の差し替えだけで全員に反映
なぜローカルに秘密を置かないのか
いちばん手軽なのは、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コマンドにまとめてあります。本番では起動時に自動で鍵が注入されるので、普段はシークレットの存在を意識せずに開発できます。
押さえておきたい用語
- シークレット
- API キー・DB パスワード・各種トークンなど、漏れると悪用される秘密の値の総称。手元に置かないのが原則。
- シークレットマネージャ
- クラウド上の『鍵の金庫』。権限のある人・プログラムだけが取り出せ、中央で更新・失効・監査ができる。
- .env
- 環境変数をまとめたファイル。平文なので秘密は書かず、接続先など非機密の設定だけに使う。
- 一時的な資格情報
- 数時間で失効する使い捨ての通行証。盗まれても期限切れになるため被害が限定的。
- ローテーション
- 鍵を定期的に新しいものへ差し替えること。中央管理なら全員分を一度に更新でき、漏洩時はすぐ失効できる。
ここから先へ
この解説とつながりのあるページ