週末前の深夜、僕はいつも通りの開発作業に没頭していた。自動投稿システムの最終調整や、複数のプロジェクトの基盤整備に追われ、正直なところ集中力は限界に近かったと思う。そんなある時、ふと、胸騒ぎがしたんだ。

自分のプロジェクトのリポジトリを眺めていて、あるファイル名が目に飛び込んできた。

「……あれ？」

それは、GCP（Google Cloud Platform）のサービスアカウントキーファイルだった。しかも、Gitのログを遡ると、かなり前の初回コミットからずっと追跡されているではないか。

背筋が凍った。

「うわ、終わった」

心臓がドクドクと鳴り響き、冷や汗が止まらない。これは、単なるミスじゃない。セキュリティインシデントだ。もし、この公開リポジトリが何かの拍子にオープンになっていたら……と想像するだけで、頭の中が真っ白になった。

🚨 冷や汗が止まらない…Git履歴に機密情報をコミットした僕の悪夢

事の発端は、数週間前に遡る。新しいプロジェクトを立ち上げる際、急いで環境を構築しようとして、GCPのサービスアカウントキーをローカルにダウンロードし、そのままGitリポジトリにコミットしてしまったのだ。当時は .gitignore の設定が不完全で、特定の機密ファイルパターンを除外できていなかった。

そして今日、複数のプロジェクトの基盤整備の一環として、Gitの運用状況をレビューしている最中に、その恐ろしい事実に気づいた。プロジェクトの歴史を辿る git log コマンドを叩くたびに、過去のコミット履歴の中に、しっかりと「サービスアカウントキーファイル追加」という情報が刻まれている。

これは、僕が開発者として犯した中でも、最も重大なセキュリティ上の過ちの一つだ。このキーファイルが外部に漏洩すれば、GCP上のリソースが乗っ取られる可能性だってある。個人情報を扱っていなかったとはいえ、それでも精神的なダメージは計り知れない。

🧪 悪夢からの脱出：全履歴削除と緊急修復オペレーション

発覚した瞬間は混乱したが、すぐに冷静さを取り戻し、緊急対応に取り掛かった。何が何でも、この機密情報をGitの履歴から完全に抹消しなければならない。

Gitの履歴操作は非常に強力だが、同時に危険も伴う。特に git filter-branch のようなコマンドは、使い方を誤るとリポジトリを破壊しかねない。しかし、今回は背に腹は代えられない。漏洩の痕跡を完全に消し去るためには、このコマンドが最も確実な手段だった。

頭の中で手順を整理し、まずは現在のリポジトリのバックアップを取ることから始めた。そして、深く息を吸い込み、修復オペレーションを開始した。

🗓️ 23:00〜23:30 開発ログ：GCP秘密鍵漏洩発覚から緊急対応まで

この日の深夜、時計の針が23時を回った頃から、僕の緊急対応が始まった。

• 23:00 発覚と冷や汗:

開発環境のGitリポジトリをレビュー中に、過去のコミット履歴にGCPのサービスアカウントキーファイル名が含まれていることを発見。「おいおい嘘だろ…」と、思わず声が出た。全身から冷や汗が吹き出し、心拍数が急上昇する。このままではヤバい、と直感。

• 23:10 状況確認と絶望:

git log --name-status で過去のコミットを詳細に確認。初回コミットから現在まで、そのファイルがずっと追跡対象になっていたことが判明し、絶望感が押し寄せる。幸い、公開リポジトリではなかったが、それでも気分は最悪だ。

• 23:15 git filter-branch の調査と計画:

Gitの履歴から特定のファイルを完全に削除する方法を検索。git filter-branch --tree-filter 'rm -f path/to/file' が最も有効な手段だと判断。コマンドのオプションや影響範囲を慎重に確認し、念のためテストリポジトリで試すことを検討したが、時間的切迫感から本番リポジトリでの直接実行を決意（これは良い子の皆は真似しないように…）。

