Sicheres API-Schlüssel-Management für KI-Produkte

Sicheres API-Schlüssel-Management für KI-Produkte ist nicht einfach nur eine Frage davon, einen Provider-Credential in einem Tresor abzulegen. KI-Anwendungen senden Prompts, Dateien, abgerufenen Kontext, Tool-Argumente und Modellausgaben durch Systeme, die sich oft über mehrere Anbieter und Umgebungen erstrecken. Ein Schlüssel kann im Ruhezustand perfekt verschlüsselt sein, während der umgebende Request-Pfad dennoch sensible Daten über Browser-Bundles, Debug-Logs, CI-Ausgaben, Support-Exporte oder einen überberechtigten Routing-Service offenlegt.

Das praktische Ziel ist daher breiter gefasst: lange gültige Provider-Keys von nicht vertrauenswürdigen Clients fernhalten, jeder Workload die kleinstmögliche nützliche Identität geben, kontrollieren, welche Daten jede Modellgrenze überschreiten dürfen, und Rotation und Widerruf zur Routine machen statt sie als Störung zu behandeln.

Dieser Leitfaden bietet Plattform-, Security- und KI-Produktteams ein Betriebsmodell, das sie umsetzen können. Er enthält ein Threat Model, eine Vorlage für das Key-Inventar, eine Control-Plane-Architektur, ein Runbook für Rotation ohne Ausfallzeit, Logging-Regeln, CI/CD-Sicherheitsmaßnahmen, einen Incident-Response-Workflow und eine Produktions-Checkliste.

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

Beginnen Sie damit, die Stellen zu erfassen, an denen ein Secret oder die Daten, die es autorisiert, sich bewegen können. Die meisten Fehler entstehen, weil Teams den Provider-Schlüssel schützen, aber eine dieser angrenzenden Grenzen übersehen.

Diese Grenzkarte verlagert die Designfrage von „Wo speichern wir den Schlüssel?“ zu „Welche Identität darf welche Anfrage mit welchen Daten über welchen Pfad stellen, und welche Nachweise bleiben danach übrig?“

Verwenden Sie ein serverseitiges Schlüsselverwahrungsmodell

Langfristige Provider-Credentials sollten nicht an Browser-, Mobile-, Desktop- oder Extension-Clients ausgeliefert werden. Alles, was an ein Endgeräte-Client geliefert wird, ist so zu behandeln, als könne es vom Nutzer oder von Malware mit denselben Rechten wiederhergestellt werden.

Ein sichereres Muster ist:

1. Der Client authentifiziert sich bei Ihrem Backend mithilfe einer Benutzersitzung, eines Geräteanmeldedatensatzes oder eines kurzlebigen Anwendungstokens.
2. Ihr Backend autorisiert die angeforderte Funktion und wendet pro Benutzer oder pro Mandant Grenzen an.
3. Ein Gateway oder eine serverseitige Integration wählt den freigegebenen Anbieter und das Modell aus.
4. Der Anbieter-Schlüssel wird zur Laufzeit abgerufen oder der vertrauenswürdigen Workload über die Bereitstellungsplattform zur Verfügung gestellt.
5. Die Antwort des Anbieters wird durch dieselbe Richtliniengrenze zurückgegeben.

Der Client benötigt das Anbietergeheimnis nie. Er erhält nur die Befugnis, Ihr Produkt innerhalb der von Ihnen definierten Grenzen aufzurufen.

Für Coding-Agenten und lokale Entwicklerwerkzeuge gilt das gleiche Prinzip mit einem bewussten Ausnahmemodell. Ein Entwickler benötigt möglicherweise einen lokalen Anmeldedatensatz, aber es sollte sich um einen Produkt- oder Gateway-Anmeldedatensatz mit Widerrufsmöglichkeit, Nutzungszuordnung und begrenztem Umfang handeln – nicht um einen gemeinsam genutzten, unternehmensweiten Anbieter-Schlüssel, der in Dotfiles im gesamten Unternehmen kopiert wird.

Erstellen Sie ein Schlüsselinventar, bevor Sie irgendetwas rotieren

Rotationsprojekte scheitern, wenn Teams nicht wissen, welche Workload einen Schlüssel verwendet. Erstellen Sie vor dem Ändern von Anmeldedaten ein maschinenlesbares Inventar und weisen Sie einen Verantwortlichen zu.

