Best Practices für die Verwaltung von API-Schlüsseln in KI-Produkten (Checkliste 2026)

Best Practices für die Verwaltung von API-Schlüsseln in KI-Produkten (Checkliste 2026)

Bei der sicheren Verwaltung von API-Schlüsseln kommt es auf fünf Dinge an: Schlüssel serverseitig und außerhalb des Codes halten, jeder Umgebung und jedem Workload einen eigenen Schlüssel mit eng begrenzten Rechten zuweisen, Schlüssel in einem Secrets Manager speichern, sie nach einem erprobten Zeitplan rotieren und widerrufen sowie die Nutzung überwachen, ohne jemals den Schlüssel selbst zu protokollieren. Bei KI-Produkten steht mehr auf dem Spiel als bei den meisten APIs: Ein offengelegter Modellschlüssel kann innerhalb weniger Stunden hohe Kosten verursachen und zugleich Zugriff auf Prompts, Dateien und Tool-Aufrufe ermöglichen.

Dieser Leitfaden übersetzt diese Prinzipien in eine Checkliste für Plattform-, Sicherheits- und KI-Produktteams. Er behandelt den Lebenszyklus von Schlüsseln, eine Vorlage für ein Schlüsselinventar, Rotation ohne Ausfallzeiten, Schutzmaßnahmen für CI/CD, ein Runbook für Sicherheitsvorfälle sowie Code zum Generieren, Speichern und Überprüfen von Schlüsseln. Zu den Quellen zählen das OWASP-Cheat-Sheet zur Verwaltung von Secrets, die Best Practices von Google Cloud für API-Schlüssel und die GitHub-Dokumentation zum Secret-Scanning, alle geprüft am 27. Oktober 2026.

Best Practices für die Verwaltung von API-Schlüsseln: die kompakte Checkliste

#	Best Practice	Was sie verhindert
1	Schlüssel niemals fest in Quellcode, Notebooks oder Client-Apps einbetten	Lecks über die Git-Historie, Browser-Bundles und mobile Binärdateien
2	Anbieterschlüssel serverseitig halten; Clients kurzlebige Sitzungstokens geben	Dass Nutzer oder Schadsoftware Ihren Schlüssel von einem Gerät auslesen
3	Pro Umgebung, Anwendung und Teammitglied einen eigenen Schlüssel verwenden	Dass ein einziges Leck beim Widerruf alles lahmlegt
4	Die engsten verfügbaren Einschränkungen anwenden: APIs, Modelle, IPs, Kontingente	Dass gestohlene Schlüssel beliebig einsetzbar sind
5	Schlüssel in einem Secrets Manager speichern, nicht in Tickets, Chats oder Wikis	Kopien, die Sie weder finden noch rotieren können
6	Ein Schlüsselinventar mit Verantwortlichen, Workload und Rotationsdatum führen	Dass die Rotation unbekannte Nutzer des Schlüssels beeinträchtigt
7	Schlüssel planmäßig mit einer Übergangsphase rotieren und anschließend den alten Schlüssel widerrufen	Langlebige Schlüssel, die auch nach dem Ausscheiden von Mitarbeitenden und Dienstleistern gültig bleiben
8	Nicht mehr verwendete Schlüssel löschen	Vergessene Schlüssel mit weiterhin aktiven Berechtigungen
9	Secret-Scanning und Push-Schutz aktivieren	Dass Schlüssel in ein öffentliches oder gemeinsam genutztes Repository gelangen
10	Niemals Schlüssel oder Autorisierungsheader protokollieren; stattdessen eine Schlüssel-ID oder Version erfassen	Dass Secrets über Logs, Traces und Fehlerberichte offengelegt werden
11	Ausgabenlimits setzen und bei ungewöhnlicher Nutzung alarmieren	Unerwartete Rechnungen durch einen gestohlenen oder unkontrolliert genutzten Schlüssel
12	Ein Runbook für Vorfälle bereithalten, bei dem der Widerruf Priorität hat	Dass ein Schlüssel lange zugänglich bleibt, während Teams darüber diskutieren, ob das Leck ausgenutzt wurde

Der Rest dieses Leitfadens erklärt, wie Sie jede dieser Maßnahmen für KI-Workloads umsetzen. Dort dient ein Schlüssel nicht nur der Authentifizierung: Er autorisiert auch den Datenfluss für Prompts, Dokumente und Modellausgaben.

Der Lebenszyklus von API-Schlüsseln

OWASP empfiehlt, Secrets über ihren gesamten Lebenszyklus hinweg zu verwalten: Erstellung, Rotation, Widerruf und Ablauf, mit Auditierung bei jedem Schritt (OWASP-Cheat-Sheet zur Verwaltung von Secrets). Bei einem KI-API-Schlüssel sieht dieser Lebenszyklus so aus:

