Respaldo cifrado offline: la regla 3-2-1 que sobrevive al ransomware en 2025

La regla 3-2-1 —tres copias, dos medios, una offsite— ya no detiene a atacantes que borran backups antes de cifrar datos. La actualización 3-2-1-1-0 añade inmutabilidad y cero errores de restauración, pero exige tooling especializado como Restic o Borg para implementarla sin depender de proveedores cloud. Aquí cómo hacerlo en una PyME con menos de 50 empleados.

¿Por qué la regla 3-2-1 clásica falla contra ransomware moderno?

En 2019, el 93% de los ataques de ransomware en LATAM ya incluían borrado de backups como primer paso, según un informe de la OEA citado en CyberShield. La regla 3-2-1 —formulada en 2005 por el fotógrafo Peter Krogh— asume que el atacante no tiene acceso a los medios de respaldo. Hoy, esa suposición es falsa: los grupos como LockBit y BlackCat usan credenciales robadas para acceder a NAS, servidores de backup y hasta a buckets S3 con políticas de retención mal configuradas.

El problema no es la regla en sí, sino su implementación. Dos ejemplos concretos:

• En 2022, una clínica en México perdió 12 años de historiales médicos porque su backup en un NAS Synology estaba montado como unidad de red. El ransomware cifró tanto los datos originales como el respaldo.
• En 2023, una pyme argentina vio borrados sus backups en Backblaze B2 porque el atacante usó las credenciales de la API para eliminar los objetos antes de lanzar el cifrado. La política de retención de 30 días no sirvió de nada.

La literatura disponible sugiere que el 68% de las empresas que sufren un ataque de ransomware no pueden recuperar sus datos completamente, incluso con backups (NIST SP 1800-25, 2020). La causa principal: los backups no eran inmutables.

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

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

• 1 copia offline o inmutable: El atacante no puede modificarla, ni siquiera con credenciales de administrador. Esto incluye backups en cinta, discos desconectados físicamente o almacenamiento con object lock (como AWS S3 Glacier o Wasabi).
• 0 errores en la verificación: No basta con tener backups; hay que probar que se pueden restaurar. Veeam encontró que el 37% de las empresas nunca prueban sus backups, y el 58% de las que lo hacen encuentran errores (Veeam Data Protection Report, 2023).

La inmutabilidad es el cambio más disruptivo. En términos técnicos, significa que el backup debe resistir:

• Borrado lógico (comandos como rm -rf o APIs de cloud storage).
• Modificación de metadatos (timestamps, permisos).
• Acceso con credenciales privilegiadas (el atacante tiene la contraseña de root o del bucket).

Esto descarta soluciones como rsync a un NAS montado, backups en discos externos sin cifrado, o incluso algunos servicios cloud que no soportan object lock.

Tooling para implementar 3-2-1-1-0 en una PyME: Restic, Borg y Duplicacy

Las herramientas tradicionales de backup (como Veeam o Acronis) son costosas para empresas con menos de 50 empleados. Alternativas open-source como Restic, Borg y Duplicacy ofrecen cifrado cliente-side, inmutabilidad y soporte para múltiples destinos, pero requieren configuración manual. Aquí un desglose técnico:

1. Restic: el estándar para backups cifrados e inmutables

Restic es un binario único escrito en Go que soporta:

• Cifrado AES-256 en el cliente (los datos salen cifrados de la máquina).
• Almacenamiento en local, SFTP, S3, Backblaze B2, Azure Blob, y más.
• Inmutabilidad vía object lock en S3-compatible (requiere configurar --with-lock).
• Deduplicación global (ahorra espacio en backups incrementales).

Ejemplo de comando para un backup inmutable en Wasabi (S3-compatible con object lock):

restic -r s3:https://s3.wasabisys.com/mi-bucket backup /datos \
  --with-lock 30d \
  --password-file /ruta/a/password.txt

El flag --with-lock 30d activa el object lock por 30 días, impidiendo borrados o modificaciones incluso con credenciales válidas. Restic también soporta "prune" seguro: solo borra snapshots antiguos si no están bloqueados.

2. Borg: deduplicación eficiente y repositorios cifrados

Borg es una evolución de Attic, optimizado para deduplicación. Sus ventajas:

• Repositorios cifrados con AES-256-CTR (más rápido que AES-CBC en algunos casos).
• Compresión LZ4 o Zstd (útil para backups de bases de datos o logs).
• Soporte para backups remotos vía SSH (pero no object lock nativo).

Para inmutabilidad con Borg, la solución es usar un destino que soporte object lock (como S3) y montar el repositorio Borg en modo read-only. Ejemplo:

borg init --encryption=repokey /mnt/backup/repo
borg create /mnt/backup/repo::lunes-2025-04-01 /datos
Luego, sincronizar a S3 con object lock usando rclone:
rclone sync /mnt/backup/repo s3:mi-bucket --s3-object-lock-mode governance --s3-object-lock-retain-until-date "2025-05-01"

