Segurança de dados e criptografia

1) Por que isso é crítico em iGaming

A plataforma iGaming funciona com PII, adereços financeiros, sessões de jogos, sinais comportamentais, sinais antifrod e modelos ML. A fuga ou troca destes dados resulta em multas, bloqueios de mercados, danos de reputação e regressão de métricas (GGR, retenção).

• Privacidade (acesso mínimo ao PII/finanças).
• Integridade (proteção contra trocas e dados «sujos»).
• Disponibilidade (SLO para leitura/gravação, planos DR).
• Rastreabilidade (quem viu/mudou e quando).

2) Modelo de ameaça (reduzido)

Externos: comprometimento de API/integração, MITM, ransomware, provedores (suply chain).
Permissões internas: permissões redundantes, descarregamentos «shadow», logs tóxicos, erros de configuração.
Dados e ML: troca de eventos/fic, inversão de modelo, membership inference.
Jurisdição: restrições, requisitos locais de armazenamento e remoção.

3) Criptografia em trânsito (In Transit)

TLS 1. 2+/1. 3 apenas, desligar os números fracos; preferência pelo TLS 1. 3.
mTLS para S2S (yadro↔dataleyk↔katalog↔fichestor↔provaydery).
O PFF (ECDHE) é obrigatório.
Certificate pinning em clientes móveis/desctop e integração crítica.
A assinatura API de solicitações aos provedores/PSP (HMAC-SHA-256) e o controle de tempo/repetição (nonce, idempotency keys).

4) Criptografia de armazenamento (At Rest)

• Criptografia de volumes/objetos na nuvem/K8s (transparente, mas não protege contra leitura «legítima» por um serviço comprometido).

• TDE (Transparent Data Encrypition) - Camada básica.
• FLE/Column-level AEAD para campos «quentes» (email, telefone, tokens PAN): AES-256-GCM ou ChaCha20-Poly1305.
• Chave row-level para gravações particularmente sensíveis (VIP, pagamentos).

• Envelope encrypition (KMS-managed DEK, rotativo), controle de acesso às chaves.
• Assinatura de manifestos e controle de integridade (hash/checksum, árvores Merkle para pacotes).

5) Eleições criptográficas (prática)

Encriptação simétrica: AES-GCM/ChaCha20-Poly1305 (AEAD) com nonce/IV exclusivos; armazenar 'ciphertext + auth tag'.
Hashing: SHA-256/512 para integridade; para senhas - Argon2id (ou bcrypt/scrypt) com configuração e sal.
Assinatura: Ed25519/ECDSA P-256 para artefatos/pacotes; HMAC-SHA-256 para assinatura API.
Acordos-chave ECDH (P-256/Curve25519).

6) Gerenciamento de chaves (KMS/HSM)

KMS + HSM para geração/armazenamento de chaves mestre; envelope encryption для DEK.
Rotação: regular (calendário) e por evento (incidente). Suporte dual-read para o período de migração.
Divisão de responsabilidades (SoD), M-of-N para «break-glass», registro de todas as operações.
Split-key/Shamir para segredos altamente críticos (por exemplo, assinatura de pey-outs).
Chaves geo-scoping - diferentes chaves para regiões/marcas.

7) Segredo-gestão

O Gestor de Segredos centralizados (não nas variáveis de ambiente do repositório).
Segredos JIT (curtas), roteiro automático e crítica.
Sidecar/CSI para levar segredos para os K8s.
Proibição de logs/trailers com segredos; detectores de fugas na CI.

8) Integridade e confiança nos dados

Assine eventos/pacotes (produtor) e verifique (consumer).
Event-idumpotência e chaves únicas para anti-replay.
Controle de circuitos (Schema Registry, compatibilidade), Data Contracts como «limites de confiança».
Armazenamento WORM para registros e relatórios críticos.

9) Toquenização, camuflagem e DLP

