Registrazione di sicurezza ed evidenza di audit nell'iGaming: guida ai controlli

La registrazione di sicurezza nell’iGaming risponde a una domanda precisa: quali eventi la piattaforma deve poter ricostruire mesi dopo e cosa dimostra che quella ricostruzione non è stata alterata. Una riga di log non è una pista di audit finché un investigatore non riesce a ricostruire una decisione concreta e a dimostrare che il registro è sopravvissuto ai sistemi che descrive.

Per un responsabile della sicurezza dell’operatore, un architetto di piattaforma, un responsabile della conformità o un fornitore davanti a una revisione indipendente, la decisione riguarda dove vive il registro, chi può modificarlo e per quanto resta riproducibile. L’artefatto utile è un pacchetto di controllo della registrazione: un inventario degli eventi legato ai sistemi critici, uno schema del record, regole di protezione e accesso, una fonte di tempo designata, un calendario di conservazione e dismissione, procedure di recupero e test di accettazione.

Separare la registrazione di sicurezza dalla pista di audit

Registrazione di sicurezza e pista di audit sono correlate e non sono lo stesso artefatto. Il cheat sheet sul logging di OWASP osserva che i log di monitoraggio dei processi, di audit e delle transazioni vengono di solito raccolti per scopi diversi, il che spesso significa tenerli separati: una pista di audit contiene un registro cronologico dell’attività che consente di ricostruire ed esaminare la sequenza originale di transazioni attribuibili, mentre la registrazione degli eventi di sicurezza risponde a domande di rilevamento, anti-automazione e indagine.

Entrambi servono. Differiscono per ambito degli eventi, conservazione, diritti di accesso e domanda a cui rispondono. La guida all’osservabilità RGS copre tracce, metriche e log dei round di gioco; quella telemetria è evidenza operativa, e un auditor che chiede chi ha modificato una configurazione di pagamento non accetterà una dashboard di metriche come registro.

Partire dai sistemi critici e dalle decisioni che devono spiegare

I requisiti di sicurezza degli standard tecnici sul gioco a distanza della Gran Bretagna definiscono i sistemi critici a cui si applicano i loro controlli: sistemi elettronici che registrano, conservano, elaborano, condividono, trasmettono o recuperano informazioni sensibili del cliente, come informazioni di autenticazione, dati delle carte o saldi del conto; sistemi che generano, trasmettono o elaborano numeri casuali usati per determinare i risultati; sistemi che conservano risultati o lo stato corrente della giocata di un cliente; punti di ingresso e uscita da quei sistemi; e reti di comunicazione che trasportano informazioni sensibili del cliente.

Quell’ambito è specifico di una giurisdizione e non un obbligo universale, ma è un inventario iniziale utile. Deriva l’ambito del registro dalle decisioni che potresti dover spiegare in seguito: chi si è autenticato e come, quale azione privilegiata è stata eseguita, quale versione di configurazione o policy era attiva, quale movimento di portafoglio o libro contabile è avvenuto, quale risultato di gioco o transizione di stato è stato registrato, quale esportazione di dati o azione di supporto è avvenuta e chi ha letto il repository dei registri stesso. La guida al controllo degli accessi al back office copre il lato degli accessi privilegiati di quell’inventario, e la guida alla riconciliazione del portafoglio copre l’evidenza del libro contabile.

Registrare l’evento, non tutto ciò che lo circonda

Uno schema del record deve portare i campi che un’indagine richiede davvero: un nome di evento stabile, l’attore e il suo metodo di autenticazione, la risorsa obiettivo, l’azione, l’esito, un codice di motivo, un identificatore di correlazione, la versione di policy o release in vigore, il componente di origine, un timestamp con la sua fonte di tempo e il contesto minimo che spiega la decisione.

Tieni credenziali, token di sessione, dati completi delle carte di pagamento e dati personali non necessari fuori dal registro. OWASP osserva che un attaccante con accesso in lettura a un log può usarlo per esfiltrare segreti e che le piattaforme di logging stesse possono essere attaccate attraverso ciò che vi viene scritto. La minimizzazione dei dati non è solo una questione di archiviazione: il principio di limitazione della conservazione dell’articolo 5 del GDPR si applica ai dati personali che compaiono nei registri, quindi inventario degli eventi e calendario di conservazione vanno tenuti insieme.

