Backups que sobreviven a un ransomware:

la regla 3-2-1 y las copias inmutables

Resiliencia y continuidad  |  unfantasmaenelsistema.com

Durante años, hacer copias de seguridad fue sobre todo una defensa contra el hardware que falla, el borrado accidental y el incendio de la oficina. El ransomware moderno ha cambiado las reglas: ya no se conforma con cifrar los ficheros de producción, sino que busca activamente las copias de seguridad, las borra o las cifra, y solo entonces lanza la nota de rescate. Un backup que el atacante puede alcanzar con las mismas credenciales que usó para entrar no es un backup, es un fichero más esperando su turno.

Este artículo repasa la regla que resume medio siglo de experiencia en copias de seguridad —la 3-2-1— y cómo se adapta a un adversario que va a por ellas: inmutabilidad real, aislamiento físico o lógico, cifrado con la clave bien custodiada, y lo que casi nadie hace pero es lo único que de verdad importa el día malo: probar la restauración antes de necesitarla.

1. La regla 3-2-1, y por qué sigue vigente

La formulación clásica cabe en una línea: tres copias de tus datos, en dos tipos de soporte distintos, con una de ellas fuera de las instalaciones. Las tres copias incluyen el original en producción, así que en la práctica hablas de los datos vivos más dos copias adicionales. La idea de fondo es que ningún evento único —un disco que muere, un cifrado masivo, un rayo, un robo— pueda alcanzar a la vez todas las instancias de un dato.

1.1 Qué cubre cada número

• Tres copias: si una copia tiene una probabilidad razonable de fallar, tres copias independientes hacen que el fallo simultáneo de todas sea muy improbable — siempre que sean de verdad independientes
• Dos soportes distintos: disco interno y disco externo, disco y cinta, cabina local y almacenamiento de objetos en la nube. Evita que un defecto común (un firmware, un formato, un lote de discos) se lleve todas las copias
• Una fuera: una copia en otro edificio, otra ciudad u otro proveedor. Cubre los desastres que afectan a una ubicación entera: incendio, inundación, robo, o un atacante con acceso a toda la red local

1.2 La ampliación 3-2-1-1-0

La versión moderna añade dos dígitos. El primer 1 extra exige que al menos una de las copias esté offline, con air gap o sea inmutable: fuera del alcance de cualquiera que controle tus sistemas. El 0 final significa cero errores en la verificación: cada copia se comprueba y cada restauración de prueba se completa sin fallos. Sin ese cero, no sabes si tienes una copia o un fichero corrupto con nombre de copia.

2. Por qué el ransomware va primero a por las copias

Los operadores de ransomware saben que su modelo de negocio depende de que no puedas restaurar. Por eso el cifrado de los ficheros de usuario suele ser la última fase de la intrusión, no la primera. Antes de eso, tras semanas de reconocimiento con credenciales robadas, el atacante dedica tiempo específico a neutralizar la recuperación.

3. Inmutabilidad real: copias que ni tú puedes borrar

Una copia es inmutable cuando, una vez escrita, no se puede modificar ni borrar hasta que expira un plazo fijado de antemano — y ese plazo no lo puede acortar nadie, ni el administrador, ni una cuenta comprometida, ni el propio proceso de backup. Es la diferencia entre «prometemos no borrarlo» y «el sistema no permite borrarlo».

3.1 Formas de conseguirla

• Object Lock en almacenamiento de objetos (S3 y compatibles, Backblaze B2, Wasabi, MinIO): cada objeto se marca con una retención. En modo gobernanza una identidad con permiso especial puede levantarla; en modo cumplimiento (compliance) no puede nadie hasta que expira
• WORM en cinta y en cabinas: la cinta LTO tiene modo WORM físico; muchas cabinas ofrecen snapshots o volúmenes WORM que el propio equipo protege
• Snapshots inmutables del repositorio de backup: soluciones como el repositorio endurecido de Veeam, ZFS con snapshots administrados por un usuario aparte, o los modos append-only de restic y borg, donde el cliente puede añadir pero no eliminar
• Retención bloqueada en el servicio de backup en la nube: el proveedor impide reducir la retención o borrar puntos de recuperación durante el plazo pactado

3.2 El detalle que hace que funcione: la separación de identidades

La inmutabilidad solo sirve si la identidad que escribe las copias no es la misma que puede cambiar la política de retención. Si el mismo token que sube los backups también puede desactivar el Object Lock, el atacante que roba ese token lo tiene todo. El patrón correcto: una credencial que solo puede escribir objetos nuevos y leer, y una cuenta administrativa distinta —con MFA y sin uso diario— para la configuración.

