Os logs de segurança permitem reconstruir ações, detetar comportamentos anómalos e investigar incidentes. Para serem úteis, precisam de eventos adequados, relógios coerentes, proteção contra alterações e pessoas responsáveis por analisar os alertas. Acumular todos os registos disponíveis cria custos e exposição de dados sem garantir que a organização consegue responder a uma pergunta simples: quem acedeu a determinado recurso e o que fez?
Este guia ajuda a construir uma matriz de fontes, eventos, acessos e conservação. O resultado é uma política de registos ligada à política de segurança da informação, com exemplos de configuração e critérios de aceitação. As escolhas quantitativas dos exemplos são hipotéticas; cada organização deve justificá-las pelas suas necessidades e pelas regras aplicáveis.
Começar pelas perguntas de segurança
Defina o que pretende conseguir detetar ou investigar. Pode ser a utilização de uma conta privilegiada fora do contexto habitual, a alteração de permissões, uma exportação de dados de clientes ou a desativação de uma proteção. Para cada pergunta, identifique os sistemas que produzem a evidência e os campos necessários para interpretar o evento.
A cartografia dos sistemas ajuda a ligar autenticação, aplicação, base de dados e serviço de partilha. Uma ação iniciada num portal pode gerar registos em vários componentes. Se cada um usar um identificador incompatível e um relógio diferente, a equipa terá dificuldade em reconstruir a sequência mesmo dispondo de muitos ficheiros.
Os registos também podem conter dados pessoais: identificadores de contas, endereços IP, recursos consultados e horários. Aplicam-se os princípios e requisitos pertinentes do RGPD, incluindo finalidade, minimização, conservação e segurança. O artigo 32.º sustenta a necessidade de medidas adequadas, sem definir um prazo único para todos os logs. RGPD, artigos 5.º e 32.º.
Escolher eventos e campos com utilidade demonstrável
Uma linha de registo deve permitir compreender o evento sem copiar desnecessariamente o conteúdo tratado. Os campos úteis podem incluir instante, sistema de origem, identificador da conta, ação, recurso, resultado e identificador de correlação. A necessidade de cada campo depende da operação e do cenário investigado.
| Fonte | Evento selecionado | Campos úteis no exemplo |
|---|---|---|
| Serviço de identidade | Entrada falhada e alteração de MFA | Conta, instante, resultado, origem e tipo de alteração |
| Aplicação de clientes | Exportação de registos | Utilizador, conjunto lógico, volume e resultado |
| Administração | Atribuição de privilégio | Autor da mudança, conta afetada e perfil atribuído |
| Partilha de ficheiros | Criação de ligação externa | Autor, recurso, modalidade de acesso e validade |
| Proteção do equipamento | Desativação ou falha | Equipamento, controlo afetado, instante e estado |
Não registe palavras-passe, códigos de recuperação, tokens de sessão completos ou números de cartão completos. Evite copiar o corpo de pedidos que possam conter dados de saúde ou documentação de clientes. Se um identificador interno permite localizar o recurso com autorização, pode ser suficiente para o evento de segurança.
A revisão deve abranger também mensagens de erro. Uma aplicação pode ocultar dados na interface e, ao mesmo tempo, gravá-los integralmente num ficheiro de diagnóstico. Peça um exemplo de erro com dados de ensaio e verifique o resultado efetivo, incluindo registos produzidos por bibliotecas e integrações.
Centralizar sem perder a origem
A centralização permite consultar e correlacionar eventos de vários sistemas e reduz a dependência do equipamento que os produziu. A ANSSI descreve esta arquitetura no seu guia de registo de eventos, incluindo a proteção da recolha e do armazenamento. É uma referência técnica francesa, não uma obrigação portuguesa universal. ANSSI: arquitetura de um sistema de registos.
Mantenha informação suficiente sobre a origem, a receção e eventuais transformações do evento. A normalização pode facilitar pesquisas, mas não deve alterar silenciosamente o significado de um campo. Se for necessário preservar uma versão original, defina o acesso e a conservação dessa cópia, evitando criar um arquivo paralelo sem controlo.
Proteja o transporte dos registos e autentique as fontes quando a arquitetura o permita. Verifique como o sistema reage a uma quebra de ligação: guarda eventos localmente, volta a enviá-los e identifica duplicados? Uma falha de comunicação não deve produzir a falsa conclusão de que não ocorreram eventos naquele período.
Sincronização, integridade e capacidade
Escolha uma referência temporal coerente e mantenha informação sobre o fuso quando necessária. Nos relatórios, distinga a hora em que a ação ocorreu da hora em que o coletor recebeu o evento. Uma fila de envio atrasada pode explicar diferenças que, de outra forma, parecem uma sequência impossível.
Os utilizadores cujas ações são registadas não devem conseguir apagar livremente a única evidência dessas ações. Separe permissões de administração do serviço e de gestão dos registos conforme o risco. Proteja os mecanismos de exportação e acompanhe alterações de configuração que possam interromper a recolha.
A capacidade do armazenamento também é uma condição de integridade. Defina alertas de espaço, limites de filas e rotação. Teste o que acontece quando o destino fica indisponível ou o volume cresce inesperadamente. Não basta receber um alerta depois de o disco cheio já ter impedido a aplicação principal de funcionar.
Definir conservação por categoria
A tabela de conservação de dados deve distinguir logs de segurança, diagnóstico temporário e extratos preservados para um incidente concreto. Uma necessidade de investigação não justifica automaticamente conservar todos os campos durante o mesmo período. Comece pela finalidade e pela janela em que o evento é útil, verificando obrigações específicas.
Como referência estrangeira, a CNIL recomenda geralmente uma janela de seis meses a um ano para certos registos, admitindo circunstâncias específicas que exigem análise própria. Esse intervalo não é um prazo legal geral para organizações portuguesas. Se for usado como ponto de comparação, documente por que razão corresponde ou não ao seu tratamento. CNIL: registar as operações.
No exemplo hipotético de uma aplicação, os diagnósticos detalhados são ativados apenas durante a resolução de uma falha e têm uma janela curta, enquanto eventos selecionados de acesso administrativo são conservados por um período maior fundamentado na investigação de incidentes. A decisão identifica os campos, a finalidade e o mecanismo de eliminação de cada grupo. Não se limita a duplicar o prazo de conservação dos dados da aplicação.
Separar operação corrente e preservação de incidente
Quando um incidente justifica preservar determinados eventos, delimite contas, sistemas e período. Registe o motivo, quem autorizou a extração, onde fica o conjunto e quando será reavaliado. A preservação não deve suspender sem necessidade a eliminação de todos os logs da organização.
A cópia de investigação pode exigir controlos de integridade e uma cadeia de custódia adequada ao uso previsto. Registe as operações relevantes e evite circular o ficheiro por correio eletrónico entre todos os participantes. A cifragem e gestão de chaves ajuda a proteger os extratos sem perder a possibilidade de recuperação autorizada.
A conclusão do incidente deve desencadear uma revisão das cópias. É frequente resolver a falha principal e deixar conjuntos completos em portáteis ou pastas temporárias. O responsável pelo incidente deve confirmar o destino das evidências, distinguindo o que ainda precisa de ser conservado do material de trabalho dispensável.
Criar alertas que alguém consegue tratar
Um alerta precisa de condição, destinatário, prioridade e ação inicial. “Enviar email sempre que há uma falha de autenticação” pode criar ruído excessivo. A organização deve calibrar o evento pelo contexto, combinando sinais quando isso ajuda a distinguir uma tentativa normal de um comportamento suspeito.
Exemplo preenchido: “Alerta quando uma conta administrativa altera a configuração de autenticação de outra conta privilegiada. Destinatário: responsável de segurança e substituto. Primeira verificação: existência de pedido autorizado, conta que executou a ação e sessão associada. Se não houver confirmação, seguir o procedimento de incidente.” A condição é um exemplo de desenho, não uma regra suficiente para todos os ambientes.
A política de autenticação fornece o contexto para avaliar estes eventos. A revisão de alertas deve analisar falsos positivos e falhas de deteção. Silenciar permanentemente um alerta incómodo sem entender a causa pode esconder justamente o comportamento que o controlo pretendia encontrar.
Limitar acessos e explicar o tratamento aos trabalhadores
Defina perfis de consulta, pesquisa, exportação e alteração de regras. Um analista pode precisar de pesquisar eventos de segurança sem poder descarregar todo o histórico de atividade. O acesso excecional a conteúdo ou informação mais detalhada deve ter uma finalidade e autorização identificáveis.
Os trabalhadores devem receber informação adequada sobre os tratamentos que lhes dizem respeito. Logs criados para segurança não devem ser reutilizados automaticamente para classificar produtividade. A avaliação de controlo do teletrabalho ajuda a distinguir segurança e vigilância individual no contexto português, sobretudo quando a ferramenta oferece funcionalidades adicionais de monitorização.
A classificação dos endereços IP como dados pessoais também importa quando os registos são partilhados com fornecedores. Antes de enviar um conjunto para apoio técnico, confirme quais os campos necessários e quem os recebe. O pedido de diagnóstico não autoriza uma exportação indiferenciada de todas as ações dos utilizadores.
Verificar o percurso completo com um ensaio
Utilize contas e dados de ensaio para executar uma ação relevante, como atribuir e retirar um privilégio. Confirme que o evento aparece na origem, chega ao coletor, mantém os campos essenciais e pode ser encontrado pelo analista autorizado. Compare o instante e o resultado com o que realmente aconteceu.
Depois teste um caso negativo: um utilizador sem permissões não consegue consultar ou apagar esses registos. Simule também uma interrupção da recolha e confirme se a equipa recebe o aviso esperado. Finalmente, verifique a expiração de uma categoria com prazo curto, assegurando que o evento não permanece numa cópia esquecida.
O registo de aceitação deve descrever o resultado observado e a correção necessária. Uma política de logs fica utilizável quando a organização consegue produzir a evidência adequada, interpretá-la e eliminá-la no momento previsto. Mantenha essa verificação ligada às alterações das aplicações e à revisão da arquitetura de recolha.