El peor momento para descubrir que tu backup no sirve

Muchas organizaciones hacen backups todos los días. Tienen políticas definidas, almacenamiento reservado y tareas automatizadas. Aun así, un ataque puede dejarlas sin una copia utilizable.

Algo que pasa muy seguido es que producción y respaldo comparten demasiado (infraestructura, credenciales, permisos y accesos administrativos), y eso es un peligro enorme.

Los ataques de ransomware pueden avanzar también sobre las copias de seguridad, de hecho es lo que más sucede. Localizarlas, modificarlas o eliminarlas aumenta la presión sobre la organización porque reduce sus alternativas para volver a operar.

Por eso, revisar una arquitectura de backup implica mirar bastante más que la existencia de las copias.

Cuando el atacante también llega al backup

Una copia conectada a la misma infraestructura y administrada con credenciales que fueron comprometidas puede quedar expuesta junto con los sistemas productivos.

En ese escenario, el backup está ejecutándose correctamente durante meses, pero su valor se define en otro momento: cuando hay que restaurar.

Ahí aparecen preguntas mucho más concretas. ¿La copia sigue disponible? ¿Está completa? ¿Se puede confiar en ella? ¿Cuánto tiempo llevará recuperar los sistemas? ¿Qué debería restaurarse primero?

Una infraestructura preparada para recuperar la operación necesita contemplar un escenario adverso: que producción y backups sean atacados al mismo tiempo, también teniendo en cuenta una realidad que a todos nos da miedo, pero que está, y es que el ataque puede venir desde adentro de la propia organización.

Qué aporta la inmutabilidad

Un backup inmutable mantiene una copia que no puede modificarse ni eliminarse durante un período definido, incluso utilizando privilegios administrativos.

Eso permite conservar un punto de recuperación frente al ransomware, credenciales comprometidas, eliminaciones accidentales, errores de configuración o acciones internas maliciosas.

También cubre un problema menos evidente: los incidentes que se descubren días después de haberse producido. Si las copias fueron sobrescribiéndose durante ese tiempo, encontrar un estado confiable desde el cual restaurar puede ser difícil.

La inmutabilidad cumple una función muy específica dentro de la arquitectura: preservar una copia aunque el resto del entorno haya sido comprometido.

El costo aparece cuando hay que volver a operar

Pensar el backup solamente en términos de capacidad de almacenamiento deja afuera buena parte del problema.

Una restauración lenta o fallida puede detener procesos administrativos y comerciales, dejar equipos sin acceso a información, interrumpir servicios a clientes o ciudadanos y generar incumplimientos contractuales o regulatorios.

A eso se suman los costos extraordinarios de recuperación y las decisiones que deben tomarse bajo presión cuando las alternativas disponibles son pocas. Por eso conviene evaluar el backup junto con la continuidad operativa.

Una revisión seria debería permitir responder, al menos, estas preguntas:

• ¿Las copias están separadas de la infraestructura productiva?

• ¿Una credencial administrativa comprometida podría modificarlas o eliminarlas?

• ¿Existe una copia inmutable?

• ¿Las restauraciones se prueban periódicamente?

• ¿Están definidos los tiempos de recuperación y el orden en que deberían recuperarse los sistemas?

  
  

Un “no sabemos” en cualquiera de estos puntos merece atención. Durante un incidente, descubrir que una copia está incompleta o que restaurar llevará mucho más tiempo del esperado deja poco margen para corregir la arquitectura.

Tener un backup inmutable genera tranquilidad. Haber comprobado que existe una copia confiable, aislada y recuperable genera algo bastante más importante: una alternativa concreta para volver a operar.

Y esa diferencia suele hacerse visible en el peor momento posible.