Segmentarea privilegiilor

1) De ce este necesară segmentarea

Segmentarea privilegiilor este cheia reducerii erorilor de „rază explozivă” și a abuzului din interior. Acesta vă permite să limitați cu precizie cine poate efectua ce acțiuni privind datele și unde, menținând în același timp viteza operațiunilor și conformitatea cu cerințele de reglementare.

• mai puține incidente din cauza „drepturilor de prisos”;
• accelerarea investigațiilor: accesul este transparent și explicabil;
• conformitatea cu SoD/conformitate, audit dovedibil;
• experimente sigure și eliberări rapide fără riscuri pentru nucleul de producție.

2) Principii

Zero Trust: fiecare acțiune este verificată contextual; fără „zone de încredere”.
Cel mai mic privilegiu: drepturi minime emise pentru o perioadă minimă (ideal JIT).
Contextul asupra rolului: drepturile depind nu numai de rol, ci și de atribute (chiriaș, regiune, mediu, risc).
Segregarea sarcinilor (SoD): inițiere, aprobare, execuție și audit separat.
Policy-as-Code: politici în cod cu versioning, teste și recenzii.

3) Modelul de maturitate a accesului

1. RBAC (roluri) - start - roluri fixe (suport, risc, plăți, tranzacționare, ops, SRE, conformitate).
2. ABAC (atribute): adăugați atribute: chiriaș, regiune, jurisdicție, produs, canal, mediu (prod/stage/dev), timp, clasa de risc de funcționare, semnale KRI.
3. PBAC (bazat pe politici): politici centralizate „cine/ce/unde/când/de ce” + condiții (de exemplu, „în vânzări - numai de JIT și cu un bilet”).

4) Domenii de segmentare (axă după axă)

4. 1 Chiriaș/Client

Accesul și operațiunile sunt limitate la un anumit brand/operator/afiliat.
Activitățile transfrontaliere sunt interzise, cu excepția agregatelor non-PII strict definite.

4. 2 Regiune/Jurisdicție

Politicile iau în considerare licențierea locală și normele KYC/AML.
Operațiile de date ale jucătorilor sunt limitate de geografia stocării și prelucrării.

4. 3 Mediu (dev/stage/prod)

Prod este izolat: credite individuale, rețele, Bastion/PAM, „citire numai în mod implicit”.
Acces la prod numai JIT, cu un bilet și schimbarea ferestrelor.

4. 4 Clasă de date

PII/finance/gaming telemetry/tehnologi - diferite niveluri de acces și mascare.
Export PII - numai prin fluxuri de lucru criptate aprobate și TTL.

4. 5 Criticalitatea operațiunilor

clase de P1/P2/P3: publicarea coeficienților, compensări manuale, concluzii, schimbarea rutării PSP - necesită control dual.
Operațiunile cu risc scăzut pot fi auto-ridicate de politică.

5) Niveluri de privilegiu (niveluri)

Vizualizator: agregate numai pentru citire și date mascate.
Operator - Efectuați procedurile de runbook fără a schimba configurațiile.
Contributor-Modifică configurații în domenii non-critice.
Aprobator: aprobarea cererilor și a operațiunilor cu risc ridicat (care nu sunt combinate cu execuția - SoD).
Admin (JIT): promovare pe termen scurt pentru sarcini rare sub control dual și înregistrarea sesiunii.

6) SoD și roluri incompatibile

• Inițiați concluzii ≠ aprobați ≠ finalizați.
• Creați o campanie bonus ≠ activați în vânzare ≠ modificați limitele.
• Dezvolta caracteristica ≠ se aplică eliberarea ≠ se rostogolească la prod.
• Solicitați o încărcare PII ≠ aprobați ≠ decriptați.

Pentru fiecare pereche - o politică formalizată de interdicție și excludere cu o dată de revizuire.

7) Acces JIT și PAM

Elevație la cerere: specificați ținta/biletul/termenul; după expirare - auto-rechemare.
Control dual: acțiuni P1/P2 - două aplicații din funcții diferite.
Controlul sesiunii: înregistrarea sesiunilor critice, alerte de anomalie, interdicția de copiere a pastei atunci când se lucrează cu PII.
Break-glass: acces de urgență cu limite dure și post-audit obligatoriu.

8) Conturi de service și scopuri API

Scopuri minime; Sarcină/microservice partiționare jetoane de scurtă durată/certificate.
Rotația secretelor, interzicerea secretelor împărtășite; interdicţia „Dumnezeu”.
Limitele ratei/cotelor, tastele de idempotență, semnătura cârligului web (HMAC).

9) Segmentarea nivelului infrastructurii

