Partner API Authorization Tests für AI API Reseller-Portale

Ein Partner API für Reseller-Portale muss davon ausgehen, dass jede Objekt-ID in einer Anfrage kopiert, erraten, wiedergegeben, von einer anderen Integration protokolliert oder durch das falsche Mitarbeitertool weitergeleitet werden kann. Das Kernproblem besteht nicht darin, ob Kunden-IDs undurchsichtig sind. Das Problem besteht darin, ob jede Aktion beweist, dass Aufrufer, Partnerkonto, Zielmandant, Objekt, Eigenschaft und Genehmigungsstatus zusammengehören.

Dies ist in einem AI API-Reseller-Portal am wichtigsten, da API in der Regel hochwirksame Objekte auf der Steuerungsebene offenlegt: Downstream-Kunden, virtuelle API Schlüssel, Wallets, Kreditanpassungen, Nutzungsexporte, Webhook-Ziele, Mitarbeiterbenutzer und Notfalleinfrierungen. Eine einzige fehlende Autorisierungsprüfung kann dazu führen, dass ein Kunde die Nutzung eines anderen Kunden liest, ein Mitarbeiter-Token Guthaben zwischen Mandanten verschiebt oder ein Automatisierungs-Token einen Schlüssel widerruft, den er niemals sehen sollte.

Fakt: OWASP API Security 2023 listet Broken Object Level Authorization als API1 und Broken Object Property Level Authorization als API3 auf. In der Praxis antworten Prüfungen auf Objektebene: „Kann dieser Aufrufer auf dieses Objekt reagieren?“ während Prüfungen auf Eigenschaftsebene antworten: „Kann dieser Aufrufer dieses Feld festlegen oder lesen?“ Beides sind erstklassige Anliegen für Partner API design.

Definieren Sie den Authorization Vertrag, bevor Sie Tests schreiben

Authorization Tests sind nur dann sinnvoll, wenn sie anhand eines expliziten Richtlinienvertrags testen. Beginnen Sie mit einer Matrix, die beschreibt, welcher Akteur unter welchen Bedingungen welche Aktion auf welches Ziel ausführen kann. Verlassen Sie sich nicht auf Endpunktnamen oder UI-Rollen als Richtlinie.

Eine nützliche Matrix hat diese Spalten:

• Akteurstyp: Partnereigentümer, Partneradministrator, Finanzbetreiber, Supportbetreiber, Automatisierungstoken, Kundenadministrator, schreibgeschützter Kundenbenutzer.
• Partnerkonto: das Reseller- oder Agenturkonto, das Eigentümer der nachgelagerten Kundenbeziehung ist.
• Zielmandant: das nachgelagerte Kundenkonto, das erstellt, in Rechnung gestellt, geprüft, gesperrt oder gelöscht wird.
• Objekttyp: Kunde, virtueller Schlüssel, Wallet, Hauptbucheintrag, Nutzungsbericht, Webhook-Endpunkt, Mitarbeiterbenutzer, Preisprofil, Anbieterzuordnung.
• Aktion: erstellen, lesen, auflisten, aktualisieren, widerrufen, aufladen, erstatten, exportieren, einfrieren, freigeben.
• Währungsbefugnis: ob die Aktion den Kontostand, das Kreditlimit, die Marge, den Abrechnungsstatus, den Rechnungsstatus oder die Ausgabenobergrenzen ändert.
• Genehmigungsstatus: ob die Anfrage vorab genehmigt ist, auf Genehmigung wartet, doppelt genehmigt, abgelaufen oder nur für den Notfall gilt.

Zum Beispiel könnte es einem Support-Mitarbeiter gestattet sein, die maskierten Schlüsselmetadaten eines Kunden einzusehen und einen Schlüssel während eines Vorfalls einzufrieren, jedoch kein Guthaben zu erstellen, den Preiskatalog zu ändern, vollständige Nutzungsdaten zu exportieren oder den Schlüssel ohne Genehmigung freizugeben. Ein Finanzdienstleister erstellt möglicherweise eine Kreditanpassung für einen Kunden, der demselben Partner gehört, jedoch nur innerhalb eines konfigurierten Betrags und nur nachdem ein Genehmigungsdatensatz vorhanden ist.

