Partnerské API Authorization testy pro portály prodejců AI API

Partner API pro portály distributorů musí předpokládat, že každé ID objektu v požadavku lze zkopírovat, uhodnout, přehrát, zaprotokolovat jinou integrací nebo předat nesprávným personálním nástrojem. Hlavním problémem není to, zda jsou ID zákazníků neprůhledná. Problém je v tom, zda každá akce dokazuje, že volající, partnerský účet, cílový tenant, objekt, vlastnost a stav schválení patří k sobě.

To je nejdůležitější na AI API prodejním portálu, protože API obvykle odhaluje vysoce účinné objekty kontrolní roviny: následné zákazníky, virtuální klíče API, peněženky, úpravy kreditu, exporty využití, webhooky, uživatelé zaměstnanců a nouzové zmrazení. Jediná chybějící kontrola autorizace může umožnit jednomu zákazníkovi přečíst si využití jiným zákazníkem, umožnit tokenu zaměstnanců přesunout kredity mezi nájemníky nebo umožnit tokenu automatizace zrušit klíč, který by nikdy neměl vidět.

Fakt: OWASP API Security 2023 uvádí Broken Object Level Authorization jako API1 a Broken Object Property Level Authorization jako API3. V praxi to znamená, že kontroly na úrovni objektu odpovídají „může tento volající na tento objekt působit? zatímco kontroly na úrovni vlastností odpovídají „může tento volající nastavit nebo přečíst toto pole?“ Oba jsou prvotřídní záležitostí pro design partnera API.

Před psaním testů definujte Authorization smlouvu

Authorization testy jsou užitečné pouze v případě, že testují na základě explicitní smlouvy o zásadách. Začněte s maticí, která popisuje, který aktér může provést kterou akci na který cíl a za jakých podmínek. Nespoléhejte na názvy koncových bodů nebo role uživatelského rozhraní jako zásady.

Užitečná matice má tyto sloupce:

• Typ aktéra: vlastník partnera, administrátor partnera, finanční operátor, operátor podpory, automatizační token, administrátor zákazníka, uživatel pouze pro čtení.
• Partnerský účet: účet distributora nebo agentury, který vlastní vztah se zákazníkem.
• Cílový tenant: účet následného zákazníka se vytváří, fakturuje, kontroluje, pozastavuje nebo maže.
• Typ objektu: zákazník, virtuální klíč, peněženka, záznam v hlavní knize, zpráva o využití, koncový bod webhooku, uživatel personálu, cenový profil, mapování poskytovatele.
• Action: vytvořit, přečíst, vypsat, aktualizovat, zrušit, doplnit, vrátit peníze, exportovat, zmrazit, uvolnit.
• Peněžní autorita: zda akce změní zůstatek, kreditní limit, marži, stav vyrovnání, stav faktury nebo limity útraty.
• Stav schválení: zda je žádost předem schválena, čeká na schválení, dvojí schválení, vypršela její platnost nebo pouze nouzová.

Operátor podpory může mít například povoleno zobrazit maskovaná metadata klíče zákazníka a zmrazit klíč během incidentu, ale nesmí vytvářet kredity, měnit katalog cen, exportovat data o úplném využití nebo uvolnit klíč bez schválení. Finanční operátor může vytvořit úpravu kreditu pro zákazníka vlastněného stejným partnerem, ale pouze v rámci nakonfigurované částky a pouze poté, co existuje záznam o schválení.

Doporučení: zapište matici jako verzovaný artefakt a poté nastavte každý název testu autorizace na řádek nebo pravidlo. Když se zásada změní, rozdíl by měl ukazovat jak změnu smlouvy, tak změnu testu.

Použít reference objektů vázaných tenantem

Neprůhledná ID snižují riziko výčtu, ale neprokazují autorizaci. ID virtuálního klíče, ID peněženky, ID položky účetní knihy, ID exportu použití nebo token kurzoru musí být vyřešeny uvnitř očekávané hranice partnera a tenanta.

Vzor bezpečného vyhledávání je:

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

Nebezpečný vzorec je:

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

Druhá verze opravňuje držení rozsahu, nikoli oprávnění nad cílem. Selže, když platný token pro partnera A odešle ID klíče od partnera B nebo když operátor pro zákazníka A odešle ID peněženky od zákazníka B.

Vazba nájemce by měla pokrývat více než zjevné objekty. Zahrňte tokeny kurzoru pro zprávy o využití, ID exportních úloh, ID koncových bodů webhooku, ID schválení, klíče idempotence a ID úpravy účetní knihy. Tyto objekty se často cítí „vnitřní“, což je přesně důvod, proč se stávají slabými místy.