Phase	Aufgabe der Verantwortlichen	Aufzubewahrender Nachweis
Beantragen	Bedarf für Workload, Umgebung und benötigte Modelle begründen	Ticket oder Inventareintrag
Erstellen	In der Konsole oder API des Anbieters mit einem aussagekräftigen Namen generieren	Schlüssel-ID, Erstellungszeitpunkt, erstellende Person
Einschränken	Modelle, APIs, Netzwerke und Budget begrenzen	Konfigurierte Einschränkungen
Speichern	Direkt in einem Secrets Manager ablegen; niemals andernorts einfügen	Secret-Pfad und Zugriffsrichtlinie
Bereitstellen	Zur Laufzeit in den einen Workload injizieren, der ihn benötigt	Deployment-Zuordnung
Überwachen	Anfragen, Tokens, Ausgaben und Zeitpunkt der letzten Nutzung verfolgen	Nutzungsdashboard und Alarme
Rotieren	Ersatz erstellen, umstellen, überprüfen	Rotationsprotokoll
Widerrufen	Beim Anbieter ungültig machen und eine 401-Antwort bestätigen	Zeitpunkt des Widerrufs und Testergebnis

Die fünf Grenzen, die ein KI-Schlüssel überschreiten kann

Erfassen Sie zunächst, wohin ein Secret oder die dadurch zugänglichen Daten gelangen können. Die meisten Fehler entstehen, weil Teams den Anbieterschlüssel schützen, dabei aber eine dieser angrenzenden Grenzen übersehen.

Grenze	Typischer Fehler	Erforderliche Maßnahme
Vom Client zur Anwendung	Ein Anbieterschlüssel ist in ein Browser-Bundle, eine mobile Binärdatei, eine Desktop-App oder eine Erweiterung eingebettet	Anbieterschlüssel serverseitig halten; Clients kurzlebige Benutzer- oder Sitzungszugangsdaten ausstellen
Von der Anwendung zum Gateway	Alle Dienste teilen sich einen uneingeschränkten Schlüssel	Workload-Identitäten, Gateway-Tokens mit begrenztem Geltungsbereich, Kontingente und explizite Routing-Richtlinien verwenden
Vom Gateway zum Anbieter	Ein Zugangsschlüssel gewährt Zugriff auf sämtliche Modelle, Projekte oder Umgebungen	Schlüssel nach Anbieter, Umgebung, Workload und Risikostufe trennen, soweit unterstützt
Von der Anfrage ins Log	Autorisierungsheader, Prompts, Dateien oder Ausgaben erscheinen in Traces	Secret-Felder über eine Sperrliste ausschließen, Payload-Protokollierung minimieren, Identifikatoren tokenisieren und die Schwärzung testen
Menschliche Abläufe	Schlüssel werden in Tickets, Chats, Runbooks oder Support-Tools eingefügt	Kontrollierte Zugriffsabläufe, auditierte Abrufe, Notfallzugriffsverfahren und automatischen Ablauf nutzen

Diese Übersicht verschiebt die Entwurfsfrage von „Wo speichern wir den Schlüssel?“ zu „Welche Identität darf welche Anfrage mit welchen Daten über welche Route stellen, und welche Nachweise bleiben danach erhalten?“

Schlüssel serverseitig verwahren

Langlebige Zugangsdaten von Anbietern sollten nicht an Browser-, Mobil-, Desktop- oder Erweiterungsclients ausgeliefert werden. Gehen Sie davon aus, dass alles, was auf einem Endgerät landet, vom Nutzer oder von Schadsoftware mit denselben Berechtigungen ausgelesen werden kann.

Ein sichereres Muster sieht so aus:

1. Der Client authentifiziert sich gegenüber Ihrem Backend mit einer Benutzersitzung, Gerätezugangsdaten oder einem kurzlebigen Anwendungstoken.
2. Ihr Backend autorisiert die angeforderte Funktion und wendet Limits pro Nutzer oder Mandant an.
3. Ein Gateway oder eine serverseitige Integration wählt den freigegebenen Anbieter und das Modell aus.
4. Der Anbieterschlüssel wird zur Laufzeit abgerufen oder dem vertrauenswürdigen Workload über die Deployment-Plattform bereitgestellt.
5. Die Antwort des Anbieters durchläuft auf dem Rückweg dieselbe Richtliniengrenze.

Der Client benötigt das Secret des Anbieters zu keinem Zeitpunkt. Er erhält lediglich die Berechtigung, Ihr Produkt innerhalb der von Ihnen festgelegten Grenzen aufzurufen.

Wenden Sie bei Coding-Agenten und lokalen Entwicklertools dasselbe Prinzip mit bewusst geregelten Ausnahmen an. Entwickler benötigen möglicherweise lokale Zugangsdaten. Diese sollten jedoch für das Produkt oder Gateway gelten, widerrufbar sein, eine Zuordnung der Nutzung erlauben und einen begrenzten Geltungsbereich haben – kein gemeinsam genutzter, organisationsweiter Anbieterschlüssel, der unternehmensweit in Dotfiles kopiert wird.

Vor jeder Rotation ein Schlüsselinventar erstellen

Rotationsprojekte scheitern, wenn Teams nicht wissen, welcher Workload einen Schlüssel verwendet. Erstellen Sie ein maschinenlesbares Inventar und benennen Sie Verantwortliche, bevor Sie Zugangsdaten ändern.

Erfassen Sie mindestens:

Feld	Beispiel	Warum es wichtig ist
Secret-ID	prod-support-chat-anthropic-01	Stabile interne Referenz, die nicht den Secret-Wert enthält
Anbieter und Projekt	Anbieterkonto + Projektkennung	Definiert das externe Schadensausmaß
Umgebung	Entwicklung, Staging, Produktion	Verhindert, dass Testsysteme Produktionsberechtigungen erhalten
Workload	support-chat-api	Ermöglicht Zuordnung und gezielten Widerruf
Verantwortliche	Team und Rufbereitschaft	Schafft klare Zuständigkeiten bei Vorfällen
Speicherort	Pfad im Secrets Manager oder Deployment-Zuordnung	Zeigt, wo die maßgebliche Quelle liegt
Zulässige Modelle/Routen	Freigegebene Modellfamilie oder Gateway-Richtlinie	Begrenzt unerwartete Nutzung
Ausgaben- und Anfragelimits	Workload-Budget, RPM, TPM oder Begrenzung gleichzeitiger Anfragen	Begrenzt Missbrauch und unkontrollierte Automatisierung
Erstellt und zuletzt rotiert	Zeitstempel	Macht veraltete Zugangsdaten sichtbar
Rotationsmethode	Zwei Schlüssel, Versionsalias oder Wartungsfenster	Verhindert improvisierte Änderungen
Abhängigkeiten beim Widerruf	Dienste, die zuerst aktualisiert werden müssen	Schützt die Verfügbarkeit
Datenklassifizierung	Öffentlich, intern, vertraulich, reguliert	Verknüpft Schlüsselrichtlinien mit der Governance von Prompts

Tragen Sie den Schlüsselwert nicht in das Inventar ein. Speichern Sie dort nur Metadaten und eine Referenz auf das verwaltete Secret.

Identitäten nach Umgebung, Workload und Risiko trennen

Das häufigste Antipattern ist ein einziger Produktionsschlüssel, den alle Dienste gemeinsam verwenden. Das ist bequem, bis er über ein Repository, einen Test-Runner, das Notebook eines externen Mitarbeiters oder ein Supportprotokoll offengelegt wird. Dann kann das Team den Schlüssel nicht widerrufen, ohne andere Produkte zu beeinträchtigen.

Verwenden Sie vorzugsweise getrennte Identitäten für:

• Produktion, Staging, Entwicklung und lokale Tests.
• Kundenanfragen, interne Tools, Batchjobs und Evaluierungspipelines.
• Workflows mit hohem Risiko, die Tools aufrufen oder vertrauliche Daten verarbeiten können.
• Verschiedene Geschäftsbereiche oder Mandanten, wenn vertragliche Grenzen eine Trennung erfordern.
• Notfallzugriffe, die im Normalbetrieb deaktiviert oder streng kontrolliert bleiben sollten.

Nutzen Sie die Einschränkungen, die ein Anbieter bereitstellt. Dazu können zulässige APIs, Modelle, Quellnetzwerke, Projekte, Referrer, Anwendungen oder Kontingente gehören. Die Anleitung von Google Cloud zu API-Schlüsseln empfiehlt beispielsweise, Schlüssel einzuschränken und zu isolieren, nicht mehr benötigte Schlüssel zu löschen, sie nicht in Repositories einzuchecken und ihre Nutzung zu überwachen.

Bietet der Anbieter keine ausreichend feinen Kontrollen, setzen Sie diese an Ihrem eigenen Gateway durch. Ein zentrales Gateway kann den aufrufenden Workload validieren, ihm eine freigegebene Route zuordnen, Budgets und Ratenlimits anwenden und Anbieterzugangsdaten hinter einer zentralen, geprüften serverseitigen Grenze halten. Hinweise zum Entwurf von Routing und Failover finden Sie im umfassenderen Architekturleitfaden für KI-API-Gateways.

Die Governance von Prompts und Logs als Teil der Schlüsselverwaltung behandeln

Ein API-Schlüssel autorisiert einen Datenfluss. Wer den Schlüssel schützt, diesen Datenfluss aber nicht kontrolliert, lässt das zentrale KI-spezifische Risiko ungelöst.

Klassifizieren Sie vor dem Routing einer Anfrage die Nutzdaten und beschränken Sie sie auf das erforderliche Minimum:

• Entfernen Sie Zugangsdaten, Tokens, Cookies, private Schlüssel und Verbindungszeichenfolgen.
• Schließen Sie Felder aus, die das Modell nicht benötigt.
• Tokenisieren oder pseudonymisieren Sie direkte Identifikatoren, wenn die Aufgabe ohne sie lösbar ist.
• Weisen Sie regulierte oder vertraglich eingeschränkte Daten zurück, deren Verarbeitung nicht unterstützt wird.
• Trennen Sie Systemanweisungen von nicht vertrauenswürdigen Nutzerinhalten oder abgerufenen Inhalten.
• Validieren Sie Tool-Argumente, bevor ein Agent externe Systeme aufrufen kann.

Logs benötigen ein explizites Schema. Verlassen Sie sich nicht darauf, dass Entwickler daran denken, ein Anfrageobjekt nicht zu protokollieren. Legen Sie fest, welche Felder erlaubt sind, und verwerfen oder transformieren Sie alle anderen.

Ein nützlicher Ereigniseintrag im Produktivbetrieb kann Folgendes enthalten:

