Motor de rol

1) Modele de autorizare

RBAC (Role-Based Access Control): subiectul primește roluri, rolurile sunt asociate cu permisiuni. Doar gestiona, bun pentru îndatoririle tipice.
ABAC (Atribute-Based Access Control) - soluția depinde de atributele subiectului, resursă, acțiune și mediu (timp, IP, regiune, risc). Flexibil și scalabil la reguli complexe.
RBAC + ABAC hibrid: rolurile dau o abilitate „de bază”, atributele îngustează (condițiile).
(Opțional) ReBAC/Relație-based: grafic relație (proprietar, membru al echipei, delegat), util pentru documente și orgii.

2) Arhitectură: PDP/PEP și fluxuri

PEP (Policy Enforcement Point): unde se aplică soluția (API gateway, backend method, SQL layer, UI).
PDP (Policy Decision Point): serviciu/bibliotecă care calculează 'ALLOW/DENY' prin politici și atribute.
PIP (Policy Information Point): surse de atribut (IdP/profil, metadate de resurse, rata de risc, geo).
AP (Policy Administration Point) - interfață administrativă/depozit de politici (versiuni, proiecte, publicații).

Flow: cererea de → PEP formează un context → PDP trage atributele lipsă (prin PIP) → calculează decizia → se aplică PEP (activați/dezactivați/decuplați câmpurile) → audit.

3) Modelul de date

• 'subject' (user/service) с атрибутами: 'chiriaş _ id',' roluri ',' departamente ',' risc _ level ',' mfa _ verified ',' scopes ',' revendicări '.
• 'resource' cu text şi atribute: 'type', 'owner _ id',' tenant _ id', 'clasificare' (public/confidenţial), 'region', 'tags'.
• 'action': 'read', 'write', 'delete', 'export', 'approve', 'impersonate' и т. п.
• 'environment': 'time', 'ip', 'device', 'geo', 'auth _ strength', 'business _ context' (канал, тариф).

• 'roles (id, tenant_id, name, moșteniri [])' - ierarhii și modele de sprijin.
• „permissions (id, resource_type, acțiune, constrângere?)”.
• 'role _ permissions (role_id, permission_id)'.
• „misiuni (subject_id, role_id, domeniu de aplicare)” - domeniu de aplicare: global/pe proiect/pe obiect.

• 'politicy (id, effect = allow' deny, target: {subject, resource, action}, condition: expr, priority, version, status) '.

4) Principii decizionale

Negarea: interdicțiile explicite acordă prioritate permisiunilor.
Cel mai mic privilegiu (PoLP): Eliberați accesul minim necesar, extindeți-vă prin condiții.
Separarea sarcinilor (SoD): interzicerea combinațiilor de roluri/acțiuni (de exemplu, „plata creată” ≠ „arestată”).
Context conștient: Consolidarea cerințelor cu risc mai ridicat (fără MAE, IP suspecte).
Determinismul: același context → același răspuns; Conectați versiunea de politică.

5) Modele de implementare

5. 1 RBAC→ABAC hibrid (condiționat)

yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5. 2 rând/câmp-nivel de securitate

La nivelul bazei de date: politici RLS (prin „chiriaș _ id',” proprietar _ id').
La nivelul API: colecții de filtre și câmpuri de mască dacă nu există 'allow: read_sensitive_fields'.

5. 3 Soluții pas cu pas

allow if action == "export" and subject. mfa_verified == true else deny

5. 4 Toleranţe temporare

Granturi cu TTL: "atribuire. expires_at', acces „ferestre” (în timpul orelor de lucru din regiunea de resurse).

6) Performanță și cache

Decizia cache prin cheie „(subject_hash, resource_key, acțiune, policy_version)” cu TTL scurt.
Memoria cache a atributelor subiectului (revendicări în token) + atribute de resurse leneș-preluare.
Invalidare incrementală: handicap în funcție de evenimente (schimbare de rol, schimbare de politică, transfer de resurse către „confidențial”).
Verificarea loturilor: pentru liste - evaluați cu un „filtru” (pushdown de previziune a politicilor) pentru a nu trage linia PDP după linie.

7) Multi-chiriaș

