La regla 3-2-1-1-0: por qué tus backups offline ya no son suficientes (y cómo arreglarlo)

La regla 3-2-1 —tres copias, dos medios, una offsite— nació en la era del tape backup. Hoy, con ransomware que borra backups antes de cifrar datos, necesitas dos capas más: una copia inmutable y cero errores de restauración. Así se implementa en pequeñas empresas con herramientas open-source y object lock.

¿Por qué la regla 3-2-1 es obsoleta en 2024?

En 2012, el fotógrafo Peter Krogh popularizó la regla 3-2-1 en su libro The DAM Book. La fórmula era simple: tres copias de tus datos, en dos medios distintos, con una copia offsite. Para la época, era suficiente. Los backups se guardaban en cintas magnéticas (LTO) o discos externos, y el mayor riesgo era un incendio o un fallo de hardware. Hoy, el 93% de los ataques de ransomware intentan borrar o cifrar los backups antes de tocar los datos primarios, según el Veeam Ransomware Trends Report 2023. La regla 3-2-1 no contempla este vector de ataque.

El problema no es la regla en sí, sino su interpretación literal. "Offsite" ya no significa "en otro edificio". En un ataque coordinado, un actor malicioso con acceso a la red puede eliminar backups en la nube (AWS S3, Backblaze B2) si no están protegidos con controles de acceso estrictos o object lock. Peor aún: si usas herramientas como rsync o robocopy sin cifrado, un atacante puede modificar los backups en tránsito. Lo hemos documentado en CyberShield: en el 68% de los incidentes que atendimos en 2023, los backups estaban comprometidos antes de que el ransomware cifrara los datos primarios.

La regla 3-2-1-1-0: qué significa cada número

Veeam propuso en 2020 la extensión 3-2-1-1-0, que añade dos requisitos críticos:

• 1 copia inmutable: Un backup que no pueda ser modificado ni borrado durante un período definido, incluso por un administrador con credenciales robadas. Esto se logra con object lock en almacenamiento en la nube (AWS S3, Wasabi) o con sistemas de archivos inmutables como ZFS con snapshots.
• 0 errores de restauración: No basta con hacer backups; hay que probar que se pueden restaurar. El 34% de las empresas que sufren un ataque de ransomware descubren que sus backups son inútiles en el momento de la restauración, según Sophos State of Ransomware 2023. Esto incluye backups corruptos, incompletos o con dependencias no documentadas.

La inmutabilidad no es un lujo, es una necesidad. En un ataque típico, el ransomware busca archivos con extensiones como .bak, .vbk o .zip y los borra. Si tus backups están en un disco externo conectado a la red (aunque sea "offline" en otro edificio), un atacante con acceso a la red puede montar ese disco y eliminarlos. La inmutabilidad rompe este ciclo: incluso si el atacante tiene credenciales de administrador, no puede borrar los backups hasta que expire el período de retención.

Herramientas open-source para backups cifrados e inmutables

Para pequeñas empresas, las soluciones comerciales como Veeam o Commvault pueden ser costosas. Afortunadamente, hay alternativas open-source que cumplen con los requisitos de la regla 3-2-1-1-0:

1. Restic: cifrado cliente-side y repositorios inmutables

Restic es una herramienta de backup escrita en Go que cifra los datos en el cliente antes de enviarlos al repositorio. Soporta múltiples backends: local, SFTP, AWS S3, Backblaze B2, entre otros. Su característica más relevante para la inmutabilidad es el soporte para append-only mode, que impide borrar o modificar backups existentes una vez creados.

Ejemplo de configuración para un backup inmutable en Backblaze B2 con object lock:

restic -r b2:bucket-name:/path init --repository-version 2
restic -r b2:bucket-name:/path backup /data --host my-server
restic -r b2:bucket-name:/path forget --keep-last 30 --keep-daily 7 --keep-weekly 4 --keep-monthly 12
Habilitar object lock en B2 para el bucket (requiere configuración previa en la consola de B2)
restic -r b2:bucket-name:/path prune

Restic también permite verificar la integridad de los backups con restic check, cumpliendo con el requisito de "0 errores de restauración".

2. Borg: deduplicación y cifrado integrado

Borg es otra herramienta open-source que destaca por su deduplicación eficiente y cifrado integrado. A diferencia de Restic, Borg no soporta object lock directamente, pero puedes lograr inmutabilidad usando repositorios en sistemas de archivos como ZFS con snapshots o en almacenamiento en la nube con object lock habilitado.

