En este artículo7 min de lectura
Un backup inmutable es una copia de seguridad que no se puede modificar ni borrar una vez creada, ni siquiera por un administrador. Es la respuesta directa a una realidad incómoda: el ransomware moderno ya no se conforma con cifrar los datos de producción, sino que busca las copias de seguridad antes de atacar, porque sabe que son la única salida sin pagar.
Esta guía explica qué es exactamente la inmutabilidad, en qué se diferencia del aislamiento con el que a menudo se confunde, dónde encaja dentro de la regla 3-2-1 y qué conviene tener hecho antes de que llegue el ataque.
Qué es un backup inmutable
Una copia de seguridad inmutable está diseñada para no poder alterarse una vez escrita. No se puede editar, no se puede cifrar y no se puede eliminar durante el periodo que se haya fijado, con independencia de quién lo intente y con qué permisos. Esa última parte es la clave: la protección también aplica a las cuentas de administrador, que son precisamente las que un atacante intenta comprometer.
Técnicamente se apoya en el bloqueo de objeto y en la tecnología WORM (Write Once, Read Many): los datos se escriben una vez y se pueden leer tantas veces como haga falta, pero no se pueden reescribir. El periodo de inmutabilidad se configura según la política de retención de cada empresa, y mientras dure, la copia es intocable.
- Defensa frente al ransomware. Aunque el atacante consiga credenciales de administrador, no puede cifrar ni borrar las copias inmutables, así que queda un punto de restauración limpio.
- Protección frente al error humano. Un borrado accidental o una política mal configurada no se llevan por delante la copia.
- Cumplimiento normativo. Sectores regulados como el financiero o el sanitario exigen garantías de integridad y retención que la inmutabilidad cubre de forma demostrable.
Inmutabilidad y aislamiento no son lo mismo
Es la confusión más habitual, y lleva a dar por protegido lo que no lo está. Son dos mecanismos distintos que resuelven cosas distintas:
| Mecanismo | En qué consiste | Qué no cubre |
|---|---|---|
| Aislamiento | Desconectar el soporte de la red, de forma física o lógica, para que un atacante no pueda alcanzarlo. | Si el soporte se conecta para escribir la copia del día, durante esa ventana es alcanzable. Y quien tenga acceso físico puede borrarlo. |
| Inmutabilidad | Bloquear el dato en sí, de modo que no se pueda alterar aunque esté en línea y accesible. | No protege frente a la pérdida del propio sistema de copias: sigue haciendo falta una copia fuera. |
La conclusión práctica es que no compiten: se complementan. El aislamiento reduce la superficie de ataque y la inmutabilidad garantiza que, si esa superficie se alcanza, el dato sigue ahí.
¿Sabes si tus copias actuales son realmente inmutables?
Muchas empresas creen tenerlo cubierto porque el proveedor menciona la palabra en su folleto. Revisamos cómo están configuradas hoy tus copias, si el periodo de retención es el que crees y si un administrador comprometido podría borrarlas.
Dónde encaja la inmutabilidad en la regla 3-2-1
La regla 3-2-1 lleva décadas siendo el estándar de las copias de seguridad, y sigue siendo el punto de partida correcto. Consiste en tres principios simples:
| Número | Qué exige | Por qué |
|---|---|---|
| 3 copias | El dato original más dos copias de seguridad. | Si falla una copia, todavía queda otra. |
| 2 soportes | Las copias, en dos tipos de soporte distintos. | Un fallo sistemático de un tipo de soporte no se las lleva todas. |
| 1 fuera | Al menos una copia en una ubicación distinta. | Un incendio, una inundación o un robo afectan a un sitio, no a los dos. |
El problema es que la regla 3-2-1 se diseñó pensando en desastres físicos y fallos de hardware, no en un atacante con credenciales. Frente al ransomware, tres copias no sirven de nada si las tres son borrables desde la misma consola. Por eso la formulación que tiene sentido hoy añade un número más: 3-2-1-1-0, donde el primer uno nuevo es una copia inmutable o aislada, y el cero es cero errores en las pruebas de restauración.
Ese cero final se olvida siempre y es el que más disgustos da: una copia que no se ha probado no es una copia, es una suposición.
Por qué importa: el ransomware va a por las copias
Los datos de Sophos sobre 2022 dieron la medida del problema en España: ocho de cada diez empresas españolas sufrieron un ataque de ransomware y al 81 % le cifraron los datos, ocho puntos por encima del año anterior y por encima de la media mundial, que se quedó en el 76 %.
En el 27 % de los casos hubo doble extorsión: además de cifrar, los atacantes se llevaron los datos para venderlos o amenazar con publicarlos. Es un matiz que cambia la estrategia, porque una copia perfecta te devuelve la operación pero no evita la filtración.
La parte buena del mismo informe es la que justifica todo lo anterior: el 98 % de las empresas españolas afectadas recuperó al menos parte de los datos, y el porcentaje que lo hizo restaurando desde copias de seguridad subió del 70 % al 81 % en un año. Las copias funcionan cuando están, y la inmutabilidad es lo que garantiza que sigan estando.
Qué tener hecho antes del ataque
Un ataque de ransomware no se previene del todo, pero la diferencia entre una empresa que lo supera en horas y otra que tarda semanas se decide antes de que ocurra:
- Una copia inmutable con retención definida, y saber exactamente cuántos días cubre.
- Restauraciones probadas, no solo copias hechas. Probar la restauración completa, con cronómetro, para saber cuánto se tarda de verdad.
- Control de accesos y segunda verificación en las cuentas que administran el sistema de copias, que es el objetivo prioritario del atacante.
- Un procedimiento escrito de quién hace qué, a quién se avisa y en qué orden se levantan los sistemas.
- Formación del equipo, porque la vía de entrada sigue siendo mayoritariamente un correo.
Y si el ataque ya ha ocurrido
El orden importa. Aislar los equipos afectados para frenar la propagación, no apagar sin más las máquinas (se pierde evidencia y a veces claves en memoria), avisar a quien corresponda —incluida la notificación a la autoridad si hay datos personales comprometidos— y solo entonces empezar a restaurar, desde la copia limpia más reciente y verificando que el punto de restauración es anterior a la intrusión, no solo anterior al cifrado.
Pagar el rescate no garantiza nada: ni que la clave funcione, ni que los datos robados no se publiquen igualmente. Es la razón por la que la inversión tiene más sentido en la copia que en el seguro de rescate. Si quieres ver cómo se articula todo esto en un plan completo, lo tratamos en disaster recovery y en el plan de continuidad.
Preguntas frecuentes
¿Un backup inmutable se puede borrar de alguna manera?
Durante el periodo de inmutabilidad configurado, no: ni por un usuario, ni por un administrador, ni por el propio software de copias. Cuando ese periodo vence, la copia vuelve a comportarse como cualquier otra y puede rotarse o eliminarse según la política de retención.
¿Es lo mismo que tener la copia en la nube?
No. Una copia en la nube puede ser perfectamente borrable si alguien tiene las credenciales. La inmutabilidad es una propiedad del dato, no del sitio donde está: se puede tener una copia inmutable en local y una copia borrable en la nube.
¿Cuánto tiempo conviene mantener la inmutabilidad?
Lo suficiente para cubrir el tiempo que un atacante puede pasar dentro de la red sin ser detectado, que a menudo son semanas. Una retención de solo dos o tres días deja la puerta abierta a que el punto de restauración limpio ya haya caducado cuando se descubre el ataque.
¿Sustituye a la regla 3-2-1?
No, la completa. La inmutabilidad protege el contenido de cada copia; la regla 3-2-1 protege frente a la pérdida del soporte o de la ubicación. Hacen falta las dos cosas.
¿Cómo sé si mis copias actuales son inmutables de verdad?
Comprobando tres cosas: si el sistema aplica bloqueo de objeto o WORM, cuál es el periodo de retención configurado y si una cuenta de administrador podría eliminar las copias antes de que venza. Si alguna de las tres respuestas no está clara, conviene revisarlo.
La copia que importa es la que se puede restaurar
La inmutabilidad ha dejado de ser una opción avanzada para convertirse en el mínimo razonable de cualquier estrategia de copias de empresa. Pero por sí sola no basta: hace falta saber qué retención cubre, tener las restauraciones probadas y que el sistema de copias no dependa de las mismas credenciales que el resto de la infraestructura.
Puedes ver cómo lo implantamos en copia inmutable, dentro de nuestras soluciones de backup empresarial.
Empieza por saber cuánto tardarías en volver
Revisamos tu sistema de copias actual, probamos una restauración real y te decimos cuánto tiempo estarías parado si mañana te cifran los datos. Con eso sobre la mesa se decide mucho mejor.
Escribe sobre ciberseguridad, protección del dato e infraestructura IT a partir de lo que plantean las empresas y administraciones con las que trabaja ITGLOBAL.