În fiecare tabel - "chiriaș _ id'; politicile implicite restricționează accesul în cadrul unui contract de leasing.
Administratorii de leasing gestionează numai rolurile/drepturile de închiriere.
Acces cross-leasing - exclusiv prin invitații explicite/partajare cu deny-suprascriere explicită.

8) Administrarea politicilor și ciclul de viață

Versioning: "politica. versiunea "în răspunsul PDP, stoca în audit.
Medii: draft canar → (părți ale traficului/modul umbră) → prod.
Matrice de testare: tabele de adevăr după roluri/atribute cheie (teste de contract).
Managementul schimbării: Îmbinați cererile de politici cu revizuiri de securitate/conformitate.

9) Audit și observabilitate

Журнал решений: 'decision _ id',' subject ',' action ',' resource _ ref ',' result ',' matched _ policies ',' policy _ version ',' attributes _ digest '.
Valori: QPS PDP, p95 latență, hit-rate cache, neagă cota, rata de pas-up, incidente SoD.
Urme: interval per apel PDP; corelație cu cererea API.
Replay: abilitatea de a „relua” deciziile istorice privind noua versiune a politicii (verificarea siguranței).

10) Integrarea cu autentificare și jetoane

Identitate - de la IdP (OIDC/SAML). Jetoanele poartă un minim de atribute: „sub”, „chiriaș”, „roluri”, „auth _ time”, „amr”, „scopes”.
Pentru ABAC, trageți semnele „grele” din partea serverului (PIP) pentru a nu umfla jetonul.
Token-uri de resurse semnate (capabilitate/invitații) - pentru delegații strict limitate.

11) PDP pseudo cod (simplificat)

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12) Anti-modele

„Role = page” (sute de roluri mici fără model de domeniu).
Stocați politicile numai în cod fără versiuni/audituri.
Lipsa negării și SoD → creșterea riscului de fraudă.
Hard liste 'user _ id' in reguli (în loc de atribute/relații).
Fără filtrare a straturilor de date (RLS) numai cu filtru UI.
Sincronizarea rolurilor prin scripturi manuale fără evenimente și dizabilități cache.

13) Cazuri și rețete

13. 1 Mascare la nivel de câmp:

allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13. 2 Exportați date numai cu MAE:

allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13. 3 SoD:

deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13. 4 Delegație (token restrâns):

Capacity token conține' resource _ id',' actions = [” read”] ',' expires _ at ',' aud '. PEP verifică semnătura și termenul limită.

14) Testarea

Testele unitare ale politicilor: tabelele adevărului prin combinații majore.
Bazat pe proprietate: generarea de atribute aleatorii pentru a găsi „găuri”.
Teste de aur: fixarea unui set de soluții pentru punctele finale critice.
Canare/Umbră: evaluarea paralelă a versiunilor vechi și noi ale politicilor cu înregistrarea discrepanțelor.

15) Capacitățile conexe ale secțiunii „Arhitectură și protocoale”

Autentificare și autorizare (OIDC/OAuth2)

Managementul consimțământului

Tokenizarea și managementul cheie

Observabilitate: busteni, valori, urme

Geo-rutare și localizare

În repaus/criptare în tranzit

16) Lista de verificare a arhitectului

1. Sunt definite rolurile subiectului și ierarhiile lor?
2. Există un model hibrid: roluri + condiții pe atribute?
3. Implementat PDP cu deny-suprascrie, SoD și pas-up?
4. Unde este PEP? (gateway, backend, baza de date, UI) - este uniformă peste tot?
5. Sunt cache-urile de soluție și dizabilitatea evenimentelor configurate?
6. Sunt politicile versionate, testate, rulate prin proces?
7. Sunt activate deciziile de audit, valorile și urmele?
8. Multi-leasing și RLS/camp-mascare acceptate?
9. Ai o carte despre incidente şi regresia politicilor?

Concluzie

RBAC oferă controlabilitate, ABAC oferă context și precizie. Prin combinarea rolurilor cu condițiile de atribut, partajarea PDP/PEP, implementarea caching-ului, auditarea și testarea politicilor, construiți autorizarea ca o capacitate de platformă: predictibilă, verificabilă și scalabilă pentru cerințele de produs și de reglementare.