GH GambleHub

Registros de auditoria e vestígios de acesso

1) Destino e área de aplicação

O objetivo é garantir a comprovação da ação dos usuários/serviços, transparência nas investigações, conformidade com os reguladores e padrões internos (GDPR/AML, contratos com os provedores PSP/KYC, ISO/PCI quando aplicáveis).
Abrangência: todos os sistemas de prod, serviços de plataforma (conta, pagamentos, antifrode, CUS/sanções, RG), painéis de admin, passarelas API, DWH/BI, infraestrutura (K8s/nuvem), integração com vendedores.


2) O que logar (classes de evento)

1. Identificação e acesso: login/logout, MFA, mudança de senhas/chaves, SSO, «break-glass».
2. Ações administrativas: alterações de papéis/permissões, configurações, regras de antifrode/sanções, bandeiras de fich.
3. Operações PII/finded: leitura/exportação/remoção, descarga, acesso a KYC, visualização de perfis VIP.
4. Transações e dinheiro: dinheiro em dinheiro/depósito, cancelamentos, reembolsos, soluções de charjbeek.
5. Complaens/AML/KYC: Resultados de screening (sanções/PEP/Adverse Media), soluções (TP/FP), EDD/TR/SAR.
6. Incidentes e segurança: escalações, mudanças nas regras WAF/IDS, isolamento de serviços, rotação de segredos.
7. Integrações/vendedores: chamadas de API, erros, temporizações, exportações, confirmação de remoção/retorno de dados.

💡 Princípio: registramos quem/o/o/quando/o/o/porquê/o resultado para qualquer operação que afete a segurança, o dinheiro, os dados e a complacência.

3) Campos de evento obrigatórios (mínimo)

`event_id` (UUID), `ts_utc`, `ts_local`, `source_service`, `trace_id`/`span_id`

'ator _ tipo' (user/service/vendor), 'ator _ id', 'ator _ org' (se B2B)

`subject_type` (account/tx/document/dataset), `subject_id`

