Backup pull-only, por qué producción nunca debe alcanzar sus propios backups

La mayoría de los diseños de backup se hacen para el fallo que todos imaginan: un disco muerto, una tabla borrada, una actualización rota. El fallo que de verdad acaba con empresas es otro. Alguien entra en un servidor de producción, encuentra las credenciales del backup ahí mismo, y borra los backups antes de cifrar todo lo demás. Este artículo explica cómo diseñar backups que sobrevivan a ese día, con el patrón al que construimos nosotros: el lado del backup extrae, producción nunca empuja, y las claves que crean backups no pueden destruirlos.

El problema del push

El backup más simple es un cron en el servidor que copia los datos a un destino de backup. Es fácil de montar, y lleva un defecto estructural. Para empujar, el servidor de producción necesita una ruta hacia el destino de backup y credenciales que puedan escribir en él. Muy a menudo esas credenciales también pueden borrar, sobrescribir o hacer prune, porque la retención tiene que ocurrir en algún sitio y el cliente es el lugar obvio.

Así que el servidor que está protegiendo guarda las llaves de su propia protección. Quien se hace con ese servidor se hace con sus backups. Los operadores de ransomware lo saben, y lo primero que hace una intrusión competente es buscar agentes de backup, comparticiones de backup montadas y claves SSH que apunten a hosts de storage.

Montar una compartición de backup en el host de producción es la peor forma de esto. Una compartición en la que se puede escribir desde producción es, desde el punto de vista del atacante, simplemente más disco que cifrar.

Dé la vuelta a la flecha

La solución es invertir la dirección de la confianza. El sistema de backup inicia cada conexión. Entra en producción, toma lo que necesita y se va. Producción no tiene ruta de red hacia la infraestructura de backup y no guarda credenciales de ella.

Haga cumplir esto donde no pueda deshacerse desde un host comprometido: en el firewall entre las dos zonas, no en el firewall de host del servidor de backup. El conjunto de reglas es corto:

permit ip  host    ! admin access only
deny   ip any host                     ! production and everyone else
permit ip any any                                   ! leave other traffic alone

El host de backup en sí necesita acceso de salida hacia producción en los puertos que usa para recoger datos, y nada de entrada salvo desde gestión. Si una conexión desde un host de producción sigue teniendo éxito, el diseño no está en vigor, diga lo que diga el diagrama.

Esto es un patrón de diodo de datos en espíritu, y encaja limpiamente con los controles por los que preguntan los auditores: segregación de la infraestructura de backup, mínimo privilegio y protección de perímetro en ISO/IEC 27001, NIS2 y NIST SP 800-53.

Mínimo privilegio en el lado de producción

Extraer sigue significando que el host de backup inicia sesión en producción. Ese inicio de sesión debe ser inútil para cualquier cosa que no sea tomar un backup. Con SSH esto es directo: dé a la clave del host de backup un comando forzado y la opción restrict en authorized_keys del servidor de producción.

command="rrsync -ro /srv/www",restrict ssh-ed25519 AAAA... backup-files
command="/usr/local/bin/backup-dump",restrict ssh-ed25519 AAAA... backup-db

La primera clave solo puede leer la raíz web a través de rrsync en modo solo lectura. La segunda solo puede ejecutar un envoltorio de volcado que usted escribió, que toma un volcado consistente de la base de datos (para MySQL o MariaDB, desde una réplica o un nodo que no recibe escrituras, con --single-transaction o una herramienta física como Percona XtraBackup) y lo transmite a la salida estándar. Ninguna de las dos claves da una shell, reenvío de puertos ni reenvío de agente. Si el propio host de backup quedara comprometido, el atacante ganaría acceso de lectura a los datos de un cliente, no el control de producción.

Use claves distintas para trabajos distintos, y claves distintas para clientes distintos. El radio de impacto debería ser un trabajo de un cliente.

Haga el repositorio append-only