Tocenização PII/finanças (vault/FPE/DET) - Uso de tokens em logs, vitrines, fichas.
Camuflagem em UI e descarga; redação do PII em tíquetes/bate-papos (NLP-saneamento).
Políticas DLP: modelos proibidos (PAN, IBAN, passaporte), unidade de descarga, inspeção de correio/FTP/S3.

10) Acesso e auditoria

RBAC/ABAC: rol + atributos (país, marca, ambiente); O menor direito.
Acessos JIT com reversão automática; Uma vez por dia, tenho razão.
mTLS + IP allowlist para painéis admins e críticos end-point.
Auditorias-logs inalteradas (WORM/append-only), correlação com SIEM.
Break-glass: papéis/chaves individuais, pós-mortem obrigatório.

11) Cópia de segurança e DR

3-2-1: 3 cópias, 2 mídias diferentes/HSD, 1 offline/isolado (air-gapped).
Criptografar bacapes com suas próprias chaves (não provedor), teste de recuperação programado.
RPO/RTO para domínios (pagamentos <X min, eventos de jogos <Y min).
Replicação regional com criptoização de chaves e redes.

12) Privacidade e complacência

Classificação de dados (Public/Internal/Confidential/Restricted).
Minimização e conexão de destino (KYC, AML, RG, relatórios).
Políticas de armazenamento e remoção: gráficos, Legal Hold, DSAR; cripto-apagado.
Geossonização e mala de armazenamento local.

13) Observabilidade de segurança de dados

Zero-PII em logs (métricas de revestimento), alertas quando o DLP é acionado.
Key health: rotações, falhas de cifra, anomalias KMS/HSM.
Integrity SLI: proporção de pacotes/eventos assinados e comprovados.
Latency SLO: p95 toquenização/detonação, criptografia/descriptação.
Access SLO: proporção de pedidos de JIT processados no horário de destino.

14) Ferramentas e camadas tecnológicas (categorias)

KMS/HSM: chaves mestre, envelope, assinatura.
Segredos JIT, rotação.
Terminação TLS/mTLS-mesh: ingress/service mesh.
DLP/Masking: Inspeção, saneamento.
Schema Registry/Contracts: compatibilidade, proibições PII.
SIEM/SOAR: correlação dos logs de auditoria, reações automáticas.
Backup/DR.: Orquestração de bacapes, teste de recuperação.

15) Modelos (pronto para uso)

15. 1 Política de criptografia (fatia)

Algoritmos: AES-256-GCM/ChaCha20-Poly1305; assinatura Ed25519; hash SHA-256.
Chaves: geração no HSM; rotação de 90 dias ou em decorrência de um incidente; geo-scoped.
Acesso: apenas as salas de serviço através de mTLS; Tokens JIT.
Registros: Modo WORM; armazenamento de ≥ N meses.
Exceções: por decisão da CISCO/DPO, com a inscrição da justificativa.

15. 2 Passaporte de conjunto de dados protegidos

Domínio/tabela: payments. transactions

Classe: Restricted (finanças)

Criptografia: FLE (AES-GCM) por 'card _ tocen', 'iban', 'payer _ id'

Chaves: DEK per-field (envelope KMS)

Toquenização: vault tokens para PAN/phone/email

Acesso: ABAC (país, papel «Payments-Ops»), JIT

Registros: Assinatura de pacotes, WORM, Retainha de 2 anos

15. 3 Folha de cheque de lançamento de dados

• Contrato proíbe PII em zonas «cinzentas», campos marcados 'pii/tocenized'
• TLS 1. 3 e mTLS no S2S incluídos
• FLE/TDE configurados, chaves no KMS/HSM, rotação ativa
• Regras DLP e camuflagem de logs são testados
• Os bacapes são criptografados e o teste de recuperação foi testado
• SIEM recebe os logs de auditoria; alertas para tentar detonar fora da zona limpa

16) Mapa de trânsito de implementação

0-30 dias (MVP)

