設定値と秘密情報の置き場所

設定値と秘密情報を分ける

接続先URLや機能フラグなど秘密でない設定値と、パスワード・APIキー・秘密鍵のような認証情報は扱いを分けます。コードに埋め込んだり、実値入りの設定ファイルを共有リポジトリへ保存したりしないでください。形式を選ぶ場合は、まずアプリが受け入れる方式を確認します。

ローカル開発では.envを保管庫にしない

対応ツールなら、開発者ごとの値をローカルの.envに置き、共有する.env.exampleには変数名や説明だけを記載します。実際の.envは.gitignoreへ追加し、すでにGitが追跡していないことも確認します。除外ルールは安全な保管機能ではなく、追跡済みの値を履歴から消すものでもありません。

CIではSecret機能と最小権限を使う

GitHub ActionsなどのCIでは、認証情報をワークフロー本文に書かず、提供元のSecret機能へ登録します。必要なリポジトリ・環境・ジョブだけにアクセスを絞り、トークン権限を最小限にし、値をログへ出さないようにします。自動マスキングだけに頼らず、変換した値やコマンドの出力にも注意してください。

本番やコンテナでは実行基盤から渡す

本番ではホスティング先やクラウドのSecret保管機能を優先し、デプロイ対象と参照権限を限定します。Docker ComposeではSecretをファイルとしてコンテナへマウントし、明示的に許可したサービスだけが読める仕組みがあります。機能や制約は基盤ごとに異なるため、実際の配備環境の仕様を確認してください。対応している場合は、長期間有効な鍵を置き続ける代わりにOIDCなどの短期認証も検討します。

漏えい時は削除より先に失効・更新する

秘密値がコミット、CIログ、チャットなどへ出た可能性がある場合、公開先から消すだけでは不十分です。まず該当キーやトークンを失効・ローテーションし、アクセスログや利用範囲を調べます。その後、リポジトリ履歴やログの扱い、再発防止の除外・権限設定を見直します。

候補形式

注意点

• .envと.gitignoreだけで機密情報の安全性は保証されません。Git追跡状態、CIログ、バックアップ、実行基盤の保管先も確認してください。
• Secretのマスキングはあらゆる変換値や出力を必ず隠すとは限りません。
• 漏えいが疑われる認証情報は、ファイル削除だけでなく失効・更新してください。

関連Guide