Erfassen Sie mindestens:

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

Trennen Sie Identitäten nach Umgebung, Workload und Risiko

Das häufigste Anti-Pattern ist ein einziger Produktionsschlüssel, der von jedem Dienst gemeinsam genutzt wird. Das ist bequem, bis ein Repository, ein Test-Runner, ein Contractor-Laptop oder ein Support-Transkript ihn preisgibt. Dann kann das Team den Schlüssel nicht widerrufen, ohne nicht verwandte Produkte zu stören.

Bevorzugen Sie separate Identitäten für:

• Produktion, Staging, Entwicklung und lokales Testen.
• Traffic für Kunden, interne Tools, Batch-Jobs und Evaluierungs-Pipelines.
• Hochriskante Workflows, die Tools aufrufen oder vertrauliche Daten verarbeiten können.
• Verschiedene Geschäftsbereiche oder Mandanten, wenn vertragliche Grenzen eine Trennung erfordern.
• Notfall- oder Break-Glass-Zugriff, der im Normalbetrieb deaktiviert bleiben oder streng kontrolliert werden sollte.

Wenn ein Anbieter Einschränkungen bietet, sollten Sie diese anwenden. Zu den Einschränkungen können zulässige APIs, Modelle, Quellnetzwerke, Projekte, Referrer, Anwendungen oder Quoten gehören. Die API-Schlüssel-Richtlinien von Google Cloud empfehlen beispielsweise, Schlüssel einzuschränken, zu isolieren, nicht benötigte Schlüssel zu löschen, Repository-Commits zu vermeiden und ihre Nutzung zu überwachen.

Bietet der Anbieter keine ausreichend granulare Steuerung, setzen Sie diese an Ihrem eigenen Gateway durch. Ein zentrales Gateway kann die aufrufende Workload validieren, sie einer freigegebenen Route zuordnen, Budgets und Rate Limits anwenden und Anbieter-Anmeldedaten hinter einer geprüften serverseitigen Grenze halten. Lesen Sie den umfassenderen Leitfaden zur Architektur von AI API-Gateways für Routing- und Failover-Design.

Behandeln Sie Prompt- und Log-Governance als Teil des Schlüsselmanagements

Ein API-Schlüssel autorisiert einen Datenpfad. Den Schlüssel zu schützen, ohne diesen Pfad zu kontrollieren, lässt das zentrale KI-spezifische Risiko ungelöst.

Bevor Sie eine Anfrage weiterleiten, klassifizieren Sie die Nutzlast und wenden Sie das Prinzip der minimalen Erforderlichkeit an:

• Entfernen Sie Anmeldedaten, 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 auch ohne sie funktionieren kann.
• Lehnen Sie nicht unterstützte regulierte oder vertraglich eingeschränkte Daten ab.
• Trennen Sie Systemanweisungen von nicht vertrauenswürdigen Benutzer- 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 sich daran erinnern, kein Request-Objekt zu protokollieren. Definieren Sie, welche Felder zulässig sind, und verwerfen oder transformieren Sie dann alles andere.

Ein nützliches Produktionsevent 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"
}

Es sollte standardmäßig nicht den Authorization-Header, den Rohschlüssel des Anbieters, den vollständigen Prompt, das hochgeladene Dokument, unredigierte Tool-Argumente oder die vollständige Modellausgabe enthalten. Wenn eine Erfassung der Nutzlast für eine streng kontrollierte Evaluierung oder einen Vorfall notwendig ist, machen Sie sie zeitlich begrenzt, zugriffskontrolliert und sichtbar getrennt von der regulären Telemetrie.

Das OWASP Logging Cheat Sheet bietet eine nützliche Grundlage dafür, Zugriffstokens, Passwörter, Verschlüsselungsschlüssel und andere sensible Daten aus Anwendungsprotokollen auszuschließen.

API-Schlüsselrotation ohne Ausfallzeiten entwerfen

Rotation ist nur dann eine Kontrolle, wenn sie sicher durchgeführt werden kann. Ein Runbook, das einen Ausfall verursacht, wird bis zu einem Notfall aufgeschoben.