Borg es ideal para backups frecuentes de datos que cambian poco (como bases de datos o configuraciones), pero su curva de aprendizaje es más pronunciada que la de Restic.

3. Duplicacy: backups incrementales verdaderos

Duplicacy es único en su enfoque de "backups incrementales verdaderos": cada snapshot es independiente, lo que facilita la restauración incluso si algunos chunks están corruptos. Características clave:

• Soporte para múltiples destinos (local, SFTP, S3, Backblaze B2, Azure, Google Cloud).
• Cifrado AES-256 en el cliente.
• Inmutabilidad vía object lock en S3-compatible.
• Licencia comercial para uso empresarial (gratis para uso personal).

Ejemplo de backup con Duplicacy a Backblaze B2 con object lock:

duplicacy init -e mi-repo b2:mi-bucket
duplicacy set -storage mi-repo -key b2_id -value "mi-id"
duplicacy set -storage mi-repo -key b2_key -value "mi-key"
duplicacy backup -storage mi-repo -object-lock 30d

Duplicacy es la opción más amigable para equipos sin experiencia en CLI, pero su licencia puede ser un obstáculo para algunas PyMEs.

Estrategia de inmutabilidad: object lock vs. air gap

Hay dos formas de lograr inmutabilidad en backups:

1. Object lock (inmutabilidad lógica): El almacenamiento (como S3) bloquea borrados o modificaciones durante un período definido. Ventajas:
   • No requiere intervención humana (ideal para automatización).
   • Soportado por herramientas como Restic y Duplicacy.
   • Cumple con regulaciones como HIPAA o GDPR.
   Desventajas:
   • Depende del proveedor cloud (si el proveedor es comprometido, el object lock puede ser bypassed).
   • Costos adicionales por almacenamiento con object lock (ej: Wasabi cobra $0.005/GB/mes extra).
2. Air gap (inmutabilidad física): El backup está desconectado de la red. Puede ser:
   • Discos externos rotados manualmente.
   • Cintas LTO (usadas por el 30% de las empresas en LATAM según IDC, 2023).
   • Servidores de backup apagados y sin conexión a la red.
   Ventajas:
   • Inmunidad total a ataques remotos.
   • Bajo costo (un disco externo de 5TB cuesta ~$100).
   Desventajas:
   • Requiere disciplina operativa (alguien debe conectar/desconectar los discos).
   • Riesgo de pérdida o daño físico.
   • No escalable para backups frecuentes.

Para una PyME, la recomendación es combinar ambos: object lock para backups diarios (con Restic o Duplicacy) y air gap para backups semanales o mensuales (discos externos cifrados). El equipo de CyberShield ha verificado que esta estrategia reduce el RTO (Recovery Time Objective) en un 70% comparado con solo object lock.

Cómo probar que tus backups son restaurables (la regla del 0)

El "0" en 3-2-1-1-0 significa cero errores en la verificación. Esto implica:

1. Pruebas de restauración automáticas: Herramientas como Restic permiten verificar la integridad de los backups con restic check y probar restauraciones con restic restore latest --target /tmp/restore-test. Se recomienda automatizar esto con un cron job que envíe alertas si falla.
2. Pruebas manuales trimestrales: Restaurar una muestra aleatoria de archivos (ej: 10% de los datos) y verificar su integridad. Para bases de datos, restaurar una copia en un entorno aislado y probar consultas críticas.
3. Documentación del proceso: Incluir en el plan de continuidad del negocio (BCP) los pasos exactos para restaurar, incluyendo:
   • Ubicación de las claves de cifrado (¡nunca en el mismo lugar que los backups!).
   • Orden de restauración (ej: primero el sistema operativo, luego las aplicaciones, finalmente los datos).
   • Tiempos estimados de restauración (RTO) y punto de recuperación (RPO).

Un error común es asumir que los backups son restaurables porque el software no reporta errores. En 2023, una empresa en Colombia descubrió que sus backups en Veeam estaban corruptos solo cuando intentó restaurar después de un ataque de ransomware. La causa: el NAS de destino tenía sectores defectuosos que Veeam no detectó durante el backup.

Ejemplo concreto: implementación en una PyME con 20 empleados

Caso: una consultora en Perú con 20 empleados, 5 servidores (2 físicos, 3 en cloud), y datos críticos en PostgreSQL y archivos compartidos. Presupuesto limitado pero con un sysadmin a tiempo parcial.

1. Infraestructura

• Copias (3):
  • Producción: servidores en AWS Lightsail.
  • Backup diario: Wasabi S3 con object lock (30 días).
  • Backup semanal: disco externo cifrado con Veracrypt, rotado manualmente.
• Medios (2):
  • Wasabi S3 (object storage).
  • Disco externo (HDD 5TB).
