Hasta 2019, borrar o cifrar los respaldos antes del ataque final era una práctica excepcional. Hoy es estándar: grupos como LockBit, BlackCat o Akira siempre destruyen los backups accesibles para maximizar el pago del rescate. La respuesta técnica se llama backup inmutable: una copia que ni siquiera el administrador puede alterar.
En esta guía explicamos qué es la inmutabilidad, cómo se implementa con Object Lock en S3/Azure Blob y Veeam Hardened Repository, y cómo combinarla con air-gap para un esquema resistente. Seguiremos recomendaciones del CISA #StopRansomware.
Contenido
Qué es un backup inmutable
Un backup inmutable es un conjunto de datos que, una vez escrito, no puede ser modificado, sobrescrito ni eliminado durante un período de retención definido. La inmutabilidad se aplica a nivel de almacenamiento, por debajo del sistema operativo: incluso con credenciales de administrador comprometidas, las operaciones de DELETE o overwrite son rechazadas por la API o el driver del storage.
El concepto proviene del mundo de compliance (SEC 17a-4, FINRA, HIPAA) donde se exigía WORM (Write Once Read Many) para garantizar no repudio de registros financieros. Hoy se aplica como defensa contra ransomware.
Por qué es crítico contra ransomware moderno
El patrón de un ataque ransomware actual se desarrolla típicamente así:
- Acceso inicial (phishing, RDP expuesto, vulnerabilidad sin parchar)
- Escalamiento de privilegios hasta Domain Admin (a veces en <24 h)
- Reconocimiento de red: identifican servidores de backup
- Destrucción de respaldos: borran o cifran los repos conocidos
- Exfiltración de datos (para doble extorsión)
- Despliegue del ransomware y cifrado final
Si tu única defensa es "tengo backups", probablemente no los tendrás cuando los necesites. La inmutabilidad corta ese eslabón de la cadena.
Tecnologías: Object Lock, WORM, Hardened Repository
Object Lock en S3 (AWS/Wasabi/MinIO)
AWS S3 Object Lock (y compatibles) ofrece dos modos:
- Governance mode: usuarios con permiso especial (
s3:BypassGovernanceRetention) pueden eliminar - Compliance mode: nadie puede eliminar hasta que expire. Ni siquiera el usuario root
Para backup anti-ransomware, siempre usa Compliance mode. Proveedores recomendados: Wasabi (sin egress), AWS S3, Backblaze B2 (con Object Lock), Cloudflare R2.
Azure Blob Immutable Storage
Azure ofrece inmutabilidad por contenedor o por blob con políticas time-based o legal hold. Integración nativa con Azure Backup y Veeam.
Veeam Hardened Repository
Para inmutabilidad on-premises, Veeam implementa un repositorio Linux con:
- Sistema de archivos XFS con flag
chattr +ien backups - Usuario dedicado fuera del dominio Active Directory
- SSH con autenticación por llave únicamente
- Sin agentes permanentes (one-time SSH para jobs)
Almacenamiento WORM dedicado
Appliances como Dell PowerProtect DD (Data Domain), ExaGrid Retention Time-Lock o HPE StoreOnce Catalyst ofrecen inmutabilidad integrada con deduplicación.
Implementación paso a paso con Veeam
Ejemplo de configuración para un repositorio Wasabi S3 con Object Lock:
Inmutabilidad + air-gap: arquitectura ideal
La inmutabilidad protege contra modificación. El air-gap protege contra acceso. Combinarlos crea un esquema donde:
- El repositorio primario local soporta restauraciones rápidas
- El repositorio offsite en cloud es inmutable (30+ días)
- Una copia adicional en cinta LTO o disco USB rotativo se mantiene air-gapped
- Los jobs se gestionan con credenciales separadas y MFA
Este diseño extiende la regla 3-2-1 hacia 3-2-1-1-0, el nuevo estándar promovido por vendors y agencias de ciberseguridad.
Errores frecuentes al implementar
1. Aplicar inmutabilidad "Governance" en lugar de "Compliance"
Governance permite bypass con permisos adecuados. Un atacante con Domain Admin y acceso a la consola cloud puede obtener esos permisos. Siempre Compliance mode.
2. Retención de solo 7 días
Muchos ataques dwellan 14-30 días antes de detonar. Retención mínima: 14 días, ideal 30-90 días.
3. Misma cuenta cloud para producción y backup
Si el atacante compromete la cuenta AWS, también controla el bucket inmutable. Usa cuentas separadas con trust boundary explícita (AWS Organizations, roles cross-account con MFA).
4. No validar que la inmutabilidad realmente esté activa
Ejecuta periódicamente un intento controlado de DELETE sobre un objeto. Debe fallar con AccessDenied. Si funciona, tu inmutabilidad es decorativa.
¿Protegemos tus respaldos contra ransomware?
Diseñamos e implementamos backup inmutable con Veeam + cloud object-locked en Chile.
Ver Respaldo y Monitoreo →Preguntas frecuentes
¿Qué es el backup inmutable?
Es un respaldo cuyo contenido no puede ser modificado ni borrado durante un período definido, ni siquiera por administradores. Usa tecnologías WORM u Object Lock.
¿Cómo funciona Object Lock en S3?
AWS S3 Object Lock aplica una fecha de retención por objeto. Hasta que expira, la API rechaza cualquier DELETE o PUT, incluso con credenciales root en modo Compliance.
¿El backup inmutable reemplaza al air-gap?
No, son complementarios. La inmutabilidad protege contra cambios; el air-gap agrega aislamiento físico/lógico. Una arquitectura 3-2-1-1-0 usa ambos.
¿Cuánto tiempo de retención inmutable es recomendable?
Mínimo 14 días para detección de ataques tardíos. 30-90 días es el estándar. Industrias reguladas requieren años.
¿La inmutabilidad incrementa mucho el costo?
El almacenamiento inmutable cuesta lo mismo que el estándar en la mayoría de clouds. El costo marginal viene de no poder expirar backups anticipadamente: dimensiona la retención con cuidado.