Anbieter-Anmeldeinformations-Tresore für Multi-Modell-KI-Gateways: Separater Laufzeit-, Verwaltungs-, Abrechnungs- und BYOK-Zugriff

Downstream-API-Schlüssel und Upstream-Anbieter-Anmeldeinformationen lösen unterschiedliche Probleme. Ein von Ihrem Gateway ausgegebener Entwicklerschlüssel identifiziert die App, das Team, den Mandanten, das Budget und den Richtlinienkontext. Mit einem Upstream-Anbieterschlüssel kann das Gateway Geld ausgeben und auf Modelle in einem Anbieterkonto zugreifen. Diese als dasselbe Geheimnis zu behandeln, besteht darin, dass Teams am Ende über einen einzigen uneingeschränkten Schlüssel in einem gemeinsamen Projekt, Administratoranmeldeinformationen in Laufzeitdiensten und keine zuverlässige Möglichkeit verfügen, zu beantworten, welcher Mandant welche anbieterseitige Gebühr verursacht hat.

Das praktische Muster ist ein Provider Credential Vault: eine dedizierte Kontrollebene zum Importieren, Klassifizieren, Speichern, Auswählen, Rotieren und Überwachen von Upstream-Anmeldeinformationen. Es sollte sich hinter dem Router, dem Abrechnungsbuch, der Richtlinien-Engine und dem Betriebsworkflow befinden – nicht innerhalb des Anwendungscodes, der Modellkonfigurationsdateien, der Mandantendatensätze oder der Analyseereignisse.

Das Leserproblem: Upstream-Zugangsdaten werden zur unsichtbaren Infrastruktur

Die meisten Bereitstellungen mit mehreren Modellen beginnen mit einem einfachen Ziel: Leiten Sie eine OpenAI-kompatible Anfrage an den besten verfügbaren Anbieter weiter. Dann erscheinen weitere Konten: ein Anbieterprojekt für die Produktion, ein anderes für die Evaluierung, ein Anthropic-Arbeitsbereich für eine Geschäftseinheit, ein Google Cloud-Projekt für Gemini und mehrere vom Kunden bereitgestellte Schlüssel für BYOK-Verträge.

Das Risiko besteht nicht nur darin, dass Geheimnisse preisgegeben werden. Es handelt sich um einen Verlust des Autorisierungskontexts. Ein gültiger Anbieterschlüssel ist möglicherweise technisch in der Lage, einen Endpunkt aufzurufen, aber das Gateway muss dennoch wissen, ob dieser Schlüssel für diesen Mandanten, diese Modellfamilie, diese Datenaufbewahrungsrichtlinie, dieses Budget, diese Region und diesen Automatisierungspfad zulässig ist.

Fakt: Anbieterplattformen legen unterschiedliche Kontogrenzen und Anmeldeinformationstypen offen. OpenAI dokumentiert Projekte und Dienstkonten, und die API-Schlüsselberechtigungen des Dienstkontos umfassen standardmäßig Lese- und Schreibzugriff für die API-Ressourcen des Projekts. OpenAI stellt außerdem Admin-API-Schlüsselobjekte getrennt von der normalen Projekt-/Laufzeit-API-Nutzung zur Verfügung. Anthropic dokumentiert Arbeitsbereiche als organisatorische Grenze und gibt an, dass Admin-API-Endpunkte Admin-API-Schlüssel erfordern, die sich von Standard-API-Schlüsseln unterscheiden; Anthropic weist außerdem darauf hin, dass API-Schlüssel an den Arbeitsbereich gebunden sind, in dem sie erstellt werden, und nicht zwischen Arbeitsbereichen verschoben werden können. In der Gemini-API-Schlüsseldokumentation von Google heißt es, dass jeder Gemini-API-Schlüssel mit einem Google Cloud-Projekt verknüpft ist, und es werden API-Einschränkungen empfohlen, um Schäden zu reduzieren, wenn ein Schlüssel kompromittiert wird.

