シークレット管理

シークレットとは

シークレットとは、漏れると悪用される秘密の値のことです。データベースの接続パスワード、外部サービスの API キーやアクセストークン、暗号化・署名用の鍵、SSH の秘密鍵などが該当します。これらは「設定値」の一種ですが、表示名やタイムアウト秒数と同じ扱いにしてはいけない点が重要です。通常の設定はリポジトリに置いてよくても、シークレットは置けません。

やってはいけないこと

最もやりがちで、最も被害が大きいのがソースコードへの直書きです。

// NG: リポジトリにキーがそのまま残ってしまう
const apiKey = 'sk-live-abcd1234...';

[[Git]] にコミットすると、あとから削除しても履歴に残り続けます。公開リポジトリなら短時間で自動収集され、クラウド課金の踏み台にされた事例が多数あります。ほかにも、チャットやメールで平文のまま送る、画面共有に映り込ませる、全員で同じ管理者アカウントを共有する(誰が使ったか追えない)、エラーログにトークンを出力する、といった失敗が典型です。

正しい保管場所

本番では専用のシークレットマネージャが基本形です。値は保管時に暗号化され([[暗号化の基礎]])、誰がいつ取得したかの監査ログも残ります。アプリは起動時に取得し、ディスクには書き出しません。

運用の原則

• ローテーション — キーは定期的に入れ替える。担当者の異動・退職時は必ず更新する
• [[最小権限の原則]] — 「全権限のキー1本」ではなく、用途ごとに必要最小限の権限のキーを分ける
• 環境の分離 — 本番と検証で別のキーを使い、検証環境から本番データに触れないようにする
• 漏洩検知と失効手順 — 混入を CI で自動スキャンし、漏れたときに何分で無効化できるかを事前に決めておく

[[IaC]] でインフラをコード管理する場合も同じです。テンプレートに値を直接書かず、シークレットマネージャへの参照だけを書きます。

漏らしてしまったら

隠さず、すぐ動くことが最優先です。まず該当のキーを即座に失効・無効化し(コミットを消すのは後回し)、新しいキーを発行して差し替えます。そのうえで、そのキーで行われた操作のログから被害範囲を調べ、混入経路をふさぎます。「履歴から消したから大丈夫」は誤りで、公開された時点で漏れたものとして扱うのが鉄則です。

初学者向けポイント

• 新しいプロジェクトを作ったら、まず .gitignore に .env を入れる習慣をつけましょう
• フロントエンドのビルドに埋め込んだ値はブラウザから丸見えです。秘密の値をクライアント側に置いてはいけません
• 「一時的だから」で直書きしたコードが、そのまま本番に残るのが典型的な事故パターンです

関連技術とのつながり

• [[暗号化の基礎]] — シークレットの保管時・転送時の暗号化
• [[CI/CD]] — ビルドやデプロイに必要な認証情報を安全に渡す
• [[IaC]] — 構成コードに値を直書きしない
• [[最小権限の原則]] — キーごとに権限を絞り、被害を局所化する
• [[クラウドコンピューティング]] — 各クラウドが提供するシークレット管理サービス

Q: APIキーをソースコードに直書きしてコミットした場合の問題はどれ?
- [x] あとで削除してもGitの履歴に残り続ける
- [ ] ビルド時間が長くなる
- [ ] コードの行数制限を超える
解説: コミットされた値は履歴に残るため、削除しただけでは漏洩は解消しません。

Q: シークレットが漏洩したとき最初に行うべきことはどれ?
- [ ] コミット履歴の書き換え
- [x] 該当キーの即時失効・無効化
- [ ] 関係者への説明資料の作成
解説: 悪用を止めるのが最優先です。まずキーを無効化し、履歴の整理はその後に行います。

Q: 本番環境でのシークレット保管方法として推奨されるのはどれ?
- [ ] リポジトリ内の設定ファイルに平文で置く
- [ ] チャットで共有して各自がコードに貼る
- [x] シークレットマネージャで保管し、アプリが起動時に取得する
解説: 専用サービスなら暗号化保管と監査ログが得られ、ローテーションも運用しやすくなります。