Respaldo y recuperación ante ransomware: el único control que devuelve la operación
Todo lo demás intenta que no pase; esto decide qué ocurre cuando pasó. Es donde más veces encontramos la misma escena: sí había respaldo, corría todas las noches, y el día del incidente el archivo cifrado también estaba en la copia.
La copia estaba conectada a la misma red
El patrón se repite con una regularidad incómoda. El disco de respaldo cuelga del servidor, montado como una unidad más, escribible por la misma cuenta que administra todo. Quien entra con esa cuenta cifra los datos y la copia en la misma pasada. La variante moderna es la carpeta sincronizada con la nube: los archivos se cifran localmente, la sincronización obedece y sube la versión dañada. En ambos casos el trabajo se hizo, el registro decía correcto todas las noches, y aun así no hay nada que restaurar. El respaldo no falló por técnica: falló porque el atacante lo alcanzaba.
La regla 3-2-1-1-0, dígito por dígito
La regla clásica creció, y creció justo por el ransomware:
- 3 copias de los datos, contando la original.
- 2 tipos de medio distintos, para que una falla de tecnología no las tumbe a la vez.
- 1 copia fuera del sitio, porque el incendio y el robo siguen existiendo.
- 1 copia inmutable o desconectada. Inmutable significa que durante la ventana de retención no se puede alterar ni borrar, ni siquiera con una cuenta de administrador. Ese detalle es el punto entero: el atacante llega con privilegios de administrador, y todo lo que una cuenta de administrador puede borrar, lo borra. Desconectada significa exactamente eso, sin ruta desde la red: una cinta o un disco que se desenchufa cuando termina el trabajo.
- 0 errores, comprobados con una restauración de verdad.
El último dígito es el que casi todo el mundo omite, y es el que separa tener copias de tener respaldo. Las aseguradoras que cubren este riesgo suelen condicionar la cobertura precisamente a los dos últimos: copia inalterable y prueba de recuperación.
RPO y RTO: los dos números que decide el dueño, no el técnico
Todo el diseño sale de dos preguntas en lenguaje de negocio.
RPO — cuántos datos aceptas perder. Es la distancia hacia atrás hasta la última copia buena. Un trabajo nocturno significa que puedes perder una jornada completa de facturación. Si eso es inaceptable, la respuesta no es un disco más grande: es respaldar más seguido.
RTO — cuánto puedes estar detenido. Aquí está el error de cálculo más frecuente, porque no es el tiempo de copiar archivos: incluye encontrar una copia limpia, rearmar el servidor, restaurar, verificar que los datos abren en la aplicación real y reconectar a los usuarios.
Los dos se fijan por sistema, no para toda la empresa. El sistema de facturación y la carpeta del archivo histórico no merecen el mismo gasto, y tratarlos igual es la manera más común de pagar de más y proteger de menos.
El ransomware empeora el RTO respecto a una falla de disco por una razón que conviene entender: hay que encontrar un punto de restauración anterior a la intrusión, y el intruso pudo llevar semanas dentro. Por eso la retención importa tanto como la frecuencia: una copia de siete días no sirve si el acceso empezó hace un mes.
La copia que jamás se restauró es una hipótesis, no un respaldo
Lo que convierte esa hipótesis en un hecho comprobado es un ensayo, hecho antes de que haga falta.
Una prueba de restauración real tiene cuatro partes:
- Se restaura a un entorno aparte, nunca encima de lo que está en producción.
- Se abren los datos con la aplicación de verdad, no mirando si los archivos existen. Una base de datos copiada a medias existe y no abre.
- Se mide con reloj cuánto tardó todo el ciclo. Ese número es tu RTO real, y suele ser bastante peor que el estimado.
- Se anota: qué se restauró, cuánto tardó, qué falló y quién lo hizo.
Hay un caso que merece mención aparte, porque casi siempre se pasa por alto: la retención de una plataforma de nube no es un respaldo. Las papeleras y los períodos de conservación de un buzón o de un sitio de documentos sirven para recuperar lo que alguien borró por error. No te devuelven el estado completo de una carpeta tal como estaba el martes a las nueve de la mañana, que es exactamente lo que necesitas después de una sincronización envenenada.
Qué te entregamos
- Inventario de sistemas con su RPO y su RTO acordados uno por uno
- Esquema de las tres copias, con el medio y la ubicación de cada una
- Copia inmutable o desconectada configurada, con su ventana de retención
- Prueba de restauración ejecutada y cronometrada delante de tu personal
- Guía de recuperación paso a paso, impresa, porque el día del incidente puede no haber red
Cómo lo abordamos
Diagnóstico
Qué se respalda hoy, cada cuánto, dónde queda la copia y quién puede borrarla. Esa última pregunta es la que suele descolocar.
Propuesta
RPO y RTO por sistema, esquema de copias y equipo necesario. Los discos y las unidades de almacenamiento que vendemos tienen precio en línea.
Implementación
Configuración de los trabajos, separación de credenciales, activación de la retención inalterable y primera restauración de prueba.
Soporte
De lunes a viernes en horario laboral: vigilancia de los trabajos fallidos y una prueba de restauración periódica.
Preguntas sobre respaldo y recuperación
¿Un disco externo conectado al servidor sirve?
Como una de las copias, sí. Como única copia, no: si está montado y escribible desde el servidor, el mismo proceso que cifra los datos lo alcanza. Un disco que se desconecta al terminar ya es otra cosa, si alguien lo desconecta de verdad.
¿Cada cuánto hay que respaldar?
Lo dice tu RPO, no una costumbre. Si perder un día de operación es tolerable, el trabajo nocturno alcanza. Si no lo es, hay que bajar a varias veces al día en los sistemas que lo justifiquen y dejar el resto en el ritmo barato.
¿Los datos en la nube ya están respaldados?
Están replicados contra la caída de la plataforma, que es otro problema. Frente a un borrado masivo o una sincronización de archivos ya cifrados, la retención del servicio ayuda poco. Los datos de nube que te importan necesitan su propia copia.
¿Cada cuánto se prueba una restauración?
Una vez al año es el mínimo defendible y trimestral es lo razonable en los sistemas críticos. También conviene probar después de cada cambio grande: servidor nuevo, versión nueva de la aplicación o cambio del esquema de copias.
¿Y si nos cifran igual, se puede negociar?
No es una decisión técnica y no la tomamos nosotros. Lo que sí sabemos es que quien tiene una copia inalterable y probada casi nunca llega a esa conversación, y quien no la tiene la enfrenta sin garantía de recuperar nada.
¿Por dónde empiezo si no tengo casi nada?
Por escribir qué sistema no puede estar caído más de un día y respaldarlo con una copia que el administrador no pueda borrar. Después se restaura una vez para comprobar que funciona. Con esos dos pasos ya estás mejor que la mayoría.
Los controles que reducen la probabilidad
El respaldo es el último recurso; conviene que se use poco. Las tres páginas que reducen las veces que hace falta:
- La división interna de la red, que evita que un equipo alcance los servidores y el propio respaldo.
- El correo autenticado y el control del pago, por donde entra la mayoría.
- El equipo de perímetro con IPS, que corta el intento de explotación y la llamada al servidor de control.
- El acceso remoto publicado por aplicación, para que una credencial robada no valga como entrada a toda la red.
El resto de lo que hacemos, en servicios.
Dónde encaja esto
«Respaldo y recuperación ante ransomware» pertenece al área de ciberseguridad. Las ocho, en Soluciones.
Hagamos una restauración de prueba este mes
No hace falta cambiar nada. Tomamos tu copia actual, la restauramos aparte, abrimos los datos con la aplicación real y cronometramos. Si funciona, ya sabes cuánto vale; si no, mejor descubrirlo hoy.