サービスは、DBのパスワードや外部サービスのAPIキーなど、見られてはいけない秘密を持っています。その扱い方の基本です。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
なぜ気をつける？
秘密の鍵が漏れると、DBの中身を抜かれたり、外部サービスを勝手に使われて課金されたり——被害が直接的です。特に、コードに直書きしたり、フロント（ブラウザ）に置くのは危険。リポジトリやブラウザから簡単に読まれます。
アニメーション『秘密情報の扱い（隔離）』を開く
この部分をもっと深く（中級）
秘密（APIキー・DBパスワード・署名鍵）が漏れると、DBの中身を抜かれたり、外部サービスを勝手に使われて課金されたり——被害が直接的です。中級で押さえたいのは、秘密は「置き場所」だけでなく「経路」でも漏れるという視点です。
- コードに直書き — リポジトリの履歴に残り、公開・共有で流出
- フロントへの埋め込み — ブラウザに配るコードは全部読まれる前提
- ログ・エラー出力 — トークンをそのまま出すと保存先から漏れる
- CI/CDの設定 — ビルドログや設定ファイルに平文で残る
アニメーション『秘密情報の扱い（隔離）』を開く
どう扱う？
- コードの外に置く — 環境変数や、専用のシークレット管理（シークレットマネージャ）に保管し、コードからは参照だけする
- リポジトリに入れない —
.gitignoreで秘密ファイルを除外。うっかり混入を防ぐ仕組みも入れる - フロントに置かない — ブラウザに配るコードは全部読まれる前提
- ローテーション — 定期的に、また漏れたら即、鍵を新しくする
この部分をもっと深く（中級）
- コードの外に置く — 環境変数や専用のシークレットマネージャ（Vault、クラウドのKMS／Secrets Manager）に保管し、実行時に読み込む
- リポジトリに入れない —
.gitignoreで秘密ファイルを除外し、シークレットスキャンで混入を自動検知する - フロントに置かない — 秘密が要る処理はサーバ側に寄せ、ブラウザには渡さない
- 最小権限 — 1つの鍵は必要な範囲だけに使わせ、用途ごとに分ける
- ローテーション — 定期的に、また漏れたら即、鍵を新しくする
⚠️ 気をつける
- リポジトリへの混入 — 一度でも公開されたら「漏れた」扱い。無効化＆差し替える
- ログに秘密を出す — エラーログにトークンを出さない
- 共有しすぎ — 1つの鍵を広く使い回すと、漏れたときの被害が大きい
この部分をもっと深く（中級）
- リポジトリへの混入 — 一度でも公開されたら「漏れた」扱い。履歴を消すより先に無効化＆差し替え
- ビルドでフロントに露出 — 埋め込んだ鍵はブラウザから読める。サーバ側に寄せる
- ログに秘密を出す — エラーログやアクセスログにトークンを出さない
- 共有しすぎ・放置 — 1つの鍵を広く使い回すと被害が拡大。ローテーションされない鍵も危険
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 秘密の鍵がうっかり公開リポジトリに入ってしまったとき、最初にやるべきは？
問2. APIキーやDBパスワードの置き場所として安全なのは？
問3. コードに秘密（APIキーやパスワード）を直書きすると危険な主な理由は？
問4. フロント（ブラウザに配るコード）に鍵を置いてはいけない理由は？
問5. 1つの鍵を広くあちこちで使い回すと 何が問題になりやすい？
問6. エラーログと秘密の扱いで正しいのはどれ？
問7. 定期的に また漏れたら即 鍵を新しいものに取り替えることを カタカナで何と呼ぶ？
問8. 秘密ファイルをリポジトリに含めないよう 除外設定を書くファイルの名前は？