Continuidad y recuperación: la restauración que nadie probó

Todo panel de copias de seguridad muestra marcas de verificación en verde. Los trabajos se completaron, la política de retención se cumplió, el almacenamiento se utilizó como se esperaba. Nada de eso te dice si puedes traer un controlador de dominio desde bare metal en menos de cuatro horas durante un incidente real. La brecha entre "la copia de seguridad se realizó correctamente" y "la restauración se realizó correctamente" es donde la mayoría de los planes de continuidad fallan silenciosamente.

Por qué la marca de verificación miente

El software de copia de seguridad reporta éxito cuando termina de escribir bytes en un destino. No sabe si esos bytes son utilizables. Una copia de seguridad de SQL Server puede completarse sin problemas y seguir siendo irrecuperable porque la cadena de registro de transacciones se rompió hace tres días y nadie lo notó. Las instantáneas de VM pueden verse bien en la consola mientras el escritor VSS subyacente falló silenciosamente dentro del SO invitado, produciendo una imagen consistente con fallos (no consistente con aplicaciones).

Los operadores de ransomware saben esto. Los grupos que ejecutaban playbooks de estilo Conti en incidentes anteriores apuntaban deliberadamente a la infraestructura de copia de seguridad, eliminando copias de sombra con vssadmin delete shadows /all /quiet, deshabilitando repositorios de Veeam, cifrando objetivos de copia de seguridad basados en NAS que eran accesibles sobre SMB. Si tus copias de seguridad viven en el mismo segmento de red que la producción con credenciales de dominio que pueden tocarlas, son un objetivo, no una red de seguridad.

Construye un runbook de restauración, no una política de copia de seguridad

Un plan de continuidad necesita instrucciones de restauración paso a paso escritas para alguien que no sea la persona que normalmente lo hace. Escribe:

• Orden exacto de recuperación (controladores de dominio y DNS primero, luego aplicaciones principales, luego todo lo demás)
• Dónde viven las credenciales para la consola de copia de seguridad si tu bóveda de contraseñas también está caída
• El comando de restauración específico o la ruta de la consola, no "usa Veeam para restaurar la VM"
• Duración esperada por sistema, basada en pruebas reales medidas, no en números de marketing del proveedor

Para Veeam Backup & Replication, eso significa documentar los pasos reales: abre la consola, ve a Backups > Disk, haz clic derecho en el punto de restauración, elige Instant VM Recovery o Full VM Restore según el escenario, y selecciona el host de destino con suficiente capacidad libre. Si tu host principal también está comprometido, necesitas un segundo host aislado ya identificado y con licencia.

Prueba restauraciones en un calendario, no por capricho

Elige una rotación. Cada mes, restaura un sistema crítico a una VLAN aislada y valida que arranca, se autentica y sirve datos correctamente. Cada trimestre, ejecuta una prueba de alcance completo: restaura tu controlador de dominio, tu servidor de archivos y tu base de datos principal a infraestructura aislada, luego haz que alguien fuera del equipo de copia de seguridad intente iniciar sesión y extraer un informe.

Para bases de datos, no solo restaures el archivo .bak, verifica que:

RESTORE VERIFYONLY FROM DISK = 'D:\\Backups\\prod_2024.bak'

Luego realmente restaura a una instancia de prueba y ejecuta DBCC CHECKDB contra ella. Una copia de seguridad que pasa VERIFYONLY aún puede contener corrupción lógica que solo aparece cuando la consultas.

Para sistemas Linux usando algo como Bacula o restic, prueba la ruta de restauración real:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

Luego ejecuta diff en los archivos de configuración restaurados contra la producción para confirmar que nada se perdió silenciosamente.

Copias inmutables y la regla 3-2-1-1

La regla clásica 3-2-1 (tres copias, dos tipos de medios, una fuera del sitio) necesita una actualización para la era del ransomware: 3-2-1-1, donde el "1" adicional es una copia inmutable o aislada por aire. Object Lock en almacenamiento compatible con S3 (Wasabi, Backblaze B2, o AWS S3 con Object Lock habilitado) previene eliminación o modificación durante una ventana de retención definida, incluso por una cuenta con credenciales de administrador. Configúralo con:

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

El modo COMPLIANCE significa que nadie, incluyendo la cuenta raíz, puede acortar la retención o eliminar objetos antes. Eso importa cuando el atacante tiene admin de dominio.

Mide RTO y RPO con números reales, no suposiciones

Recovery Time Objective y Recovery Point Objective suenan como ejercicios de papeleo hasta que un ejecutivo pregunta "cuántos datos perdemos y cuánto tiempo estamos caídos". Cronometra tus últimas tres restauraciones de prueba. Si tu objetivo RPO es una hora pero tu trabajo de copia de seguridad solo se ejecuta cada seis, tienes una brecha documentada, y es mejor encontrar esa brecha en un ejercicio de mesa que durante un evento de cifrado real a las 2 a.m. un sábado.

Ejecuta la prueba, anota la hora real del reloj, y compárala con lo que prometiste en el documento de recuperación ante desastres. La diferencia entre esos dos números es el estado real de tu plan de continuidad.

Para más información sobre cómo endurecer los sistemas que estás protegiendo y construir flujos de trabajo de respuesta a incidentes, consulta los segmentos relacionados de Blue Team y Digital Forensics en Korra Studio.