Verwenden Sie eine Dual-Key- oder versionierte Secret-Sequenz, wenn der Anbieter überlappende Anmeldedaten unterstützt:

1. Erstellen Sie einen neuen Anbieter-Schlüssel. Wenden Sie dieselben oder engere Einschränkungen an wie beim alten Schlüssel.
2. Speichern Sie ihn als neue Secret-Version. Überschreiben Sie den alten Wert nicht an Ort und Stelle, wenn Ihre Plattform Versionen oder Aliase unterstützt.
3. Bereitstellen von Readern, die die neue Version akzeptieren. Aktualisieren Sie das Gateway oder die Workloads so, dass sie den aktuellen Alias oder die aktuelle Version auflösen.
4. Verkehr umschalten und beobachten. Bestätigen Sie erfolgreiche Anfragen, erwartete Modelle, Ausgaben, Rate-Limits und Fehlerraten unter Verwendung der neuen Schlüsselversion.
5. Alte Consumer entfernen. Prüfen Sie Bereitstellungsinventare, Jobs, Worker und Disaster-Recovery-Umgebungen.
6. Den alten Schlüssel widerrufen. Hören Sie nicht nur auf, ihn zu verwenden; machen Sie ihn beim Anbieter ungültig.
7. Ablehnung verifizieren. Ein kontrollierter Test sollte bestätigen, dass die alte Anmeldedaten nicht mehr funktionieren.
8. Nachweise dokumentieren. Speichern Sie Zeitstempel, Verantwortliche, betroffene Workloads, Validierungsergebnisse und das Datum der nächsten Überprüfung.

Für ein System, das die Auswahl von Schlüsselversionen unterstützt, sollte die Anwendung auf einen stabilen Alias verweisen, statt eine Secret-Version fest zu codieren:

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 den nicht geheimen Versionsbezeichner.

Das OWASP Secrets Management Cheat Sheet empfiehlt, den gesamten Secret-Lebenszyklus zu planen, einschließlich Erstellung, Rotation, Widerruf, Ablauf, Auditierung, Sicherung und Break-Glass-Zugriff. Es betont außerdem, die Rotation nach Möglichkeit zu automatisieren.

Verhindern Sie, dass Secrets in Repositories und CI-Logs gelangen

Secret-Manager helfen nicht mehr, nachdem eine Anmeldedaten in Quellcode, ein Fixture, ein Build-Artefakt oder ein CI-Transkript kopiert wurde.

Verwenden Sie Kontrollen in drei Phasen:

Vor dem Commit

• Stellen Sie .env.example-Dateien mit Platzhaltern bereit, niemals mit funktionierenden Anmeldedaten.
• Bewahren Sie lokale Secret-Dateien außerhalb der Versionskontrolle auf.
• Führen Sie in Pre-Commit-Hooks einen schnellen Secret-Scanner für gängige Anbieter-Muster und hochentropische Werte aus.
• Vermitteln Sie Entwicklern, dass das Löschen eines Secrets in einem späteren Commit es nicht aus dem Verlauf entfernt.

Beim Push und Pull Request

• Aktivieren Sie Repository-Secret-Scanning und Push-Schutz, sofern verfügbar.
• Fügen Sie benutzerdefinierte Muster für interne Gateway-Tokens hinzu, die öffentliche Scanner nicht erkennen.
• Verlangen Sie einen dokumentierten Umgehungsgrund und leiten Sie Umgehungen an die Sicherheitsprüfung weiter.
• Scannen Sie generierte Dateien, Notebooks, Testsnapshots und Infrastrukturpläne — nicht nur den Anwendungscode.

GitHub dokumentiert Push-Schutz als Möglichkeit, den Push-Vorgang zu scannen und erkannte Secrets zu blockieren, bevor sie in ein Repository gelangen. Die Erkennung ist kein Grund, den Schlüssel zu behalten: Behandeln Sie jede bestätigte, eingecheckte Anmeldedaten als offengelegt und rotieren Sie sie.

Während CI/CD

