Verifica di backup e ripristino nelle piattaforme iGaming

Un calendario di backup riferisce che sono state prodotte copie. Non riferisce che la piattaforma può essere ripristinata. Per un operatore, la differenza tra le due affermazioni è una prova di ripristino datata, eseguita su una destinazione che il sistema in produzione non tocca mai e con prove proprie.

L’ambito di quella prova è più ampio di un solo database. Il ripristino deve rispondere dei conti giocatore, del libro mastro del portafoglio, della cronologia di round e scommesse, della passività dei bonus, dello stato di contribuzione ai jackpot, della configurazione che determina il comportamento di ciascuno di questi elementi e delle analisi su cui l’operatore riferisce. Ognuno tollera in modo diverso la perdita di cronologia, e una sola riga «database ripristinato» non li distingue.

Distingui «esistono copie» da «la piattaforma può essere ripristinata»

La guida NIST sulla pianificazione di contingenza inquadra il lavoro come un piano da sviluppare, esercitare e mantenere, non come una configurazione di archiviazione. La SP 800-34 Rev. 1 descrive la pianificazione di contingenza come lo sviluppo di «scopo, processo e formato» di un piano di contingenza dei sistemi informativi, e l’edizione precedente della stessa guida definisce un processo in sette fasi le cui ultime due sono «pianificare test, formazione ed esercitazioni e pianificare la manutenzione». La SP 800-184, pubblicata a dicembre 2016, fornisce «orientamento tattico e strategico su pianificazione, sviluppo di playbook, test e miglioramento della pianificazione del ripristino». Consulta la guida NIST sulla pianificazione di contingenza e la guida al ripristino da eventi di cybersicurezza per il testo e l’ambito.

Entrambe sono guide generali per i sistemi informativi. Nessuna definisce un obiettivo di ripristino per una piattaforma di gioco, certifica una distribuzione o sostituisce i criteri di accettazione del titolare della licenza. Ciò che stabiliscono per un team di ingegneria è più circoscritto e comunque utile: il test fa parte del controllo, e un ripristino mai esercitato è un’ipotesi non verificata.

Definisci l’ambito del ripristino prima di eseguire la prova

«Ripristinare la piattaforma» non è un’affermazione verificabile. Una prova diventa controllabile quando ogni classe di dato ha la propria domanda di ripristino e la prova attesa:

Classe di dato	Domanda a cui risponde la prova	Prova che deve conservare
Conti giocatore e registrazioni di verifica	I record dei conti sono completi e coerenti nel punto di ripristino?	Conteggi e controlli dei campi identificativi rispetto all’origine, oltre ai campioni che una persona revisore può rileggere.
Libro mastro del portafoglio e saldi	I saldi ricostruiti coincidono con la posizione riconciliata precedente all’incidente?	La query di ricalcolo, il suo risultato e la riconciliazione con cui è stato confrontato.
Cronologia di round, scommesse e regolamenti	Gli esiti dei round e le relative scritture nel portafoglio sono presenti, collegati e senza duplicati?	Conteggi per gioco e fornitore, controlli di collegamento e verifica dei duplicati per i round riprodotti dopo il punto scelto.
Passività di bonus e promozioni	Le promozioni attive e la loro passività in essere sono rappresentate come erano?	L’elenco delle promozioni attive con la passività al punto di ripristino e l’origine di quel valore.
Stato dei jackpot e altre accumulazioni	Lo stato di contribuzione è recuperabile insieme ai record che lo giustificano?	I valori di accumulo ripristinati e la versione della regola o della configurazione che li ha prodotti.
Configurazione, chiavi e credenziali di integrazione	L’ambiente ripristinato può dialogare con i servizi da cui dipende senza che materiale di produzione vi venga trasferito?	L’identificatore versionato della configurazione e come sono state fornite le credenziali per la prova.
Analisi derivate ed estrazioni di reporting	Il reporting può essere ricostruito dalle fonti recuperate anziché da una copia parziale?	Il comando di ricostruzione, il suo output e ogni periodo che non può essere ricostruito.

Non dare per scontato che tutte le righe condividano lo stesso obiettivo di ripristino. Un libro mastro ripristinato a un punto leggermente precedente è una correzione finanziaria; un’estrazione di reporting ripristinata allo stesso punto non lo è.

Ripristina su una destinazione isolata, mai sopra il sistema in produzione

Un ripristino è una scrittura. Eseguilo in un ambiente separato e registra quale fosse lo snapshot di origine. Il ripristino a un punto nel tempo combina di norma un backup di base con un log di scrittura anticipata archiviato: la documentazione PostgreSQL sull’archiviazione continua descrive la riproduzione di un log archiviato a partire da un backup di base e chiama il punto di arresto «destinazione di ripristino», indicabile come data e ora, punto di ripristino denominato o completamento di un identificatore di transazione.

