Como Logs à Prova de Adulteração Fortalecem a Conformidade (SOC 2, ISO 27001, PCI DSS, LGPD)

O Que os Auditores Realmente Querem Ver

Auditores não querem apenas logs. Qualquer sistema consegue gerar logs. Uma plataforma pode produzir milhões de registros por dia, e nada disso tem valor se os dados puderem ser alterados sem detecção.

O que os auditores querem cada vez mais, e o que frameworks como SOC 2, ISO 27001, PCI DSS e LGPD cada vez mais esperam, é evidência de que os logs são confiáveis. Não basta que existam. É preciso demonstrar que não foram alterados desde a sua criação.

Essa diferença importa.

A distância entre "nós temos logs" e "nós conseguimos provar que nossos logs estão corretos" é onde auditorias travam, certificações atrasam e riscos regulatórios aumentam.

SOC 2: CC7.2 e CC7.3

O SOC 2 é baseado nos Trust Services Criteria. Dois desses critérios são especialmente relevantes para integridade de logs de auditoria.

CC7.2 exige que a organização monitore os componentes do sistema e a operação dos controles de segurança. Esse monitoramento depende de logs. Mas, se os logs puderem ser alterados, o monitoramento deixa de ser confiável, porque o próprio registro de eventos pode ter sido falsificado.

CC7.3 exige que a organização avalie eventos de segurança para determinar se eles representam incidentes. Essa avaliação depende de uma linha do tempo confiável. Se uma entrada de log puder ser modificada depois do fato, a cronologia do incidente perde credibilidade.

Auditores de SOC 2 cada vez mais pedem não apenas os logs, mas também garantias de que a integridade desses registros foi preservada. Um sistema de logging com evidência criptográfica de integridade atende diretamente a essa expectativa.

Já um sistema mutável obriga o auditor a confiar em controles internos de acesso e garantias processuais. Essa é uma posição mais fraca e normalmente gera perguntas adicionais.

ISO 27001: Anexo A.12.4

O Anexo A.12.4 da ISO 27001 trata de logging e monitoramento. Seu objetivo é garantir que eventos sejam registrados e que esses registros possam servir como evidência.

O controle A.12.4.2 aborda especificamente a proteção das informações de log, afirmando que os mecanismos de logging e os dados de log devem ser protegidos contra adulteração e acesso não autorizado.

Isso é explícito. O framework não recomenda apenas coletar logs. Ele identifica a adulteração como um risco direto que precisa ser mitigado.

A orientação de implementação normalmente inclui medidas como:

• Proteger arquivos de log contra modificação
• Impedir que usuários apaguem ou sobrescrevam logs relacionados às suas próprias atividades
• Utilizar trilhas de auditoria write-once

O encadeamento criptográfico de hashes atende ao espírito e à intenção prática do A.12.4.2 de uma forma que o controle de acesso, sozinho, não consegue.

Controles de acesso ajudam a evitar alterações não autorizadas. Integridade criptográfica torna qualquer alteração detectável, seja causada por um ator não autorizado ou por um usuário privilegiado.

São controles complementares, mas não equivalentes.

PCI DSS: Requisito 10

Para organizações que lidam com dados de cartão de pagamento, o Requisito 10 do PCI DSS é um dos conjuntos de exigências de logging mais rigorosos entre os principais frameworks de compliance.

O Requisito 10 exige que registros de trilha de auditoria sejam protegidos contra modificação, incluindo expectativas como:

• 10.3.2: Arquivos de log de auditoria devem ser protegidos contra modificação não autorizada
• 10.3.3: Arquivos de log devem ser copiados rapidamente para um servidor centralizado ou outra mídia difícil de alterar
• 10.5.1 (PCI DSS v4.0): O histórico de logs deve ser mantido por pelo menos 12 meses, com no mínimo os três meses mais recentes disponíveis para análise imediata

A expressão "difícil de alterar" é especialmente relevante.

Auditores de PCI DSS geralmente interpretam isso como uma exigência de proteção técnica, e não apenas de política interna. Uma frase como "administradores não devem modificar logs" é fraca. Já um sistema em que qualquer alteração é detectável criptograficamente é muito mais robusto.

