¿Qué es un backup inmutable?
La palabra lo dice casi todo: inmutable es algo que no se puede cambiar. Un backup inmutable es, entonces, una copia de seguridad que, una vez escrita, queda bloqueada durante un periodo de retención definido: no se puede modificar, no se puede cifrar y no se puede borrar, ni siquiera por un administrador con los máximos privilegios. La tecnología que lo hace posible se conoce como WORM, por sus siglas en inglés «write once, read many» —escribir una vez, leer muchas—: los datos se graban y, a partir de ahí, solo se pueden leer. Piénsalo como un documento firmado ante notario y guardado en una caja con temporizador: hasta que el plazo no vence, nadie puede tocarlo, ni quien lo guardó. Esa cualidad, que parece una limitación, es justo lo que convierte a una copia en un refugio seguro: por mucho que un atacante consiga el control de tus sistemas, no podrá alterar lo que ya está sellado.
¿Por qué importa ahora?
Durante años bastó con tener copias de seguridad. Eso cambió. Los grupos de ransomware aprendieron que la mejor forma de forzar el pago es dejar a la víctima sin salida, así que ahora, antes de cifrar la producción, van directamente a por los respaldos: los buscan, deshabilitan sus protecciones y los borran o cifran. Las cifras lo confirman: alrededor del 94% de los ataques de ransomware tienen como objetivo los backups. La consecuencia es brutal y silenciosa: la empresa descubre que su producción está cifrada, va a restaurar… y encuentra que las copias también desaparecieron. En ese momento, de nada sirven los objetivos de recuperación si no queda nada desde donde recuperar. Aquí es donde la inmutabilidad cambia el desenlace: si una de tus copias no puede ser borrada ni cifrada durante su retención, siempre te quedará una versión limpia para volver a operar. Por eso dejó de ser un lujo de grandes empresas para volverse una pieza básica de la resiliencia.
Cómo se logra la inmutabilidad
No es magia, sino mecanismos concretos en la capa de almacenamiento. El más extendido es Object Lock, el estándar basado en la API de S3 que hoy usan tanto la nube como muchos sistemas on-premises. Funciona sobre el versionado de objetos y ofrece dos modos que conviene distinguir bien: en modo compliance, nadie —ni un administrador, ni la cuenta root— puede borrar o modificar el objeto antes de que expire la retención; en modo governance, ciertos usuarios con permisos sí pueden anular la protección. Para defenderte de un atacante que ha robado credenciales de administrador, el modo compliance es el que de verdad te protege. A Object Lock se suman otras formas de inmutabilidad: el almacenamiento WORM propiamente dicho, las instantáneas inmutables bloqueadas por un periodo, y los medios físicos como cinta que, guardados fuera de línea, añaden aislamiento. Un detalle no menor: la inmutabilidad verdadera exige que el sistema de respaldo no exponga acceso root ni al sistema operativo, y se refuerza protegiendo el borrado con autenticación de varios factores.
Los grandes proveedores de nube ofrecen esta capacidad de forma nativa —el almacenamiento inmutable de Azure o las políticas de retención de Google Cloud, además del Object Lock de S3—, lo que permite desplegarla sin gestionar hardware propio. Y algunos sistemas exigen el principio de «cuatro ojos» para cambiar una política de inmutabilidad: la aprobación de varias personas a la vez, de modo que ninguna credencial robada, por sí sola, baste para desactivar la protección antes de tiempo.Inmutable, air gap y offline: ¿no es lo mismo?
Se mencionan juntos y se confunden, pero no son idénticos, aunque persiguen la misma meta: una copia que el atacante no pueda tocar. La inmutabilidad bloquea los cambios y borrados aunque la copia siga conectada y en línea, lo que tiene una gran ventaja: permite restaurar de inmediato. El air gap aísla la copia de la red —física o lógicamente—, de modo que sea inalcanzable de forma remota; suele ser algo más lento de restaurar, pero ofrece una separación que el software por sí solo no da. Y offline es, sencillamente, una copia desconectada. No compiten: se complementan, y la configuración más robusta combina inmutabilidad y aislamiento. Esta es, precisamente, la lógica del «1» adicional en la regla 3-2-1-1-0: al menos una copia inmutable o aislada, además del «0» de cero errores verificados. La explicación a fondo de ambos enfoques está en nuestra página de backup inmutable y air gap.
Errores comunes con la inmutabilidad
Tener inmutabilidad no garantiza estar protegido si se configura mal. El error más habitual es confiar en el modo governance creyendo que es inmutable: si un administrador comprometido puede anularlo, no cumple su función frente a un atacante con credenciales. Otro es fijar una retención demasiado corta: si el ataque permanece latente más tiempo que la ventana de inmutabilidad, la copia limpia ya habrá caducado cuando la necesites. También es un fallo dejar la única copia inmutable solo en las instalaciones, sin una segunda fuera del sitio que sobreviva a un incendio o un robo. Y el más peligroso de todos: dar por hecho que, por ser inmutable, el respaldo funciona. La inmutabilidad evita que lo borren, pero no comprueba que sea restaurable; un backup que no se prueba podría no servir el día del desastre. La inmutabilidad es una pieza poderosa, no el plan entero.
Una capa, dentro de una estrategia
El backup inmutable resuelve un problema muy específico y cada vez más frecuente: que un atacante destruya tus copias. Hace ese trabajo mejor que cualquier otra técnica, y por eso hoy es indispensable en cualquier defensa seria contra el ransomware. Pero conviene verlo en su sitio: es una capa —decisiva— dentro de una estrategia que incluye tener varias copias, probarlas con regularidad y saber cómo restaurar, es decir, un plan de recuperación ante desastres. En Data Recovery Panama diseñamos esa capa con inmutabilidad y aislamiento reales, integrada con el resto del respaldo y con las restauraciones verificadas. Y cuando llega lo peor, esa copia intocable es la diferencia entre restaurar y negociar con quien atacó. Porque, como repetimos, el laboratorio que recupera también protege.
Preguntas frecuentes
Es una copia de seguridad que, una vez escrita, no se puede modificar, borrar ni cifrar durante un periodo de retención definido, ni siquiera por un administrador con acceso root. Se implementa con tecnología WORM (escribir una vez, leer muchas), de modo que siempre exista una versión intocable de la información, incluso ante un ataque.
Porque el ransomware moderno ataca primero los repositorios de respaldo —alrededor del 94% de los ataques van tras los backups— y una copia accesible desde la red se puede borrar o cifrar. Una copia inmutable no puede ser alterada durante su retención, así que garantiza que sobreviva al menos una versión limpia desde la cual restaurar.
No, aunque persiguen lo mismo. La inmutabilidad (WORM, Object Lock) bloquea cambios y borrados aunque la copia siga en línea, lo que permite restaurar rápido. El air gap aísla la copia de la red, física o lógicamente, de modo que sea inalcanzable de forma remota. Son complementarios, y combinarlos es la protección más fuerte.
En modo compliance, ni siquiera un administrador puede borrar o modificar el objeto antes de que expire la retención: es inmutabilidad real. En modo governance, ciertos usuarios con permisos pueden anular la protección. Para protección genuina frente a ransomware y credenciales comprometidas, el modo compliance es el recomendable.
Es una capa decisiva, pero no la única. La inmutabilidad evita que borren o cifren la copia, pero no sustituye probar las restauraciones —un backup que no se prueba podría no servir— ni tener un plan de recuperación. Conviene además una retención suficiente, que no sea solo on-site, y proteger el acceso al sistema de respaldo con MFA.