Auditorias e registros imutáveis

Auditorias e registros imutáveis

1) Por que é necessário

O objetivo da auditoria é registrar «quem, onde, quando e porquê» com uma integridade comprovável para manter a segurança, as investigações, os relatórios financeiros e a conformidade.
O registro imutável é o formato e o armazenamento onde os eventos são gravados apenas por adição (append-only) e a alteração ou remoção subsequente não é possível ou detectável por ferramentas criptográficas e políticas de armazenamento.

2) Modelo de ameaças e objetivos de controle

• Editar/remover eventos intencionalmente por um insider.
• Troca de tempo/origem (replay/backdating).
• Desligamento silencioso de logs no nó.
• Perda de parte do registro em acidentes/migrações.
• Excesso de coleta de PII e separação de privacidade.

1. Integridade: prova de proteção contra modificações/remoções.

2. Abrangência: encerramento de fluxos-chave (controle plane, data plane, acessíveis, dinheiro).

3. Exacto tempo: tempo reproduzível, sincronizado.

4. Disponibilidade: leitura e busca dentro do SLO.

5. Privacidade: PII mínimo, toquenização/criptografia, legalidade de uso.

3) Taxonomia e prioridades de eventos

• Controle de plano: autenticação/autorização, alterações de configuração, operações de chave (KMS), gerenciamento de segredos, alteração de políticas.
• Data Plane: acesso a objetos/registros/cheques/pagamentos; leitura/criação/remoção.
• Admin e DevOps: SSH/console, CI/CD, alterações de infraestrutura/IaC, escalação de direitos.
• Produtos, transações, billing, transações de clientes.
• Sistema/rede: núcleo/agentes/proxy/balanços, corretores, BD.
• Segurança: IDS/IPS/EDR, WAF, anti-DDoS, antifrode, DLP.

Cada classe registra criticidade, padrão, campos obrigatórios, prazo de armazenamento, requisitos de imutabilidade.

4) Campos e formatos obrigatórios

Identificadores de correlação: 'trace _ id', 'span _ id', 'request _ id', 'ator _ id' (usuário/serviço), 'tenant _ id', 'resource _ id'.
Contexto A&A: modo de autenticação, papel/política no momento da ação.
Tempo: RFC3339/UTC, milissegundos/nanossegundos; fonte de sincronização.
Ação e resultado: tipo de operação, alvo, status, número de objetos afetados.
Integridade: registro HMAC local, número de ordem (sequence), hash-ave.
Padrão: JSON com modelo estável (por exemplo, compatível com dicionários de evento compartilhados).

Segredos, chaves, tokens cheios de PAN, senhas, chaves privadas. PII - Apenas por necessidade, mascarado/tocado.

5) Tempo e sincronização

Fonte de tempo: pelo menos duas fontes independentes (NTP/PTP) + monitoramento de deslocamento.
Assinaturas de tempo críticas: Use os serviços de marca de tempo confiável (TSA) ou o serviço de time-sealing interno para pacotes de eventos.
Regras: sem fusos horários locais, apenas UTC; logar e deslocar/qualidade do tempo.

6) Arquitetura de fluxo de logs

Agentes → Tampão → Transporte → Landing → Cadeia de Hash/assinatura → Frio/Arquivo → Índice de pesquisa.

Coleta no nó: agentes leves (daemonset/sidecar) com bufê no disco (back-pressure).
Transporte: canal seguro (TLS/mTLS), entrega garantida (at-least-once), idempotent-ingest.
Área de Landing: Armazém de objetos em «queijo» (partições por data/tenante/tipo).
Índice: motor de pesquisa/análise para consultas online (camada quente).
Arquivo (WORM): baquetes/fitas imutáveis com políticas de retenção e hold legal.
Anchor/Seal: Um «estoque» intermitente de pacotes de circuitos de hash (veja abaixo).

7) Imutabilidade criptográfica

7. 1 Cadeias de hasteamento (append-only)

Cada entrada contém: 'hash _ curr = H (record)', 'hash _ steve' da gravação anterior, 'seq'. Qualquer alteração quebra a corrente.

prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7. 2 Assinaturas de maços e carimbo de tempo

A cada N segundos/MB formamos a raiz do Merkle de todos os 'hash _ curr'.
Assinamos a chave de auditoria (armazenada de forma sustentável no KMS/HSM).
Adicionamos a marca de tempo da TSA e publicamos o «diretório de blocos» (Transparency Jobs).
Opcional: âncora periodicamente a raiz para um espaço comprovado externo (por exemplo, diário independente ou armazenamento imutável público).

7. 3 Gerenciamento de chave de auditoria

As chaves de assinatura são KMS/HSM, rotação gráfica, acesso multifacetado, dual-controle para exportação.
Rever a chave para um novo ramo de confiança; assinaturas antigas permanecem verificáveis.

8) Políticas de armazenamento e WORM

WORM/imutability: Incluímos contêineres/baquetes imutáveis com as políticas Retence e Legal Hold para as classes P0/P1.
Versioning: ativado; remoção - apenas em procedimentos com atraso (proibição do purge instantâneo).
Retenção: quente (7-30 dias), quente (3-6 meses), frio/arquivo (1-7 anos ou mais, dependendo do regulador/contrato).
Multiplicidade: espaços individuais de nomes/ensaios/chaves de criptografia por locador; relatórios de acessos de revistas.

