Backups ante ransomware: cómo saber si realmente podrás recuperar

Tener respaldos no garantiza recuperar la operación después de ransomware. Para una gerencia, la pregunta es cuánto tiempo se detendrán pedidos y facturación, qué información podría perderse y qué evidencia demuestra que las copias son utilizables. Una política sin pruebas crea una confianza difícil de defender cuando ocurre un incidente.

Distinguir copiar de recuperar

Un respaldo de la base de datos no recupera por sí solo una aplicación. Puede depender de sistemas de identidad, certificados, archivos adjuntos, configuraciones, colas y conexión con terceros. El plan debe inventariar todos esos componentes y fijar el orden de recuperación. Si la gerencia espera recuperar un ERP en cuatro horas, TI debe demostrar que las dependencias permiten ese plazo. Una restauración de tablas sin pruebas funcionales no valida que la organización pueda volver a emitir documentos o atender clientes.

Acordar RPO y RTO por servicio

RPO expresa cuánto dato puede perderse y RTO el tiempo objetivo de recuperación. No se deducen del precio del producto: son compromisos que los dueños de procesos deben establecer y comprobar. Una plataforma de órdenes y un archivo histórico tienen necesidades distintas. Pregunte cuántas transacciones se generan cada hora y cuáles pueden reconstruirse. Cuando el proveedor asegura recuperación rápida, exija la línea base, condiciones, tamaño de datos y recursos necesarios para demostrarlo en una prueba reproducible.

Evitar que el atacante destruya las copias

Un atacante con credenciales administrativas puede buscar y borrar versiones de respaldo. Analice aislamiento, cuentas diferenciadas, cifrado, retención protegida e inmutabilidad cuando corresponda. La regla de varias copias deja de ser suficiente si todas dependen del mismo acceso comprometido. También deben protegerse llaves, catálogos y documentación para recuperar. Evalúe el costo de descargar grandes volúmenes desde proveedores externos. Un respaldo técnicamente existente puede no ser viable en los tiempos comerciales acordados.

Ensayar una recuperación completa

Prepare un entorno aislado y seleccione una aplicación representativa. Registre cuándo comienza el ejercicio, qué personal participa, qué errores aparecen y cuánto tarda en completarse una transacción de negocio. Valide integridad y permisos, no solo la notificación de éxito. Pruebe recuperación de claves, servidores, dependencias y versiones. El cierre debe incluir evidencia, tiempo real medido, hallazgos y una segunda prueba para las correcciones. Una práctica anual puede ser insuficiente si la arquitectura cambia cada mes.

Decisiones durante el incidente

Restaurar de inmediato puede reintroducir el compromiso. Coordine contención, investigación, elección de un punto de recuperación confiable y autorización de puesta en marcha. Defina por anticipado quién declara la contingencia, quién habla con clientes y quién aprueba riesgos al operar en modo degradado. Mantenga contactos y procedimientos disponibles incluso si el correo falla. La dirección necesita escenarios de recuperación parcial y criterios para decidir, en lugar de improvisar bajo presión.

Qué medir y cómo contratar

Pida porcentaje de servicios críticos con restauración probada, desviación real frente al RTO, edad de la última copia válida y cantidad de fallas pendientes. Evalúe almacenamiento, licencias, personal, conexión, costos de salida y asistencia durante una crisis. Las promesas genéricas deben convertirse en pruebas y compromisos explícitos. ZopiTech puede ayudar a medir la situación y diseñar controles proporcionados sin prometer que una tecnología aislada detendrá todos los incidentes.

Caso de decisión: el sistema de ventas no arranca

Imaginemos una empresa que conserva copias diarias de su ERP, pero cuya infraestructura de autenticación también fue afectada. El respaldo de la base de datos está intacto y el proveedor anuncia que puede restaurarlo en dos horas. Sin embargo, el equipo no recuerda qué certificados utilizaba la aplicación, las integraciones con facturación dependen de secretos almacenados en otro servidor y nadie ha probado el procedimiento completo. Para el directorio, la diferencia entre restaurar archivos y recuperar ventas se vuelve evidente. Un simulacro previo habría detectado esas dependencias y permitido conservar procedimientos accesibles fuera del entorno afectado. El ejercicio también sirve para estimar cuánto trabajo puede realizarse manualmente, qué errores se generan al reconstruir operaciones y qué clientes deben recibir información durante la recuperación.

Tres evidencias que exigir después de un ensayo

Primero, un registro temporal que muestre desde la declaración del incidente hasta la validación funcional del servicio, con los retrasos atribuibles a personas, red y aplicaciones. Segundo, una comprobación de integridad de datos mediante operaciones conocidas y reconciliación con fuentes externas cuando corresponda. Tercero, un plan de acciones con responsables y fecha de nueva prueba. No debe ocultarse que una copia fue recuperada en un laboratorio con recursos superiores a los disponibles durante una crisis real. Si el ensayo no alcanzó el RTO acordado, la gerencia debe decidir entre invertir, modificar el procedimiento o aceptar explícitamente una exposición mayor. La reducción de riesgo se demuestra al repetir y mejorar el ejercicio, no al adquirir otra licencia.

Para decidir los siguientes pasos

La primera inversión útil puede ser un simulacro controlado que descubra brechas en recuperación. Con ese resultado, gerencia y TI pueden priorizar capacidades con impacto demostrado.