GH GambleHub

Criteri di accesso e segmentazione

1) Scopo e principi

Obiettivo: ridurre al minimo il rischio di fuoriuscite/frodi e gli effetti regolatori attraverso il controllo rigoroso del «chi, a cosa e perché ha accesso», con prove di verifica.
Principi: Least Privilege (minimo diritti), Need-to-Know, Zero Trust, Segregation of Duties (SoD), Just-in-Time (JIT), tracciabilità e revoca dell'accesso in un clic.

2) Classificazione dei dati e livelli di protezione

ClasseEsempiProtezione e accesso
Publicpagine statiche, marketingDisponibile senza autorizzazione
Internalmetriche operative senza PIISSO, ruolo «read-only»
Confidentialunità DWH, report senza IDSSO + MFA, gruppi approvati, registro
Restrited (PII/finanza)KYC, transazioni, segnali RG, sanzioni/RERABAC per attributi, JIT, Registro campi, WORM
Highly Restrictedchiavi, segreti, console admine, segmento PANPAM, perimetro isolato, mTLS, sessioni registrate
💡 La classe viene assegnata a RoPA/directory dati ed è associata a criteri di crittografia, retino e modalità di accesso.

3) Modello di accesso: RBAC + ABAC

RBAC (ruoli) - Matrice di base «ruolo di risoluzione →».
ABAC (attributi): regole contestuali (giurisdizione giocatore/operatore, segmento ambiente, sensibilità set, cambio/tempo, dispositivo, livello di convalida KYC, servizio/purpose).

Esempio di condizione ABAC (logica):
  • L'analista di marketing può leggere le tabelle «events _» solo per i paesi in cui si dispone di un consenso analitico solo durante la settimana 08: 00-21: 00, solo dalla rete/dispositivo MDM, senza campi PII (masking abilitato).

4) SoD - Separazione dei compiti (antifrode e compilazione)

FunzioneCosa è possibileCosa non consentita
Anti-Fraudcambiare le regole dell'antifrodeapprovare le proprie cache/limiti VIP
Paymentsconfermare le conclusionimodificare le regole antifrode
Compliance/AMLchiudere EDD/TR, lettura KYCesportazione diretta dell'intero DWH
DPO/Privacycontrollo, lettura dei registri PIImodificare i diritti prod
SRE/DevOpsamministrazione dell'infrastrutturaleggere la tabella PII aziendale
Developersaccesso a logs/uv/stageaccesso ai dati prod con PII
Support/VIPleggere il profilo del giocatore (mascherato)esportazione di PII crudo
💡 Qualsiasi azione che influisce sul denaro/PII richiede un controllo a due contorni (un principio a quattro occhi) o un'approvazione a ticket automatica.

5) JIT, break-glass и PAM

JIT (Just-in-Time) - I diritti elevati vengono assegnati per un intervallo limitato (15-120 minuti) a un'attività specifica e richiamati automaticamente.
Break-glass - Accesso di emergenza attraverso una procedura separata (MFA + seconda conferma + indicazione di purpose obbligatoria), scrittura completa della sessione e post-fattura con gelosia.
PAM - Per gli account admini - archivio password, analisi comportamentali, rotazione chiavi/segreti, proxy di sessione con registrazione.

6) Segmentazione: media, rete e logica

6. 1 Mercoledì: "Prod" stage "" devv ". I dati prod non vengono copiati in stage/uv; utilizzare insiemi sintetici o pseudonimi.

6. 2 Reti (esempio di zone):
  • Edge/WAF/CDN Area App (DWH/DB) Secret/KMS.
  • Perimetro di pagamento (PSP/Card) isolato dal comune prod; Il CUS/sanzioni è un segmento separato.
  • 6. 3 Segmentazione logica: spazio dei nomi (K8s), tenant-IDs, diagrammi di database/catalogo dati, singole chiavi di crittografia per tenant/regione.
  • 6. 4 segmentazione geo: conservazione/elaborazione secondo posizione (CE/UK/...); instradamento di guidi e chiavi per regione.

7) Accesso a venditori e partner

Meccanica: singoli tenenti/account B2B, API minimo, mTLS, allow-list IP, tempo-finestra.
Contratti: DPA/SLA (registri, conservazione, geografia, incidenti, sottoprocessori).
Off - revoca delle chiavi, conferma della cancellazione, atto di chiusura.
Gli alert per quantità anomale, il divieto di esportazioni di massa.

8) Processi (SOP)

8. 1 Richiesta/Modifica accesso

1. Richiesta IDM/ITSM con purpose e scadenza.
2. Autorizzatore SoD/giurisdizione/classe dati.
3. Approvazione da parte del proprietario del dominio + Security/Compliance (se Restrited +).
4. Rilascia JIT/Accesso continuo (set minimo).
5. Registrazione: chi/quando/cosa è stato rilasciato; Data di revisione.

