Verificação de backup e restauração em plataformas de iGaming

Um calendário de backups informa que foram geradas cópias. Não informa que a plataforma pode ser recuperada. Para um operador, a diferença entre essas duas afirmações é um exercício de restauração datado, executado contra um destino que o sistema em produção nunca toca e com evidências próprias.

O escopo desse exercício é mais amplo do que um único banco de dados. A recuperação precisa responder pelas contas de jogador, pelo livro-razão da carteira, pelo histórico de rodadas e apostas, pelo passivo de bônus, pelo estado de contribuição de jackpot, pela configuração que determina como cada um desses elementos se comporta e pelas análises a partir das quais o operador reporta. Cada um tolera de forma diferente a perda de histórico, e uma única linha de “banco de dados restaurado” não os distingue.

Separe “existem cópias” de “a plataforma pode ser restaurada”

A orientação do NIST sobre planejamento de contingência enquadra o trabalho como um plano que precisa ser desenvolvido, exercitado e mantido, e não como uma configuração de armazenamento. A SP 800-34 Rev. 1 descreve o planejamento de contingência como o desenvolvimento do “propósito, processo e formato” de um plano de contingência de sistemas de informação, e a edição anterior do mesmo guia define um processo de sete etapas cujas duas últimas são “planejar testes, treinamento e exercícios, e planejar a manutenção”. A SP 800-184, publicada em dezembro de 2016, oferece “orientação tática e estratégica sobre o planejamento, a elaboração de playbooks, os testes e a melhoria do planejamento de recuperação”. Consulte o guia de planejamento de contingência do NIST e o guia de recuperação de eventos de cibersegurança para conhecer o texto e o escopo.

Ambos são guias gerais de sistemas de informação. Nenhum define um objetivo de recuperação para uma plataforma de jogo, certifica uma implantação ou substitui os critérios de aceitação do detentor da licença. O que eles estabelecem para uma equipe de engenharia é mais delimitado e ainda assim útil: o teste faz parte do controle, e uma restauração nunca exercitada é uma suposição não verificada.

Defina o escopo da recuperação antes de executar o exercício

“Restaurar a plataforma” não é uma afirmação testável. Um exercício torna-se verificável quando cada classe de dado tem sua própria pergunta de recuperação e a evidência esperada dela:

Classe de dado	Pergunta que o exercício responde	Evidência que ele deve manter
Contas de jogador e registros de verificação	Os registros de conta estão completos e coerentes no ponto de recuperação?	Contagens e verificações de campos de identidade contra a origem, além das amostras que uma pessoa revisora possa reler.
Livro-razão da carteira e saldos	Os saldos reconstruídos são iguais à posição conciliada anterior ao incidente?	A consulta de recálculo, seu resultado e a conciliação com a qual foi comparada.
Histórico de rodadas, apostas e liquidações	Os resultados de rodada e seus lançamentos na carteira estão presentes, vinculados e sem duplicidade?	Contagens por jogo e provedor, verificações de vínculo e a checagem de duplicidade das rodadas reprocessadas após o ponto escolhido.
Passivo de bônus e promoções	As promoções ativas e seu passivo em aberto estão representados como estavam?	A lista de promoções ativas com seu passivo no ponto de recuperação e a origem desse valor.
Estado de jackpot e outras acumulações	O estado de contribuição é recuperável junto com os registros que o justificam?	Os valores de acumulação restaurados e a versão da regra ou da configuração que os produziu.
Configuração, chaves e credenciais de integração	O ambiente restaurado consegue conversar com os serviços dos quais depende sem que material de produção seja levado para dentro dele?	O identificador versionado de configuração e como as credenciais foram fornecidas para o exercício.
Análises derivadas e extrações de relatórios	Os relatórios podem ser reconstruídos a partir das fontes recuperadas, e não de uma cópia parcial?	O comando de reconstrução, sua saída e qualquer período que não possa ser reconstruído.

Não presuma que todas as linhas compartilham o mesmo objetivo de recuperação. Um livro-razão restaurado para um ponto ligeiramente anterior é uma correção financeira; uma extração de relatórios restaurada para o mesmo ponto não é.

Restaure em um destino isolado, nunca sobre o sistema em produção

Uma restauração é uma escrita. Execute-a em um ambiente separado e registre qual era o snapshot de origem. A recuperação em um ponto no tempo normalmente combina um backup base com um log de escrita antecipada arquivado: a documentação de arquivamento contínuo do PostgreSQL descreve a reprodução de um log arquivado a partir de um backup base e chama o ponto de parada de “destino de recuperação”, que pode ser indicado como data e hora, ponto de restauração nomeado ou conclusão de um identificador de transação.

