A 21 de outubro, quando o PHP2Shell se tornou público, a equipa de threat intelligence da Amazon publicou uma linha que qualquer incident responder deveria ter lido duas vezes: investigar a partir de, pelo menos, 17 de outubro. Quatro dias antes da divulgação.
Fica aqui uma questão para a sua equipa. Ainda tem os registos do servidor web de 17 de outubro?
Se rodarem a cada sete dias, a resposta honesta à pergunta «fomos comprometidos antes de alguém saber?» é «nunca iremos descobrir».
Agora pergunte ao seu DPO durante quanto tempo deve conservar esses registos. A resposta será diferente. Estão cheios de endereços IP, identificadores de utilizador, dados de sessão, por vezes corpos de pedido completos. Dados pessoais, conservados para uma finalidade de segurança que ninguém registou por escrito, durante um período que ninguém escolheu.
Os mesmos registos, duas pessoas, dois receios. Ambos legítimos.
Dois dogmas à mesma mesa
O dogma da segurança: registar tudo, conservar para sempre, o armazenamento é barato e nunca se sabe. Vem de uma ferida real. Qualquer incident responder já chegou ao beco sem saída em que o rasto termina porque os registos rodaram na semana anterior.
O dogma da privacidade: registar o mínimo possível, durante o mínimo de tempo possível. Também uma ferida real. Um repositório de registos que guarda tudo sobre todos indefinidamente torna-se uma base de dados de vigilância e um dos alvos mais atrativos da organização. A CNIL identificou esse risco exato nas suas orientações: volumes de dados de registo suficientemente grandes para serem atacados ou utilizados para finalidades que ninguém previu.
Cada lado tem razão quanto ao seu próprio risco. Nenhum funciona como padrão. «Para sempre» não é um período de retenção, e «o mínimo possível» também não.
Nota: Na prática, raramente há uma segunda pessoa nessa mesa. Nas auditorias ISO 27001 que conduzo, o DPO quase nunca é consultado sobre o logging. Surpreende-me sempre, e é uma das não conformidades menores que levanto com maior frequência. A equipa de segurança define um período de retenção, a ferramenta aplica-o, e a pessoa cujo trabalho é perguntar «porque guardamos isto?» fica a saber na auditoria. O Artigo 38.º do GDPR já exige que o DPO seja envolvido, de forma adequada e atempada, em todas as questões relacionadas com dados pessoais. Os registos são uma delas.
O que os textos dizem de facto
Eis o que quebra o impasse. Nenhum regulamento fornece um número universal. E todos exigem o mesmo.
O GDPR exige minimização de dados e limitação da conservação. Requer também segurança adequada ao abrigo do Artigo 32.º, e o Considerando 49 reconhece o tratamento estritamente necessário e proporcionado para a segurança das redes e da informação como um interesse legítimo. O logging é, portanto, lícito. O logging sem uma finalidade definida é onde surgem os problemas.
A recomendação da CNIL de 2021, uma das orientações mais detalhadas de um regulador sobre o tema, prevê seis meses a um ano para registos aplicacionais que rastreiam quem acedeu e alterou o quê. Períodos mais longos são possíveis com justificação, até três anos nos casos comuns. Quando os dados subjacentes são conservados por menos de seis meses, os registos não devem transportar esses dados pessoais. E exclui explicitamente do seu âmbito os registos de perímetro, provenientes de firewalls e equipamentos de rede. Quase todos os que citam «seis meses» ignoram essa parte.
O Regulamento de Execução NIS2 2024/2690, para os fornecedores de infraestruturas e serviços digitais que abrange, exige uma lista de ativos a registar baseada no risco, revisão regular, proteção contra adulteração e retenção por um período predefinido. Sem mínimo definido. As orientações de implementação da ENISA acrescentam depois duas linhas: eliminar quando o período de retenção terminar, e não conservar nos registos dados cujo próprio período de retenção expirou.
Leia de novo. O regulador de segurança está a dizer o mesmo que o regulador de privacidade.
O AI Act define um mínimo em vez de um máximo. Os utilizadores de sistemas de alto risco terão de conservar os registos gerados por esses sistemas durante pelo menos seis meses.
O PCI DSS exige doze meses de histórico, três dos quais imediatamente disponíveis. Um número contratual, não legal.
Cinco fontes, cinco respostas, uma exigência comum: um período definido, associado a uma finalidade, registado por escrito.
Decidir por finalidade
O erro habitual é definir a retenção por ferramenta. «O SIEM guarda 90 dias» é uma decisão de licenciamento disfarçada de decisão de segurança.
Defina-a por finalidade.
Deteção necessita de dados recentes e pesquisáveis. Semanas, em camada quente.
Investigação necessita de histórico suficiente para cobrir o tempo que realisticamente demora a detetar um comprometimento, acrescido da janela pré-divulgação que o PHP2Shell acabou de demonstrar. Deteção lenta implica retenção longa. Esta é a troca honesta.
Responsabilização por acessos privilegiados necessita de um rasto mais longo, porque «quem fez isto, e estava autorizado?» surge habitualmente meses depois.
Obrigações legais e contratuais definem o seu próprio mínimo. Cumpre-o.
Um registo pode servir várias finalidades. A sua retenção é definida pela finalidade mais exigente que consegue efetivamente justificar, e não pela que preferiria ter.
Três alavancas que dissolvem a maior parte do conflito
A retenção é um dos controlos. A maior parte do conflito desaparece quando se utilizam os outros dois.
Conteúdo. Registe o evento, omita os dados. Quem, que ação, quando, qual a referência do registo. Omita o registo em si, o corpo do pedido, o campo de formulário onde alguém inseriu uma palavra-passe por engano. Os registos verbose e de debug são onde os dados pessoais escapam para lugares que ninguém governa; atribua-lhes uma vida medida em dias.
Camadas. Uma camada quente curta para deteção. Uma camada fria mais longa para investigação, cifrada e de acesso mais restrito. Um arquivo restrito para os rastos cuja conservação por anos está justificada. A cada descida de nível, menos pessoas podem aceder.
Acesso. O seu repositório de registos pode muito bem ser o registo mais completo de atividade pessoal na organização. Trate-o como tal. Funções nomeadas, acesso aos próprios registos registado, e administradores que não possam editar silenciosamente o seu próprio rasto.
E um limite a não ultrapassar. Um registo de segurança é recolhido para fins de segurança. No dia em que for utilizado num processo disciplinar sem base legal autónoma e transparência adequada, alterou a sua finalidade, e em vários países trouxe também a comissão de trabalhadores para a sala.
Uma tabela de retenção de exemplo
Adapte-a à sua avaliação de risco e à legislação nacional aplicável. É um ponto de partida, e ilustra o raciocínio que precisará de documentar.
| Tipo de registo | Finalidade | Retenção de exemplo | Justificação |
|---|---|---|---|
| Firewall, proxy, DNS, VPN | Deteção, investigação | 12 meses, 90 dias em camada quente | Cobre janelas de deteção tardia e de exploração pré-divulgação |
| Autenticação (SSO, diretório, MFA) | Deteção, investigação de comprometimento | 12 meses | O comprometimento de contas raramente se anuncia no primeiro dia |
| Ações privilegiadas e de administração | Responsabilização, controlo interno | Até 3 anos, acesso restrito | Necessidade de controlo interno documentada, dentro do limite máximo da CNIL |
| Acesso aplicacional a dados pessoais | Rastreabilidade | 6 a 12 meses | Intervalo de referência da CNIL |
| Aplicações com dados de curta duração | Rastreabilidade | 6 a 12 meses, sem os dados pessoais em si | Os registos não devem sobreviver aos dados que descrevem |
| Registos debug e verbose de aplicações | Resolução de problemas | Dias a semanas | Sem finalidade além da correção do problema |
| Ambiente de pagamento por cartão | PCI DSS | 12 meses, 3 em linha | Requisito contratual |
Registar a decisão por escrito
No controlo A.8.15, o auditor perguntará durante quanto tempo conserva os seus registos. Os melhores perguntam depois porquê.
A resposta tem de existir antes da pergunta. Uma política de logging com a tabela de retenção e a respetiva justificação. Uma avaliação de interesse legítimo para o próprio logging. O logging listado no seu registo das atividades de tratamento, porque é uma atividade de tratamento. A opinião do DPO em arquivo. Um responsável nomeado. Uma data de revisão.
Esse conjunto de documentos é o que transforma um dogma numa decisão. A segurança obtém o rasto de que necessita. A privacidade obtém uma finalidade, um limite e uma data de eliminação. E quando alguém questiona qualquer um dos lados, há uma assinatura no fundo.
Nota Final
O conflito entre «guardar tudo» e «não guardar nada» costuma terminar com quem argumenta mais alto, e o período de retenção acaba por ser o que a ferramenta trazia de origem.
Nenhum dos regimes o deixa sair assim tão facilmente. Ambos querem ver que alguém analisou a finalidade, escolheu um número e registou o motivo.
Demora uma tarde. Poupa-lhe duas conversas: explicar a uma empresa de incident response que os registos de que precisava foram eliminados por defeito, e explicar a uma autoridade de proteção de dados por que conservou sete anos de tudo.
Ambos os lados desta questão estão presentes em dois dos nossos cursos. ISO 27001 Lead Implementer aborda o logging e a monitorização enquanto controlos que pode evidenciar em auditoria. ISO 27701 Lead Implementer aborda o lado da privacidade: finalidade, retenção e os registos que as justificam.