8. 2 Revisione periodica (recertification)

Trimestrale: i proprietari confermano i diritti dei gruppi; rilascio automatico dei diritti inutilizzati (> 30/60 giorni).

8. 3 Esportazione dati

Solo tramite pipline/vetrine approvate, elenchi di formati bianchi (CSV/Parquet/JSON), maschera predefinita, firma/hash, registro di carico.

9) Criteri e contesto dei dispositivi

MDM/EMM: accesso a Restrited/Highly Restrited solo da dispositivi gestiti.
I segnali contestuali sono geo, rischio-scansione del dispositivo, ora del giorno, stato MFA, reputazione IP - come attributi ABAC.
Estensioni browser/acquisizione schermo - Controllo e registro, divieto per console sensibili.

10) Esempi di regole (sezioni)

10. 1 YAML (pseudo) - ABAC per l'analista di marketing

yaml policy: read_analytics_no_pii subject: role:marketing_analyst resource: dataset:events_
condition:
consent: analytics == true data_class: not in [Restricted, HighlyRestricted]
network: in [corp_vpn, office_mdm]
time: between 08:00-21:00 workdays effect: allow masking: default logging: audit_access + fields_scope

10. 2 Masking SQL (idea)

sql
SELECT user_id_hash,
CASE WHEN has_priv('pii_read') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

11) Monitoraggio, registri e alert

Audit trails: `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `BREAK_GLASS`, `PAYMENT_APPROVE`.
KRIs: disponibilità senza «purpose» = 0; tentativi di Highly Restricted fuori dalla finestra Percentuale di controlli SoD falliti scarichi anomali.
KPI:% di richieste con JIT ≥ 80%; Tempo medio di accesso di 4 ore Copertura e-certificazione al 100%.
playbook SOAR: recensione automatica in caso di minacce, ticket per indagini.

12) Conformità (scheda breve)

GDPR/UK GDPR: minimizzazione, Need-to-Know, compatibilità DSAR, controllo PII.
AML/KYC: accesso a CUS/sanzioni - Solo ruoli formati, registro delle soluzioni.
PCI DSS (se applicabile): segregazione dell'area di pagamento, divieto di conservazione PAN/CSC, chiavi/hosting separate.
ISO/ISMS: criteri di accesso formalizzati, verifiche annuali e test.

13) PACI

AttivitàCompliance/LegalDPOSecuritySRE/ITData/BIProduct/EngDomain Owners
Politica e politicaA/RCCCCCC
Modello RBAC/ABACCCA/RRRRC
IDM/JIT/PAMIIA/RRICI
E-certificazioneCCARRRR
Esporta/mascheraCARRRCC

14) Metriche di maturità

La copertura ABAC per i dataset critici è pari al 95%.
Sessione JIT/tutti gli aumenti del 90%.
Il tempo di accesso per l'offboarding è di 15 minuti.
0 incidenti «ruolo funzione» ( ).
Il 100% dei registri disponibili è disponibile e verificato (firma/hash).

15) Assegno fogli

15. 1 Prima dell'accesso

  • Definizione di purpose, scadenza e proprietario dei dati
  • Controllo SoD/giurisdizioni completato
  • Scansione/maschera minima abilitata
  • MFA/MDM/Condizioni di rete soddisfatte
  • Registro e data di revisione configurati

15. 2 Panoramica trimestrale

  • Riconciliazione di gruppi e ruoli con organigramma
  • Rilascio automatico dei diritti «appesi»
  • Controllo di esportazioni anomale e break-glass
  • Apprendimento e test-alert

16) Scenari e misure di tipo

A) Nuovo ruolo «VIP Manager»

Accesso ai profili VIP (mascherato), divieto di esportazione, JIT per la visualizzazione singola di KYC tramite ticket.

B) Controllo BI

read-only alle vetrine senza PII, temporaneo VPN + allow-list, divieto di salvataggio locale, registro di carico.

C) Accesso di emergenza del sistema prod-database

break-glass da 30 min, scrittura sessione, post-review con DPO/Compliance, CAPE in caso di violazioni.

17) Road map di implementazione

Settimane 1-2: inventario dei dati/sistemi, classi di dati, matrice RBAC di base, SoD.
Settimane 3-4: implementare ABAC (primi attributi: ambiente, geo, classe di dati), flussi IDM, JIT/break-glass, PAM.
Mese 2: segmentazione del perimetro di pagamento e KYC, chiavi separate/KMS, registri di esportazione, SOAR-alert.
Mese 3 +: e-certificazione trimestrale, estensione degli attributi (dispositivo/rischio), automazione del masking, esercizio regolare.

TL; DR

Un modello di accesso affidabile = classificazione dei dati RBAC + ABAC Ciò riduce la possibilità di fuoriuscite e abusi, accelera il controllo e mantiene la piattaforma nei limiti di GDPR/AML/PCI e standard interni.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.