• Bevorzugen Sie Workload Identity oder kurzlebige Föderation gegenüber gespeicherten Cloud-Anmeldedaten.
• Stellen Sie ein Secret nur dem Job und dem Schritt zur Verfügung, die es benötigen.
• Maskieren Sie bekannte Secret-Werte, verlassen Sie sich jedoch nicht auf Maskierung als primäre Kontrolle.
• Deaktivieren Sie Shell-Trace-Ausgaben rund um das Abrufen von Secrets.
• Verhindern Sie, dass nicht vertrauenswürdiger Code aus Forks auf Bereitstellungs-Secrets zugreift.
• Prüfen Sie Artefakte, Caches, Crash-Dumps und Testberichte auf unbeabsichtigte Erfassung.

Nutzung überwachen, ohne das Secret zu protokollieren

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

Verfolgen Sie:

• Workload, Umgebung, Mandant oder Projekt und Schlüsselversion.
• Provider, Modell, Routing-Richtlinie und Fallback-Pfad.
• Anzahl der Anfragen, Token-Volumen, Ausgaben, Latenz und Fehlerklasse.
• Quellnetzwerk oder Bereitstellungsidentität, wo sinnvoll.
• Zugriffe auf den Secret Manager, einschließlich verweigerter Lesezugriffe.
• Schlüsselerstellung, Änderungen an Einschränkungen, Rotation, Widerruf und Löschung.
• Plötzliche Nutzung aus einer unerwarteten Umgebung, Region, einem unerwarteten Modell oder Zeitfenster.

Richten Sie Alarme am Verhalten aus, nicht nur an den Gesamtausgaben. Ein gestohlener Schlüssel mit kleinem Budget kann dennoch Prompts offenlegen oder interne Workflows auskundschaften. Umgekehrt kann ein legitimer Batch-Job einen Ausgabenanstieg verursachen, ohne dass Anmeldedaten kompromittiert wurden. Korrelieren Sie die Nutzung beim Anbieter mit Anwendungs-Anfrage-IDs, Entscheidungen der Gateway-Richtlinie, Bereitstellungsereignissen und Audit-Logs des Secret Managers.

Für Traffic-Kontrollen, die Anmeldedaten-Kontrollen ergänzen, verwenden Sie den Leitfaden zu LLM-Rate-Limits und das LLM-API-Fallback-Routing-Playbook.

Verwenden Sie einen Vorfall-Countdown von Exposition bis Widerruf

Wenn ein Schlüssel möglicherweise offengelegt wurde, ist das erste Ziel die Eindämmung — nicht der Nachweis, ob ein Angreifer ihn verwendet hat.

Führen Sie diese Sequenz aus:

1. Das Anmeldedatum als verdächtig einstufen. Erfassen Sie, wann und wo es möglicherweise offengelegt wurde.
2. Über den normalen kontrollierten Weg einen Ersatz erstellen. Fügen Sie keinen neuen Schlüssel in den Chat ein, um den Vorfall zu beschleunigen.
3. Legitime Workloads auf den Ersatz umstellen. Verwenden Sie das vorbereitete Rotationsverfahren.
4. Den verdächtigen Schlüssel widerrufen. Wenn ein sofortiger Widerruf unzumutbaren Schaden verursachen würde, isolieren Sie die Pfade und reduzieren Sie die Limits, während Sie die Umstellung abschließen.
5. Jeden Speicherort der Kopie durchsuchen. Prüfen Sie den Quellverlauf, CI-Logs, Artefakte, Container-Layer, Support-Systeme, Dashboards, Notebooks, lokale Konfigurationen und Backups.
6. Autorisierte Datenpfade überprüfen. Bestimmen Sie, auf welche Prompts, Ausgaben, Dateien, Tools oder Modelle der Schlüssel zugreifen konnte — nicht nur auf seinen Abrechnungsbereich.
7. Aktivitäten korrelieren. Vergleichen Sie die Nutzung beim Anbieter, Gateway-Logs, Deployments, Secret-Zugriffe und Benutzeraktivitäten.
8. Die richtigen Eigentümer benachrichtigen. Binden Sie je nach den betroffenen Daten und Verträgen Security-, Plattform-, Rechts-, Datenschutz- und Kundenteams 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. Erfassen Sie die Zeit bis zur Erkennung, zum Ersatz, zur Verkehrsumschaltung, zum Widerruf und zur Verifizierung.