{
  "request_id": "req_01J...",
  "tenant_id_hash": "tnt_7f2...",
  "workload": "support-chat-api",
  "route_policy": "support-low-risk-v3",
  "provider": "selected-provider",
  "model": "selected-model",
  "input_tokens": 842,
  "output_tokens": 211,
  "latency_ms": 1370,
  "status": 200,
  "key_version": "v12",
  "redaction_policy": "customer-support-v4"
}

Standardmäßig sollte er weder den Autorisierungsheader noch den unveränderten Anbieterschlüssel, den vollständigen Prompt, das hochgeladene Dokument, ungeschwärzte Tool-Argumente oder die vollständige Modellausgabe enthalten. Falls für eine streng kontrollierte Evaluierung oder einen Vorfall Nutzdaten erfasst werden müssen, begrenzen Sie dies zeitlich, kontrollieren Sie den Zugriff und trennen Sie diese Erfassung klar von der routinemäßigen Telemetrie.

Das OWASP-Cheat-Sheet zur Protokollierung bietet eine hilfreiche Grundlage, um Zugriffstokens, Passwörter, Verschlüsselungsschlüssel und andere sensible Daten aus Anwendungslogs auszuschließen.

API-Schlüsselrotation ohne Ausfallzeiten planen

Rotation ist nur dann eine wirksame Schutzmaßnahme, wenn sie sicher durchgeführt werden kann. Ein Runbook, das einen Ausfall verursacht, wird bis zum Notfall aufgeschoben.

Verwenden Sie einen Ablauf mit zwei Schlüsseln oder versionierten Secrets, wenn der Anbieter gleichzeitig gültige Zugangsdaten unterstützt:

1. Einen neuen Anbieterschlüssel erstellen. Wenden Sie dieselben oder engere Einschränkungen als beim alten Schlüssel an.
2. Als neue Secret-Version speichern. Überschreiben Sie den alten Wert nicht direkt, wenn Ihre Plattform Versionen oder Aliase unterstützt.
3. Komponenten bereitstellen, die die neue Version einlesen. Aktualisieren Sie das Gateway oder die Workloads so, dass sie den aktuellen Alias oder die aktuelle Version auflösen.
4. Datenverkehr umstellen und beobachten. Prüfen Sie anhand der neuen Schlüsselversion erfolgreiche Anfragen, die erwarteten Modelle, Ausgaben, Ratenlimits und Fehlerraten.
5. Verbleibende Nutzer des alten Schlüssels umstellen. Prüfen Sie Deployment-Inventare, Jobs, Worker und Disaster-Recovery-Umgebungen.
6. Den alten Schlüssel widerrufen. Verwenden Sie ihn nicht einfach nur nicht mehr, sondern machen Sie ihn beim Anbieter ungültig.
7. Die Zurückweisung überprüfen. Ein kontrollierter Test sollte bestätigen, dass die alten Zugangsdaten nicht mehr funktionieren.
8. Nachweise dokumentieren. Halten Sie Zeitstempel, Verantwortliche, betroffene Workloads, Validierungsergebnisse und den nächsten Prüftermin fest.

Unterstützt ein System die Auswahl der Schlüsselversion, sollte die Anwendung einen stabilen Alias referenzieren, statt eine Secret-Version fest im Code zu hinterlegen:

type ProviderCredential = {
  value: string;
  version: string;
};

async function loadProviderCredential(): Promise<ProviderCredential> {
  const activeVersion = await secretStore.resolveAlias("ai/provider/active");
  const value = await secretStore.readVersion("ai/provider", activeVersion);

  return { value, version: activeVersion };
}

Geben Sie value nicht aus, serialisieren Sie das zurückgegebene Objekt nicht und hängen Sie es nicht an einen Fehler an. Protokollieren Sie nur die nicht geheime Versionskennung.

Das OWASP-Cheat-Sheet zur Verwaltung von Secrets empfiehlt, den gesamten Lebenszyklus eines Secrets zu planen, einschließlich Erstellung, Rotation, Widerruf, Ablauf, Auditierung, Sicherung und Notfallzugriff. Außerdem betont es, dass die Rotation nach Möglichkeit automatisiert werden sollte.

Verhindern, dass Secrets in Repositories und CI-Logs gelangen

Secrets Manager helfen nicht mehr, sobald Zugangsdaten in Quellcode, eine Test-Fixture, ein Build-Artefakt oder ein CI-Protokoll kopiert wurden.

Setzen Sie Schutzmaßnahmen in drei Phasen ein:

Vor dem Commit

• Stellen Sie .env.example-Dateien mit Platzhaltern bereit, niemals mit gültigen Zugangsdaten.
• Halten Sie lokale Secret-Dateien außerhalb der Versionskontrolle.
• Führen Sie in Pre-Commit-Hooks einen schnellen Secret-Scanner aus, der gängige Anbietermuster und Werte mit hoher Entropie erkennt.
• Vermitteln Sie Entwicklern, dass das Löschen eines Secrets in einem späteren Commit es nicht aus der Historie entfernt.

Beim Push und Pull Request

