Guide
KI-API-Schlüssel kompromittiert: Was dein Team jetzt tun muss
Railway schätzt die unautorisierten Ausgaben auf 740.000 US-Dollar. So sperrst du betroffene Schlüssel, prüfst die Kosten und stellst Dienste sicher wieder her.
KI-generiertes Symbolbild mit beispielhafter Verbrauchskurve.
Wenn ein KI-API-Schlüssel gestohlen wird, können fremde Anfragen auf deiner Rechnung landen. Sperre den betroffenen Schlüssel beim Anbieter. Kläre dann, welche Anwendungen ihn genutzt haben, welche Berechtigungen er hatte und welche Kosten im fraglichen Zeitraum entstanden sind. Neue Schlüssel gehören erst in eine Umgebung, deren Zugriff ihr wieder unter Kontrolle habt.
Beim Cloud-Anbieter Railway summierten sich die unautorisierten Ausgaben laut eigener Schätzung auf rund 740.000 US-Dollar. Der Fall zeigt, warum Plattformbetrieb, Security und Finance beim selben Vorfall mitarbeiten müssen.
Was der Railway-Bericht bestätigt
Railway hat am 10. November 2026 den ausführlichen Bericht zum Angriff vom 20. und 21. Oktober veröffentlicht. Der Angreifer konnte einen Teil der Kundenvariablen entschlüsseln. Darunter waren Zugangstokens für verknüpfte Konten von 1.852 Nutzern, darunter mitgebrachte KI-Schlüssel und GitHub-OAuth-Tokens. Railway setzte die betroffenen Tokens zurück und informierte die Nutzer. Die geschätzten 740.000 US-Dollar betreffen unautorisierte Nutzung gestohlener Schlüssel. Railway arbeitet mit den Anbietern an Erstattungen. Vorfallbericht von Railway
Railway bat mehrere Anbieter, potenziell betroffene Zugangsdaten zu sperren, während das Team die eigene Infrastruktur absicherte. Zu diesem Zeitpunkt konnte Railway noch nicht gewährleisten, dass dort hinterlegte Ersatzschlüssel geschützt wären. Für die Kunden waren damit zwei Entscheidungen fällig. Wie stoppen wir die fremde Nutzung? Und wann können wir unsere Anwendung mit einem neuen Schlüssel wieder betreiben?
Wie reagierst du auf einen kompromittierten API-Schlüssel?
- Schlüssel beim ausstellenden Anbieter sperren. Bei einem konkreten Verdacht zügig widerrufen. Löschen aus der App-Konfiguration reicht dafür nicht. Falls der Umfang unklar ist, prüft weitere Zugangsdaten, die in derselben betroffenen Umgebung lagen. Anthropic empfiehlt bei Verdacht den sofortigen Widerruf. Anthropic-Hilfe
- Betroffene Systeme und Kosten eingrenzen. Sichert verfügbare Nutzungsdaten und Abrechnungsinformationen. Haltet den Zeitraum, das betroffene Projekt und die referenzierbare Schlüssel-ID fest, soweit der Anbieter sie ausweist. Prüft, welche Anwendungen oder Jobs den Schlüssel nutzen und welche Aktionen seine Berechtigungen zuließen. Den Schlüsselwert selbst braucht ihr dafür in keinem Ticket.
- Dienste kontrolliert wiederherstellen. Sobald ihr die betroffene Umgebung abgesichert habt, stellt neue, zweckgebundene Zugangsdaten aus. Aktualisiert die bekannten Anwendungen und Hintergrundjobs. Prüft, ob sie mit dem neuen Zugang laufen, der alte widerrufen ist und der Verbrauch sich normalisiert. Bei einem externen Hosting-Vorfall stimmt die Wiederinbetriebnahme mit dem Anbieter ab.
Wer übernimmt welche Aufgabe?
| Team | Was es im Vorfall klärt |
|---|---|
| Plattformbetrieb | Zugang sperren, abhängige Dienste ermitteln und Wiederanlauf prüfen |
| Finance | Kosten nach Projekt und Zeitraum aufschlüsseln und strittige Positionen mit dem Anbieter klären |
| Security | Auswirkungen bewerten, Belege sichern und nötige Meldungen mit den zuständigen Stellen klären |
Haltet eine Person für die Koordination fest. Wenn Finance eine neue Auffälligkeit entdeckt, braucht der Plattformbetrieb dieselbe Projektkennung und denselben Zeitraum. Wenn der Plattformbetrieb einen Schlüssel sperrt, muss der Zeitpunkt ins Lagebild. Sonst lässt sich später kaum beurteilen, ob eine neue Abbuchung auf weitere Nutzung oder auf eine verspätete Abrechnung zurückgeht.
Wie begrenzt du das Risiko vor dem nächsten Vorfall?
Ordne den Zugang einer Anwendung und einer verantwortlichen Person zu. Im Verzeichnis genügen Anbieter, Projekt, Schlüsselreferenz, Verwendungszweck und Zuständigkeit. Schlüsselwerte bleiben in der dafür vorgesehenen Secret-Verwaltung. Nutzt getrennte Zugänge für Anwendungen und Umgebungen und beschränkt sie auf die benötigten Funktionen, soweit der Anbieter das unterstützt. Empfehlungen von Google Cloud
Prüfe, was bei Überschreitung eures Budgets passiert. Geht nur eine E-Mail raus oder stoppt die Nutzung? Ein Google-Cloud-Budget sendet Warnungen und begrenzt die Ausgaben für sich genommen nicht. Prüft beim jeweiligen KI-Dienst, ob sich ein verbindliches Limit einstellen lässt. Legt fest, wer auf einen Alarm reagiert und wer einen Dienst bei Bedarf pausieren darf. Google Cloud zu Budgetbenachrichtigungen
Übe den Austausch an einer eigenen Testintegration. Findet ihr den zuständigen Anbieterzugang? Kennt ihr alle Verbraucher? Könnt ihr nach der Umstellung sehen, dass legitime Jobs wieder laufen? Wie ihr verhindert, dass dabei Secrets in Protokollen landen, zeigt unser Beitrag zu API-Schlüsseln und sensiblen Daten in Logs.
Vorfall und Folgemaßnahmen dokumentieren
Für die erste Abstimmung reichen fünf Angaben. Welcher Zugang ist betroffen? Wann wurde er gesperrt? Was wissen wir über Nutzung und Kosten? Welche Dienste sind wieder verfügbar? Wer klärt die offenen Punkte? In Kopexas Vorfallmanagement kannst du die Entscheidungen und Nachweise zum Vorfall zusammenführen und die Folgemaßnahmen nachverfolgen.
Quellen
- Railway: Incident Report on the October 21 Security Attack () [Abgerufen am ]
- Anthropic: Was tun bei einem möglicherweise kompromittierten API-Schlüssel? [Abgerufen am ]
- Google Cloud: Best Practices für die Verwaltung von API-Schlüsseln [Abgerufen am ]
- Google Cloud: Budgets und Budgetbenachrichtigungen [Abgerufen am ]