Saltar al contenido

Checklist: ¿tu backup resiste un ransomware?

Marca lo que ya está así hoy. Al final aparece una nota y, para cada punto pendiente, qué hacer. Sirve para cualquier herramienta de backup que grabe en un bucket S3; los atajos apuntan a Arkame cuando tiene el camino listo.

Nada sale de tu navegador: las respuestas quedan guardadas solo en este dispositivo, y puedes borrarlas cuando quieras.

  1. Por qué: Sin versiones, un archivo cifrado sobrescribe el bueno, y el backup siguiente copia el daño.

  2. Por qué: El versionado solo no protege contra quien tiene la clave: borra las versiones. Object Lock sin retención predeterminada tampoco protege nada.

  3. Por qué: En Governance, quien tiene el permiso adecuado puede saltarse el bloqueo. En Compliance, nadie borra antes del plazo.

  4. Por qué: El ransomware suele quedarse quieto antes de actuar. Si la retención vence antes de que lo notes, las versiones buenas ya pueden haber salido.

  5. Por qué: Un bucket público expone los backups a cualquiera que descubra la dirección.

  6. Por qué: Una clave de toda la cuenta, filtrada desde el servidor, abre todos los buckets y toda la configuración.

  7. Por qué: Con Object Lock, Arkame no borra ninguna versión; el permiso que sobra solo sirve a quien robe la clave.

  8. Por qué: La copia olvidada de la contraseña es la puerta que nadie vigila.

  9. Por qué: Una copia al alcance del servidor se cifra junto con él; una copia en el mismo edificio se pierde en el mismo incendio.

  10. Por qué: Un backup manual es el backup de cuando alguien se acordó.

  11. Por qué: Un backup que nunca se restauró sigue siendo una hipótesis, y el día del ataque es el peor día para descubrirlo.

  12. Por qué: Copiar los archivos de una base en uso suele generar una copia que no abre.

  13. Por qué: Un backup detenido en silencio se descubre el día en que se necesita.

  14. Por qué: Con la contraseña de quien administra, el atacante apaga el backup o borra lo que no esté bloqueado.

Resultado

0 de 14 puntos cumplidos

En riesgo

Falta al menos un punto esencial. Empieza por ellos: son los que deciden si el backup sobrevive al ataque.

Lo que falta

  • El versionado está activado en el bucket del backup.esencial

    Qué hacer: Activa el versionado en el bucket: Backblaze B2 (ya viene activado), Wasabi, AWS. El agente de Arkame rechaza buckets sin versionado.

  • El Object Lock está activado, con una retención predeterminada en el bucket.esencial

    Qué hacer: En Wasabi, el Object Lock solo se activa al crear el bucket: crea uno nuevo y apunta el plan a él. En B2, actívalo también al crear, porque la retención predeterminada lo requiere. Paso a paso: Backblaze B2, Wasabi, AWS.

  • La retención predeterminada está en modo Compliance, no Governance.esencial

    Qué hacer: Cambia el modo de la retención predeterminada del bucket a Compliance. En Wasabi viene en Governance por defecto: mira cómo cambiarlo.

  • El bucket es privado: nada de acceso público.esencial

    Qué hacer: Quita el acceso público en la configuración del bucket en el proveedor (lo que todo bucket necesita).

  • La clave del backup es solo suya y solo abre ese bucket. No es la clave maestra ni la cuenta raíz del proveedor.esencial

    Qué hacer: Crea una clave limitada al bucket (política de acceso), cámbiala en el servidor con arkame-agent set-storage-keys --restart (comandos) y revoca la antigua en el proveedor.

  • El backup queda fuera del servidor protegido y fuera del edificio.esencial

    Qué hacer: Envía el backup a un bucket en un proveedor de nube (compara los costos). Con un MinIO en el mismo edificio, el bucket existe, pero no está fuera del sitio.

  • Alguien restauró un archivo del backup en el último mes, y se abrió.esencial

    Qué hacer: Restaura un archivo en una carpeta nueva y ábrelo. En Arkame, en Restaurar, por búsqueda, carpetas o línea de tiempo (restauración). Anótalo en la agenda: cada mes.

  • La retención dura más de lo que tardarías en notar un ataque (30 días es un buen comienzo).

    Qué hacer: Aumenta la retención predeterminada del bucket. Recuerda que también es el tiempo en que nadie puede borrar nada, ni tú: pésalo contra el costo de guardar.

  • Con Object Lock, la clave del agente no tiene permiso para borrar versiones (donde el proveedor deja elegir).

    Qué hacer: En AWS y Wasabi, quita s3:DeleteObjectVersion de la política (por qué). Ojo: en un bucket sin Object Lock, la limpieza de la retención de Arkame lo necesita.

  • La contraseña de la clave no está en una hoja de cálculo, chat, correo o repositorio.

    Qué hacer: Genera una clave nueva, cámbiala en el servidor (comandos), revoca la antigua y borra las copias. En Arkame, la clave solo existe en el servidor: el panel nunca la recibe.

  • El backup se ejecuta solo, con horario, sin depender de que alguien se acuerde.

    Qué hacer: En Arkame, dale un horario al plan (diario o cada algunas horas) en Planes (planes).

  • Las bases de datos entran en el backup como dump, no como los archivos de la base abierta.

    Qué hacer: Genera un dump antes del backup: en Arkame, con el comando de antes del backup del plan; con el agente en Docker, donde esos comandos no se ejecutan, programa el dump en el propio servidor (cron) en una carpeta incluida en el plan (detalles).

  • Llega un aviso cuando un backup falla o un servidor deja de responder, y alguien lee ese correo.

    Qué hacer: En Arkame, verifica en Configuración → Organización → Avisos por correo que los dos avisos están activados. Van al correo de facturación de la cuenta: asegúrate de que llegue a quien actúa.

  • La consola del proveedor y el panel de backup piden verificación en dos pasos.

    Qué hacer: Activa la verificación en dos pasos en la consola del proveedor y, en Arkame, en Configuración → Perfil.