Ein Schlüssel, ein Tool, ein knapper Ausgang
Vor einiger Zeit wollte ich ein Entwicklungswerkzeug ausprobieren, das für die Bildgenerierung einen eigenen API-Zugang braucht. Ich habe getan, was in dieser Situation alle tun: einen Schlüssel bei Google erzeugt, ihn in das Eingabefeld des Tools kopiert, weitergearbeitet. Kein ungewöhnlicher Vorgang, keine erkennbare Warnung, ein Feld wie hundert andere.
Einige Zeit später funktionierte der Schlüssel nicht mehr. Der Grund war nicht ein abgelaufenes Kontingent, sondern eine Sperre durch Google selbst: Der Schlüssel war öffentlich geworden. Google hat ihn erkannt und stillgelegt, bevor nennenswerte Kosten entstanden sind. Anders gesagt: Nicht meine Vorsicht hat den Schaden verhindert, sondern die automatische Erkennung des Anbieters.
Das ist der eigentlich unangenehme Teil der Geschichte. Ich habe den Schlüssel nicht in ein öffentliches Repository geschoben und ihn nicht in einen Chat kopiert. Ich habe ihn einem Werkzeug anvertraut, und ab diesem Moment lag seine Sicherheit nicht mehr in meiner Hand. Genau das ist das Muster, das in Unternehmen täglich hundertfach abläuft, meist ohne dass jemand davon erfährt.
Der Kern in einem Satz: Ein API-Key ist ein Inhaberschlüssel. Er kennt keinen Benutzer, kein Passwort, keine zweite Stufe. Wer ihn besitzt, ist berechtigt. Deshalb ist die einzige belastbare Frage nicht, ob ein Schlüssel abhandenkommen kann, sondern was er anrichten kann, wenn es passiert.
Die Größenordnung: 28,6 Millionen im Jahr
Der State of Secrets Sprawl 2026 von GitGuardian zählt für das Jahr 2025 28,6 Millionen neu entdeckte Secrets in öffentlichen GitHub-Commits. Das sind 34 Prozent mehr als im Vorjahr und ein Wachstum von 152 Prozent seit 2021. Die Zahl umfasst Zugangsdaten aller Art, API-Keys machen davon einen großen Teil aus.
Die aussagekräftigere Zahl ist eine andere: 64 Prozent der im Jahr 2022 entdeckten Secrets waren vier Jahre später noch gültig. Ein geleakter Schlüssel ist also kein Vorfall mit Anfang und Ende, sondern ein Zustand. Er bleibt offen, bis ihn jemand aktiv widerruft, und in den meisten Fällen tut das niemand, weil niemand vom Leck weiß.
Warum das Problem gerade wächst
Zwei Entwicklungen treffen aufeinander. Erstens braucht heute fast jedes Werkzeug einen Zugang zu einem fremden Dienst, und jeder dieser Zugänge ist ein weiterer Schlüssel im Umlauf. Der Bericht weist für Zugangsdaten zu KI-Diensten ein Wachstum von 81 Prozent gegenüber dem Vorjahr aus.
Zweitens verschiebt sich, wer Code schreibt. Laut demselben Bericht enthalten KI-gestützt erstellte Commits ungefähr doppelt so häufig Secrets wie der Durchschnitt aller öffentlichen Commits. Das liegt nicht daran, dass die Werkzeuge fahrlässig wären, sondern daran, dass mehr Menschen mit weniger Betriebserfahrung produktiven Code erzeugen. Wer sich mit dieser Seite beschäftigt, findet mehr dazu in unserem Artikel zu den Sicherheitsrisiken bei Vibe Coding.
Vier Wege, auf denen ein Schlüssel abhandenkommt
In der Praxis sind es fast immer dieselben vier. Der erste ist bekannt, die anderen drei werden regelmäßig unterschätzt, weil sie sich nicht wie ein Sicherheitsvorfall anfühlen.
| Weg | Wie es passiert | Was dagegen hilft |
|---|---|---|
| Versionsverwaltung | Der Schlüssel steht in einer Konfigurationsdatei, die versehentlich mitcommittet und später öffentlich wird | Secret-Scanning im Repository aktivieren, Konfigurationsdateien konsequent ausschließen |
| Auslieferung an den Browser | Der Schlüssel steckt im Frontend-Code und wird an jeden Besucher mitgeliefert, sichtbar in den Entwicklerwerkzeugen | Aufrufe über einen eigenen Server leiten, der den Schlüssel ergänzt, statt ihn auszuliefern |
| Übergabe an ein fremdes Werkzeug | Der Schlüssel wird in ein Tool, einen Baukasten oder eine Plattform eingetragen und liegt danach auf deren Servern | Eigener Schlüssel je Werkzeug, eingeschränkt und mit Ausgabenlimit, nie der Produktivschlüssel |
| Protokolle und Adresszeilen | Der Schlüssel wandert als Parameter in die URL und landet in Server-Protokollen, Verläufen und Fehlerberichten | Schlüssel im HTTP-Header übergeben, nicht als Abfrageparameter |
Der dritte Fall ist der aus meiner Geschichte und der mit dem größten Zuwachs. Sobald ein Schlüssel an ein fremdes Werkzeug übergeben wird, erben Sie dessen Sicherheitslage: dessen Serverkonfiguration, dessen Protokollierung, dessen Mitarbeiterzugriffe, dessen Umgang mit Sicherungskopien. Sie haben keine dieser Fragen geprüft, und in der Regel können Sie es auch nicht.
Drei Ebenen, die den Schaden begrenzen
Da sich das Abhandenkommen nicht sicher verhindern lässt, ist die belastbare Strategie eine andere: den Wert des Schlüssels für einen Angreifer so weit senken, dass ein Leck folgenlos bleibt. Das geschieht auf drei Ebenen.
Ebene 1: Einschränken
Google formuliert es in der eigenen Dokumentation ohne Umschweife: Uneingeschränkte API-Keys sind unsicher. Zwei Beschränkungen sollten immer gleichzeitig gesetzt sein. Die API-Beschränkung legt fest, welche Schnittstellen der Schlüssel überhaupt ansprechen darf. Die Anwendungsbeschränkung legt fest, von wo aus er gültig ist, etwa von bestimmten IP-Adressen, Webseiten oder App-Kennungen. Ein Schlüssel, der nur eine Schnittstelle und nur von einer Server-IP aus bedient, ist in fremden Händen weitgehend wertlos.
Ebene 2: Begrenzen
Hier steckt der Irrtum, der aus einem Leck erst eine Rechnung macht. Ein Budget-Alarm ist keine Obergrenze. Die Google-Cloud-Dokumentation sagt ausdrücklich, dass ein reines Alarm-Budget die Nutzung oder die Kosten nicht automatisch deckelt. Es benachrichtigt Sie, während der Zähler weiterläuft, und Benachrichtigungen erreichen niemanden um drei Uhr früh.
Über welche Größenordnung wir dabei reden, unterschätzen die meisten. Ein gestohlener Schlüssel wird nicht sparsam benutzt. Die übliche Verwertung ist der Weiterverkauf von Rechenzeit: Der Schlüssel läuft rund um die Uhr am oberen Ende dessen, was das Ratenlimit hergibt. Und dieses Limit ist bei einem regulär freigeschalteten Zahltarif großzügig, weil es für Ihren Produktivbetrieb ausgelegt ist und nicht für Missbrauch. Rechnen Sie es einmal für Ihren eigenen Zugang durch: zulässige Anfragen pro Minute mal 1.440 Minuten mal Preis pro Anfrage. Bei einem leistungsfähigen Modell ohne gesetztes Kontingent landen Sie bei einem vierstelligen Tagesbetrag, und zwar an jedem Tag, an dem das Leck unbemerkt bleibt.
Das ist auch der Grund, warum die Erkennungsmechanismen der Anbieter so wichtig sind. In meinem Fall hat Google den Schlüssel gesperrt, bevor sich das aufsummiert hat. Diese Sperre ist eine Kulanz der Infrastruktur, kein Anspruch, und sie greift nur, wenn der Schlüssel an einer Stelle auftaucht, die der Anbieter scannt.
Der Unterschied, der zählt: Eine echte Obergrenze entsteht nur durch Kontingente auf Schnittstellenebene, etwa maximale Anfragen pro Minute und pro Tag, oder durch eine Automatisierung, die bei Überschreitung die Abrechnung des Projekts abschaltet. Wer sich mit dieser Mechanik grundsätzlich beschäftigen will, findet die Systematik im Artikel zu KI-Kosten und Budgetkontrolle.
Ebene 3: Rotieren und aufräumen
Schlüssel altern schlecht. Drei Gewohnheiten genügen: einen neuen Schlüssel mit denselben Beschränkungen anlegen, die Anwendungen umstellen, den alten löschen. Ungenutzte Schlüssel konsequent entfernen, denn jeder existierende Schlüssel ist Angriffsfläche. Und pro Person und pro Anwendung einen eigenen Schlüssel vergeben, damit im Protokoll erkennbar ist, wer was getan hat. Ein gemeinsam genutzter Schlüssel macht jede Untersuchung nach einem Vorfall unmöglich.
Wichtig dabei: Einen kompromittierten Schlüssel zu ändern reicht nicht. Er muss widerrufen werden. Solange er existiert, ist er gültig, unabhängig davon, ob Sie ihn noch verwenden.
Prüfliste, bevor Sie einen Key eintippen
Sechs Fragen, die vor jedem Eingabefeld für einen API-Zugang beantwortet sein sollten. Sie kosten zusammen zwei Minuten.
- Ist das ein eigener Schlüssel für genau dieses Werkzeug? Wenn Sie denselben Schlüssel schon woanders verwenden, erzeugen Sie einen neuen. Ein Schlüssel je Zweck.
- Ist er eingeschränkt? Nur die eine benötigte Schnittstelle, und wenn technisch möglich nur von bestimmten Adressen aus.
- Gibt es eine harte Obergrenze? Kontingent auf Anfragen pro Tag, nicht nur ein Kostenalarm.
- Läuft er auf einem separaten Projekt oder Konto? Ein eigenes Abrechnungsprojekt für Experimente trennt den Schaden vom Produktivbetrieb.
- Wo liegt der Schlüssel danach? Auf einem Server des Anbieters, im Browser des Nutzers, in einer geteilten Konfiguration? Wenn Sie es nicht beantworten können, ist die Antwort ungünstig.
- Wann läuft er wieder ab? Setzen Sie sich eine Erinnerung zum Widerruf, wenn das Experiment beendet ist. Ohne Termin bleibt der Schlüssel für immer.
Für Unternehmen, die mehrere Werkzeuge parallel testen, lohnt zusätzlich ein einfaches Verzeichnis: welcher Schlüssel, für welches Werkzeug, wer hat ihn erzeugt, wann läuft er ab. Eine Tabelle genügt. Sie ersetzt kein Secrets-Management, macht aber den Unterschied zwischen "wir widerrufen den betroffenen Schlüssel" und "wir wissen nicht, welche Schlüssel es gibt". Wie dieses Muster mit unkontrolliert eingeführten Werkzeugen zusammenhängt, beschreibt der Artikel zu Shadow AI im Unternehmen.
Fazit: Den Schlüssel klein halten
In meinem Fall ging es gut aus, weil der Anbieter schneller war als der Missbrauch. Darauf lässt sich keine Strategie bauen. Die belastbare Alternative ist unaufwendig: ein eigener Schlüssel je Werkzeug, beide Beschränkungen gesetzt, ein Kontingent statt eines Kostenalarms, und ein Ablaufdatum im Kalender.
Der konkrete nächste Schritt dauert eine halbe Stunde: Öffnen Sie die Schlüsselverwaltung Ihres wichtigsten Anbieters und sehen Sie nach, wie viele Schlüssel dort ohne jede Beschränkung stehen und wie viele davon Sie noch benutzen. Diese Liste ist bei den meisten Unternehmen länger als erwartet, und sie lässt sich am selben Nachmittag halbieren. Wenn Sie dabei ohnehin über Ihre Anbindungen an fremde Dienste nachdenken: Wir bauen solche Integrationen in der Softwareentwicklung und der KI-Integration von vornherein so, dass kein Schlüssel den Server verlässt.