Die umsetzbarste Kennzahl ist oft Zeit von Exposition bis Widerruf: wie lange ein verdächtiges Anmeldedatum nach dem Vorliegen glaubwürdiger Hinweise auf eine Offenlegung noch nutzbar bleibt. Die Verkürzung dieses Intervalls erfordert vorbereitete Verantwortlichkeiten, Inventarisierung, Automatisierung und getestete Rotation — nicht ein längeres Richtliniendokument.

Referenzarchitektur für Multi-Provider-KI-Produkte

Ein sicheres Multi-Provider-Setup kann in fünf Schichten organisiert werden:

1. Schicht der Client-Identität: Authentifiziert den Benutzer, das Gerät, den Agenten oder die Anwendung, ohne Anbieter-Anmeldedaten offenzulegen.
2. Schicht der Anwendungsautorisierung: Prüft Produktberechtigungen, Mandantengrenzen, Funktionszugriffe und Budgets.
3. Schicht der Datenrichtlinien: Klassifiziert und redigiert Prompts, Dateien, abgerufenen Kontext und Tool-Argumente.
4. Schicht von Gateway und Routing: Wählt freigegebene Modelle aus, wendet Kontingente an, protokolliert nicht geheime Zuordnungen und behandelt Failover.
5. Schicht der Anbieter-Anmeldedaten: Speichert isolierte Lieferanten-Anmeldedaten, rotiert Versionen und stellt sie nur dem vertrauenswürdigen Routing-Workload zur Verfügung.

Dieses Design begrenzt die Auswirkung eines Vorfalls. Ein kompromittiertes Client-Token legt nicht automatisch einen Anbieter-Schlüssel offen. Eine kompromittierte Workload-Identität sollte nicht den Zugriff auf jeden Anbieter gewähren. Ein offengelegtes Anbieter-Anmeldedatum sollte nicht jede Umgebung autorisieren. Ein Protokollierungsfehler sollte nicht sowohl das Geheimnis als auch die vollständige Nutzlast offenlegen.

Flatkeys Produktpositionierung ist ein OpenAI-kompatibler Endpunkt und ein einheitlicher Zugriff über mehrere Modellanbieter hinweg. Das kann die Anzahl der anbieterspezifischen Integrationen reduzieren, die eine Anwendung pflegt, aber ein Gateway entbindet Sie nicht von der Verantwortung, die Client-Authentifizierung abzusichern, Anfragedaten zu klassifizieren, Protokolle zu konfigurieren, Verantwortliche zuzuweisen und den Widerruf zu testen. Bewerten Sie vor dem produktiven Rollout die genauen Kontrollen, die für Ihr Konto und Ihre Architektur verfügbar sind. Sie können mit dem Flatkey-Integrationsleitfaden beginnen und die aktuellen Modellzugriffe und Preise prüfen.

Produktions-Checkliste

Verwenden Sie diese Checkliste vor dem Start und während der quartalsweisen Kontrollprüfungen.

Verwahrung und Identität

• Kein langfristiger Anbieter-Schlüssel wird in Browser-, Mobile-, Desktop- oder Erweiterungscode ausgeliefert.
• Jede Produktions-Workload hat einen identifizierbaren Verantwortlichen und einen Credential-Pfad.
• Produktion, Staging, Entwicklung, Evaluierung und lokaler Zugriff sind getrennt.
• Geteilte menschliche Schlüssel wurden, wo möglich, durch Workload- oder Gateway-Identitäten ersetzt.
• Anbieter- und Gateway-Einschränkungen sind auf den engstmöglichen praktischen Umfang gesetzt.

Speicherung und Bereitstellung

• Die maßgebliche Quelle ist ein verwalteter Secret Store oder eine kontrollierte Deployment-Bindung.
• Anwendungen rufen Geheimnisse nur zur Laufzeit ab und drucken oder serialisieren sie nicht.
• CI-Jobs erhalten nur die Geheimnisse, die für den jeweiligen Schritt erforderlich sind.
• Der Zugriff auf Geheimnisse und administrative Änderungen werden geprüft.
• Break-Glass-Zugriff ist dokumentiert, zeitlich begrenzt und getestet.

Daten und Beobachtbarkeit