Empfehlung: Schreiben Sie die Matrix als versioniertes Artefakt und verweisen Sie dann darauf, dass jeder Autorisierungstestname auf eine Zeile oder Regel verweist. Wenn sich eine Richtlinie ändert, sollte das Diff sowohl die Vertragsänderung als auch die Teständerung anzeigen.

Mandantengebundene Objektreferenzen verwenden

Undurchsichtige IDs verringern das Aufzählungsrisiko, beweisen jedoch keine Autorisierung. Eine virtuelle Schlüssel-ID, Wallet-ID, Ledger-Eintrags-ID, Nutzungsexport-ID oder Cursor-Token muss innerhalb der erwarteten Partner- und Mandantengrenze aufgelöst werden.

Ein sicheres Suchmuster ist:

resolve object where
  object.id = request.object_id
  and object.partner_id = actor.partner_id
  and object.customer_id = request.customer_id
  and actor has action_scope for object_type/action
  and object.state allows action

Das gefährliche Muster ist:

object = find_by_id(request.object_id)
if actor.has_scope("keys:revoke"):
  revoke(object)

Die zweite Version autorisiert den Besitz eines Bereichs, nicht die Autorität über das Ziel. Es schlägt fehl, wenn ein gültiges Token für Partner A eine Schlüssel-ID von Partner B übermittelt oder wenn ein Operator für Kunde A eine Wallet-ID von Kunde B übermittelt.

Die Mandantenbindung sollte mehr als die offensichtlichen Objekte abdecken. Fügen Sie Cursor-Tokens für Nutzungsberichte, Exportauftrags-IDs, Webhook-Endpunkt-IDs, Genehmigungs-IDs, Idempotenzschlüssel und Ledger-Anpassungs-IDs hinzu. Diese Objekte fühlen sich oft „innerlich“ an, was genau der Grund ist, warum sie zu Schwachstellen werden.

Erstellen Sie eine minimale mandantenübergreifende Testvorrichtung

Verwenden Sie eine bewusst kleine Vorrichtung, die es leicht macht, falsche Zugriffe auszudrücken. Das Ziel ist nicht ein breites Datenvolumen. Das Ziel ist eine klare Trennung.

Partner P1
  Staff: p1_owner, p1_support, p1_finance
  Token: p1_full_token, p1_support_token, p1_finance_token
  Customer C1A
    Key K1A
    Wallet W1A
    Usage cursor U1A
    Ledger entry L1A
  Customer C1B
    Key K1B
    Wallet W1B
    Usage cursor U1B
    Ledger entry L1B

Partner P2
  Staff: p2_owner
  Token: p2_full_token
  Customer C2A
    Key K2A
    Wallet W2A
    Usage cursor U2A
    Ledger entry L2A

Mit diesem Gerät können Sie zwei Fehlerklassen testen. Erstens der kundenübergreifende Zugriff über denselben Partner, bei dem ein Anrufer von P1 versucht, C1B zu berühren, während er auf C1A reagiert. Zweitens: Partnerübergreifender Zugriff, bei dem ein P1-Token versucht, die Objekte von P2 zu berühren.

Empfehlung: Führen Sie dasselbe Fixture für den öffentlichen Partner API und das Reseller-Portal-Backend aus. UI-Einschränkungen schützen keine direkten API Clients, Hintergrundjobs, Browser-Devtools oder kompromittierte Integrationstokens.

Testen Sie Objektebene Authorization auf jedem High-Impact-Endpunkt

Erstellen Sie für jeden Endpunkt, der eine Objekt-ID akzeptiert, mindestens einen positiven Test und mehrere negative Tests. Positive Tests beweisen, dass die Vorrichtung gültig ist. Negative Tests beweisen, dass die Grenze gilt.

