La copia 3-2-1 no basta contra ransomware: falta aislarla y probarla

Para recuperar datos tras un ataque de ransomware, distribuya las copias y asegure que al menos una sobreviva al compromiso de los sistemas y las cuentas administrativas. La guía de ENISA propone la regla 3-2-1: tres copias —el original y dos respaldos—, dos tipos de medio y una copia en otra ubicación; además, recomienda proteger los respaldos mediante inmutabilidad o almacenamiento fuera de línea y probar su recuperación.

El recuento de copias es solo el comienzo del plan. En su guía sobre Veeam Data Platform, el CCN-CERT presenta la ampliación 3-2-1-1-0: añade una copia fuera de línea, aislada o inmutable y cero errores en copias previamente probadas y verificadas como recuperables. Para llevarla a la práctica, hay que identificar quién puede borrar cada respaldo, cómo se obtienen sus claves y cuándo se restauró una versión utilizable.

Defina qué debe volver a funcionar

Empiece por los datos y servicios necesarios para reanudar la actividad: archivos de trabajo, bases de datos y configuraciones de las aplicaciones. Para cada conjunto, establezca cuánto trabajo puede perderse entre una copia y la siguiente, y cuánto tiempo puede esperar la organización para volver a usarlo. Esas necesidades determinan la frecuencia de respaldo, la retención y el orden de restauración; aplicar el mismo calendario a todos los sistemas puede dejar sin una versión suficientemente reciente los cambios más importantes.

Localice también las dependencias de cada servicio. Restaurar una base de datos no devuelve una aplicación operativa si faltan su configuración, sus permisos o una clave necesaria para leer los datos. Anote qué componentes deben recuperarse juntos y cuáles pueden esperar. Esa relación servirá para elegir una prueba que reproduzca la recuperación del servicio, en lugar de limitarse a abrir un archivo suelto.

Aísle una copia y siga los permisos de borrado

Una ubicación externa reduce la exposición a un incidente físico local, pero no separa por sí sola los permisos. Dos repositorios distantes pueden depender de la misma identidad administrativa. Para las copias en la nube, los principios del NCSC recomiendan impedir que las cuentas del cliente, incluidas las de administradores y agentes automáticos, borren o sobrescriban todos los respaldos. También contemplan versiones anteriores, una vía de acceso cuando fallen las identidades corporativas y alertas que lleguen aunque la infraestructura habitual esté comprometida.

Revise los permisos efectivos de cada destino. Compruebe si alguien que administra producción puede acortar la retención, desactivar la protección, borrar versiones o cerrar la cuenta con la que se solicitan. Si una sola identidad puede inutilizar todas las copias, separe la administración del respaldo y establezca una autorización adicional para las acciones destructivas. La misma revisión debe incluir las cuentas de máquina: un agente de copia con permisos excesivos abre otra ruta hacia el repositorio.

Una copia fuera de línea queda desconectada después de escribirse; su utilidad depende de la rotación, la custodia y la posibilidad de encontrar una versión suficientemente reciente. La inmutabilidad protege las versiones existentes durante un periodo definido. En ese caso, verifique cuándo vence la protección y quién puede modificar la política para versiones futuras. Ninguno de los dos mecanismos permite prescindir de una versión anterior a los datos dañados ni de una vía para leerla.

Proteja las claves y el acceso de recuperación

Si el respaldo está cifrado, su supervivencia no basta: también debe conservarse la clave que permite descifrarlo. Registre dónde se guarda, quién puede modificarla o eliminarla y cómo se obtendrá si el sistema principal de identidad deja de estar disponible. Mantenga la información necesaria para recuperarla separada tanto de los datos respaldados como de las credenciales usadas a diario.

Plantee la recuperación con el directorio corporativo y las cuentas habituales fuera de servicio. Debe quedar claro qué persona está autorizada para solicitar el acceso, cómo acreditará su identidad y qué pasos dependen del proveedor del almacenamiento. Ensaye esa vía durante una restauración programada. Revise además dónde se reciben los avisos de borrados masivos, cambios de retención o modificaciones de cuentas privilegiadas: una alerta enviada únicamente al entorno afectado puede pasar inadvertida cuando más se necesita.

Restaure una versión y compruebe el servicio

El mensaje «copia completada» acredita que terminó una tarea, no que el servicio pueda volver a funcionar. Elija una versión anterior y recupérela en un entorno aislado. Compruebe que los archivos se abren o, si se trata de una aplicación, que esta funciona con sus datos y su configuración. Incluya en el ejercicio la obtención de claves, la autorización de acceso al repositorio y el tiempo transcurrido hasta disponer de un resultado utilizable.

Repita las pruebas según la importancia y la velocidad de cambio de cada sistema, y después de cambios relevantes en el respaldo. Guarde la fecha, la versión elegida, el resultado y los fallos pendientes. Defina la retención por tiempo además de revisar la cantidad de versiones: si una serie rápida de copias dañadas desplaza todas las anteriores, puede desaparecer el punto de recuperación que se necesitaba. Una prueba fallida señala qué parte del proceso hay que corregir antes de confiar en esa copia.

Plantilla de auditoría para cada copia

Registre una fila por copia, incluso si varias comparten proveedor. La tabla debe mostrar tanto dónde están los datos como las dependencias capaces de dejarlos inaccesibles:

• Datos y ubicación: sistema cubierto, repositorio y lugar o servicio donde reside la copia; indique si permanece conectada.
• Medio y calendario: tipo de almacenamiento, frecuencia de creación y antigüedad de la última versión disponible.
• Credenciales: identidades humanas y de máquina que pueden leer, modificar, borrar o cambiar la retención; señale cuáles también administran producción.
• Retención y aislamiento: periodo de conservación, protección frente a cambios y cuenta capaz de alterarla o desactivarla.
• Claves: ubicación, responsables de custodia y método de recuperación si falla el acceso habitual.
• Última restauración probada: fecha, versión, destino, comprobación del funcionamiento, tiempo empleado y errores abiertos.

Con las filas completas, siga el alcance de una cuenta administrativa comprometida a través de repositorios, políticas y claves. Si esa cuenta todavía puede inutilizar todas las versiones recuperables, corrija la dependencia compartida y vuelva a probar la restauración con la nueva configuración.

Lee también:

• Cómo aislar agentes de IA sin falsear una prueba de ciberseguridad
• Borrar Mi Actividad no limpia el navegador: hacen falta dos pasos
• El ransomware roba 896 TB: la cifra de Zscaler no mide solo víctimas