Controlul accesului și RBAC în API

1) De ce controlul accesului API

Autorizarea este răspunsul la întrebarea "Poate acest actor efectua această acțiune pe această resursă acum? ». Erorile duc la scurgeri BOLA/IDOR, escaladarea drepturilor și încălcarea cerințelor de reglementare. Scopul este de a construi un model pe mai multe niveluri: perimetru → service mash → reguli de afaceri, cu politici și verificări explicite la nivel de obiect.

2) Modele de autorizare: când să alegeți ce

RBAC (Role-Based Access Control) - roluri → permisiuni. Simplu, stabil, dar predispus la „explozie de rol”.
ABAC (Atribute-Based) - decizie cu privire la atributele subiectului/obiect/context (țară, nivel KYC, proprietar de resurse, risc).
ReBAC (Relation-Based) - grafic de relații (proprietar, membru al echipei, „manager de proiect”); rezolvă ierarhii complexe.
Scopes (OAuth) - un contract între client și serverul de resurse despre „zona de acces” (de exemplu, „plăți: scrie”).
Practică: RBAC pentru matrice de bază, ABAC pentru context și constrângeri, ReBAC pentru ierarhii complexe (dosare, organizații, limite și podaccounts).

3) Taxonomia resurselor și acțiunilor

Ierarhii: „org → proiect → portofel → tranzacție”. Moștenirea drepturilor de sus în jos cu posibile „limitatoare”.
Acțiuni: CRUD + specific domeniului ('aprobă', 'rambursează', 'soluționează').
Proprietăți resurse: proprietar, regiune, statut, etichete de risc (AML/KYC), limite.
Multi-chirie: toate soluțiile conțin 'chiriaș _ id'; nega-în-mod implicit.

4) Arhitectura: unde se ia decizia

PEP (Policy Enforcement Point) - site de verificare: gateway/API-gateway, mash lateral, serviciu în sine.
PDP (Policy Decizion Point) - motor de politică: centralizat (OPA-service, Cedar-motor) sau built-in bibliotecă.
PIP (Policy Information Point) - surse de atribut: director utilizator/rol, profil chiriaș, CCP/risc, harta proprietății resurselor.
AP (Policy Administration Point) - versiuni de politici, publicare, audit.

Recomandare: cache centralizat PDP + soluție locală în PEP; controale complexe ale obiectelor în serviciu în prezența invarianților de domeniu.

5) Jetoane, timbre și identitate

OIDC/OAuth2: „sub” (identificator subiect), „aud” (serviciu ţintă), „scope ”/„ roluri”, „chiriaş”, „kyc _ level”, „risk _ tier”.
JWT: semnătură RS/ES, scurtă „exp”, relansare prin reîmprospătare. Nu pune PII; utilizați „jti” pentru revocarea/urmărirea auditului.
mTLS/HMAC: service-to-service și parteneri; ștampilele sunt trase din directorul by 'client _ id'.
Dispozitiv/Context: IP/ASN, geo, ora zilei - autentificare la soluția ABAC (de exemplu, interziceți scrierea în afara orelor de lucru).

6) Autorizare la nivel de obiect (BOLA-first)

Fiecare operațiune trebuie să răspundă la "este subiectul proprietarului/are dreptul la acest" resource _ id'? ".

Verificarea proprietății: "resursă. owner_id = = subiect. id' sau de membru într-un „org” cu un rol.
Eșantioane de filtrare: întotdeauna suprapuneți resursa 'WHERE. tenant_id =: chiriaș ȘI "... (securitate la nivel de rând).
Pentru operațiunile de referință (ID în cale/corp) - normalizați și validați logica de afaceri.

7) RBAC Design: Roluri, Permisiuni, Seturi

Permisiuni - drepturi atomice: 'portofel. Citeşte, portofel. scrie „,” plata. rambursare ".
Roluri - numite seturi de permisiune: "admin", "suport. citeşte ',' casier ',' fraudă. analist ".

Scopuri - contract extern pentru clienți (cartografiere scope→permissions)

• roluri de bază + pachete de permisiune,
• Restricții ABAC (țară/regiune/chiriaș)
• „Acces la timp”.

8) ABAC/constrângeri contextuale

Geo/jurisdicție: interdicție de scriere din țări interzise (sancțiuni/reglementare).
Timp/risc: 'risk _ score <prag' pentru operațiuni mari.
ACC/limite: 'kyc _ level> = 2' pentru pini> X; controlul „răcirii” între tranzacții.
„Dispozitive de încredere”: necesită mTLS pentru partenerii de pe rutele periculoase.

9) ReBAC și graficul drepturilor

Utile pentru structuri complexe de afaceri (grupuri, echipe, branduri, sucursale).

Relații: „membru”, „admin”, „proprietar”, „privitor”.
Drepturi derivate: „vizualizatorul” resursei este moștenit de la „membru” al proiectului care aparține „org”.
Stocarea graficului: o bază de date cu o matrice de relații, un serviciu specializat (în spiritul abordării Zanzibar). Cache 'check (subiect, relație, obiect)' răspunsuri.