Vybudujte minimální testovací zařízení pro více nájemců

Používejte záměrně malé zařízení, které usnadňuje vyjádření nesprávného přístupu. Cílem není široký objem dat. Cílem je jasné oddělení.

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

Toto zařízení vám umožňuje otestovat dvě třídy selhání. Za prvé, mezizákaznický přístup stejného partnera, kdy se volající z P1 pokouší dotknout C1B a zároveň jednat na C1A. Za druhé, přístup mezi partnery, kdy se token P1 pokouší dotknout objektů P2.

Doporučení: spustit stejné zařízení proti veřejnému partnerovi API a backendu portálu distributora. Omezení uživatelského rozhraní nechrání přímé API klienty, úlohy na pozadí, devtools prohlížeče ani kompromitované integrační tokeny.

Testovací objekt na úrovni Authorization na každém koncovém bodě s vysokým dopadem

Pro každý koncový bod, který přijímá ID objektu, vytvořte alespoň jeden pozitivní test a několik negativních testů. Pozitivní testy dokazují, že přípravek je platný. Negativní testy dokazují, že hranice platí.

Vytváření a vyhledávání zákazníků

Vytvoření zákazníka obvykle vypadá neškodně, protože cílový tenant ještě neexistuje. Stále potřebuje autorizaci, protože volající se může pokusit vytvořit zákazníky pod jiným partnerem, přiřadit zakázaný cenový profil nebo nastavit interní metadata.

Testovací případy:

• Vlastník partnera může vytvořit zákazníka pod stejným partnerem.
• Token automatizace s rozsahem poskytování služeb zákazníkům může vytvořit zákazníka pod stejným partnerem.
• Token pouze pro podporu nemůže vytvořit zákazníka.
• Token P1 nemůže vytvořit zákazníka s partner_id=P2.
• Token na úrovni zákazníka nemůže obsahovat seznam zákazníků sourozenců.

Vytvoření, odvolání a rotace klíče

Klíčové akce životního cyklu mají velký dopad, protože poskytují runtime přístup a mohou přerušit produkční zátěž. Řídicí roviny poskytovatele běžně odhalují administrativní objekty, jako jsou projekty, pracovní prostory, servisní účty, členové a klíče API prostřednictvím rozhraní API. Vrstva brány nebo distributora by měla zacházet se svými vlastními virtuálními klíči se stejnou péčí.

Testovací případy:

• Automatizace P1 může vytvořit K1A pouze pro C1A, pokud její token zahrnuje rozsah zápisu klíče.
• Podpora P1 nemůže vytvořit K1A, pokud je role podpory pro klíče pouze pro čtení.
• Podpora P1 může zmrazit K1A, pouze pokud je v rozsahu nouzové zmrazení.
• Podpora P1 nemůže odvolat K1B, když kontext požadavku říká C1A.
• P1 plný token nemůže zrušit K2A.
• Správce zákazníka pro C1A nemůže otočit, odhalit ani zrušit K1B.

Pro týmy implementující Partner API automatizaci není důležitým testem jen otázka „má tento token zápis klíče?“ Je to „má tento token zápis klíče pro tohoto partnera, tohoto zákazníka, tento klíč, tento stav a tuto operaci?“

Dobití kreditu a změny v peněžence

Akce na přesun peněz vyžadují přísnější testy než běžné aktualizace. Dobití kreditu může být syntakticky správné a přesto může být neautorizované, protože peněženka patří jinému nájemci, částka překračuje oprávnění, záznam o schválení cílí na jiného zákazníka nebo byl klíč idempotence poprvé použit pro jinou operaci.

Testovací případy:

• P1 finance může po schválení dobít W1A v rámci svého limitu.
• P1 finance nemohou dobít W1B pomocí schválení vytvořeného pro W1A.
• P1 finance nemohou dobít W2A.
• Podpora P1 nemůže dobít žádnou peněženku.
• Automatizační token nemůže změnit kreditní limit, pokud nemá explicitní rozsah pohybu peněz.
• Zopakovaný klíč idempotence nemůže přesměrovat předchozí dobití W1A na W1B.

Doporučení: zacházet s klíči idempotency jako s rozsahem partner plus operace plus cílový tenant plus normalizované tělo požadavku. Opakování by mělo být bezpečné, ale nemělo by se stát kanálem pro kolizi mezi nájemci.

Přehledy využití a export kurzorů

