RBAC: gestionarea rolurilor și permisiunilor

1) Obiectivele și principiile RBAC

Scop: Faceți accesul ușor de gestionat, verificabil și minim în volum pentru a proteja banii/PII și conformitatea (GDPR/AML/PCI/ISO).
Principii: Cel mai mic privilegiu· Need-to-Know· Separarea îndatoririlor (SoD)· Zero Trust· Revocabilitate (rechemare rapidă)· Auditabilitate (probabilitate).

2) Taxonomia drepturilor și rolurilor

• Date: 'READ', 'WRITE', 'EXPORT', 'DELETE', 'MASKED_READ' (implicit pentru PII).
• Operațiuni: 'APPROVE_RETRAGERE', 'CHANGE_FRM_RULE', 'KYC_DECISION', 'SANCTIONS_OVERRIDE'.
• Admin: 'ROLE_UPDATE', 'USER_PROVISION', 'SECRET_ROTATE', 'BREAK_GLASS'.
• Integrări: 'API_CALL:', 'WEBHOOK_SIGN', 'SERVICE_CONFIG_UPDATE'.

• Core (end-to-end): 'employee_basic', 'viewer_intern', 'auditor_privacy'.
• De domeniu: 'support_agent', 'vip_manager', 'payments_ops', 'aml_officer', 'kyc_operator', 'fraud_analist', 'rg_specialist', 'bi_analist'.
• Sistem/acelea: 'devops_admin', 'dba_admin', 'service_account _', 'read_only_prod'.
• Privilegiat (prin PAM/JIT): 'break_glass_admin', 'prod_db_jit_editor'.

3) Ingineria rolului

1. Inventarul resurselor: sisteme/tabele/puncte finale, clase de date (Public/Intern/Confidential/Restricted/High Restricted).
2. Povești de utilizator după funcții: cine ce face și de ce (scop).
3. Maparea sarcinilor → permisiuni - set minim pe funcție.
4. Gruparea în rol: un rol = un domeniu de responsabilitate; evita „super roluri”.
5. Testarea SoD: verificarea incompatibilităților (de ex. 'payments_ops' ≠'fraud_rule_admin').
6. Pilot și măsurare: emitem un grup limitat temporar, colectăm o pistă de audit.
7. Versioning: Fiecare schimbare de rol este prin CAB cu changelog.

4) Interacţiunea RBAC ↔ ABAC ↔ SoD

RBAC răspunde „cine în principiu poate”, ABAC - „în ce condiții” (mediu, geo, dispozitiv/MDM, timp, nivel KYC, „scop”).
SoD interzice combinațiile de roluri periculoase și necesită 4 ochi pentru acțiuni critice.
Practică: în mod implicit, rolurile dau MASKED_READ la PII; accesul demascat necesită un atribut „scop” + JIT și o decizie pozitivă privind politica ABAC.

5) Multi-chirie și geo-context

Chiriaș: Rolurile sunt legate de un contract de închiriere/marcă/jurisdicție ('rol: payments_ops @ EEA').
Geo-chei: chei de criptare individuale și segmente de acces pe regiune (EC/UK/...).
Granularitate: filtrare după coloana „region_code” (RLS) și după jurisdicția jucătorului.

6) Rând/Coloana-nivel de securitate și mascare

• RLS (siruri de caractere): Acces numai la înregistrările țării/mărcii/echipei.
• CLS (coloane): câmpurile sensibile sunt disponibile mascate; demascate - numai cu privilegiul 'pii_unmask' + 'scop'.

sql
CREATE POLICY rls_tx
ON dwh. transactions
USING (region_code = current_setting('app. region'));

SELECT
CASE WHEN has_priv('pii_unmask') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

7) JIT, sticlă spartă și PAM în RBAC

JIT: rol temporar privilegiat (15-120 min) sub bilet; feedback automat; audit complet.
Break-glass: acces de urgență cu confirmarea MFA + a doua și înregistrarea sesiunii; post-review cu Securitate + DPO.
PAM: magazin secret, proxy sesiune, rotație parolă/cheie.

8) Ciclul de viață al rolului (POS)

SOP-1: Creare/Modificare rol

1. Anchetă a proprietarului domeniului lista de sarcini cartografierea permisiunilor SoD-check pilot CAB eliberare + documentație.

SOP-2: Cerere și acces la grant

