Snapshot no es respaldo: qué exige la Ley 21.719 para proteger los datos de tus clientes

Hay una conversación que se repite en casi cada diagnóstico de infraestructura que hacemos. Preguntamos: ¿tienen respaldos de sus sistemas críticos? La respuesta es sí, con frecuencia acompañada de una pantalla que muestra una lista de trabajos completados exitosamente la noche anterior.

Lo que no preguntamos todavía — y lo que la entrada en vigor de la Ley 21.719 el 1 de diciembre convierte en urgente — es: ¿pueden demostrar que esos respaldos protegen los datos de sus clientes y empleados de forma que resista un análisis?

Esa segunda pregunta tiene una respuesta diferente.

Por qué un snapshot no es suficiente

Un snapshot es una fotografía del estado de una máquina virtual en un momento dado. Es una herramienta excelente para lo que fue diseñada: probar un cambio con la posibilidad de revertirlo rápido. Antes de instalar una actualización, se toma el snapshot; si algo sale mal, se vuelve al punto anterior.

El problema aparece cuando el snapshot se usa como estrategia de respaldo. Un snapshot vive en el mismo almacenamiento que la VM que fotografía. Si ese almacenamiento falla — un disco que se daña, un ataque de ransomware que cifra el storage, un error que corrompe los datos — el snapshot cae junto con la VM. Y en la mayoría de las configuraciones por defecto, el snapshot no está cifrado: los datos personales de los clientes están ahí, en claro, en el mismo lugar que todo lo demás.

Desde diciembre, si algo falla y los datos de tus clientes quedan expuestos, la pregunta va a ser qué medidas técnicas concretas tenías implementadas. Un snapshot sin cifrar en el mismo almacenamiento que los datos originales no es una medida de protección: es una copia de seguridad operacional. Son cosas distintas.

Lo que Proxmox Backup Server resuelve

Proxmox Backup Server es la solución de respaldo nativa de la plataforma. Lo que la distingue para el contexto de diciembre son tres capacidades específicas.

La primera es el cifrado del lado del cliente. PBS cifra los datos antes de transmitirlos al servidor de respaldo. Eso significa que en el servidor de respaldo — que puede estar en otro lugar, en la nube, o en manos de un proveedor externo — los datos son ilegibles sin la clave que tiene la organización. Si alguien accede al servidor de respaldo, no accede a los datos de los clientes.

La segunda es la verificación de integridad. PBS puede programar trabajos automáticos que comprueban que cada respaldo almacenado está íntegro. Un respaldo dañado detectado hoy es un problema administrativo. Detectado durante una emergencia es una crisis. La verificación automática convierte lo segundo en lo primero.

La tercera es la copia remota. PBS permite sincronizar copias cifradas hacia una ubicación separada. Si el sitio principal tiene un problema grave — un incendio, una inundación, un ataque que destruye el storage — existe una copia íntegra en otro lugar desde la que se puede recuperar todo.

La pregunta de gobierno que cualquier gerente puede hacer

No hace falta entender cómo funciona la deduplicación de PBS para saber si la estrategia de respaldo es adecuada. Hacen falta cuatro preguntas con respuesta concreta: ¿qué sistemas se respaldan y con qué frecuencia? ¿dónde están físicamente las copias? ¿cuándo fue la última vez que se restauró un respaldo como prueba? ¿cuánto tiempo tomaría recuperar el sistema más crítico si fallara hoy?

Si alguna de esas preguntas no tiene respuesta verificable — no “creo que sí”, sino con un registro que lo demuestre — la empresa no tiene una estrategia de respaldo: tiene una expectativa. Y desde diciembre, las expectativas no son suficientes.

¿Cuántas de esas cuatro preguntas puede responder tu empresa con evidencia hoy?


Artículos relacionados