Retención dos rexistros de VPN: átala ao incidente, non a un número
A retención segue o incidente, o contido e a política, non un prazo universal. Atopa cada copia, detén a recollida detallada e mantén un rexistro breve.
Ninguén pregunta en realidade canto tempo conservar un rexistro de VPN; preguntan para que serve o rexistro, e a resposta a iso fixa a data. Dun só incidente poden saír dous ficheiros con vidas distintas, e tratalos como unha única política produce á vez retención excesiva e perda de probas. Unha exportación de depuración capturada mentres a causa era descoñecida non é o mesmo artefacto que unha liña nun almacén de monitorización. Comeza polo propósito e despois escolle a data.
Responde catro preguntas antes de escoller unha data
Catro preguntas deciden se un ficheiro queda: se o incidente segue aberto, que contén o ficheiro, quen necesita lelo e que esixe a política aplicable. Respóndeas nesa orde e a data de retención sae soa. O razoamento cabe nunha táboa:
| 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 |
Mentres o incidente está aberto, conserva un orixinal protexido para poder comparar eventos ou responder a unha pregunta de soporte máis adiante, e dálle un propietario e un propósito por escrito. Para calquera persoa fóra do equipo de resposta adoita abondar un extracto breve e redactado, e é moito máis fácil de defender que a exportación completa. O orixinal e o extracto son artefactos separados con públicos separados, e fusionalos é o que crea á vez retención excesiva e perda de probas. A política fixa un mínimo, así que se esixe máis tempo que o teu razoamento, gaña a política.
Pecha o incidente cun rexistro, non cunha exportación
Escribe no tícket un rexistro de catro liñas: o síntoma, o cliente e a versión, a única liña de erro que o identificou e a corrección. Non anexes nada máis, porque a exportación era para ti e o rexistro é para a seguinte persoa.
O rexistro tamén ten máis probabilidades de ser lido: a exportación completa serve sobre todo a quen a capturou, e esa persoa xa sabe que pasou. Garda o rexistro onde se buscará o próximo incidente, o que normalmente significa o tícket e non un cartafol co nome dunha data. Un número de caso pode levar a referencia se o rexistro ten que ser rastrexable sen expor un identificador de conexión. Se aínda queda unha pregunta aberta, o orixinal queda baixo a regra de copia protexida de arriba; unha vez que existe o rexistro, todo o demais pode irse.
Atopa cada copia antes de borrar unha
Mira no cartafol de exportación, despois no diario da xanela do incidente, despois nos anexos do tícket, despois no catálogo de copias de seguridade, despois no almacén de monitorización. Se o mesmo identificador de conexión aparece nun quinto lugar, o inventario estaba mal. O diario é a sorpresa habitual, porque seguiu recollendo mentres lías a exportación.
Usa a ruta de rotación e borrado admitida en lugar de desvincular ficheiros a man. Un ficheiro que segue aberto conserva o seu almacenamento despois de que desapareza a entrada do directorio, así que o borrado parece completo e non libera nada. Iso é un fallo de almacenamento con etiqueta de privacidade, e non satisface ningún dos dous obxectivos.
Detén a recollida antes de verificar o borrado
Detén a recollida detallada temporal desde a aplicación que a posúe, non editando o seu ficheiro de saída. Un axuste de depuración esquecido segue escribindo rexistros novos despois de eliminar os antigos, o que desfai en silencio o traballo que acabas de facer. Comproba o nivel de rexistro efectivo e non o valor que lembras ter posto. Despois confirma que o que queda está protexido e que só as persoas previstas poden recuperalo.
O principio é a minimización de datos: conserva o que un propósito declarado necesita, durante o tempo que o necesite, e nada máis, tal como o formulan as directrices de privacidade RFC 6973. Un ficheiro gardado sen propósito é unha responsabilidade cunha marca de tempo. A decisión está rematada cando podes nomear o ficheiro, o seu propósito, o seu propietario e a súa data de fin.