APIga kirishni va RBACni nazorat qilish

1) Nima uchun APIga kirishni nazorat qilish

Avtorizatsiya - "Bu aktyor bu resursni hozir bajarishi mumkinmi? ». Xatolar BOLA/IDOR-sizib chiqishiga, huquqlarning kuchayishiga va regulyatorlar talablarining buzilishiga olib keladi. Maqsad - ko’p darajali modelni yaratish: perimetr → servis-mash → biznes-qoidalar, ob’ekt darajasida aniq siyosat va tekshiruvlar.

2) Avtorizatsiya modellari: qachon nimani tanlash kerak

RBAC (Role-Based Access Control) - rollar → ruxsatnomalar. Oddiy, barqaror, lekin «rollarni portlatishga» moyil.
ABAC (Attribute-Based) - subyekt/obyekt/kontekst atributlari bo’yicha qaror (mamlakat, KYC-darajasi, resurs egasi, xavf).
ReBAC (Relationship-Based) - munosabatlar grafasi (egasi, jamoa a’zosi, «loyiha menejeri»); murakkab ierarxiyalarni hal qiladi.
Scopes (OAuth) - mijoz va resurs-server o’rtasida "kirish hududi" to’g "risidagi shartnoma (masalan,’payments: write’).
Amaliyot: baza matritsasi uchun RBAC, kontekst va cheklovlar uchun ABAC, murakkab ierarxiyalar (jildlar, tashkilotlar, limitlar va akkauntlar) uchun ReBAC.

3) Resurslar va harakatlar taksonomiyasi

Ierarxiyalar:’org → project → wallet → transaction’. Huquqlarni yuqoridan pastga mumkin bo’lgan «cheklovlar» bilan meros qilib olish.
Harakatlar: CRUD + domain-spetsifik (’approve’,’refund’,’settle’).
Resurslarning xossalari: egasi, mintaqasi, maqomi, tavakkalchilik teglari (AML/KYC), limitlari.
Multiarendlik: barcha qarorlarda’tenant _ id’mavjud; andoza (deny-by-default) xoch-tenant so’rovlarni taqiqlash.

4) Arxitektura: qaror qayerda qabul qilinadi

PEP (Policy Enforcement Point) - tekshirish joyi: shlyuz/API-geytvey, sidecar mash, xizmatning o’zi.
PDP (Policy Decision Point) - siyosatchi dvigateli: markazlashtirilgan (OPA-servis, Cedar-dvigatel) yoki kutubxonada oʻrnatilgan.
PIP (Policy Information Point) - atributlar manbalari: foydalanuvchilar/rollar katalogi, tenant profili, KTS/xavf, resurslarga egalik qilish xaritasi.
PAP (Policy Administration Point) - siyosat versiyalarini boshqarish, nashr etish, audit.

Tavsiya: markazlashtirilgan PDP + PEPdagi mahalliy yechimlar keshi; domen invariantlari mavjud bo’lganda servisda murakkab obyekt tekshiruvlari.

5) Tokenlar, tamg’alar va o’ziga xoslik

OIDC/OAuth2:’sub’(subyekt identifikatori),’aud’(maqsadli xizmat),’scope ’/’ roles’,’tenant’,’kyc _ level’,’risk _ tier’.
JWT: RS/ES-imzo, qisqa’exp’, refresh bo’yicha qayta chiqarish. PII qo’ymang; sharh/trek-audit uchun’jti’dan foydalaning.
mTLS/HMAC: servis-k-servis va sheriklar; markalar’client _ id’bo’yicha katalogdan tortiladi.
Device/Context: IP/ASN, geo, sutka vaqti - ABAC-yechimga kirish (masalan, ish soatlaridan tashqari write-ni taqiqlash).

6) Obyekt-darajali avtorizatsiya (BOLA-first)

Har bir operatsiya «subyekt ushbu’resource _ id’ga egalik qiladimi/huquqiga egami?» ga javob berishi kerak.

