Контроль доступу та RBAC в API

1) Навіщо контроль доступу в API

Авторизація - це відповідь на питання "чи можна цьому актору виконати цю дію над цим ресурсом зараз? ». Помилки призводять до BOLA/IDOR-витоків, ескалації прав і порушення вимог регуляторів. Мета - побудувати багаторівневу модель: периметр → сервіс-меш → бізнес-правила, з явними політиками і перевірками на об'єктному рівні.

2) Моделі авторизації: коли що вибирати

RBAC (Role-Based Access Control) - ролі → дозволу. Проста, стабільна, але схильна до «вибуху ролей».
ABAC (Attribute-Based) - рішення по атрибутах суб'єкта/об'єкта/контексту (країна, KYC-рівень, власник ресурсу, ризик).
ReBAC (Relationship-Based) - граф відносин (власник, член команди, «менеджер проекту»); вирішує складні ієрархії.
Scopes (OAuth) - договір між клієнтом і ресурс-сервером про «зону доступу» (наприклад,'payments:write`).
Практика: RBAC для базової матриці, ABAC для контексту і обмежень, ReBAC для складних ієрархій (папки, організації, ліміти і підаккаунти).

3) Таксономія ресурсів і дій

Ієрархії: `org → project → wallet → transaction`. Спадкування прав зверху вниз з можливими «обмежувачами».
Дії: CRUD + domain-специфічні ('approve','refund','settle').
Властивості ресурсів: власник, регіон, статус, ризик-теги (AML/KYC), ліміти.
Мультиарендність: всі рішення містять'tenant _ id'; заборона крос-тенантних запитів за замовчуванням (deny-by-default).

4) Архітектура: де приймається рішення

PEP (Policy Enforcement Point) - місце перевірки: шлюз/API-гейтвей, sidecar меша, сам сервіс.
PDP (Policy Decision Point) - рушій політик: централізований (OPA-сервіс, Cedar-рушій) або вбудований бібліотечно.
PIP (Policy Information Point) - джерела атрибутів: каталог користувачів/ролей, профіль тенанта, КУС/ризик, карта володіння ресурсами.
PAP (Policy Administration Point) - управління версіями політик, публікація, аудит.

Рекомендація: централізований PDP + локальний кеш рішень в PEP; складні об'єктні перевірки в сервісі при наявності доменних інваріантів.

5) Токени, клейми та ідентичність

OIDC/OAuth2: 'sub'( ідентифікатор суб'єкта),'aud'( цільовий сервіс),'scope '/' roles','tenant','kyc _ level','risk _ tier'.
JWT: RS/ES-підпис, короткий'exp', перевипуск по refresh. Не кладіть PII; використовуйте'jti'для відгуку/трек-аудиту.
mTLS/HMAC: сервіс-к-сервіс і партнери; клейми підтягуються з каталогу по'client _ id'.
Device/Context: IP/ASN, гео, час доби - вхід в ABAC-рішення (наприклад, заборона write поза робочими годинами).

6) Об'єктно-рівнева авторизація (BOLA-first)

Кожна операція повинна відповідати на «чи є суб'єкт власником/чи має право на цей'resource _ id'?».

Перевірка володіння: `resource. owner_id == subject. id'або членство в'org'з роллю.
Фільтрація вибірок: завжди накладайте'WHERE resource. tenant_id =:tenant AND...` (row-level security).
Для посилальних операцій (ID в дорозі/тілі) - нормалізуйте і валідуйте до бізнес-логіки.

7) Проектування RBAC: ролі, дозволи, набори

Дозволи (permissions) - атомарні права: `wallet. read`, `wallet. write`, `payment. refund`.
Ролі - іменовані набори дозволів: `admin`, `support. read`, `cashier`, `fraud. analyst`.
Scopes - зовнішній контракт для клієнтів (меппінг scope→permissions).

• базові ролі + «надбудови» (permission packs),
• обмеження ABAC (країна/регіон/тенант),
• «тимчасові підвищення» (Just-In-Time access, термін дії).

8) АВАС/контекстні обмеження

Гео/юрисдикція: заборона write із заборонених країн (санкції/регуляторика).
Час/ризик: 'risk _ score <threshold'для великих операцій.
КУС/ліміти: 'kyc _ level> = 2'для виводів> X; контроль «охолодження» між транзакціями.
«Довірені пристрої»: вимагати mTLS для партнерів на небезпечних маршрутах.

9) ReBAC і граф прав

Корисний для складних бізнес-структур (групи, команди, бренди, філії).

Відносини: `member`, `admin`, `owner`, `viewer`.
Похідні права: «viewer» ресурсу успадковується з «member» проекту, який належить «org».
Сховище графа: БД з матрицею відносин, спеціалізований сервіс (в дусі Zanzibar-підходу). Кешуйте відповіді'check (subject, relation, object)'.

10) Кеш рішень і продуктивність

Кеш PDP на рівні PEP (наприклад, в шлюзі) ключем по: `sub|tenant|resource|action|policy_version`.
TTL короткий (секунди-хвилини) + інвалідація за подіями: зміна ролей/відносин/тенанта.
Batch-перевірки (bulk authz) для списків: зменшують чарджі PDP.
Вимірюйте latency рішень; при деградації - graceful-degradation тільки для read (ніколи для write/грошових).

