Invasões descobertas meses depois raramente falham por falta de ferramenta. Falham porque o evento decisivo nunca foi registrado, ou porque o log que continha a prova morava no próprio servidor comprometido e desapareceu junto com ele. O playbook Secure by Design and Default publicado pela ENISA coloca o registro de eventos no mesmo patamar de autenticação e criptografia: é princípio de projeto, não tarefa acessória de operações. Para equipes defensivas, o documento funciona como critério objetivo de prontidão — sistema que não gera os eventos mínimos, não os centraliza e não os protege contra manipulação não está pronto para produção. A ação prioritária é auditar quais eventos essenciais existem no seu ambiente hoje e fechar as lacunas antes de investir em novas camadas de deteção.
O princípio do ENISA
A regra central do capítulo de logging é enxuta: segurança depende de visibilidade. Sistemas devem gerar logs de segurança relevantes, com retenção definida e proteção contra adulteração, para sustentar investigações e obrigações regulatórias. O foco declarado do documento está num conjunto pequeno de eventos de alto sinal, em retenção confiável e em alertas que não saturem a equipe — não em coletar o máximo possível.
Essa inversão importa porque o erro mais comum de monitoramento é o oposto: ingestão gigante, custo alto e nenhum alerta sobre o qual alguém consiga agir. O playbook também fixa um limite de bom senso: não registrar dados pessoais nem segredos por padrão. No nível padrão de log, grave o mínimo necessário para entender o evento e eleve o nível de detalhe apenas onde houver necessidade documentada. Menos volume significa menos custo de armazenamento, menos risco de vazamento pelos próprios logs e menos ruído na triagem.
Eventos que não faltam
A lista de eventos obrigatórios do playbook cobre quatro famílias de risco:
| Família | O que registrar | Por que importa |
|---|---|---|
| Autenticação | Sucesso e falha de login, eventos de MFA, emissão, renovação e revogação de tokens | Roubo de credencial e de token é a forma mais comum de acesso inicial |
| Autorização | Acesso negado, mudanças de papel e privilégio, ações administrativas | Escalonamento de privilégio transforma acesso pontual em controle duradouro |
| Fronteira | Chamadas externas de API, pareamento de dispositivos, eventos de atualização | Movimento lateral e exfiltração passam por esses pontos de passagem |
| Mudanças | Alterações de configuração, trocas de chave e segredo, contas habilitadas ou desabilitadas | Persistência do invasor quase sempre deixa rastro aqui |
Duas exigências acompanham a tabela. A primeira é atribuição: toda ação administrativa precisa ser atribuível a uma identidade nomeada, sem contas compartilhadas — se o registro aponta apenas para um usuário genérico de administração, ele não sustenta nenhuma investigação. A segunda é estrutura: campos consistentes de quem (ator), o quê (tipo de evento) e quando (marca de tempo), com contexto adicional onde fizer sentido. Quem já reduz privilégios em ambientes orquestrados encontra aqui o complemento natural — papel enxuto só vira controle auditável quando a consulta aparece no log, como detalhamos no guia de RBAC no Kubernetes.
Centralizar e proteger
Log que só existe na máquina de origem não é evidência: é vantagem tática do invasor. O playbook determina coleta centralizada em plataforma dedicada (SIEM ou serviço gerenciado), separação por tipo ou serviço, restrição de acesso com segregação de funções e permissões de somente escrita onde for viável. Alvos de retenção explícitos — a sugestão do documento usa 30 ou 90 dias, mais para material de arquivo — permitem dimensionar armazenamento sem improviso no meio do incidente.
Sem sincronia de tempo a correlação entre fontes desmorona: o checklist exige NTP em todos os sistemas. A integridade também é critério de liberação, não só de operação — logs centralizados, com acesso restrito, retenção configurada e sincronia verificada fazem parte do portão de qualidade do próprio produto. A evidência mínima que o documento pede é honesta com o tamanho da equipe: uma página listando os eventos obrigatórios, uma prova de que os logs chegam ao repositório central, a configuração de retenção e a política de acesso documentadas.
Alertas de alta confiança
A recomendação mais prática do documento é dimensionar o alerta de baixo: comece com um catálogo inicial pequeno de alertas, na casa de 5 a 10 regras de alta confiança, cada uma com limite e responsável definidos. O conjunto inicial sugerido cobre falhas repetidas de autenticação, criação de novo administrador, escalonamento de privilégio, picos anormais de erros de API, falhas de atualização, desligamento de logging e acesso a pontos sensíveis a partir de localidades novas.
Depois de ligar as regras, o trabalho vira afinação: limites por taxa, janelas de supressão e filtros por ambiente para reduzir ruído sem cegar a deteção. O ciclo se fecha com o lado humano — plantão definido, um runbook de triagem em uma página cobrindo validar, dimensionar, conter, remediar e comunicar, e exercício trimestral de um cenário comum, como tomada de conta ou vazamento de chave de API. A rotina de treino que prova a resposta a incidentes já foi tema aqui no portal e é a peça que impede o runbook de virar papel.
O que o NIST acrescenta
Para quem precisa planejar a mudança em escala, a referência complementar vem do NIST. A revisão preliminar do guia de log management substitui a publicação original do SP 800-92, lançada em 2006, e organiza o esforço em quatro jogadas: inventário de necessidades, definição do estado-alvo, documentação de lacunas com causa raiz e plano de mitigação. A definição do documento cabe em uma linha: gerir logs é gerar, transmitir, armazenar, acessar e descartar os dados — cada verbo é uma etapa que pode falhar em silêncio.
Plano de adoção priorizado
- P1 — próximos 30 dias: confirmar que os eventos da tabela acima chegam ao repositório central a partir dos componentes críticos; atribuir um responsável a cada alerta existente; escrever a lista de eventos obrigatórios em uma página.
- P2 — no trimestre: reduzir o catálogo às 10 regras de maior confiança e afiná-las com limites e supressão; configurar retenção e política de acesso aos logs; rodar o primeiro exercício de triagem e registrar o resultado.
O portão de liberação do playbook resume o aceitável: eventos obrigatórios implementados em componentes novos ou alterados, logs com campos de atribuição centralizados, acesso restrito, sincronia de tempo verificada, alertas de alto sinal com dono definido e runbook testado — e exceções documentadas, com responsável e data de revisão. Se o seu serviço não passa nesse portão, a lacuna não é de deteção avançada; é de engenharia básica de gestão de logs de segurança, e é a mais barata de fechar.