Access Control və RBAC API

1) Niyə API-yə giriş nəzarəti

Avtorizasiya «Bu aktyor indi bu resurs üzərində bu hərəkəti yerinə yetirə bilərmi?» sualının cavabıdır ». Səhvlər BOLA/İDOR sızmalarına, hüquqların artmasına və tənzimləyicilərin tələblərinin pozulmasına səbəb olur. Məqsəd çoxsəviyyəli model qurmaqdır: perimetr → xidmət-mash → biznes qaydaları, obyektin səviyyəsində açıq siyasətlər və yoxlamalar ilə.

2) Avtorizasiya modelləri: nə zaman seçmək lazımdır

RBAC (Role-Based Access Control) - rolları → qətnamə. Sadə, sabitdir, lakin «rolların partlamasına» meyllidir.
ABAC (Attribute-Based) - subyektin/obyektin/kontekstin atributlarına dair qərar (ölkə, KYC-səviyyə, resurs sahibi, risk).
ReBAC (Relationship-Based) - əlaqələr qrafiki (sahibi, komanda üzvü, «layihə meneceri»); mürəkkəb iyerarxiyaları həll edir.
Scopes (OAuth) - müştəri ilə resurs-server arasında «giriş zonası» haqqında müqavilə (məsələn, 'payments: write').
Təcrübə: əsas matris üçün RBAC, kontekst və məhdudiyyətlər üçün ABAC, mürəkkəb iyerarxiyalar (qovluqlar, təşkilatlar, limitlər və alt hesablar) üçün ReBAC.

3) Resurslar və hərəkətlərin taksonomiyası

İyerarxiyalar: 'org → project → wallet → transaction'. Mümkün «məhdudlaşdırıcılar» ilə yuxarıdan aşağıya hüquqların miras.
Fəaliyyət: CRUD + domain-spesifik ('approve', 'refund', 'settle').
Resursların xüsusiyyətləri: sahibi, region, status, risk etiketləri (AML/KYC), limitlər.
Multi-icarə: bütün həllər 'tenant _ id'; default xaç-tenant sorğu qadağan (deny-by-default).

4) Memarlıq: qərar harada verilir

PEP (Policy Enforcement Point) - yoxlama yeri: şluz/API-geytway, sidecar mash, özü xidmət.
PDP (Policy Decision Point) - siyasətin mühərriki: mərkəzləşdirilmiş (OPA xidməti, Cedar mühərriki) və ya daxili kitabxana.
PIP (Policy Information Point) - atributların mənbələri: istifadəçilər/rollar kataloqu, tenant profili, KUS/risk, resurslara sahib olma xəritəsi.
PAP (Policy Administration Point) - siyasət versiyalarının idarə edilməsi, nəşr, audit.

Tövsiyə: Mərkəzləşdirilmiş PDP + PEP-də yerli cache həlləri; domen invariantları mövcud olduqda servisdə kompleks obyekt yoxlamaları.

5) Tokenlər, markalar və şəxsiyyət

OIDC/OAuth2: 'sub', 'aud', 'scope '/' roles', 'tenant', 'kyc _ level', 'risk _ tier'.
JWT: RS/ES-imza, qısa 'exp', refresh. PII qoymayın; geri çağırmaq/trek auditi üçün 'jti' istifadə edin.
mTLS/HMAC: xidmət-xidmət və tərəfdaşlar; markalar 'client _ id' kataloqundan çıxarılır.
Device/Context: IP/ASN, geo, günün vaxtı - ABAC həllinə giriş (məsələn, iş saatları xaricində write qadağası).

6) Obyekt-səviyyəli avtorizasiya (BOLA-first)

Hər bir əməliyyat «mövzu sahibidir/bu 'resource _ id' hüququ varmı?» cavab verməlidir.

Sahiblik testi: 'resource. owner_id == subject. id 'və ya rol ilə' org 'üzvlük.
Seçimi filtrasiya: həmişə 'WHERE resource. tenant_id =:tenant AND...` (row-level security).
Link əməliyyatları üçün (yolda/telefonda ID) - normallaşdırın və biznes məntiqinə qədər təsdiqləyin.

7) RBAC dizaynı: rollar, icazələr, dəstlər

Icazələr (permissions) - atom hüquqları: 'wallet. read`, `wallet. write`, `payment. refund`.
Rollar: 'admin', 'support. read`, `cashier`, `fraud. analyst`.
Scopes - müştərilər üçün xarici müqavilə (scope → permissions).

• əsas rollar + «əlavələr» (permission packs),
• ABAC məhdudiyyətləri (ölkə/region/tenant),
• «Müvəqqəti artımlar» (Just-In-Time access, etibarlılıq müddəti).

8) AVAS/kontekst məhdudiyyətləri

Geo/yurisdiksiya: qadağan olunmuş ölkələrdən write qadağası (sanksiyalar/tənzimləyici).
Vaxt/risk: 'risk _ score <threshold' böyük əməliyyatlar üçün.
KUS/Limitlər: 'kyc _ level> = 2' nəticələr üçün> X; əməliyyatlar arasında «soyutma» nəzarət.
«Etibarlı qurğular»: təhlükəli marşrutlarda tərəfdaşlar üçün mTLS tələb.

9) ReBAC və Graf hüquqları

Mürəkkəb biznes strukturları (qruplar, komandalar, markalar, filiallar) üçün faydalıdır.

Əlaqələr: 'member', 'admin', 'owner', 'viewer'.
Törəmə hüquqlar: 'viewer' resursu 'org' aid olan 'member' layihəsindən miras alır.
Qraf saxlama: əlaqələr matrisi ilə DB, xüsusi xidmət (Zanzibar yanaşma ruhunda). Cavabları cache 'check (subject, relation, object)'.

10) Cache Solutions və Performance

