Copias inmutables y recuperación ante ransomware: del plan al simulacro

Todo el mundo tiene copias de seguridad. Casi nadie sabe si puede restaurar. Y el ransomware moderno no ataca primero tus datos: ataca primero tus copias, porque quien las pierde deja de tener alternativa a pagar.

Las copias de seguridad inmutables son la respuesta técnica a ese problema: una copia que, una vez escrita, no puede modificarse ni borrarse durante un plazo definido, ni siquiera por un administrador con credenciales válidas. Suena simple. Implantarlo en una plataforma en producción no lo es, y probarlo todavía menos.

Por qué el backup tradicional ya no basta

Durante años la copia de seguridad protegía contra el fallo: un disco que muere, un borrado accidental, un centro de datos que se cae. Contra el fallo, una copia accesible desde la red vale.

Contra un atacante no vale, porque el atacante piensa. Entra semanas antes, escala privilegios, localiza la consola de copias y la ataca antes de cifrar nada. Cuando llega el cifrado, ya no hay a dónde volver. Ese es el guion habitual, y explica por qué una organización con copias correctas puede acabar pagando igual.

La diferencia entre resistir y pagar casi nunca está en la tecnología de copia. Está en si esa copia es alcanzable desde las credenciales que el atacante ha conseguido.

Qué hace inmutable a una copia

Inmutable no es un adjetivo comercial: es una propiedad que se cumple o no se cumple. Tres condiciones, y las tres a la vez:

• No se puede sobrescribir. El sistema rechaza cualquier escritura sobre un objeto ya escrito, venga de donde venga.
• No se puede borrar antes de tiempo. Hay un plazo de retención que ni el administrador de la plataforma puede acortar. Si alguien puede reducirlo, no es inmutabilidad: es una política.
• Está fuera del dominio de confianza. Credenciales distintas, autenticación distinta, idealmente proveedor o red distintos. Una copia inmutable a la que se llega con la misma cuenta que administra los servidores protege bastante menos de lo que parece.

A partir de ahí las variantes son de implementación: bloqueo de objeto en almacenamiento compatible, dispositivos con retención forzada, cintas fuera de línea, réplicas en un tenant separado. Todas valen si cumplen las tres condiciones. Ninguna vale si falla una.

La regla que de verdad se sostiene

La vieja regla de tres copias, dos soportes y una fuera se quedó corta. La versión que aguanta hoy añade dos números: una copia inmutable o desconectada, y cero errores en la verificación.

El segundo es el que casi nadie cumple. Una copia que nunca se ha restaurado no es una copia: es una intención. La verificación automática de que el conjunto es recuperable —no que el trabajo terminó sin error, sino que los datos se levantan— es lo que convierte un inventario de cintas en una capacidad de recuperación.

Del plan al simulacro real

Aquí es donde la mayoría de los planes de continuidad se caen. Existe el documento, existe el diagrama, existe la matriz de responsabilidades. Lo que no existe es la vez que se hizo de verdad.

Qué tiene que medir un simulacro

No «si se puede restaurar». Eso se sabe. Un simulacro útil mide tres cosas: cuánto se tarda de verdad en tener el servicio otra vez en pie, cuántos datos se pierden por el camino y cuántas decisiones hubo que improvisar porque el procedimiento no las contemplaba.

Los dos primeros números son los objetivos de tiempo y de punto de recuperación que ya tienes escritos. El tercero no está escrito en ningún sitio y es el que predice cómo irá el día real.

El escenario que nadie ensaya

Casi todos los simulacros restauran un servidor. El escenario que hay que ensayar es otro: el directorio corporativo comprometido, la consola de copias inaccesible, las credenciales de administración quemadas y la orden de no encender nada hasta saber por dónde entraron.

Ahí aparecen las preguntas que nadie se había hecho. ¿Con qué identidad te autenticas si el dominio no es de fiar? ¿Dónde está el procedimiento si la intranet está cifrada? ¿Quién autoriza restaurar sobre producción y por qué canal, si el correo corporativo está caído? Esas respuestas se preparan antes o se improvisan mal.

Qué exigen DORA, NIS2 e ISO 22301

Las tres empujan en la misma dirección, con distinto acento. DORA pide políticas de copia y procedimientos de restauración, y que la resiliencia operativa se pruebe, no se declare. NIS2 sitúa la continuidad y la gestión de crisis entre las medidas mínimas, con responsabilidad de dirección. La ISO 22301 aporta el método: análisis de impacto, objetivos de recuperación y ejercicios periódicos con evidencia.

El denominador común es la palabra evidencia. Ante un supervisor, un plan sin ejercicios documentados pesa lo mismo que no tener plan. Lo desarrollo en la guía de ISO 22301 y continuidad de negocio y en el solapamiento normativo entre DORA, NIS2, ENS y AI Act.

Lo que he visto en plataformas reguladas

Tres patrones que se repiten, y ninguno es de producto.