Egalik tekshiruvi:’resource. owner_id == subject. id’yoki rol bilan’org’ga a’zolik.
Tanlanganlarni filtrlash: har doim’WHERE resource’ni qoʻying. tenant_id =:tenant AND...` (row-level security).
Havola operatsiyalari uchun (yo’l/teleda ID) - normallashtiring va biznes-mantiqgacha tasdiqlang.

7) RBACni loyihalash: rollar, ruxsatnomalar, to’plamlar

Ruxsatnomalar (permissions) - atomar huquqlar:’wallet. read`, `wallet. write`, `payment. refund`.
Rollar - ruxsatnomalar toʻplami:’admin’,’support. read`, `cashier`, `fraud. analyst`.
Scopes - mijozlar uchun tashqi kontrakt (mepping scope → permissions).

• bazaviy rollar + «ustavlar» (permission packs),
• ABAC cheklovlari (mamlakat/mintaqa/tenant),
• «vaqtinchalik oshirishlar» (Just-In-Time access, amal qilish muddati).

8) AVAS/kontekst cheklovlari

Geo/yurisdiksiya: taqiqlangan mamlakatlardan write taqiqlash (sanksiyalar/tartibga solish).
Vaqt/xavf:’risk _ score <threshold’yirik operatsiyalar uchun.
KTS/limitlar:’kyc _ level> = 2’xulosalar uchun> X; tranzaksiyalar o’rtasidagi «sovish» ni nazorat qilish.
«Ishonchli qurilmalar»: xavfli yo’nalishlardagi hamkorlar uchun mTLS talab qilish.

9) ReBAC va huquqlar grafasi

Murakkab biznes tuzilmalar (guruhlar, jamoalar, brendlar, filiallar) uchun foydalidir.

Aloqalar:’member’,’admin’,’owner’,’viewer’.
Hosilaviy huquqlar:’viewer’resursi’org’ga tegishli’member’loyihasidan meros qilib olinadi.
Grafa ombori: munosabatlar matritsasi bo’lgan DB, ixtisoslashtirilgan servis (Zanzibar-yondashuv ruhida). ’check (subject, relation, object)’ javoblarini kesh qiling.

10) Yechimlar keshi va unumdorligi

"sub’tenant’resource’action’policy _ version’bo’yicha kalit bilan PEP darajasidagi (masalan, shlyuzda) PDP keshi.
TTL qisqa (soniya-daqiqa) + hodisalar bo’yicha nogironlik: rollar/munosabatlar/tenant o’zgarishi.
Roʻyxatlar uchun batch-tekshirish (bulk authz): PDP charjlarini kamaytiradi.
Latency yechimlarini o’lchang; degradatsiyada - graceful-degradation faqat o’qish uchun (hech qachon write/pul uchun).

11) Siyosatchilar misollari

11. 1 JWT-tamg’a → qo’pol PEP (psevdo-geytvey)

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 Yurisdiksiya bo’yicha cheklash (deny-list siyosati)

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

11. 4 ReBAC siyosati (psevdo)

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

12) Siyosat va versiyalarni boshqarish

Siyosatni versionlash (’policy _ version’) va xavfli oʻzgarishlar uchun kanareyka.
«Quruq pog’onalar» (dry-run/shadow decisions) - ta’sirsiz’allow/deny’logotipi.
Siyosat va migratsiyalar katalogi: kim, qachon va nima uchun o’zgartirdi; hodisalar bilan taqqoslash.
Salbiy stsenariylarga testlar (taqiqlangan keyslar) - CIda majburiy hisoblanadi.

13) Kuzatuv va audit

’trace _ id’,’subject’,’tenant’,’action’,’resource _ id’,’result’,’policy _ version’, rad etish sabablari.
Metriklar:’authz _ decision _ latency’,’authz _ denied _ total {action}’, BOLA urinishlari ulushi, kesh-hit-rate.
Dashbordlar: harakatlar/tenantlar bo’yicha top-rad etishlar, siyosat relizlaridan keyingi trendlar.

14) Xavfsizlik va barqarorlik

Deny-by-default: aniq ruxsatnomaning yo’qligi = taqiqlash.
Fail-closed: PDP mavjud bo’lmaganda tanqidiy write → taqiqlanadi (yoki qat’iy tekshirilgan rollarning «minimal to’plamiga» nisbatan tanazzulga uchraydi).
Kritik invariantlar uchun xizmatlar ichidagi lokal «guard-tekshirishlar» (masalan,’tenant ’/’ owner’).
JWTdagi tamg’alarni minimallashtirish; sezgir atributlarni himoyalangan kanal orqali PIP orqali yuklash.

15) iGaming/Moliya xususiyatlari

Rollar:’cashier’,’kyc. agent`, `aml. officer`, `fraud. analyst`, `vip. manager`, `risk. admin`.
Cheklovlar: to’lov operatsiyalari «kyc _ level», mas’ul to’lovlar limitlari, AML/sanksiyalar maqomiga bog’liq.
Bloklash reyestrlari:’org/brand/device/payment _ instrument’- write’dagi ABAC-filtrlar.
KYC/AML/xulosalar uchun o’zgarmas audit-jurnallar; tartibga solish muddatlariga muvofiq saqlash.
Sheriklik API: mTLS + yo’nalishlar bo’yicha kontrakt’scopes’, perimetrda geo/ASN-filtrlar.

