Logging seguro e detecção de intrusão: enxergar o ataque enquanto ele acontece

Um invasor entrou pela conta de um usuário legítimo cujo token vazou num repositório público. Ele não quebrou nada com estardalhaço: fez login, navegou por algumas telas, exportou um relatório com dados de milhares de clientes e saiu. Três semanas depois, quando o vazamento apareceu num fórum, a equipe foi olhar os logs para entender o que havia sido acessado — e descobriu que o sistema registrava requisições HTTP com status e latência, mas não registrava qual usuário acessou qual recurso, muito menos quando um export de dados sensíveis acontecia. Havia terabytes de log e nenhuma resposta. O ataque foi invisível não porque foi sofisticado, mas porque ninguém instrumentou o sistema para vê-lo.

Logging de segurança é uma disciplina distinta do logging de depuração, e confundir as duas é a origem da maioria dos incidentes que só são descobertos por terceiros. Este artigo trata de como registrar os eventos certos, proteger esse registro de adulteração, e transformar linhas de log em detecção acionável — a diferença entre ter dados e ter respostas.

Log de debug e log de segurança são coisas diferentes#

O log de debug existe para o desenvolvedor entender o comportamento do código: valores de variáveis, fluxo de execução, tempos de resposta. Ele é volátil, verboso, e frequentemente desligado em produção. O log de segurança existe para reconstruir quem fez o quê, quando e a partir de onde — é uma trilha de auditoria, e o seu público não é o dev na próxima sprint, é o analista de resposta a incidente daqui a seis meses e, eventualmente, o perito num processo.

Essa diferença de propósito muda tudo. O log de segurança precisa ser estruturado (JSON ou formato parseável, não texto livre), precisa carregar identidade verificada (user_id, tenant_id, papel efetivo — vindos do token validado no servidor, nunca do que o cliente afirmou ser), precisa ter carimbo de tempo confiável e fuso explícito, e precisa de um identificador de correlação que amarre todos os eventos de uma mesma requisição ou sessão. Sem isso, você tem prosa, não evidência.

Os eventos que você precisa registrar#

Há uma classe de eventos que constitui o mínimo inegociável de uma trilha de segurança. Autenticação: todo login bem-sucedido e, mais importante, todo login que falhou — com o motivo (senha errada, segundo fator inválido, conta bloqueada) e a origem. Uma sequência de falhas seguida de sucesso conta a história de um ataque de força bruta que deu certo. Autorização negada: quando alguém tenta acessar um recurso e o sistema recusa, isso é sinal — usuário legítimo raramente esbarra em 403, então uma enxurrada deles é reconhecimento de superfície ou tentativa de escalonamento.

Mudança de privilégio e de estado sensível merecem registro dedicado: concessão ou revogação de papel, troca de senha, cadastro de novo segundo fator, criação de chave de API, alteração de configuração de segurança. Acesso a dado sensível — especialmente export, download em massa, ou leitura de PII — precisa ser registrado com o volume e o escopo, porque é exatamente o que o atacante do exemplo de abertura fez sem deixar rastro. Por fim, eventos administrativos e qualquer uso de acesso privilegiado (o break-glass, o sudo, a rota de operador de plataforma) devem gerar registro imutável e, idealmente, alerta em tempo real.

O que você nunca deve escrever num log#

O log é lido por muita gente, é copiado para sistemas de análise, é retido por anos, e frequentemente vaza. Por isso, ele nunca pode conter segredo. Senha em texto claro — nem "só no log de debug temporário", porque o temporário vira permanente. Token de sessão, refresh token, chave de API, chave privada: escrever qualquer um deles equivale a distribuí-los para todo mundo com acesso ao SIEM. Dados de cartão completos, o CVV, número de documento sem mascaramento, e em geral PII que não é necessária para a trilha.

A regra prática é registrar referências, não valores: o user_id, não o e-mail e a senha; o identificador do cartão tokenizado, não o PAN; o fato de que um segredo foi rotacionado, não o segredo novo. Quando a PII é indispensável para a investigação, aplique mascaramento na borda de escrita (mostrar só os últimos quatro dígitos) e trate a retenção desse log sob as mesmas regras de proteção de dados do resto do sistema — logs também estão sob a LGPD, e um log que guarda PII indefinidamente é um passivo, não um ativo.

Log injection: a entrada de log que o atacante escreve#

Um detalhe frequentemente ignorado: se o seu log inclui dados controlados pelo usuário — um nome, uma URL, um user-agent — e você os concatena sem tratamento num log de texto, o atacante pode injetar quebras de linha e forjar entradas falsas. Ele manda um nome de usuário contendo \n seguido de uma linha que imita um evento legítimo de sucesso, e agora a sua trilha de auditoria contém eventos que nunca aconteceram, plantados pelo próprio invasor para despistar a investigação. Pior: se os logs são renderizados numa interface web sem escape, você tem XSS via log, atingindo justamente o analista.

A defesa é a mesma disciplina do resto da segurança de aplicação: registre em formato estruturado (o valor do usuário vai como um campo de string escapado, não como texto solto), neutralize quebras de linha e caracteres de controle antes de gravar, e trate o log como dado não confiável ao exibi-lo. Um log que o atacante pode reescrever não é evidência.

Integridade: o log precisa resistir a quem tem acesso#

