Uma equipa que só coleta logs, mas não consegue reconstruir uma autenticação, uma alteração de privilégio ou uma exportação de dados, tem armazenamento e não tem capacidade de investigação. O problema afeta empresas com aplicações próprias, serviços em nuvem e identidades distribuídas; a ação prioritária é definir os eventos que sustentam decisões de segurança, centralizá-los com horário confiável e testar uma investigação antes de ampliar o volume coletado.
Comece pela decisão
O desenho do registro deve partir das perguntas que a defesa precisa responder. Em vez de começar pela ferramenta, documente pelo menos cinco decisões: quem autenticou; o que essa identidade tentou fazer; qual recurso foi atingido; se a ação foi permitida ou negada; e que mudança ocorreu depois. Essa abordagem evita o erro de considerar um arquivo cheio de requisições como evidência suficiente.
Para uma conta privilegiada, por exemplo, a equipa deve conseguir relacionar login, segundo fator, emissão ou renovação de sessão, elevação de função, alteração de política, criação de credencial e acesso a dados. Para uma aplicação, precisa distinguir falha de autenticação, mudança de endereço de e-mail, redefinição de senha, alteração de autorização, exportação e exclusão. Sem essa sequência, o analista pode ver eventos isolados, mas não consegue estabelecer uma linha do tempo.
A orientação do NIST sobre gestão de logs trata o tema como uma capacidade empresarial: infraestrutura, processos, retenção e manutenção precisam funcionar juntos. Portanto, o inventário de fontes deve ser acompanhado por um proprietário, um objetivo de detecção e um prazo mínimo de disponibilidade para cada conjunto.
Fontes que não podem faltar
Priorize as fontes que representam fronteiras de confiança. O provedor de identidade deve registrar autenticações bem-sucedidas e falhas, método usado, aplicação, dispositivo, endereço de rede, resultado de políticas, alterações de fatores, consentimentos delegados, criação de chaves e mudanças de grupos. Em nuvem, inclua o plano de controle: criação, alteração e exclusão de recursos; mudanças de IAM; acesso a cofres; alterações de regras de rede; e ações feitas por contas de serviço.
Na aplicação, não dependa apenas do servidor web. O código conhece o usuário, a função, o objeto acessado e o resultado da autorização. A Logging Cheat Sheet da OWASP recomenda registrar eventos de segurança na própria aplicação, porque essa informação frequentemente não aparece nos dispositivos de infraestrutura. Registre também falhas de validação relevantes, uso anormal de funções administrativas, alterações de dados sensíveis e exportações.
Complete o conjunto com logs de gateway, WAF, DNS, endpoint, banco de dados, ferramenta de CI/CD, armazenamento de objetos, VPN e cópias de segurança. Não é necessário enviar tudo para o mesmo índice com a mesma retenção. Eventos de auditoria, depuração, desempenho e segurança possuem finalidades diferentes; misturá-los aumenta custo e dificulta a triagem.
| Área | Eventos prioritários | Uso defensivo |
|---|---|---|
| Identidade | Login, MFA, sessão, fator, grupo e consentimento | Detectar tomada de conta e abuso de privilégio |
| Nuvem | IAM, chaves, rede, cofres e plano de controle | Reconstruir mudanças e persistência |
| Aplicação | Autorização, exportação, alteração e exclusão | Identificar abuso de função e impacto |
| Resiliência | Backup, restauração, retenção e falhas | Detectar sabotagem antes do incidente de extorsão |
Padronize o evento
Um evento útil precisa ter identidade e contexto, não apenas uma mensagem textual. Adote campos consistentes para horário em UTC, fonte, ambiente, serviço, identificador de correlação, ator, tipo de ação, alvo, resultado, endereço de origem, dispositivo e motivo da decisão. Diferencie usuário humano, conta de serviço, função assumida e processo automatizado. Preserve o identificador original do provedor para permitir consulta no sistema de origem.
O horário deve ser comparável entre fontes. Verifique sincronização, registre o fuso quando a origem não puder usar UTC e documente a precisão conhecida. Uma diferença de minutos entre provedor de identidade, aplicação e banco pode inverter a ordem dos acontecimentos. O identificador de correlação ajuda a seguir uma requisição entre serviços, mas não substitui o identificador da sessão ou da transação.
Evite colocar senhas, tokens, chaves privadas, códigos de autenticação ou dados pessoais desnecessários no registro. Mascaramento e redução de dados não podem apagar o contexto indispensável à investigação. Controle acesso aos logs com privilégios separados dos administradores da aplicação e proteja a coleta contra alterações, exclusão e interrupção deliberada. O próprio canal de registro é uma superfície de ataque.
Transforme logs em detecção
Uma regra de detecção deve ter hipótese, fontes, janela, limiar, responsável e ação. “Login fora do país” isoladamente produz ruído e pode refletir uma rede corporativa. Uma combinação é mais defensável: autenticação por dispositivo novo, seguida de alteração de fator, criação de consentimento e acesso volumoso a arquivos em curto intervalo. A análise anterior do portal sobre roubo de sessões mesmo com MFA mostra por que a equipa deve observar o que acontece depois do login, não apenas se o segundo fator foi aprovado.
Para privilégios, alerte quando uma identidade não administrativa criar outra conta privilegiada, quando uma função sensível for assumida fora da janela esperada ou quando uma chave permanecer ativa após a remoção do responsável. Para aplicações, acompanhe aumento de negações de autorização, redefinições de senha, chamadas a endpoints administrativos, exportações raras e mudanças seguidas de leitura em massa.
O alerta não é o fim do processo. Cada regra deve apontar para um procedimento: validar o ator, preservar registros, revogar sessão ou credencial quando houver risco, delimitar o período afetado e identificar recursos acessados. Meça tempo até a triagem, cobertura das fontes, falsos positivos e a capacidade de reproduzir uma investigação. Regras sem proprietário envelhecem rapidamente.
Retenção e teste
Defina retenção por risco, obrigação e utilidade investigativa. Logs de autenticação e plano de controle merecem prioridade porque sustentam reconstruções de identidade e mudança. Dados de depuração podem ter prazo menor, desde que a redução não remova evidência necessária. Separe armazenamento quente para consulta rápida de armazenamento de longo prazo, controle a expiração e registre quem alterou a política.
Faça um teste mensal com um cenário pequeno: uma conta de teste acessa um serviço, altera uma permissão e executa uma ação sensível. Confirme se todas as etapas aparecem, se os horários concordam, se o alerta dispara, se o analista encontra o evento e se o procedimento consegue revogar o acesso. Faça também um teste de indisponibilidade da coleta. O ambiente deve indicar a perda de telemetria; silêncio não pode ser interpretado como ausência de ataque.
Proteja o caminho de ingestão com filas ou armazenamento temporário quando uma fonte perder conectividade. Monitore volume, atraso, taxa de erro e lacunas por origem. Um atacante pode tentar inundar o coletor para esconder ações, enquanto uma falha operacional pode produzir o mesmo sintoma. A resposta precisa tratar ambos como incidentes de observabilidade até que a causa seja conhecida.
Plano de execução
P1 — próximos sete dias: inventarie fontes de identidade, nuvem e aplicações críticas; escolha cinco eventos indispensáveis por fonte; confirme sincronização de horário; remova segredos dos registros; restrinja acesso; e crie uma consulta para autenticação seguida de mudança de privilégio ou exportação.
P2 — próximos 30 dias: padronize o esquema, atribua proprietários, configure retenção por risco, monitore falhas de coleta, incorpore contas de serviço e exercite um caso de comprometimento. Compare o resultado com o inventário de ativos. Uma fonte que existe no desenho, mas não entrega eventos durante o teste, não deve ser marcada como coberta.
Logs não substituem prevenção, autenticação resistente a phishing, segmentação ou backups testados. Eles permitem decidir com evidência quando esses controles falham. A medida de maturidade não é o número de gigabytes armazenados, mas a resposta a uma pergunta operacional: a equipa consegue dizer quem fez o quê, em qual recurso, quando, com que resultado e qual ação deve ocorrer agora?