• Autorisierungs-Header und Schlüsselwerte werden von Logs, Traces, Fehlern und Support-Exporten ausgeschlossen.
• Das Logging von Prompt, Ausgabe, Datei und Tool-Argumenten folgt einem Allowlist-Schema.
• Redaction erfolgt vor dem Multi-Provider-Routing.
• Die Nutzung kann Workload, Umgebung, Route, Anbieter, Modell und Schlüsselversion zugeordnet werden.
• Alarme decken ungewöhnliche Routen und Identitäten sowie Ausgaben ab.

Rotation und Reaktion

• Ein getestetes Runbook für die Rotation mit zwei Schlüsseln oder versionierten Geheimnissen liegt vor.
• Alte Schlüssel werden beim Anbieter widerrufen und als unbrauchbar verifiziert.
• Secret Scanning und Push-Schutz decken Repositories und generierte Artefakte ab.
• Ein vermuteter Leak löst sofortige Eindämmung aus, ohne auf den Nachweis von Missbrauch zu warten.
• Die Zeit von der Exposition bis zum Widerruf wird nach Übungen und Vorfällen gemessen.

FAQ

Was ist sicheres API-Schlüssel-Management für KI-Produkte?

Es ist die Praxis, den gesamten Lebenszyklus und den Request-Pfad von Anmeldedaten zu kontrollieren, die zum Aufruf von KI-Modellen verwendet werden. Dazu gehören serverseitige Verwahrung, Workload-Identität, Least Privilege, Secret Storage, Routing-Richtlinien, Governance für Prompts und Logs, Rotation, Monitoring und Incident Response.

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

Eine Umgebungsvariable kann ein Bereitstellungsmechanismus sein, ist aber kein vollständiges Managementsystem. Das Secret benötigt weiterhin eine kontrollierte Quelle der Wahrheit, eingeschränkten Bereitstellungszugriff, Rotation, Auditierung und Schutz vor Prozessdumps, Logs, Debug-Endpunkten und vererbten Kindprozessen. Bevorzugen Sie eine plattformnative Secret-Injektion oder Laufzeitabfrage, wenn dadurch diese Kontrollen verbessert werden.

Wie oft sollten KI-API-Schlüssel rotiert werden?

Nutzen Sie die Möglichkeiten des Anbieters, Ihr Bedrohungsmodell, Verträge und interne Richtlinien, um das Intervall festzulegen. Wichtiger als eine beliebige Kalenderzahl ist der Nachweis, dass die Rotation automatisiert oder eingeübt ist, alte Schlüssel widerrufen werden, vermutete Schlüssel sofort ersetzt werden können und veraltete Zugangsdaten nicht unbemerkt bestehen bleiben können.

Kann ein Browser einen KI-Anbieter direkt mit einem eingeschränkten Schlüssel aufrufen?

Einige Anbieter unterstützen clientseitige Einschränkungen für bestimmte APIs, aber ein Produktions-KI-Produkt sollte davon ausgehen, dass ein ausgelieferter Zugangsschlüssel wiederhergestellt werden kann. Ein Backend oder Gateway bietet in der Regel stärkere Kontrolle über Benutzerautorisierung, Kontingente, Prompt-Redaktion, Anbieterauswahl, Reaktion auf Missbrauch und Schlüsselwiderruf.

Ist ein Gateway-Schlüssel sicherer als viele Anbieter-Schlüssel?

Er kann die Ausbreitung von Zugangsdaten im Anwendungscode reduzieren, bündelt aber Autorität am Gateway. Die Gateway-Zugangsdaten müssen begrenzt, zuordenbar, rate-limited, überwacht, rotierbar und vor Clients geschützt sein. Die dahinterliegenden Anbieter-Zugangsdaten benötigen weiterhin Isolation und Lebenszyklusmanagement.

Was sollten wir tun, wenn ein API-Schlüssel in der Git-Historie auftaucht?

Behandeln Sie ihn als kompromittiert. Widerrufen oder rotieren Sie ihn, ersetzen Sie legitime Verbraucher, prüfen Sie die Aktivität des Anbieters und des Gateways, entfernen Sie den Wert aus aktiven Branches und relevanten Artefakten und ergänzen Sie präventives Scanning. Das Umschreiben der Historie macht einen noch gültigen Zugangsschlüssel nicht sicher.

Quellen und weiterführende Literatur

• OWASP Secrets Management Cheat Sheet
• OWASP Logging Cheat Sheet
• GitHub: About push protection
• Google Cloud: Best practices for managing API keys