Kundenspezifische KI-API-Schlüssel: Isolieren Sie Mieter, Budgets und Missbrauch, ohne dass sich Anbieterschlüssel ausbreiten

Wenn ein Produkt es vielen Kunden ermöglicht, KI-Modelle aufzurufen, ist das falsche Grundelement häufig der Schlüssel des Upstream-Anbieters. Ein Anbieterschlüssel stellt normalerweise ein Konto, ein Projekt, einen Arbeitsbereich oder ein Dienstkonto dar. Ihr Produkt benötigt etwas Engeres: einen kundenorientierten Schlüssel, der einen Mandanten, einen Kunden, eine Anwendung, eine Umgebung, eine Modellrichtlinie, ein Budget und eine Prüfregel identifiziert.

Das ist der Zweck von kundenbezogenen KI-API-Schlüsseln. Das Gateway gibt den Schlüssel aus, authentifiziert Anfragen, wendet Richtlinien an, misst die Nutzung und ruft dann Upstream-Anbieter mit versteckten Anmeldeinformationen an. Downstream-Kunden erhalten niemals den Provider-Schlüssel. Sie erhalten einen stabilen Vertrag mit Ihrer Plattform.

Leserproblem: Kundenisolierung ohne ein Anbieterprojekt pro Kunde

SaaS-Entwickler, Agenturen und Reseller-Plattformen müssen in der Regel praktische Fragen beantworten, bevor sie den KI-Zugriff nachgelagert offenlegen können:

• Welcher Kunde hat diese Nutzung generiert?
• Welche Anwendung, Umgebung oder Integration hat den Anruf getätigt?
• Welche Modelle und Modalitäten sind erlaubt?
• Wie viel kann dieser Kunde diesen Monat ausgeben?
• Was passiert, wenn ein Schlüssel undicht ist?
• Kann dieser Kunde gesperrt werden, ohne dass sich dies auf alle anderen auswirkt?
• Kann die Nutzung später mit Anbieterberichten abgeglichen werden?

Projekte und Arbeitsbereiche auf Anbieterseite können hilfreich sein, sie sind jedoch nicht immer die richtige Einheit für jeden nachgelagerten Kunden. Das Erstellen einer Upstream-Grenze pro Kunde kann die harte Isolierung und Berichterstellung verbessern, führt aber auch zu Bereitstellungsaufwand, Quotenfragmentierung, Ausufern von Anmeldeinformationen und mehr Abgleichsarbeit.

Ein vom Gateway ausgegebener Schlüssel gibt dem Produkt einen Kontrollpunkt auf Kundenebene, selbst wenn Upstream-Anmeldeinformationen gepoolt werden. Es unterstützt auch stärkere Modi, wie z. B. mandantengebundene Anbieteranmeldeinformationen oder Bring-Your-Own-Key, wenn ein Kunde eine vertragliche Trennung, Wohnsitzbeschränkungen oder den direkten Besitz eines Anbieterkontos benötigt.

Fakten, Empfehlungen und Vorhersagen

Fakten

• OpenAI-Projekte unterstützen Mitglieder, Dienstkonten, API-Schlüssel, Nutzungsbeschränkungen, Budgets und bereichsbezogene Projektressourcen. Das macht Projekte als Upstream-Grenzen nützlich, aber nicht automatisch für jeden Endkunden das richtige Primitiv.
• OpenAI-Nutzungsberichte können die Nutzung nach Dimensionen wie Projekt, Benutzer, API-Schlüssel, Modell, Batch und Serviceebene gruppieren. Beim SaaS-Chargeback müssen diese Anbieterdatensätze weiterhin mit produkteigenen Kundenkennungen verknüpft werden.
• Anthropic Workspaces trennen API-Ressourcen nach Anwendungsfall, Team, Abteilung, Projekt oder Produkt. API-Schlüssel sind an den Arbeitsbereich gebunden, in dem sie erstellt werden, und können nicht zwischen Arbeitsbereichen verschoben werden.
• Anthropic-Nutzungs- und Kostenberichte unterstützen die Gruppierung nach API-Schlüssel, Arbeitsbereich, Modell, Serviceebene, Kontextfenster, Datenresidenz und geschwindigkeitsbezogenen Optionen, wobei die Kosten in täglichen USD-Buckets zurückgegeben werden.
• Die Schlüsselrichtlinien für die Google Gemini-API empfehlen die Einschränkung von Schlüsseln. Gemini-API-Schlüssel sind standardmäßig auf die Generative Language API beschränkt. Je nach Bereitstellungsform können Anwendungseinschränkungen wie IP-Adressen verfügbar sein.
• OWASP-Richtlinien behandeln API-Schlüssel als erforderliche Kontrollen für geschützte Endpunkte und sagen, dass Schlüssel widerrufen werden sollten, wenn Clients gegen Nutzungsvereinbarungen verstoßen.
• OWASP-Geheimnisse-Richtlinien legen Wert auf die geringsten Rechte, den Widerruf, wenn Geheimnisse nicht mehr benötigt werden oder gefährdet sind, und eine automatische Rotation, um Implementierungsfehler zu reduzieren.

