La inmutabilidad se implementa a nivel de almacenamiento, no de aplicación. Tecnologías como S3 Object Lock, Azure Immutable Blob Storage, Veeam Hardened Repository o cabinas con snapshots WORM garantizan que ni el software de backup ni un admin comprometido puedan alterar las copias.
Qué es un backup inmutable
Un backup inmutable es una copia de seguridad protegida a nivel de almacenamiento para que no pueda ser modificada, cifrada, sobrescrita ni eliminada por nadie —ni siquiera por administradores con privilegios elevados— durante un periodo de retención definido. La inmutabilidad se implementa mediante tecnologías como WORM (Write Once Read Many), Object Lock en almacenamiento cloud (S3, Azure Blob, GCS) o snapshots inmutables en cabinas de almacenamiento. Es la última línea de defensa contra ransomware: si un atacante cifra toda tu infraestructura pero tus backups son inmutables, puedes restaurar sin pagar rescate.
Por qué importa
Los grupos de ransomware modernos no se limitan a cifrar servidores de producción. Su primera acción tras obtener acceso privilegiado es identificar y destruir los backups. Si lo consiguen, la víctima no tiene más opción que pagar o perder todo. Por eso los backups tradicionales ya no son suficientes: si el atacante puede acceder al servidor de backup con las mismas credenciales de dominio, los borra. Un backup inmutable elimina esa posibilidad. Aunque el atacante tenga credenciales de admin, no puede modificar ni eliminar las copias protegidas hasta que expire el periodo de retención. Para un CISO, implementar inmutabilidad en backups es probablemente la medida con mejor relación coste-impacto contra ransomware. No previene el ataque, pero garantiza que puedes recuperarte sin ceder al chantaje.
Puntos clave
El periodo de retención debe definirse según el RPO (Recovery Point Objective) y las necesidades regulatorias. Un periodo demasiado corto puede dejar copias obsoletas; uno demasiado largo dispara los costes de almacenamiento.
La regla 3-2-1-1-0 es el estándar actual: 3 copias, en 2 medios diferentes, 1 fuera del sitio, 1 inmutable, 0 errores en las pruebas de restauración.
La inmutabilidad no sustituye al cifrado de backups ni a la segmentación de la red de backup. Son capas complementarias: el cifrado protege la confidencialidad, la inmutabilidad protege la disponibilidad e integridad.
Ejemplo: ransomware neutralizado gracias a backups inmutables
Una empresa logística sufre un ataque de ransomware que cifra 120 servidores y destruye los backups almacenados en un NAS accesible por dominio. La empresa tiene un RTO de 24 horas y un seguro cyber que no cubre el rescate si no se demuestra diligencia en protección de datos. Sin embargo, seis meses antes habían implementado un repositorio de backups inmutable con Veeam Hardened Repository sobre Linux endurecido, aislado del dominio Windows. El atacante no pudo acceder a ese repositorio porque no estaba unido al dominio, no tenía credenciales compartidas y los backups tenían un Object Lock de 30 días. La empresa restauró los 120 servidores en 18 horas desde los backups inmutables, sin pagar rescate. El coste del repositorio inmutable fue de 15.000 euros. El rescate pedido era de 2 millones.
Errores habituales
- Asumir que tener backups es suficiente sin verificar que son inmutables. Si el servidor de backup está en el mismo dominio y accesible con las mismas credenciales, un atacante con acceso de admin lo destruye en minutos.
- No probar la restauración desde backups inmutables. La inmutabilidad garantiza que la copia existe, pero no que funciona. Los ejercicios de restauración periódicos son obligatorios para validar que el RPO y el RTO se cumplen en la práctica.
- Configurar inmutabilidad solo en cloud y olvidar los backups on-premise, o viceversa. La estrategia debe cubrir ambos entornos de forma coherente, especialmente en arquitecturas híbridas.
Términos relacionados
Servicios relacionados
Este concepto puede tener relación con servicios como:
Preguntas frecuentes
¿Qué diferencia hay entre un backup normal y un backup inmutable?
Un backup normal puede ser modificado o eliminado por cualquier usuario o proceso con los permisos adecuados, incluido un ransomware que haya comprometido credenciales de administrador. Un backup inmutable está protegido a nivel de almacenamiento con políticas WORM o Object Lock que impiden cualquier alteración durante el periodo de retención, independientemente de quién intente hacerlo.
¿Puede un atacante con acceso root eliminar un backup inmutable?
Si la inmutabilidad está correctamente implementada a nivel de almacenamiento (Object Lock en S3, snapshots WORM en cabina, repositorio Linux endurecido sin acceso SSH de root), no. Ni siquiera un administrador con máximos privilegios puede saltarse la protección hasta que expire el periodo de retención. Esa es precisamente la diferencia con un backup tradicional protegido solo por permisos de fichero.
¿Cuánto cuesta implementar backups inmutables?
Depende del volumen de datos y la tecnología elegida. En cloud, S3 Object Lock no tiene coste adicional sobre el almacenamiento estándar de S3. On-premise, un repositorio Linux endurecido con Veeam puede implementarse con hardware estándar por unos pocos miles de euros. Comparado con el coste medio de un ataque de ransomware (cientos de miles o millones de euros entre rescate, parada operativa y daño reputacional), la inversión es mínima.
¿Los backups inmutables son suficientes para cumplir con NIS2 y DORA?
Son un componente clave, pero no suficiente por sí solos. NIS2 y DORA exigen planes de continuidad de negocio completos que incluyen análisis de impacto, procedimientos de recuperación documentados, pruebas periódicas y tiempos de recuperación definidos. Los backups inmutables cubren la parte de disponibilidad de datos, pero deben integrarse en una estrategia de resiliencia más amplia.