`action` (e. g., `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `WITHDRAWAL_APPROVE`)

`result` (success/deny/error) и `reason`/`error_code`

'ip', 'device _ fingerprint', 'geo' (país/região), 'auth _ context' (MFA/SSO)

'fields _ accessed '/' scope' (ao usar PII/finds) - com disfarce

'purpose '/' jet _ id' (base: DSAR, incidente, pedido do regulador, tarefa operacional)


4) Imutabilidade e provabilidade

Armazenamento WORM para cópia «dourada» (imutable buckets/retence policies).
Criptopoder/cadeia de hash: assinatura periódica de pacotes de eventos e/ou construção de uma cadeia de hash (hash chaining) para identificar modificações.
Registro de alterações de padrão/regra: versionando esquemas e políticas de loging; qualquer edição passa por FAB.
Armazenamento em dois contornos: índice em linha (pesquisa) + arquivo/imutabilidade.


5) Sincronizar tempo e traçar

NTP/Crony unificado em todos os ambientes; nos logs, 'ts _ utc' como fonte da verdade.
Cada loga é 'trace _ id '/' span _ id' para rastrear as solicitações de forma completa (correlação entre serviços, vendedores e frente).


6) Privacidade e segredos

Proibido: senhas, tokens completos com PAN/CSC, números completos de documentos, biometria crua.
Camuflagem padrão: e-mail/telefone/IBAN/PAN → tokens/exibição parcial.
Pseudônimo: 'user _ id' é um token estável no analista; a referência a um ID real é apenas em um caminho protegido.
Compatibilidade DSAR: possibilidade de extração seletiva de logs por sujeito sem divulgação de PII estranho.


7) Prazo de armazenamento e níveis (retensas)

Sala de aulaHotWarmColdWORM/Legal Hold
Acesso a ação PII/Admin30 dígitos6-12 mes24-36 mesaté 5 anos/sob demanda
Transações/transações90 dígitos12 mes36 mes5-10 anos (AML/contratos)
CUS/sanções/soluções RER30 dígitos12 mes36 mes5-10 anos
Incidentes/segurança30 dígitos6-12 mes24 mesaté que as investigações sejam concluídas
💡 Prazos específicos são aprovados pelo Legal/Compliance, considerando jurisdições, licenças e contratos (PSP/KYC/Nuvem).

8) Acesso e controle (RBAC/ABAC)

Os papéis de leitura dos logs de auditoria estão separados dos papéis de administração.
Acesso MFA e Just-in-Time (break-glass) automático/logado.
Política de «mínimo»: acesso aos campos PII/findados somente por necessidade e com fixação 'purpose'.
Exportação/descarga: listas brancas de destinatários e formatos; assinatura obrigatória/hash, registro de descarga.


9) Integração com SIEM/SOAR/ETL

O fluxo de eventos de auditoria é enviado ao SIEM para correlações (e. g., em massa 'READ _ PII' + entrada do novo dispositivo).
Playbooks SOAR: tíquetes automáticos em caso de violação de políticas (sem 'purpose', volume anormal, acesso fora da janela).
ETL/DWH: Vitrines de 'auditoria _ acesso', 'pii _ exports', 'admin _ changes', com controle de qualidade e versões dos circuitos.


10) Qualidade dos dados e validadores

Esquemas como código (JSON/Protobuf/Avro): campos obrigatórios, tipos, dicionários; Validadores CI.
Desviação e fila quarantine para eventos com erros de padrão; as métricas do casamento.
Deduplicação/idempotação por '(event _ id, trace _ id, ts)'; Controle de novo envio.


11) RACI

TarefaCompliance/LegalDPOSecuritySRE/DataProduct/Eng
Política e RetensasA/RCCCI
Controle de camuflagem/PIICA/RRRC
Imutabilidade/assinaturasICA/RRC
Acesso/exportaçãoCCA/RRI
Esquemas/validadoresICCA/RR
Incidentes e investigaçõesCARRC
Vendedores/contratosA/RCCCI

12) SOP: Investigação de acesso a dados

1. Trigger: alert SIEM (anormal 'READ _ PII '/exportação), queixa, sinal do vendedor.
2. Coleta de artefatos: carregamento de eventos por 'ator _ id '/' subject _ id '/' trace _ id', registro 'purpose', logs associados (WAF/IdP).
3. Verificar a legalidade: base (DSAR/incidente/serviço), concordância, janelas de acesso.
4. Avaliação de impacto: quantidade/categoria PII, jurisdição, risco para as entidades.
5. Solução: incidente de bridge (em High/Critical), containment (rever acessibilidade, rotação de chaves).
6. Relatório e CAPA: razões, políticas violadas, medidas (camuflagem, treinamento, alterações RBAC), prazos.


13) SOP: Exportação de dados (regulador/parceiro/DSAR)

1. A solicitação → verificação de base e identidade (para DSAR) → a formação do pedido no DWH.
2. Descontrolação/minimização padrão; a inclusão do PII somente com base legal.
3. Geração de descarga (CSV/JSON/Parquet) → assinatura/hash → registro de descarga (quem/quando/quê/a/base).
4. Transmissão através do canal aprovado (sFTP/Secure link); O prazo de armazenamento da cópia é por política.
5. Pós-controle: confirmação de recebimento, remoção de arquivos temporários.


14) Métricas e KRIs/KPIs

Coverage: O percentual de sistemas críticos que enviam eventos de auditoria ≥ 95%.
Erros DQ, eventos rejeitados pelo validador, ≤ 0. 5% do fluxo.
MTTD perda de fluxo: ≤ 15 min (alert em silêncio).
Acessíveis anormais sem 'purpose': = 0 (KRI).
Hora da resposta à investigação, mediana de 4 h, P95 24 h.
Exportação assinada/assinada: 100%.
Cumprimento de retino: Remoções/arquivos dentro do prazo de ≥ de 99%.


15) Requisitos para vendedores e subprocessadores

DPA/SLA: descrição dos logs de auditoria (esquemas, prazos, geografia, formato de exportação), WORM/imutability, SLA notificações de incidentes.
Acesso ao vendedor: contas de serviço nomeadas, registros de suas ações, auditoria seletiva.
Offboarding: Rever chaves, exportar/remover registros, fechar, confirmar a destruição de bacapes.


16) Segurança e proteção contra manipulação

Separação de papéis: admin de origem ≠ admin de armazenamento ≠ auditor.
Assinatura de agentes/coletores mTLS entre os componentes.
Os anti-Tamper controlaram: comparações de haste, verificações regulares de integridade, alertas de divergência.
Geo-replicação de cópias WORM e testes regulares de recuperação.


17) Erros típicos e anti-pattern

Logação de valores sensíveis (PAN/segredos) → ativação imediata da redação-middleware.
Falta de 'purpose '/' jet _ id' ao acessar o PII.
Carregamento local para o desktop e envio por e-mail.
A falta de um único padrão e validação → campos «mudos», impossibilidade de correlação.
Uma única super conta sem ligação com uma pessoa ou serviço.


18) Folhas de cheque

18. 1 Iniciar/rever políticas

  • Esquemas e dicionários aprovados; campos obrigatórios incluídos
  • Camuflagem ativada e proibição de segredos
  • Configurado NTP, 'trace _ id' em todo o lado
  • Camadas Hot/Warm/Cold/WORM são criadas
  • RBAC/ABAC e break-glass são decorados
  • SIEM/SOAR integrados, alertas testados

18. 2 Auditoria Mensal

  • Amostra de exportação: assinaturas/registros corretos
  • Verificação de retenha/remoções/Legal Hold
  • Métricas DQ normais, quarantine análise
  • Logs de venda disponíveis/completos

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

Semanas 1-2: inventário de sistemas, alinhamento de esquemas e campos obrigatórios, configuração de tempo e rastreamento.
Semanas 3-4: inclusão de camadas de camada, integração com SIEM/SOAR, lançamento de registros de exportação.
Mês 2: automação de validadores/alertas, playbooks de investigação, treinamento de equipes.
Mês 3 +: auditorias regulares, testes de estresse de integridade, otimização de custos (tiering), revisão de vendedores/contratos.


TL; DR

Registros de auditoria fortes = eventos completos e estruturados + imutability (WORM) e assinaturas + camuflagem PII + acesso rígido e registro de download + integração com SIEM/SOAR. Isso acelera as investigações, reduz os riscos e torna a complacência provável.

Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.