Controlul accesului la date

1) De ce este iGaming

Riscuri și reglementări: PII/finanțe, cerințe transfrontaliere, RG/AML.
Viteză și încredere: analize sigure de self-service și ML fără „distribuții” manuale.
Audit și responsabilitate: „cine a văzut ce și de ce”, probabilitatea principiului drepturilor minime.

2) Principii de bază

1. Cel mai puțin privilegiu - doar ceea ce ai nevoie și pentru momentul potrivit.
2. Segregarea sarcinilor (SoD) - dezvoltator ≠ aprobă accesul; analist ≠ proprietar de date.
3. Just-in-Time (JIT) - drepturi temporare, revocate automat.
4. Apărare în profunzime - protecție pe mai multe niveluri: rețea service tabel coloană rând celula.
5. Policy-as-Code - accesări și măști în cod/depozit, revizuire prin PR.
6. Conștient de proveniență - soluțiile se bazează pe catalog, descendență, clasificare și contracte.

3) Clasificarea datelor

Clase: Public/Intern/Confidențial/Restricționat (PII/Finanțe).
Etichete în diagrame și catalog: „pii”, „financiar”, „tokenized”, „mascare”, „rle” (rând-nivel), „cle” (coloană-nivel), „geo = EU/TR/...”, „chiriaș”.

• Restricționate: jetoane/măști peste tot; detokenizare numai în „zona curată”, la cerere.
• Confidențial: acces cu măști implicite; îndepărtarea măștilor - prin justificare și JIT.
• Intern/Public: pe roluri de domeniu, fără PII.

4) Modele de autorizare

RBAC (rol-base.) : start rapid, cataloage de roluri („Marketing-Analyst',” Risk-Ops').
ABAC (atribut-basis.) : tara, brand, mediu (prod/stage), proiect, scop de procesare, timp, nivel de risc.
ReBAC (prin relație): „proprietar de set”, „administrator de domeniu”, „referent”.
Hibrid: RBAC ca cadru, ABAC rafinează limitele.

5) Granularitatea accesului

Rețea/intrare: mTLS, allow-list, link-uri private.
Serviciu/cluster: roluri IAM, cont de servicii cu un minim de privilegii.
Depozite: cataloage/diagrame/tabele (GRANT), securitate la nivel de rând (RLS), securitate la nivel de coloană (CLS).
Mascare/tokenizare: măști dinamice în SQL/BI; jetoane în loc de PII.
Fichestor/ML: acces numai la agregate/caracteristici permise; politica de caracteristici (permite/nega).
Fișiere/obiecte: legături pre-semnate cu TTL, politica de criptare și descărcare.

6) Modele pentru domenii cheie

KYC/AML: CLS (numai jetoanele sunt vizibile), RLS pe țări operatoare; detokenization - DPO/Legal by JIT.
Plăți: Restricționate, token-uri FLE +, Risc/Plăți-Ops acces prin JIT; încărcări auditate.
Evenimente de joc: Intern/Confidențial, RLS după marcă/regiune/chiriaș, CLS pentru user_id.
Joc responsabil: RG comandă acces la agregate; cazuri individuale - la cerere.
BI/ML: vitrine „de aur” fără PII; ML - lista de caracteristici permise, jurnal de justificare pentru cele controversate.

7) Proceduri de acces

7. 1 Cerere → aprobare a dispozițiilor →

Formular de rechiziție: scop, domeniu de aplicare, termen, rol, atribute ABAC, proprietar set.
Verificare automată: clasa de date, SoD, instruire finalizată? conflict de interese?
RACI: Proprietar (R), Steward (C), DPO/Sec (A/C), IT/IAM (R).

7. 2 JIT и spargerea sticlei

JIT: 15 min/2 h/1 zi cu auto-rechemare; reînnoire - pe o nouă cerere.
Spargerea sticlei: pentru incidente; roluri/chei individuale, audit îmbunătățit, post-mortem necesar.

7. 3 Recenzii regulate

Revizuirea accesului trimestrial: Proprietarii de domenii confirmă rolurile/atributele.
Dezactivarea automată a acceselor „uitate” (fără utilizare 30/60 zile).

8) Mecanisme tehnice

Catalog și contracte: o sursă de adevăr despre proprietari, clase, măști.
Motor de politică: OPA/echivalent pentru politicile ABAC/rând/coloană.
Mascarea datelor: măști dinamice în DWH/BI; format mască în condiții de siguranță pentru telefoane/e-mail.
Tokenizare: seif/FPE; detokenizare numai în „zona curată”.
Secretele & PAM: manager secret, sesiuni JIT, ecrane de înregistrare pentru accesele admin.
Audit și SIEM: jurnale imuabile (WORM), corelarea evenimentelor de acces cu sesiuni și încărcări.
Izolatoare geo/chiriaș: separare fizică/logică (scheme, directoare, clustere, chei de criptare).

