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

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.