11) Приклади політик

11. 1 JWT-клейми → грубий PEP (псевдо-гейтвей)

yaml
- match: { prefix: "/api/v1/wallets" }
authz:
require:
- claim: "aud"
equals: "wallet-service"
- claim: "scope"
includes_any: ["wallet. read", "wallet. write"]
context:
tenant_from: "claim:tenant"

11. 2 OPA/Rego (ABAC + BOLA)

rego package authz

default allow = false

allow {
input. action == "wallet. read"
input. subject. tenant == input. resource. tenant some role role:= input. subject. roles[_]
role == "support. read"
}

allow {
input. action == "payment. refund"
input. subject. tenant == input. resource. tenant input. subject. kyc_level >= 2 input. subject. risk_tier <= 2 input. subject. id == input. resource. owner_id # BOLA
}

11. 3 Обмеження щодо юрисдикції (політика deny-list)

rego deny[msg] {
input. action == "withdraw. create"
input. context. country in {"IR","KP","SY"}
msg:= "Jurisdiction not allowed"
}

11. 4 Політика ReBAC (псевдо)

allow(subject, "wallet. write", wallet) --
related(subject, "member", wallet. project) ∧ related(subject, "admin", wallet. org)   ∧ wallet. tenant == subject. tenant.

12) Управління політиками та версіями

Версіонування політик ('policy _ version') і канареєчка для небезпечних змін.
«Сухі прогонки» (dry-run/shadow decisions) - логуємо'allow/deny'без впливу.
Каталог політик і міграцій: хто, коли і чому змінив; порівняння з інцидентами.
Тести на негативні сценарії (заборонені кейси) - обов'язкові в CI.

13) Спостережуваність і аудит

Логи рішень: 'trace _ id','subject','tenant','action','resource _ id','result','policy _ version', причина відмови.
Метрики: 'authz _ decision _ latency','authz _ denied _ total {action}', частка BOLA-спроб, кеш-hit-rate.
Дашборди: топ-відмови щодо дій/тенантів, тренди після релізів політик.

14) Безпека і стійкість

Deny-by-default: відсутність явного дозволу = заборона.
Fail-closed: при недоступності PDP критичні write → заборону (або деградація до «мінімального набору» строго перевірених ролей).
Локальні «guard-перевірки» всередині сервісів для критичних інваріантів (наприклад,'tenant '/' owner').
Мінімізація клеймів в JWT; чутливі атрибути підвантажувати через PIP по захищеному каналу.

15) Специфіка iGaming/фінансів

Ролі: `cashier`, `kyc. agent`, `aml. officer`, `fraud. analyst`, `vip. manager`, `risk. admin`.
Обмеження: операції виплати залежать від'kyc _ level', лімітів відповідальних платежів, статусу AML/санкцій.
Реєстри блокувань: 'org/brand/device/payment _ instrument'- ABAC-фільтри на write.
Аудит-журнали незмінні для дій KYC/AML/висновків; зберігання згідно з регуляторними термінами.
Партнерські API: mTLS + контрактні'scopes'за маршрутами, гео/ASN-фільтри на периметрі.

16) Тестування та верифікація

Negative-матриця: перерахуйте явні «заборонені» кейси і закріпіть тестами.
Fuzz авторизації: підміна'tenant _ id','owner _ id', обхід фільтрів при пагінації/сортуванні.
Load-тест PDP: перевірте латентність і поведінку кешів при p95/p99.
Реліз політик: dry-run + canary + автосверка з очікуваними deny/allow.
Інциденти: реплей запитів на стенді з точною версією політик.

17) Антипатерни

Покладатися тільки на «scope» без об'єктних перевірок (BOLA).
Змішувати бізнес-логіку і перевірки прав в кожному хендлері без централізованої моделі.
Хардкодити ролі в UI і довіряти клієнтським рішенням.
Відсутність'tenant '/' owner'фільтрів в запитах до БД (leaky reads).
Немає інвалідації кеш-рішень при зміні ролей/відносин.
Довгоживучі JWT без відкликання/ротації.

18) Чек-лист prod-готовності

• Визначено ресурси/дії, ієрархії та багатоарендність.
• Базова RBAC-матриця + ABAC-обмежувачі, де потрібно - ReBAC.
• PDP/PEP спроектовані; є локальний кеш рішень і його інвалідація.
• Політики версіонуються, тести негативних сценаріїв в CI.
• BOLA-перевірки в кожному write/read на конкретний'resource _ id'.
• JWT з мінімальними клеймами, коротким'exp'; аудит/відгук по'jti'.
• Метрики/логи рішень, дашборди, алерти по deny/latency.
• Fail-closed для критичних write; fallback-режим документований.
• Документація для клієнтів: «scopes», коди помилок (401/403/404/409), приклади.

19) TL; DR

Будуйте авторизацію BOLA-first: центральний PDP + кеш рішень, RBAC як основа, ABAC для контексту, ReBAC для відносин. Всі запити - в контексті'tenant'і конкретного'resource _ id'; deny-by-default, короткі JWT, об'єктні фільтри в БД. Версіонуйте і тестуйте політики, міряйте latency/deny, інциденти відтворюйте реплеєм. Для iGaming - окремі ролі (KYC/AML/каса), жорсткі ABAC-обмежувачі і незмінний аудит.