Партньор API Authorization Тестове за AI API Портали за дистрибутори

Партньор API за портали за дистрибутори трябва да приеме, че всеки идентификатор на обект в заявка може да бъде копиран, познат, възпроизведен, регистриран от друга интеграция или прекаран през грешен инструмент на персонала. Основният проблем не е дали идентификаторите на клиентите са непрозрачни. Проблемът е дали всяко действие доказва, че повикващият, акаунтът на партньора, целевият наемател, обектът, собствеността и състоянието на одобрение са свързани заедно.

Това има най-голямо значение в AI API портал за дистрибутори, тъй като API обикновено излага обекти от контролната равнина с голямо въздействие: клиенти надолу по веригата, виртуални API ключове, портфейли, кредитни корекции, експортиране на използване, дестинации за уеб кукички, потребители на персонала и аварийно замразяване. Една единствена липсваща проверка за оторизация може да позволи на един клиент да прочете използването на друг клиент, да позволи на токен на персонала да премества кредити между наематели или да позволи на токен за автоматизация да отмени ключ, който никога не трябва да вижда.

Факт: OWASP API Security 2023 изброява Ниво на повреден обект Authorization като API1 и Ниво на свойство на повреден обект Authorization като API3. От практическа гледна точка проверките на ниво обект отговарят „може ли този повикващ да действа върху този обект?“ докато проверките на ниво собственост отговарят „може ли този повикващ да зададе или прочете това поле?“ И двете са първокласни грижи за партньор API дизайн.

Дефинирайте Authorization договора, преди да пишете тестове

Authorization тестовете са полезни само ако тестват срещу изричен договор за политика. Започнете с матрица, която описва кой актьор може да извърши какво действие върху коя цел, при какви условия. Не разчитайте на имена на крайни точки или роли на потребителския интерфейс като правило.

Полезната матрица има следните колони:

• Тип актьор: собственик на партньор, администратор на партньор, финансов оператор, оператор по поддръжката, маркер за автоматизация, администратор на клиента, потребител само за четене на клиента.
• Партньорски акаунт: акаунтът на дистрибутор или агенция, който притежава връзката с клиента надолу по веригата.
• Целеви наемател: клиентският акаунт надолу по веригата се създава, таксува, проверява, спира или изтрива.
• Тип на обекта: клиент, виртуален ключ, портфейл, запис в книга, отчет за използването, крайна точка на уебкукичка, потребител на персонала, профил на ценообразуване, съпоставяне на доставчик.
• Действие: създаване, четене, списък, актуализиране, отмяна, допълване, възстановяване на средства, експортиране, замразяване, размразяване.
• Паричен орган: дали действието променя баланса, кредитния лимит, маржа, състоянието на сетълмента, състоянието на фактурата или ограниченията на разходите.
• Състояние на одобрение: дали заявката е предварително одобрена, очаква одобрение, двойно одобрена, с изтекъл срок или само за спешни случаи.

Например, на оператор по поддръжката може да бъде разрешено да преглежда маскираните метаданни за ключ на клиент и да замразява ключ по време на инцидент, но не и да създава кредити, да променя ценовия каталог, да експортира пълни данни за употреба или да размразява ключа без одобрение. Финансов оператор може да създаде кредитна корекция за клиент, притежаван от същия партньор, но само в рамките на конфигурирана сума и само след като съществува запис за одобрение.

Препоръка: запишете матрицата като артефакт с версии, след което направете всяко име на тест за оторизация да препраща към ред или правило. Когато политика се промени, разликата трябва да показва както промяната на договора, така и промяната на теста.

Използване на препратки към обвързани с наемател обекти

Непрозрачните идентификатори намаляват риска от изброяване, но не доказват упълномощаване. Идентификатор на виртуален ключ, идентификационен номер на портфейла, идентификационен номер на запис в книгата, идентификационен номер за експортиране на използване или токен на курсора трябва да бъдат разрешени в очакваната граница на партньор и наемател.

Модел за безопасно търсене е:

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

Опасният модел е:

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

Втората версия разрешава притежание на обхват, а не власт над целта. Той е неуспешен, когато валиден токен за Партньор А подаде ИД на ключ от Партньор Б или когато оператор за Клиент А подаде ИД на портфейла от Клиент Б.