Empfehlung: Erstellen Sie nicht ein generisches „provider_key“-Feld und nennen Sie es fertig. Erstellen Sie einen Anmeldeinformationsbestand, der anbieterspezifische Grenzen beibehält und gleichzeitig dem Gateway ein normalisiertes Richtlinienmodell zur Verfügung stellt.

Definieren Sie eine Taxonomie der Anmeldeinformationen, bevor Sie Schlüssel akzeptieren

Ein Tresor sollte mehrdeutige Anmeldeinformationen ablehnen. Zum Zeitpunkt des Imports muss der Bediener oder der Automatisierungsworkflow die Anmeldeinformationen klassifizieren. Verwenden Sie mindestens diese Kategorien:

• Anmeldeinformationen zur Laufzeitinferenz: werden vom Gateway verwendet, um Modellinferenzendpunkte wie Chat, Antworten, Einbettungen, Moderation, Transkription oder Bildgenerierung aufzurufen, je nach Anbieterunterstützung.
• Anmeldeinformationen für die Administratorautomatisierung: werden zur Verwaltung von Organisationen, Arbeitsbereichen, Projekten, Benutzern, Schlüsseln oder Verwaltungsressourcen auf Anbieterseite verwendet. Diese sollten sich niemals im Laufzeitanforderungspfad befinden.
• Abrechnungs- und Berichtsanmeldeinformationen: werden zum Abrufen von Nutzung, Rechnungen, Kosten oder Organisationsberichten verwendet, wenn Anbieter diese APIs unterstützen. Halten Sie sie von Inferenzschlüsseln getrennt, damit Berichtsjobs keine Modellnutzung generieren können.
• Nur Evaluierungs-Anmeldeinformationen: werden von Benchmark-, Qualitätssicherungs-, Migrations- oder Staging-Workflows verwendet. Sie sollten niedrige Quoten, klare Umweltkennzeichnungen und keine Produktions-Fallback-Berechtigung haben.
• BYOK-Anmeldeinformationen des Kunden: Vom Kunden bereitgestellte Schlüssel, die an einen bestimmten Mandanten, ein Anbieterkonto, einen Vertrag und eine Datenrichtlinie gebunden sind. Sie sollten nicht im gemeinsamen Routing zusammengefasst werden, es sei denn, der Kunde stimmt ausdrücklich zu.

Diese Taxonomie ist nicht nur eine Dokumentation. Es sollte die Zugriffskontrolle, Weiterleitungsberechtigung, Alarmierung und Rotationsworkflows vorantreiben. Wenn Anmeldeinformationen ohne Kategorie, Eigentümer, Anbieterkontogrenze und zulässige Verwendung importiert werden, sollten sie deaktiviert bleiben.

Speichern Sie Geheimnisse in einem Tresor, nicht in Produktdatensätzen

Der Tresor sollte die einzige Komponente sein, die Upstream-Anmeldeinformationen entschlüsseln kann. Andere Systeme speichern möglicherweise Referenzen, Hashes, Statusfelder und Richtlinienmetadaten, jedoch nicht den Anmeldeinformationswert selbst.

Speichern Sie an diesen Orten keine Upstream-Geheimnisse

• Mandantenprofilzeilen.
• Modell-Routing-Konfigurationsdateien.
• Prompt-Protokolle oder Trace-Spans.
• Analytics-Ereignisnutzlasten.
• Entwicklerorientierte CI-Variablen.
• Support-Tickets, Chat-Tools oder Screenshots.

Ein nutzbares Gewölbedesign hat zwei Ebenen. Die Geheimebene speichert verschlüsseltes Anmeldeinformationsmaterial und kontrolliert streng die Entschlüsselungsvorgänge. Die Metadatenebene speichert nicht geheime Attribute, die von Routing und Governance verwendet werden. Der Router sollte normalerweise nur eine Anmeldeinformations-ID und einen kurzlebigen geheimen Abruf im Arbeitsspeicher zum Zeitpunkt des Versands benötigen, nicht jedoch einen umfassenden Datenbankzugriff auf jeden Anbieterschlüssel.

