初級では「秘密はコードの外に隔離し、参照だけする」を土台としました。中級では、どこにどう隔離し、運用でどう守り続けるかを整理します。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
なぜ気をつける？
秘密（APIキー・DBパスワード・署名鍵）が漏れると、DBの中身を抜かれたり、外部サービスを勝手に使われて課金されたり——被害が直接的です。中級で押さえたいのは、秘密は「置き場所」だけでなく「経路」でも漏れるという視点です。
- コードに直書き — リポジトリの履歴に残り、公開・共有で流出
- フロントへの埋め込み — ブラウザに配るコードは全部読まれる前提
- ログ・エラー出力 — トークンをそのまま出すと保存先から漏れる
- CI/CDの設定 — ビルドログや設定ファイルに平文で残る
アニメーション『秘密情報の扱い（隔離）』を開く
この部分をもっと深く（上級）
中級では「秘密は置き場所だけでなく経路でも漏れる」と押さえました。上級では、もっとも手軽な環境変数すら「隔離」としては弱いことを直視します。
- プロセスから覗ける — 環境変数はプロセス一覧やメモリダンプ、
/proc経由で読まれうる。同じホストの別プロセスや、クラッシュダンプにそのまま載る - 子プロセスへ継承される — 起動した外部コマンドに丸ごと引き継がれ、意図せぬ範囲へ広がる
- イメージや設定に焼き付く — コンテナイメージやCIの設定へ平文で埋め込まれやすい
つまり環境変数は「コードから分離する最低ライン」であって、上限ではありません。上級の目標は、実行時にだけ・必要な範囲にだけ・短命に秘密を渡すことです。
やさしく言うと（初級）
秘密の鍵が漏れると、DBの中身を抜かれたり、外部サービスを勝手に使われて課金されたり——被害が直接的です。特に、コードに直書きしたり、フロント（ブラウザ）に置くのは危険。リポジトリやブラウザから簡単に読まれます。
アニメーション『秘密情報の扱い（隔離）』を開く
どう扱う？
- コードの外に置く — 環境変数や専用のシークレットマネージャ（Vault、クラウドのKMS／Secrets Manager）に保管し、実行時に読み込む
- リポジトリに入れない —
.gitignoreで秘密ファイルを除外し、シークレットスキャンで混入を自動検知する - フロントに置かない — 秘密が要る処理はサーバ側に寄せ、ブラウザには渡さない
- 最小権限 — 1つの鍵は必要な範囲だけに使わせ、用途ごとに分ける
- ローテーション — 定期的に、また漏れたら即、鍵を新しくする
やさしく言うと（初級）
- コードの外に置く — 環境変数や、専用のシークレット管理（シークレットマネージャ）に保管し、コードからは参照だけする
- リポジトリに入れない —
.gitignoreで秘密ファイルを除外。うっかり混入を防ぐ仕組みも入れる - フロントに置かない — ブラウザに配るコードは全部読まれる前提
- ローテーション — 定期的に、また漏れたら即、鍵を新しくする
隔離の選択肢
置き場所は用途と規模で選びます。
- 環境変数 — 小規模や単一サービスで手軽。ただしプロセスやログから見えやすい点に注意
- シークレットマネージャ（Vault・クラウドのSecrets Manager） — 一元管理・アクセス制御・監査・自動ローテーションを仕組み化できる
- KMS（鍵管理サービス） — 暗号鍵そのものを預け、鍵を取り出さずに暗号化や署名を実行させる
規模が大きくなるほど、誰が・いつ・どの鍵を使ったかを追える管理へ寄せるのが定石です。
この部分をもっと深く（上級）
中級の「隔離の選択肢」を、運用の仕組みとして深掘りします。専用基盤に集約する狙いは、単なる保管ではなく 集中管理・アクセス制御・監査 です。
- 一元管理 — Vault ※1 のような基盤に秘密を集め、誰がどの秘密をいつ読んだかを監査ログに残す
- 実行時取得 — アプリは起動時や実行時にAPIで取得し、ディスクに書かない。設定ファイルに平文を置かない
- リースとTTL — 貸し出しに期限を付け、「借りっぱなし」を防ぐ。失効すれば自動で無効になる
登場人物メモ（※の説明）:
- ※1 Vault — 秘密の保管・払い出し・監査・動的発行を担う専用基盤の代表格。アクセスは細かいポリシーで制御する
⚠️ 破れ方のパターン
- リポジトリへの混入 — 一度でも公開されたら「漏れた」扱い。履歴を消すより先に無効化＆差し替え
- ビルドでフロントに露出 — 埋め込んだ鍵はブラウザから読める。サーバ側に寄せる
- ログに秘密を出す — エラーログやアクセスログにトークンを出さない
- 共有しすぎ・放置 — 1つの鍵を広く使い回すと被害が拡大。ローテーションされない鍵も危険
この部分をもっと深く（上級）
- TTLとライフサイクルの不整合 — 動的シークレットの有効期限より処理が長引き、途中で突然失効する。再取得の実装が要る
- KMS依存が単一障害点 — 復号のたびにKMSへ往復するため、KMSの停止や遅延、コストが効いてくる。適切なキャッシュとフォールバックを設計する
- 監査ログに秘密が漏れる — 秘密を守るはずのログに、値そのものを書いてしまう本末転倒
- デバッグ時のダンプ — 「一度も外に出さない」建前が、障害調査のメモリダンプや詳細ログで一気に崩れる
やさしく言うと（初級）
- リポジトリへの混入 — 一度でも公開されたら「漏れた」扱い。無効化＆差し替える
- ログに秘密を出す — エラーログにトークンを出さない
- 共有しすぎ — 1つの鍵を広く使い回すと、漏れたときの被害が大きい
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. ビルド時にAPIキーをフロントのコードへ埋め込む方式のリスクとして正しいのは？
問2. シークレットマネージャ（VaultやクラウドのKMS）を使う主な利点はどれ？
問3. 中級で押さえたい「秘密は置き場所だけでなく○○でも漏れる」の○○に入るのはどれ？
問4. 秘密がリポジトリへ混入したときの正しい初動はどれ？
問5. 「.gitignore」による除外に加えて 秘密の混入を自動で検知する仕組みはどれ？
問6. KMS（鍵管理サービス）の説明として正しいのはどれ？
問7. リポジトリに秘密ファイルを含めないよう 除外設定を書き込むファイルの名前は？
問8. 暗号鍵そのものを預け 鍵を取り出さずに暗号化や署名を実行させるサービスを英字3文字の略語で？