Обвързването на клиента трябва да покрива повече от очевидните обекти. Включете токени на курсора за отчети за използване, идентификатори на задачи за експортиране, идентификатори на крайни точки на уеб кукичка, идентификатори на одобрение, ключове за идемпотентност и идентификатори за коригиране на счетоводна книга. Тези обекти често се чувстват „вътрешни“ и точно затова се превръщат в слаби места.

Изградете минимално тестово устройство за кръстосани наематели

Използвайте умишлено малък фиксатор, който улеснява изразяването на грешен достъп. Целта не е широк обем данни. Целта е ясно разделение.

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

Това приспособление ви позволява да тествате два класа на отказ. Първо, междуклиентски достъп от един и същи партньор, при който повикващ от P1 се опитва да докосне C1B, докато действа на C1A. Второ, междупартньорски достъп, при който P1 токен се опитва да докосне обектите на P2.

Препоръка: стартирайте една и съща програма срещу публичния партньор API и бекенда на портала за дистрибутори. Ограниченията на потребителския интерфейс не защитават директни API клиенти, фонови задания, инструменти за разработка на браузъра или компрометирани токени за интегриране.

Тест на ниво обект Authorization на всяка крайна точка с голямо въздействие

За всяка крайна точка, която приема идентификатор на обект, създайте поне един положителен тест и няколко отрицателни теста. Положителните тестове доказват, че приспособлението е валидно. Отрицателните тестове доказват, че границата е валидна.

Създаване и търсене на клиенти

Създаването на клиент обикновено изглежда безобидно, тъй като целевият клиент все още не съществува. Все още се нуждае от упълномощаване, тъй като обаждащият се може да опита да създаде клиенти под друг партньор, да присвои забранен профил на ценообразуване или да зададе вътрешни метаданни.

Тестови случаи:

• Собственик на партньор може да създаде клиент под същия партньор.
• Ознака за автоматизация с обхват за осигуряване на клиента може да създаде клиент под същия партньор.
• Токен само за поддръжка не може да създаде клиент.
• P1 токен не може да създаде клиент с partner_id=P2.
• Токен на ниво клиент не може да изброява братски клиенти.

Създаване, отмяна и ротация на ключ

Ключовите действия от жизнения цикъл имат голямо въздействие, защото предоставят достъп по време на изпълнение и могат да прекъснат производствените работни натоварвания. Контролните равнини на доставчика обикновено разкриват административни обекти като проекти, работни пространства, акаунти за услуги, членове и API ключове чрез API. Слоят на шлюза или дистрибутора трябва да третира своите собствени виртуални ключове със същото внимание.

Тестови случаи:

• P1 автоматизацията може да създаде K1A само за C1A, когато неговият токен включва обхват за писане на ключ.
• Поддръжката на P1 не може да създаде K1A, ако ролята на поддръжка е само за четене за ключове.
• Поддръжката на P1 може да блокира K1A само ако аварийното замразяване е в обхвата.
• Поддръжката на P1 не може да отмени K1B, когато контекстът на заявката казва C1A.
• P1 пълен токен не може да отмени K2A.
• Администратор на клиент за C1A не може да ротира, разкрива или отменя K1B.

За екипи, внедряващи Партньор API автоматизация, важният тест не е просто „този токен има ли запис на ключ?“ Това е „този токен има ли запис на ключ за този партньор, този клиент, този ключ, това състояние и тази операция?“

Доплащане на кредити и промени в портфейла

Действията за прехвърляне на пари се нуждаят от по-строги тестове от обикновените актуализации. Допълването на кредит може да бъде правилно синтактично и все още да е неупълномощено, защото портфейлът принадлежи на друг наемател, сумата надхвърля пълномощията, записът за одобрение е насочен към друг клиент или ключът за идемпотентност е използван за първи път за различна операция.

Тестови случаи:

• P1 finance може да допълва W1A в рамките на своя лимит на сумата след одобрение.
• P1 finance не може да допълва W1B с помощта на одобрение, създадено за W1A.
• P1 Finance не може да допълва W2A.
• Поддръжката на P1 не може да допълва портфейла.
• Означението за автоматизация не може да променя кредитния лимит, освен ако няма изричен обхват за преместване на пари.
• Повторен ключ за идемпотентност не може да пренасочи предишно презареждане W1A към W1B.

Препоръка: третирайте ключовете за идемпотентност като обхват на партньор плюс операция плюс целеви наемател плюс нормализирано тяло на заявка. Повторният опит трябва да е безопасен, но не трябва да се превръща в канал за сблъсък между клиенти.

Отчети за използване и експортирани курсори

