Retenção de registos de VPN: ligue-a ao incidente, não a um número
A retenção segue o incidente, o conteúdo e a política, não um prazo universal. Encontre cada cópia, pare a recolha detalhada e mantenha um registo breve.
Ninguém pergunta realmente quanto tempo guardar um registo de VPN; perguntam para que serve o registo, e a resposta a isso define a data. De um incidente podem sair dois ficheiros com vidas diferentes, e tratá-los como uma única política produz tanto retenção excessiva como perda de provas. Uma exportação de depuração capturada enquanto a causa era desconhecida não é o mesmo artefacto que uma linha num armazém de monitorização. Comece pelo objetivo e só depois escolha a data.
Responda a quatro perguntas antes de escolher uma data
Quatro perguntas decidem se um ficheiro fica: o incidente ainda está aberto, o que contém o ficheiro, quem precisa de o ler e o que exige a política aplicável. Responda por essa ordem e a data de retenção sai sozinha. O raciocínio cabe numa tabela:
| Question | How it moves the answer |
|---|---|
| Incident state | An open investigation justifies a protected original; a closed one rarely does |
| Content | Connection identifiers, internal names and addresses raise the cost of a leak |
| Audience | Who retrieves it, and whether a redacted excerpt would serve them instead |
| Policy floor | The applicable service or organizational rule, which overrides a shorter reasoning |
Enquanto o incidente estiver aberto, guarde um original protegido para poder comparar eventos ou responder mais tarde a uma pergunta de suporte, e atribua-lhe um proprietário e um objetivo por escrito. Para quem está fora da equipa de resposta, um extrato curto e expurgado costuma bastar, e é muito mais fácil de defender do que a exportação completa. O original e o extrato são artefactos separados com públicos separados, e é a sua fusão que cria tanto retenção excessiva como perda de provas. A política fixa um mínimo, por isso se exigir mais tempo do que o seu raciocínio, ganha a política.
Feche o incidente com um registo, não com uma exportação
Escreva no ticket um registo de quatro linhas: o sintoma, o cliente e a versão, a única linha de erro que o identificou e a correção. Não anexe mais nada, porque a exportação era para si e o registo é para a próxima pessoa.
O registo também tem mais probabilidade de ser lido: a exportação completa serve sobretudo quem a capturou, e essa pessoa já sabe o que aconteceu. Guarde o registo onde o próximo incidente será procurado, o que normalmente significa o ticket e não uma pasta com o nome de uma data. Um número de caso pode transportar a referência se o registo tiver de ser rastreável sem expor um identificador de ligação. Se ainda houver uma pergunta aberta, o original fica sob a regra da cópia protegida acima; assim que o registo exista, tudo o resto pode ir.
Encontre cada cópia antes de apagar uma
Veja na pasta de exportação, depois no diário da janela do incidente, depois nos anexos do ticket, depois no catálogo de cópias de segurança, depois no armazém de monitorização. Se o mesmo identificador de ligação aparecer num quinto local, o inventário estava errado. O diário é a surpresa habitual, porque continuou a recolher enquanto lia a exportação.
Use o caminho de rotação e eliminação suportado em vez de desassociar ficheiros à mão. Um ficheiro que ainda está aberto mantém o seu armazenamento depois de a entrada de diretório desaparecer, por isso a eliminação parece completa e não liberta nada. Isso é um defeito de armazenamento com etiqueta de privacidade, e não satisfaz nenhum dos dois objetivos.
Pare a recolha antes de verificar a eliminação
Pare a recolha detalhada temporária através da aplicação que a possui, não editando o seu ficheiro de saída. Uma definição de depuração esquecida continua a escrever registos novos depois de os antigos serem removidos, o que desfaz silenciosamente o trabalho que acabou de fazer. Verifique o nível de registo efetivo e não o valor que se lembra de ter definido. Depois confirme que o que resta está protegido e que só as pessoas previstas o podem obter.
O princípio é a minimização de dados: guarde o que um objetivo declarado exige, durante o tempo que for necessário, e nada mais, como o orientações de privacidade RFC 6973 formulam. Um ficheiro guardado sem objetivo é uma responsabilidade com um carimbo temporal. A decisão está concluída quando consegue nomear o ficheiro, o objetivo, o proprietário e a data de fim.