La stessa documentazione spiega perché la diramazione conta. Un ripristino a un punto nel tempo crea una nuova linea temporale, e la cronologia ripristinata non sovrascrive il log generato prima; la pagina registra che non è possibile ripristinare su una linea temporale diramatasi prima che il backup di base fosse eseguito. Conseguenza pratica per il verbale della prova: l’identità dello snapshot, la destinazione di ripristino scelta e la linea temporale risultante fanno parte delle prove, perché «abbiamo ripristinato il database» è ambiguo quando una piattaforma è già stata ripristinata più di una volta.

Il meccanismo dipende dal motore e questa pagina descrive il comportamento di un motore, non di ogni piattaforma. La regola generale è trasferibile: sappi quale artefatto definisce il punto su cui hai ripristinato e conservalo.

Verifica l’aritmetica del libro mastro, non il conteggio delle righe

Un ripristino può restituire il numero atteso di righe e saldi errati. I conteggi sopravvivono a un ripristino che un giocatore contesterebbe, perché una scrittura di compensazione mancante e una in più si annullano in un totale.

Ricalcola i saldi dalle scritture ripristinate e confronta quel risultato con la posizione riconciliata precedente all’incidente, non con il valore della colonna di saldo ripristinata; altrimenti una tabella dei saldi danneggiata viene confrontata con se stessa. Poi verifica i collegamenti che rendono utilizzabile un libro mastro: ogni round regolato ha le sue scritture nel portafoglio, non esiste alcuna scrittura per un round assente e i round accettati dopo la destinazione di ripristino non vengono contati due volte se la prova li riproduce. La guida ai requisiti di riconciliazione del portafoglio descrive i controlli di riconciliazione da cui dipendono questi confronti.

Considera il ripristino di un libro mastro a un punto nel tempo come una porta a senso unico

Recuperare un momento precedente all’incidente riavvolge anche tutto ciò che è accaduto dopo quel momento. Per un libro mastro è una decisione di business, non un’impostazione di ripristino: l’attività tra la destinazione di ripristino e l’incidente deve essere riapplicata, annullata o regolata in altro modo, e qualcuno con responsabilità deve autorizzare quale di queste opzioni.

Decidi prima della prova, non durante un incidente, chi può scegliere la destinazione di ripristino, come viene classificata l’attività bancaria, di portafoglio e di gioco successiva alla destinazione, cosa vede il giocatore nella propria cronologia delle transazioni in seguito e come viene registrata la correzione. Un operatore che non ha risposto a queste domande ha un backup, non una capacità di ripristino.

Registra la prova come evidenza datata

Un test che non lascia artefatti è indistinguibile da un test saltato. Un verbale minimo contiene l’identità del backup di origine e il suo checksum, la destinazione di ripristino, l’ambiente isolato utilizzato, la durata misurata rispetto all’obiettivo dichiarato dalla piattaforma, le query di verifica con i loro risultati, ogni eccezione con il suo responsabile, la data e la persona revisore. Conservalo dove la guida alla registrazione di sicurezza e alle evidenze di audit conserverebbe un verbale di indagine comparabile, e conserva il testo delle query invece di uno screenshot di una dashboard verde.

Enunciare le aspettative di un regolatore non equivale a soddisfarle. Come esempio della direzione in cui viaggia questa evidenza, la Gambling Commission del Regno Unito dichiara nella sua pagina dei remote gambling and software technical standards che i titolari di licenza remota e di software di gioco devono rispettare gli RTS e i «requisiti relativi ai tempi e alle procedure di test» ai sensi della condizione di licenza 2.3.1, che gli standard includono requisiti di sicurezza derivati dalla ISO/IEC 27001:2013 e che l’albero pubblicato comprende l’RTS 9 sui sistemi di jackpot progressivo, l’RTS 10 sul gioco interrotto e l’RTS 16 sull’uso di software di terze parti. Questa pagina è un rimando a quegli standard pubblicati, non un’interpretazione: se un requisito specifico si applichi a una determinata piattaforma è una questione per il titolare della licenza, il suo valutatore e il regolatore.

Fermati a ciò che il ripristino dimostra

Un ripristino completato dimostra che i dati potevano essere recuperati quel giorno, su quella destinazione e in quell’ambiente. Non dimostra che il servizio sia ripreso entro un tempo determinato, che i fornitori a valle si siano ricollegati correttamente o che la piattaforma abbia rispettato un obbligo. Sono esercitazioni distinte e vanno riferite separatamente.

Mantieni l’ambiente ripristinato disponibile abbastanza a lungo da rispondere alle domande generate dalla prova e distruggilo deliberatamente in seguito, con il verbale di ciò che conteneva. La guida al piano di risposta agli incidenti copre la fase in cui verrebbe presa una decisione di ripristino reale; la guida alla residenza dei dati e al trasferimento internazionale spiega perché l’ubicazione della destinazione di ripristino sia essa stessa una questione e non un valore predefinito.