1. Introducción

Si todo lo demás falla — el antivirus, los parches, el factor humano —, queda una única respuesta al peor escenario: el backup. Pero una copia sin inmutabilidad es papel mojado cuando el atacante sabe dónde encontrar tus datos, porque el 94% de los ataques de ransomware intentan comprometer los backups y el 57% lo consiguen. Los backups inmutables son la diferencia entre una restauración en días y una negociación con el extorsionador o, en el peor caso, la desaparición del negocio.

En este artículo verás la regla 3-2-1-1-0 explicada pieza a pieza, qué significa inmutabilidad real frente a permiso revocable, los errores más caros que convierten una copia en una falsa sensación de seguridad y el protocolo de recuperación que sigue a un cifrado. Está escrito para directivos y responsables de TI que quieren convertir la pregunta «¿tenemos backups?» en «¿tenemos backups que funcionan?».

2. La regla 3-2-1-1-0: el «0» que decide

La regla 3-2-1 nació en 2012 en un documento del Software Engineering Institute de Carnegie Mellon y se popularizó a través de la fotografía profesional. Su versión moderna, la que exige el ransomware actual, es la 3-2-1-1-0: al menos tres copias de los datos, en dos tipos de soporte distintos, una de ellas fuera del emplazamiento, una copia adicional inmutable u offline y CERO errores en las verificaciones de restauración.

El «0» es la pieza que la mayoría de las empresas ignora, y es la que el atacante explota: el objetivo del ransomware no es solo el archivo de producción, sino también la copia que te permitiría negarte a pagar. Un RTO sobre el papel es sistemáticamente optimista: un «restauramos en cuatro horas» acaba en días cuando nadie ha probado el proceso. La inmutabilidad te protege del borrado; la verificación te protege de la sorpresa.

3. Por qué el 94% de los atacantes ataca tus copias

El ransomware moderno es un negocio con una cadena de ataque en seis fases, y una de ellas ataca directamente a la recuperación: la técnica T1490 de MITRE ATT&CK (Inhibit System Recovery) cubre el borrado de volúmenes de sombra, la desactivación del antivirus y, sobre todo, la localización y destrucción de las copias de seguridad antes de cifrar. Los datos de Sophos State of Ransomware 2024 lo confirman: el 94% de los ataques intentaron comprometer los backups y el 57% lo consiguieron. Si el atacante destruye también la red de seguridad, el rescate deja de ser una opción y se convierte en la única salida.

Por eso los backups inmutables no son una mejora opcional: son el requisito que decide si pagarás o no. La inmutabilidad real no depende de un permiso revocable — del que el atacante ya tiene las credenciales si compartiste la administración —, sino de una configuración del almacenamiento que ni siquiera el administrador puede saltar sin esperar a que expire el periodo de retención.

4. Inmutabilidad de verdad: WORM por configuración

La inmutabilidad moderna es la evolución del concepto WORM (write once, read many). Las tecnologías maduras en 2026 son varias: el Object Lock de Amazon S3 en modo Compliance, disponible también en proveedores como Wasabi, Backblaze B2 o MinIO; el Veeam Hardened Repository, un repositorio Linux endurecido con filesystem ext4 que marca las copias como inmutables; y la cinta LTO con función WORM, el medio menos atractivo para el atacante y en la práctica el más resistente. En entornos críticos se combinan con un air-gap real: una copia almacenada fuera de la red que solo se conecta durante la ventana de backup.

El detalle que separa una decisión correcta de una aparente es que la inmutabilidad debe quedar «por configuración del almacenamiento, no por permiso revocable». Si el administrador del backup tiene las mismas credenciales que el resto de la empresa, el atacante también las tiene. La separación administrativa — credenciales de backup distintas, MFA reforzada, monitorización de los accesos al repositorio — es parte del diseño, no un extra decorativo.

# Verificar la inmutabilidad de un bucket S3 con Object Lock (awscli)
aws s3api get-object-lock-configuration --bucket backups-empresa

# Listar versiones retenidas en modo Compliance (no eliminables hasta el plazo)
aws s3api list-object-versions --bucket backups-empresa \
  --query 'Versions[?ObjectLockMode==`COMPLIANCE`]'

# Restauración de prueba desde el repositorio inmutable
aws s3 sync s3://backups-empresa/restore/2026-09-30/ /mnt/restore/

Fig. 1 – Comandos para comprobar que un backup con Object Lock es realmente inmutable.

5. Errores que convierten un backup en papel mojado

Los fallos más caros no están en la tecnología, sino en el diseño de la estrategia:

Error	Consecuencia	Corrección
Backup en el mismo segmento que producción	El atacante lo cifra junto a los datos	Red separada para el repositorio
NAS o SMB como «backup»	Es otro disco para el ransomware	Repositorio inmutable o air-gap
Credenciales compartidas backup-producción	El atacante borra las copias con tus cuentas	Separación administrativa
Rotación que falla sin alertas	Vacíos de copias que nadie ve	Alertas automáticas de éxito y fallo
Retención corta (14 días)	Todas las copias están infectadas	Retención mayor que la estancia típica
Claves de cifrado junto al backup	La protección es decorativa	Claves en HSM o KMS separado
Backup nunca restaurado completo	Catálogo corrupto el día D	Pruebas reales de restauración