La copia inmutable existe, pero cuelga del mismo directorio. Se compró la funcionalidad y se integró con la autenticación corporativa porque era lo cómodo. El día que el directorio cae, la copia cae con él. La separación de identidad no es un detalle de despliegue: es la mitad del control.

Los objetivos de recuperación son de papel. Están escritos en el plan y nadie los ha medido nunca en condiciones. Cuando se mide, la primera cifra siempre decepciona; y eso es exactamente lo que hay que descubrir en un ejercicio y no en un incidente.

Nadie ha ensayado el orden. Restaurar es fácil; restaurar en el orden correcto, con las dependencias vivas y sin volver a infectar lo ya limpio, no lo es. Ese orden se descubre haciendo el inventario de dependencias, la misma disciplina que sostiene cualquier migración seria. Puedes ver cómo se aplica en los nueve programas que he dirigido en banca.

Cuánto tiempo hay que retener

La pregunta que más se equivoca. La retención de una copia inmutable no se elige por espacio disponible ni por lo que venga por defecto en la consola: se elige por el tiempo que un atacante puede permanecer dentro sin ser detectado.

Si tu capacidad de detección tarda semanas en descubrir una intrusión y tu ventana inmutable es de siete días, la copia protegida ya estará contaminada cuando la necesites. La regla práctica es sencilla: la retención inmutable tiene que superar con margen tu tiempo medio de detección, no tu política de archivo.

Ese número casi nadie lo tiene medido. Si es tu caso, empieza por asumir que es peor de lo que crees y dimensiona en consecuencia. Es una de esas decisiones donde equivocarse por exceso cuesta almacenamiento y equivocarse por defecto cuesta la empresa.

Retener no es archivar

Conviene separar dos cosas que suelen mezclarse en la misma política. El archivo responde a una obligación legal o contractual de conservar información durante años. La retención inmutable responde a un riesgo operativo: poder volver a un punto limpio. Son plazos distintos, soportes distintos y a menudo responsables distintos.

Cuando se mezclan, pasa siempre lo mismo: se paga almacenamiento caro durante siete años para cumplir una obligación que se satisfaría con una copia mucho más barata, y a la vez la ventana que de verdad protege frente a un cifrado es de dos semanas.

Cómo se defiende el coste ante dirección

La inmutabilidad cuesta dinero: almacenamiento que no se puede liberar antes de tiempo, a menudo en un segundo proveedor. Y llega a la mesa compitiendo con proyectos que sí generan ingresos.

El argumento que funciona no es el miedo, que se desgasta en dos comités. Es la comparación entre dos cifras que la dirección entiende sin traducción: cuánto cuesta al día que el servicio esté parado, y cuántos días se tarda en recuperar sin una copia limpia garantizada. Ese producto es el coste del riesgo, y casi siempre supera con mucho el del almacenamiento.

Si además puedes enseñar el resultado de un ejercicio real —el tiempo que tardasteis la última vez— la conversación cambia de tono. Se deja de discutir sobre hipótesis y se empieza a discutir sobre un número medido en tu propia casa. Es el mismo mecanismo que hace defendibles los indicadores de un proyecto: nada convence tanto como una medición propia.

Los errores que más se repiten

• Proteger los datos y olvidar la configuración. Se restauran las bases de datos y falta lo que hace que el servicio funcione: reglas de cortafuegos, certificados, definiciones de tareas, integraciones. La copia tiene que cubrir el servicio, no el fichero.
• Guardar la documentación del plan dentro del sistema que va a caer. Si el procedimiento de recuperación vive en la intranet, el día que la intranet esté cifrada no existe el procedimiento.
• No probar la restauración cruzada. Restaurar en el mismo entorno demuestra poco. La prueba útil es levantar el servicio en una infraestructura distinta, porque es lo que tocará hacer si la original está comprometida.
• Dejar la copia sin vigilancia. Un intento de borrado dentro del plazo de retención es una de las señales más limpias que existen de que alguien está dentro. Si ese evento no genera alerta, se pierde el mejor aviso disponible.

Por dónde empezar esta semana

• Comprueba con qué credenciales se llega a tu repositorio de copias. Si son las mismas que administran los servidores, ya tienes el primer hallazgo.
• Pide que alguien intente borrar una copia dentro del plazo de retención. Si lo consigue, la inmutabilidad es nominal.
• Elige un servicio de negocio, no un servidor, y restáuralo entero contra reloj. Apunta el tiempo real y las decisiones que hubo que improvisar.

Tres tareas de una tarde cada una. Las tres dan más información sobre tu capacidad real de recuperación que cualquier informe de estado de las copias.

Conclusión: la copia que cuenta

La única copia que cuenta es la que sobrevive a un atacante con tus credenciales y la que alguien ya ha restaurado antes, con cronómetro. Todo lo demás es inventario.

Preguntas frecuentes sobre copias inmutables