設定ファイル内のシークレット

config.yaml、application.yml、.env、settings.json などの設定ファイルに保存したシークレットは、ソースコード内の値と同様に漏えいするおそれがあります。設定ファイルは「コードではないので問題ない」という誤解から、リポジトリにコミットされることがあります。

このガイドが役立つ場合

  • config.yaml、application.yml、.env にパスワードやトークンが含まれている場合
  • config.yaml.example と実際の config.yaml が両方コミットされている場合
  • 設定ファイルに本番DBのパスワード、APIキー、OAuthシークレットを直接保存している場合

対処の原則

  • Gitで管理する設定ファイルには、シークレットの実際の値を保存しないでください。
  • リポジトリにはサンプルだけを置き、実際の値を含むファイルはコミットしないでください。
  • アプリケーションが環境変数または実行時に供給する設定ファイルからシークレットを読み取るようにしてください。

詳細ガイドの選び方

最低限必要な対応

  • リポジトリの設定ファイルで露出したシークレットを失効し、再発行してください。
  • 実際の本番設定ファイルをGitに含めないでください。
  • サンプルファイルと実ファイルの役割を明確に分けてください。
  • ログ、エラーメッセージ、デバッグ出力にシークレットが出ないようにしてください。

開発者が行うこと

  • 設定ファイルから実際のシークレットを削除してください。
  • サンプルファイルには構造だけを残し、実際の値を削除してください。
  • アプリケーションが環境変数または実行時に供給される設定ファイルを読むように変更してください。
  • 設定のダンプ、エラーログ、デバッグ出力にシークレットの値が含まれていないか確認してください。

インフラ・プラットフォーム担当者が行うこと

  • 実際の設定ファイルは、Gitではなく安全なデプロイ経路で供給してください。
  • .gitignore とデプロイパイプラインで、実ファイルが再びリポジトリに入ることを防いでください。
  • Kubernetes、シークレット管理サービス、安全なファイル配信から、運用標準に合う方法を選んでください。
  • シークレットのローテーションと再デプロイまたは再読み込みの手順を定めてください。

確認方法

  • リポジトリに本番設定ファイルがないことを確認してください。
  • サンプルファイルに本番のシークレットがコピーされていないことを確認してください。
  • ログやエラー応答にシークレットの値が出ていないことを確認してください。
  • デプロイ後、アプリケーションが意図した方法でシークレットを読み取ることを確認してください。

よくある間違い

  • config.yaml.example に本番の値をそのままコピーする
  • .gitignore に追加しただけで、コミット済みのファイルを残す
  • ConfigMapやDockerイメージに入れれば設定ファイルが保護されると考える
  • デバッグログに設定オブジェクト全体を出力する

担当者の対処手順

露出した認証情報は、以下のファイル整理やデプロイ変更を待たず、まず失効または無効化して新しい値に置き換えてください。

  1. 設定ファイルからシークレットの実際の値を削除してください。
  2. 実際の値を含むファイルがリポジトリに登録されていた場合は、Git履歴の整理が必要か判断してください。
  3. 露出したシークレットを失効し、新しい値を発行してください。
  4. 実際の設定ファイルを .gitignore に追加してください。
  5. 設定方法に合う詳細ガイドを参照し、修正パターンを適用してください。

担当者への案内例

  • 「設定ファイルから実際のシークレットを削除し、本番の実ファイルをGitから除外してください。」
  • 「環境変数に変更できない場合は設定形式を維持し、実ファイルを実行時に安全に供給してください。」
  • 「config.yaml.example には構造だけを残し、実際の config.yaml はコミット対象から除外してください。」

追加の確認事項

  • .env ファイルはすでにコミットされていないか。
  • サンプルファイルに本番の値がコピーされていないか。
  • ログやエラーメッセージに設定値が出力されていないか。

関連文書