Controllo dell'accesso ai dati

1) Perché questo iGaming

Rischio e regolazione: PI/finanza, transfrontaliera, RG/AML-requisiti.
Velocità e fiducia: l'autosufficienza sicura di analisti e ML senza «distribuzione» manuale.
Controllo e responsabilità: «Chi ha visto e perché», la prova del principio dei diritti minimi.

2) Principi di base

1. Least Privilege: solo per il tempo desiderato.
2. Segregation of Duties ( ) è uno sviluppatore che approva l'accesso; Analista proprietario dei dati.
3. Just-in-Time - Permessi temporanei e automaticamente revocabili.
4. Defense in Depth - Protezione su più livelli - Rete → Servizio → Tabella → Colonna → Riga → Cella.
5. Policy-as-Code - Accessibilità e maschere nel codice/repository, rivitalizzando tramite PR.
6. Provenance-aware - Le soluzioni si basano su catalogo, linea, classificazione e contratti.

3) Classificazione dei dati

Classi: Public/Internal/Confidential/Restringted (PII/Finanza).
Etichette nei diagrammi e nella directory: «pii», «financial», «tokenized», «masking», «rle» (row-level), «cle» (column-level), «geo = EU/TR/...», «tenant».

• Restrited: token/maschere ovunque; Disinstallazione solo nella «zona pulita» richiesta.
• Confidential - Accesso predefinito con maschere rimozione maschera - tramite giustificazione e JIT.
• Internal/Public: per ruolo di dominio, senza PII.

4) Modelli di autorizzazione

RBAC (ruolo-bazire) : avvio rapido, cataloghi di ruoli (Marketing-Analyst, Risk-Ops).
ABAC (attributo-bazar) : paese, marchio, ambiente (prod/stage), progetto, scopo di elaborazione, tempo, rischio-livello.
«proprietario del set», «steward del dominio», «reviver».
Hybrid: RBAC come ossatura, ABAC specifica i limiti.

5) Granularità di accesso

Rete/ingress: mTLS, allow-list, private links.
Strumenti/cluster: ruoli IAM, service account con privilegi minimi.
Repository: directory/schemi/tabelle (GRANT), RLS (Row-Level Security), Column-Level Security (CLS).
Maschera dinamica in SQL/BI token invece di PII.
Fichestor/ML: accesso solo a aggregazioni/fiocchi autorizzati; Criterio dei segni (allow/deny).
File/oggetti: collegamenti pre-firmati con TTL, crittografia e criteri di download.

6) Pattern per domini chiave

KYC/AML: CLS (visibile solo ai token), RLS per paese dell'operatore; detonazione - DPO/Legale per JIT.
Pagamenti: Restrited, FLE + token, accesso Risk/Payments-Ops tramite JIT; download verificabili.
Eventi di gioco: Internal/Confidential, RLS per marchio/regione/tenante, CLS per user _ id.
Responciabile Gaming: accesso ai comandi RG; valigette individuali, su richiesta.
BI/ML: vetrine «dorate» senza PII; ML è la lista dei file autorizzati, il registro delle scuse per le controversie.

7) Procedure di accesso

7. 1 Richiesta di allineamento delle provviste

Modulo di richiesta: obiettivo, volume, scadenza, ruolo, attributi ABAC, proprietario del set.
Classe dati, SoD, formazione completata? conflitto di interessi?
RACI: Owner (R), Steward (C), DPO/Sec (A/C), IT/IAM (R).

7. 2 JIT и break-glass

JIT: 15 min/2 ore/1 giorno con richiamo automatico; la proroga è una nuova richiesta.
Break-glass: per incidenti; ruoli/chiavi separati, controllo rafforzato, post mortem obbligatorio.

7. 3 Gelosia regolare

Access review trimestrale: i proprietari dei domini confermano i ruoli/attributi.
Disattivazione automatica delle accessorie'dimenticate '(no-use 30/60 giorni).

8) Meccanismi tecnici

Catalog & Contracts è una fonte di verità su proprietari, classi, maschere.
Policy Engine: ORA/equivalente per ABAC/Row/Column-Policy.
Data Masking: maschere dinamiche in DWH/BI; formato-cassaforte maschera per telefoni/email.
Tokenization: vault/FPE; La detonazione è solo nella «zona pulita».
Secret & PAM: gestore segreto, sessioni JIT, scrittura schermata per accessibilità.
Check & SIEM: Logi invariati (WORM), correlazione degli eventi di accesso con sessioni e scarichi.
Isolanti Geo/tenant: separazione logica (schemi, directory, cluster, chiavi di crittografia).