Essa documentação também explica por que a ramificação importa. Uma recuperação em um ponto no tempo cria uma nova linha do tempo, e o histórico recuperado não sobrescreve o log gerado antes; a mesma página registra que não é possível recuperar para uma linha do tempo que se ramificou antes de o backup base ter sido feito. Consequência prática para o registro do exercício: a identidade do snapshot, o destino de recuperação escolhido e a linha do tempo resultante fazem parte da evidência, porque “restauramos o banco de dados” é ambíguo quando uma plataforma já foi recuperada mais de uma vez.

O mecanismo depende do motor e esta página descreve o comportamento de um motor, não o de todas as plataformas. A regra geral é transportável: saiba qual artefato define o ponto para o qual você restaurou e mantenha-o.

Verifique a aritmética do livro-razão, não a contagem de linhas

Uma restauração pode devolver o número esperado de linhas e saldos errados. Contagens sobrevivem a uma restauração que um jogador contestaria, porque um lançamento compensatório ausente e outro adicional se anulam em um total.

Recalcule os saldos a partir dos lançamentos restaurados e compare esse resultado com a posição conciliada anterior ao incidente, não com o valor da coluna de saldo restaurada; caso contrário, uma tabela de saldos corrompida é comparada consigo mesma. Em seguida, verifique as junções que tornam um livro-razão utilizável: toda rodada liquidada tem seus lançamentos na carteira, não existe lançamento de uma rodada ausente, e as rodadas aceitas após o destino de recuperação não são contadas duas vezes se o exercício as reprocessar. O guia de requisitos de conciliação da carteira descreve os controles de conciliação dos quais essas comparações dependem.

Trate a restauração de um livro-razão em um ponto no tempo como uma porta de mão única

Recuperar um momento anterior ao incidente também rebobina tudo o que aconteceu depois desse momento. Para um livro-razão, isso é uma decisão de negócio, não um ajuste de restauração: a atividade entre o destino de recuperação e o incidente precisa ser reaplicada, anulada ou liquidada de outra forma, e alguém com responsabilidade precisa autorizar qual dessas opções.

Decida antes do exercício, e não durante um incidente, quem pode escolher o destino de recuperação, como a atividade bancária, de carteira e de jogo posterior ao destino é classificada, o que o jogador vê em seu histórico de transações depois, e como a correção é registrada. Um operador que não respondeu a essas perguntas tem um backup, não uma capacidade de recuperação.

Registre o exercício como evidência datada

Um teste que não deixa artefato é indistinguível de um teste omitido. Um registro mínimo contém a identidade do backup de origem e sua soma de verificação, o destino de recuperação, o ambiente isolado utilizado, a duração medida contra o objetivo que a plataforma declara, as consultas de verificação com seus resultados, cada exceção com seu responsável, a data e a pessoa revisora. Guarde-o onde o guia de registro de segurança e evidência de auditoria guardaria um registro de investigação comparável, e guarde o texto das consultas em vez de uma captura de tela de um painel verde.

Enunciar as expectativas de um regulador não é o mesmo que cumpri-las. Como exemplo da direção em que essa evidência viaja, a Comissão de Jogos do Reino Unido afirma em sua página de padrões técnicos de jogo remoto e software que detentores de licença remota e de software de jogo devem cumprir os RTS e os “requisitos relativos ao momento e aos procedimentos de teste” conforme a condição de licença 2.3.1, que os padrões incluem requisitos de segurança provenientes da ISO/IEC 27001:2013 e que a árvore publicada inclui o RTS 9 sobre sistemas de jackpot progressivo, o RTS 10 sobre jogo interrompido e o RTS 16 sobre uso de software de terceiros. Esta página é um ponteiro para esses padrões publicados, não uma interpretação deles: se um requisito específico se aplica a uma determinada plataforma é uma questão para o detentor da licença, seu avaliador e o regulador.

Pare no que a restauração comprova

Uma restauração concluída comprova que os dados podiam ser recuperados naquele dia, para aquele destino e naquele ambiente. Não comprova que o serviço foi retomado em um prazo específico, que os provedores posteriores se reconectaram corretamente nem que a plataforma cumpriu qualquer obrigação. Esses são exercícios separados e devem ser reportados separadamente.

Mantenha o ambiente restaurado disponível por tempo suficiente para responder às perguntas que o exercício criou, e destrua-o deliberadamente depois, com o registro do que ele continha. O guia do plano de resposta a incidentes cobre a fase em que uma decisão de recuperação real seria tomada; o guia de residência de dados e transferência internacional cobre por que a localização do destino de restauração é, ela própria, uma questão, e não um padrão.