API キーがリポジトリに含まれてしまった場合の対処法

GitHub にコードをプッシュした直後、API キーも一緒にアップロードしてしまったことに気づく。GitHub からアラートが届いたかもしれません。GitGuardian からメールが来たかもしれません。いずれにせよ、フロントエンドアプリで秘密情報が露出してしまい、時間との戦いが始まります。

ほとんどの開発者が間違える重要なポイントがあります。最新のコミットからキーを削除しても問題は解決しません。Git の履歴はすべてを保持します。フォークがすでに作成されている可能性があります。自動化されたボットは、プッシュから数秒以内に公開リポジトリをスキャンします。

本記事では、GitHub で API キーが漏洩した場合の正確な対処法、本当に機密性の高いシークレットと公開クライアントキーの区別方法、そして再発防止策について解説します。

まず、実際に何を露出させたかを理解する

すべてのキーが同じリスクを持つわけではありません。パニックになる前に、どのタイプの認証情報が漏洩したかを特定しましょう。

公開クライアントキーは、可視化されることを前提に設計されています。特定のドメインに制限された Google Maps API キー、アナリティクストークン、またはクライアントサイド使用を明示的に示すプレフィックス(Next.js の NEXT_PUBLIC_ や Vite の VITE_ など)が付いたキーは、ブラウザバンドルに含まれることを想定しています。これらにも使用制限を設けるべきですが、露出が致命的というわけではありません。

真のシークレットは特権アクセスを付与します。Stripe のシークレットキー、AWS 認証情報、データベース接続文字列、または機密データの読み書きや課金が発生する可能性のあるキーなどです。これらは即座の対応が必要です。

この区別は重要です。なぜなら、対応の内容は深刻度に応じて変わるべきだからです。

即座の対応:まず無効化とローテーション

真のシークレットを漏洩させた場合、履歴のクリーンアップは二次的です。最優先事項は漏洩した API キーのローテーションです。

ステップ 1:露出したキーを即座に無効化する。 API プロバイダーのダッシュボードにログインし、漏洩した認証情報を削除または無効化します。Git 履歴をクリーンアップするまで待たないでください—キーはすでに漏洩しています。

ステップ 2:最小限のスコープで新しいキーを生成する。 最小権限の原則を適用します。可能な限り IP、ドメイン、または特定の API エンドポイントで制限します。

ステップ 3:アプリケーションを更新する。 アプリが動作しなくなる前に、新しいキーを環境にデプロイします。

一部のクラウドプロバイダーは、公開リポジトリで検出された認証情報を自動的に無効化します。例えば、Google Cloud はデフォルトで露出したサービスアカウントキーを自動的に無効化できます。AWS を含む他のプロバイダーは通常、通知は行いますが、一貫してキーを自動的に無効化するわけではありません。これらのプロバイダーはすべて GitHub のシークレットスキャニングパートナープログラムに参加しています。自動化に頼らず、いずれにせよ即座に行動してください。

コミットを削除するだけでは不十分な理由

Git は決して忘れません。現在のブランチからシークレットを削除しても、以下に残ります:

• git log でアクセス可能な過去のコミット
• 修正前に作成されたフォーク
• 他のユーザーやボットがプルした既存のクローン
• 削除前に作成されたあらゆるミラー

これが無効化を最優先する理由です。履歴のクリーンアップは封じ込めであり、修復ではありません。

履歴をスクラブする必要がある場合、git filter-repo や BFG Repo-Cleaner などのツールが役立ちます。ただし、リポジトリが少しでも公開されていた場合は、シークレットが捕捉されたと想定してください。

GitHub のシークレットスキャニングとプッシュ保護

GitHub は、まさにこの問題に対する一流の保護機能を提供しています。シークレットスキャニングとプッシュ保護は、すべての公開リポジトリと、GitHub Secret Protection(GitHub Advanced Security にもバンドル)を介したプライベートリポジトリで利用できます。

シークレットスキャニングは、リポジトリ内の既知の認証情報パターンを検出し、自動的にあなたやプロバイダーに警告します。

プッシュ保護はさらに進んで、検出されたシークレットを含むコミットがリポジトリに到達する前にブロックします。これは利用可能な最も効果的な予防メカニズムです。

リポジトリ設定の Settings → Code security and analysis で両方を有効化するか、GitHub Secret Protection の公式ドキュメントを参照してください。

フロントエンド環境変数の罠

React、Vue、Next.js 開発者の多くが陥る間違いがあります。クライアント使用のためにプレフィックスが付けられた環境変数はシークレットではありません。

REACT_APP_*、NEXT_PUBLIC_*、VITE_* のような変数は、JavaScript に直接バンドルされます。誰でも DevTools を開いて見つけることができます。これらは隠されているのではなく、単に整理されているだけです。

キーが特権アクセスを付与する場合、フロントエンドコードに配置することはできません。以上です。

フロントエンドチームのための予防策

特権キーをサーバーサイドに保持する。 API ルート、サーバーレス関数、またはバックエンドプロキシを使用します。フロントエンドはユーザーを認証し、バックエンドがシークレットを保持します。

プッシュ保護を有効化する。 これにより、ミスがインシデントになる前に捕捉されます。

プレコミットフックを使用する。 gitleaks や detect-secrets などのツールで、ステージされた変更をローカルでスキャンします。

CI スキャニングを追加する。 パイプラインでシークレット検出を実行し、セーフティネットとします。

キーを積極的に制限する。 公開クライアントキーであっても、ドメイン、IP、または API スコープで制限すべきです。

まとめ

API キーが漏洩した場合、完璧さよりもスピードが重要です。まず無効化し、即座にローテーションし、その後二次的なステップとして履歴をクリーンアップします。公開クライアントキーと真のシークレットを混同せず、フロントエンドビルドで環境変数が何かを隠すとは決して信じないでください。

GitHub のプッシュ保護を今日有効化しましょう。この問題が二度と起こらないようにする最も簡単な方法です。

よくある質問

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.