Configurar nodos de copia de seguridad air-gapped en el centro de datos: diseño de red, hardware y sincronización

Nodos de backup con air‑gap — es decir, servidores de backup o sistemas de almacenamiento que están aislados física o lógicamente de la red de producción — son una medida consolidada para contrarRESTar el ransomware, los movimientos laterales y el compromiso de la red. Este documento práctico describe cómo planificar dichos nodos en el centro de datos, qué hardware y qué topologías de red son adecuadas, cómo se realiza técnicamente la sincronización segura y qué particularidades hay que tener en cuenta en bases de datos MySQL. Público objetivo: administradores, ingenieros de sistemas, operadores y proveedores técnicos de servicios IT.

¿Por qué nodos de backup con air‑gap? Riesgos y objetivos operativos

Un air‑gap significa que un sistema no tiene una ruta de red rutinaria hacia la red de producción. En la práctica de backup existen dos variantes: un aislamiento físico (sin cable de red, intercambio de soportes) o una transmisión unidireccional lógica (diode de datos de hardware o ventanas de transferencia estrictamente controladas). El objetivo es reducir la superficie de ataque y disponer de un último conjunto de datos limpio al que el malware en la red de producción no pueda acceder.

Es importante definir claramente los objetivos operativos: ¿se trata del Recovery Time Objective (RTO), del Recovery Point Objective (RPO), del cumplimiento normativo o de la integridad forense? Los air‑gaps ayudan sobre todo con la integridad y el cumplimiento, pero normalmente empeoran el RTO/RPO en comparación con réplicas en línea.

Requisitos básicos y lista de verificación del proyecto

Antes del diseño debe verificar requisitos organizativos y técnicos. Los siguientes puntos mínimos deben figurar en la lista de verificación:

• Definir objetivos de recuperación (RTO/RPO) y periodos de retención.
• ¿Qué datos deben protegerse? (bases de datos de producción, backups de configuración, certificados)
• Presupuesto para hardware, rotación de medios y, si procede, appliances de Data‑Diode.
• Procesos operativos: ¿quién conecta físicamente los medios, quién firma/verifica los manifiestos?
• Plan de pruebas para ejercicios regulares de RESTauración.

Diseño de red: topologías para nodos de backup con air‑gap

Existen tres topologías prácticas:

1) Nodos físicamente aislados con intercambio de soportes

Los servidores de backup están instalados localmente en el centro de datos, pero no tienen enrutamiento L2/L3 permanente hacia la red productiva. Los datos se transfieren mediante soportes extraíbles offline (discos duros cifrados, cintas LTO). Ventaja: aislamiento muy alto. Inconveniente: procesos manuales y RTO más largos.

2) Transmisión unidireccional lógica con Data Diode o appliance unidireccional

Un Data‑Diode de hardware es un dispositivo que físicamente solo permite el paso de datos en una dirección (en la práctica suele ser óptico). Como alternativa, se pueden configurar routers/ACLs para que las conexiones solo puedan iniciarse hacia una subred. Ventaja: transferencias automatizables y menor esfuerzo manual. Limitación: costes mayores y dependencia del fabricante del appliance y de la seguridad de su firmware.

3) Nodos temporalmente conectados y fuertemente controlados (ventanas de transferencia)

El air‑gap se abre solo temporalmente: se conecta físicamente un cable de red o se modifican reglas de firewall durante una ventana definida. Las transferencias se realizan cifradas, a continuación se RESTaura inmediatamente el aislamiento y se ejecutan verificaciones de firma. Adecuado cuando se necesita automatización sin Data‑Diode. Riesgo: errores humanos al volver a aislar.

Planificación de segmentos de red y firewalls

Defina al menos tres segmentos: red de producción, DMZ de transferencia (si existe) y zona aislada (air‑gapped). Use ACLs (listas de control de acceso) claras, VLANs (LAN virtuales) y separación física de los puertos de los switches. Una regla simple es: no permitir conexiones entrantes desde la red de producción hacia la zona aislada (air‑gapped). Pruebe las reglas con Netcat o tcpdump antes de ponerlas en producción.

Hardware: servidores, almacenamiento y selección de medios

Las decisiones de hardware afectan la disponibilidad, la integridad y los costes operativos. Criterios de selección:

