セキュリティ
APIキーをGitHubに上げてしまったら:消すより先に無効化する
2026年8月17日

レン
しまった!APIキーを書いたままGitHubに上げちゃった!でも消したから大丈夫だよね!?

プロクラ
落ち着いて。でも残念だけど、消しただけでは終わらないんだ。順番に対処しよう。

ウィルスン
フフフ…公開された瞬間から、ワタシは見ているのだよ。新しく公開されたコードを常時監視し、認証情報らしき文字列を自動で拾い集めている。数分で十分だ。キミが気づいて消す頃には、もう手元にある。

レン
数分で!?そんなに早いの!

プロクラ
認証情報には決まった形があるものが多いからね。機械が探すのは簡単なんだ。だから「誰も見ていないうちに消せた」という前提は、最初から捨てたほうがいい。
守りは「重ねる」のが基本
攻撃
ファイアウォール
不要な入口を塞ぐ
SSH鍵認証
総当たりを無効化
OS更新
既知の穴を埋める
サーバー
1つ破られても次の層で止まる。どれか1つでは不十分
やるべきこと(この順番で)
- 1. まず鍵を無効化する。消すことより、使えなくすることが先
- 2. 新しい鍵を発行して、環境変数など安全な場所に置き換える
- 3. その鍵で不正な利用がなかったか、利用履歴・請求を確認する
- 4. そのうえで、コミット履歴からも削除する

プロクラ
順番を変えないでね。履歴の書き換えは手間がかかるので、そちらを先に始めると、その間ずっと有効な鍵が公開されたままになる。無効化は数分で終わるよ。
なぜ「消すだけ」では駄目なのか

プロクラ
Gitは履歴を残す仕組みだからだよ。最新のコードから消しても、過去のコミットを辿れば読める。さらに、フォークされていたり、検索サービスにキャッシュされていたりもする。完全に消しきれる保証は無いんだ。

プロクラ
だから「消す」ではなく「その鍵を無価値にする」のが正しい対処。無効化してしまえば、誰に見られていても害はないからね。
被害を確認する

プロクラ
3を飛ばさないこと。既に使われていた場合、気づくのが遅れるほど請求も被害も膨らむよ。
- そのサービスの利用履歴に、身に覚えのない実行が無いか
- 請求額が想定から外れていないか
- その鍵で作られたリソースが増えていないか
- サーバーの鍵だったなら、侵入されていないかも併せて確認する
次から防ぐには
- 認証情報は必ず環境変数に置き、コードに直接書かない
- .envを.gitignoreに入れる(新しいプロジェクトを作った最初にやる)
- コミット前に差分を目視する習慣をつける
- 認証情報の混入を検知する仕組みを導入する
- 鍵には可能な限り権限の制限をかけておく(漏れたときの被害が変わる)

プロクラ
最後の項目が効くよ。読み取りだけの鍵、特定の操作しかできない鍵を分けておけば、漏れたときに失うものが小さくなる。「全部できる鍵」を1つ作って使い回すのが、いちばん危ない。

プロクラ
それと、設定ファイルをスクリーンショットに写して共有する、というのもよくある経路だよ。コードだけの話ではないんだ。

プロクラ
やってしまった経験がある人は多いよ。大事なのは、気づいたときに素早く無効化すること。恥ずかしがって黙っているほうがずっと危険だからね。

レン
消すより先に無効化。履歴は後。権限も絞っておく。覚えた。
あわせて読みたい
- セキュリティ使っていないアカウントを残さない使われていないアカウントとSSH鍵が入口になる理由、棚卸しの手順、消すときの副作用、共同作業で鍵を渡すときの決めごとまで解説します。
- セキュリティ権限777の罠:ファイルパーミッションの基本権限を777にして直すのがなぜ危険か、3桁の数字の意味、そして所有者を合わせるという本筋の直し方。鍵やログなど特に注意するファイルまで解説します。
- セキュリティ個人情報を預かるということ:立場が変わる、という話他人の情報を保管する側になると何が変わるのか、漏らしたときに起きること、そして設計の段階でリスクそのものを減らす考え方を解説します。
- セキュリティ侵入されたら、復旧より先に保全する乗っ取りが疑われるときに真っ先にやるべきこと、慌てて再構築すると失うもの、記録すべき項目と、他人に被害が及んでいる場合の優先順位を解説します。