Empfehlungen

• Verwenden Sie vom Gateway ausgegebene Kundenschlüssel als Richtlinienhandles, nicht nur als Authentifizierungstoken.
• Halten Sie die Anmeldeinformationen des Upstream-Anbieters vor Downstream-Kunden verborgen.
• Erstellen Sie zum Zeitpunkt der Anfrage ein Gateway-Nutzungsprotokoll, bevor Sie sich auf Anbieter-Dashboards verlassen.
• Verwenden Sie Anbieterprojekte oder Arbeitsbereiche gezielt für risikoreiche, großvolumige, regulierte, standortabhängige oder vertraglich getrennte Kunden.
• Erstellen Sie die Schlüsselrotation als überlappenden Workflow, nicht als unmittelbares Bruchereignis.

Vorhersagen

• Mehr Anbieter werden umfassendere Nutzungsgruppierungen und Budgetkontrollen bereitstellen, aber die produkteigene Kundenzuordnung wird weiterhin für die SaaS-Abrechnung und Reseller-Berichte erforderlich sein.
• Reseller- und Agenturplattformen werden Gateway-Schlüssel zunehmend als kommerzielle Objekte behandeln: gebunden an Pläne, Guthaben, Umfänge und Support-Workflows.
• Kunden mit strengen Compliance- oder Beschaffungsanforderungen werden nach BYOK oder Anbieter-Kontoinhaberschaft fragen, während die meisten normalen Kunden einen Managed-Gateway-Vertrag bevorzugen.

Das Gateway-Schlüsselobjekt

Ein kundenbezogener Schlüssel sollte in ein strukturiertes Richtlinienobjekt aufgelöst werden. Modellieren Sie den Schlüssel zumindest als mehr als einen Hash und einen Namen.