1. Aplicație (IDM/ITSM) cu „scop” și termen limită → SoD/jurisdicție auto-verificare → aprobarea proprietarului de date + Securitate (pentru restricționate +) → emiterea (de multe ori JIT) → intrarea în registru.

SOP-3: Feedback/Offboarding

Declanșatoare: Terminare, schimbare de rol, inactivitate> 30/60 zile, JIT a expirat.
Rechemare automată și jurnal.

SOP-4: Re-certificare

Trimestrial, proprietarii confirmă că rolurile utilizatorilor sunt încă necesare; sistemul elimină drepturile de „spânzurare”.

9) Exemplu de matrice de rol (fragment)

10) Instrumente și implementare (modele)

Catalog de roluri ca cod: YAML/JSON în depozit + validatoare CI, changelog.
IdP central/SSO: provizionare SCIM, mapări de grup „grup → rol”.
Punct de decizie de politică: motor de politică (ABAC) cu atribute contextuale.
Secretele/KMS: izolarea cheie pe mediu/regiune/chiriaș.
Data gateway: un singur strat de mascare/audit pentru DWH/BI/exporturi.
SIEM/SOAR: corelație 'ROLE_UPDATE'/'READ_PII'/'EXPORT_DATA', auto-bilete.

11) Audit și exploatare forestieră

Evenimente obligatorii: 'ROL_ATRIBUIRE', 'ROL_REVOCARE', 'ROL_ACTUALIZARE', 'PAUZĂ _ STICLĂ', 'JIT_GRANT', 'CITIRE_PII', 'EXPORT_DATE', 'PLATĂ _ APROBARE', 'KYC_DECIZIE'.
Cerințe: copie WORM, lanțuri hash, semnătura pachetului, "scop "/" ticket_id' în fiecare eveniment, sincronizarea timpului.

12) Valori și KPI/KRI

Acoperire:% din sisteme sub RBAC ≥ 95%.
Încălcări ale SoD: = 0; încercările de a atribui roluri incompatibile - auto-bloc.
Rata JIT: ≥ 80% din creșteri sunt JIT.
Offboarding TTR: revocarea drepturilor ≤ 15 min.
Raportul citirilor mascate: ≥ 95% dintre apelurile către PII sunt mascate.
Recertificare: 100% roluri confirmate trimestrial.
Exporturi semnate: 100% din exporturi cu semnătură/jurnal.

13) RACI (mărită)

14) Liste de verificare

Înainte de a crea un rol

• Povești de utilizator descrise și „scop”
• Lista resurselor și a claselor de date
• Maparea permisiunilor minime
• Verificarea SoD/conflicte
• Mascarea și politica RLS/CLS
• Planul de re-certificare și proprietarii

Înainte de acordarea accesului

• Fixed 'scop' și data
• SoD/jurisdicții/MDM/MFA completat
• Implicit mascare, JIT pe promovare
• Jurnalul și data revizuirii incluse

15) Erori frecvente și anti-modele

„Super roluri” cu drepturi largi în loc de cele de domeniu mic.
Acces direct la PII fără mascare și „scop”.
Nu există ochi SoD/al patrulea pentru 'PAYMENT_APPROVE'/'KYC_APPROVE'.
Extinderea drepturilor temporare „pentru totdeauna”.
Copiați datele prod în dev/etapă.
Export opac fără semnătură și jurnal.

16) Foaia de parcurs privind implementarea

Săptămânile 1-2: inventarierea activelor/clasificarea datelor; un proiect de matrice de roluri; Masa SoD.
Săptămânile 3-4: RBAC ca cod (depozit), grupuri IdP/SCIM, motor ABAC (atribute de bază: mediu/geo/MDM/timp), JIT/PAM, strat de mascare pentru DWH/BI.
Luna 2: re-certificare, automatizare offboarding, alerte SOAR pentru încălcări RBAC/SoD/ABAC, jurnale de export/WORM.
Luna 3 +: extinderea atributelor (riscul dispozitivului, nivelul KYC), audituri de părtinire a accesului, optimizarea costurilor și exerciții regulate de masă.

TL; DR

Puternic RBAC = roluri de domeniu mici + condiții de atribut (ABAC) + SoD și JIT/PAM + mascare și RLS/CLS + audit greu și re-certificare. Acest lucru reduce riscul de scurgeri/abuzuri, accelerează auditul și menține platforma în limitele cerințelor de confidențialitate și conformitate.