Докладите за употреба са лесни за недостатъчна защита, тъй като са само за четене. В системите за дистрибутори данните за употребата могат да разкрият имена на клиенти, натоварвания, избор на модел, разходи, идентификатори на крайни потребители и търговски маржове. Cursor токените и идентификационните номера за експортиране също трябва да бъдат обвързани с клиента.

Тестови случаи:

• C1A администраторът може да чете кофи за използване на C1A.
• C1A администраторът не може да прочете използването на C1B чрез промяна customer_id.
• P1 аналитичният токен само за четене може да експортира използване за P1 клиенти само ако е наличен обхват на експортиране.
• P1 токен не може да възобнови експортиране на използване на P2 с копиран курсор.
• Курсор, създаден за отчет на ниво ключ, не може да се използва повторно за извличане на използване в целия клиент, освен ако не е изрично разрешено.

Ако порталът разкрива AI API измерване на използването на клиентите, тествайте както обобщените изгледи, така и експортирания за изтегляне. Пътищата за експортиране често заобикалят същия контролер или код на правилата, използвани от интерактивните страници.

Тест на ниво на собственост Authorization на PATCH и актуализиране на крайни точки

Ниво на свойство на счупен обект Authorization се появява, когато на повикващия е разрешено да актуализира обект, но може също така да задава полета, които трябва да бъдат вътрешни, привилегировани или притежавани от друг работен процес.

За приложни програмни интерфейси на партньори чувствителните полета често включват:

• partner_id, customer_id и полета за родителска собственост.
• provider_project_id, provider_workspace_id и ключови препратки нагоре по веригата.
• pricing_catalog_version, margin_tier и отмени на отстъпките.
• wallet_balance, credit_limit, settlement_status и състояние на фактурата.
• fraud_status, risk_score и флагове за съответствие.
• role, scopes и флагове за заобикаляне на одобрението.

Използвайте списъци с разрешени, а не списъци за отказ. Например крайна точка за актуализиране на потребителски профил може да позволи display_name, billing_email и metadata.external_reference. Той трябва да отхвърли или игнорира margin_tier, credit_limit и provider_project_id, дори ако повикващият може да актуализира клиентския обект.

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

Очакваният резултат трябва да бъде детерминистичен. Предпочитайте грешка при валидиране, която идентифицира непозволени полета, без да разкрива чувствителни вътрешни стойности. Не приемайте мълчаливо привилегировани полета и след това ги игнорирайте, освен ако вашият API договор вече не използва този модел последователно.

Направете отказите неизброими

Отрицателните тестове трябва да проверяват както кодовете за състояние, така и формата на отговора. Ако токен P1 поиска K2A, отговорът не трябва да разкрива дали K2A съществува под друг партньор.

Общо правило е:

• Използвайте 401, когато повикващият не е удостоверен.
• Използвайте 403, когато повикващият е удостоверен, но няма обхват на действие в собствената си граница.
• Използвайте 404 или общ отговор не е намерен, когато обектът е извън границата на повикващия и съществуването не трябва да се разкрива.

Точната конвенция може да варира, но поведението трябва да е последователно. Основният текст на отказа трябва да избягва съобщения като „ключът принадлежи на друг клиент“ или „портфейлът съществува под партньор P2“. Тази информация е полезна за нападателите и рядко е полезна за законните клиенти.

Компромис: общите откази правят отстраняването на грешки по-трудно за партньорските разработчици. Решете това с идентификатори на заявки, структурирани регистрационни файлове за проверка и инструменти за поддръжка, а не чрез изтичане на съществуване на кръстосани наематели в публични API грешки.

Регистрирайте Authorization решението, нечувствителните полезни натоварвания

Authorization тестовете трябва също да твърдят, че отказите произвеждат полезни вътрешни доказателства. Имате нужда от достатъчно подробности, за да възстановите случилото се по време на инцидент, без да съхранявате необработени подкани, тайни или ненужни данни за клиенти.

Полетата в регистрационния файл трябва да включват:

• request_id и ИД на корелация на проследяване.
• actor_id, тип актьор, ID на токена и шаблон за роля.
• partner_id от удостоверения актьор.
• Заявен целеви наемател и разрешен целеви наемател, когато разрешението е разрешено.
• Тип обект и действие.
• Версия на правилата и резултат от решение.
• Код на причината за отказ, като missing_scope, tenant_mismatch, approval_required или field_not_allowed.

