Registros de auditoria de operações
(Seção Operações e Gerenciamento)
1) Atribuição e princípios
O registo de auditoria é a fonte primária da verdade sobre quem, onde, quando e porquê fez, com a possibilidade de provar a permanência e autenticidade dos registros.
Princípios:- Abrangem a ação de pessoas, serviços e parceiros externos.
- Invariável: as gravações não podem ser reescritas ou removidas sem um traço aparente.
- Atribuição: a ação está associada ao sujeito, ao papel, ao contexto, aos artefatos.
- Reprodução: o evento pode ser reproduzido no relatório/discussão.
- Minimização do PII: apenas o necessário, com máscara e tokens.
2) Áreas de revestimento
Acções personalizadas: entrada/SSO/MFA, alteração de papéis/limites, operações PII.
Operações privilegiadas: JIT/PAM, break-glass, admin-console.
Finanças: Listras/impostos/FX publicações, pagamentos/pagamentos, escrow, cancelamentos/reembolsos.
Configurações/lançamentos: ficheflags, migração de circuitos, deplall/reversão, chaves/certificados.
Integrações: webhooks, assinaturas, recibos, chaves idempotency.
Dados: leitura/exportação de PII, criação/remoção de artefatos, alterações de políticas.
3) Arquitetura e imutabilidade
Gateway Ingest com autenticação, quotas e validação de esquema.
Armazenamento WORM (imutable buckets/append-only): versão, Retence Lock, Legal Hold.
Criptocvitações: os eventos críticos formam 'receipt _ hash' e uma assinatura DSSE.
Correntes Merkle: Recorte é construído periodicamente (checkpoint) e hash de raiz é publicado.
Chain of custody: rastreamento da movimentação dos artefatos (quem acessou, quando, com que base).
Time Sync: NTP/PTP, rótulos de 'event _ time' e 'ingest _ time', ajuste de 'skew'.
4) Esquema de evento (árbitro)
audit_event {
id, event_time, ingest_time, producer, subject {
id, type: human service partner, roles[], mfa?, device_posture?
},
action: CREATE READ UPDATE DELETE EXECUTE PUBLISH APPROVE ROLLBACK,
target { type, id, version?, region?, tenant? },
context { ip/asn, user_agent, env, trace_id, request_id },
policy_version, sod_check: pass fail, justification?, ticket_ref?,
result: success deny error, error_code?,
diff_hash?, payload_hash?, receipt_hash?, dsee_signature?,
pii_classification: none aggregated tokenized sensitive,
retention_class, labels[]
}
Adicional: para finanças - 'fx _ versão/tax _ rule _ versão/pricelist _ versão'; para os webhooks - 'webhook _ id', 'idempotency _ key'.
5) Modelo de dados e áreas
Hot (operação): 7-30 dias, consultas rápidas/dashboards.
Warm (OLAP): 6-24 m, analista/busca.
Cold (arquivo/WORM): até 7-10 anos (regulação).
As classes de retenção são 'operational', 'financial', 'security', 'legal _ hold'.
Versionização de políticas: todos os eventos são marcados com «policy _ version»; editar a política é um evento de auditoria separado.
6) Acessibilidade e privacidade
RBAC/ABAC/ReBAC: visibilidade por papel/tenante/região/caso (case).
Camuflagem PII: Torneamento de ID, saída primária - somente através de jobs aprovados.
Apenas 'tombstone' + Legal Hold proíbe a remoção direta; «Doçuras» expostas com uma revista separada.
A auditoria da auditoria, quem viu/descarregou os logs, também é logada.
7) Qualidade, consistência, duplicações
Data contracts: esquema rígido e validações lambda na entrada.
Idempotency & dedup: '(event _ id, producer)'; «seen-cache» + KV.
Correção de tempo: marcas de água (watermarks) para eventos tardios.
Controle de totalidade: comparação entre os contadores de origem e as métricas de ingest.
8) Dashboards e consultas
Operacionais: ação privilegiada, violações SoD, levantamentos de direitos JIT, acesso a PII.
Financeiras: publicações de FX/Tax/PriceList, divergências de quote↔checkout, assinaturas-chave.
Integrações: recibos de webhooks, ligas, retais, duplas.
Lançamentos/configs: quem/quando/o que ativou/reverteu, a ligação com os incidentes.
Cenários de busca: 'trace _ id', 'subject'. id`, `target. id, hora/região/tenante, 'policy _ version'.
Exportar: Carregamentos de lote sob pedido com recibo (manifesto assinado).
9) API e webhooks
'POST/auditoria/ingest' - Recepção de eventos (autenticação, limites, esquema).
'GET/auditoria/search' - filtros, paginação, limite por resultado.
'GET/auditoria/trace/< trace _ id a.' é uma ligação de eventos na cadeia.
'POST/auditoria/receipt/verify' - verificação do recibo/DSSE.
Вебхуки: `SoDViolation`, `PrivilegedSession`, `PIIAccess`, `PolicyChanged`, `FinancialArtifactPublished`.
10) SLO/métricas de qualidade de auditoria
Ingest Availability: ≥ 99. 95%.
Freshness (operacional): liga ≤ 30 com p95.
Completeness: ≥ 99. 5% das fontes enviaram os dados para a janela.
Cortness: variação de valor de referência ≤ 0. 1%.
Tamper-evidence: 100% dos períodos são assegurados com raízes/assinaturas Merkle.
PII Hygiene: 100% dos eventos com classe sensível com máscara/token.
11) Playbooks e incidentes
Suspeita de substituição de registros: verificação imediata das raízes Merkle, verificação de recibos DSSE, isolamento de acesso, Legal Hold.
Vazamento de PII: pesquisa de eventos/exportações afetados, auditoria de acesso, notificações do DPO/regulador de prazos.
Violação de SoD, operação, remoção temporária, investigação e ajuste de políticas.
Falha ingest: tampão, modo de degradação, réplicas após recuperação, controle de duplicação.
12) Suprimento legal e complacência
Retenção por jurisdição: finanças/impostos - 5 a 10 anos; Segurança - Política; os dados pessoais são o mínimo de tempo necessário.
Legal Hold: congelamento da remoção no caso/pedido do regulador.
Artefactos relatórios: índice de períodos, hashs de raiz, lista de assinantes, inventário de fontes.
Indefectível: criptopodescrição, timestamping independente (TSA interno).
13) Especificidades do iGaming/fintech
Pagamentos/pagamentos: rastreamento completo de autorizações, clearing, recusos, chargeback; comparação com recibos bancários.
RTP/limites: publicações de perfis, alterações observadas pela RTP e soluções de limites com assinaturas e versões.
Afiliados: recepção de webhooks, conversões de dedução, objeções/escrow - apenas através de artefatos assinados.
Listras de Price/impostos/FX: versão do artefato em cada encomenda; Os desvios são com recibos.
14) RACI
15) Riscos e anti-pattern
Logs editáveis sem vestígios → suprimento legal.
A falta de sincronização do tempo → as timelines incompletas.
Shadow-export sem recibos → fugas/disputas.
Segredos nos logs → comprometimento.
Não há ligação com o SLO/incidentes de «cemitério de dados» sem utilidade.
16) Folha de cheque de implementação
- Definir áreas de revestimento e policy _ version.
- Expandir ingest com autenticação, esquemas e quotas.
- Incluir WORM, Corte de Merkle, assinaturas DSSE, TSA.
- Personalizar reticências por classe e Legal Hold.
- Digitar RBAC/ABAC/ReBAC e auditoria de acesso aos registros.
- Construir dashboards: privilégios, PII, finanças, lançamentos/configs.
- Incluir playbooks: tamper, fuga PII, falha ingest, violação SoD.
- Experimente réplicas e dedups no conjunto de testes.
- Exportar com recibos e registro de solicitação.
- Auditar as métricas de qualidade trimestralmente (freshness/completeness/tamper).
17) FAQ
É possível guardar tudo em um banco de dados normal?
Sim, mas as revistas críticas devem ser duplicadas no WORM/append-only, com assinaturas e no Merkle.
Você precisa logar cada leitura de dados?
Leitura do PII/finanças - obrigatório; O resto é por política e custo.
Como provar a imutabilidade?
Hashs de raiz, assinaturas DSSE, TSA independente e procedimentos de verificação reproduzidos.
O que fazer com «direito de remoção» (GDPR)?
Remova o primário nos sistemas de processamento; em revistas de auditoria - armazene os tokens/hachis sem PII restaurável e conduza o Legal Hold quando necessário.
Resumo: Os registros de auditoria não são «logs em S3», mas sim um histórico criptográfico comprovado, com políticas claras, armazenamento imutável, acesso controlado e disposição para a disputa/verificação regulatória. Construa um ingest em contratos, assine eventos críticos, apoie o Merkle e os dashboards - e você terá uma base confiável de confiança, segurança e complacência.