Um novo espaço de análise, reflexão e pluralidade no
debate público sobre o sistema de justiça criminal
Um novo espaço de análise, reflexão e pluralidade no
debate público sobre o sistema de justiça criminal
A reconstrução técnico-pericial de eventos em ambientes digitais depende, com frequência, da análise de registros automatizados produzidos por sistemas operacionais, aplicações, dispositivos de rede, mecanismos de autenticação, bancos de dados, soluções de segurança, plataformas de identidade e serviços em nuvem. Esses registros, usualmente denominados logs, ocupam posição relevante em investigações envolvendo acessos indevidos, fraudes, alterações sistêmicas, transações questionadas e controvérsias sobre a ocorrência de atos praticados em meio eletrônico.
Do ponto de vista pericial, os logs somente possuem utilidade demonstrativa quando sua procedência, integridade, rastreabilidade, forma de geração, preservação e compatibilidade com outros vestígios digitais puderem ser tecnicamente examinadas e documentadas. O valor probatório do registro não decorre de sua aparência automatizada, mas da possibilidade de submeter sua origem, seu contexto e sua cadeia de preservação a verificação metodologicamente controlável.
Logs não constituem reconstrução integral dos fatos. São registros técnicos parciais, produzidos conforme a configuração prévia do ambiente, a arquitetura dos sistemas, as políticas de retenção, os mecanismos de auditoria, a sincronização temporal e os controles de integridade existentes no momento da geração e da preservação dos dados.
A questão jurídico-técnica consiste em delimitar em que medida os logs podem sustentar inferências periciais sobre eventos digitais e quais restrições metodológicas impedem sua conversão automática em prova de autoria, intenção, causalidade ou completude fática.
Nesse contexto, a prova digital não elimina a incerteza própria da reconstrução processual dos fatos. Sua função é reduzir a margem de dúvida a partir da qualidade dos vestígios disponíveis, da confiabilidade do procedimento empregado e da correspondência lógica entre os dados observados e a conclusão técnica apresentada.
No processo penal brasileiro, a disciplina da prova pericial decorre, em especial, dos arts. 155 e 158 a 184 do Código de Processo Penal. Com a Lei nº 13.964/2019, foram introduzidos os arts. 158-A a 158-F, que passaram a tratar expressamente da cadeia de custódia e da documentação cronológica do vestígio (Brasil, 1941, 2019).
Embora a disciplina legal tenha sido estruturada de forma geral, sua aplicação à evidência digital exige atenção às propriedades específicas dos dados eletrônicos. Em matéria de logs, a cadeia de custódia não se restringe à guarda de arquivos exportados. Deve abranger, no mínimo, a identificação da fonte originária, o método de extração, o intervalo temporal coletado, os filtros aplicados, o formato de exportação, os metadados preservados, os controles de integridade, o armazenamento subsequente e as transformações realizadas durante a análise.
A jurisprudência do Superior Tribunal de Justiça tem atribuído relevância à documentação dos procedimentos de coleta e preservação da prova digital, especialmente quando a aferição de integridade, autenticidade e confiabilidade depende do registro do caminho percorrido pelo vestígio. Essa orientação reforça que a cadeia de custódia digital não deve ser tratada como formalidade periférica, mas como condição de auditabilidade e controle contraditório da prova técnica (Brasil, 2023).
A função da perícia não é substituir o juízo jurisdicional. Sua finalidade é apresentar elementos técnicos verificáveis, permitindo ao julgador e às partes compreenderem o alcance, a confiabilidade e os limites dos vestígios examinados. A redação pericial deve, portanto, distinguir fato técnico, inferência técnica, hipótese e impossibilidade inferencial.
A teoria racional da prova, em linha com a formulação de Michele Taruffo (2014), opera como instrumento de controle da reconstrução fática, e não como mecanismo de certeza absoluta. A força probatória dos registros digitais depende da qualidade epistêmica dos elementos disponíveis e da coerência das inferências produzidas a partir deles.
Em perspectiva compatível, Susan Haack (2014) trata a justificação probatória como relação racional entre evidência, coerência explicativa e conclusão sustentada. No campo dos logs, essa premissa impede que a simples existência de um registro automatizado seja convertida, sem etapas intermediárias de validação, em demonstração suficiente de autoria ou intencionalidade.
As garantias processuais, a motivação da decisão penal e a submissão da prova ao contraditório impõem cautela adicional à valoração de vestígios digitais. Registros de autenticação, endereços IP, timestamps, identificadores de sessão e eventos de aplicação não devem ser valorados isoladamente como prova plena de comportamento humano individualizado. Sua relevância probatória depende da demonstração técnica de contexto, integridade, correlação e suficiência inferencial.
Logs são registros produzidos por componentes computacionais para documentar eventos relevantes ao funcionamento, à segurança, à auditoria ou à administração de sistemas. Podem ser gerados em diferentes camadas tecnológicas, incluindo sistemas operacionais, aplicações corporativas, bancos de dados, servidores web, firewalls, proxies, VPNs, provedores de identidade, sistemas de autenticação multifator, dispositivos de rede, soluções EDR, plataformas SIEM, serviços em nuvem e ferramentas de administração ou orquestração.
A pluralidade de fontes amplia a possibilidade de correlação entre vestígios, mas também introduz riscos de inconsistência, duplicidade, normalização indevida, perda de metadados e divergência temporal.
Para fins periciais, a aptidão probatória dos logs é condicionada por características próprias dos registros computacionais, entre as quais:
Essas características impõem restrições metodológicas específicas. A existência de um log não demonstra, isoladamente, sua completude, autenticidade, integridade ou suficiência probatória. É necessário demonstrar como o registro foi gerado, preservado, extraído e interpretado.
Normas técnicas como ISO/IEC 27037, ISO/IEC 27041 e ISO/IEC 27042 oferecem diretrizes para identificação, coleta, aquisição, preservação, validação metodológica, análise e interpretação de evidência digital (ISO, 2012, 2015a, b). A NIST SP 800-86 fornece parâmetros para integração de técnicas forenses à resposta a incidentes, enquanto a NIST SP 800-92 trata especificamente da gestão de logs computacionais (NIST, 2006a, b).
Em ambientes corporativos, controles de segurança previstos na ISO/IEC 27001:2022, na ISO/IEC 27002:2022 (ISO, 2022a, b) e nos CIS Controls v8.1 (CIS, 2024) podem contribuir para logging, monitoramento, proteção de registros, retenção e auditoria. Contudo, a existência formal de controles não dispensa a verificação concreta de sua implementação, efetividade e aderência ao período e ao sistema investigado.
A preservação de logs exige procedimentos compatíveis com a natureza dinâmica do vestígio. Diferentemente de mídias estáticas, registros de log podem ser continuamente atualizados, agregados, compactados, rotacionados, sobrescritos ou encaminhados a repositórios centralizados.
Como síntese metodológica aplicável à análise pericial de logs, a partir das boas práticas de preservação de evidência digital e gestão de registros computacionais, a coleta deve documentar, no mínimo:
A geração de hash sobre arquivo exportado permite demonstrar correspondência matemática entre o arquivo preservado e o arquivo posteriormente analisado. Não demonstra, por si só, que os registros eram verdadeiros, completos, originários do sistema indicado ou livres de alteração antes da exportação.
Essa distinção é metodologicamente crítica. O hash protege o estado preservado da evidência a partir de determinado momento. Não autentica o histórico anterior do registro, não valida a configuração do sistema, não comprova autoria e não exclui manipulação pretérita.
Em ambientes SIEM, deve-se distinguir o evento de origem do evento ingerido, normalizado ou correlacionado. O timestamp de ingestão não equivale necessariamente ao timestamp de ocorrência. A normalização pode alterar campos, converter fusos horários, agregar eventos, descartar atributos ou reorganizar registros conforme regras internas da ferramenta.
Em serviços de nuvem e plataformas SaaS, a perícia pode depender de logs disponibilizados por painéis administrativos, APIs ou relatórios do provedor. Nesses casos, deve-se ressalvar a limitação de verificabilidade independente sobre a infraestrutura subjacente, especialmente quando não houver acesso direto ao repositório original ou aos mecanismos internos de geração dos registros.
A dimensão temporal é elemento central na análise de logs. A reconstrução pericial de eventos depende da ordenação cronológica dos registros e da compatibilidade entre eventos observados em fontes distintas.
Timestamps devem ser analisados com cautela. Diferenças de fuso horário, ausência de sincronização via NTP, relógios locais incorretos, latência de transmissão, atraso de ingestão, normalização por SIEM e armazenamento em UTC podem produzir sequências aparentes incompatíveis com a ordem real dos eventos.
Em termos periciais, é necessário identificar:
Na ausência de sincronização temporal demonstrada, não é tecnicamente adequado sustentar sequência causal rígida. Pode ser possível afirmar compatibilidade temporal relativa, mas não necessariamente anterioridade, posterioridade ou causalidade exata.
A correlação entre múltiplas fontes aumenta a robustez inferencial quando os registros são independentes, preservados, temporalmente coerentes e tecnicamente compatíveis. Por outro lado, a repetição do mesmo evento em fontes derivadas não equivale necessariamente a corroboração independente. Um SIEM pode apenas reproduzir, enriquecer ou normalizar evento gerado originalmente por uma única fonte.
A análise de logs exige delimitação precisa do que cada artefato permite afirmar.
Um log de autenticação pode demonstrar que determinada credencial, conta ou identificador foi utilizado em tentativa de acesso ou acesso bem-sucedido, sob as condições registradas pelo sistema.
Não permite afirmar, isoladamente, que o titular cadastral da conta executou pessoalmente o ato. Atribuição pessoal depende de elementos adicionais, como MFA, posse do dispositivo, logs de endpoint, geolocalização tecnicamente confiável, histórico de comportamento, inexistência de compartilhamento de credenciais, ausência de indícios de comprometimento e correlação com outras fontes independentes.
Um endereço IP registrado pode indicar origem lógica ou ponto de saída de uma conexão, conforme observado pela fonte examinada.
Não identifica automaticamente pessoa física, dispositivo específico ou operador humano. O mesmo IP pode representar NAT, CGNAT, VPN, proxy, rede corporativa, balanceador, infraestrutura de nuvem ou ambiente compartilhado.
Logs de aplicação podem demonstrar eventos processados pela própria lógica do sistema, como criação, alteração, exclusão, autenticação, erro, transação ou mudança de estado.
Não demonstram, isoladamente, que o evento corresponde integralmente ao fato externo que se pretende provar. A aplicação registra aquilo que sua lógica foi configurada para registrar, podendo haver falhas, omissões, eventos não auditados, alterações diretas em banco de dados ou execução por APIs não refletidas no mesmo fluxo.
Logs de banco de dados podem registrar comandos, transações, alterações, conexões ou eventos administrativos, dependendo da configuração de auditoria.
Não demonstram, isoladamente, finalidade, legitimidade, autoria humana ou contexto operacional da alteração. Também podem não registrar alterações se a auditoria não estava habilitada, se a granularidade era insuficiente ou se houve retenção limitada.
Logs de rede podem demonstrar conexões, fluxos, permissões, bloqueios, autenticações ou túneis estabelecidos.
Não demonstram, isoladamente, conteúdo semântico da comunicação, intenção do usuário ou relação causal com evento de aplicação. Também podem registrar apenas metadados, sem payload, e estar sujeitos a agregação, rotação ou perda por volume.
Logs de endpoint podem contribuir para correlacionar uso local, execução de processos, autenticação, conexão de dispositivos, atividade de usuário e eventos de segurança.
Não são automaticamente conclusivos quando há lacunas, privilégios administrativos, possível comprometimento do sistema, ausência de EDR, logs desabilitados ou retenção insuficiente.
Logs de SIEM podem ampliar capacidade de correlação, centralização e preservação.
Não substituem a análise das fontes originárias. Eventos normalizados ou correlacionados podem depender de regras internas, parsers, enriquecimentos, deduplicação, ingestão parcial e configurações de retenção específicas.
Logs de serviços em nuvem e plataformas SaaS podem demonstrar eventos administrativos, autenticações, alterações de configuração, chamadas de API, atividades de usuário e eventos de segurança disponibilizados pelo provedor.
Não permitem, sem acesso técnico adicional, verificar integralmente a infraestrutura subjacente, os mecanismos internos de geração, os critérios de retenção e eventuais transformações realizadas antes da disponibilização ao cliente. Nesses casos, a conclusão pericial deve explicitar o grau de dependência em relação ao provedor e ao meio de exportação utilizado.
A validade técnico-probatória da análise de logs depende da separação entre quatro categorias.
Fato técnico é o dado diretamente verificável no vestígio examinado. Exemplo: existência de registro indicando autenticação bem-sucedida da conta “X”, às 10h03, a partir do IP “Y”, conforme arquivo exportado da fonte “Z”.
Inferência técnica é a conclusão logicamente derivada da correlação entre registros. Exemplo: os logs de autenticação, aplicação e banco de dados são compatíveis com a execução de determinada transação durante sessão vinculada à conta “X”.
Hipótese é explicação plausível não suficientemente demonstrada pelos registros disponíveis. Exemplo: a operação pode ter sido realizada pelo titular da conta, por terceiro com acesso à credencial, por sessão sequestrada, por automação ou por integração sistêmica.
Impossibilidade inferencial ocorre quando os vestígios não permitem sustentar determinada conclusão. Exemplo: na ausência de registros de endpoint, MFA, posse do dispositivo, geolocalização confiável e exclusão técnica de comprometimento, não é metodologicamente possível afirmar autoria pessoal apenas com base em log de autenticação.
Essa distinção deve orientar a redação pericial. A formulação “a conta realizou a transação” é tecnicamente distinta de “o titular da conta realizou a transação”. A primeira pode ser compatível com logs de aplicação. A segunda exige elementos adicionais de individualização.
Considere-se cenário em que uma aplicação registra autenticação bem-sucedida da conta “A” às 10h03, criação de sessão às 10h04 e execução de transação sensível às 10h07.
Sob perspectiva técnico-pericial, os fatos técnicos verificáveis podem ser:
A inferência técnica possível, desde que preservada a integridade dos logs e demonstrada a coerência temporal, é que a transação é compatível com execução durante sessão autenticada com a conta “A”.
Não é metodologicamente possível afirmar, apenas a partir desses registros, que o titular cadastral da conta executou pessoalmente a transação, que agiu com intenção específica ou que inexistem causas técnicas alternativas.
Para atribuição pessoal com maior robustez, seriam necessários elementos adicionais, tais como autenticação multifator vinculada a dispositivo sob controle do titular, logs do provedor de identidade, registros de endpoint, evidência de posse e uso do equipamento, ausência de indícios de comprometimento, geolocalização tecnicamente confiável, histórico de comportamento compatível, ausência de compartilhamento de credenciais, correlação com registros de rede independentes e preservação íntegra dos logs no período analisado.
Na ausência desses elementos, a conclusão deve permanecer restrita à compatibilidade técnica entre credencial, sessão e transação.
Em muitos ambientes, logs são mantidos por períodos limitados. A retenção pode variar conforme volume de dados, criticidade do sistema, capacidade de armazenamento, política corporativa, requisitos regulatórios e configuração da ferramenta.
Se a perícia é realizada após o prazo de retenção, registros relevantes podem ter sido sobrescritos ou eliminados por processo ordinário. Nessa hipótese, a ausência de logs não permite concluir automaticamente que o evento não ocorreu.
A formulação tecnicamente adequada é: não foram localizados, nas fontes examinadas e no período preservado, registros suficientes para confirmar o evento. Formulação distinta, como “o evento não ocorreu”, somente seria admissível se demonstrado que o sistema necessariamente registraria aquele evento, que os logs estavam completos, íntegros, preservados e abrangiam integralmente o intervalo relevante.
A distinção entre ausência de evidência e evidência de ausência possui relevância decisiva na prova digital. Sistemas computacionais nem sempre registram todos os eventos relevantes. A inexistência de registro pode decorrer de não ocorrência do evento, mas também de logging desabilitado, retenção expirada, rotação automática, configuração inadequada, falha de coleta, perda de metadados, exportação parcial ou limitação da ferramenta.
A análise de logs torna-se metodologicamente vulnerável quando converte indicadores técnicos em conclusões pessoais, causais ou subjetivas.
É inadequado converter login em autoria pessoal sem elementos adicionais de individualização.
É inadequado converter IP em identificação humana sem correlação com contexto de rede, provedor, dispositivo, usuário e período.
É inadequado converter sequência temporal em causalidade sem demonstração de vínculo técnico entre eventos.
É inadequado converter ausência de log em inexistência do fato sem demonstração de completude e obrigatoriedade de registro.
É inadequado converter hash de arquivo exportado em prova de veracidade originária dos registros.
É inadequado converter evento normalizado em SIEM em evidência independente sem verificação da fonte primária.
É inadequado converter conta de usuário em pessoa física quando houver possibilidade de credencial compartilhada, conta de serviço, automação, integração ou comprometimento.
Essas extrapolações comprometem a racionalidade probatória porque ampliam o alcance dos vestígios além de sua capacidade demonstrativa.
A principal fragilidade probatória dos logs reside na assimetria entre o que o processo deseja demonstrar e o que os registros efetivamente permitem sustentar.
Logs podem documentar eventos técnicos. Podem indicar uso de credenciais, criação de sessões, execução de comandos, conexões de rede, alterações em registros, erros, bloqueios, permissões e interações entre sistemas. Contudo, nem sempre permitem reconstruir integralmente o evento histórico, individualizar o agente humano ou excluir hipóteses alternativas.
A aparência de objetividade tecnológica tende a produzir hiperconfiança. Timestamps, identificadores de sessão, endereços IP e registros automatizados podem ser interpretados como se fossem equivalentes a observação direta do fato. Essa equivalência é tecnicamente inadequada.
O sistema registra aquilo que foi configurado para registrar, no formato definido, com a granularidade disponível, sob as condições operacionais existentes e dentro do prazo de retenção aplicável. Se a trilha de auditoria era incompleta, o log será incompleto. Se o relógio estava incorreto, a cronologia pode ser defeituosa. Se a conta era compartilhada, o identificador lógico não individualiza pessoa. Se o SIEM recebeu eventos parciais, a correlação poderá ser incompleta. Se os registros foram exportados sem documentação suficiente, a auditabilidade será reduzida.
A limitação probatória, nesses casos, não decorre necessariamente de deficiência da perícia. Pode decorrer da inexistência material de vestígios suficientes para reconstrução mais robusta.
Por essa razão, a conclusão pericial deve observar proporcionalidade inferencial. Quanto maior a lacuna de preservação, integridade, contexto ou correlação, menor deve ser a amplitude da conclusão. A confiabilidade da prova técnica não está na assertividade máxima, mas na aderência entre vestígio, método e inferência efetivamente sustentável.
Logs são vestígios digitais relevantes para a reconstrução técnico-pericial de eventos em ambientes computacionais. Sua utilidade probatória depende das condições de geração, preservação, extração, integridade, retenção, contextualização e correlação com outras fontes.
Em termos estritamente técnicos, o exame de logs permite constatar registros preservados, descrever seus campos, indicar sua fonte declarada ou aparente, verificar compatibilidades temporais e formular conclusões limitadas aos vestígios efetivamente examinados.
Não é possível, sem extrapolação metodológica, atribuir autoria pessoal, intenção subjetiva, causalidade inequívoca ou completude histórica apenas com base na existência isolada de logs.
A validade técnico-probatória da análise de logs exige aderência entre registro disponível, fonte examinada, método de coleta, preservação de integridade, cadeia de custódia, contexto sistêmico, correlação temporal e inferência apresentada.
Quando os logs são íntegros, preservados, temporalmente consistentes e corroborados por fontes independentes, podem sustentar inferências técnicas relevantes. Quando são isolados, incompletos, exportados sem rastreabilidade, temporalmente inconsistentes ou dependentes de pressupostos não verificados, sua força probatória deve ser reduzida e expressamente condicionada.
A adequada análise pericial de logs não consiste em transformar registros automatizados em narrativa conclusiva, mas em delimitar, com precisão metodológica, o que os vestígios permitem afirmar, o que apenas sugerem, o que permanece como hipótese e o que não pode ser tecnicamente sustentado.
A prova digital tecnicamente válida não é aquela que apresenta a narrativa mais extensa, mas aquela que explicita, com rastreabilidade metodológica, os limites entre o demonstrado, o inferido, o apenas possível e o tecnicamente indemonstrável.
BRASIL. Decreto-Lei nº 3.689, de 3 de outubro de 1941. Código de Processo Penal. Rio de Janeiro: Presidência da República, 1941.
BRASIL. Lei nº 13.964, de 24 de dezembro de 2019. Aperfeiçoa a legislação penal e processual penal. Brasília: Presidência da República, 2019.
BRASIL. Superior Tribunal de Justiça. A cadeia de custódia no processo penal: do Pacote Anticrime à jurisprudência do STJ. Brasília: STJ, 2023.
CENTER FOR INTERNET SECURITY. CIS Critical Security Controls Version 8.1. East Greenbush: CIS, 2024.
HAACK, Susan. Evidence Matters: Science, Proof, and Truth in the Law. Cambridge: Cambridge University Press, 2014.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 27001:2022. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Geneva: ISO, 2022a.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 27002:2022. Information security, cybersecurity and privacy protection — Information security controls. Geneva: ISO, 2022b.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 27037:2012. Information technology — Security techniques — Guidelines for identification, collection, acquisition and preservation of digital evidence. Geneva: ISO, 2012.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 27041:2015. Information technology — Security techniques — Guidance on assuring suitability and adequacy of incident investigative method. Geneva: ISO, 2015a.
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 27042:2015. Information technology — Security techniques — Guidelines for the analysis and interpretation of digital evidence. Geneva: ISO, 2015b.
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST Special Publication 800-86: Guide to Integrating Forensic Techniques into Incident Response. Gaithersburg: NIST, 2006a.
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST Special Publication 800-92: Guide to Computer Security Log Management. Gaithersburg: NIST, 2006b.
TARUFFO, Michele. A prova. São Paulo: Marcial Pons, 2014.
Nota
Declaro que utilizei ferramenta de Inteligência Artificial generativa de forma acessória e limitada, exclusivamente para revisão gramatical, ajustes de estilo e organização textual, sem delegação da autoria, da análise técnica, da seleção das fontes, das conclusões ou da responsabilidade científica pelo conteúdo do manuscrito.
Como citar: RIBEIRO, Adiel de Lima. Logs e validade técnico-probatória: limites periciais na reconstrução de eventos digitais. Jornal de Ciências Criminais do IBCCRIM, 10 junho 2026. Disponível em: https://jcc.ibccrim.org.br/artigos/logs-e-validade-tecnico-probatoria-limites-periciais-na-reconstrucao-de-eventos-digitais/. Acesso em: 10 jun. 2026.
Esta obra é disponibilizada sob a licença Creative Commons Atribuição 4.0 Internacional (CC BY 4.0), permitindo uso, compartilhamento, adaptação e finalidade comercial, desde que seja dado crédito adequado ao autor.
Encontrou um erro?
Nos ajude a melhorar! Envie sua correção abaixo 👇