Не записвайте пълни API ключове, тайни на доставчици нагоре по веригата, подкани, необработени полезни данни за използване или пълно експортирано съдържание. За отказани заявки за кръстосани наематели внимавайте вътрешните регистрационни файлове да са с контролиран достъп; общественият отговор може да бъде общ, докато екипът по сигурността все още разполага с достатъчно доказателства.

Автоматизиране на сбруята в CI и етапи

Тестовият пакет трябва да се изпълнява на три места: тестове на единици за функции на политиката, тестове за интегриране за API крайни точки и тестове за етапи срещу внедрения бекенд на портала за дистрибутори. Всеки слой улавя различни грешки.

Практическа 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

Всеки матричен ред трябва да дефинира актьора, заявката, очакваното решение и очакваното поведение без изброяване.

- 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

Добавяне на варианти в стил на мутация, които разменят един по един идентификатор: ИД на клиента, ИД на ключ, ИД на портфейла, ИД на одобрение, курсор, ключ за идемпотентност и ИД на крайна точка на уеб кукичка. Тези тестове са повтарящи се по дизайн. Повторението е приемливо, когато доказва, че всеки идентификатор има независим обхват.

Оперативен контролен списък

Преди да изпратите крайна точка на партньор API, използвайте този контролен списък:

• Крайната точка има наименувано правило за оторизация в матрицата на правилата.
• Всяко търсене на обект включва гранични условия на партньор и наемател.
• Всяка крайна точка на списък филтрира по граница на актьора преди пагиниране.
• Всеки курсор, идентификационен номер за експортиране, идентификационен номер на уебкукичка, идентификационен номер на одобрение и ключ за идемпотентност са с обхват.
• Крайните точки на PATCH използват списъци с разрешени свойства по роля и действие.
• Действията за преместване на пари изискват изричен обхват и състояние на одобрение.
• Спешното замразяване е отделено от размразяването и кредитното разпореждане.
• Отказите избягват изтичане на информация за съществуване между наематели.
• Дневниците за проверка записват решението за оторизация и версията на правилата.
• Същите отрицателни тестове се изпълняват срещу API и пътеки в задната част на портала.

Компромиси за изрично решение

Финно зърнестите прицели намаляват радиуса на взрива, но усложняват включването на партньора. Шаблоните за роли по подразбиране помагат: собственик, финанси, поддръжка, анализи, автоматизация на осигуряване и реакция при спешни случаи. Позволете на напредналите партньори да персонализират от тези шаблони, вместо да започват от необработени обхвати.

Стриктните списъци с разрешени свойства забавят внедряването на функцията, тъй като всяко ново редактируемо поле се нуждае от промяна на правилата. Това триене е полезно за фактуриране, ценообразуване, картографиране на доставчик и полета за управление на ключове. За полета на профил с нисък риск процесът може да бъде по-лек.

Потоците на одобрение намаляват случайните или злонамерени кредитни промени, но добавят забавяне към законните операции по поддръжката. Поддържайте аварийното замразяване бързо, обратимо и с отделен обхват. Не позволявайте на едно и също спешно означение да добавя кредити, да променя маржовете, да експортира използването и да размразява акаунти.

Прогноза: порталите за дистрибутори ще продължат да излагат повече административни действия чрез партньорски API, тъй като клиентите очакват предоставяне на самообслужване, отчитане и автоматизация. Системите, които остаряват добре, ще бъдат тези с договори за оторизация и отрицателни тестове, а не тези, които разчитат само на именуване на маршрути, скрити контроли на потребителския интерфейс или непрозрачни идентификатори.

Приложимо заключение

Изградете системата за оторизация, преди партньорът API да стане достатъчно голям, така че всяка крайна точка да има собствено изключение. Започнете с двама партньори, двама клиента под един партньор, един клиент под друг партньор и малък набор от токени. След това тествайте действията, които могат да ви навредят най-много: създаване на ключ, анулиране на ключ, допълване на кредити, експортиране на използване, актуализации на портфейла, повторно използване на одобрение, повторно възпроизвеждане на идемпотентност и полета PATCH.

Договорът е лесен за посочване: повикващият трябва да има правилния обхват, под правилния партньор, за правилния наемател, обект, собственост, действие, сума и състояние на одобрение. Работата по внедряването прави това вярно във всяка крайна точка, включително скучните.

Свързано четене

• идемпотентен партньор API автоматизация за предоставяне на ключове и кредити