• 23:20 緊急オペレーション実行:

バックアップをローカルに確保したことを確認し、震える手で git filter-branch コマンドを実行。コマンドが走り出すと、過去の全てのコミットが書き換えられていく様子がターミナルに表示され、異常な緊張感が走る。

「頼む、成功してくれ…」

• 23:25 blob残存確認とクリーンアップ:

コマンド完了後、git verify-pack -v .git/objects/pack/*.idx | grep filename などで、削除したファイルの「blobオブジェクト」がGitのリポジトリ内に残存していないかを念入りに確認。残存していないことを確認し、さらに git reflog expire --expire=now --all と git gc --prune=now で参照ログと孤立したオブジェクトを完全に削除した。これでGit履歴からは抹消されたはずだ。

• 23:30 .gitignore の設定修正:

将来的に同じミスを繰り返さないため、既存の .gitignore を見直し、サービスアカウントキーファイル名（*service_account*.json）を確実に除外するパターンを追加した。既存の設定ではハイフン付きのファイル名しか考慮されていなかったため、今回のケースでは機能していなかったのだ。

✅ 秘密鍵は完全消去！Git履歴クリーンアップと認証テスト成功の安堵

git filter-branch による履歴の書き換え、そしてblobオブジェクトの完全な削除が成功したことを確認し、ひとまず安堵の息を漏らした。だが、これで終わりではない。実際にGCPとの認証が正常に行えるかを確認する必要があった。

まずは、ローカルから削除してしまったサービスアカウントキーファイルを、バックアップから元のプロジェクトパスに復元。そして、GCPとの接続を試みるテストスクリプトを実行した。

結果は… 成功！

「やった…」

認証テストが成功し、GCPリソースへのアクセスが可能になったのを確認したとき、全身の力が抜けるような感覚に襲われた。一時はどうなることかと思ったが、なんとか緊急対応を乗り切ることができた。

💡 後悔先に立たず：『人間の宿題』として残された鍵ローテーションの重要性

Git履歴からファイルを削除できたとはいえ、漏洩したGCPサービスアカウントキーファイルそのものが無効になったわけではない。つまり、もしこのファイルがどこかにコピーされてしまっていたら、未だに悪用されるリスクは残っているということだ。

この事実を突きつけられたとき、改めてセキュリティの厳しさを痛感した。根本的な解決のためには、「鍵ローテーション」が必要不可欠となる。これは、漏洩したキーをGCPコンソール上で無効化し、新しいキーを再発行する作業だ。

この作業は、僕が自動化システムでどうこうできるものではなく、GCPのコンソールにアクセスし、手動で対応する必要がある。このときの開発ログにもはっきりと「鍵ローテーション(GCPコンソール)は人間の宿題」と残されていた。この宿題が完了して初めて、本当にこのインシデントは「解決」と言える。

この経験は、認証情報の取り扱いがいかに重要であるかを僕に深く刻み込んだ。一度でも漏洩した可能性のある鍵は、問答無用で無効化し、作り直す。これこそが、セキュリティの絶対的な原則だ。

🔑 あなたのリポジトリは安全？今日からできるセキュリティ対策と次の一歩

今回のGCPサービスアカウントキー漏洩という大失敗を通して、僕が学んだことは計り知れない。もしあなたが、過去に僕と同じようなヒヤリ体験をしたことがあるなら、あるいは「いつか自分もやってしまいそう…」と漠然とした不安を抱えているなら、ぜひ以下の対策を今日から始めてみてほしい。

今回の僕のやらかしは、幸いにも大事には至らなかったが、一歩間違えば深刻な事態を招いていた可能性がある。セキュリティは「いつかやろう」では手遅れになる。

この後、僕はGCPコンソールでの鍵ローテーション作業を完了させた。これにより、完全に安全な状態になったはずだ。しかし、これで終わりじゃない。この経験を活かして、今後はより強固なセキュリティ体制を築いていく。