O primeiro movimento de um atacante competente depois de comprometer um servidor é limpar os rastros — apagar ou editar os logs locais. Por isso, log de segurança que mora apenas no disco da máquina atacada tem valor limitado. A trilha precisa ser enviada, o mais rápido possível, para um destino que o comprometimento daquela máquina não alcança: um coletor central, um SIEM, um armazenamento append-only. O modelo WORM (write once, read many) e buckets com retenção travada garantem que nem quem tem credencial administrativa consiga reescrever o passado.

A centralização resolve dois problemas de uma vez. Protege a integridade — o atacante teria que comprometer também o pipeline de logs — e permite correlação: eventos que, isolados em cada serviço, parecem inofensivos, revelam o ataque quando vistos em conjunto e ordenados por trace_id. Uma falha de login no serviço de auth, seguida em segundos de um acesso negado no serviço de billing e de um export no serviço de conteúdo, todos da mesma origem, é uma cadeia que só aparece quando os logs convergem.

Detecção: da linha de log ao alerta que vale a pena#

Guardar log é necessário mas não suficiente; detecção é o que transforma o registro passivo em defesa ativa. Há duas famílias de abordagem. Detecção por assinatura procura por padrões conhecidos de ataque — a string de uma injeção de SQL, o user-agent de uma ferramenta de scan, a sequência exata de um exploit. É precisa e gera pouco falso positivo, mas só pega o que já foi catalogado; um ataque novo passa reto. Detecção por anomalia estabelece uma linha de base do comportamento normal e alerta sobre o desvio — um usuário que sempre acessa dez registros por dia baixando dez mil, um login de um país onde a conta nunca esteve, um horário atípico. Pega o desconhecido, ao custo de mais ruído.

Sistemas de detecção de intrusão operam nessas duas frentes, no host (HIDS — monitorando integridade de arquivos, chamadas de sistema, logs locais) e na rede (NIDS — inspecionando tráfego em busca de padrões maliciosos). Um IPS vai além e bloqueia ativamente. Mas ferramenta é só metade; a outra metade é o processo de resposta ao que ela aponta.

A fadiga de alerta mata a detecção#

O maior inimigo da detecção não é a falta de alertas — é o excesso. Um sistema que dispara centenas de alertas por dia, a maioria falso positivo, treina o time a ignorá-los. Quando o alerta de verdade chega, ele se perde no ruído, exatamente como aconteceu em incidentes famosos em que a intrusão gerou alerta e ninguém agiu. Um alerta acionável tem três propriedades: é raro o bastante para ser levado a sério, carrega contexto suficiente para o analista decidir sem investigar do zero (quem, o quê, de onde, por que isso é suspeito), e aponta para uma ação clara. Vale mais dez alertas por semana que sempre merecem investigação do que mil por dia que ninguém lê.

A pergunta do OWASP A09: o ataque gerou log?#

A categoria A09 do OWASP Top 10 — falhas de logging e monitoramento — é peculiar porque não é uma vulnerabilidade que o atacante explora diretamente; é a ausência de visibilidade que permite todas as outras passarem despercebidas. O teste definitivo de uma trilha de segurança é adversarial: execute o ataque contra o seu próprio sistema — a tentativa de IDOR, o export não autorizado, o brute force, a injeção — e depois vá aos logs e ao painel de detecção e pergunte se aquilo apareceu. Se o ataque não deixou rastro, ou deixou um rastro que nenhum alerta capturou, a detecção está cega, e você só vai descobrir a próxima intrusão quando ela virar notícia. Purple team — atacar de propósito para validar que a defesa vê — é a forma mais honesta de testar logging.

Detecção em aplicações de IA#

Aplicações com LLM adicionam uma superfície que a maioria dos pipelines de log ainda não instrumenta. Uma tentativa de prompt injection, um usuário tentando extrair o system prompt, um agente sendo induzido a chamar uma ferramenta fora do escopo pretendido — tudo isso deveria deixar rastro. Registre os prompts (com cuidado sobre PII), as chamadas de ferramenta que o modelo solicitou, as que foram bloqueadas por guardrail, e o consumo anômalo de tokens que pode indicar um ataque de custo. A pergunta do A09 vale igual: se alguém tenta subverter o seu agente, isso aparece em algum lugar? Modelos são não determinísticos e a superfície é nova, mas o princípio é o velho — sem registro do comportamento, você não detecta o abuso.

Fechando o ciclo#

Logging de segurança não é uma tarefa que se marca como concluída; é uma capacidade que se mantém. Comece definindo, com o time, a lista de eventos de segurança que importam no seu domínio e garanta que cada um gera registro estruturado, com identidade verificada e correlação. Elimine, por revisão de código e por teste, qualquer segredo ou PII desnecessária que esteja vazando para os logs. Centralize num destino imutável que o comprometimento de um servidor não alcança. Construa detecção calibrada para ser rara e acionável, não um dilúvio que o time aprende a ignorar. E, periodicamente, ataque o próprio sistema e confira se você viu — porque a única coisa pior do que ser invadido é ser invadido e não saber. O log que ninguém lê e o alerta que ninguém atende custam o mesmo que não ter nenhum; a diferença entre uma trilha de auditoria e um passivo de armazenamento está inteiramente no processo que você constrói em volta dela.