シークレット管理｜サイバーセキュリティ

🎓 レベル：標準　|　重要度：A（必須） 📎 前提：クラウドの責任共有とIAM

要点（BLUF）

シークレット（API キー・パスワード・暗号鍵・トークン）はコード・設定ファイル・コンテナイメージに直書きしない。これが鉄則。
専用のシークレットマネージャで保管し、実行時に最小権限で取得し、定期的に**ローテーション（更新）**する。
守りの軸は「漏れにくくする＋漏れても短命・最小権限で被害を抑える」の二段構え。

概念：なぜシークレットが危ないか

シークレットは「それさえあれば中に入れる鍵」です。だから一か所に漏れると連鎖的に被害が広がります。特に厄介なのはコードリポジトリへの直書きで、いったんコミット履歴に入ると、後で消しても履歴に残り回収が困難です。OWASP の供給網・設定ミス（OWASP Top 10 の概観）とも深く関わります。

暗号鍵そのものの強度・種類は第2章（公開鍵暗号）の話で、ここは「その鍵をどう安全に保管・配布・更新するか」という運用の話です。

仕組み：シークレットのライフサイクル

段階	やること	防御のポイント
保管	専用マネージャに暗号化保存	平文ファイル・環境変数の直書きを避ける
配布	実行時に最小権限で取得	アプリ起動時に取得、メモリ上で扱う
利用	ログ・例外に出さない	誤って出力しないようマスク
監査	誰がいつアクセスしたか記録	異常アクセスを検知（ログと監視（SIEM/SOC））
ローテーション	定期・漏えい時に差し替え	短命化で漏えいの有効期間を縮める

専用のシークレットマネージャ（クラウド各社のマネージドサービスや Vault 系）を使うと、暗号化保存・アクセス制御・監査・自動ローテーションがまとめて得られます。

flowchart LR
    CODE["アプリコード（シークレットを持たない）"] -->|"実行時に最小権限で要求"| SM["シークレットマネージャ（暗号化保管・監査）"]
    SM -->|"短命の値を返す"| APP["実行中プロセス（メモリ上で利用）"]
    SM -.->|"定期・漏えい時に更新"| ROT["ローテーション"]
    GIT["リポジトリ"] -. "直書き禁止・検出で防ぐ" .-> CODE

防御側の使い方／設定

直書きを禁止し、検出で守る：シークレット検出ツールを CI に入れ（セキュアコーディングとレビュー）、コミット前に弾く。
専用マネージャに集約：暗号化保管・アクセス制御・監査・自動ローテーションを使う。
実行時取得＋最小権限：アプリは起動時にマネージャから取得。取得できる範囲を IAM（クラウドの責任共有とIAM）で最小化。
短命化・ローテーション：長期の固定鍵より短命の動的資格情報。漏えい時は即ローテーション。
ログに出さない：シークレットを例外・ログ・URL に含めない。マスク処理を既定に。
イメージに焼き込まない：コンテナイメージにシークレットを入れない（コンテナとイメージのセキュリティ）。

なぜ安全か：被害の「面積×時間」を縮める

シークレット管理が効くのは、漏えいリスクを面積と時間の両方で縮めるからです。直書きを排し集約することで「漏れる場所」を減らし（面積）、最小権限で「漏れても使える範囲」を絞り（面積）、短命化・ローテーションで「漏れても使える期間」を縮めます（時間）。完全に漏れを防ぐことはできなくても、漏れたときの被害を構造的に小さくできます。

仕組みの直観

シークレット管理は金庫と合鍵の運用です。金庫の番号を壁に貼る（直書き）のは論外。番号は金庫管理室（シークレットマネージャ）が握り、必要なときだけ担当者にその日限りの一時コード（短命資格情報）を渡し、誰がいつ受け取ったか記録します（監査）。番号は定期的に変え（ローテーション）、漏れたら即変更。これで「鍵を一度見られたら永久に終わり」を避けられます。

⚠️ よくある誤解・設定ミス

コード・設定・イメージへの直書き：最頻出。履歴に残り回収困難。検出ツールで防ぐ。
環境変数に平文で長期保管：プロセス情報やログから漏れうる。マネージャ経由＋短命化。
ローテーションしない：一度漏れたら無期限に有効。定期・即時の更新を。
シークレットをログ・例外に出力：意図せず露出。マスクを既定に。
取得権限が広すぎる：全シークレットにアクセスできるアプリは危険。範囲を最小化。

対応 lab

クラウド/マネージャ実環境が前提のため lab は置きません。鍵そのものの原理は第2章 security-study/labs/ を、検出の組み込みはセキュアコーディングとレビューを参照します。