• Aktivieren Sie Secret-Scanning und Push-Schutz für Repositories, soweit verfügbar.
• Ergänzen Sie eigene Muster für interne Gateway-Tokens, die öffentliche Scanner nicht erkennen.
• Verlangen Sie bei Umgehungen eine dokumentierte Begründung und leiten Sie diese zur Sicherheitsprüfung weiter.
• Scannen Sie generierte Dateien, Notebooks, Test-Snapshots und Infrastrukturpläne ebenso wie den Anwendungsquellcode.

GitHub beschreibt den Push-Schutz als Möglichkeit, während des Push-Vorgangs zu scannen und erkannte Secrets zu blockieren, bevor sie in ein Repository gelangen. Die Erkennung ist kein Grund, den Schlüssel beizubehalten: Behandeln Sie alle nachweislich eingecheckten Zugangsdaten als offengelegt und rotieren Sie sie.

Während CI/CD

• Bevorzugen Sie Workload-Identitäten oder kurzlebige Föderation gegenüber gespeicherten Cloud-Zugangsdaten.
• Stellen Sie ein Secret nur dem Job und Schritt bereit, der es benötigt.
• Maskieren Sie bekannte Secret-Werte, verlassen Sie sich aber nicht auf die Maskierung als primäre Schutzmaßnahme.
• Deaktivieren Sie Shell-Tracing beim Abrufen von Secrets.
• Verhindern Sie, dass nicht vertrauenswürdiger Code aus Forks auf Deployment-Secrets zugreift.
• Prüfen Sie Artefakte, Caches, Speicherabbilder nach Abstürzen und Testberichte auf versehentlich erfasste Secrets.

Die Nutzung überwachen, ohne das Secret zu protokollieren

Gutes Monitoring beantwortet die Frage „Wer hat welche Berechtigung genutzt?“, ohne die Zugangsdaten selbst aufzuzeichnen.

Erfassen Sie:

• Workload, Umgebung, Mandant oder Projekt sowie Schlüsselversion.
• Anbieter, Modell, Routing-Richtlinie und Fallback-Pfad.
• Anzahl der Anfragen, Token-Volumen, Ausgaben, Latenz und Fehlerklasse.
• Quellnetzwerk oder Deployment-Identität, sofern hilfreich.
• Zugriffe auf den Secrets Manager, einschließlich verweigerter Lesezugriffe.
• Erstellung von Schlüsseln, Änderungen an Einschränkungen, Rotation, Widerruf und Löschung.
• Plötzliche Nutzung aus einer unerwarteten Umgebung oder Region, mit einem unerwarteten Modell oder in einem unerwarteten Zeitfenster.

Richten Sie Alarme am Verhalten aus, nicht nur an den Gesamtausgaben. Auch ein gestohlener Schlüssel mit geringem Budget kann Prompts offenlegen oder zum Auskundschaften interner Workflows dienen. Umgekehrt kann ein legitimer Batchjob eine Ausgabenspitze verursachen, ohne dass Zugangsdaten kompromittiert wurden. Korrelieren Sie die Anbieternutzung mit Anfrage-IDs der Anwendung, Richtlinienentscheidungen des Gateways, Deployment-Ereignissen und Audit-Logs des Secrets Managers.

Für die Steuerung des Datenverkehrs als Ergänzung zur Kontrolle von Zugangsdaten nutzen Sie den Leitfaden zu LLM-Ratenlimits und das Playbook für Fallback-Routing bei LLM-APIs.

Die Zeit von der Offenlegung bis zum Widerruf messen

Wenn ein Schlüssel möglicherweise offengelegt wurde, hat die Eindämmung Vorrang vor dem Nachweis, ob ein Angreifer ihn genutzt hat.

Gehen Sie in dieser Reihenfolge vor:

1. Die Zugangsdaten als verdächtig einstufen. Halten Sie fest, wann und wo sie möglicherweise offengelegt wurden.
2. Über den regulären, kontrollierten Weg Ersatz erstellen. Fügen Sie keinen neuen Schlüssel in einen Chat ein, um die Bearbeitung des Vorfalls zu beschleunigen.
3. Legitime Workloads auf den Ersatz umstellen. Nutzen Sie das vorbereitete Rotationsverfahren.
4. Den verdächtigen Schlüssel widerrufen. Würde ein sofortiger Widerruf unvertretbare Schäden verursachen, isolieren Sie Routen und senken Sie Limits, während Sie die Umstellung abschließen.
5. Alle möglichen Speicherorte von Kopien durchsuchen. Prüfen Sie Quellcodehistorie, CI-Logs, Artefakte, Container-Layer, Supportsysteme, Dashboards, Notebooks, lokale Konfiguration und Backups.
6. Autorisierte Datenflüsse prüfen. Ermitteln Sie, auf welche Prompts, Ausgaben, Dateien, Tools oder Modelle der Schlüssel zugreifen konnte; betrachten Sie nicht nur seinen Abrechnungsumfang.
7. Aktivitäten korrelieren. Vergleichen Sie Anbieternutzung, Gateway-Logs, Deployments, Secret-Abrufe und Nutzeraktivitäten.
8. Die zuständigen Verantwortlichen informieren. Beziehen Sie je nach betroffenen Daten und Verträgen die Teams für Sicherheit, Plattform, Recht, Datenschutz und Kundenbetreuung ein.
9. Die Ursache beseitigen. Ergänzen Sie den fehlenden Scanner, die Einschränkung, die Identitätsgrenze oder den Log-Filter.
10. Die Zeit messen. Dokumentieren Sie die Zeit bis zur Erkennung, Ersetzung, Umstellung des Datenverkehrs, zum Widerruf und zur Überprüfung.