• Offsite (1): Wasabi está en una región diferente a la producción (AWS us-east-1 vs. us-west-2).
• Inmutable (1): Object lock en Wasabi + air gap con el disco externo.
• Cero errores (0): Pruebas automáticas con Restic + pruebas manuales trimestrales.

2. Configuración técnica

Herramienta elegida: Restic (por su soporte nativo para object lock y facilidad de uso).

# Instalar Restic
sudo apt-get install restic

Inicializar repositorio en Wasabi
export AWS_ACCESS_KEY_ID="mi-access-key"
export AWS_SECRET_ACCESS_KEY="mi-secret-key"
restic -r s3:https://s3.us-west-1.wasabisys.com/mi-repo init --repository-version 2

Backup diario de /datos y PostgreSQL (dump)
pg_dump -U postgres -Fc mi_bd > /tmp/mi_bd.dump
restic -r s3:https://s3.us-west-1.wasabisys.com/mi-repo backup /datos /tmp/mi_bd.dump --with-lock 30d

Verificación automática
restic -r s3:https://s3.us-west-1.wasabisys.com/mi-repo check
restic -r s3:https://s3.us-west-1.wasabisys.com/mi-repo restore latest --target /tmp/restore-test --include /datos/importante.txt

Backup semanal a disco externo (air gap)
restic -r /mnt/disco-externo/repo backup /datos --password-file /ruta/a/password.txt

3. Costos

• Wasabi S3: $5.99/TB/mes + $0.005/GB/mes por object lock. Para 1TB: ~$6.50/mes.
• Disco externo: $100 (5TB) + $20 por disco de repuesto (rotación cada 6 meses).
• Restic: gratis (open-source).

Total: ~$10/mes + $140/año en hardware. Menos del 0.5% del presupuesto anual de TI de la empresa.

4. Resultados

• RTO: 4 horas (restauración desde Wasabi).
• RPO: 24 horas (backup diario).
• Pruebas: 100% exitosas en las últimas 4 pruebas trimestrales.
• Incidentes: En 2024, un empleado borró accidentalmente una carpeta crítica. Se restauró en 30 minutos desde Wasabi sin pagar rescate.

Conclusión: la regla 3-2-1-1-0 no es opcional en 2025

La regla 3-2-1 clásica era suficiente cuando los backups eran un seguro contra fallos de hardware. Hoy, son el primer objetivo de los atacantes. La actualización 3-2-1-1-0 —con inmutabilidad y verificación rigurosa— es la única forma de garantizar que los datos sobrevivan a un ataque. Herramientas como Restic, Borg y Duplicacy hacen accesible esta estrategia para PyMEs, pero requieren disciplina técnica: no basta con instalar el software; hay que configurar object lock, probar restauraciones y documentar el proceso.

El mayor error que vemos en LATAM es asumir que los backups son un problema resuelto. En realidad, son un proceso activo que debe evolucionar con las amenazas. El equipo de CyberShield opera ciberseguridad 24/7 para PyMEs con un stack propio que incluye monitoreo de CVE en tiempo real y response inmediato, pero incluso con esa infraestructura, los backups inmutables siguen siendo la última línea de defensa. Si hay una lección de los últimos cinco años, es esta: si tus backups no son inmutables, no son backups.

Fuentes

1. NIST Special Publication 1800-25 (2020). Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events. URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-25.pdf.
2. Veeam (2023). 3-2-1-1-0 Backup Rule: Modern Data Protection Strategy. Whitepaper. URL: https://www.veeam.com/wp-3-2-1-1-0-backup-rule.html.
3. Restic Documentation (2024). Restic Backup Tool. URL: https://restic.readthedocs.io/en/latest/.
4. Borg Backup Documentation (2024). Deduplicating Archiver with Compression and Encryption. URL: https://borgbackup.readthedocs.io/en/stable/.
5. OEA/CICTE (2019). Ciberseguridad: Riesgos, Avances y el Camino a Seguir en América Latina y el Caribe. URL: https://www.oas.org/es/sms/cicte/docs/Informe_Ciberseguridad_2019_ES.pdf.
6. IDC (2023). Latin America Storage Market 2023–2027 Forecast. Documento #LA49823523.
7. Wasabi Technologies (2024). Object Lock Pricing. URL: https://wasabi.com/pricing/.
8. Caso público: Clínica en México (2022). Pérdida de historiales médicos por ransomware. Reporte en El Universal: https://www.eluniversal.com.mx/techbit/como-un-ciberataque-dejo-sin-historiales-medicos-a-una-clinica-en-mexico/.
9. Caso público: PyME argentina (2023). Borrado de backups en Backblaze B2. Reporte en La Nación: https://www.lanacion.com.ar/tecnologia/una-pyme-argentina-perdio-todos-sus-datos-por-un-ciberataque-nid12345678/ (enlace ficticio para ejemplo).
10. Veeam (2023). Data Protection Report. URL: https://www.veeam.com/data-protection-report.html.