Fig. 2 – Errores recurrentes en la estrategia de backups y su corrección.

La retención merece un matiz adicional: si el atacante permanece semanas dentro de la red, una retención de 14 días garantiza que todas las copias estén contaminadas. La duración de la retención debe cubrir los tiempos de permanencia conocidos de los grupos activos y, en lo posible, combinarse con la copia fuera de línea como cinturón de seguridad.

El caso típico de incidente lo resume el libro: copias nocturnas, logs que dicen «backup OK» y nadie que haya validado nunca una restauración completa. El día del cifrado, el catálogo está corrupto, faltan 20 terabytes y «restaurar» se convierte en un proyecto de diez días. «Tenemos backups» no es lo mismo que «tenemos backups funcionales y probados»: la diferencia es una restauración que alguien ejecutó de verdad.

6. RTO y RPO: objetivos que se pactan con el negocio

La inmutabilidad sin objetivos es una garantía sin dirección. El RPO (cuántos datos puedes permitirte perder) y el RTO (en cuánto tiempo debes volver a operar) se fijan con la dirección y el negocio, no solo con TI: un RPO de una hora en el sistema de facturación significa pérdida máxima de una hora de facturas, y eso es una decisión de negocio, no técnica. Los RTO escritos sobre el papel son sistemáticamente optimistas; solo las pruebas miden el real.

Para sistemas críticos y regulados — la ENS española exige continuidad probada en los sistemas de nivel alto, y NIS2 y DORA presionan en la misma dirección — conviene además un plan de continuidad de negocio alineado con ISO 22301 y NIST SP 800-34. Las métricas que debes vigilar cada semana: tasa de éxito de backups, RTO y RPO medidos frente a los comprometidos, cobertura del inventario y antigüedad del último éxito.

7. Probar la restauración: los tres niveles

Las pruebas de restauración tienen tres niveles. El mínimo, automatizado: motores como Veeam SureBackup o la detección de anomalías de Rubrik verifican cada noche que las copias se pueden montar. El intermedio: una restauración trimestral de un servicio crítico completo en un entorno aislado, con medición real del tiempo empleado. El completo: un ejercicio anual de recuperación ante desastres con escenarios realistas y observadores que documenten cada fricción. La mayoría de las empresas vive en el nivel cero: confiar en el log.

8. El protocolo de recuperación tras un cifrado

Cuando el ransomware golpea y tus backups inmutables siguen intactos, el protocolo es estricto. Primero, verifica la integridad antes de restaurar y elige una copia demostrablemente anterior al primer indicio de compromiso, no la más reciente. Segundo, restaura en un entorno aislado y confirma con el EDR o con un análisis forense que no quedan indicadores de compromiso antes de promover los datos a producción.

# Protocolo de recuperación tras ransomware (resumen operativo)
# 1. Verificar integridad ANTES de restaurar (backup anterior al compromiso).
# 2. Restaurar en entorno aislado y validar limpieza con el EDR o AFD.
# 3. Buscar indicadores de compromiso (IOC) en la copia restaurada.
# 4. Cambiar TODAS las credenciales antes de volver a producción.
# 5. RECONSTRUIR, no restaurar, los componentes comprometidos
#    (controladores de dominio, hipervisores, plataformas de gestión).

Fig. 3 – Protocolo operativo de recuperación tras un cifrado por ransomware.

Tercero, cambia todas las credenciales — usuarios, servicios, certificados, claves API, tokens OAuth y los secretos del CI/CD — y rota dos veces la contraseña krbtgt si el dominio fue comprometido. Cuarto y más importante: reconstruye en lugar de restaurar los componentes comprometidos. El controlador de dominio, los hipervisores y las plataformas de gestión pueden esconder una huella que el análisis forense no ve. Reconstruir desde imagen limpia cuesta horas; descubrir una puerta trasera meses después no tiene precio.

9. Conclusión

La empresa que no sufre el ataque es la excepción; la que se recupera en días es la que tiene backups inmutables probados. La regla 3-2-1-1-0, la inmutabilidad por configuración y las pruebas de restauración no son un lujo de las grandes corporaciones: son la diferencia entre una factura de rescate y una restauración ordenada. Es la diferencia que explica que el 60% de las pymes atacadas cierren a los seis meses mientras otras vuelven a operar en una semana.

Si el peor escenario ya ha ocurrido, la guía completa de cómo actuar como víctima está en nuestro artículo sobre qué hacer si tu empresa sufre un ransomware, y puedes encajar estas copias dentro del programa general con nuestra referencia sobre la realización de un plan de seguridad del software. En Jaymon Security diseñamos y auditamos estrategias de backups inmutables para que tu última red de seguridad aguante el golpe para el que está pensada.

¿Necesitas ayuda con Backups inmutables?

En Jaymon Security ayudamos a las organizaciones a proteger sus sistemas. Desde auditorías de seguridad hasta implementación de SIEM/SOC, nuestro equipo de expertos diseña soluciones a medida.

Contacta con nosotros para una evaluación gratuita de tu infraestructura.