16) Test sinovi va verifikatsiya

Negative matritsasi: Aniq «taqiqlangan» keyslarni sanab, testlar bilan mahkamlang.
Fuzz avtorizatsiya:’tenant _ id’,’owner _ id’almashtirish, paginatsiya/saralash paytida filtrlarni aylanib chiqish.
PDP yuklash testi: p95/p99’dagi kesh xatti-harakatlarini tekshiring.
Siyosatni chiqarish: dry-run + canary + kutilgan deny/allow bilan avtosverka.
Hodisalar: siyosatning aniq versiyasi bilan stendda so’rovlarni takrorlash.

17) Antipatternlar

Obyekt tekshiruvisiz faqat’scope’ga tayanish (BOLA).
Har bir hendlerda biznes-mantiqni va huquqlarni markazlashtirilgan modelsiz tekshirishni aralashtirish.
UIda rol o’ynash va mijozlarning qarorlariga ishonish.
DB (leaky reads) soʻrovlarida’tenant ’/’ owner’filterlari mavjud emas.
Rollar/munosabatlar o’zgarganda kesh qarorlari nogironligi yo’q.
Uzoq umr ko’radigan JWT qaytarib olinmaydi/rotatsiya qilinmaydi.

18) Prod-tayyorlik chek-varaqasi

• Resurslar/harakatlar, iyerarxiya va ko’p ijarali belgilandi.
• Bazaviy RBAC matritsasi + kerak bo’lganda ABAC cheklovlari - ReBAC.
• PDP/PEP loyihalashtirilgan; mahalliy yechimlar keshi va uning nogironligi mavjud.
• Siyosatchilar CI-da salbiy stsenariy sinovlarini o’tkazadilar.
• BOLA-tekshirish har bir write/o’qish uchun aniq’resource _ id’.
• JWT minimal tamg’alari, qisqa’exp’; ’jti’ bo’yicha audit/chaqirib olish.
• Qarorlarning metrikasi/loglari, dashbordlar, deny/latency bo’yicha alertlar.
• Tanqidiy write uchun fail-closed; fallback rejimi hujjatlashtirilgan.
• Mijozlar uchun hujjatlar:’scopes’, xato kodlari (401/403/404/409), misollar.

19) TL; DR

BOLA-first: markaziy PDP + yechimlar keshini, RBAC asosini, ABAC kontekstini, ReBAC munosabatlarini avtorizatsiya qiling. Barcha so’rovlar’tenant’va aniq’resource _ id’kontekstida; deny-by-default, qisqa JWT, DBdagi obyekt filtrlari. Siyosatni versiya va sinab ko’ring, latency/deny o’lchang, hodisalarni replay qiling. iGaming uchun - alohida rollar (KYC/AML/kassa), qattiq ABAC cheklovlari va o’zgarmas audit.