秘密情報をGitに入れない仕組み｜.gitignore・git-secrets・履歴から漏れた鍵の削除

「.envをうっかりコミットしてpushしてしまった」「公開リポジトリにAWSのアクセスキーが含まれていると通知が来た」「削除コミットを積んだのに、履歴を辿れば今でも鍵が見える」。秘密情報のGitへの混入は、注意深い開発者でも一度は経験する事故で、しかも"気をつける"だけでは再発します。

この記事では、秘密情報がコミットされる典型的な経路を整理したうえで、.gitignoreと.env.exampleの運用、pre-commitフックでのgitleaks／git-secretsによる自動検知、GitHubのsecret scanning、そして漏れてしまった場合に「鍵の無効化が先、履歴の書き換えは後」である理由とgit filter-repoの手順を解説します。どこに秘密情報を保管すべきかという話はシークレット管理入門に譲り、ここでは「Gitに入れない・入っても検知する・入ったら消す」に集中します。

秘密情報がコミットされる典型経路

.envだけが問題ではない

混入経路として最も多いのは.envファイルですが、それ以外にも見落とされやすい場所があります。

• 設定ファイル：config/database.yml、appsettings.json、application.propertiesなどに直接パスワードを書き、そのままコミットする
• ログ・ダンプ・デバッグ出力：リクエストヘッダーごと出力したログファイルやDBダンプに、トークンやCookieが含まれる
• IaCの状態ファイル：terraform.tfstateにはRDSのパスワードなどが平文で入る
• ノートブック・スクリプトの実験コード：検証用に直書きしたAPIキーをそのまま残す
• git add . と git commit -a：意図しないファイルをまとめて含めてしまう
• プライベートリポジトリの油断：「非公開だから大丈夫」と入れた鍵が、のちに公開化・フォーク・移管で露出する

いずれも「人が毎回気をつける」以外の防御がない状態で起きています。対策は、混入を物理的に起きにくくする層と、起きても検知する層の二段構えで考えます。

.gitignoreと.env.exampleの運用

最初のコミットより前に.gitignoreを整える

.gitignoreは「追跡していないファイル」を無視するだけで、すでに追跡済みのファイルには効きません。.envをコミットしたあとに.gitignoreへ追加しても、変更は追跡され続けます。リポジトリ作成時点で用意するのが原則で、後から追加した場合は git rm --cached でインデックスから外す必要があります。

# .gitignore（秘密情報関連の最低限）
.env
.env.*
!.env.example
*.pem
*.key
*.p12
*.pfx
credentials.json
service-account*.json
terraform.tfstate
terraform.tfstate.backup
.terraform/
*.log
dump.sql

# すでに追跡してしまった.envをインデックスから外す（ファイル自体は残る）
git rm --cached .env
git commit -m "chore: stop tracking .env"

ここで注意すべきは、この操作は「これ以降のコミット」から外すだけで、過去の履歴には.envの中身が残っていることです。過去分の扱いは後半で説明します。

.env.exampleで「必要な変数」だけを共有する

チームで必要な環境変数を共有するために、値を空にした.env.exampleをコミットします。新メンバーはこれをコピーして自分の値を入れます。値の欄には「どこで取得するか」をコメントで残しておくと、Slackで鍵を送り合う行動も減ります。

# .env.example（コミットする。実際の値は書かない）
DATABASE_URL=postgres://user:password@localhost:5432/app_dev
STRIPE_SECRET_KEY=            # 1Passwordの「開発用Stripe」から取得
AWS_ACCESS_KEY_ID=            # IAM Identity Centerで一時クレデンシャルを発行
SESSION_SECRET=               # openssl rand -hex 32 で各自生成

pre-commitフックで自動検知する

gitleaksをコミット前に走らせる

gitleaksは、コミット内容や履歴全体を正規表現とエントロピー（文字列のランダムさ）で走査し、AWSキー・GitHubトークン・秘密鍵などのパターンを検知するツールです。pre-commitフレームワークと組み合わせると、コミットの瞬間に自動で止められます。

# インストール
brew install gitleaks pre-commit

# .pre-commit-config.yaml（リポジトリ直下にコミットする）
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks

# 各開発者が一度だけ実行してフックを有効化
pre-commit install

# 既存の履歴全体をスキャンする（導入時に一度実施）
gitleaks git --redact -v

フックはリポジトリをcloneしただけでは有効にならず、各開発者がpre-commit installを実行する必要があります。そのためCIでも同じスキャンを走らせて、フックを入れ忘れた人のコミットも止めるのが定石です。GitHub Actionsならgitleaks公式のアクションをプルリクエストのワークフローに1ステップ追加するだけです。git-secrets（AWS製）も同様の目的のツールですが、AWSキーのパターンが中心で、近年はgitleaksの方が検知パターンの網羅性とメンテナンス頻度で選ばれることが多いです。

誤検知への向き合い方