Kundenerstellung und -suche

Die Kundenerstellung sieht normalerweise harmlos aus, da der Zielmandant noch nicht existiert. Es ist weiterhin eine Autorisierung erforderlich, da der Anrufer möglicherweise versucht, Kunden unter einem anderen Partner anzulegen, ein verbotenes Preisprofil zuzuweisen oder interne Metadaten festzulegen.

Testfälle:

• Ein Partnerinhaber kann einen Kunden unter demselben Partner erstellen.
• Ein Automatisierungstoken mit Kundenbereitstellungsbereich kann einen Kunden unter demselben Partner erstellen.
• Ein Nur-Support-Token kann keinen Kunden erstellen.
• Ein P1-Token kann keinen Kunden mit partner_id=P2 erstellen.
• Ein Token auf Kundenebene kann keine Geschwisterkunden auflisten.

Schlüsselerstellung, -widerruf und -rotation

Wichtige Lebenszyklusaktionen haben große Auswirkungen, da sie Laufzeitzugriff gewähren und Produktionsarbeitslasten unterbrechen können. Anbietersteuerungsebenen stellen häufig Verwaltungsobjekte wie Projekte, Arbeitsbereiche, Dienstkonten, Mitglieder und API-Schlüssel über APIs zur Verfügung. Eine Gateway- oder Reseller-Ebene sollte ihre eigenen virtuellen Schlüssel mit der gleichen Sorgfalt behandeln.

Testfälle:

• P1-Automatisierung kann K1A nur für C1A erstellen, wenn sein Token den Schlüsselschreibbereich umfasst.
• Der P1-Support kann K1A nicht erstellen, wenn die Supportrolle für Schlüssel schreibgeschützt ist.
• P1-Unterstützung kann K1A nur einfrieren, wenn ein Notfall-Einfrieren im Geltungsbereich liegt.
• P1-Unterstützung kann K1B nicht widerrufen, wenn der Anforderungskontext C1A lautet.
• P1-Volltoken kann K2A nicht widerrufen.
• Ein Kundenadministrator für C1A kann K1B nicht rotieren, offenlegen oder widerrufen.

Für Teams, die Partner API-Automatisierung implementieren, ist der wichtige Test nicht nur „Verfügt dieser Token über Schlüsselschreibfunktion?“ Es lautet: „Verfügt dieses Token über Schlüssel-Schreibzugriff für diesen Partner, diesen Kunden, diesen Schlüssel, diesen Status und diesen Vorgang?“

Guthabenaufladungen und Wallet-Änderungen

Geldbewegende Maßnahmen erfordern strengere Tests als gewöhnliche Aktualisierungen. Eine Guthabenaufladung kann syntaktisch korrekt sein und dennoch nicht autorisiert sein, weil das Wallet einem anderen Mieter gehört, der Betrag die Autorität überschreitet, der Genehmigungsdatensatz auf einen anderen Kunden abzielt oder der Idempotenzschlüssel zunächst für einen anderen Vorgang verwendet wurde.

Testfälle:

• P1 Finance kann W1A nach Genehmigung innerhalb seiner Betragsgrenze aufstocken.
• P1 Finance kann W1B nicht mit einer für W1A erstellten Genehmigung aufladen.
• P1-Finanzierung kann W2A nicht aufladen.
• Der P1-Support kann kein Wallet aufladen.
• Ein Automatisierungstoken kann das Kreditlimit nicht ändern, es sei denn, es hat einen expliziten Geldbewegungsbereich.
• Ein wiederholter Idempotenzschlüssel kann eine vorherige W1A-Aufladung nicht auf W1B umleiten.

Empfehlung: Behandeln Sie Idempotenzschlüssel als auf Partner plus Vorgang plus Zielmandanten plus normalisierten Anforderungstext beschränkt. Ein erneuter Versuch sollte sicher sein, aber nicht zu einem mandantenübergreifenden Kollisionskanal werden.

