GitHub上で誤ってAPIキーを公開リポジトリにプッシュしてしまった場合、速やかな対応が必要です。本記事では、APIキーが漏洩した際の即時無効化手順と、安全な再発行手順を解説します。これにより、漏洩による被害を最小限に抑える方法を理解できます。具体的な手順と注意点を、実際の操作画面の例を交えて説明します。
【要点】APIキー漏洩時の緊急対応手順
- 即時無効化: 漏洩発見後すぐに該当キーを失効させて不正利用を防ぎます。
- 安全な再発行: 新しいキーを生成後、関連サービスに適用して運用を継続します。
- 再発防止策: シークレットスキャンや環境変数の利用など、漏洩を防ぐ仕組みを導入します。
ADVERTISEMENT
APIキー漏洩のリスクとGitHubの検知機能
APIキーは、各種サービスへのアクセス権限を持つ認証情報です。これがGitHubのような公開プラットフォームに漏洩すると、第三者に不正利用される可能性があります。たとえば、OpenAIのAPIキーが漏れると、知らないうちに大量のAPI呼び出しが発生し、高額な請求が来る危険があります。また、AWSのアクセスキーやGoogle CloudのAPIキーが漏れると、クラウドリソースを勝手に起動されたり、データを窃取されたりするリスクがあります。
GitHubには、公開リポジトリ内の機密情報を自動検知するシークレットスキャン機能があります。ただし、すべてのパターンを完璧に検出できるわけではありません。また、プッシュ前に検知するpre-commitフックを導入することで、漏洩を未然に防ぐことも可能です。しかし、万が一漏洩してしまった場合に備え、迅速な対応手順を理解しておくことが重要です。
即時無効化と再発行の手順
ここでは、APIキーがGitHubに漏洩した際の具体的な対応手順を説明します。以下の5ステップで進めてください。
- 漏洩の検知と確認
まず、漏洩が発生したことを確認します。GitHubのシークレットスキャンからの通知メールや、リポジトリのSecurityタブで警告を確認します。または、自分でコミット履歴を確認する方法もあります。たとえば、”git log –diff-filter=A –name-only”で追加ファイルを確認する手もあります。 - 該当APIキーの即時無効化
漏洩したキーを発行元のサービスで直ちに無効化します。たとえば、OpenAIのAPIキーであればOpenAIのダッシュボードからキーを削除または無効にします。AWSのアクセスキーであればIAMコンソールからキーを無効化します。このステップが最も重要で、数分以内に行うことで被害を最小限に抑えられます。 - 新しいAPIキーの発行
無効化したキーの代わりに、新しいAPIキーを発行します。同じサービスで新しいキーを生成し、適切な権限を設定します。このとき、必要最小限のスコープだけを与えるように注意します。たとえば、読み取り専用で十分な場合は書き込み権限を付けないようにします。 - 漏洩したキーの痕跡を削除
GitHubのリポジトリから、漏洩したキーが含まれるファイルや行を削除します。単にファイルを削除するだけでは履歴に残るため、”git filter-branch”やBFG Repo-Cleanerなどのツールを使って履歴からも消去する必要があります。ただし、リポジトリをフォークしている人やクローンを持っている人には影響が及ぶため、通知することも検討します。 - 関連サービスでのキー更新
新しいAPIキーを、実際にそのキーを使用している全てのサービスやアプリケーションに反映します。設定ファイルや環境変数を更新し、動作確認を行います。このとき、シークレット管理サービス(例:GitHub Secrets、AWS Secrets Manager)を利用している場合は、そちらも更新します。
注意点とよくある失敗パターン
無効化前に削除してしまうと履歴に残る
APIキーを含むファイルを削除してから無効化しようとすると、履歴からキーが取得されるリスクがあります。必ず先にキーを無効化してから、ファイルを削除・履歴書き換えを行います。順序を間違えると、無効化前に第三者に悪用される可能性が高まります。
複数サービスで同じキーを使い回している
一つのAPIキーを複数のサービスで共用している場合、漏洩したキーを無効化すると全てのサービスが停止します。そのため、キーはサービスごとに個別に発行し、使い回しを避けることが重要です。もし使い回しをしている場合は、漏洩を機に分離するようにします。
シークレットスキャンの通知を見逃す
GitHubのシークレットスキャンからの通知はメールで届きますが、見落とすことがあります。定期的にリポジトリのSecurityタブを確認する習慣をつけると良いでしょう。また、SlackやTeamsに通知を転送する設定も可能です。
ADVERTISEMENT
APIキーの種類別リスク比較
| キーの種類 | 漏洩時の影響 | 無効化の容易さ | 推奨運用 |
|---|---|---|---|
| 個人アクセストークン | リポジトリ操作可能、悪用でコード改変リスク | 簡単(GitHub設定から即時削除) | 定期的にローテーション、使い捨てトークン利用 |
| OAuth App トークン | スコープ内の操作、ユーザー情報取得 | 中程度(GitHub設定またはアプリ側で失効) | 最小限のスコープ、使用時に発行・使い捨て |
| GitHub App インストールトークン | アプリの権限範囲内、比較的限定 | やや複雑(App設定からトークン削除) | 有効期限を短く設定、自動ローテーション利用 |
よくある質問
Q1: 漏洩したAPIキーを無効化した後、古いキーを使っていたサービスが停止してしまいました。どうすればよいですか?
A: 新しいキーを発行し、そのキーを該当サービスに設定し直してください。サービスの設定画面や環境変数を更新することで復旧できます。事前に新しいキーの準備と切り替え手順を確認しておくとスムーズです。
Q2: GitHubのシークレットスキャンで検出されないAPIキーもありますか?
A: はい。シークレットスキャンは既知のパターンに依存するため、カスタム形式のキーやマイナーサービスのキーは検出されない可能性があります。そのため、手動での確認やpre-commitフックによる予防が重要です。
Q3: 漏洩後、キーを無効化する前に誰かに使われてしまった場合、どうすれば良いですか?
A: すぐにキーを無効化し、サービスプロバイダのサポートに連絡して不正使用の報告を行います。さらに、アクセスログを確認して被害範囲を特定し、必要に応じて関連するデータやリソースの保護措置を講じてください。
まとめ
本記事では、GitHubにAPIキーが漏洩した際の即時無効化と再発行手順を解説しました。漏洩を発見したら、まずキーを無効化し、その後安全な新しいキーを発行して切り替えることが基本です。また、履歴からのキー削除や関連サービスの更新も忘れずに行います。さらに、シークレットスキャンや環境変数を使った予防策を導入することで、漏洩自体を防ぐことができます。
ADVERTISEMENT
超解決 第一編集部
疑問解決ポータル「超解決」の編集チーム。正確な検証と、現場視点での伝わりやすい解説を心がけています。