"sub 'tenant' resource 'action' policy _ version 'açarı ilə PEP səviyyəsində PDP cache (məsələn, şlüzdə).
TTL qısa (saniyə-dəqiqə) + hadisələrə görə əlillik: rolların/münasibətlərin/tenantın dəyişməsi.
Siyahılar üçün Batch-check (bulk authz): PDP şarjlarını azaltın.
Latency həlləri ölçün; deqradasiya - graceful-degradation yalnız oxumaq üçün (write/pul üçün heç vaxt).

11) Siyasətçi nümunələri

11. 1 JWT markaları → kobud PEP (psevdo-geytway)

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 məhdudiyyəti (deny-list siyasəti)

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

11. 4 ReBAC siyasəti (psevdo)

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

12) Siyasət və versiyaların idarə edilməsi

Version siyasəti ('policy _ version') və təhlükəli dəyişikliklər üçün kanarya.
«Quru yarışlar» (dry-run/shadow decisions) - heç bir təsir göstərmədən 'allow/deny' loqosu.
Siyasət və miqrasiya kataloqu: kim, nə vaxt və niyə dəyişdi; hadisələrlə müqayisə.
Mənfi ssenarilər üçün testlər (qadağan olunmuş hallar) - CI-də tələb olunur.

13) Müşahidə və audit

Həll qeydləri: 'trace _ id', 'subject', 'tenant', 'action', 'resource _ id', 'result', 'policy _ version', imtina səbəbi.
Metriklər: 'authz _ decision _ latency', 'authz _ denied _ total {action}', BOY cəhdlərinin payı, cash-hit-rate.
Daşbordlar: hərəkətlər/tenantlar üzrə top uğursuzluqlar, siyasətlərin buraxılışlarından sonra trendlər.

14) Təhlükəsizlik və sabitlik

Deny-by-default: açıq icazənin olmaması = qadağa.
Fail-closed: PDP-nin əlçatmazlığı kritik write → qadağa (və ya ciddi yoxlanılmış rolların «minimum dəsti» üçün deqradasiya).
Kritik invariantlar üçün xidmətlər daxilində lokal «guard-yoxlamalar» (məsələn, 'tenant '/' owner').
JWT-də markaların minimuma endirilməsi; həssas atributları təhlükəsiz kanal vasitəsilə PIP vasitəsilə yükləmək.

15) iGaming/Maliyyə Xüsusiyyətləri

Rollar: 'cashier', 'kyc. agent`, `aml. officer`, `fraud. analyst`, `vip. manager`, `risk. admin`.
Məhdudiyyətlər: ödəniş əməliyyatları «kyc _ level», məsuliyyətli ödəniş limitləri, AML/sanksiya statusundan asılıdır.
Bloklama reyestrləri: 'org/brand/device/payment _ instrument' - write-də ABAC filtrləri.
Audit-jurnallar KYC/AML/nəticə hərəkətləri üçün dəyişməz; tənzimləmə müddətinə görə saxlama.
Tərəfdaş API: mTLS + müqaviləli 'scopes' marşrutları üzrə, geo/ASN-filtrlər perimetrdə.

16) Test və yoxlama

Negative matrisi: Açıq «qadağan olunmuş» halları sadalayın və testlərlə düzəldin.
Fuzz avtorizasiyası: 'tenant _ id', 'owner _ id' dəyişdirilməsi, paqinasiya/çeşidləmə zamanı filtrlərin yan keçməsi.
PDP yükləmə testi: p95/p99-da gizliliyi və cache davranışını yoxlayın.
Siyasət Release: dry-run + canary + gözlənilən deny/allow ilə avtomobil sverk.
Hadisələr: Siyasətlərin dəqiq versiyası ilə stenddə sorğuların səsləndirilməsi.

17) Antipattern

Obyekt yoxlamaları olmadan yalnız 'scope' arxalanır (BOLA).
Mərkəzləşdirilmiş model olmadan hər hendlerdə biznes məntiqi və hüquq yoxlamalarını qarışdırın.
Hardcoding UI rolları və müştəri həlləri etibar.
DB (leaky reads) sorğularında 'tenant '/' owner' filtrlərinin olmaması.
Rolların/münasibətlərin dəyişdirilməsi zamanı cash-qərarların əlilliyi yoxdur.
Uzun ömürlü JWT geri çağırılmadan/rotasiya.

18) Prod hazırlıq yoxlama siyahısı

• Resurslar/hərəkətlər, iyerarxiya və multi-icarə müəyyən edilmişdir.
• Əsas RBAC matrisi + lazım olan ABAC məhdudlaşdırıcıları - ReBAC.
• PDP/PEP dizayn; yerli cache həllər və onun əlillik var.
• Siyasətçilər CI mənfi ssenari testləri versiyası.
• Xüsusi 'resource _ id' üçün hər write/read-in BOLA-check.
• JWT minimal markalar, qısa 'exp'; audit/rəy 'jti'.
• Metrik/log həllər, dashboard, deny/latency ilə alert.
• kritik write üçün fail-closed; fallback rejimi sənədləşdirilmişdir.
• Müştəri sənədləri: 'scopes', səhv kodları (401/403/404/409), nümunələr.

19) TL; DR

BOLA-first avtorizasiyasını qurun: mərkəzi PDP + cache solutions, əsas kimi RBAC, kontekst üçün ABAC, münasibətlər üçün ReBAC. Bütün sorğular - 'tenant' və konkret 'resource _ id' kontekstində; deny-by-default, qısa JWT, DB-də obyekt filtrləri. Siyasətləri versiya və test edin, latency/deny ölçün, hadisələri replay edin. iGaming üçün - fərdi rollar (KYC/AML/kassa), sərt ABAC məhdudlaşdırıcıları və dəyişməz audit.