Ransomware: qué revisar en tus copias antes de necesitarlas

Tener un backup no significa que puedas seguir operando después de un ransomware. La copia puede estar incompleta, ser inaccesible con las credenciales comprometidas o contener datos que ya fueron cifrados. La prueba decisiva es restaurar sistemas y datos prioritarios en un entorno limpio, dentro del tiempo que tu operación tolera.

La guía conjunta #StopRansomware de CISA recomienda mantener copias críticas desconectadas o aisladas, cifradas, y probar periódicamente su disponibilidad e integridad. Una herramienta de backup es parte de esa estrategia; no sustituye la prevención, la respuesta a incidentes ni las pruebas de recuperación.

1. Define qué necesitas recuperar primero

Haz un inventario de servicios y dependencias: ERP, archivos, correo, máquinas virtuales, bases de datos, configuraciones de red y credenciales necesarias para reconstruirlos. Ordena qué debe volver primero para que el negocio funcione. Después fija dos objetivos por servicio:

• RPO: cuántos datos puedes perder medidos en tiempo; determina la frecuencia necesaria de las copias.

• RTO: cuánto puede estar detenido el servicio; condiciona el método, la infraestructura y el orden de restauración.

No publiques un RPO o RTO como promesa al cliente si no lo has medido en un ensayo completo. El NIST ofrece una guía para MSP sobre creación, mantenimiento y prueba de copias frente a ransomware; úsala como criterio de revisión, no como certificación de una instalación específica.

2. Evita que el atacante alcance todas las copias

Separa al menos una copia de los sistemas y credenciales de producción. Según el entorno, esto puede implicar medios offline, un repositorio aislado o retención inmutable. Inmutable no significa invulnerable: protege versiones concretas durante un plazo definido, pero no corrige una copia defectuosa ni garantiza que toda la operación pueda restaurarse.

En Amazon S3, Object Lock protege versiones de objetos contra borrado o sobrescritura durante la retención configurada y requiere versionado. Sus modos Governance y Compliance tienen permisos y restricciones diferentes. Diseña el plazo de retención, acceso y costos con el equipo responsable antes de activarlo; una etiqueta «Object Lock» sin verificar la configuración no prueba protección.

3. Comprueba requisitos concretos de la herramienta

NAKIVO documenta opciones de inmutabilidad para determinados repositorios. Para Amazon S3 y algunos repositorios compatibles, su guía de requisitos exige Object Lock y versionado; la retención se configura en el trabajo de backup. Otras plataformas y tipos de repositorio tienen condiciones o exclusiones distintas. Confirma edición, versión, tipo de repositorio, licencias y configuración exacta antes de ofrecer esa función en una propuesta.

NAKIVO puede aportar funciones de backup y recuperación, pero no «previene el ransomware» por sí solo ni promete restaurar cualquier pérdida. La efectividad depende de que la copia incluya las cargas necesarias, se conserve íntegra, permanezca accesible para el equipo de recuperación y se haya probado en el entorno real.

4. Haz una restauración de prueba, no solo una captura de pantalla

Programa ejercicios con una copia seleccionada al azar dentro de la retención. Restaura una máquina o aplicación crítica en un entorno separado, valida consistencia de datos y permisos, mide el tiempo hasta que el servicio funciona y documenta lo que faltó. Incluye dependencias como DNS, credenciales, claves de cifrado, red y software. Si el ensayo falla, corrige el procedimiento y repítelo antes de confiar en él.

Antes de cotizar, reúne el inventario de cargas, RPO/RTO deseados, tamaño y crecimiento de datos, plataforma de virtualización, destino de almacenamiento, política de retención y responsable de la prueba. Hablemos de tu requerimiento: Tienda TIC puede ayudarte a comparar opciones y condiciones comerciales B2B. La arquitectura de seguridad, la implementación y la validación de recuperación deben quedar a cargo de los especialistas responsables del proyecto.

Fuentes principales: CISA; NIST; AWS; NAKIVO. Consultadas el 13 de octubre de 2026.

Artículo original del 19 de abril de 2024, revisado y actualizado el 13 de octubre de 2026.