Segmentazione dei privilegi

1) Perché devi segmentare

La segmentazione dei privilegi è la chiave per ridurre gli errori «blast radius» e gli abusi privilegiati. Consente di limitare con precisione chi e dove può eseguire quali azioni con quali dati, mantenendo al contempo la velocità delle operazioni e la conformità ai regolatori.

• meno incidenti dovuti ai «diritti superflui»;
• accelerazione delle indagini: la disponibilità è trasparente e spiegabile
• Conformità SoD/compilation, verifica provata;
• esperimenti sicuri e rilasci veloci senza rischi per il core prod.

2) Principi

Zero Trust: ogni azione viene verificata contestualmente; Non ci sono zone di fiducia.
Least Privilege: diritti minimi concessi per un periodo minimo (idealmente JIT).
Text over Rolle: i diritti dipendono non solo dal ruolo, ma anche dagli attributi (tenant, regione, ambiente, rischio).
Segregation of Duties (SoD) - Condividiamo l'avvio, l'approvazione, l'esecuzione e il controllo.
Policy-as-Code: regole in codice con versioning, test e gelosia.

3) Modello di maturità di accesso

1. RBAC (roles) - Avvio - ruoli fissi (Support, Risk, Payments, Trading, Ops, SRE, Compliance).
2. ABAC (attributi) - Aggiungi gli attributi: tenente, regione, giurisdizione, prodotto, canale, ambiente (prod/stage/dave), tempo, classe di rischio dell'operazione, segnali KRI.
3. PBAC (policy-based): criteri centralizzati «chi/cosa/quando/perché» + condizioni (ad esempio, «in vendita solo per JIT e con ticket»).

4) Domini di segmentazione (asse dopo asse)

4. 1 Tenente/client

L'accesso e le operazioni sono limitati a un particolare marchio/operatore/affiliato.
Le attività cross-tenanti non sono consentite tranne le aggregazioni rigorosamente definite senza PII.

4. 2 Regione/giurisdizione

Le policy tengono conto delle licenze locali e delle regole KYC/AML.
Le operazioni con i dati del giocatore sono limitate dalla geografia di archiviazione e elaborazione.

4. 3 Ambiente (uv/stage/prod)

Prod è isolato: credenze separate, reti, Basion/PAM, «read-only predefinito».
Accesso al prod solo JIT, con ticket e finestre di modifica.

4. Classe di dati 4

PII/finanza/telemetria di gioco/tecnologia - diversi livelli di accesso e occultamento.
Esporta PII solo tramite workflow autorizzati con crittografia e TTL.

4. 5 Criticità delle operazioni

Le classi P1/P2/P3 - Pubblicazione di coefficienti, calcoli manuali, conclusioni, cambio di routing PSP - richiedono un controllo dual.
Le operazioni a basso rischio possono essere avviate da una politica.

5) Livelli di privilegio (tiers)

Viewer: sola lettura di aggregati e dati mascherati.
Operator: esecuzione delle procedure di runbook senza modificare le configurazioni.
Contributor - Modifica delle configurazioni in domini non critici.
Approver: approvazione delle richieste e delle operazioni high-risk (non compatibile con l'esecuzione - SoD).
Ammin (JIT) - Aumento a breve termine per attività rare sotto controllo dual e scrittura sessione.

6) ruoli SoD e incompatibili

• Avviare le conclusioni, approvare il risultato finale.
• Creare una campagna di bonifica, attivare in vendita, cambiare i limiti.
• Progettare un FIC per il lancio.
• Richiedi caricamento PII ≠ approva ≠ decodifica.

Per ciascuna coppia è formalizzata una politica di divieto ed esclusione con data di revisione.

7) Accesso JIT e PAM

Elevation su richiesta: indicazione obiettivo/ticket/scadenza; dopo la scadenza - recensione automatica.
Dual Control: P1/P2 azioni - due appruzzi con funzioni diverse.
Sessione control - Scrittura di sessioni critiche, alert di anomalie, disattivazione di copipasti in fase PII.
Break-glass: accesso di emergenza con limiti rigidi e post-revisione obbligatoria.

8) Account di assistenza e API

Scorciatoie minime; Suddivisi per attività/microservizi token/certificati a breve vita.
Rotazione dei segreti, proibizione dei segreti shared; Divieto «god-scope».
Limiti su rate/quote, chiavi idempotency, firma webhook (HMAC).