1. Classificação de dados e mapa de fluxo (PII/finanças/ML).
2. Activar TLS 1. 3/mTLS para S2S; a proibição de números fracos.
3. Levantar KMS/HSM; traduzir as chaves para o circuito envelope.
4. Incluir TDE e FLE para 3 domínios críticos (Payments/KYC/RG).
5. Camuflagem de logs e regras DLP básicas; avaliação Zero-PII.

30 a 90 dias

1. Toquenização PII/finanças (vault/FPE); JIT e auditoria de detonação.
2. Assinar eventos e cheques integrity em ingestão/ETL.
3. Rotação regular de chaves, split-key para pagamentos VIP.
4. Bacaps: 3-2-1, cópia offline, dia de restore mensal.
5. Dashboard SLO (Zero-PII, Integrity, Key-Health, Latency).

3-6 meses

1. Chaves geo-scoped/dados de jurisdição; Políticas de fronteira.
2. Armazenamento WORM para auditoria/relatórios; playbooks SOAR.
3. Revestimento completo de tokens analistas/ML; a proibição do PII nas vitrines.
4. Exercício trimestral: simulações de incidente (ransomware, key leak, data poisoning).
5. Reaproveitamento anual e auditoria externa.

17) RASI (exemplo)

Políticas e controle: CISCO/CDO (A), DPO (C), SecOps (R), Domain Owners (C).
Ключи/KMS/HSM: Security/Platform (R), CTO (A), Audit (C).
Toquenização/DLP: Data Plate (R), DPO (A), Domins (C).
Backaps/DR.: SRE (R), CIO (A).
Monitoramento/incidentes: SecOps (R), SOAR (R), Legal/PR (C).

18) Métricas e SLO de segurança de dados

Zero-PII em logs: ≥ 99. 99% dos eventos.
Integrity-pass: ≥ 99. 9% dos pacotes assinados foram testados com sucesso.
Key-hygiene: 100% rotações pontuais, 0 chaves vencidas.
Detokenization SLO: p95 ≤ X min, apenas para pedidos de justificativa.
Backup restore-rate: um teste de recuperação bem-sucedido ≥ 99%.
Access review: fechado ≥ 95% de permissões extras de auditoria trimestral.
Invident MTTR: ≤ limiar de destino para os tipos P1/P2.

19) Anti-pattern

O TDE «por um selo», sem FLE e tocando campos sensíveis.
Armazenamento de segredos em variáveis de ambiente/repositório.
Chaves compartilhadas/pepper para todos os domínios/regiões.
Logs com PII/segredos; dampas de base de prod sem criptografia.
Não há assinaturas ou verificações de integridade nas Pipinas.
Admin unificado para todos os KMS/HSM; Não há SoD nem M-of-N.

20) Incidente playbook (breve)

1. Detecção: SIEM/DLP/auditoria-logs/queixa.
2. Estabilização: isolar o segmento, rever as chaves/segredos, manter os fluxos problemáticos.
3. Avaliação: O que se arrastou/desvirtuou, a escala, a jurisdição, as vítimas.
4. Comunicações: Legal/PR/regulador (onde necessário), parceiros/jogadores.
5. Mitigações: rotações, localização retrô/criptografia, backfill/verificação de integridade.
6. Pós-mortem: razões, lições, atualização de políticas/liminares/testes.

21) Seções relacionadas

Toquenização de dados, Origem e Caminho de Dados, Ética e Privacidade, ML Confidencial, Federated Learning, Redução de preconceito, DSAR/Legal Hold, Observabilidade de Dados.

Resultado

Proteção de dados confiável é uma arquitetura em vários níveis + disciplina de processos: criptografia moderna, KMS/HSM rigoroso, tocenização, integridade assinada, logs limpos, acessibilidade controlada e bacapes verificáveis. O iGaming ganha plataformas onde os dados são protegidos por padrão e as alterações são transparentes, reproduzidas e adequadas.