テスト用のダミートークンやサンプルの公開鍵で検知されることがあります。その場合は.gitleaksignoreに検知結果のフィンガープリントを追記するか、対象行に gitleaks:allow コメントを付けて除外します。「面倒だからフックを無効化する」のが最も危険で、除外は必ず理由が残る形で行ってください。

GitHub secret scanningとpush protection

GitHubは、リポジトリにpushされた内容から既知のプロバイダー（AWS・Stripe・Slack・OpenAIなど）のトークン形式を検知するsecret scanningを提供しています。公開リポジトリでは自動で有効になり、検知するとプロバイダー側に通知されて鍵が自動失効することもあります。さらにpush protectionを有効にすると、検知した時点でpush自体が拒否されます。プライベートリポジトリでも、リポジトリのSettings → Code security から有効化できます（プランにより利用範囲が異なります）。

ただし、これはGitHubが知っているパターンに限られます。自社の内部APIの独自トークンや、DBの平文パスワードは検知できないため、ローカルのgitleaksとCIスキャンとの併用が前提です。

漏れてしまったときの対応｜無効化が先、履歴書き換えは後

なぜ履歴の削除より鍵の失効を優先するのか

公開リポジトリにpushされた鍵は、数分以内にクローラーに収集されると考えてください。GitHubのイベントを監視するボットが多数存在し、削除コミットを積んでもforceでpushし直しても、すでに取得された鍵は戻りません。また、フォーク・ローカルクローン・CIのキャッシュ・プルリクエストの参照など、履歴を書き換えても残る場所が複数あります。したがって対応の順番は次のとおりです。

1. 鍵を即座に無効化・ローテーションする（AWSならIAMでアクセスキーを削除、Stripeならロールして再発行）。これが済むまで他の作業をしない。
2. その鍵で不正利用されていないかを確認する（CloudTrail・請求・監査ログ）。
3. 新しい鍵をシークレットマネージャー経由で配布し直し、アプリを更新する。
4. そのうえで履歴から削除し、関係者にクローンし直しを依頼する。

git filter-repoで履歴から完全に消す

git filter-branchは公式に非推奨で、後継のgit filter-repoを使います。特定ファイルを全履歴から削除する場合と、ファイル内の特定文字列だけを置換する場合の2通りがあります。

# インストール
brew install git-filter-repo

# 作業用に新しくクローンして実施する（filter-repoは安全のためfreshなcloneを要求する）
git clone --mirror git@github.com:example-org/app.git app-cleanup
cd app-cleanup

# 方法1: ファイルを全履歴から削除
git filter-repo --invert-paths --path .env --path config/secrets.yml

# 方法2: 文字列だけを置換（replacements.txt に1行1パターン）
#   AKIAIOSFODNN7EXAMPLE==>REDACTED_AWS_KEY
git filter-repo --replace-text replacements.txt

# 書き換えた履歴を強制push（保護ブランチは一時的に解除が必要）
git push --force --all
git push --force --tags

force push後は、全メンバーがローカルを捨てて再クローンする必要があります。古いローカルからpushすると、消したはずのコミットが復活します。GitHub上ではプルリクエストや到達不能なコミットにキャッシュが残る場合があるため、公開リポジトリで完全に消したい場合はGitHubサポートへの削除依頼も必要です。履歴の書き換えは通常のマージやリベースとは影響範囲が異なるため、rebaseとmergeの違いを理解したうえで、チーム全体に周知して実施してください。

トラブル事例：削除したはずの鍵で不正利用が続いた

症状：公開リポジトリにAWSアクセスキーを含む.envを誤ってpush。気づいてすぐ削除コミットをpushしたが、翌日AWSから高額な利用通知が届いた。
原因：削除コミットは履歴の先頭を変えるだけで、過去のコミットには鍵が残っていた。またpush後数分で自動収集されており、履歴を消しても意味がなかった。鍵自体を無効化していなかったため、EC2の大量起動に使われ続けた。
対処：IAMでアクセスキーを削除し、起動されたリソースをすべて停止。CloudTrailで操作範囲を確認し、AWSサポートに事象を報告した。その後git filter-repoで履歴を書き換え、gitleaksのpre-commitとCIスキャン、GitHubのpush protectionを有効化。長期的なアクセスキーの利用自体をやめ、IAMロールと一時クレデンシャルに移行した。「削除コミット」が対策にならないことをチーム全員が学ぶ契機になった事例です。

まとめ

秘密情報の混入は、.gitignoreと.env.exampleで起きにくくし、gitleaksのpre-commitフックとCIスキャン、GitHubのpush protectionで起きても止める、という多層で防ぎます。それでも漏れたときは、履歴の書き換えより先に鍵を無効化し、不正利用の有無を確認してから、git filter-repoで履歴を消して全員に再クローンを依頼します。この手順を「事故が起きてから調べる」のではなく、平時に一度リハーサルしておくことが最も効果的な備えです。開発フローにセキュリティチェックを組み込みたい場合は、Harmonic Societyのシステム開発・インフラ支援にご相談ください。