Gelöschte Google‑API‑Keys bleiben bis zu 23 Minuten aktiv

Das Löschen eines Google‑Cloud‑API‑Schlüssels beendet dessen Nutzung nicht zwingend sofort. Sicherheitsforscher von Aikido Security haben festgestellt, dass ein gelöschter Schlüssel noch mehrere Minuten lang API‑Anfragen authentifizieren kann – selbst wenn die Google‑Cloud‑Konsole bereits anzeigt, dass der Schlüssel entfernt wurde.

In ihren Tests beobachteten die Forscher, dass gelöschte Schlüssel weiterhin zwischen 8 und 23 Minuten funktionierten, mit einem Median von etwa 16 Minuten.

Verzögerter Widerruf in der Cloud

Der Grund liegt in der Architektur großer verteilter Systeme. Änderungen an Zugangsdaten – etwa das Löschen eines API‑Schlüssels – werden nicht gleichzeitig auf allen Servern wirksam.

Wenn ein Schlüssel gelöscht wird, muss diese Information zuerst durch Googles Infrastruktur propagiert werden. Während einige Backend‑Systeme den Schlüssel bereits ablehnen, akzeptieren andere ihn möglicherweise noch, bis die Aktualisierung dort angekommen ist.

Aikido testete dieses Verhalten, indem nach dem Löschen frisch erstellter Schlüssel weiterhin regelmäßig Authentifizierungsanfragen gesendet wurden. In zehn Testläufen funktionierte die Authentifizierung noch mehrere Minuten weiter, bis die Widerrufs‑Information vollständig verteilt war. Daraus ergab sich das beobachtete Zeitfenster von 8 bis 23 Minuten.

Warum das ein Sicherheitsrisiko ist

Für Unternehmen ist das schnelle Deaktivieren kompromittierter Zugangsdaten entscheidend. Wird ein API‑Schlüssel öffentlich oder gestohlen, löschen Administratoren ihn normalerweise sofort, um Missbrauch zu stoppen.

Die von Aikido beobachtete Verzögerung bedeutet jedoch, dass Angreifer den Schlüssel noch eine Weile weiter nutzen können, obwohl Verteidiger glauben, er sei bereits deaktiviert.

In diesem Zeitfenster könnten Angreifer zum Beispiel:

• auf aktivierte APIs eines Projekts zugreifen
• weitere API‑Anfragen senden
• unerwartete Cloud‑Kosten oder Ressourcenverbrauch verursachen

Die Forscher testeten Schlüssel unter anderem mit Zugriff auf Gemini, stellten jedoch fest, dass das Verhalten auch bei anderen Google‑Cloud‑APIs auftritt, darunter BigQuery und Google Maps. Das Problem hängt also mit dem API‑Key‑Mechanismus selbst zusammen und nicht mit einem bestimmten Dienst.

Googles Reaktion

Berichten zufolge stufte Google das Verhalten zunächst als normalen Propagation‑Delay in einem verteilten System ein und betrachtete es nicht als kritische Sicherheitslücke. In einigen Fällen wurde der Bericht zunächst als „won’t fix“ geschlossen.

Nach weiterer Prüfung wurde der Report jedoch wieder geöffnet und intern als P0‑Bug – also mit höchster Priorität – klassifiziert.

Was Entwickler und Sicherheitsteams jetzt tun sollten

Bis eine sofortige Widerrufs‑Garantie möglich ist, sollten Teams davon ausgehen, dass das Löschen eines API‑Schlüssels nicht sofort alle Zugriffe stoppt.

Sinnvolle Vorsichtsmaßnahmen sind unter anderem:

Löschung als verzögerte Eindämmung betrachten
Nach dem Löschen eines kompromittierten Schlüssels sollte ein potenzielles Risiko‑Fenster von bis zu etwa 30 Minuten eingeplant werden.

Logs und Abrechnung genau beobachten
Unerwartete API‑Aufrufe oder plötzliche Nutzungsspitzen kurz nach dem Löschen können darauf hinweisen, dass ein Schlüssel weiterhin verwendet wird.

API‑Schlüssel strikt einschränken
Google empfiehlt, Schlüssel auf bestimmte APIs, IP‑Adressen oder HTTP‑Referrer zu beschränken, damit ein geleakter Schlüssel möglichst wenig Schaden anrichten kann.

Schlüssel rotieren statt nur löschen
Im Incident‑Fall sollten neue Zugangsdaten erzeugt und Dienste möglichst schnell auf diese umgestellt werden, statt sich allein auf das Löschen zu verlassen.

Die größere Lektion für Cloud‑Sicherheit

Der Vorfall zeigt ein grundlegendes Prinzip moderner Cloud‑Infrastrukturen: Änderungen an Konfigurationen oder Zugangsdaten werden oft nicht sofort global wirksam, sondern breiten sich schrittweise aus.

Für Sicherheitsteams bedeutet das eine wichtige operative Regel: „Gelöscht“ heißt nicht zwangsläufig „sofort inaktiv“. Schutzmaßnahmen und Incident‑Response‑Pläne sollten solche Verzögerungen einkalkulieren.