No PCI DSS v4.0, as expectativas em torno de verificação de integridade ficaram ainda mais explícitas. Organizações que não conseguem demonstrar controles técnicos confiáveis de integridade de logs ficam mais expostas a findings e planos de remediação.

LGPD e GDPR: Accountability sobre o Acesso aos Dados

A LGPD no Brasil e o GDPR na União Europeia exigem que organizações demonstrem accountability sobre como dados pessoais são processados, acessados e tratados.

Pelo Artigo 37 da LGPD, controladores e operadores devem manter registros das operações de tratamento. Pelo Artigo 5(2) do GDPR, as organizações precisam demonstrar conformidade com os princípios centrais de proteção de dados.

Na prática, isso significa que os registros de acesso precisam ser defensáveis.

Quando um titular solicita evidências relacionadas a acesso, correção ou exclusão de dados, a resposta da organização depende da credibilidade dos logs. Se esses registros puderem ser questionados como mutáveis ou não confiáveis, a demonstração de accountability perde força.

Um log de acesso com integridade verificável oferece uma posição muito mais forte. Ele cria um registro defensável de quem acessou quais dados, em que momento, e se esse histórico permaneceu íntegro desde a escrita.

Em disputas, investigações e análises regulatórias, a diferença entre um log comum e um log verificável pode influenciar materialmente o desfecho.

Tamper-Evident vs. Tamper-Proof: A Distinção que Importa

Essa distinção é útil em conversas de compliance.

Tamper-evident significa que, se um registro for modificado, essa modificação poderá ser detectada. Uma cadeia criptográfica de hashes é tamper-evident porque qualquer alteração em um registro histórico quebra a cadeia naquele ponto, e essa quebra pode ser verificada de forma independente.

Tamper-proof sugere que adulteração não pode acontecer de forma alguma. Essa é uma afirmação muito mais forte e, em muitos sistemas reais, nem prática nem necessária.

A maioria dos frameworks de compliance não exige impossibilidade absoluta. O que eles exigem são controles fortes, detectáveis e defensáveis de integridade.

Por isso, a linguagem correta em compliance normalmente não é "nossos logs nunca podem ser alterados", mas sim: "qualquer alteração em nossos logs é imediatamente detectável porque cada registro é criptograficamente selado e encadeado".

Esse é o tipo de resposta que o auditor consegue avaliar tecnicamente.

Como a ImmutableLog se Alinha a Cada Framework

A arquitetura da ImmutableLog atende diretamente a essas expectativas de compliance:

• SOC 2 CC7.2 / CC7.3: Os eventos são gravados uma única vez e selados criptograficamente no momento da ingestão. O monitoramento e a análise de incidentes passam a depender de registros cuja integridade pode ser verificada.
• ISO 27001 A.12.4.2: O encadeamento de hashes torna qualquer modificação detectável, independentemente do nível de privilégio do usuário. A proteção não depende apenas de procedimento.
• PCI DSS Requisito 10: Os eventos se tornam imutáveis desde o momento do registro, e a verificação de integridade pode ser executada sob demanda, apoiando as expectativas do framework sobre resistência à alteração e integridade verificável.
• LGPD / GDPR accountability: Registros de acesso são selados com timestamps e hashes criptográficos, criando uma cadeia de custódia mais defensável para eventos de acesso a dados pessoais.

Compliance Fica Mais Simples Quando a Integridade Já Está na Base

Organizações que tratam compliance como um projeto recorrente acabam descobrindo que sistemas de logging mutáveis geram retrabalho em todo ciclo de auditoria. É preciso revisar políticas, validar backups, explicar controles e compensar a falta de prova técnica com documentação processual.

Já organizações que incorporam logging imutável à infraestrutura desde o início mudam esse cenário.

A resposta para "vocês conseguem provar que os logs não foram alterados?" passa a ser simples: "sim: aqui está a verificação".

Essa resposta é mais forte do que qualquer política, mais rápida do que qualquer explicação processual e mais resistente ao escrutínio de auditoria.

---

Veja como a ImmutableLog ajuda empresas a sair do simples registro de eventos para a prova verificável deles. Fale conosco →