API-Schlüssel bei einem kompromittierten Anbieter: Eindämmung, Austausch und Abrechnungsprüfung

Ziel

Stand: 25. Oktober 2026. Das Risiko durch API-Schlüssel eindämmen, die bei einem Dienst, der sie gespeichert hat, möglicherweise offengelegt wurden; danach autorisierte Zugriffe wiederherstellen und die Nutzung abgleichen. Die aktuelle Mitteilung dieses Dienstes sowie die Dokumentation der jeweiligen Aussteller zu Widerruf, Rotation und Abrechnung erneut prüfen. Dieses Verfahren belegt nicht, dass ein bestimmter Sicherheitsvorfall stattgefunden hat.

Voraussetzungen

Eine vertrauenswürdige Administrationsumgebung mit ausstellerseitiger Verwaltung der Zugangsdaten, die betroffenen Projektkennungen, die Anwendungsverantwortlichen sowie Zugriff auf Audit- und Abrechnungsdaten bereitstellen. Die Fassung der Mitteilung und den Zeitraum der möglichen Offenlegung einschliesslich Zeitzone festhalten; einen unbekannten Beginn als unbekannt kennzeichnen. Die eigentlichen Zugangsdaten nicht in das Vorfallticket aufnehmen.

Schritte

1. Die mögliche Offenlegung erfassen. Ermitteln, welche Schlüssel der Anbieter gespeichert hatte und welche berechtigten Anwendungen sie gemeinsam verwenden. Kennungen, Berechtigungen und Verantwortliche erfassen. Für Google Cloud lautet der dokumentierte Inventarbefehl gcloud services api-keys list --project=PROJECT_ID; den Platzhalter durch die Projektkennung ersetzen. Ein Schlüsselverzeichnis zeigt mögliche Betroffene, ist aber kein Diebstahlnachweis. CLI-Referenz.

2. Vor der Wiederherstellung eindämmen. Die betroffene Integration aussetzen und offengelegte Schlüssel bei ihrem Aussteller widerrufen. Das Löschen einer gespeicherten Kopie ist kein ausstellerseitiger Widerruf. Das Vorfallverfahren von OWASP sieht zuerst den sofortigen Widerruf vor, danach Austausch und Bereinigung. Eine kontrollierte Unterbrechung in Kauf nehmen, statt offengelegte Zugangsdaten weiterzuverwenden. Verhindern, dass der betroffene Dienst neue Geheimnisse erhält, bis seine Wiederherstellung bestätigt ist. OWASP zum Umgang mit offengelegten Geheimnissen.

3. Über vertrauenswürdige Wege ersetzen. Ersatzschlüssel ausstellen und jede berechtigte Anwendung aktualisieren. Google Cloud dokumentiert auch eine gestaffelte API-Schlüsselrotation: den Ersatzschlüssel erstellen, Anwendungen aktualisieren und anschliessend den bisherigen Schlüssel löschen. Wird eine solche Überschneidung zur Wahrung der Verfügbarkeit genutzt, den Zeitraum ausdrücklich berücksichtigen, in dem der offengelegte Schlüssel weiter verwendbar bleibt. Das Erstellen eines neuen Schlüssels nicht stillschweigend mit dem Widerruf des alten gleichsetzen. Verfahren des Ausstellers.

4. Das Konto untersuchen. Verfügbare Audit-Daten vom frühestmöglichen plausiblen Zeitpunkt der Offenlegung bis zur Eindämmung durchsuchen. Auf unerwartete Aufrufe, neue Zugangsdaten und Identitäten sowie Ressourcenänderungen achten; Google Cloud verweist für diese Untersuchung auf Cloud Logging und Security Command Center. Relevante Nachweise sichern, bevor unberechtigte Zugriffsmöglichkeiten entfernt werden. Nutzung und Abrechnung separat mit den erwarteten Workloads vergleichen und Kennungen strittiger Anfragen, Zeitstempel sowie Kostenbelege über authentifizierte Supportkanäle übermitteln. Keine Erstattung voraussetzen. Hinweise zur Untersuchung.

5. Künftige Zugriffe begrenzen. Integrationen und Umgebungen trennen, nur die erforderlichen Berechtigungen vergeben und kurzlebige Zugangsdaten bevorzugen, sofern unterstützt. Google Cloud empfiehlt API- und Anwendungsbeschränkungen, um Schlüsselmissbrauch zu verringern. Die Beschränkungen auf die berechtigte Anwendung zuschneiden und prüfen, ob sie weiterhin funktioniert. Schlüsselbeschränkungen, Lebenszyklus von Geheimnissen.

6. Kostenkontrollen einrichten und unterscheiden. Vom Aussteller durchgesetzte Ausgabenlimits oder Kontingente konfigurieren, soweit verfügbar, und zusätzlich Warnungen an einen überwachten Kanal senden lassen. Bestätigen, welche Einstellungen Anfragen tatsächlich stoppen. AWS Budgets warnt ausdrücklich, dass verzögerte Abrechnungen und Benachrichtigungen Ausgaben oberhalb einer Warnschwelle ermöglichen können. Die Zustellung von Warnungen testen, ohne absichtlich übermässige Kosten zu erzeugen. Grenzen von Budgetkontrollen.

7. Den Abschluss verifizieren. Die ausstellerseitige Ungültigkeit der alten Zugangsdaten, die erfolgreiche berechtigte Nutzung der Ersatzschlüssel und die fortgesetzte Nutzungsprüfung kontrollieren, während verzögerte Abrechnungsdaten nachträglich erfasst werden. Ungeklärte Protokolllücken und verdächtige Kontoänderungen dokumentieren. Bei Hinweisen auf eine Kompromittierung des Hosts eine gesonderte Untersuchung zur Wiederherstellung einleiten, bevor dort erneut Zugangsdaten eingerichtet werden.

Erwartetes Ergebnis

Die offengelegten Zugangsdaten sind ungültig, berechtigte Anwendungen verwenden eingeschränkte Ersatzschlüssel, und die beleggestützte Nutzungsprüfung hat eine verantwortliche Stelle und dokumentierte Befunde.

Grenzen und Prüfbasis

Dies ist ein vorgeschlagenes Vorgehen, das betriebliche Empfehlungen zusammenführt, keine getestete Wiederherstellung. Fehlende Protokolle können nicht belegen, dass kein Missbrauch stattgefunden hat. Google Cloud warnt, dass bereits ausgestellte Service-Account-Tokens eigene Gültigkeitsdauern haben: Abgeleitete Zugriffsmöglichkeiten untersuchen, statt anzunehmen, dass der Austausch des zugrunde liegenden Schlüssels sie ungültig macht. Es wird weder eine betroffene Softwareversion noch eine Version mit behobenem Fehler behauptet.