API-ге қолжетімділікті бақылау және RBAC

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' ресурсының 'org' тиесілі 'member' жобасынан мұраға қалдырылады.
Баған қоймасы: қарым-қатынас матрицасы бар ДБ, мамандандырылған сервис (Zanzibar-тәсіл рухында). 'check (subject, relation, object)' жауаптарын кэштеңіз.

10) Шешімдердің кэші және өнімділігі

PEP деңгейіндегі (мысалы, шлюздегі) PDP кэші 'sub' tenant 'resource' action 'policy _ version' бойынша кілтпен.
TTL қысқа (секунд-минут) + оқиғалар бойынша мүгедектік: рөлдердің/қатынастардың/тенанттың өзгеруі.
Тізімдер үшін Batch-тексерулер (bulk authz): PDP шарджаларын азайтады.
Шешімдердің latency өлшеңіз; деградация кезінде - graceful-degradation тек оқу үшін (ешқашан 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' - write-дегі ABAC сүзгілері.
Аудит-журналдар KYC/AML/қорытындылардың әрекеттері үшін өзгермейді; реттеуші мерзімдерге сәйкес сақтау.
Серіктестік API: mTLS + бағыттар бойынша келісімшарттық 'scopes', периметрдегі гео/ASN-сүзгілер.

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

Negative-матрица: анық «тыйым салынған» кейстерді санап, тесттермен бекітіңіз.
Fuzz авторизациясы: 'tenant _ id', 'owner _ id' алмастыру, пагинация/сұрыптау кезінде сүзгілерді тексеріп шығу.
PDP жүктеу тесті: p95/p99 кэшінің жасырындылығын және тәртібін тексеріңіз.
Саясатты шығару: dry-run + canary + күтілетін deny/allow бар автосверк.
Оқиғалар: саясаттың дәл нұсқасымен стендтегі сұрауларды репликалау.

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

Нысанды тексерусіз 'scope' дегенге ғана сүйену (BOLA).
Бизнес-логиканы және құқықтарды тексеруді орталықтандырылған үлгісіз әрбір хэндлерде араластыру.
UI-дегі рөлдерді хардкодтау және клиенттік шешімдерге сену.
ДБ (leaky reads) сұрауларында 'tenant '/' owner' сүзгілерінің болмауы.
Рөлдерді/қатынастарды ауыстырған кезде кэш-шешімдердің мүгедектігі жоқ.
Ұзақ өмір сүретін JWT кері қайтарусыз/ротациясыз.

18) Prod-дайындық чек-парағы

• Ресурстар/әрекеттер, иерархиялар және көп жалға алу анықталған.
• Базалық RBAC-матрица + қажет жерде ABAC-шектегіштер - ReBAC.
• PDP/PEP жобаланған; шешімдердің жергілікті кэші және оның мүгедектігі бар.
• Саясаткерлер нұсқаланады, CI-дегі теріс сценарийлердің тестілері.
• Нақты 'resource _ id' -ге әр write/read BOLA-тексерулер.
• JWT ең аз таңбалармен, қысқа 'exp'; 'jti' бойынша аудит/пікір.
• Шешімдердің өлшемдері/логтары, дашбордтар, deny/latency бойынша алерттар.
• Сыни write үшін Fail-closed; 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-шектегіштер және өзгермейтін аудит.