GitHubにAPIキーをpushした時の対処法｜失効・履歴削除・再発防止

GitHubへAPIキーをpushしてしまったら、最優先はコミットを消すことではなく、そのキーを失効または交換することです。「すぐ非公開にしたから大丈夫」「直後にファイルを削除したから安全」と考えたくなりますが、一度リモートへ送った秘密情報は、すでに取得された可能性があるものとして扱う必要があります。

この記事では、キーを無効化して被害を止める初動から、不正利用の確認、現在のコードの修正、Git履歴を書き換えるかどうかの判断、再発防止までを順番に解説します。焦って履歴操作を始める前に、まずアクセスできる力そのものを止めましょう。

最初にAPIキーを失効または交換する

GitHubは、リポジトリへコミットされた秘密情報を侵害されたものとして扱い、直ちにローテーションするよう案内しています。まずAPIキーを発行したサービスの公式管理画面を開き、漏洩したキーを無効化してください。新しいキーが必要なら、古いキーとは別に発行し、アプリケーションやデプロイ環境を新しい値へ切り替えます。

重要なのは、先に古いキーの効力を止めることです。公開リポジトリだけでなく、限定公開や非公開のリポジトリでも、権限設定の誤り、共同作業者の端末、ログ、連携サービスなどを通じてコピーが残る可能性があります。公開時間が数秒でも「使われていない」とは判断せず、失効を基準に対応します。

GitHubの秘密情報の安全な保管に関する公式ガイドも、露出した秘密情報は直ちに失効し、新しい値を安全に保存するよう勧めています。

新しいキーへ切り替え、利用履歴を確認する

古いキーを止めたら、そのキーを使っていた場所を洗い出します。ローカルの環境変数、ホスティングサービス、CI/CD、定期実行ジョブ、サーバー、共有開発環境などを確認し、新しいキーへ切り替えます。古いキーを必要とする処理が残っていないことを確かめたうえで、失敗したデプロイや停止中のジョブを復旧します。

次に、APIの発行元が提供する利用履歴、監査ログ、請求情報を確認してください。不審なリクエスト、通常と異なる地域や時刻、急な使用量増加、権限変更がないかを調べます。異常が見つかった場合は、キーの権限だけでなく、関連アカウント、データ、支払い設定への影響も確認し、必要に応じてサービス提供元や組織のセキュリティ担当へ連絡します。

GitHubのSecret scanningアラートが出ている場合は、キーの対処が済んでから内容を確認して閉じます。公式のアラート解決手順によると、リポジトリから文字列を削除しただけではアラートは自動的に閉じないため、対応結果を確認して手動で解決状態にします。

現在のコードから秘密情報を取り除く

新しいキーをソースコードへ直接書き戻してはいけません。環境変数、ホスティングサービスのSecret機能、GitHub ActionsのSecrets、組織で承認された秘密情報管理サービスへ保存し、コードからは変数名だけを参照します。共有用の設定例が必要なら、実値を含まない .env.example を用意します。

.env などを .gitignore に追加するだけでは、すでにGitが追跡しているファイルは追跡対象のままです。Git公式のgitignore資料が説明するように、追跡を止めるには実ファイルをローカルに残したまま、インデックスから外します。

git rm --cached path/to/.env

そのうえで .gitignore と、秘密情報を除いたコードをコミットします。ただし、このコミットは現在のブランチからキーを見えなくするだけです。過去のコミットには元の値が残るため、単なるファイル削除や git revert は履歴からの完全削除にはなりません。

Git履歴を書き換えるか判断する

APIキーを失効できたなら、攻撃者が過去の値を見つけても通常は認証に使えません。GitHubの機密データ削除ガイドも、失効または交換でリスクを軽減できる場合は、時間と副作用の大きい履歴書き換えが不要なことがあると説明しています。

一方、失効できない秘密情報、法令や契約上の削除対象、内部ポリシーで完全削除が必要な情報、キー以外の機密データまで含まれていた場合は、履歴削除を検討します。組織のリポジトリでは、個人の判断でforce pushを始めず、管理者やセキュリティ担当と範囲を確認してください。