9) Segmentazione a livello di infrastruttura

Reti: isolamento dei segmenti (per-domain/per-tenant), restrizione dell'egress di default, mTLS.
Kubernets/Cloud: Neimspace/progetti per-ambiente e dominio, Gatekeeper/OPA per il divieto di modelli pericolosi.
BD/Cache - Broker di accesso (DB proxy/IAM), read-only di default, disabilitazione del DDL fuori dalla finestra.
Archivi: diverse chiavi/booket per-classe dati con regole TTL e WORM per il controllo.

10) Criteri come codice (PaC)

Criteri nei repository (Rego/YAML), Riva PR, Test automatici (unit/e2e), Controllo diff.
Il contesto dinamico è l'ora del giorno, la posizione, il livello KRI, il rischio-scansione dell'operazione.
La spiegazione della soluzione allow/deny e il riferimento al criterio nel controllo.

11) Registri e verifiche

Completezza: chi/cosa/quando/perché, prima/post-valore, ID del ticchetto.
Idoneità: raccolta centralizzata, WORM/immutabile, firma record.
Connettività: la catena della console admine dell'API del database i provider esterni.
Controllo SLA: velocità di risposta alle richieste di controllo/controllo.

12) Dashboard e metriche (KPI/KRI)

Accessi KPI: quota di diritti fissi JIT vs, durata media del privilegio,% di SoD coperti, tempo di elaborazione delle richieste, copertura delle ricevute.
KRI abuso: picchi di operazioni sensibili, scarichi di massa, localizzazioni/orologi non comuni, sequenze «zayavka→deystviye→otkat».
Exec-dashboard - Traccia dello stato dei ruoli ad alto rischio, break-glass eventi, trend.

13) Esempi di criteri (sketch)

Prod-операции: `allow if role in {Operator, Admin} AND env=prod AND jit=true AND ticket!=null AND sod_ok AND time in ChangeWindow`.
Экспорт PII: `allow if data_class=PII AND purpose in ApprovedPurposes AND ttl<=7d AND encryption=ON AND approvers>=2`.
PSP-роутинг: `allow if action=UpdateRouting AND dual_control AND risk_assessment_passed AND rollback_plan_attached`.

14) Road map di implementazione (8-12 settimane)

Ned. 1-2: inventario di operazioni/ruoli/dati, matrice di dati, classificazione dei dati e domini di segmentazione.
Ned. 3-4: RBAC-base, catalogo dei ruoli, JIT per le console prod, lancio del PaC (OPA/Gatekeeper).
Ned. 5-6: ABAC: attributi tenant/regione/ambiente/classe di dati; Separare Neimspace/Progetti.
Ned. 7-8: PAM (JIT-elevation, scrittura sessioni, break-glass), divieto DDL e broker di database, regole di esportazione PII.
Ned. 9-10: PBAC per operazioni ad alto rischio (conclusioni, bonus, PSP), dual control, KRI-alert.
Ned. 11-12: ricezione trimestrale, copertura 100% high-risk delle attività di PaC, reporting e formazione.

15) Manufatti

Rolle Catalog ruoli, privilegi minimi, proprietari.
SoD Matrix: ruoli/operazioni incompatibili, eccezioni, processo override.
Policy Pack - Set di regole PaC con test e esempi deny/allow.
Access Sollest Form: obiettivo, scadenza, oggetto (tenante/regione/ambiente), rischio-valutazione, approvazioni.
Sensitive Ops Registrer: elenco delle azioni P1/P2, delle finestre, dei criteri dual control.
Controllo Playbook - Raccolta e distribuzione di registri, risposta SLA, ruoli.

16) Antipattern

Diritti fissi e cartelle generali.
Accessibilità cross-tenante'per comodità '.
Nessun isolamento prod/stage/dave.
Regole su carta senza enforce nel codice/console.
Esporta PII con convenzioni manuali senza crittografia o TTL.
Nessuna ricezione e diritti «dipendenti».

17) Totale

La segmentazione dei privilegi non è solo «ruoli corretti». Si tratta di isolamento multidimensionale (tenante, regione, ambiente, dati, criticità) + contesto dinamico (ABAC/PBAC) + processi (SoD, JIT, ricezione) + coercizione tecnica (PaC, PAM, reti/database). Questo tracciato riduce drasticamente il rischio di errori e abusi, accelera i cambiamenti sicuri e rende la piattaforma resistente alle esigenze di scala e regolatori.