LoginSignup
17
10

More than 3 years have passed since last update.

機密情報が含まれるファイルをGitHubに上げてしまったときの対応

Last updated at Posted at 2020-12-15

機密情報が含まれるファイルを、作業ブランチのローカルリポジトリからリモートリポジトリへpushしてしまいました。
今回はプルリクエストを作成済みで、デフォルトブランチ(masterブランチ)へのmergeをしていないという状況でした。

対応したこと(報連相)

上長に報告

今回起こした事象のうち、どの部分が問題にあたるのかを社内のセキュリティ資料と照らして確認し、問題を収束させるためにはどのような対応が考えられるか(git resetまたはgit filter-branchで、機密情報が含まれたコミットの履歴を削除するor書き換える)をやり取りしました。

社内のCSIRTチームへ連絡を入れて対応を確認

弊社にはCSIRTチームが存在するため、CSIRTチームへ連絡をし、取るべき対応を仰ぎました。

Enterprise supportのOpen a support ticketから問い合わせするのが吉だと教えていただきGitHubのサポートの方と連絡を取りました。

GitHubのサポートへ相談

  • 上げてしまった機密情報のコミット履歴を削除する
  • GitHub上に残っているキャッシュを削除して、git logからも遡れないよう完全に削除する

これが今回満たしたい要件だったので先方にお伝えしました。

対応したこと(Git操作)

GitHubのサポートの方から、「機密情報がプルリクエストに関連付けられたブランチにのみ存在し、mergeされていない場合は、このブランチに強制的にpushできます。」との回答が得られました。

なので、git resetでコミット履歴を削除し、強制pushする対応を取ります。

Gitコマンド実行

1.$ git branch #現在のブランチを確認する
2.$ git reset --soft <commit> #機密情報が入ったコミットの1つ手前のコミットハッシュを指定
3.$ git add <file> #削除したいファイルを除くファイルをステージング
4.$ git commit -m <message>
5.$ git push --force-with-lease origin <branch> #強制Push

これで上げてしまった機密情報のコミット履歴を削除するという要件を満たせます。

確認

該当のコミットハッシュのページがGitHub上で見れなくなっていることが確認できます。
image.png

プルリクエストのコミット履歴からもちゃんと削除されていました。

キャッシュの削除

今回はGitHubのサポート側でガーベージコレクションのプロセスを実行してキャッシュを削除してくれるとのことなので、実行してもらいました。
これによりgit logからも遡れなくなりました。

確認

git log | grep <commit> #機密情報が入ったコミットのコミットハッシュを指定

git logから遡れなくなっていることが確認できました。

念のため、普段作業しているディレクトリとは異なる階層に今回対応しているリポジトリをcloneし、同様にgrepすることで、自分以外のコントリビューターからも参照されることがないかの確認も行いました。

git reflogはローカルリポジトリでのHEADやブランチ先端の動きを記録するものです。
一方、git logは現在のHEADから各コミットの親を再帰的に調べて、リモートリポジトリを遡ります。
git logのコミット履歴が消えているということは他者から参照されなくなるということです。

これでGitHub上に残っているキャッシュを削除して、git logからも遡れないよう完全に削除するという要件も満たせました。

※注意

git resetやgit filter-branchをしただけで対応完了だと勘違いする人もいますが、GitHubに問い合わせてGitHub側のキャッシュなどを削除してもらう必要があるので、忘れずに対応してください。

再発防止策

今回は、マスク化されていない機密情報を含むテーブルをdumpし、GitHubのリモートリポジトリに上げたことで問題を起こしてしまいました。機密情報にあたるカラムを意識せずデータを扱っていたことを反省しています。

弊社では有難いことに機密情報をマスク化したVIEWが用意されているので、これからは些細な作業でも必ずVIEWからデータを取得するように心に誓います。
SQL Serverにおけるデータベースの秘密情報取扱いルールの実装について

そして、マスク済みVIEWからデータを取得するという個人の意識ベースでの再発防止策だけではなく、仕組み化による再発防止策も対応予定です。マスク済みVIEWしか閲覧権限がないDBユーザーを作成し、開発時はそのユーザーでDBにアクセスする運用を検討中です。

デフォルトブランチにmergeしてしまった場合は

デフォルトブランチにmergeされた状況だと今回とは対応がガラリと変わります。
詳細はGitHubの公式記事に預けますが、git filter-branch(またはgit filter-repo)やBFG Repo-Cleanerを使用し、リポジトリの履歴を書き換える必要があります。

実行にはリスクが伴うので、細心の注意を払いましょう。
実行する前にGitHubのサポートに状況を伝えて、必要な対応を確認することを強く推奨します。

まとめ

  • 今回はプルリクエストを作成済みで、デフォルトブランチへのmergeをしていないという状況の対応記事です。
  • デフォルトブランチにmergeされた状況だと対応が異なるので、GitHubのサポートにその旨を伝えて必要な対応を確認してください。
  • git resetやgit filter-branchをしただけでは対応完了ではありません。GitHubに問い合わせてGitHub側のキャッシュなどを削除してもらう必要があるので、忘れずに対応してください。
17
10
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
17
10