10) Soluție cache și performanță

Cache-ul PDP la nivelul PEP (de exemplu, într-un gateway) cu cheia: „sub” chiriaș „resursă” acțiune „politică _ versiune”.
Scurt TTL (secunde-minute) + handicap după eveniment: rol/relație/schimbare chiriaș.
Verificarea loturilor (authz în vrac) pentru liste: reduceți taxele PDP.
Măsurați soluțiile de latență; în timpul degradării - degradare grațioasă numai pentru citit (niciodată pentru scris/monetar).

11) Exemple de politici

11. 1 timbre JWT → PEP dur (pseudo-gateway)

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 Restricție de jurisdicție (politică de negare a listei)

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

11. 4 Politica ReBAC (pseudo)

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

12) Gestionarea politicilor și a versiunilor

Versionarea politicilor („policy _ version”) și canarul pentru schimbări periculoase.
„Dry-run” (decizii uscate/umbră) - jurnal „permite/nega” fără impact.
Directorul de politică și migrație: Cine a schimbat când și de ce; cartografierea incidentelor.
Teste pentru scenarii negative (cazuri interzise) - necesare în CI.

13) Observabilitate și audit

Jurnalele decizionale: 'trace _ id',' subject ',' chiriaş ',' action ',' resource _ id', 'result', 'policy _ version', motiv pentru eşec.
Metrics: 'authz _ decision _ latency', 'authz _ neged _ total {action}', parts of BOLA încercări, cache hit-rate.
Tablouri de bord: eșecuri de top de acțiuni/chiriași, tendințe după lansări de politici.

14) Siguranța și durabilitatea

Negare implicită: fără permisiune explicită = negare.
Eșec închis: atunci când PDP nu este disponibil, scrierea critică → interzisă (sau degradată la „setul minim” de roluri strict verificate).
„Controale de pază” locale în cadrul serviciilor pentru invarianții critici (de exemplu, „chiriaș ”/„ proprietar”).
Minimizarea semnelor distinctive în JWT; încărcați atribute sensibile prin PIP pe un canal securizat.

15) Specificul iGaming/Finanțe

Roluri: 'casier', 'kyc. agent ',' aml. Ofiţer, fraudă. analist ',' vip. manager „,” risc. admin ".
Restricții: tranzacțiile de plată depind de 'kyc _ level', limitele plăților responsabile, statutul/sancțiunile AML.
Registre de blocare: 'org/brand/device/payment _ instrument' - filtre ABAC la scriere.
Jurnalele de audit neschimbate pentru acțiunile KYC/AML/pin; stocarea în conformitate cu termenele de reglementare.
API-uri partenere: mTLS + contract 'scopes' pe rute, filtre geo/ASN pe perimetru.

16) Testarea și verificarea

Matricea negativă: enumerați cazurile explicite „interzise” și fixați cu teste.
Autorizație Fuzz: înlocuirea 'tenant _ id',' owner _ id', ocolirea filtrelor la paginare/sortare.
Testul de încărcare PDP: Verificați latența și comportamentul cache-urilor la p95/p99.
Eliberarea politicii: uscat-run + canar + auto-test cu negare/permite.
Incidente: cereri de reluare pe suport cu o versiune exactă a politicilor.

17) Antipattern

Bazați-vă numai pe „domeniul de aplicare” fără verificări ale obiectelor (BOLA).
Se amestecă logica de afaceri și cecuri de drepturi în fiecare handler fără un model centralizat.
Hardcode roluri în UI şi încredere soluţii client.
Absența filtrelor 'tenant '/' owner' în cererile către baza de date (citiri scurgeri).
Nu există nici o dizabilitate soluție cache atunci când se schimbă rolurile/relațiile.
JWT-uri cu durată lungă de viață fără rechemare/rotație.

18) Lista de verificare Prod Readiness

• Sunt definite resurse/activități, ierarhii și multi-chirie.
• Matrice RBAC de bază + limitatoare ABAC, acolo unde este necesar - ReBAC.
• PDP/PEP sunt proiectate; există o soluție locală cache și handicapul său.
• Politicile sunt versionate, testele de scenariu negative în CI.
• BOLA verifică în fiecare scriere/citire la un anumit "resource _ id'.
• JWT cu timbre minime, scurt „exp”; audit/rechemare pe „jti”.
• Măsurători/jurnale de decizii, tablouri de bord, alerte prin negare/latență.
• Nu se închide pentru scriere critică; modul de rezervă este documentat.
• Documentația clientului: „scopes”, coduri de eroare (401/403/404/409), exemple.

19) TL; DR

Construiți prima autorizație BOLA: cache central PDP + soluție, RBAC ca bază, ABAC pentru context, ReBAC pentru relații. Toate cererile sunt în contextul "chiriaș" și un anumit "resource _ id'; deny-by-default, scurt JWT, filtre obiect în baza de date. Versiune și politici de testare, măsura latență/negare, reluarea incidentelor. Pentru iGaming - roluri individuale (KYC/AML/casă de marcat), limitatoare ABAC dure și audit neschimbabil.