Nutzungsberichte und Exportcursor

Nutzungsberichte können leicht unzureichend geschützt werden, da sie schreibgeschützt sind. In Reseller-Systemen können Nutzungsdaten Kundennamen, Arbeitslasten, Modellauswahl, Kosten, Endbenutzer-Identifikatoren und kommerzielle Margen offenlegen. Cursor Token und Export-IDs müssen ebenfalls mandantengebunden sein.

Testfälle:

• C1A-Administrator kann C1A-Nutzungs-Buckets lesen.
• Der C1A-Administrator kann die C1B-Nutzung nicht lesen, indem er customer_id ändert.
• Das schreibgeschützte P1-Analysetoken kann die Nutzung für P1-Kunden nur dann exportieren, wenn ein Exportbereich vorhanden ist.
• P1-Token kann einen P2-Nutzungsexport mit einem kopierten Cursor nicht fortsetzen.
• Ein für einen Bericht auf Schlüsselebene erstellter Cursor kann nicht wiederverwendet werden, um die mandantenweite Nutzung abzurufen, sofern dies nicht ausdrücklich erlaubt ist.

Wenn das Portal AI APIKundennutzungsmessung verfügbar macht, testen Sie sowohl die Zusammenfassungsansichten als auch die herunterladbaren Exporte. Exportpfade umgehen häufig denselben Controller oder Richtliniencode, der von interaktiven Seiten verwendet wird.

Property-Level Authorization auf PATCH- und Update-Endpunkten testen

Broken Object Property Level Authorization erscheint, wenn ein Aufrufer ein Objekt aktualisieren darf, kann aber auch Felder festlegen, die intern, privilegiert oder im Besitz eines anderen Workflows sein sollten.

Bei Partner-APIs umfassen vertrauliche Felder häufig:

• partner_id, customer_id und übergeordnete Eigentumsfelder.
• provider_project_id, provider_workspace_id und Upstream-Schlüsselreferenzen.
• pricing_catalog_version, margin_tier und Rabattüberschreibungen.
• wallet_balance, credit_limit, settlement_status und Rechnungsstatus.
• fraud_status, risk_score und Compliance-Flags.
• role, scopes und Genehmigungsumgehungsflags.

Verwenden Sie Zulassungslisten, keine Ablehnungslisten. Beispielsweise könnte ein Kundenprofilaktualisierungsendpunkt display_name, billing_email und metadata.external_reference zulassen. Es sollte margin_tier, credit_limit und provider_project_id ablehnen oder ignorieren, auch wenn der Aufrufer das Kundenobjekt aktualisieren kann.

PATCH /partner/customers/C1A
{
  "display_name": "Acme Support Team",
  "margin_tier": "internal_zero_margin",
  "provider_project_id": "provider-project-owned-by-C1B"
}

Das erwartete Ergebnis sollte deterministisch sein. Bevorzugen Sie einen Validierungsfehler, der unzulässige Felder identifiziert, ohne vertrauliche interne Werte preiszugeben. Akzeptieren Sie privilegierte Felder nicht stillschweigend und ignorieren Sie sie dann, es sei denn, Ihr API Vertrag verwendet dieses Muster bereits konsequent.

Ablehnungen nicht aufzählen

Negative Tests sollten sowohl Statuscodes als auch Antwortform prüfen. Wenn ein P1-Token K2A anfordert, sollte die Antwort nicht verraten, ob K2A unter einem anderen Partner existiert.

Eine gängige Regel ist:

• Verwenden Sie 401, wenn der Anrufer nicht authentifiziert ist.
• Verwenden Sie 403, wenn der Aufrufer authentifiziert ist, aber keinen Aktionsbereich in seiner eigenen Grenze hat.
• Verwenden Sie 404 oder eine generische Nicht-Gefunden-Antwort, wenn sich das Objekt außerhalb der Grenzen des Aufrufers befindet und seine Existenz nicht preisgegeben werden soll.

