Edited at

間違えてGitHubなどにSECRET_KEYをpushしてしまった時の対処法(個人のみ)

備忘録です

2019/03/09 15:00 - @tetsukay さん @shibukk さんのコメントを反映しました


やらかした!!

GitHubなどで、TwitterのpasswordやAWSなどのSECRET_KEYが含まれたプロジェクトを管理する際、.gitignoreをちゃんと指定してやらないとgitのcommit履歴などにそのSECRET_KEYなどの値が残ってしまいます。

こういったミスでSECRET_KEYなどが流出するとセキュリティインシデントに繋がりますね。

この記事では一番最悪な「SECRET_KEYなどがcommitされた履歴がpushされてしまった」という事態の対策として、「git上での履歴の削除方法」と「リモートリポジトリ上の履歴の削除方法」を解説します。


パスワードの変更

まずはパスワード/SECRET_KEYを今すぐ変更しましょう。

対応が遅れてしまうと、たったの13分で不正利用されてしまうそうです。

パスワードさえ変えてしまえば、ひとまずアクセスされることはありません。


gitでの履歴の削除(上書き)

一番シンプルな方法は次の通りです。



  1. git logを用いてどのcommitからSECRET_KEYがバージョン管理されたかを調べる

  2. n個前のcommitと判明したらgit reset --soft HEAD^*nを実行する(^がn個)


  3. git ls-tree <branch名>としignoreしたいファイルがtrackingされてるか確認

  4. もし3でtrackingされている場合git rm --cached <ファイル名>でtrackingから外す


  5. .gitignoreにちゃんとSECRET_KEYの含まれるファイルを記述する

  6. 改めてcommit

簡単に言えば、SECRET_KEYがないところまでcommitをなかった事にし、改めてignoreした後commitし直す、という事です。

git reset --softでファイルの変化はそのままcommit履歴だけなくすことができるのがミソになっています。

ちなみにgit reset --soft HEAD^*nの代わりにgit reset --soft HEAD~nでもできるようです。

# 以下は同じ

$ git reset --soft HEAD^^^^^
$ git reset --soft HEAD~5

もし複数のbranchでSECRET_KEYが入ったファイルがtrackingされている場合は各branchごとに行えば良いです。

commit履歴を綺麗にしたい場合は、6の時点でcommitをファイルごとに分割しながらやれば良いかと思います。


リモートリポジトリでの履歴の削除(上書き)

こちらは簡単です。

上述したようにgitでの履歴削除を行った後、pushする際にforce pushを行えば、gitでの履歴変更でGitHub上のものも上書きされます。

git push -f --allとしましょう。

もし複数のbranchでpushされている場合は、現状の進捗だけ別のbranchにmergeしておき、GitHub場で該当branch以外を削除すれば良いです。(少なくともGitHubでは)削除されたbranchは参照できなくなるようなのでこれで最低限の問題は解決するでしょう

チーム運用?ごめんなさいわからないです...。


再発防止

もう大丈夫と思っても人はミスはしてしまいます。

なので、git-secretsを設定しておくと再発を防止できます。


終わりに

force pushはご法度という雰囲気が界隈にはありますが、適材適所だと思っています。

チーム開発でgit運営は経験が0なのでごめんなさいって感じです。

個人開発レベルならこれで良いかと思います。

そもそもこんな単純なミスしなければ良いというだけの話ですね、よく気をつけましょう。