Zprávy o využití lze snadno podchránit, protože jsou pouze pro čtení. V systémech prodejců mohou údaje o použití odhalit jména zákazníků, pracovní vytížení, výběr modelů, náklady, identifikátory koncových uživatelů a obchodní marže. Cursor tokeny a exportní ID musí být také svázány s tenantem.

Testovací případy:

• Administrátor C1A může číst segmenty využití C1A.
• Administrátor C1A nemůže číst využití C1B změnou customer_id.
• Analytický token P1 pouze pro čtení může exportovat využití pro zákazníky P1, pouze pokud je k dispozici rozsah exportu.
• Token P1 nemůže obnovit export využití P2 se zkopírovaným kurzorem.
• Kurzor vytvořený pro přehled na úrovni klíče nelze znovu použít k načtení použití v rámci celého tenanta, pokud to není výslovně povoleno.

Pokud portál odhaluje AI API měření využití zákazníků, otestujte souhrnná zobrazení i exporty ke stažení. Cesty exportu často obcházejí stejný řadič nebo kód zásad, jaký používají interaktivní stránky.

Test Property-Level Authorization on PATCH and Update Endpoints

Úroveň vlastnosti poškozeného objektu Authorization se zobrazí, když je volajícímu povoleno aktualizovat objekt, ale může také nastavit pole, která by měla být interní, privilegovaná nebo vlastněná jiným pracovním postupem.

V případě rozhraní API pro partnery mezi citlivá pole často patří:

• partner_id, customer_id a pole rodičovského vlastnictví.
• provider_project_id, provider_workspace_id a upstream klíčové reference.
• pricing_catalog_version, margin_tier a přepisy slev.
• wallet_balance, credit_limit, settlement_status a stav faktury.
• fraud_status, risk_score a příznaky souladu.
• role, scopes a příznaky vynechání schválení.

Používejte seznamy povolených, nikoli seznamy odmítnutých. Koncový bod aktualizace profilu zákazníka může například povolit display_name, billing_email a metadata.external_reference. Měl by odmítnout nebo ignorovat margin_tier, credit_limit a provider_project_id, i když volající může objekt zákazníka aktualizovat.

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

Očekávaný výsledek by měl být deterministický. Preferujte chybu ověření, která identifikuje nepovolená pole, aniž by odhalila citlivé vnitřní hodnoty. Nepřijímejte potichu privilegovaná pole a poté je ignorujte, pokud vaše API smlouva již tento vzor konzistentně nepoužívá.

Make Denials Non-Enumerating

Negativní testy by měly zkontrolovat stavové kódy i tvar odpovědi. Pokud token P1 požaduje K2A, odpověď by neměla odhalit, zda K2A existuje pod jiným partnerem.

Obvyklé pravidlo je:

• Pokud volající není ověřen, použijte 401.
• Použijte 403, když je volající ověřen, ale postrádá rozsah akce ve vlastním ohraničení.
• Pokud je objekt mimo hranice volajícího a jeho existence by neměla být odhalena, použijte 404 nebo obecnou odpověď nenalezeno.

Přesná konvence se může lišit, ale chování musí být konzistentní. Tělo odmítnutí by se mělo vyhnout zprávám jako „klíč patří jinému zákazníkovi“ nebo „peněženka existuje pod partnerem P2“. Tyto informace jsou užitečné pro útočníky a zřídka užitečné pro legitimní klienty.

Trade-off: Obecná zamítnutí ztěžují partnerským vývojářům ladění. Vyřešte to pomocí ID požadavků, strukturovaných protokolů auditu a podpůrných nástrojů, nikoli únikem existence mezi klienty ve veřejných API chybách.

Zaznamenejte Authorization rozhodnutí, necitlivé užitečné zatížení

Authorization testy by také měly potvrdit, že odmítnutí poskytují užitečné interní důkazy. Potřebujete dostatek podrobností, abyste mohli rekonstruovat, co se stalo během incidentu, aniž byste ukládali nezpracované výzvy, tajemství nebo zbytečná data zákazníků.

Pole protokolu by měla obsahovat:

• request_id a ID korelace trasování.
• actor_id, typ aktéra, ID tokenu a šablona role.
• partner_id od ověřeného herce.
• Požadovaný cílový tenant a vyřešený cílový tenant, když je řešení povoleno.
• Typ objektu a akce.
• Verze zásad a výsledek rozhodnutí.
• Kód důvodu odmítnutí, například missing_scope, tenant_mismatch, approval_required nebo field_not_allowed.