• Factor de forma: servidores 1U/2U o tape‑library dedicada según el volumen.
• Tipo de almacenamiento: archivos basados en HDD (económicos, alta capacidad), SSD (para pruebas de RESTauración rápidas), cintas LTO (duraderas, aptas para almacenamiento offline).
• Redundancia: para nodos en la zona aislada (air‑gapped) RAID suele ser suficiente; para cinta apueste por rotación de medios y copias fuera de sitio.
• Cifrado: cifrado por hardware en los medios o cifrado en el host antes de la transferencia.

PRESTe atención a un etiquetado de medios trazable y a un almacenamiento seguro: controles de acceso, registros de CCTV y firmas.

Sincronización: procedimientos, herramientas y principios de integridad

La pregunta central es: ¿Cómo llegan los datos de forma fiable y verificable al nodo aislado? Métodos habituales con ventajas y desventajas:

• rsync / rclone a través de enlace unidireccional: flexible, de grano fino, soporta sumas de verificación (checksums). Requiere conexión de red (o Data Diode).
• Replicación a nivel de bloque (ZFS send/receive, btrfs send): eficiente para grandes volúmenes de datos con consistencia por snapshot.
• Rotación de medios física (scp/disco duro físico, LTO‑Tape): muy aislada, pero lenta y manual.
• Percona XtraBackup / Backups consistentes de MySQL: necesario para dumps de MySQL y backups incrementales (ver sección MySQL abajo).

Ejemplo: rsync mediante ventana controlada

rsync está probado en la práctica para sincronización de ficheros. Importante: use sumas de verificación y genere un manifiesto con sha256 para cada lote de transferencia.

# Auf der Produktionsseite: Backup vorbereiten und Manifest erstellen
rsync -aH --delete /var/lib/appdata/ /staging/backupdir/
find /staging/backupdir -type f -print0 | xargs -0 sha256sum > /staging/backupdir/manifest.sha256
gpg --detach-sign --armor /staging/backupdir/manifest.sha256

Tras la transferencia a la zona aislada (air‑gapped) verifique las sumas de verificación y la firma GPG.

# Auf Air-Gapped-Node: Integritätsprüfung
gpg --verify manifest.sha256.asc manifest.sha256
sha256sum -c manifest.sha256

Firmas y manifiestos inmutables

Firme los manifiestos siempre con una clave offline o con una clave cuyo secreto no resida en la red de producción. Esto evita que un atacante manipule manifiestos en la cadena de transferencia.

MySQL‑específico: consistencia, herramientas y errores típicos

MySQL (incl. MariaDB) tiene requisitos especiales: necesita copias de seguridad de base de datos consistentes que garanticen consistencia de la aplicación al RESTaurar. Conceptos importantes: posiciones del binlog (binlog = Write‑Ahead‑Log), GTID (Global Transaction ID) para posicionamiento replicable, y métodos de quiesce (snapshot LVM o estrategias de bloqueo).

Opción A: Percona XtraBackup (recomendado para grandes bases de datos InnoDB)

Percona XtraBackup permite backups incrementales y no‑bloqueantes de bases de datos InnoDB. Flujo: XtraBackup crea una copia de archivos + Transaction Log (redo) y proporciona un punto de consistencia que se prepara antes del RESTore con xtrabackup –prepare.

# Copia de seguridad completa con xtrabackup
xtrabackup --backup --target-dir=/backup/xtrabackup/full --datadir=/var/lib/mysql --user=xbackup --password='secret'
# Copia incremental
xtrabackup --backup --incremental --target-dir=/backup/xtrabackup/inc1 --incremental-basedir=/backup/xtrabackup/full

Errores típicos: preparación incompleta, metadatos binlog‑/GTID faltantes o permisos olvidados al copiar archivos de sistema de InnoDB. Compruebe los procedimientos de RESTauración regularmente en un entorno de pruebas aislado.

Opción B: mysqldump / Copias lógicas

mysqldump es sencillo y portátil, pero genera volcados grandes y puede ser problemático para el RTO en bases de datos muy grandes. Para InnoDB debe usar –single‑transaction, que permite una lectura de snapshot consistente (sin locks) siempre que no se ejecuten operaciones DDL.

# mysqldump consistente para InnoDB
mysqldump --single-transaction --routines --events --triggers --databases appdb > appdb.sql
# Consultar posición del binlog
mysql -e "SHOW MASTER STATUSG"