Die oft nützlichste Kennzahl ist die Zeit von der Offenlegung bis zum Widerruf: wie lange verdächtige Zugangsdaten nutzbar bleiben, nachdem der Organisation belastbare Hinweise auf ihre Offenlegung vorliegen. Um diese Zeitspanne zu verkürzen, braucht es vorab geklärte Zuständigkeiten, ein Inventar, Automatisierung und erprobte Rotation – kein längeres Richtliniendokument.

Wenn Sie API-Schlüssel an Ihre eigenen Kunden ausgeben

Viele KI-Produkte geben auch selbst Schlüssel aus, etwa damit Kunden Ihren Agenten aufrufen oder Ihre Funktion einbetten können. Dieselben Best Practices gelten in umgekehrter Richtung:

• Generieren Sie Schlüssel mit einem kryptografisch sicheren Zufallszahlengenerator, mit mindestens 32 Bytes Entropie.
• Fügen Sie ein erkennbares Präfix hinzu (wie sk-fk- bei Flatkey-Schlüsseln), damit Secret-Scanner und Ihr Supportteam offengelegte Schlüssel identifizieren können. Das Partnerprogramm von GitHub nutzt bekannte Token-Formate, um Aussteller zu benachrichtigen, wenn ein Schlüssel in ein öffentliches Repository gepusht wird (GitHub-Secret-Scanning).
• Zeigen Sie den vollständigen Schlüssel genau einmal an und speichern Sie anschließend nur einen Hash. Wird Ihre Datenbank offengelegt, bleiben die Schlüssel sicher.
• Zeigen Sie im Dashboard nur ein maskiertes Präfix an, ergänzt um das Erstellungsdatum und den Zeitpunkt der letzten Nutzung.
• Lassen Sie den Widerruf sofort wirksam werden und geben Sie für widerrufene Schlüssel 401 zurück.
• Ermöglichen Sie Kunden, Schlüssel einzuschränken, etwa auf bestimmte Modelle, Projekte oder Ausgabenlimits.

Python: Schlüssel generieren, hashen und überprüfen

import hashlib
import hmac
import secrets

PREFIX = "sk-acme-"

def new_api_key() -> tuple[str, str]:
    """Return (plaintext key shown to the user once, hash to store)."""
    key = PREFIX + secrets.token_urlsafe(32)  # 32 random bytes
    return key, hashlib.sha256(key.encode()).hexdigest()

def verify(presented: str, stored_hash: str) -> bool:
    candidate = hashlib.sha256(presented.encode()).hexdigest()
    return hmac.compare_digest(candidate, stored_hash)  # constant-time compare

key, digest = new_api_key()
print(key[:12] + "...")   # show the full key once in the UI, never log it
print(verify(key, digest))  # True

Ein schneller Hash wie SHA-256 ist hier akzeptabel, weil der Schlüssel im Gegensatz zu einem menschlichen Passwort lang und zufällig ist. Speichern Sie den Hash, eine Schlüssel-ID, den Eigentümer, den Berechtigungsumfang und Zeitstempel.

Node.js: Einen Schlüssel aus der Umgebung laden und bei Fehlern den Zugriff verweigern

// Never fall back to a hardcoded default key.
const apiKey = process.env.FLATKEY_API_KEY;
if (!apiKey || !apiKey.startsWith("sk-fk-")) {
  throw new Error("FLATKEY_API_KEY is missing or malformed");
}

const res = await fetch("https://router.flatkey.ai/v1/chat/completions", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "claude-haiku-5-5",
    messages: [{ role: "user", content: "ping" }],
    max_tokens: 5,
  }),
});
console.log(res.status); // log the status, never the header

Überprüfen, ob ein widerrufener Schlüssel wirklich unbrauchbar ist

Ein Widerruf ist erst nachgewiesen, wenn der alte Schlüssel fehlschlägt. Führen Sie nach jeder Rotation oder jedem Vorfall von einem vertrauenswürdigen Rechner aus eine Prüfung wie diese durch:

# Expect 401 for the revoked key; do not echo the key itself
OLD_KEY="$(cat /run/secrets/old_flatkey_key)"
status=$(curl -s -o /dev/null -w "%{http_code}" \
  https://router.flatkey.ai/v1/models \
  -H "Authorization: Bearer $OLD_KEY")
if [ "$status" = "401" ]; then echo "revoked OK"; else echo "STILL ACTIVE: $status"; fi

Halten Sie Ergebnis und Zeitpunkt im Rotationsprotokoll fest. Laut Flatkey-Dokumentation ist der Widerruf sofort wirksam, und jede Anfrage mit einem widerrufenen Schlüssel erhält ohne Übergangsfrist 401 Unauthorized (Flatkey-Dokumentation zu API-Schlüsseln).

Wie Flatkey diese Best Practices unterstützt

