削除後も最大23分使える？Google Cloud APIキーの“遅延失効”問題

なぜ削除後もAPIキーが使えてしまうのか

原因は、Googleのクラウド基盤が大規模な分散システムであることにあります。APIキー削除の情報は全サーバーに同時反映されるわけではなく、インフラ全体に**段階的に伝播（propagation）**します。

その結果、

• あるサーバーではすぐにキーが拒否される
• 別のサーバーではまだ有効として扱われる

という状態が一時的に発生します。

Aikidoはこの挙動を確認するため、新しいAPIキーを作成して削除した直後から認証リクエストを繰り返し送信するテストを実施。10回の試験の結果、削除後もしばらく認証が成功し続け、最長で約23分間利用できるケースが観測されました。

GeminiやBigQuery、Mapsにも影響

この問題は特定のサービス固有ではなく、Google CloudのAPIキーという認証方式そのものに関連しています。

研究者は、以下のAPIでも同様の遅延失効を確認しました。

• Gemini
• BigQuery
• Google Maps

つまり、これらのAPIを利用するプロジェクトでキーが漏洩していた場合、開発者が削除した後でも攻撃者が一定時間アクセスを続けられる可能性があります。

この時間内であれば、攻撃者は次のような行為を行える恐れがあります。

• APIエンドポイントへの追加リクエスト
• プロジェクトのAPI機能へのアクセス
• クラウド利用料金の増加（不正な大量リクエストなど）

Googleの初期対応とその後

Aikidoによると、Googleは当初この挙動を**「分散システムにおける伝播遅延」**として扱い、重大なセキュリティ問題ではないと判断し、報告を「won’t fix（修正予定なし）」として一度クローズしました。

しかしその後、報告は再検討され、内部でP0（最優先レベル）のバグとして再度調査対象になったとされています。

この問題の本質は、削除操作そのものではなく、削除状態がインフラ全体に行き渡るまでの時間差にあります。

開発者・企業が取るべき対策

現時点では、APIキー削除を即時の完全な遮断とみなさない運用が重要です。

推奨される対策は次の通りです。

削除後も短時間のリスクを想定する
キー削除後でも最大30分程度は不正利用が続く可能性を考慮して対応する。

ログと課金状況を監視する
削除直後のAPIトラフィックや急な利用量増加がないか確認する。

APIキーに厳格な制限を設定する
IPアドレス制限、HTTPリファラー制限、利用可能APIの限定などを設定し、漏洩しても悪用範囲を小さくする。

キーのローテーションを行う
削除だけに頼らず、新しいキーを生成してアプリ側を迅速に切り替える。

クラウド運用で覚えておきたい教訓

今回のケースは、巨大な分散インフラでは設定変更が即時に全システムへ反映されるとは限らないという現実を示しています。

つまり、セキュリティ対応の観点では次の原則が重要です。

「削除＝即時無効」ではない可能性を常に想定すること。

APIキーや認証情報が漏洩した場合、削除だけで安心せず、ログ監視・制限設定・迅速なキー更新を組み合わせた対応が求められます。