PRESTe atención a las posiciones del binlog o a los GTID con mysqldump, para poder realizar una recuperación Point‑in‑Time (PITR) tras la RESTauración.

Pasos de verificación y ejercicios de RESTauración para MySQL

• Documentar el procedimiento de RESTauración y probarlo una vez por trimestre.
• Tras la RESTauración comprobar: número de tablas, checksums (pt-table-checksum u herramientas equivalentes), pruebas smoke de la aplicación.
• Compruebe los permisos de usuario, el estado del binlog y la configuración de replicación después de la RESTauración.

Pasos concretos de RESTauración para XtraBackup

Un camino típico de RESTauración tras la transferencia a un sistema aislado (air‑gapped):

# Preparación del backup
xtrabackup --prepare --target-dir=/backup/xtrabackup/full
# Detener el servicio MySQL
systemctl stop mysql
# Copiar al datadir (Atención: permisos de archivos)
rsync -aH /backup/xtrabackup/full/ /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
# Iniciar MySQL
systemctl start mysql

Si –prepare falla, revise los archivos de log de xtrabackup en busca de redo‑logs faltantes o de dependencias incrementales.

Operación: Runbooks, Transferprozeduren und Automatisierung

Los buenos Runbooks son el corazón de la operación. Un runbook de transferencia describe en detalle:

1. Condiciones previas: medios disponibles, claves de firma, responsables.
2. Paso a paso: iniciar la copia de seguridad, crear el manifiesto, firmar, iniciar la transferencia, comprobaciones post‑transferencia, re‑aislamiento.
3. Monitorización y registro: syslog/central logs, registro de auditoría que indique quién y cuándo conectó los medios.
4. Plan de contingencia: ¿Qué hacer si el manifiesto falla? (p. ej., reiniciar la transferencia o usar la copia previa basada en medios).

Ejemplo de automatización: ventana de transferencia controlada

Automatice la apertura/cierre de reglas de firewall mediante API o gestión de configuración (Ansible/Chef). Ejecute antes de abrir verificaciones preflight automáticas (comprobación de integridad, verificación de cuotas).

Integridad, firmas y auditoría

La integridad debe asegurarse en tres niveles: integridad de archivos (checksums), integridad de la transferencia (TLS, Data‑Diode) y autenticidad (firmas GPG). Además, debe crear logs de auditoría que documenten los movimientos de medios físicos y las acciones de los usuarios.

# Crear y firmar el manifiesto (ejemplo)
find /backupdir -type f -print0 | xargs -0 sha256sum > manifest.sha256
gpg --default-key backup-admin --detach-sign --armor manifest.sha256

Monitorización, alertas y comprobaciones de sanidad automáticas

Controle las siguientes métricas: hora del último traslado exitoso, número de archivos verificados, resultado de la comprobación sha256, capacidad de medios disponible. Integre alarmas (p. ej. mediante Prometheus Alertmanager o RZ‑Monitoring) para transfers ausentes o manifiestos defectuosos.

Ejemplo: script de healthcheck sencillo para nodo Air‑Gapped

Este script consolida la verificación de integridad y el recuento de archivos y devuelve códigos de salida para sistemas de monitorización.

#!/bin/bash
MANIFEST=/var/airgap/manifest.sha256
MANIFESTSIG=/var/airgap/manifest.sha256.asc
BACKUPDIR=/var/airgap/data
# Signatur prüfen
if ! gpg --verify "$MANIFESTSIG" "$MANIFEST" >/dev/null 2>&1; then
  echo "GPG verification failed" >&2
  exit 2
fi
# Checksums prüfen
if ! sha256sum -c "$MANIFEST" >/dev/null 2>&1; then
  echo "Checksum mismatch" >&2
  exit 2
fi
# Dateizahl prüfen
FILECOUNT=$(find "$BACKUPDIR" -type f | wc -l)
if [ "$FILECOUNT" -lt 10 ]; then
  echo "Too few files: $FILECOUNT" >&2
  exit 2
fi
echo "OK: $FILECOUNT files verified"
exit 0

Errores típicos y cómo evitarlos