4. Air gap: aislamiento físico y aislamiento lógico

Air gap es la ausencia de un camino por el que un atacante pueda llegar a la copia. Puede ser físico o lógico, y ambos son válidos si se implementan con disciplina.

En una pyme, el air gap físico más simple y eficaz sigue siendo un juego de dos o tres discos externos que se rotan: uno conectado para la copia de hoy, los demás guardados fuera del edificio. Es rudimentario, pero un disco en un cajón de otra oficina es inmune a cualquier cosa que pase por la red.

5. El 3-2-1 en casa y en una pyme

No hace falta una cabina cara para cumplir la regla. Con herramientas libres como restic, borg o Kopia y un poco de método, un particular o una pyme pequeña tiene un 3-2-1-1-0 completo.

5.1 Un montaje de ejemplo

• Copia 1 (local, rápida): restic o borg a un disco externo o un NAS de casa. Es la que usas para recuperar un fichero que has borrado sin querer
• Copia 2 (remota): el mismo restic, en modo append-only, contra un almacenamiento de objetos con Object Lock (B2, Wasabi, S3). Es la que sobrevive al ransomware y al incendio
• Copia 3 (offline, rotatoria): una vez al mes, una copia a un disco que luego se desconecta y se guarda en otro sitio físico. Es el seguro contra el fallo de las otras dos
• El 0: un script mensual que monta la copia remota, restaura un subconjunto a una carpeta temporal y compara hashes; y una restauración completa de prueba una o dos veces al año

# restic: repositorio remoto en almacenamiento de objetos con Object Lock
export RESTIC_REPOSITORY="s3:s3.eu-central.example.com/mi-bucket-backup"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"   # clave de cifrado, NO en el repo
 
# Copia diaria (el bucket aplica retencion/immutability del lado del servidor)
restic backup /datos /etc /home --tag diaria --exclude-caches
 
# Politica de retencion en el cliente (no borra lo que el Object Lock aun protege)
restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
 
# Verificacion: integridad del repo + lectura real de una fraccion de los datos
restic check --read-data-subset=5%
 
# Prueba de restauracion a una carpeta temporal
restic restore latest --target /tmp/restore-test --include /etc

6. Cifrado del backup y custodia de la clave

Una copia fuera de tus instalaciones está, por definición, en manos de otro: un proveedor de nube, un centro de datos, el maletero del coche camino de la otra oficina. Debe ir cifrada en origen, antes de salir, de modo que quien tenga el soporte no tenga los datos. restic, borg y Kopia cifran por defecto; en otras soluciones hay que activarlo explícitamente.

El problema se traslada entonces a la clave. Una clave de cifrado que se pierde convierte todas las copias en ruido, y una clave que solo existe en el servidor que se ha cifrado no sirve de nada el día del incidente.

• Guarda la clave (o la frase de contraseña del repositorio) fuera de los sistemas que respalda: en un gestor de contraseñas con su propia copia, impresa en un sobre en una caja fuerte, en el módulo de seguridad de la organización
• Ten al menos dos personas con acceso a la clave en una organización; una sola persona es un punto único de fallo humano
• Documenta el procedimiento de recuperación completo —incluida la clave— y guárdalo con las copias offline, no solo en la intranet que quizá no puedas abrir ese día

7. Lo único que de verdad importa: probar la restauración

Un backup no verificado es una hipótesis. La mayoría de los fracasos de recuperación no vienen de que no hubiera copias, sino de que las copias estaban incompletas, corruptas, cifradas con una clave que nadie encontraba, o tardaban tanto en restaurarse que el negocio ya había asumido pérdidas mayores que el rescate.

7.1 Un calendario mínimo de pruebas

De cada prueba salen dos números que deberías conocer y que rara vez coinciden con lo que se supone: el RPO real (cuántos datos pierdes, es decir, cada cuánto hay una copia buena) y el RTO real (cuánto tardas en volver a operar). Si no los has medido restaurando, no los sabes.

Conclusión

El ransomware ha convertido el backup en un objetivo, así que la copia que cuenta no es la más reciente ni la más rápida, sino la que el atacante no puede tocar: inmutable o desconectada, en otra cuenta o en otro edificio, cifrada con una clave que tú custodias aparte. La regla 3-2-1-1-0 no es burocracia: cada dígito tapa una forma concreta en que las copias fallan.

Y si te quedas con una sola frase: la copia de seguridad no existe hasta que has restaurado desde ella. Pon una prueba de restauración en el calendario esta semana, antes de que la ponga el atacante.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)