Vergessene API-Schlüssel: So widerrufen Sie sie, ohne den Dienst zu stoppen

Eine interne Prüfung von OpenRouter ergab, dass 85 Mitarbeitende mehr als 1.000 aktive API-Schlüssel hatten; 168 Schlüssel waren nach Angaben des Unternehmens monatelang nicht verwendet worden. Das sind Zahlen aus einem Selbstaudit von OpenRouter, keine unabhängige Branchenstudie. Doch selbst als Einzelfall veranschaulichen sie eine bekannte technische Falle: Ein Schlüssel kann in Vergessenheit geraten, nicht aber die Anwendung, die von ihm abhängt. Das Unternehmen datierte die Ankündigung des Security Centers auf den 28. September 2026.

Das Problem besteht nicht einfach darin, die älteste Zugangsdaten zu finden und zu löschen. Ein Team muss die verantwortliche Person ermitteln, herausfinden, wo der Schlüssel verwendet wird, und klären, wie er ersetzt werden kann, ohne einen seltenen Auftrag oder einen vergessenen Dienst abzuschalten. Ohne diese Informationen wird der Widerruf von Zugriffsrechten statt einer Aufräumaktion zu einem riskanten Experiment.

Was im Security Center zu sehen ist – und was sich daraus nicht ableiten lässt

Nach der Beschreibung von OpenRouter führt das Security Center die Schlüssel eines Kontos zusammen und zeigt die verantwortliche Person, die letzte Nutzung, ein Ausgabenlimit und das Ablaufdatum an. Organisationsadministratoren sehen alle Schlüssel, Mitglieder nur die von ihnen erstellten. Für Massenaktionen können bis zu 500 Schlüssel ausgewählt werden: zum Deaktivieren, Archivieren oder Festlegen eines Ausgabenlimits. Die Deaktivierung ist umkehrbar, die Archivierung nicht. Das sind vom Anbieter selbst beschriebene Funktionen und keine unabhängige Bewertung ihrer Wirksamkeit.

Besonders wichtig ist, den Status „kann gelöscht werden“ als Hinweis auf eine notwendige Prüfung zu verstehen – nicht als Beweis dafür, dass keine Abhängigkeiten bestehen. Die Nutzungsmetrik zeigt vergangene Anfragen, erklärt aber nicht unbedingt, zu welchem Cron-Job, Notfallszenario oder saisonalen Prozess ein Schlüssel gehört. OpenRouter selbst empfiehlt, die Löschung mit der verantwortlichen Person abzustimmen; auch die Dokumentation zu Sicherheitseinstellungen warnt davor, vor einer Deaktivierung oder Archivierung die Abhängigkeiten zu prüfen.

Für Netzwerkeinschränkungen gilt ein gesonderter Vorbehalt: Eine IP-Allowlist ist für Administratoren im Enterprise-Tarif verfügbar und gilt für alle Schlüssel der Organisation. Anfragen von Adressen außerhalb der Liste werden mit dem Fehler 403 abgelehnt, und Änderungen treten sofort in Kraft. Berücksichtigen Sie daher vor dem Aktivieren der Einschränkung die Adressen von Produktionsservern, Büronetzwerk und CI-Runnern – andernfalls kann die Schutzmaßnahme selbst legitime Aufrufe unterbrechen.

Reihenfolge beim Aufräumen: erst die verantwortliche Person, dann der Widerruf

1. Erstellen Sie ein Inventar. Erfassen Sie für jeden Schlüssel die verantwortliche Person, den Zweck, die Umgebung, die Verbraucher, das Ausgabenlimit und das Ablaufdatum. Wenn das System nur eine Person als verantwortlich ausweist, benennen Sie zusätzlich ein Team oder einen Dienst, das beziehungsweise der bei deren Ausscheiden die Verantwortung übernimmt.
2. Prüfen Sie Nutzung und Abhängigkeiten. Vergleichen Sie den Zeitpunkt der letzten Anfrage mit Zeitplänen für Hintergrundaufgaben, Notfallabläufen, Release-Pipelines und externen Integrationen. Fehlende aktuelle Aktivität ist ein Grund, bei der verantwortlichen Person nachzufragen, aber kein ausreichender Grund für eine sofortige Löschung.
3. Verringern Sie das Risiko vor der Migration. Legen Sie, sofern unterstützt, ein angemessenes Ausgabenlimit und ein Ablaufdatum fest. Beachten Sie das Prinzip der geringsten Berechtigung und die Regeln zur Speicherung von Geheimnissen: Der OWASP-Leitfaden zur Verwaltung von Geheimnissen behandelt Inventarisierung, Zugriff und den Lebenszyklus von Zugangsdaten als eigenständige Prozessbereiche.
4. Erstellen Sie einen Ersatz und migrieren Sie die Verbraucher. Aktualisieren Sie das Geheimnis im Secret Store oder in der Deployment-Konfiguration und stellen Sie die Anwendungen anschließend schrittweise um. Fügen Sie den Schlüssel nicht in Tickets, Logs oder Quellcode ein.
5. Prüfen Sie die Produktionsumgebung vor dem Widerruf. Vergewissern Sie sich, dass der neue Schlüssel bei allen bekannten Verbrauchern funktioniert – einschließlich CI und selten ausgeführter Aufgaben. Deaktivieren Sie den alten Schlüssel anschließend zunächst, wenn eine umkehrbare Aktion verfügbar ist; archivieren oder löschen Sie ihn erst, wenn die Migration bestätigt ist und die vereinbarte Beobachtungszeit verstrichen ist.

Die Abfolge „neuen Schlüssel erstellen → Anwendungen umstellen → Funktion prüfen → alten Schlüssel löschen“ entspricht der Rotationsanleitung von OpenRouter. Das ist eine empfohlene Reihenfolge, aber keine Garantie dafür, dass es zu keiner Unterbrechung kommt: Das Ergebnis hängt davon ab, ob Sie alle Systeme gefunden haben, die die Zugangsdaten verwenden.

Serverschlüssel sind nicht alle Geheimnisse einer Organisation

Die Verwaltungsoberfläche eines einzelnen Anbieters hilft bei der Verwaltung der Schlüssel für dessen Dienst, zentralisiert aber nicht automatisch Geheimnisse aus der Cloud, Datenbanken, CI/CD und anderen APIs. Die allgemeinen OWASP-Empfehlungen zum Lebenszyklus von Geheimnissen umfassen zentrale Speicherung, Zugriffskontrolle, Audits, Rotation und Widerruf. Die Empfehlungen von Google Cloud raten außerdem dazu, den Anwendungsbereich von Schlüsseln einzuschränken, unnötige Zugangsdaten zu löschen und ihre Nutzung nachzuverfolgen.

OpenRouter erklärt zudem, dass das Security Center Schlüsselmetadaten, Ausgaben und Ablaufdaten verwendet, nicht aber Prompts und Antworten liest. Das ist eine Aussage des Anbieters selbst; in den untersuchten Quellen findet sich keine unabhängige technische Überprüfung. Und generell belegt das Vorhandensein einer Verwaltungsoberfläche nicht, dass ein Team bereits die Zahl der Vorfälle oder die Ausgaben reduziert hat: In den untersuchten Materialien wurden keine öffentlichen Ergebnisse nach der Einführung gefunden.