9) Consimțământ și DSAR

Accesele iau în considerare consimțământul jucătorului (marketing = off → ascunde atributele de marketing).
Butoane DSAR: găsiți/descărcați/ștergeți după token; jurnalul întregii operațiuni; Legal Hold contează.

10) Monitorizare și SLO

Acces SLO: p95 timp de emitere acces JIT (de exemplu ≤ 30 min).
Zero-PII în jurnale: 100% evenimente fără PII.
Rata de anomalie: alerte pentru SELECT spike sau atipic JOIN la Restricționat.
Review Acoperire: ≥ 95% din roluri sunt revizuite la timp.
Masca Hit-Rate: Proporția de cereri în cazul în care masca/token a fost declanșat.
Detokenization MTTR: timpul mediu de procesare a unei aplicații valide.

11) Șabloane

11. 1 Politica de acces (fragment)

Principiu: cel mai mic privilegiu + SoD + JIT.
Roluri: un catalog de roluri cu o descriere a sarcinilor/vitrinelor.
Atribute ABAC: „țară”, „marcă”, „env”, „scop”, „retenție”.
Măști/jetoane: Activ pe Confidențial/Restricționat în mod implicit.
Revizuire: trimestrial; auto-rechemarea acceselor „uitate”.
Încălcări: blocare, investigare, formare.

11. 2 Formular de cerere

Cine: Numele complet/echipa/manager.
Ce: Set/Tabel/Vitrină/Caracteristică.

De ce: Obiectiv, Rezultat așteptat/Metrics

Cât timp: termen/program.
Clasa de date: (completare automată din catalog).
Semnături: Proprietar/Steward, DPO sau Sec (dacă este restricționat).

11. 3 Catalog de roluri (exemplu)

Marketing-Analyst: Marte de marketing interne/confidențiale; fără detokenizare; RLS după marcă.
Opțiuni de risc: plăți restricționate cu măști; JIT pentru detokenizare; export numai prin șabloane „albe”.
RG-Team: unități RG, acces la cazuri la cerere.
DS/ML: ficestor (caracteristică de listă permisă), cutie de nisip fără PII.

12) Foaia de parcurs privind implementarea

0-30 zile (MVP)

1. Clasificarea datelor și a etichetelor în scheme.
2. Catalog de roluri + atribute ABAC de bază (țară/marcă/env).
3. Mascare/tokenizare implicită pentru Confidențial/Restricționat.
4. Procesul JIT și jurnalul de audit; Regulamentul de spargere a sticlei.
5. RLS/CLS pentru plăți, KYC, evenimente de jocuri de noroc; excluderea „SELECTAȚI” pentru Restricționat.

30-90 zile

1. Policy-as-Code în CI (cerere linter, blocuri în caz de încălcare).
2. Integrarea cu consimțământul/DSAR; accesează rapoartele SLO.
3. Revizuirea trimestrială a accesului; dezactivare automată.
4. PAM pentru admin access; Caseta de timp sesiuni de înregistrare.

3-6 luni

1. Izolarea geo/chiriașilor, cheile de criptare individuale în funcție de jurisdicție.
2. Auto-recomandări de roluri bazate pe solicitări reale (bazate pe utilizare).
3. Analiza comportamentală a accesului (anti-analiză), cărți de redare SOAR.
4. Certificarea proceselor și auditul extern.

13) Anti-modele

„Superuser” pentru toți - fără SoD și JIT.
Partajarea datelor prin fișiere/capturi de ecran în afara canalelor controlate.
RLS/CLS numai „pe hârtie” - măștile sunt oprite în BI.
Nici o revizuire a drepturilor și auto-rechemare; acces „etern”.
Catalogul/contractele nu sunt actualizate - regulile de acces sunt depășite.
Detokenizarea în aplicații „pentru comoditate” fără audit.

14) RACI (exemplu)

Politici/Arhitectură: CDO/CISO (A), DPO (C), SecOps (R), Data Platform (R).
Emisiune de acces: IAM/IT (R), Proprietari (A/R), Stewards (C), Manageri (I).
Audit/Revizuire: Proprietari (R), DPO/Sec (A), Audit intern (C).
Incidente: SecOps (R), Legal/PR (C), Domenii (R).

15) Secțiuni conexe

Gestionarea datelor, tokenizarea datelor, securitatea și criptarea datelor, originea și calea datelor, etică/DSAR, ML confidențial, învățare federalizată.

Total

Controlul accesului este un sistem de politici, atribute și automatizări care oferă echipelor datele potrivite în exact cantitatea și timpul potrivit, lăsând trasabilitatea completă. În iGaming, aceasta este baza încrederii în valori, reziliența incidentelor și viteza de luare a deciziilor.