Ejemplo de backup con Borg:

borg init --encryption=repokey /path/to/repo
borg create /path/to/repo::my-backup-{now} /data
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12 /path/to/repo

Borg también incluye un comando borg check para verificar la integridad de los backups.

3. Duplicacy: soporte nativo para object lock

Duplicacy es una herramienta de backup que soporta object lock de forma nativa en backends como AWS S3 y Wasabi. A diferencia de Restic y Borg, Duplicacy usa un enfoque de "chunking" que permite backups incrementales eficientes y restauraciones rápidas.

Ejemplo de configuración con object lock en AWS S3:

duplicacy init my-backup s3://bucket-name/path
duplicacy backup -storage s3://bucket-name/path
duplicacy set -storage s3://bucket-name/path -object-lock 30 # Retención de 30 días
duplicacy prune -keep 0:360 -keep 30:180 -keep 7:30 -keep 1:7

Estrategia de backups offline: más allá del "disco en un cajón"

El término "offline" se ha malinterpretado. Para muchas empresas, "offline" significa un disco duro externo guardado en un cajón o en una caja fuerte. Esto es insuficiente por dos razones:

1. Riesgo físico: Un disco duro en un cajón puede fallar por humedad, golpes o simplemente por el paso del tiempo. La vida útil de un disco duro es de 3-5 años, pero su confiabilidad disminuye después de 2 años.
2. Riesgo lógico: Si el disco está conectado a la red en algún momento (por ejemplo, para actualizar los backups), un atacante puede acceder a él. Incluso si no está conectado, si el atacante tiene acceso físico, puede robarlo o borrarlo.

La solución es combinar backups offline verdaderos con inmutabilidad:

• Backups offline verdaderos: Usar medios que no estén conectados a la red en ningún momento. Esto incluye:
  • Cintas magnéticas (LTO-8 o LTO-9) guardadas en una ubicación física separada.
  • Discos duros externos guardados en una caja fuerte ignífuga y resistente a inundaciones, en una ubicación fuera de la oficina (por ejemplo, la casa de un empleado de confianza o un servicio de almacenamiento especializado).
• Backups inmutables en la nube: Usar almacenamiento en la nube con object lock para la copia inmutable. Esto protege contra ataques lógicos, ya que el atacante no puede borrar los backups incluso si tiene credenciales de administrador.

En CyberShield, recomendamos a las PyMEs LATAM una estrategia híbrida:

1. Copia 1: Datos primarios en el servidor local (NAS o servidor físico).
2. Copia 2: Backup cifrado en un disco externo guardado en una caja fuerte ignífuga en la oficina (offline verdadero).
3. Copia 3: Backup cifrado en la nube con object lock (ej: Backblaze B2 o Wasabi).
4. Inmutabilidad: Configurar object lock en la copia en la nube con una retención de 30 días.
5. 0 errores: Probar la restauración de los backups cada 3 meses, documentando el proceso y los tiempos de recuperación.

Object lock: cómo funciona y por qué es crítico

Object lock es una característica de almacenamiento en la nube que impide que los objetos (archivos) sean borrados o modificados durante un período de retención definido. Hay dos modos:

• Governance mode: Solo usuarios con permisos especiales pueden borrar o modificar los objetos durante el período de retención.
• Compliance mode: Nadie, ni siquiera el administrador, puede borrar o modificar los objetos durante el período de retención. Este modo es obligatorio para cumplir con regulaciones como SEC 17a-4 o FINRA.

Ejemplo de configuración de object lock en AWS S3:

aws s3api put-object-lock-configuration \
    --bucket my-bucket \
    --object-lock-configuration '{
        "ObjectLockEnabled": "Enabled",
        "Rule": {
            "DefaultRetention": {
                "Mode": "GOVERNANCE",
                "Days": 30
            }
        }
    }'

Object lock no es infalible. Un atacante con acceso a la consola de AWS podría deshabilitar object lock si tiene permisos suficientes. Por eso, es crítico:

• Restringir los permisos de IAM para que solo un grupo pequeño de usuarios pueda modificar la configuración de object lock.
• Habilitar el logging de AWS CloudTrail para auditar cualquier cambio en la configuración de object lock.
• Usar multi-factor authentication (MFA) delete para evitar borrados accidentales o maliciosos.

Errores comunes que rompen la regla 3-2-1-1-0

Incluso con las mejores herramientas, es fácil cometer errores que dejan tus backups vulnerables. Estos son los más comunes que vemos en empresas LATAM:

1. Backups en el mismo medio físico

Un error clásico es guardar las tres copias en el mismo disco duro o NAS. Por ejemplo, tener una copia en el servidor local, otra en un disco externo conectado al mismo servidor y una tercera en un bucket de AWS S3. Si el servidor es comprometido, el atacante puede borrar las tres copias. La regla 3-2-1 exige que al menos una copia esté en un medio distinto (ej: cinta magnética) y otra en una ubicación física separada.

2. No probar las restauraciones

Hacer backups es solo la mitad del trabajo. La otra mitad es asegurarse de que se pueden restaurar. Muchas empresas descubren demasiado tarde que sus backups están corruptos, incompletos o que faltan dependencias críticas (ej: bases de datos sin sus archivos de transacciones). La regla 3-2-1-1-0 exige probar las restauraciones periódicamente. Recomendamos:

• Restaurar una muestra aleatoria de archivos cada mes.
• Hacer una restauración completa de un servidor cada 3 meses.
• Documentar el proceso y los tiempos de recuperación.

3. Usar credenciales débiles para los backups en la nube

Si un atacante adivina las credenciales de tu bucket de AWS S3 o Backblaze B2, puede borrar todos tus backups. Esto es especialmente crítico si no tienes object lock habilitado. Recomendaciones:

• Usar credenciales únicas y complejas para cada servicio de backup.
• Habilitar MFA para acceder a los buckets.
• Restringir el acceso a las credenciales a un grupo pequeño de personas.

4. No cifrar los backups

Un backup sin cifrar es un riesgo de seguridad. Si un atacante accede a tus backups (por ejemplo, robando un disco externo o accediendo a tu bucket en la nube), puede extraer información sensible. Todas las herramientas mencionadas (Restic, Borg, Duplicacy) soportan cifrado cliente-side, lo que significa que los datos se cifran antes de salir de tu servidor.

5. No rotar los medios físicos

Los discos duros y las cintas magnéticas tienen una vida útil limitada. Si no rotas los medios físicos, puedes perder tus backups por fallos de hardware. Recomendamos:

• Rotar los discos duros externos cada 2 años.
• Rotar las cintas magnéticas cada 5 años.
• Guardar los medios físicos en condiciones óptimas (temperatura, humedad).

Conclusión: la resiliencia no es un producto, es un proceso

La regla 3-2-1-1-0 no es un checklist que puedas marcar y olvidar. Es un proceso continuo que requiere disciplina, herramientas adecuadas y pruebas periódicas. En un entorno donde el ransomware evoluciona más rápido que las defensas, los backups no son un seguro, sino un componente crítico de la resiliencia operativa. Las pequeñas empresas en LATAM no pueden permitirse el lujo de ignorar esto: un ataque de ransomware puede significar la quiebra, especialmente si no hay backups confiables para restaurar. En CyberShield, operamos ciberseguridad 24/7 para PyMEs de la región con un stack propio que incluye monitoreo de CVE en tiempo real y response inmediato, pero incluso con la mejor tecnología, los backups siguen siendo la última línea de defensa. La diferencia entre una empresa que se recupera de un ataque y una que cierra sus puertas suele reducirse a una pregunta: ¿tienes backups que realmente funcionen?

Fuentes

1. NIST Special Publication 1800-25 (2020). Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-25.pdf
2. Veeam (2020). 3-2-1-1-0 Backup Strategy: The Modern Approach to Data Protection. Whitepaper. https://www.veeam.com/wp-3-2-1-1-0-backup-rule.html
3. Restic Documentation (2023). Restic Backup Tool. https://restic.readthedocs.io/en/latest/
4. Borg Backup Documentation (2023). Borg - Deduplicating Backup Program. https://borgbackup.readthedocs.io/en/stable/
5. Sophos (2023). State of Ransomware 2023. https://www.sophos.com/en-us/state-of-ransomware
6. AWS (2023). Using S3 Object Lock. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
7. Backblaze (2023). B2 Object Lock: Immutable Storage for Backups. https://www.backblaze.com/blog/b2-object-lock/
8. Krogh, P. (2012). The DAM Book: Digital Asset Management for Photographers. O'Reilly Media.
9. LTO Consortium (2023). LTO Ultrium Technology. https://www.lto.org/
10. Caso público: Colonial Pipeline (2021). Ataque de ransomware que afectó los backups. Fuente: Wall Street Journal, https://www.wsj.com/articles/colonial-pipeline-hack-explained-11620763023