削除したGoogle APIキーが最大23分間有効のまま、Googleは報告を「修正しない（Won’t Fix）」としてクローズ|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年05月27日更新日時: 2026年05月27日

セキュリティ企業Aikido SecurityのJoe Leon氏は2026年5月21日、Google Cloud Platform（GCP）のAPIキーを削除してもGoogleの認証基盤が即座に反映されず、削除後最大23分間にわたってキーが有効なまま認証が成功し続けることを実証した調査結果を公式ブログで公表しました。

Aikido Securityは本件をGoogleに報告しましたが、Googleはこの報告を「Won’t Fix（修正しない）」として閉じました。

この記事のサマリー

調査機関：Aikido Security（Joe Leon氏）
調査方法：2日間にわたる10回の制御実験
発見した事実：Googleの管理コンソール（GCPコンソール）上では「削除済み」と即座に表示されるにもかかわらず、削除されたAPIキーは平均16分間・最大23分間にわたって実際に有効（認証成功）なままである。
根本原因：Googleのグローバル認証基盤における「結果整合性（Eventual Consistency）」の設計——削除コマンドがグローバルに分散したサーバー全体に即座には伝播しない。
攻撃の条件：漏洩したAPIキーを持つ攻撃者が、まだ更新されていないサーバーに対して継続的にリクエストを送り続けることで悪用が可能。
悪用できるサービス：GCP全般・Gemini（会話キャッシュ・アップロードファイルの窃取）・BigQueryのデータ・Google Maps API・プロジェクトで有効化されているすべてのAPI。
ユーザーの見えなさ：GCPコンソールはキーを削除済みと表示し、キーがまだ動作中であることを通知しない。ユーザーには失効を早める手段も、いつ止まるかを確認する手段もない。
AWSとの比較：Eduard Agavriloae氏が数か月前に開示したAWSの同種問題の失効遅延はわずか4秒。Googleは同じ問題が最大23分。
Googleの対応：Aikido SecurityからのレポートをGoogleは**「Won’t Fix（修正しない）」としてクローズ**。

1 実験の詳細—「削除済み」表示後も23分間認証が成功
- 1.1 何を実験したか
- 1.2 結果
2 根本原因—「認証に結果整合性は許されない」
- 2.1 結果整合性とは
- 2.2 地域によって異なる失効速度
3 何ができるか—Gemini会話・BigQueryデータ・Maps APIへのアクセス
4 AWSとの比較——4秒 vs 23分
5 Googleの「Won’t Fix」対応
6 ユーザーが取るべき対応
- 6.1 「削除すれば安全」という前提を見直す
- 6.2 推奨される追加対応
7 FAQ
8 参考情報（1次ソース）

実験の詳細—「削除済み」表示後も23分間認証が成功

何を実験したか

Aikido Securityは2日間にわたり、以下の手順を10回繰り返す制御実験を実施しました。Googleのプロジェクトに新規APIキーを作成し、GCPコンソールから当該APIキーを削除します。削除直後から一定間隔で当該キーを使ってAPIリクエストを送信し、認証が成功しなくなるまでの時間を計測しました。

結果

平均失効時間：約16分として、10回の試験の平均で、削除から認証が通らなくなるまで約16分を要しました。最大失効時間：約23分として、最も遅かったケースでは23分近くにわたって削除済みのキーで認証が成功し続けました。この間、GCPコンソール上では当該キーは「削除済み」と表示されており、キーがまだ機能していることを示す情報は一切表示されませんでした。

根本原因—「認証に結果整合性は許されない」

結果整合性とは

Aikido Securityのブログタイトル「Authentication should not be eventually consistent（認証は結果整合性であるべきでない）」が本質を端的に表しています。

「結果整合性（Eventual Consistency）」は、大規模な分散システムにおいて、更新が全サーバーに即座に反映されるのではなく、時間をかけて段階的に伝播していく設計モデルです。Googleのように世界規模のインフラを持つ企業にとって、多くのサービスで結果整合性を採用することはスケーラビリティと高速性のために合理的な選択です。しかし認証（特にキーの失効）においてこのトレードオフを採用することは正当化が難しいとAikido Securityは指摘しています。

APIキーが削除されると、その「削除」メッセージはGoogleのグローバルに分散したサーバー群に即座には伝播せず、段階的に伝播していきます。攻撃者は連続的な認証リクエストを送り続けることで、まだ更新されていないサーバーに当たり続けるという手法で、削除済みのキーを使い続けられます。

地域によって異なる失効速度

HGCPの異なる地域での実験により、地域によって多様なばらつきがあることも判明しています。削除後最初の1分間では、異なるGCPリージョンのVMによって異なる割合でキーが受け入れられていました。これは攻撃者がより「更新の遅い」地域のエンドポイントを狙って継続的に悪用できることを示しています。