Schützen Sie den Tresor als hochwertige Infrastruktur: Umschlagverschlüsselung oder verwaltetes KMS, strenge Dienstidentitäten, Break-Glass-Verfahren, Backup- und Wiederherstellungstests, Zugriffsüberprüfung und Warnung bei ungewöhnlichem Entschlüsselungsvolumen. Ein zentraler Tresor vereinfacht die Governance, konzentriert aber auch das Risiko. Das ist der Kompromiss.

Fügen Sie allen Anmeldeinformationen Richtlinienmetadaten hinzu

Das Metadatenmodell sollte so explizit sein, dass das Gateway entscheiden kann, ob eine Anmeldeinformation berechtigt ist, bevor sie einen Anbieterendpunkt berührt.

Ein praktischer Berechtigungsnachweis umfasst:

• credential_id: interne unveränderliche Kennung.
• Anbieter: OpenAI, Anthropic, Gemini, Azure OpenAI oder ein anderer Adapter.
• provider_account_boundary: Organisation, Projekt, Arbeitsbereich, Cloud-Projekt, Abonnement oder Äquivalent.
• credential_class: Laufzeit, Admin, Abrechnung, Evaluierung oder BYOK.
• Umgebung: Produktion, Staging, Entwicklung, Evaluierung, Sandbox.
• tenant_binding: gemeinsame Plattformanmeldeinformationen, einzelner Mandant, Mandantengruppe oder BYOK-Mandant des Kunden.
• Erlaubte_Modellfamilien: zum Beispiel Textgenerierung, Einbettungen, Vision, Bild, Audio oder bestimmte Modellprofile.
• allowed_endpoints: normalisierte Gateway-Funktionen, die Anbieterendpunkten zugeordnet sind.
• data_policy: erlaubte Aufbewahrungsklasse, Protokollierungsklasse, Residenzanforderung und Funktionseinschränkungen.
• budget_scope: Kostenstelle, Reseller-Kunde, interne Abteilung oder Vertrag.
• Eigentümer: benanntes Team oder verantwortliche Person.
• erstellt am, abgelaufen am, rotation_due_at, zuletzt verwendet am.
• Gesundheitsstatus: unbekannt, fehlerfrei, beeinträchtigt, nicht autorisiert, Quote erschöpft, deaktiviert.
• emergency_disable: sofortige Routing-Blockierung unabhängig vom normalen Richtlinienstatus.

Halten Sie dieses Modell anbieterneutral, aber löschen Sie nicht die Realitäten der Anbieter aus. Ein an den Anthropic-Arbeitsbereich gebundener Schlüssel und ein an ein Google Cloud-Projekt gebundener Gemini-Schlüssel sind nicht austauschbar, nur weil beide Text generieren können. Das Gateway benötigt diese Herkunft für Audits, Rückbuchungen und sicheres Failover.

Getrennter Laufzeit-, Administrator- und Abrechnungszugriff

Die wichtigste Regel ist einfach: Ein Schlüssel, der für die Laufzeitinferenz verwendet wird, sollte keine Anbieterorganisationen, Arbeitsbereiche, Benutzer, Projekte oder Verwaltungsressourcen verwalten.

Der Laufzeitverkehr weist ein hohes Volumen auf und ist der größten Betriebsoberfläche ausgesetzt. Es durchläuft Anforderungsrouter, Wiederholungslogik, Streaming-Handler, Modelladapter und Vorfall-Workflows. Administratoranmeldeinformationen sind selten und haben große Auswirkungen. Sie sollten hinter einem separaten Genehmigungspfad mit kurzen TTLs, gegebenenfalls benannter menschlicher Genehmigung, starker Protokollierung und ohne Berechtigung zum Laufzeitrouting leben.

