要約： API 削除すると 、即座に削除されたと表示されますが、当社のテストでは約23分かかると判明しました。 この間、漏洩したキーを悪用する攻撃者は、引き続きデータや有効なAPI（Geminiを含む）にアクセスできます。これをより早く無効化したり、いつ機能しなくなるかを確認したりする手段はありません。Googleは当社の報告に対し、「修正しない」として処理を終了しました。
API 削除すると、アクセス権は直ちに失効すると想定されます。
GoogleAPI 、そのような仕組みにはなっていません。無効化はGoogleのインフラ全体に徐々に反映されていきます。数秒でキーを拒否するサーバーもあれば、23分間も引き続き受け入れるサーバーもあります。
削除された鍵を保持している攻撃者は、同期が完了していないサーバーにリクエストが届くまで、リクエストを送り続けることができます。プロジェクトでGeminiが有効になっている場合、攻撃者はユーザーがアップロードしたファイルをダンプしたり、キャッシュされた会話内容を外部へ持ち出したりすることが可能です。
GCPコンソールにはキーが表示されず、キーがまだ有効であるかどうかも通知されません。最終的にはGoogleのインフラが追いついてくれることを信頼するしかありません。
認証は、最終的に一貫性が保たれるものであってはならない
Google Cloudのサービスの多くは、設計上、最終的な一貫性（eventually consistent）を備えています。このモデルでは、更新内容はサーバー全体に一度に反映されるのではなく、徐々に伝播していきます。このトレードオフにより、Googleはグローバルなスケールを実現しつつ高速性を維持できており、ほとんどのサービスにおいて、この遅延はユーザーには気づかれないほどです。しかし、認証に関しては、このトレードオフを正当化するのは困難です。
認証情報の失効処理の遅延は悪用される可能性があります。数ヶ月前、エドゥアルド・アガヴリロエ氏は、削除されたAWSアクセスキーが新しい認証情報を作成できてしまう原因となる4秒間の遅延を公表しました。AWSにおいては、この4秒という時間は重大な影響を及ぼすのに十分な長さでした。
最近、Geminiへのアクセスに使用されるGoogleAPI 注目を集めていることを受け、GoogleAPI 無効化期間がどのくらいの期間有効であるかを調査することとした。
「失効期間」とは何ですか？
失効期間とは、キーを削除した時点から、最後に認証が成功した時点までの期間を指します。
その時間が数マイクロ秒であれば、動作はユーザーの期待通りになります。それより長くなると、1秒長くなるごとに、攻撃者が盗んだ鍵を悪用する時間がさらに増えます。
失効期間の測定
GoogleAPI 失効までの期間を測定するため、2日間にわたり10回の試験を実施しました。
各テストでは、API を作成し、それを削除した後、数分間有効な応答が返ってこなくなるまで、毎秒3～5回の認証済みリクエストを送信しました。
このレートを選んだのは、Googleが世界中のさまざまな認証サーバーへリクエストをどのようにルーティングするかを、私たちが制御できないためです。このリクエスト量は、Googleのインフラに配慮しつつ、1回のテストで可能な限り多くのサーバーを順次処理できるように設定したものです。リクエストレートを高くすれば、観測可能な期間が延長されるかどうかは定かではありません。攻撃者が私たちのようにリクエストを制限する理由はないため、私たちの数値が最悪のケースを反映しているとは限らない点に留意する必要があります。
念のため、数週間後に作業内容を確認し、確認した動作が一時的なネットワークの問題によるものではないことを確かめました。
23分
10回のテストを通じて、最も長い期間は23分近くにも及びました！削除された鍵がこれほど長い時間、認証に成功し続けるというのは、実に驚くべきことです。
最短の処理時間は8分弱、中央値は約16分でした。各試験を通じて、成功率は極めて予測困難なものでした。削除から1分後、ある試験ではリクエストの79%が成功した一方で、別の試験ではわずか5%しか成功しませんでした。
盗んだ鍵を保持している攻撃者には、明確な遮断や予測可能な減衰は見られません。アクセスは不安定な状態のまま機能し続け、最終的には単に停止するだけです。
GCPコンソールで単一のテストを追跡する
Googleのインフラストラクチャにおける不整合を明らかにするため、GCPの「認証情報ごとのトラフィック」グラフを用いて、当社の試験の1つを監視しました。下の（青色の）線は認証に成功した回数を示しており、失効期間の長さを反映しています。
これ以外のデータが出ることは予想していなかったが、2本目の線が現れた。上の（緑色の）線は拒否されたリクエストを表しており、ラベルには apikey:UNKNOWN私たちは、（誤って）無効なリクエストはプロジェクトの帰属情報なしに単に破棄されるものだと想定していました。ところが、GCPではそれらがこのグラフに含まれているのです。
その謎をより深く理解するために apikey:UNKNOWN 値について、数日前に削除されたAPI を使用して認証を試みました。驚いたことに、それらのリクエストは同じグラフに表示され、同じ apikey:UNKNOWN グループ。
おそらく、ユーザーが認証情報を復元することを想定して、Googleはキーの削除後もプロジェクトの帰属情報を保持しているものと思われます。
認証情報の漏洩を調査しているIRチームにとって、 apikey:UNKNOWN この値は混乱を招く可能性があります。削除されたGoogleAPI を使用して行われたリクエストはすべて「UNKNOWN」カテゴリにまとめられるため、どのリクエストが特定の認証情報に関連しているのかを見分けるのが困難になります。このカテゴリに含まれるリクエストは、攻撃者が削除されたキーで認証を試み続けていることを意味する場合もあれば、無関係な古いキーで実行されている正当なサービスによるものかもしれません。
23分間の失効期間内である場合は、漏洩した鍵を使用した有効な認証がないか確認してください。その期間外であれば、リスクは極めて低いと考えられます。
一貫性における地域差
最初の実験は、米国東海岸の一般家庭のIPアドレスから実施しました。異なるGCPリージョンのVM間で同様の実験を行うことで、さらなる不整合が明らかになるのではないかと仮説を立てました。
3つのリージョンでVMを起動しました： us-east1, ヨーロッパ・西1、および アジア・東南アジア1その後、5回の試験を実施した。各試験において、1つのAPI 削除し、3台のVMそれぞれから並行してリクエストを送信した。
特に2つの点が目立ちました。まず、キーが削除された直後、リージョンごとにVMの認証成功率が大きく異なっていました。以下の表は、リージョンごとの最初の1分間の有効なリクエストの割合を示しています。
例1を見てください： us-east1 82%, ヨーロッパ・西1 60%, アジア・東南アジア1 32%。米国から離れた場所にあるVMほど、削除処理の反映が早かった。これは予想とは逆の結果だ。外部からはその正確な理由は特定できない。Googleのリクエストルーティングは、「VMのリージョン＝サーバーのリージョン」という単純な仕組みよりも複雑であり、シンガポールにあるVMが必ずしもシンガポールのサーバーと通信しているわけではないからだ。しかし、この傾向はすべての試験で一貫して見られたことから、この違いは地域ごとのインフラ、キャッシュ、あるいはルーティングのアフィニティといった要因によるものと考えられる。
第二に、地域間の格差は試合開始直後の現象にとどまらなかった。試合全体を通じて、 アジア・東南アジア1 認証要求の成功率は中央値で22%であった一方、 us-east1 そして ヨーロッパ・西1 どちらも49％前後で推移した。アジア市場は、開始時だけでなく、分刻みで下落し続けた。
こうした違いの原因が何であれ、サーバーの設置場所が、削除されたキーの削除後の挙動に明らかに影響を与えている。
その他のGoogleアカウント情報
今回のテストではすべてGeminiへのアクセス権を持つキーを使用しましたが、BigQueryやMapsなど、他のGCP APIを対象とするキーでも同様の挙動が確認されました。この遅延は、プロジェクトで有効化されているAPIの種類によるものではなく、認証情報の種類に起因するものです。
完全を期すため、Googleの他の2つの認証情報タイプについてもテストを行いました：
- 新しいGeminiAPI （AQ.で始まるもの）。削除処理は約1分で反映されます。
- Google サービス アカウントのキー。削除処理は約 5 秒で反映されました。
どちらもGoogle規模で稼働しており、GoogleAPI 測定した23分よりもはるかに短い時間で無効化されます。
Googleへの開示
この件についてGoogleに報告しました。Googleは、この報告を「修正しない」として処理しました。私たちの理解では、同チームの立場としては、伝播遅延はシステムの既知の特性であり、セキュリティ上の問題ではないとしています。
Googleは、自社のIAMAPI 「最終的にAPI （eventually consistent）」ことを公式に明記していますが、GoogleAPI この動作については具体的に記載していません。
[キャプション：GoogleのIAMAPI ページからのスクリーンショット。]
裏切られたユーザーの期待
Googleのような規模の分散システムを運用するのは困難であり、これはGCP IAMチームに対する批判ではありません。しかし、23分という取り消し可能時間は、ユーザーが「削除」ボタンに期待する動作とは根本的に相容れないものです。その期待とGoogleの実際の動作との間に生じる乖離は、以下の4つの問題を浮き彫りにしています：
1. ユーザーインターフェースが非常に分かりにくい。
キーを削除すると、Googleはそのキーをユーザー画面から削除し、「一度削除すると、そのキーAPI を行うことはできなくなります」と表示します。しかし、この説明は明らかに誤りです。ユーザーには、そのキーがまだ有効かどうかを確認する手段も、無効化を早める手段も、そして完全に機能しなくなったことを確認する手段もありません。
2. Googleは、他の認証情報タイプ向けに、より迅速な失効処理機能を構築しました。
サービスアカウントの認証情報の無効化は、約5秒で反映されます。GeminiのAPI の反映には、約1分かかります。どちらもGoogleのスケールで運用されています。このことから、GoogleAPI についても技術的には解決可能であると考えられます。
3. 長い一貫性ウィンドウは、認証と互換性がありません。
認証情報を削除した際、その認証情報は完全に無効になることが期待されます。エドゥアルドが昨年行ったAWSに関する調査が示したように、ほんの数秒の遅れでも重大な問題となります。
4. 失効期間が長すぎると、ジャスト・イン・タイム方式による認証情報の発行が機能しなくなる。
GoogleAPI 動的に生成したいサービスプロバイダーは、キーが無効化された後、そのキーが確実に使用不能になるまで23分の猶予期間を設ける必要があります。これは、JITの想定される動作とは相容れません。
窓の周りを作業する
Googleがより迅速な失効処理機能を提供するまでは、この課題に対処する責任はユーザーにあります。その際、次の2つの対策が役立ちます。
1. キーの削除は、瞬時に行われるものではなく、30分程度の作業であると見なしてください。
GoogleAPI 漏洩に対応する場合、削除をクリックした後も30分間はキーが有効であると想定してください。これにより、実際に確認された最大23分よりも若干の余裕が生まれます。インシデント対応の残りの手順は、この時間枠を考慮して計画してください。
2. 指定期間中の利用状況を確認する。
GCP コンソールの「有効な API とサービス」で、認証情報ごとのAPI 。削除後にその認証情報から予期しない使用が確認された場合、誰かがその認証情報を悪用している可能性があります。
認証情報の失効処理において、長期にわたる最終一貫性ウィンドウを設定することは、設計上の誤りです。Googleがこの仕様を変更するまでは、すべてのキー削除を30分かかる操作として扱い、このウィンドウが不正利用されないよう注意を払ってください。