Die genaue Konvention kann variieren, das Verhalten muss jedoch konsistent sein. Die Ablehnungsstelle sollte Meldungen wie „Schlüssel gehört einem anderen Kunden“ oder „Wallet existiert unter Partner P2“ vermeiden. Diese Informationen sind für Angreifer nützlich, für legitime Clients jedoch selten.

Kompromiss: Generische Ablehnungen erschweren das Debuggen für Partnerentwickler. Lösen Sie das Problem mit Anforderungs-IDs, strukturierten Audit-Protokollen und Support-Tools, und nicht dadurch, dass Sie die mandantenübergreifende Existenz in öffentlichen API Fehlern durchsickern lassen.

Protokollieren Sie die Authorization Entscheidung, keine sensiblen Nutzlasten

Authorization-Tests sollten auch bestätigen, dass Ablehnungen nützliche interne Beweise liefern. Sie benötigen genügend Details, um zu rekonstruieren, was während eines Vorfalls passiert ist, ohne rohe Eingabeaufforderungen, Geheimnisse oder unnötige Kundendaten zu speichern.

Protokollfelder sollten Folgendes enthalten:

• request_id und Trace-Korrelations-ID.
• actor_id, Akteurtyp, Token-ID und Rollenvorlage.
• partner_id vom authentifizierten Akteur.
• Angeforderter Zielmandant und gelöster Zielmandant, wenn die Auflösung zulässig ist.
• Objekttyp und Aktion.
• Richtlinienversion und Entscheidungsergebnis.
• Ablehnungsgrundcode, z. B. missing_scope, tenant_mismatch, approval_required oder field_not_allowed.

Es werden keine vollständigen API Schlüssel, Geheimnisse des Upstream-Anbieters, Eingabeaufforderungen, Rohnutzungsnutzlasten oder vollständige Exportinhalte protokolliert. Achten Sie bei abgelehnten mandantenübergreifenden Anforderungen darauf, dass der Zugriff auf die internen Protokolle kontrolliert wird. Die öffentliche Reaktion kann allgemein gehalten sein, solange das Sicherheitsteam noch über genügend Beweise verfügt.

Automatisieren Sie die Nutzung von CI und Staging

Die Testumgebung sollte an drei Stellen ausgeführt werden: Komponententests für Richtlinienfunktionen, Integrationstests für API Endpunkte und Staging-Tests für das bereitgestellte Reseller-Portal-Backend. Jede Schicht fängt unterschiedliche Fehler ab.

Eine praktische CI-Struktur:

authz-tests/
  fixtures/
    partners.json
    customers.json
    roles.json
    tokens.json
  matrix/
    keys.yaml
    wallets.yaml
    usage_exports.yaml
    customers.yaml
  tests/
    test_keys_authz.ts
    test_wallet_authz.ts
    test_usage_authz.ts
    test_patch_allowlists.ts

Jede Matrixzeile sollte den Akteur, die Anfrage, die erwartete Entscheidung und das erwartete nicht aufzählende Verhalten definieren.

- name: p1_support_cannot_revoke_p2_key
  actor: p1_support_token
  method: POST
  path: /partner/customers/C2A/keys/K2A/revoke
  expected_status: 404
  expected_error_code: not_found
  expected_audit_reason: tenant_mismatch

Fügen Sie Varianten im Mutationsstil hinzu, die jeweils eine Kennung austauschen: Kunden-ID, Schlüssel-ID, Wallet-ID, Genehmigungs-ID, Cursor, Idempotenzschlüssel und Webhook-Endpunkt-ID. Diese Tests sind von Natur aus repetitiv. Eine Wiederholung ist akzeptabel, wenn sie beweist, dass jede Kennung einen unabhängigen Gültigkeitsbereich hat.

Betriebscheckliste

Bevor Sie einen Partner API-Endpunkt versenden, verwenden Sie diese Checkliste:

• Der Endpunkt verfügt über eine benannte Autorisierungsregel in der Richtlinienmatrix.
• Jede Objektsuche umfasst Partner- und Mandanten-Randbedingungen.
• Jeder Listenendpunkt wird vor der Paginierung nach Akteursgrenze gefiltert.
• Jeder Cursor, jede Export-ID, jede Webhook-ID, jede Genehmigungs-ID und jeder Idempotenzschlüssel hat einen Gültigkeitsbereich.
• PATCH-Endpunkte verwenden Eigenschaftszulassungslisten nach Rolle und Aktion.
• Geldbewegende Maßnahmen erfordern einen expliziten Umfang und Genehmigungsstatus.
• Notfall-Einfrieren ist von Auftauen und Kreditautorität getrennt.
• Ablehnungen vermeiden mandantenübergreifende Existenzlecks.
• Überwachungsprotokolle zeichnen die Autorisierungsentscheidung und die Richtlinienversion auf.
• Die gleichen negativen Tests werden für API und Portal-Backend-Pfade ausgeführt.

Kompromisse zur expliziten Entscheidung

Fein abgestimmte Bereiche verringern den Explosionsradius, erhöhen jedoch die Komplexität des Partner-Onboardings. Standardrollenvorlagen helfen: Eigentümer, Finanzen, Support, Analysen, Bereitstellungsautomatisierung und Notfallreaktion. Lassen Sie fortgeschrittene Partner Anpassungen anhand dieser Vorlagen vornehmen, anstatt mit Rohbereichen zu beginnen.

Strenge Zulassungslisten für Eigenschaften verlangsamen die Einführung von Funktionen, da jedes neue bearbeitbare Feld eine Richtlinienänderung erfordert. Diese Reibung ist nützlich für die Bereiche Abrechnung, Preisgestaltung, Anbieterzuordnung und Schlüsselverwaltung. Für Felder mit geringem Risikoprofil kann der Prozess einfacher sein.

Genehmigungsabläufe reduzieren versehentliche oder böswillige Kreditänderungen, erhöhen jedoch die Latenz bei legitimen Supportvorgängen. Sorgen Sie dafür, dass das Einfrieren im Notfall schnell, reversibel und separat geregelt ist. Lassen Sie nicht zu, dass mit demselben Notfall-Token Guthaben hinzugefügt, Margen geändert, die Nutzung exportiert und Konten entsperrt werden.

Vorhersage: Reseller-Portale werden weiterhin mehr Verwaltungsvorgänge über Partner-APIs offenlegen, da Kunden Self-Service-Bereitstellung, Berichterstellung und Automatisierung erwarten. Die Systeme, die gut altern, werden diejenigen mit Autorisierungsverträgen und negativen Tests sein, und nicht diejenigen, die allein auf Routenbenennung, versteckten UI-Steuerelementen oder undurchsichtigen IDs basieren.

Umsetzbare Schlussfolgerung

Erstellen Sie den Autorisierungsstrang, bevor der Partner API groß genug wird, dass jeder Endpunkt seine eigene Ausnahme hat. Beginnen Sie mit zwei Partnern, zwei Kunden unter einem Partner, einem Kunden unter einem anderen Partner und einem kleinen Satz Token. Testen Sie dann die Aktionen, die Ihnen am meisten schaden können: Schlüsselerstellung, Schlüsselwiderruf, Guthabenaufladungen, Nutzungsexporte, Wallet-Updates, Wiederverwendung von Genehmigungen, Idempotenzwiederholung und PATCH-Felder.

Der Vertrag ist einfach zu formulieren: Ein Anrufer muss über den richtigen Geltungsbereich, unter dem richtigen Partner, für den richtigen Mieter, das richtige Objekt, die richtige Eigenschaft, die richtige Aktion, den richtigen Betrag und den richtigen Genehmigungsstatus verfügen. Die Implementierungsarbeit sorgt dafür, dass dies auf jedem Endpunkt wahr wird, auch auf den langweiligen.

Verwandte Lektüre

• idempotent Partner API Automatisierung für die Bereitstellung von Schlüsseln und Credits