9) Consent & DSAR

La disponibilità tiene conto del consenso del giocatore (marketing = off per nascondere gli attributi di marketing).
Tasti DSAR: trova/carica/rimuovi per token; il login dell'intera operazione; Legale Hold è considerato.

10) Monitoraggio e SLO

Access SLO: p95 tempo per l'accesso JIT (ad esempio, 30 min).
Zero-PII in logs: 100% eventi senza PII.
Anataly rate: alert in caso di picco SELECT o JOIN non comuni a Restrited.
Review Coverage: il 95% dei ruoli è invecchiato.
Mask Hit-Rate è la percentuale di richieste in cui la maschera/token ha funzionato.
Detokenization MTTR - Tempo medio di elaborazione della richiesta valida.

11) Modelli

11. 1 Criterio di accesso (sezione)

Il principio è least private + SoD + JIT.
Ruoli: directory dei ruoli che descrivono le operazioni/le vetrine.
Attributi ABAC: «country», «brand», «env», «purpose», «retention».
Le maschere/token sono attive per impostazione predefinita su Confidential/Restringted.
La gelosia è trimestrale; una recensione automatica delle accessibilità «dimenticate».
Violazioni, blocco, indagine, addestramento.

11. 2 Modulo di richiesta

Chi? FIO/team/manager.
Cosa: set/tabella/vetrina/fici.
Perché: obiettivo, risultato atteso/metriche.
Per quanto tempo, data/ora.
Classe dati: (automatizzato dalla directory).
Etichette: Owner/Steward, DPO o Sec (se Restrited).

11. 3 Catalogo ruoli (esempio)

Marketing-Analyst: Internal/Confidential Vetrine Marketing; senza detonazione; RLS del marchio.
Risk-Ops: Rimborsi con maschere JIT per la detonazione; esportare solo tramite modelli bianchi.
RG-Team: aggregazioni RG, accesso alle valigette su richiesta.
DS/ML - Fifistor (allow-list fich), sandbox senza PII.

12) Road map di implementazione

0-30 giorni (MVP)

1. Classificazione dei dati e delle etichette negli schemi.
2. Catalogo ruoli + attributi ABAC di base (paese/marchio/eng).
3. Maschera/tornitura predefinita per Confidential/Restringted.
4. Processo JIT e registro di verifica break-glass regola.
5. RLS/CLS per pagamenti, KYC, eventi di gioco; «SELECT» per Restritted.

30-90 giorni

1. Policy-as-Code in CI (linter query, blocchi in caso di violazione).
2. Integrazione con Consent/DSAR Report di accesso SLO.
3. Access review trimestrale; disattivazione automatica.
4. PAM per la disponibilità admine scrittura delle sessioni time box.

3-6 mesi

1. Isolamento geo/tenant, singole chiavi di crittografia per giurisdizione.
2. Linee guida automatiche dei ruoli basate su query effettive (usage-based).
3. Analisi di accesso comportamentale (anti-anoma), playbook SOAR.
4. Certificazione dei processi e controllo esterno.

13) Anti-pattern

«Superuser» per tutti, senza SoD o JIT.
Decifrare i dati attraverso file/screenshot al di fuori dei canali controllati.
RLS/CLS solo «su carta» - Le maschere sono spente in BI.
Nessun diritto e revoca automatico; L'eternità è disponibile.
La directory/i contratti non vengono aggiornati. Le regole di accesso sono obsolete.
Disinstallazione nelle applicazioni per la comodità senza controllo.

14) RACI (esempio)

Criteri/architettura: CDO/CISCO (A), DPO (C), SecOps (R), Data Platform (R).
Disponibilità: IAM/IT (R), Owners (A/R), Stewards (C), Manager (I).
Controllo/gelosia: Owners (R), DPO/Sec (A), Internal Auditel (C).
Incidenti: SecOps (R), Legale/PR (C), Domini (R).

15) Partizioni correlate

Gestione dei dati, Tokenizzazione dei dati, Sicurezza dei dati e crittografia, Origine e percorso dei dati, Etica/DSAR, Privacy ML, Federated Learning.

Totale

Il controllo dell'accesso è un sistema di regole, attributi e automazione che fornisce ai comandi i dati giusti nella quantità e nel tempo giusti, lasciando la tracciabilità completa. Nel iGaming è la base per la fiducia nelle metriche, la resistenza agli incidenti e la velocità decisionale.