履歴を書き換えると、対象コミット以降のコミットIDが変わり、コミットやタグの署名、オープン中または過去のプルリクエスト、ブランチ保護、外部ツールの参照に影響します。共同作業者の古いcloneから汚染された履歴が再pushされる危険もあるため、作業時間を決め、pushを一時停止してから実施します。

git-filter-repoで履歴を整理する

履歴削除が必要な場合、GitHubは最新の git-filter-repo と --sensitive-data-removal オプションを使う手順を案内しています。ローカル固有の変更を失わないよう、普段の作業ディレクトリではなく、新しくcloneした専用コピーで作業します。

機密情報だけが入ったファイルをすべての履歴から除く場合は、実際のリポジトリ内パスを指定します。

git filter-repo --sensitive-data-removal --invert-paths --path path/to/file

通常のソースファイルにキーが混在している場合は、削除対象文字列をリポジトリ外の置換ファイルへ記録し、--replace-text を使う方法があります。キーそのものをシェル履歴、Issue、チャットへ貼り付けないよう注意してください。

git filter-repo --sensitive-data-removal --replace-text ../passwords.txt

処理後は、対象の全パス、移動前のファイル名、ブランチ、タグに秘密情報が残っていないことと、必要なコードが失われていないことを確認します。その後に限り、管理者と調整してGitHub上の履歴をforce pushで更新します。具体的なpush方法や一時的なブランチ保護変更は、対象リポジトリの運用方針とGitHub公式手順に従ってください。

clone・fork・プルリクエストの残存参照に対応する

中央リポジトリを書き換えても、共同作業者のclone、fork、プルリクエストが参照するcommit、GitHubのキャッシュ表示に古いデータが残ることがあります。共同作業者には通常のmergeや git pull で古い履歴を戻さないよう伝え、可能なら新しくcloneし直してもらいます。

forkに対象commitが残っている場合は、その所有者との調整が必要です。プルリクエスト参照やキャッシュの削除が必要で、キーの失効だけではリスクを緩和できないケースでは、GitHub Supportへ対象リポジトリ、影響するプルリクエスト、git-filter-repo が報告した最初の変更commitなどを伝えます。GitHubは、失効で対処できる秘密情報や機密性のないデータについて、必ずサーバー側の削除を行うとは案内していません。

履歴書き換えは「force pushが成功したら終了」ではありません。共同作業者が新しい履歴へ移行し、古いキーが無効であり、再混入する参照がないことまで確認して完了です。

Secret scanningとPush protectionで再発を防ぐ

GitHubのSecret scanningは、対応するAPIキーやトークンなどをGit履歴から検出します。利用できるリポジトリではアラートを有効にし、通知先と対応担当を決めておきましょう。ただし、すべての独自形式や変形された秘密情報を必ず検出できるわけではないため、検出機能だけには依存しません。

Push protectionは、対応する秘密情報をpush時に検出し、リポジトリへ届く前にブロックします。個人向け保護や組織・リポジトリ向け設定の利用条件を確認し、警告を安易に回避しない運用を整えます。

日常の対策として、キーには必要最小限の権限と有効期限を設定し、用途ごとに分けます。git add . だけで済ませず、ステージするファイルを選び、commit前に次の差分を確認する習慣も有効です。

git diff --cached

秘密情報を環境変数へ移すこと、追跡対象を限定すること、push前に内容を確認すること、自動検出を有効にすることを重ねると、一つの見落としがそのまま漏洩になる可能性を下げられます。

まとめ

GitHubへAPIキーをpushしたら、最初に発行元でキーを失効または交換し、新しいキーへ利用先を切り替えます。続いて利用履歴と請求を確認し、現在のコードから秘密情報を除去してください。履歴の書き換えは、失効だけでリスクを抑えられない場合に、共同作業者や管理者と影響を調整して実施します。

今すぐできる最も重要な行動は、commitを消す操作を探すことではなく、漏れたキーの権限を止めることです。

一度の誤pushは焦る出来事ですが、正しい順序で封じ込め、仕組みを一つ追加すれば、次の事故を防ぐ具体的な改善へ変えられます。