Proteggere il repository dei registri come un sistema a sé

I requisiti di sicurezza citati derivano dall’Allegato A della ISO/IEC 27001:2022 e il loro elenco di controlli comprende la registrazione delle attività (8.15), la sincronizzazione degli orologi (8.17), il backup delle informazioni (8.13), i diritti di accesso privilegiato (8.2) e la restrizione dell’accesso alle informazioni (8.3), insieme alla raccolta delle evidenze. Letti insieme, descrivono un repository progettato e governato come i sistemi che osserva.

In pratica questo significa che leggere e scrivere nel repository dei registri è un privilegio separato dall’amministrazione dell’applicazione; un amministratore dell’applicazione non dovrebbe poter modificare o cancellare il registro delle proprie azioni. Archiviazione in sola aggiunta o con blocco di conservazione, digest di integrità sui lotti, ruoli di interrogazione con ambito ristretto e monitoraggio della salute della pipeline di log servono a questo scopo. Gli eventi che arrivano da sistemi fuori dal tuo confine di fiducia vanno trattati come input non attendibile: OWASP avverte che i dati di un’altra zona di fiducia possono essere mancanti, modificati, falsificati o ripetuti.

Sincronizzare gli orologi prima di discutere l’ordine

La sincronizzazione degli orologi ha un controllo dedicato perché l’ordine tra componenti vale quanto le fonti di tempo che lo sostengono. Il requisito 10 di PCI DSS applica fonti di tempo accettate dal settore ai sistemi in ambito. In pratica: una policy documentata sulla fonte di tempo, allarmi monitorati sulla deriva, archiviazione in UTC con l’ora locale solo in visualizzazione, un identificatore monotonicamente crescente per gli eventi dentro un singolo componente e la fonte di tempo registrata nel record stesso. Due sistemi che discordano di qualche secondo trasformano la cronologia di un incidente in una discussione sulla cronologia.

Rispondere alla conservazione con due domande distinte

La prima domanda è per quanto tempo il registro deve essere conservato. Dipende dall’obbligo e dalla giurisdizione. PCI DSS richiede che la cronologia dei log di audit sia conservata per almeno dodici mesi, con almeno i tre mesi più recenti disponibili immediatamente per l’analisi. Le regole sulla protezione dei dati spingono nella direzione opposta per i dati personali: la guida dell’ICO sulla limitazione della conservazione ricorda che il UK GDPR non fissa termini specifici e che il titolare decide per quanto tempo i dati sono necessari alle sue finalità. Conservare tutto per sempre è una passività, non un controllo.

La seconda domanda è con quale rapidità il registro deve essere prodotto. La capacità di recupero fa parte del controllo, non è un dettaglio operativo. Le indicazioni sugli audit di sicurezza della Gran Bretagna prevedono che il rapporto completo di audit sia fornito entro sette giorni da una richiesta; un’esportazione di log che richiede tre settimane non rispetta quell’obbligo anche se i dati esistono. Scrivi nel medesimo documento il calendario di conservazione, la traccia di evidenza della dismissione, il percorso di conservazione legale per le indagini aperte e il processo di aggiornamento per nuovi obblighi.

Raccogliere evidenza per la revisione, non per la dashboard

Le stesse indicazioni sull’audit descrivono cosa deve contenere un rapporto di audit di sicurezza: l’ambito dei test, compresi i sistemi informativi esaminati; l’evidenza ottenuta con versioni e date dei documenti; le verifiche sul campo svolte; i campioni usati per verificare la conformità; i risultati per elemento di controllo e un piano di gestione per i rilievi. L’audit rispetto alla BS ISO/IEC 27001:2022 è lo standard atteso per le classi di licenza che elenca.