La segunda mitad del diseño es lo que ocurre en el lado del backup. Con BorgBackup, el archivador deduplicador, compresor y cifrador, un repositorio puede abrirse en modo append-only: se pueden escribir archivos nuevos, pero los datos existentes no se pueden borrar ni reescribir por esa vía de acceso.

Cuando Borg tiene que ejecutarse en el origen (por ejemplo, porque una raíz web contiene millones de ficheros pequeños y quiere que la deduplicación ocurra antes de que los datos crucen la red), puede seguir dejando el mando al hub. El hub abre la sesión SSH hacia el host de producción y proporciona un túnel inverso de vuelta hacia sí mismo, y la cuenta del extremo lejano de ese túnel está bloqueada en el hub:

command="borg serve --append-only --restrict-to-repository /srv/backup/tenants//borg",restrict ssh-ed25519 AAAA... customer-node

El host de producción nunca inicia nada; solo habla de vuelta por el túnel que abrió el hub, y solo con su propio repositorio, en modo append-only.

La retención se convierte entonces en un trabajo separado y local en el hub:

borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 /srv/backup/tenants//borg
borg compact /srv/backup/tenants//borg

Ejecútelo como un trabajo privilegiado en el propio host de backup, nunca por la vía que producción puede ver. Un atacante que cifra el servidor de un cliente puede, como mucho, escribir más archivos. No puede eliminar los antiguos.

Un repositorio, una clave, un cliente

En una plataforma de backup multicliente, dé a cada cliente su propio repositorio y su propia frase de paso, con el cifrado habilitado al crear el repositorio:

borg init --encryption=repokey-blake2 /srv/backup/tenants//borg

El aislamiento se sostiene entonces en la capa criptográfica, no solo en los permisos de fichero: los datos de un cliente no se pueden leer con la clave de otro, ni siquiera por alguien con una shell en el hub. La deduplicación sigue funcionando bien dentro de un cliente, y entre los nodos web casi idénticos de un mismo cliente el segundo nodo cuesta casi nada.

Demuéstrelo, no se fíe

Un trabajo de backup en verde le dice que el trabajo se ejecutó. No le dice que se cubrió cada máquina que importa, ni que los datos vuelven. Tres hábitos cierran ese hueco.

• Compruebe la cobertura contra el inventario vivo. Liste lo que está en ejecución, liste lo que tiene un backup reciente en disco, y compare. Cualquier cosa en ejecución sin un punto de restauración reciente es un hallazgo.
• Vigile la frescura, no el estado. Alarme sobre «horas desde el último archivo bueno» por cliente, de modo que un trabajo que deja de ejecutarse en silencio se note rápido.
• Restaure con una cadencia fija. Extraiga ficheros, restaure una base de datos en una instancia de pruebas y compruébela, con regularidad. Borg lo hace barato:

borg list /srv/backup/tenants//borg
borg extract --dry-run /srv/backup/tenants//borg::
borg check --verify-data /srv/backup/tenants//borg

Las restauraciones también siguen la regla pull-only. El host de backup, o un ingeniero, entrega los datos restaurados a producción. A producción nunca se le da acceso al repositorio, ni siquiera «solo para la restauración».

Qué comprobar en su propia plataforma

• ¿Puede algún servidor de producción abrir una conexión hacia su storage de backup? Pruébelo.
• ¿Permite alguna credencial de un servidor de producción borrar o hacer prune de backups?
• ¿Hay alguna compartición de backup montada, con escritura, en algún host de producción?
• ¿Están las claves de backup restringidas a un único comando, o dan una shell?
• ¿Está cada cliente o sistema en su propio repositorio cifrado con su propia clave?
• ¿Cuándo restauró algo por última vez, y comprobó el resultado?

Si alguna respuesta le incomoda, empiece por la regla del firewall. Es el control más barato de esta lista y elimina primero la ruta más peligrosa.

Si quiere un segundo par de ojos sobre su diseño de backup, nuestros ingenieros estarán encantados de ayudar. Hable con un ingeniero

Related

Relacionado: Backup gestionado en Veeam y Borg, pull-only · Recuperación ante desastres y réplicas entre sedes