Rechnungsdaten verdienen ebenfalls eine Trennung. Ein Berichtsjob, der Rechnungen abgleicht, sollte nicht in der Lage sein, Abschlüsse zu generieren, und ein Laufzeit-Inferenzschlüssel sollte nicht die einzige Möglichkeit sein, Nutzungsberichte abzurufen. Wenn ein Anbieter keine feinkörnige Trennung bietet, kompensieren Sie dies im Gateway: Isolieren Sie die Anmeldeinformationen, begrenzen Sie, welche interne Dienstidentität sie abrufen kann, und protokollieren Sie jede Verwendung.

Empfehlung: Machen Sie die Anmeldeinformationsklasse zu einer harten Autorisierungsgrenze und nicht zu einer Bezeichnung. Ein Laufzeit-Dispatcher sollte nicht in der Lage sein, die Entschlüsselung für Administratoranmeldeinformationen anzufordern, selbst wenn ein Konfigurationsfehler auf seine ID verweist.

Erstellen Sie eine Richtlinien-Engine für die Auswahl von Anmeldeinformationen

Die Auswahl der Anmeldeinformationen sollte erfolgen, nachdem das Gateway den Downstream-Anrufer authentifiziert hat und bevor ein Anbieteranruf versucht wird. Die Richtlinien-Engine sollte mehrere Eingaben zusammenführen:

• Mandanten-ID und Downstream-API-Schlüsselbereich.
• Angefordertes Modellprofil oder anbieterspezifische Modell-ID.
• Endpunktfähigkeit: Chat, Einbettungen, Bild, Audio, Batch, Dateien, Tools oder Admin-Automatisierung.
• Anforderungen an die Datenaufbewahrung und den Aufenthaltsort.
• Budget, Kreditreservierung und Kostenstelle.
• Ratengrenzzustand und Quotendruck.
• Anmeldeinformationsmetadaten, Zustand, Umgebung und Mandantenbindung.

Die Engine sollte eines von drei Ergebnissen zurückgeben: „Zulassen“ mit ausgewählten Anmeldeinformationen, „Ablehnen“ mit einem Richtliniengrund oder „Genehmigung anfordern“. Ablehnungen sollten präzise genug sein, damit die Betriebsteams das Problem beheben können, ohne den Entwicklern geheimes Material preiszugeben.

Beispielentscheidung:

{
  „tenant_id“: „tenant_42“,
  „requested_profile“: „fast-text-prod“,
  „endpoint“: „chat.completions“,
  „data_policy“: „no_prompt_logging“,
  „credential_requirements“: {
    „Klasse“: „Laufzeit“,
    „Umwelt“: „Produktion“,
    „tenant_binding“: „tenant_42“,
    „allowed_model_family“: „text“,
    „health_status“: „gesund“
  },
  „Entscheidung“: „erlauben“,
  „credential_id“: „cred_8f2…“,
  „audit_reason“: „Die BYOK-Anmeldeinformationen des Mandanten stimmen mit dem Laufzeittextprofil und der Datenrichtlinie überein.“

Implementieren Sie keinen Fallback als „Nächsten Schlüssel ausprobieren“. Für den Fallback muss die Richtlinie erneut ausgeführt werden. Anmeldeinformationen für eine gemeinsam genutzte Plattform sind möglicherweise für den Anbieterzugriff gültig, für einen Nur-BYOK-Kunden jedoch ungültig. Eine Berechtigung in einem anderen Projekt verfügt möglicherweise über ein Kontingent, verstößt jedoch möglicherweise gegen Kostenzuordnungs- oder Aufbewahrungsanforderungen.

Behandeln Sie BYOK als Zugang im Besitz des Mandanten, nicht als freie Kapazität

BYOK ändert das Vertrauensmodell. Der Kunde hat die Anmeldeinformationen angegeben, damit sein Datenverkehr seinem Anbieterkonto in Rechnung gestellt, von diesem verwaltet oder isoliert werden kann. Diese Anmeldeinformationen sollten an die Herkunft des Kundenmandanten und des Anbieterkontos gebunden sein.

Empfohlene BYOK-Kontrollen:

• Ein Tresordatensatz pro Kunde, Anbieter, Kontogrenze und Umgebung.
• Kein mandantenübergreifendes Routing über BYOK-Anmeldeinformationen.
• Keine Nutzung als gemeinsame Fallback-Kapazität, es sei denn, der Kunde stimmt ausdrücklich zu.
• Für den Kunden sichtbarer Gesundheitszustand, der den Rohschlüssel nicht preisgibt.
• Separater Rotationsworkflow, der es dem Kunden ermöglicht, einen Ersatz hinzuzufügen, bevor der alte Schlüssel deaktiviert wird.
• Eindeutige Zuordnung in Nutzungsanalysen und Rechnungen: Gateway-Mandant, Anbieterkontogrenze, Anmeldeinformations-ID, Modellprofil und Anforderungsverfolgungs-ID.

Für Agenturen, Wiederverkäufer und Partner-API-Automatisierung kann BYOK komplexer sein, da ein Dienst Mandanten und Anmeldeinformationen programmgesteuert bereitstellen kann. Es gilt weiterhin die gleiche Regel: Die Automatisierung kann Anmeldeinformationen importieren und binden, sollte aber die Eigentümerschaft des Mandanten nicht verwischen.

Fügen Sie Gesundheitsprüfungen vor dem Flug hinzu, ohne Eingabeaufforderungen preiszugeben

Eine Anmeldeinformation kann aus vielen Gründen fehlschlagen: widerrufener Schlüssel, falscher Arbeitsbereich, fehlender Modellzugriff, deaktivierte Abrechnung, Kontingentausschöpfung, Endpunktbeschränkung, Nichtübereinstimmung regionaler Richtlinien oder Anbieterausfall. Wenn man herausfindet, dass es erst dann zu lauten Zwischenfällen kommt, wenn eine Produktionsanforderung eintrifft.

Verwenden Sie Integritätsprüfungen, die die Leistungsfähigkeit validieren, ohne Kundenaufforderungen zu senden. Eine synthetische Prüfung könnte einen minimalen Endpunkt aufrufen, gegebenenfalls zulässige Modelle auflisten oder eine harmlose feste Eingabeaufforderung senden, wenn dies die einzig praktische Option ist. Halten Sie diese Schecks günstig, ratenbegrenzt und kennzeichnen Sie sie in Telemetrie und Abrechnung als synthetischen Datenverkehr.

Zustandsprüfungen sollten ausgeführt werden:

• Beim Anmeldeinformationsimport.
• Bevor Sie einen Berechtigungsnachweis für die Produktionsweiterleitung aktivieren.
• Nach anbieterseitigen Einschränkungsänderungen.
• Während der Rotationsumschaltung.
• In regelmäßigen Abständen für Anmeldeinformationen mit Produktionsberechtigung.

Kompromiss: Automatisierte Prüfungen erkennen abgelaufene Schlüssel oder Schlüssel mit zu geringem Gültigkeitsbereich frühzeitig, aber schlecht konzipierte Prüfungen können bei Anbieterausfällen zu unnötigen Anbieteranrufen, Abrechnungslärm oder Fehlalarmen führen. Speichern Sie das Integritätsergebnis mit Zeitstempel, Anbieterfehlerklasse, getestetem Endpunkt und getesteter Modellfamilie. Speichern Sie keine geheimen Werte oder vertraulichen Eingabeaufforderungen.

Rotieren Sie mit zwei Schlitzen, nicht mit einem riskanten Austausch

Die Rotation von Anmeldeinformationen sollte kein Lösch-und-Beten-Vorgang sein. Verwenden Sie ein Rotationsmodell mit zwei Slots:

1. Ersatzanmeldeinformationen importieren als inaktiv, mit vollständigen Metadaten und Besitzer.
2. Führen Sie synthetische Zustandsprüfungen durch für die vorgesehenen Endpunkte, Modellfamilien und Kontogrenzen.
3. Aktivieren Sie ggf. die Shadow-Berechtigung für einen kleinen Teil des sicheren synthetischen oder risikoarmen Datenverkehrs.
4. Verlagern Sie den Produktionsverkehr schrittweise von alten Anmeldeinformationen auf neue Anmeldeinformationen.
5. Überwachen Sie Fehler, Latenz, Kontingent und Kostenzuordnung nach Anmeldeinformations-ID.
6. Fallback auf die alten Anmeldeinformationen einfrieren, sobald die neuen Anmeldeinformationen stabil sind.
7. Widerrufen Sie die alten Anmeldeinformationen beim Anbieter und markieren Sie den Tresordatensatz als widerrufen.
8. Stellen Sie sicher, dass nach dem Widerruf keine Entschlüsselungen oder Anbieteraufrufe erfolgen über die alten Anmeldeinformationen.

Rotationsfristen sollten in Betriebsansichten und Warnmeldungen sichtbar sein. Für die Notfallrotation ist ein kürzerer Weg erforderlich: Anmeldeinformationen deaktivieren, Routing blockieren, genehmigten Ersatz aktivieren und alle Audit-Datensätze zur Überprüfung von Vorfällen aufbewahren.

Anbieterschlüssel einschränken, wenn der Anbieter dies unterstützt

Gateway-Richtlinien sind erforderlich, aber Einschränkungen auf Anbieterseite verringern den Explosionsradius, wenn ein Schlüssel kompromittiert oder missbraucht wird. Verwenden Sie für Gemini- und andere Cloud-Plattform-API-Schlüssel API-/Dienstbeschränkungen und geeignete Anwendungsbeschränkungen, sofern verfügbar. Vermeiden Sie bei Anbieterprojekten, Arbeitsbereichen und Dienstkonten umfassende Organisationsrechte, wenn ein projektbezogener Laufzeitschlüssel ausreicht.

Empfehlung: Führen Sie für jede Anmeldeinformationsklasse eine anbieterseitige Einschränkungscheckliste. Die Checkliste sollte Teil der Importgenehmigung und Rotationsgenehmigung sein und keine separate Sicherheitsaufgabe, die unter Druck übersprungen werden kann.

Kompromiss: Einschränkungen auf Anbieterseite erhöhen den betrieblichen Mehraufwand. Neue Endpunkte, Modellfamilien, Regionen oder Automatisierungsfunktionen erfordern möglicherweise Richtlinien- und Einschränkungsänderungen. Das ist besser, als nach einem Leck herauszufinden, dass ein Schlüssel auf alle Workloads in einem gemeinsam genutzten Projekt zugreifen kann.

Führen Sie ein Audit-Protokoll für Anmeldeinformationen nur zum Anhängen

Ein Audit-Trail sollte Aufschluss darüber geben, wer einen Berechtigungsnachweis importiert hat, was er tun durfte, welche Routing-Entscheidungen ihn ausgewählt haben, wann er fehlgeschlagen ist und wann er rotiert oder widerrufen wurde.

Diese Ereignisse protokollieren:

• Anmeldeinformationen erstellt oder importiert.
• Metadaten geändert, einschließlich zulässiger Endpunkte, Mandantenbindung oder Datenrichtlinie.
• Gesundheitscheck durchgeführt und Ergebnis aufgezeichnet.
• Anmeldeinformationen, die von der Routing-Richtlinie für eine Anfrage ausgewählt wurden.
• Entschlüsselung der Anmeldeinformationen, angefordert durch eine interne Dienstidentität.
• Der Anbieteraufruf ist aufgrund eines Authentifizierungs-, Autorisierungs-, Kontingent- oder Einschränkungsfehlers fehlgeschlagen.
• Rotation gestartet, Datenverkehr verschoben, alte Zugangsdaten widerrufen.
• Notfalldeaktivierung aktiviert oder deaktiviert.
• Zugriff auf Administrator- oder Break-Glass-Anmeldeinformationen.

Fügen Sie keine rohen Anmeldeinformationswerte in Prüfereignisse ein. Verwenden Sie Anmeldeinformations-IDs, Anbieterkontogrenzen, Anforderungsverfolgungs-IDs, Akteuridentitäten und Entscheidungsgründe für Richtlinien. Für hochvolumigen Laufzeitverkehr können Sie detaillierte Entschlüsselungstelemetriedaten abtasten, aber die Routing-Auswahl und die Kostenzuordnung sollten für die Abrechnung und Reaktion auf Vorfälle vollständig genug bleiben.

Checkliste für die Implementierung

• Erstellen Sie eine Taxonomie für Anmeldeinformationen und lehnen Sie nicht klassifizierte Importe ab.
• Verschieben Sie alle Anbietergeheimnisse in einen dedizierten verschlüsselten Tresor.
• Speichern Sie Routing-Metadaten getrennt vom geheimen Material.
• Machen Sie Laufzeit-, Administrator-, Abrechnungs-, Bewertungs- und BYOK-Anmeldeinformationen zu separaten Autorisierungsklassen.
• Binden Sie BYOK-Anmeldeinformationen an die Herkunft des Mandanten- und Anbieterkontos.
• Erfordern Sie die Genehmigung der Richtlinien-Engine, bevor Sie Upstream-Anmeldeinformationen auswählen.
• Führen Sie vor der Produktionsberechtigung umgehend sichere Gesundheitsprüfungen durch.
• Verwenden Sie eine Zwei-Slot-Rotation mit schrittweiser Verkehrsverschiebung und Sperrung auf Anbieterseite.
• Wenden Sie anbieterseitige Einschränkungen an, wo immer verfügbar.
• Verwalten Sie Audit-Protokolle, die nur angehängt werden können, für Import, Verwendung, Fehler, Rotation und Widerruf.
• Bewahren Sie Administratoranmeldeinformationen hinter Sicherheitskontrollen auf: kurze TTL, benannte Genehmigung, starke Protokollierung, keine Laufzeitnutzung.

Umsetzbare Schlussfolgerung

Beginnen Sie mit der Bestandsaufnahme aller Upstream-Provider-Anmeldeinformationen, die derzeit vom Gateway, von Skripten, CI-Jobs, Evaluierungssystemen und der Partnerautomatisierung verwendet werden. Weisen Sie für jeden eine Klasse, einen Besitzer, eine Anbieterkontogrenze, eine Mandantenbindung, zulässige Endpunkte, zulässige Modellfamilien, einen Rotationstermin und einen Notfall-Deaktivierungsstatus zu. Alles, was Sie nicht klassifizieren können, sollte deaktiviert oder unter Quarantäne gestellt werden, bis es einen klaren Zweck hat.

Erzwingen Sie dann eine Architekturregel: Downstream-Entwickler erhalten Gateway-Schlüssel; Das Gateway allein steuert den Upstream-Provider-Zugriff. Durch diese Trennung können Sie die geringsten Rechte, die Mandantenzuordnung, die Abrechnungsgenauigkeit, das Datenrichtlinien-Routing und die sichere Automatisierung beibehalten, selbst wenn sich Anbieter, Projekte, Arbeitsbereiche und BYOK-Kunden vervielfachen.

Verwandte Lektüre

• teamorientiert API-Schlüsselverwaltung und Leak-Reaktion
• Datenaufbewahrungsfähige Routing-Richtlinien
• Abrechnungsbuch und Kostenzuordnungskontrollen