Access Control жана RBAC үчүн API

1) Эмне үчүн API жетүү контролдоо

Авторизация - бул "бул актёр бул ресурсту азыр аткара алабы? ». Каталар БАЛА/IDOR-агып кетишине, укуктардын күчөшүнө жана жөнгө салуучу талаптардын бузулушуна алып келет. Максаты - көп баскычтуу моделди куруу: периметри → сервис-mash → бизнес эрежелери, ачык-айкын саясаттар жана объекттин деңгээлинде текшерүүлөр менен.

2) Authorization моделдери: качан тандоо керек

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 + домен-спецификалык ('approve', 'refund', 'settle').
Ресурстардын касиеттери: ээси, аймагы, статусу, тобокелдик тегдери (AML/KYC), лимиттери.
Мультиаренттүүлүк: бардык чечимдер 'tenant _ id'; демейки (deny-by-default) боюнча кросс-тенант суроо тыюу салуу.

4) Архитектура: чечим кабыл алынган жерде

PEP (Policy Enforcement Point) - текшерүү орду: шлюз/API-Gateway, sidecar mash, өзү кызмат.
PDP (Policy Decision Point) - саясаттын кыймылдаткычы: борборлоштурулган (OPA кызматы, Cedar кыймылдаткычы) же орнотулган китепкана.
PIP (Policy Information Point) - атрибуттардын булактары: колдонуучулардын/ролдордун каталогу, тенанттын профили, KUS/тобокелдик, ресурстарга ээлик кылуу картасы.
PAP (Policy Administration Point) - саясаттардын версияларын башкаруу, жарыялоо, аудит.

Сунуш: PEP борборлоштурулган PDP + жергиликтүү кэш чечимдер; домендик инварианттар болгон учурда кызматтагы татаал объекттик текшерүүлөр.

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) Object-деңгээл Authorization (BOLA-биринчи)

Ар бир операция "субъект ээси болуп саналабы/бул '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 - кардарлар үчүн тышкы келишим (mapping scope → permissions).

• негизги ролдору + "кошумча" (permission packs),
• ABAC чектөөлөрү (өлкө/аймак/тенант),
• "Убактылуу жогорулатуулар" (Just-In-Time access, жарактуу мөөнөтү).

8) AVAS/контексттик чектөөлөр

Гео/юрисдикция: тыюу салынган өлкөлөрдөн write тыюу салуу (санкциялар/жөнгө салуучу).
Убакыт/тобокелдик: 'risk _ score <threshold' ири операциялар үчүн.
CMC/лимиттер: 'kyc _ level> = 2' корутундулар үчүн> X; транзакциялардын ортосундагы "муздатуу" контролу.
"Ишенимдүү түзмөктөр": кооптуу жолдордо өнөктөштөр үчүн mTLS талап.

9) ReBAC жана укук тилкеси

Татаал бизнес структуралар (топтор, командалар, бренддер, филиалдар) үчүн пайдалуу.

Байланыш: 'member', 'admin', 'owner', 'viewer'.
Туунду укуктар: 'viewer' ресурсу 'org' таандык 'member' долбоорунан мурасталат.
Graf сактоо: DD мамилелер матрицасы менен, адистештирилген кызмат (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) Саясатты жана версияларды башкаруу

Version саясат ('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}', БАЛА-аракет үлүшү, кэш-хит-rate.
Дашборддор: иш-аракеттер/тенанттар боюнча жогорку ийгиликсиздиктер, саясатчылардын чыгарылышынан кийинки тенденциялар.

14) Коопсуздук жана туруктуулук

Deny-by-default: так уруксаттын жоктугу = тыюу салуу.
Fail-closed: PDP жок болсо критикалык write → тыюу (же катуу текшерилген ролдордун "минималдуу топтому" деградация).
Критикалык инварианттар үчүн кызматтардын ичиндеги жергиликтүү "гвардиялык текшерүүлөр" (мисалы, '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' жолдору боюнча, GEO/ASN-периметри боюнча чыпкалар.

16) тестирлөө жана текшерүү

Negative-матрица: ачык "тыюу салынган" учурларда тизмеси жана тесттер менен бекитүү.
Fuzz авторизациясы: 'tenant _ id', 'owner _ id' алмаштыруу, пагинация/сорттоо учурунда фильтрлерди айланып өтүү.
PDP Load сыноо: жашыруун жана p95/p99 кэш жүрүм-турумун текшерүү.
Release Politics: dry-run + canary + күтүлгөн deny/allow менен унаа жарыш.
Инциденттер: саясаттын так версиясы менен стендде суроо-талаптарды кайталоо.

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

Объект текшерүүлөрсүз гана 'scope' таянуу (BOLA).
борборлоштурулган модели жок ар бир Handler бизнес-логика жана укуктарды текшерүү аралаштырып.
Hardcoding UI ролу жана кардарлардын чечимдерине ишенүү.
DB (leaky reads) өтүнүчтөрүндө 'tenant '/' owner' фильтрлеринин жоктугу.
Ролдорду/мамилелерди алмаштырууда кэш чечимдер майыптыгы жок.
Узак мөөнөттүү JWT кайра чакыртып алуу/айлануу жок.

18) Prod-даярдык чек тизмеси

• Аныкталган ресурстар/иш-аракеттер, иерархия жана көп ижара.
• Негизги RBAC матрицасы + ABAC чектөөчүлөрү - ReBAC.
• PDP/PEP иштелип чыккан; жергиликтүү кэш чечимдер жана анын майыптыгы бар.
• Саясатчылар версияланат, CI терс сценарийлердин тесттери.
• конкреттүү 'resource _ id' боюнча ар бир write/окуу БАЛА-текшерүү.
• JWT минималдуу, кыска 'exp'; аудит/кайра карап чыгуу 'jti'.
• Метрика/Loi Solutions, Dashboard, deny/latency боюнча алерт.
• оор write үчүн Fail-closed; fallback режими документтештирилген.
• Кардарлар үчүн документтер: 'scopes', ката коддору (401/403/404/409), мисалдар.

19) TL; DR

БАЛА-биринчи уруксат куруу: борбордук PDP + кэш чечимдер, RBAC негизи катары, ABAC контекстте, ReBAC мамилелер үчүн. Бардык суроолор - 'tenant' жана конкреттүү 'resource _ id' контекстинде; deny-by-default, кыска JWT, DD объектилер чыпкалар. Политиканы версиялоо жана тестирлөө, latency/deny өлчөө, окуяларды реплема менен ойноо. iGaming үчүн - жеке ролдор (KYC/AML/касса), катуу ABAC чектегичтери жана өзгөрүлбөгөн аудит.