何ができるか—Gemini会話・BigQueryデータ・Maps APIへのアクセス

この23分間の「失効ウィンドウ」の間、漏洩したAPIキーを持つ攻撃者はプロジェクトで有効化されているすべてのAPIにフルアクセスできます。Aikido Securityが確認した悪用可能なアクションには以下が含まれます。

Gemini AIへのアクセスとして、Geminiがプロジェクトで有効化されている場合、キャッシュされた会話内容の窃取（exfiltrate cached conversations）およびGeminiにアップロードされたファイルのダンプ（dump files uploaded to Gemini）が可能です。BigQueryデータへのアクセスとして、BigQueryが有効化されている場合、格納されている企業データ・分析データへのクエリ実行が可能です。Google Maps APIへのアクセスとして、Maps APIが有効化されている場合、APIクォータの不正消費や関連データへのアクセスが可能です。その他すべての有効化済みAPIへのアクセスとして、プロジェクトで有効化されているすべてのGCP APIが対象となります。

AWSとの比較——4秒 vs 23分

Aikido Securityのブログは、同種の問題が他のクラウドプロバイダーでも確認されていることを指摘しています。セキュリティ研究者Eduard Agavriloae氏が数か月前にAWS（Amazon Web Services）で同類の「結果整合性による削除遅延」を開示しており、削除されたAWSアクセスキーが新規の認証情報を作成できる窓は4秒でした。4秒でも問題視されたにもかかわらず、Googleでは同じ問題が最大23分間発生していることがAikido Securityの実験で判明しました。

AWSの4秒とGoogleの23分という約350倍の差は、両者の認証基盤の設計と失効処理の優先度の違いを如実に示しています。

Googleの「Won’t Fix」対応

Aikido SecurityはGoogleにこの調査結果を報告しましたが、Googleはこの報告を「Won’t Fix（修正しない）」としてクローズしました。

「Won’t Fix」は通常、報告された問題が（a）設計通りの動作である、（b）修正コストがリスクを上回る、または（c）優先度が低い、と評価された場合に付けられる判定です。今回のケースでは結果整合性がGoogleのインフラの根本的な設計原則であり、全世界のサーバーで瞬時に認証失効を実現することがGoogle規模のインフラでは困難であることが背景にあるとみられます。

しかしAikido Securityは「この問題の深刻さは明らかである。認証情報の失効遅延は悪用可能であり、実際に悪用されるリスクがある」と主張しています。

ユーザーが取るべき対応

「削除すれば安全」という前提を見直す

今回の発見が最も重要な示唆を与えるのは「APIキーが漏洩した際のインシデントレスポンス」の文脈です。多くの組織・開発者がAPIキーの漏洩に気づいた際に最初に取るアクションは「GCPコンソールで削除する」ことです。しかし今回の調査が示すように、削除操作はGCPコンソール上でのみ即座に反映され、実際の認証失効は平均16分・最大23分後にしか完了しません。

この23分間、漏洩先の攻撃者はGemini・BigQuery・Maps等のデータに依然としてアクセスし続けられます。

推奨される追加対応

APIキーの削除と同時に当該プロジェクトへのアクセスを完全に遮断することとして、GCPのIAM設定でプロジェクト全体へのアクセスを一時的に制限することで、削除遅延の影響を最小化できます。Gemini・BigQuery等の監査ログを即座に確認することとして、APIキーを削除した後の23分間に当該キーで行われたAPIコールのログを確認し、不審な操作（ファイルのダウンロード・クエリの実行等）がないかを確認してください。

APIキーの使用範囲を最小化する（最小権限の原則）こととして、漏洩した際の影響範囲を最小化するため、APIキーに付与する権限を必要最小限に制限し、IPアドレス制限や参照元制限（Referrer Restriction）を設定してください。GitHubのシークレットスキャン・Defenderを活用することとして、APIキーが誤ってコードリポジトリにコミットされた際の即時検出と通知の仕組みを整備してください。

FAQ

Q. この問題はAPIキーだけの問題ですか？OAuthトークン等は影響を受けますか？ A. Aikido Securityの今回の調査はGCPのAPIキー（Simple API Key）に特化したものです。OAuthトークンやサービスアカウントキー等への適用については本調査の対象外であり、別途確認が必要です。

Q. Google Workspaceや個人向けGoogleアカウントも影響を受けますか？ A. 今回の調査はGoogle Cloud Platform（GCP）のAPIキーを対象にしています。Google Workspaceの管理者アカウントやGoogleアカウントのパスワード等は対象外です。

Q. Googleは何らかの改善策を示しましたか？ A. Aikido Securityのブログによれば、GoogleはこのレポートをWon’t Fixとしてクローズしており、現時点で公式な改善計画や代替手段は公表されていません。