{
  „key_id“: „key_01J9…“,
  „tenant_id“: „tenant_acme“,
  „customer_id“: „cust_4812“,„application_id“: „app_support_bot“,
  „Umwelt“: „Produktion“,
  „Besitzer“: {
    „Typ“: „service_account“,
    „id“: „svc_support_ai“
  },
  „model_profile_id“: „profile_support_standard“,
  „allowed_modalities“: [„text“, „image_input“],
  „tool_policy_id“: „tools_readonly_kb“,
  „monthly_budget“: {
    „Währung“: „USD“,
    „Betrag“: „500,00“
  },
  „rate_limits“: {
    „requests_per_minute“: 120,
    „input_tokens_per_minute“: 250000,
    „output_tokens_per_minute“: 80000
  },
  „retention_policy“: „metadata_only“,
  „Status“: „aktiv“,
  „created_at“: „2026-09-05T10:00:00Z“,
  „last_used_at“: null

Die genauen Felder variieren, das Prinzip sollte jedoch nicht gelten: Jede eingehende Anfrage löst den Schlüssel vor dem Versand in die Mandantenrichtlinie auf. Die Authentifizierung antwortet: „Wer ruft an?“ Die Richtlinienauflösung antwortet: „Was darf dieser Anrufer tun, wie viel darf er ausgeben, wohin darf die Anfrage weitergeleitet werden und was muss protokolliert werden?“

Hier kommt es auch auf die semantische Produktstrategie an. Eine Plattform, die eine KI-API für Agenturen verkauft, benötigt möglicherweise Kunden- und Kampagnendimensionen. Ein Entwicklertool benötigt möglicherweise Arbeitsbereichs- und Repository-Dimensionen. Ein Wiederverkäufer benötigt möglicherweise externe Kunden-IDs, die zu seinem Abrechnungssystem passen.

Arbeitsablauf zur Schlüsselerstellung

Die Schlüsselerstellung sollte deterministisch genug für die Automatisierung und streng genug für die Sicherheitsüberprüfung sein.

1. Erstellen Sie zuerst den Kundendatensatz

Erstellen Sie keine verwaisten Schlüssel. Der Schlüssel sollte zu einem Mieter- und einem Kundendatensatz gehören, bevor er existiert. Bei Reseller-Plattformen sollte der Kundendatensatz externe IDs aus dem CRM- oder Abrechnungssystem des Resellers, Planmetadaten, Steuer- oder Rechnungsgruppierung bei Bedarf sowie ein Statusfeld enthalten, das alle untergeordneten Schlüssel sperren kann.

2. Hängen Sie ein Modellprofil an

Ein Modellprofil ordnet kundenorientierte Modellnamen Anbietermodellen und -funktionen zu. Beispielsweise könnte support-standard ein ausgewogenes Textmodell, Bildeingabe und keine Codeausführung ermöglichen. research-premium ermöglicht möglicherweise Modelle mit langem Kontext, Websuche und höhere Obergrenzen pro Anfrage.

Zwingen Sie Downstream-Anwendungen nicht dazu, Anbietermodell-IDs fest zu codieren. Verwenden Sie das Gateway-Profil, um Verfügbarkeit, Fallback, Preise und Einstellung zu verwalten.

3. Legen Sie Ausgaben- und Ratenlimits fest

Verwenden Sie Budgets und Ratenlimits zusammen. Ein monatliches Budget verhindert Rechnungsschäden im Laufe der Zeit. Ratenbegrenzungen verhindern, dass plötzlicher Missbrauch, Wiederholungsstürme oder versehentliche Schleifen innerhalb von Minuten das gesamte Budget verbrauchen.

Nützliche Steuerelemente umfassen:

• Monatliches Kundenbudget.
• Tägliche Soft-Cap zur Anomalieerkennung.
• Anfragerate pro Schlüssel.
• Eingabe- und Ausgabe-Token-Rate.
• Maximale geschätzte Kosten pro Anfrage.
• Toolspezifische Grenzwerte für die gehostete Suche, Dateiverarbeitung oder Codeausführung.

Die Budgetdurchsetzung sollte die geschätzten Kosten vor dem Versand reservieren, die tatsächlichen Kosten nach der Fertigstellung begleichen und ungenutzte Rücklagen freigeben. Dadurch wird die Schlüsselrichtlinie mit der AI-API-Abrechnung verknüpft, anstatt die Abrechnung als verzögerte Berichtsaufgabe zu behandeln.

4. Das Geheimnis richtig generieren und speichern

Zeigen Sie das Klartext-Geheimnis einmal an. Speichern Sie nur einen starken Hash sowie ein kurzes Präfix oder einen Fingerabdruck für die Support-Suche. Das Präfix hilft Supportteams, „den Schlüssel, der auf 8F2A endet“, zu identifizieren, ohne das Geheimnis zu sehen.

Ein typisches Speichermuster ist:

• key_id: stabile Datenbankkennung.
• secret_hash: Hash des vollständigen Geheimnisses unter Verwendung einer geeigneten Passwort- oder Token-Hashing-Strategie.
• secret_prefix: kurzes, nicht sensibles Anzeigepräfix.
• Fingerabdruck: deterministische Kennung für Audit-Suche.
• created_by: Benutzer oder Partner-API-Client, der den Schlüssel erstellt hat.
• Status: aktiv, leerlaufend, widerrufen, unter Quarantäne gestellt, abgelaufen.

Speichern Sie niemals Upstream-Anbieterschlüssel auf dem Kundenschlüsselobjekt. Anbieter-Anmeldeinformationen gehören in einen separaten Anmeldeinformations-Tresor mit eigenen Zugriffsregeln.

Durchsetzung der Anforderungszeit

Das Gateway sollte jeden Modellaufruf als Richtlinienentscheidung behandeln, gefolgt von einem Provider-Versand. Ein praktischer Anfragepfad sieht so aus:

1. Parsen Sie den präsentierten Gateway-Schlüssel.
2. Suchen Sie den Schlüssel-Hash und den Status.
3. Mandanten-, Kunden-, Anwendungs-, Umgebungs-, Eigentümer- und Modellprofil auflösen.
4. Überprüfen Sie, ob der Mieter und der Kunde aktiv sind.
5. Validieren Sie den angeforderten Modellalias, die Modalität, die Tools, den Aufbewahrungsmodus, die Region und die Serviceebene.
6. Anfragekosten schätzen und Budget reservieren.
7. Überprüfen Sie Ratenlimits und Missbrauchsschwellen.
8. Wählen Sie den Upstream-Anmeldeinformationsmodus: gepoolt, mandantengebunden oder BYOK.
9. Versand an den Anbieter.
10. Erfassen Sie Nutzung, Kosten, Anbieterreferenzen, Fehler und Sicherheitssignale.
11. Gleichsetzen Sie die Budgetreservierung und schreiben Sie das Schlussbuchereignis.

Diese Reihenfolge sorgt dafür, dass das Gateway für den Kundenvertrag verantwortlich ist. Anbieter-Dashboards werden zu Abstimmungseingaben und nicht zur einzigen Quelle der Wahrheit.

Nutzungshauptbuchfelder, die später tatsächlich hilfreich sind

Ein Gateway-Ledger sollte genügend Details enthalten, um Support-, Abrechnungs-, Missbrauchs- und Routing-Fragen zu beantworten, ohne dass standardmäßig eine Rohaufforderungsspeicherung erforderlich ist.

Nützliche Felder sind:

• request_id und trace_id.
• tenant_id, customer_id, application_id und key_id.
• Endnutzer-ID, ggf. vorzugsweise pseudonym.
• Vom Kunden gewünschter Modellalias.
• Upstream-Anbieter und -Modell behoben.
• Eingabe, Ausgabe, Argumentation, zwischengespeichert, Audio, Bild, Video und Tool-Nutzung, sofern zutreffend.
• Angebotene Kosten, reservierter Betrag, abgerechnete Kosten, Währung und Preiskatalogversion.
• Anbieteranforderungs-ID, Referenz zum Nutzungsbericht, Projekt, Arbeitsbereich oder API-Schlüsselgruppierungsdimension, falls verfügbar.
• Aufbewahrungsrichtlinie angewendet.
• Sicherheits-, Missbrauchs- oder Richtlinienentscheidungscodes.
• Fehlerkategorie und Wiederholungsmetadaten.

Diese Struktur unterstützt Rückbuchung, Kundensupport, Reaktion auf Vorfälle und einen API-Schlüsselmanagement-Workflow, der antworten kann: „Was hat dieser Schlüssel bewirkt?“ ohne unabhängige Mieter preiszugeben.

Anmeldeinformationsmodi: gepoolt, mandantengebunden und BYOK

Gepoolte Anbieteranmeldeinformationen

Im Standardmodus werden viele Kundenschlüssel über einen kleineren Satz an Anbieteranmeldeinformationen weitergeleitet. Dies ist betrieblich einfach und reduziert die Ausbreitung auf der Anbieterseite. Es funktioniert, wenn das Gateway über eine starke Mandantenzuordnung, Budgetdurchsetzung, Ratenbegrenzung, Missbrauchsisolierung und Cache-Grenzenkontrollen verfügt.

Der Nachteil besteht darin, dass in der anbieterseitigen Berichterstellung möglicherweise nur die Gateway-Anmeldeinformationen oder das Anbieterprojekt angezeigt werden. Sie müssen Anbieterdatensätze wieder mit Gateway-Ledgerdatensätzen verknüpfen, um Abrechnungen und Analysen auf Kundenebene zu erstellen.

Mandantengebundene Anbieteranmeldeinformationen

Binden Sie bei größeren oder risikoreicheren Mandanten einen Mandanten an ein dediziertes Anbieterprojekt, einen Arbeitsbereich, ein Dienstkonto oder einen Schlüssel. Dies sorgt für eine stärkere Upstream-Trennung und kann die anbieterseitige Berichterstattung vereinfachen. Es kann auch eine harte Kontingentsicherung bieten, wenn der Anbieter Grenzwerte an dieser Grenze unterstützt.

Die Kosten sind die betriebliche Komplexität. Bereitstellung, Rotation, Anbieterlimits, Reaktion auf Vorfälle und Abgleich erfolgen jetzt über mehrere Upstream-Objekte hinweg.

Bringen Sie Ihren eigenen Schlüssel mit

BYOK kann nützlich sein, wenn Kunden das Anbieterkonto besitzen, ihren eigenen Anbietervertrag aushandeln oder die Abrechnung durch den Anbieter getrennt halten müssen. Das Gateway wendet nach Möglichkeit weiterhin Modellprofile, Routing-Richtlinien, Analysen und Kontrollen auf Anwendungsebene an.

Der Kompromiss ist die Komplexität der Unterstützung. Das Anbieterkonto jedes Kunden kann über unterschiedliche Zugriffsmodelle, Kontingente, Preise, Aufbewahrungseinstellungen und Vorfallstatus verfügen. Das Gateway muss diese Unterschiede klar erkennen und erklären.

Widerruf und Quarantäne

Der Widerruf sollte neue Anfragen nach einem Kundenschlüssel sofort blockieren, ohne dass die Anmeldeinformationen unabhängiger Upstream-Anbieter rotiert werden. Dies ist einer der Hauptvorteile virtueller Schlüssel.

Verwenden Sie separate Zustände für verschiedene operative Aktionen:

• aktiv: Anfragen sind erlaubt.
• Draining: Der alte Schlüssel wird während eines Rotationsfensters akzeptiert, es werden jedoch Warnungen und Prüfereignisse ausgegeben.
• widerrufen: Neue Anfragen werden dauerhaft abgelehnt.
• unter Quarantäne gestellt: Neue Anfragen werden aufgrund von Missbrauch, Zahlung, Richtlinien oder Reaktion auf Vorfälle blockiert.
• abgelaufen: Schlüssel hat seine Lebensdauer überschritten und muss ersetzt werden.

Die Quarantäne sollte umkehrbar sein, wenn der Vorfall behoben ist. Der Widerruf sollte in der Regel nicht rückgängig gemacht werden können, da die Wiederherstellung alter Geheimnisse Verwirrung und Risiko erhöht.

Wenn ein Schlüssel gegen die Nutzungsrichtlinie verstößt, protokollieren Sie den Grund, den Akteur, die Zeit und den Umfang der Durchsetzung. Wenn die Entscheidung automatisiert wurde, bewahren Sie die Regelversion und die Signale auf, die sie ausgelöst haben. Dadurch bleiben Kundengespräche sachlich.

Rotation ohne Produktionsunterbrechung

Die Schlüsselrotation sollte einen Zwei-Schlüssel-Überlappungs-Workflow verwenden:

1. Erstellen Sie einen Ersatzschlüssel mit demselben Kunden, derselben Anwendung, demselben Modellprofil und denselben Grenzwerten, es sei denn, der Bediener ändert sie absichtlich.
2. Das neue Geheimnis einmal anzeigen.
3. Markieren Sie den alten Schlüssel als entleerend.
4. Akzeptieren Sie beide Schlüssel für einen begrenzten Zeitraum, z. B. 7, 14 oder 30 Tage, je nach Kundenplan und Risiko.
5. Geben Sie Nutzungswarnungen auf dem Entleerungsschlüssel aus.
6. Benachrichtigen Sie den Eigentümer oder Partner-API-Client, wenn der alte Schlüssel kurz vor Ablauf der Frist noch verwendet wird.
7. Widerrufen Sie den alten Schlüssel am Ende des Fensters.
8. Behalten Sie die Zuordnung beider Schlüssel-IDs unter demselben Kunden und derselben Anwendung bei.

Dadurch wird der häufige Fehlermodus vermieden, bei dem eine Sicherheitsverbesserung zu einem Produktionsausfall führt. Rotation ist immer noch eine Kontrolle, aber sie wird zu einem betrieblichen Arbeitsablauf mit Beweisen und Fristen.

Partner-API-Oberfläche

Wenn nachgelagerte Plattformen Kunden programmgesteuert verwalten, legen Sie wichtige Vorgänge über eine Partner-API offen. Die API sollte Idempotenzschlüssel und Prüfereignisse unterstützen, da die Bereitstellung häufig innerhalb von Abrechnungs-, Onboarding- oder CRM-Workflows erfolgt.

Mindestendpunkte:

• POST /customers: Erstellen oder aktualisieren Sie einen Kunden.
• POST /customers/{customer_id}/keys: Schlüssel erstellen.
• GET /customers/{customer_id}/keys: Schlüssel und Status auflisten.
• PATCH /keys/{key_id}: Aktualisierungsbereiche, Besitzer, Limits, Modellprofil oder Status.
• POST /keys/{key_id}/rotate: Ersatz erstellen und alten Schlüssel als entleerend markieren.
• POST /keys/{key_id}/revoke: sofort widerrufen.
• GET /customers/{customer_id}/usage: Gibt Nutzung und Kosten nach Zeitraum, Schlüssel, App, Modell oder Endbenutzerdimension zurück.

Jede mutierende Anfrage sollte einen Idempotenzschlüssel akzeptieren. Für jede Änderung sollte ein Audit-Ereignis mit Akteur, Ziel, Vorher- und Nachher-Feldern, Quell-IP oder Client-Identität und dem Grund (sofern verfügbar) geschrieben werden.

Wann Sie Anbieterprojekte oder Arbeitsbereiche verwenden sollten

Behandeln Sie Gateway-Schlüssel und Anbietergrenzen nicht als sich gegenseitig ausschließend. Sie lösen verschiedene Probleme.

Gateway-Schlüssel für die normale Steuerung auf Kundenebene verwenden:

• Attribution pro Kunde.
• Schlüssel pro Anwendung.
• Budget- und Ratenbeschränkungen.
• Schnelle Federung.
• Rotationsworkflows.
• Nutzungsanalysen und Reseller-Berichte.

Fügen Sie Anbieterprojekte, Arbeitsbereiche oder dedizierte Anbieteranmeldeinformationen hinzu, wenn der Kunde eine stärkere Trennung benötigt:

• Hohes monatliches Volumen, das spezielle Kontingente verdient.
• Regulierte Workloads mit expliziten Aufenthalts- oder Aufbewahrungsanforderungen.
• Vertragliche Rechnungstrennung.
• Harte anbieterseitige Budget- oder Quoten-Backstops.
• Spezielle Missbrauchsüberwachungs- oder Sicherheitsüberprüfungsgrenzen.
• Kundeneigene Anbieterkonten über BYOK.

Der praktische Standard ist eine Gateway-erzwungene Isolation mit selektiven harten Upstream-Grenzen. Dadurch bleibt der gemeinsame Weg einfach und gleichzeitig bleibt ein Eskalationspfad für Kunden erhalten, die mehr Trennung benötigen.

Implementierungs-Checkliste

• Definieren Sie ein Kundenschlüsselschema mit Mandant, Kunde, Anwendung, Umgebung, Eigentümer, Modellprofil, Grenzwerten, Aufbewahrungsrichtlinie und Status.
• Geheimnisse im Ruhezustand hashen und Klartext nur einmal anzeigen.
• Gateway-Schlüssel vom Anmeldeinformationsspeicher des Upstream-Anbieters trennen.
• Lösen Sie jede Anfrage vor dem Versand in Richtlinien um.
• Reservieren Sie das Budget, bevor Sie den Anbieter anrufen, und begleichen Sie es, sobald die endgültige Nutzung bekannt ist.
• Erfassen Sie die Nutzung mit Kunden, Schlüssel, Modell-Alias, Upstream-Modell, Token-Kategorien, Tool-Nutzung, angebotenen Kosten, abgerechneten Kosten und Anbieterreferenzen.
• Implementieren Sie die Status „Aktiv“, „Drainage“, „Widerrufen“, „Quarantäne“ und „Abgelaufen“.
• Unterstützt Zwei-Tasten-Rotationsüberlappung.
• Partner-API-Vorgänge mit Idempotenzschlüsseln verfügbar machen.
• Verwenden Sie Anbieterprojekte oder Arbeitsbereiche nur dann, wenn ihre Betriebskosten gerechtfertigt sind.

Umsetzbare Schlussfolgerung

Die Kundenisolierung für den KI-Zugriff sollte normalerweise beim Gateway-Schlüssel beginnen, nicht beim Anbieterschlüssel. Der Gateway-Schlüssel ist der kundenseitige Vertrag: Er benennt den Mandanten, den Kunden, die Anwendung, das Modellprofil, das Budget, das Ratenlimit, die Aufbewahrungsregel und die Prüfrichtlinie. Der Anbieterschlüssel ist ein Implementierungsdetail hinter diesem Vertrag.

Diese Architektur bietet SaaS-Entwicklern und Reseller-Plattformen einen schnellen Widerruf, genaue Zuordnung, Budgets pro Kunde, kontrollierte Rotation und nützliche Nutzungsanalysen, ohne standardmäßig ein vorgelagertes Anbieterprojekt für jeden Kunden zu erstellen. Verwenden Sie Upstream-Projekte, Arbeitsbereiche, mandantengebundene Anmeldeinformationen oder BYOK, wenn das Risiko, das Volumen, der Standort oder der Vertrag dies erfordern. Erzwingen Sie für den normalen Pfad die Kundenisolation im Gateway-Ledger und in der Richtlinien-Engine und gleichen Sie anschließend die Anbieterdatensätze ab.

Verwandte Lektüre

• idempotente Partner-API-Bereitstellung für Kunden, Schlüssel und Credits