Quella forma di evidenza dovrebbe determinare ciò che il controllo di registrazione produce: la policy, lo schema dei record, la procedura di interrogazione ed esportazione con i suoi controlli di accesso, il calendario di conservazione e dismissione e un insieme di ricostruzioni documentate. Uno screenshot di dashboard non è un campione. La guida alla risposta agli incidenti copre il caso adiacente in cui il registro deve sostenere un’indagine in corso e non una revisione periodica.

Accettare il controllo di registrazione con una riproduzione reale

L’accettazione inizia scegliendo un evento per ciascuna categoria critica e riproducendolo dall’inizio alla fine dal repository, inclusa la versione della policy in vigore. Poi si testano le modalità di guasto: un amministratore dell’applicazione che tenta di cancellare o modificare un record, la pipeline di log che perde una fonte, una fonte di tempo che deriva, un’esportazione di un intervallo di date definito per un investigatore, la scadenza della conservazione con la sua evidenza di dismissione, gli allarmi quando la scrittura fallisce e la revisione di chi ha letto il repository dei registri.

NIST SP 800-92 inquadra la gestione dei log come un ciclo di vita — generare, trasmettere, conservare, analizzare e dismettere i dati di log — e la sua revisione in bozza descrive la pianificazione di miglioramenti a supporto di requisiti regolatori e buone pratiche raccomandate. Ogni fase richiede un responsabile, un test e un risultato registrato, e il pacchetto di accettazione deve indicare quali sistemi, release e ambienti copre davvero.

Per operatori e fornitori che preparano una revisione di sicurezza indipendente, lo sviluppo di piattaforme di Wizards può trasformare l’inventario degli eventi, le regole di conservazione e i test di accettazione delle evidenze in requisiti di piattaforma concreti.

Domande frequenti

Cosa deve definire una policy di registrazione di sicurezza nell’iGaming?

Una policy di registrazione di sicurezza deve definire i sistemi critici in ambito, gli eventi registrati per ciascuno, i campi di ogni record, la fonte di tempo, chi può leggere o scrivere nel repository, il calendario di conservazione e dismissione, la procedura di recupero e i test di accettazione che dimostrano che il registro può essere riprodotto.

Una piattaforma di osservabilità basta come evidenza di audit?

No. Le piattaforme di osservabilità sono costruite per rilevamento, prestazioni e indagine, e di solito campionano, aggregano o fanno scadere i dati. Una pista di audit richiede un registro cronologico completo di azioni attribuibili, con controlli di accesso e una conservazione che rispondano all’obbligo che deve soddisfare.

Per quanto tempo vanno conservati i log di sicurezza nell’iGaming?

La conservazione segue l’obbligo, quindi varia per giurisdizione e tipo di dato. Le regole sulle carte di pagamento richiedono comunemente dodici mesi, con i tre mesi più recenti disponibili immediatamente, mentre le regole sulla protezione dei dati richiedono che i dati personali nei log non siano conservati oltre il necessario. Il calendario deve registrare il minimo e l’evidenza di dismissione.

Perché la sincronizzazione degli orologi conta per l’evidenza dei registri?

Perché l’ordine è l’argomento. Se i componenti discordano sull’ora, un investigatore non può dimostrare quale azione ha preceduto l’altra e una contestazione o un rilievo di audit diventa difficile da rispondere. Una fonte di tempo monitorata, l’archiviazione in UTC e la fonte di tempo registrata in ogni evento mantengono la sequenza difendibile.

Quale evidenza deve fornire un controllo di registrazione a un audit indipendente?

Deve fornire la policy, lo schema di eventi e record, il modello di accesso del repository, la configurazione della fonte di tempo, i registri di conservazione e dismissione, la procedura di recupero e ricostruzioni documentate di eventi rappresentativi con le versioni di policy in vigore. Deve inoltre indicare quali sistemi e ambienti l’evidenza copre.

Si può affidare la manutenzione del registro di audit a un amministratore dell’applicazione?

Non come unico controllo. L’amministrazione dell’applicazione e l’accesso al repository dei registri devono essere privilegi separati, così che chi gestisce un sistema non possa cambiare in silenzio il registro di ciò che ha fatto. Archiviazione in sola aggiunta, verifiche di integrità e accesso registrato al repository sostengono questa separazione.