9) Privacidade e minimização

Coleta de acordo com o princípio de necessidade, não é necessário.
Localização/pseudonimato de campos sensíveis, hash com sal para identificadores.
Criptografar campos no lado AEAD no armazenamento compartilhado de objetos.
Direito de remoção (quando aplicável): É implementado através da cripto-apagar as chaves de campos/partituras sem violar a imutabilidade do contêiner (planejado para ser projetado).

10) Acesso, papéis e auditoria da própria auditoria

Divisão: producers ≠ readers ≠ admins.
Apenas leitura do WORM; alteração de políticas de reticência - através de papéis individuais e processo com aprovação.
Todas as operações de leitura/exportação são registradas para um registro secundário (meta-auditoria).
Exportação para investigação/complacência - em forma criptografada com catálogo de hash blocs e cadeia de confiança.

11) Observabilidade e SLO

Métricas: taxa de injeção, liga a índice,% de perda/repetição, proporção de tempo não incronizado, erro de assinatura/ancoragem, preenchimento de buffers.
SLO: ≥99. 9% dos eventos foram entregues ≤ X segundos antes do índice quente; 0 «buracos» inexplicáveis nas sequências; 100% dos blocos estão assinados e marcados por tempo.
Alerts: interrupção da injeção> N minutos, crescimento invalid-hash, separação da cadeia, falha da assinatura/temporizador, deslocamento do tempo para além do limite.

12) Testes e verificação

Testes Red/Blue: tentativa de edição/remoção de gravações em diferentes estágios; verificação de detecção.
Chaos: desligar o agente no nó, quebrar a rede, abarrotar o tampão, trocar o tempo.
Verificações criptadas, validação regular de correntes, varredura de raízes de Merckle e carimbos.
Forenzica: reprodução de cenários de investigação de revistas end-to-end.

13) Exploração e procedimentos

Runbook «verificação de integridade» (on-demand e programado).
Procedimento legal hold e «congelamento» temporário das partições.
Processo de discovery e exportação mantendo a cadeia de confiança.
Plano de rotação de chave de auditoria e reação de comprometimento (novo ramo de confiança, e-assinatura de blocos, notificações).

14) Mini-receitas

records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

• Controle/Data Plane P0: quente 30 dias → quente 6 m → arquivo de 7 anos (WORM).
• DevOps: 14 dias quente → 3 m quente → arquivo 1 ano.
• Sinais de Security, 90 dias quente (para investigação), depois 1 ou 3 anos.

15) Erros frequentes

«Logi é um texto sem padrão». Sem esquema, não há integridade e busca definidas; O JSON canônico e os campos fixos são obrigatórios.
Não há correlação. A falta de 'trace _ id' quebra as investigações.
Hora local. Apenas UTC e controle de deslocamento.
Gravar em volumes modificáveis. Sem o WORM, qualquer invenção é ficção.
Não logam leitura. Ler dados sensíveis é importante para capturar tanto quanto gravar.
Os segredos estão nos logs. Ative os agentes de saúde antes do envio, as listas vermelhas dos patters.
Uma chave para tudo. As chaves de assinatura e criptografia estão separadas, com o papel e a rotação.

16) Conformidade e regulação

Os requisitos de armazenamento/retenção dependem do domínio (finanças, pagamentos, TV, etc.).
Comprovação: disponibilidade de protocolos WORM/Reticência, relatórios de validação de cadeias, registros de acesso a revistas, procedimentos legal hold e exportação.

17) Folhas de cheque

Antes de vender

• Aprovado taxonomia de eventos e esquema (campos obrigatórios).
• Agentes configurados, tampões, transporte seguro, back-pressure.
• Incluídos: cadeias de hashtag, assinatura de bloco, carimbo de tempo, logos transparency.
• O armazenamento WORM/Retenção está ativado; teste de impossibilidade de regravação/remoção.
• Camuflar/tornear campos sensíveis.
• Sincronizar o tempo e monitorar o deslocamento.
• Plano de rotação e armazenamento de chaves de auditoria no KMS/HSM.

Exploração

• Validação semanal de correntes e blocos (+ relatório).
• Alertas para quebra de cadeia/erro de assinatura/deslocamento de tempo.
• Testes de substituição/remoção do Red-Team.
• Review regularmente retenções e custos.

18) FAQ

«Apenas uma adição» ao nível da base de dados é suficiente?
Oh, não. São necessárias garantias criptográficas (cadeias de hashtag, assinaturas de blocos, selos de tempo) e políticas WORM.

Em: Como estar com direito a remoção de dados?
O: Projete a desinstalação cripto (remoção de chaves) para campos/partituras, mantendo o suporte inalterável e comprovável.

Em: Você precisa de uma chave para assinar blocos?
Oh, sim. As chaves de assinatura de blocos são separadas das chaves de criptografia de armazenamento; Guarde no KMS/HSM, com rotação e áudio.

Pode-se «ancorar» num espaço público?
Opcional. Isso aumenta a capacidade de verificação e reduz «reescrever a história» dentro do circuito.

• Criptografia At Rest
• Criptografia In Transit
• «Gestão de segredos»
• Gerenciamento de chaves e rotação
• «Assinar e verificar solicitações»