Neprotokolujte úplné API klíče, tajná tajemství poskytovatele upstream, výzvy, nezpracovaná data využití ani úplný obsah exportu. U zamítnutých požadavků mezi klienty buďte opatrní, aby interní protokoly byly řízeny přístupem; veřejná reakce může být obecná, zatímco bezpečnostní tým má stále dostatek důkazů.

Automatizujte kabeláž v CI a Staging

Testovací svazek by měl probíhat na třech místech: jednotkové testy pro funkce zásad, integrační testy pro API koncové body a zkušební testy s nasazeným backendem portálu distributora. Každá vrstva zachytí různé chyby.

Praktická struktura CI:

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

Každý řádek matice by měl definovat aktéra, požadavek, očekávané rozhodnutí a očekávané chování bez výčtu.

- 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

Přidejte varianty ve stylu mutace, které zaměňují jeden identifikátor za druhým: ID zákazníka, ID klíče, ID peněženky, ID schválení, kurzor, klíč idempotence a ID koncového bodu webhooku. Tyto testy se opakují podle návrhu. Opakování je přijatelné, pokud prokazuje, že každý identifikátor má nezávislý rozsah.

Provozní kontrolní seznam

Před odesláním koncového bodu partnera API použijte tento kontrolní seznam:

• Koncový bod má v matici zásad pojmenované autorizační pravidlo.
• Každé vyhledávání objektů zahrnuje okrajové podmínky partnera a tenanta.
• Každý koncový bod seznamu se před stránkováním filtruje podle hranice aktéra.
• Rozsah se vztahuje na každý kurzor, ID exportu, ID webhooku, ID schválení a klíč idempotence.
• Koncové body PATCH používají seznamy povolených vlastností podle role a akce.
• Akce spojené s přesunem peněz vyžadují explicitní rozsah a stav schválení.
• Nouzové zmrazení je odděleno od uvolnění a úvěrové autority.
• Odepření zabrání únikům existence mezi nájemci.
• Protokoly auditu zaznamenávají rozhodnutí o autorizaci a verzi zásad.
• Stejné negativní testy probíhají proti API a backendovým cestám portálu.

Výhody, které se rozhodnou explicitně

Jemné zaměřovače snižují rádius výbuchu, ale zvyšují složitost partnerské registrace. Výchozí šablony rolí pomáhají: vlastník, finance, podpora, analytika, automatizace poskytování a reakce na mimořádné události. Nechte pokročilé partnery přizpůsobit se z těchto šablon, místo abyste začínali od nezpracovaných rozsahů.

Přísné seznamy povolených vlastností zpomalují zavádění funkcí, protože každé nové upravitelné pole vyžaduje změnu zásad. Toto tření je užitečné pro pole fakturace, cen, mapování poskytovatelů a správy klíčů. U polí profilu s nízkým rizikem může být proces jednodušší.

Toky schvalování snižují náhodné nebo škodlivé změny kreditu, ale zvyšují latenci legitimních podpůrných operací. Udržujte nouzové zmrazení rychlé, reverzibilní a oddělené. Nedovolte, aby stejný nouzový token přidával kredity, měnil marže, exportoval použití a rozmrazoval účty.

Prediction: Distributorské portály budou prostřednictvím rozhraní API pro partnery nadále odhalovat více administrativních akcí, protože zákazníci očekávají samoobslužné poskytování, vytváření sestav a automatizaci. Systémy, které stárnou dobře, budou systémy s autorizačními smlouvami a negativními testy, nikoli systémy, které se spoléhají pouze na pojmenování cest, skryté ovládací prvky uživatelského rozhraní nebo neprůhledná ID.

Akční závěr

Vytvořte autorizační svazek dříve, než bude partner API dostatečně velký, aby měl každý koncový bod svou vlastní výjimku. Začněte se dvěma partnery, dvěma zákazníky pod jedním partnerem, jedním zákazníkem s dalším partnerem a malou sadou tokenů. Pak otestujte akce, které vám mohou nejvíce ublížit: vytvoření klíče, zrušení klíče, dobití kreditu, export využití, aktualizace peněženky, opětovné použití schválení, přehrání idempotence a pole PATCH.

Stanovení smlouvy je jednoduché: volající musí mít správný rozsah, pod správným partnerem, pro správného nájemce, objekt, majetek, akci, částku a stav schválení. Implementační práce to potvrzuje na všech koncových bodech, včetně těch nudných.

Související čtení

• idempotentní partner API automatizace zřizování klíčů a kreditů