• Confiar en un único método: combine checksums + firmas + auditoría física.
• Errores humanos al volver a aislar: automatice la re‑isolación cuando sea posible o exija el principio de cuatro ojos.
• Falta de pruebas de RESTauración: sin pruebas periódicas no sabe si las copias realmente son utilizables.
• Gestión de claves: nunca guarde claves privadas en sistemas productivos en línea; utilice HSM fuera de línea o claves separadas air‑gapped.
• Documentación insuficiente: los runbooks y las responsabilidades deben estar actualizados y accesibles.

Planificación de capacidad, throughput y aspectos de rendimiento

Planifique la capacidad no solo según el volumen actual, sino según las ventanas de RESTauración y el crecimiento. Factores que influyen en el RTO:

• Rendimiento de escritura de la fuente (duración del job de backup)
• Throughput de transferencia (red o velocidad de streaming de cinta)
• I/O de RESTauración en el destino (qué tan rápido se pueden RESTaurar los datos)

Ejemplo: una Data‑Diode de 1 Gbit/s tiene teóricamente ~125 MB/s. Tras overhead, protocolo y cifrado, calcule de forma realista 80–90 MB/s en buenas condiciones. Para varios terabytes eso supone muchas horas; documente estos intervalos en su runbook.

Deducción, compresión y estrategias de almacenamiento

La deduplicación y la compresión reducen el volumen de datos, pero pueden afectar la ruta de RESTauración y la compatibilidad. Los almacenes deduplicados suelen requerir herramientas de RESTauración especializadas; en contextos air‑gapped muchos equipos prefieren formatos simples y portables (tar, flujos comprimidos) para conservación a largo plazo. Si usa dedupe, pruebe obligatoriamente RESTauraciones completas desde stores deduplicados.

Gestión de claves, HSM y requisitos forenses

Para firmas y cifrado los secretos nunca deben estar en la red productiva en línea. Opciones:

• Claves GPG offline en un portátil Air‑Gapped
• HSM (Hardware Security Module) o Cloud‑HSM con RESTricciones de acceso
• Autorización de dos personas basada en smartcard/token para firmas críticas

Documente la rotación de claves, la retención y los protocolos de acceso a claves. Para preservación forense de evidencias es esencial una cadena de custodia verificable: quién movió y verificó cada medio y cuándo.

Lista práctica de verificación para resolución de problemas

Si una transferencia falla o la verificación del manifiesto arroja errores, proceda de forma sistemática:

1. Compruebe los archivos de registro (rsync/xtrabackup/gpg/syslog).
2. Compare el número de archivos y el tamaño total entre origen y destino.
3. Verifique las huellas digitales de las claves GPG frente a una lista de confianza.
4. Si –prepare falla en XtraBackup: compruebe si todos los redo‑Logs necesarios están presentes y si los backups incrementales se han vinculado correctamente.
5. Si los medios están defectuosos: intente una copia bit a bit (dd) y el análisis de los sectores defectuosos; catalogue el medio defectuoso para auditorías.

Migración y despliegue gradual

Un cambio completo a nodos air‑gapped es complejo desde el punto de vista operativo. Ruta gradual recomendada:

1. Piloto con un volumen de datos reducido (datos de configuración, bases de datos menos críticas).
2. Automatizar la creación y la firma de manifiestos.
3. Implementación de un monitor de healthcheck y simulacros de RESTauración trimestrales.
4. Escalado a volúmenes mayores y reajuste de los objetivos RTO/RPO.

Conclusión final

Los nodos de backup air‑gapped son un elemento eficaz en una estrategia de backup integral, especialmente cuando la integridad y la protección contra manipulaciones son prioritarias. Sin embargo, requieren disciplina en los procesos, una gestión sólida de claves y medios, así como pruebas de RESTauración periódicas. Desde el punto de vista técnico, las Data‑Diodes, las ventanas de transferencia controladas y la rotación de medios físicos ofrecen diferentes compromisos entre automatización, coste e aislamiento — elija la variante que se ajuste a sus objetivos RTO/RPO y a su equipo de operaciones.

Concéntrese operativamente en manifiestos verificables, claves de firma gestionadas offline, runbooks documentados y pruebas de RESTauración periódicas. Así evitará los tropiezos más comunes y asegurará que sus nodos de backup air‑gapped respondan de forma fiable en caso de emergencia.

Para este tema también son importantes Air Gap y el diseño de la red de backup. El artículo sitúa estos aspectos de manera comprensible y muestra qué es importante en la operativa diaria.