Flatkey bietet einen OpenAI-kompatiblen Endpunkt (https://router.flatkey.ai/v1) für viele Modellanbieter. Dadurch sind weniger Anbieterschlüssel über Ihre Dienste verteilt. Laut der Flatkey-Dokumentation zu API-Schlüsseln (geprüft am 27. Oktober 2026):

• Sie können mehrere Schlüssel erstellen: einen pro Umgebung, Anwendung oder Teammitglied, mit aussagekräftigen Namen wie prod-customer-chatbot.
• Der vollständige sk-fk--Schlüssel wird nur einmal angezeigt. Danach führt die Schlüsselseite den Namen, das Erstellungsdatum, den Zeitpunkt der letzten Nutzung und ein maskiertes Präfix auf.
• Der Widerruf ist sofort wirksam. Stellen Sie daher den Ersatzschlüssel bereit, bevor Sie den alten widerrufen.
• Alle Schlüssel teilen sich das Kontoguthaben und können standardmäßig auf alle Modelle zugreifen. Nutzen Sie Groups in der Konsole, um einen Schlüssel auf bestimmte Modelle einzuschränken oder ein Ausgabenkontingent festzulegen.

Die Dokumentation zur Nutzung beschreibt Protokolle für einzelne Anfragen mit Modell, Tokens, Kosten und Schlüssel sowie eine monatliche Ausgabenobergrenze und E-Mail-Warnungen bei niedrigem Guthaben. Damit werden die Maßnahmen 10 und 11 abgedeckt. Für größere Organisationen beschreibt die Flatkey-Enterprise-Dokumentation baumförmig organisierte Unterschlüssel mit eigenen Budgets und Listen zulässiger Modelle. Ein Gateway ersetzt weder Ihre eigene Client-Authentifizierung noch Datenklassifizierung und sorgfältige Protokollierung. Behalten Sie daher die übrigen Maßnahmen dieser Checkliste bei. Den Einstieg erleichtert der Flatkey-Integrationsleitfaden.

Referenzarchitektur für KI-Produkte mit mehreren Anbietern

Ein sicherer Aufbau mit mehreren Anbietern lässt sich in fünf Schichten gliedern:

1. Client-Identitätsschicht: Authentifiziert Nutzer, Gerät, Agent oder Anwendung, ohne Anbieterzugangsdaten offenzulegen.
2. Autorisierungsschicht der Anwendung: Prüft Produktberechtigungen, Mandantengrenzen, Funktionszugriff und Budgets.
3. Datenrichtlinienschicht: Klassifiziert und schwärzt Prompts, Dateien, abgerufenen Kontext und Tool-Argumente.
4. Gateway- und Routing-Schicht: Wählt freigegebene Modelle aus, wendet Kontingente an, protokolliert die Zuordnung ohne Secrets und übernimmt das Failover.
5. Schicht für Anbieterzugangsdaten: Speichert voneinander isolierte Anbieterzugangsdaten, rotiert Versionen und stellt sie nur dem vertrauenswürdigen Routing-Workload bereit.

Dieses Design begrenzt das Schadensausmaß. Ein kompromittiertes Client-Token legt nicht automatisch einen Anbieterschlüssel offen. Eine kompromittierte Workload-Identität sollte keinen Zugriff auf sämtliche Anbieter ermöglichen. Offengelegte Anbieterzugangsdaten sollten nicht jede Umgebung autorisieren. Ein Fehler in der Protokollierung sollte nicht zugleich das Secret und die vollständigen Nutzdaten offenlegen.

Checkliste für den Produktivbetrieb

Nutzen Sie diese Checkliste vor dem Start und bei vierteljährlichen Prüfungen der Schutzmaßnahmen.

Verwahrung und Identität

• [ ] Kein langlebiger Anbieterschlüssel wird im Code für Browser, Mobilgeräte, Desktop oder Erweiterungen ausgeliefert.
• [ ] Jeder Produktionsworkload hat klar benannte Verantwortliche und einen nachvollziehbaren Bereitstellungsweg für Zugangsdaten.
• [ ] Zugriffe für Produktion, Staging, Entwicklung, Evaluierung und lokale Nutzung sind getrennt.
• [ ] Gemeinsam genutzte persönliche Schlüssel wurden nach Möglichkeit durch Workload- oder Gateway-Identitäten ersetzt.
• [ ] Anbieter- und Gateway-Einschränkungen sind auf den engsten praktikablen Berechtigungsumfang eingestellt.

Speicherung und Bereitstellung

• [ ] Die maßgebliche Quelle ist ein verwalteter Secret-Speicher oder eine kontrollierte Deployment-Zuordnung.
• [ ] Anwendungen rufen Secrets nur zur Laufzeit ab und geben sie weder aus noch serialisieren sie sie.
• [ ] CI-Jobs erhalten nur die Secrets, die für den jeweiligen Schritt erforderlich sind.
• [ ] Secret-Zugriffe und administrative Änderungen werden auditiert.
• [ ] Notfallzugriffe sind dokumentiert, zeitlich begrenzt und getestet.

Daten und Beobachtbarkeit

• [ ] Autorisierungsheader und Schlüsselwerte sind aus Logs, Traces, Fehlermeldungen und Supportexporten ausgeschlossen.
• [ ] Die Protokollierung von Prompts, Ausgaben, Dateien und Tool-Argumenten folgt einem Schema mit explizit erlaubten Feldern.
• [ ] Die Schwärzung erfolgt vor dem Routing an mehrere Anbieter.
• [ ] Die Nutzung lässt sich Workload, Umgebung, Route, Anbieter, Modell und Schlüsselversion zuordnen.
• [ ] Alarme erfassen neben Ausgaben auch ungewöhnliche Routen und Identitäten.

Rotation und Reaktion

• [ ] Ein erprobtes Rotations-Runbook mit zwei Schlüsseln oder versionierten Secrets ist vorhanden.
• [ ] Alte Schlüssel werden beim Anbieter widerrufen und nachweislich unbrauchbar gemacht.
• [ ] Secret-Scanning und Push-Schutz decken Repositories und generierte Artefakte ab.
• [ ] Ein vermutetes Leck löst sofortige Eindämmungsmaßnahmen aus, ohne auf einen Missbrauchsnachweis zu warten.
• [ ] Die Zeit von der Offenlegung bis zum Widerruf wird nach Übungen und Vorfällen gemessen.

FAQ

Was sind die Best Practices für die Verwaltung von API-Schlüsseln?

Halten Sie Schlüssel aus Quellcode und Client-Apps heraus, verwenden Sie pro Umgebung und Workload einen eigenen Schlüssel, beschränken Sie jeden Schlüssel auf die benötigten APIs, Modelle und Budgets, speichern Sie Schlüssel in einem Secrets Manager, rotieren Sie sie nach einem erprobten Zeitplan, löschen Sie ungenutzte Schlüssel, aktivieren Sie Secret-Scanning, protokollieren Sie niemals Schlüssel und widerrufen Sie sie bei Verdacht auf ein Leck sofort.

Sollte ein API-Schlüssel in einer Umgebungsvariablen gespeichert werden?

Umgebungsvariablen sind ein sinnvoller Weg, einem Prozess einen Schlüssel bereitzustellen, aber kein Verwaltungssystem. Der Wert sollte aus einem Secrets Manager oder der Secret-Injektion Ihrer Plattform stammen, mit Zugriffskontrolle, Rotation und Auditierung. Checken Sie niemals .env-Dateien ein.

Wie häufig sollten API-Schlüssel rotiert werden?

Wählen Sie ein Intervall anhand des Risikos und der Kontrollmöglichkeiten Ihres Anbieters. Viele Teams rotieren KI-Produktionsschlüssel alle 90 Tage und sofort bei personellen Veränderungen oder vermuteter Offenlegung. Entscheidend ist, dass die Rotation geübt wird, der alte Schlüssel widerrufen und der Widerruf überprüft wird.

Kann eine Browser- oder mobile App einen KI-Anbieter mit einem API-Schlüssel direkt aufrufen?

Vermeiden Sie das. Alles, was auf ein Gerät ausgeliefert wird, kann ausgelesen werden. Lassen Sie den Client sich gegenüber Ihrem Backend authentifizieren und das Backend oder Gateway das Modell mit einem serverseitigen Schlüssel und Limits pro Nutzer aufrufen.

Was sollte ich tun, wenn ein API-Schlüssel auf GitHub offengelegt wird?

Behandeln Sie ihn als kompromittiert. Erstellen Sie Ersatz, stellen Sie die Workloads darauf um, widerrufen Sie den offengelegten Schlüssel, bestätigen Sie, dass er 401 zurückgibt, prüfen Sie die Nutzung während des Offenlegungszeitraums und ergänzen Sie Scanning oder Push-Schutz, damit sich der Vorfall nicht wiederholt. Das Löschen des Commits macht den Schlüssel nicht wieder sicher.

Ist ein einziger Gateway-Schlüssel sicherer als viele Anbieterschlüssel?

Er reduziert die Anzahl der Secrets in Ihrem Code, bündelt aber Berechtigungen. Verwenden Sie pro Umgebung und Workload eigene Gateway-Schlüssel, begrenzen Sie diese durch Modell- und Ausgabenlimits und schützen Sie die Anbieterschlüssel hinter dem Gateway genauso sorgfältig wie zuvor.

Wie sollte ich API-Schlüssel speichern, die ich meinen eigenen Nutzern ausstelle?

Speichern Sie von jedem Schlüssel nur einen Hash, zeigen Sie den vollständigen Schlüssel bei der Erstellung einmal an, danach nur noch ein maskiertes Präfix, und ermöglichen Sie den sofortigen Widerruf.

Quellen und weiterführende Literatur

• OWASP-Cheat-Sheet zur Verwaltung von Secrets
• OWASP-Cheat-Sheet zur Protokollierung
• GitHub: Informationen zum Secret-Scanning
• GitHub: Informationen zum Push-Schutz
• Google Cloud: Best Practices für die Verwaltung von API-Schlüsseln
• Flatkey: API-Schlüssel erstellen und verwalten

Weitere Flatkey-Leitfäden: Richtlinie zur Schwärzung von KI-API-Daten, Architektur von KI-API-Gateways und LLM-Ratenlimits erklärt.