Rețele: izolarea segmentului (per domeniu/per chiriaș), inhibarea implicită a ieșirii, mTLS.
Kubernetes/Cloud: namespaces/proiecte per mediu și domeniu, Gatekeeper/OPA pentru a interzice modele periculoase.
DB/Caches: broker de acces (proxy DB/IAM), citire numai în mod implicit, DDL restricționând vânzările în afara ferestrei.
Depozite: diferite chei/găleți de date pe clasă cu TTL și politici WORM pentru audit.

10) Politici ca cod (PaC)

Politici în depozite (Rego/YAML), revizuire PR, teste auto (unitate/e2e), audit diff.
Contextul dinamic: ora zilei, locația, nivelul KRI, scorul de risc al operațiunii.
Explicabilitatea deciziei de autorizare/negare și trimiterea la politica de audit.

11) Jurnale și audit

Completitudine: cine/ce/unde/când/de ce, valorile pre/post, ID-ul biletului.
Non-schimbătoare: colectarea centralizată, WORM/imuabil, semnarea înregistrărilor.
Conectivitate: un lanț de console de administrare → API-uri → baze de date → furnizori externi.
Audit SLA: rata de răspuns la cererile de control/regulator.

12) Tablouri de bord și metrici (KPI/KRI)

Accesați KPI: cota de drepturi permanente JIT vs, durata medie a privilegiului,% acoperită de SoD, timpul de procesare a aplicației, acoperirea recertificării.
IRC de abuz: explozii de operațiuni sensibile, descărcare în masă, locații/ore atipice, secvențe „zayavka→deystviye→otkat”.
Tabloul de bord: urmărirea stării rolurilor cu risc ridicat, a evenimentelor de spargere a sticlei, a tendinţelor.

13) Exemple de politici (schițe)

Prod- операции: 'allow if role in {Operator, Admin} AND env = prod AND jit = true AND ticket! = null AND sod_ok AND time in ChangeWindow'.
Экспорт PII: 'permiteți dacă data_class=PII și scopul în ApprovedScops ȘI ttl <= 7d și criptare = ON AND aprobers> = 2'.
PSP- роутинг: 'permiteți dacă acțiunea = UpdateRouting ȘI dual_control ȘI risk_assessment_passed ȘI rollback_plan_attached'.

14) Foaie de parcurs de implementare (8-12 săptămâni)

Ned. 1-2: Operațiune/Rol/Inventar de date, Matrice SoD, Clasificarea datelor și Domenii de segmentare.
Ned. 3-4: baza RBAC, catalogul de roluri, JIT pentru console de producție, începutul PaC (OPA/Gatekeeper).
Ned. 5-6: ABAC: atribute de chiriaș/regiune/mediu/clasă de date; separarea spațiilor de nume/proiectelor.
Ned. 7-8: PAM (JIT-elevation, înregistrarea sesiunii, spargerea sticlei), prohibiția DDL și brokerul de baze de date, politicile de export PII.
Ned. 9-10: PBAC pentru operațiuni cu risc ridicat (concluzii, bonusuri, PSP), control dual, alerte KRI.
Ned. 11-12: Recertificare trimestrială, acoperire 100% cu risc ridicat a operațiunilor PaC, raportare și instruire.

15) Artefacte

Catalog de roluri: roluri, privilegii minime, proprietari.
SoD Matrix: roluri/operații incompatibile, excepții, proces de suprascriere.
Pachetul de politici: un set de politici PaC cu teste și exemple neagă/permit.
Formular de cerere de acces: scop, termen, obiect (chiriaș/regiune/mediu), evaluare a riscurilor, aplicații.
Înregistrare Ops sensibile: lista acțiunilor P1/P2, ferestre, criterii de control dual.
Audit Playbook: colectarea și furnizarea de jurnale, răspuns SLA, roluri.

16) Antipattern

Drepturi de administrare permanente și conturi generale.
Cross-chiriaș accesează „pentru comoditate”.
Nici un prod de izolare/etapa/dev.
Politici pe hârtie fără aplicare în cod/console.
PII export prin aranjament manual fără criptare și TTL.
Lipsa recertificărilor şi a drepturilor atârnate.

17) Linia de jos

Segmentarea privilegiilor nu este doar „roluri corecte”. "Aceasta este izolarea multidimensională (chiriaș, regiune, mediu, date, critică) + context dinamic (ABAC/PBAC) + procese (SoD, JIT, recertificare) + constrângere tehnică (PaC, PAM, rețele/DB). Această buclă reduce dramatic riscul de eroare și abuz, accelerează schimbarea sigură și face platforma rezistentă la cerințele de scară și de reglementare.