核心原因在於 分散式系統的設定傳播延遲(propagation delay)。
Google Cloud 的驗證服務由多個後端系統組成。當 API 金鑰被刪除時,撤銷訊息需要在整個基礎設施中逐步同步,而不是同一瞬間在所有伺服器生效。
因此可能出現這種情況:
Aikido 在兩天內進行了 10 次測試,每次建立新金鑰後立即刪除,並持續發送驗證請求,直到完全失效為止,最終得到 8–23 分鐘的可用窗口。
在實際的資安事件中,一旦 API 金鑰外洩,立即撤銷憑證通常是最重要的應對措施之一。但這項研究指出,即使已刪除金鑰,仍可能存在短暫的可利用時間。
如果攻擊者已取得該金鑰,在這段時間內仍可能:
研究人員表示,他們的測試使用了可存取 Gemini 的 API 金鑰,但同樣的延遲也出現在 BigQuery、Google Maps 等其他 Google Cloud API 上。問題與特定服務無關,而是 API 金鑰憑證機制本身的撤銷流程所造成。
根據公開報告,Google 最初將這個問題視為分散式系統中的 正常傳播延遲,而不是嚴重的安全漏洞,一度以「won’t fix(不修正)」結案。
之後在進一步檢視後,該問題被重新開啟並在內部標記為 P0 等級 bug,代表需要最高優先級調查與處理。
目前觀察到的延遲差異,主要取決於請求被哪個後端系統處理,以及撤銷資訊何時傳播到該節點。
在官方機制能確保即時撤銷之前,安全團隊應假設 刪除 API 金鑰並不等於立即失效。
1. 將刪除視為「延遲隔離」措施
發生憑證外洩時,應預期存在約 30 分鐘內的風險窗口。
2. 持續監控日誌與帳單
如果在刪除後仍出現 API 呼叫或使用量暴增,可能代表金鑰在傳播延遲期間仍被使用。
3. 對 API 金鑰加上限制
Google 建議設定來源限制,例如:允許的 IP、HTTP referrer 或可使用的 API,以降低外洩金鑰的利用價值。
4. 盡快輪替憑證
不要只依賴刪除舊金鑰,應同時建立新金鑰並更新服務設定,快速完成憑證輪替。
這項發現再次凸顯大型雲端平台的一個現實:設定變更往往不是即時生效,而是逐步傳播。
對開發者與安全團隊而言,這意味著事件應變流程需要考慮這種延遲。換句話說——在分散式系統裡,「已刪除」並不一定代表「立即無效」。
核心原因在於 分散式系統的設定傳播延遲(propagation delay)。
Google Cloud 的驗證服務由多個後端系統組成。當 API 金鑰被刪除時,撤銷訊息需要在整個基礎設施中逐步同步,而不是同一瞬間在所有伺服器生效。
因此可能出現這種情況:
Aikido 在兩天內進行了 10 次測試,每次建立新金鑰後立即刪除,並持續發送驗證請求,直到完全失效為止,最終得到 8–23 分鐘的可用窗口。
在實際的資安事件中,一旦 API 金鑰外洩,立即撤銷憑證通常是最重要的應對措施之一。但這項研究指出,即使已刪除金鑰,仍可能存在短暫的可利用時間。
如果攻擊者已取得該金鑰,在這段時間內仍可能:
研究人員表示,他們的測試使用了可存取 Gemini 的 API 金鑰,但同樣的延遲也出現在 BigQuery、Google Maps 等其他 Google Cloud API 上。問題與特定服務無關,而是 API 金鑰憑證機制本身的撤銷流程所造成。
根據公開報告,Google 最初將這個問題視為分散式系統中的 正常傳播延遲,而不是嚴重的安全漏洞,一度以「won’t fix(不修正)」結案。
之後在進一步檢視後,該問題被重新開啟並在內部標記為 P0 等級 bug,代表需要最高優先級調查與處理。
目前觀察到的延遲差異,主要取決於請求被哪個後端系統處理,以及撤銷資訊何時傳播到該節點。
在官方機制能確保即時撤銷之前,安全團隊應假設 刪除 API 金鑰並不等於立即失效。
1. 將刪除視為「延遲隔離」措施
發生憑證外洩時,應預期存在約 30 分鐘內的風險窗口。
2. 持續監控日誌與帳單
如果在刪除後仍出現 API 呼叫或使用量暴增,可能代表金鑰在傳播延遲期間仍被使用。
3. 對 API 金鑰加上限制
Google 建議設定來源限制,例如:允許的 IP、HTTP referrer 或可使用的 API,以降低外洩金鑰的利用價值。
4. 盡快輪替憑證
不要只依賴刪除舊金鑰,應同時建立新金鑰並更新服務設定,快速完成憑證輪替。
這項發現再次凸顯大型雲端平台的一個現實:設定變更往往不是即時生效,而是逐步傳播。
對開發者與安全團隊而言,這意味著事件應變流程需要考慮這種延遲。換句話說——在分散式系統裡,「已刪除」並不一定代表「立即無效」。