Configurare nodi di backup air-gapped nel data center: progettazione di rete, hardware e sincronizzazione

Air‑Gapped Backup‑Nodes — ovvero backup server o sistemi di storage isolati fisicamente o logicamente dalla rete di produzione — sono una misura consolidata per contrastare ransomware, movimento laterale e compromissioni di rete. Questo documento operativo descrive come progettare tali node nel centro dati, quale hardware e quali topologie di rete sono appropriate, come realizzare tecnicamente una sincronizzazione sicura e quali peculiarità considerare per i database MySQL. Destinatari: amministratori, System Engineers, operatori e fornitori di servizi IT tecnici.

Perché Air‑Gapped Backup‑Nodes? Rischi e obiettivi operativi

Un Air‑Gap significa che un sistema non dispone di un percorso di rete routinario verso la rete di produzione. Nella pratica di backup esistono due varianti: una separazione fisica (nessun cavo di rete, cambio dei supporti) oppure una trasmissione logica monodirezionale (Data‑Diode hardware o finestre di trasferimento rigorosamente controllate). L’obiettivo è ridurre la superficie d’attacco e disporre di uno stato dati finale integro, a cui il malware presente nella rete di produzione non può accedere.

È fondamentale definire chiaramente gli obiettivi operativi: si tratta di Recovery Time Objective (RTO), Recovery Point Objective (RPO), conformità normativa o integrità forense? Gli Air‑Gap sono particolarmente utili per integrità e compliance, ma generalmente peggiorano RTO/RPO rispetto alle repliche online.

Prerequisiti fondamentali e checklist di progetto

Prima del design è necessario verificare prerequisiti organizzativi e tecnici. I seguenti punti minimi devono comparire nella checklist:

• Definire gli obiettivi di recovery (RTO/RPO) e i periodi di retention.
• Quali dati vanno protetti? (database di produzione, backup di configurazione, certificati)
• Budget per hardware, rotazione dei supporti e, se necessario, appliance Data‑Diode.
• Processi operativi: chi connette fisicamente i supporti, chi firma/verifica i manifesti?
• Piano di test per esercitazioni di RESTore periodiche.

Progettazione di rete: topologie per Air‑Gapped Backup‑Nodes

Esistono tre topologie pratiche:

1) Node isolati fisicamente con cambio dei supporti

I backup server sono installati localmente nel centro dati, ma non dispongono di routing L2/L3 permanente verso la rete di produzione. I dati vengono trasferiti tramite supporti rimovibili (HDD crittografati, nastri LTO) in modalità offline. Vantaggio: isolamento molto elevato. Svantaggio: processi manuali, RTO più lunghi.

2) Trasferimento unidirezionale logico con Data Diode o appliance unidirezionale

Una Data‑Diode hardware è un dispositivo che consente fisicamente il passaggio dei dati in una sola direzione (semplicemente: ottico). In alternativa è possibile configurare router/ACL in modo che le connessioni possano essere originate solo verso una determinata sottorete. Vantaggio: trasferimenti automatizzabili, minore carico manuale. Limitazione: costi più elevati, dipendenza dal fornitore dell’appliance e dalla sicurezza del loro firmware.

3) Node connessi temporaneamente e fortemente controllati (finestre di trasferimento)

L’Air‑Gap viene aperto solo temporaneamente: il cavo di rete viene collegato fisicamente oppure le regole di firewall vengono modificate per una finestra di tempo definita. I trasferimenti avvengono in forma crittografata, segue un immediato ri‑isolamento e controlli di firma. Adatto quando è richiesta automazione senza Data‑Diode. Rischio: errori umani nel ri‑isolare.

Pianificazione dei segmenti di rete e dei firewall

Definite almeno tre segmenti: rete di produzione, DMZ di trasferimento (se presente) e zona air-gapped. Utilizzate ACL (liste di controllo degli accessi), VLAN (Virtual LAN) chiare e la separazione fisica delle porte degli switch. Una regola semplice: nessuna connessione in ingresso dalla rete di produzione verso la zona air-gapped. Testate le regole con netcat o tcpdump prima della messa in produzione.

Hardware: Server, Storage und Medienauswahl

Le decisioni hardware influenzano disponibilità, integrità e costi operativi. Criteri di selezione:

• Fattore di forma: server 1U/2U o tape‑library dedicate a seconda del volume.
• Tipo di storage: archivi basati su HDD (economici, alta capacità), SSD (per test di RESTore veloci), LTO‑Tape (duraturo, adatto all’offline).
• Ridondanza: per i nodi air-gapped il RAID è spesso sufficiente; per i nastri puntare su rotazione dei supporti e copie offsite.
• Crittografia: crittografia hardware sui supporti o crittografia lato host prima del trasferimento.

PRESTate attenzione a etichettatura tracciabile dei supporti e conservazione sicura: controlli di accesso, log CCTV e firme.

Synchronisation: Verfahren, Werkzeuge und Integritätsprinzipien

La domanda centrale è: come trasferire i dati in modo affidabile e verificabile verso il nodo isolato? Metodi comuni con vantaggi e svantaggi:

• rsync / rclone su collegamento unidirezionale: flessibile, granulare, supporta checksum. Richiede connessione di rete (o Data Diode).
• Replica basata su blocchi (ZFS send/receive, btrfs send): efficiente per grandi volumi di dati con consistenza garantita da snapshot.
• Rotazione di supporti fisici (scp/dischi fisici, LTO‑Tape): molto isolata, ma lenta e manuale.
• Percona XtraBackup / backup coerenti MySQL: necessario per dump MySQL e backup incrementali (vedi la sezione MySQL sotto).

Beispiel: rsync über kontrolliertes Fenster

rsync è collaudato per la sincronizzazione dei file. Importante: utilizzate checksum e generate un manifest con sha256 per ogni lotto di trasferimento.

# 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

Dopo il trasferimento nella zona air-gapped verificate le checksum e la firma GPG.

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

Signaturen und unveränderliche Manifeste

Firmate sempre i manifest con una chiave offline o con una chiave il cui segreto non risieda nella rete di produzione. Questo impedisce che un attaccante manipoli i manifest lungo la catena di trasferimento.

MySQL‑Spezifika: Konsistenz, Tools und typische Stolperfallen

MySQL (incl. MariaDB) presenta requisiti particolari: serve eseguire backup coerenti del database che garantiscano consistenza applicativa al RESTore. Concetti importanti: posizioni di binlog (binlog = Write‑Ahead‑Log), GTID (Global Transaction ID) per posizionamento riproducibile, e metodi di quiescenza (snapshot LVM o strategie di lock).

Option A: Percona XtraBackup (empfohlen für große InnoDB‑Datenbanken)

Percona XtraBackup consente backup incrementali e non bloccanti di database InnoDB. Procedura: XtraBackup crea la copia dei file + transaction log (redo) e fornisce un punto di consistenza che va reso pronto per il RESTore con xtrabackup –prepare.

# Volles Backup mit xtrabackup
xtrabackup --backup --target-dir=/backup/xtrabackup/full --datadir=/var/lib/mysql --user=xbackup --password='secret'
# Inkrementelles Backup
xtrabackup --backup --incremental --target-dir=/backup/xtrabackup/inc1 --incremental-basedir=/backup/xtrabackup/full

Errori tipici: preparazione incompleta, metadati binlog‑/GTID mancanti o permessi dimenticati durante la copia dei file di sistema InnoDB. Testate le procedure di ripristino regolarmente in un ambiente di test isolato.

Opzione B: mysqldump / backup logici

mysqldump è semplice e portabile, ma genera dump di grandi dimensioni e può essere problematico per l’RTO su DB molto grandi. Per InnoDB dovRESTe usare –single‑transaction, che permette una lettura snapshot coerente (senza lock) finché non sono in corso operazioni DDL.

# Konsistenter mysqldump für InnoDB
mysqldump --single-transaction --routines --events --triggers --databases appdb > appdb.sql
# Binlog-Position abfragen
mysql -e "SHOW MASTER STATUSG"

PRESTate attenzione alle posizioni del binlog o alle GTID con mysqldump, in modo da poter eseguire un Point-in-Time Recovery (PITR) dopo il ripristino.

Controlli ed esercitazioni di ripristino per MySQL

• Documentare la procedura di ripristino e testarla una volta per trimestre.
• Dopo il ripristino verificare: numero di tabelle, checksum (pt-table-checksum o strumenti equivalenti), smoke test dell’applicazione.
• Controllare i diritti degli utenti, lo stato del binlog e la configurazione della replica dopo il ripristino.

Passaggi concreti di ripristino per XtraBackup

Una tipica procedura di ripristino dopo il trasferimento in un sistema air-gapped:

# Vorbereitung des Backups
xtrabackup --prepare --target-dir=/backup/xtrabackup/full
# Stoppen des MySQL-Dienstes
systemctl stop mysql
# Kopieren in datadir (Achtung: Dateirechte)
rsync -aH /backup/xtrabackup/full/ /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
# MySQL starten
systemctl start mysql

Se –prepare fallisce, controllate i file di log di xtrabackup per redo log mancanti o dipendenze incrementali.

Operazioni: Runbooks, procedure di trasferimento e automazione

Runbook ben fatti sono il cuore delle operazioni. Un runbook di trasferimento descrive in dettaglio:

1. Precondizioni: supporti disponibili, chiavi di firma, responsabili.
2. Passo per passo: avviare il backup, creare il manifest, firmarlo, avviare il trasferimento, controlli post‑trasferimento, reisolamento.
3. Monitoraggio e logging: syslog/log centralizzati, voci di audit che registrino chi e quando ha collegato un supporto.
4. Fallback: cosa fare se il manifest fallisce? (es. riavviare il trasferimento o usare una copia precedente basata su supporti).

Esempio di automazione: finestra di trasferimento controllata

Automatizzate l’apertura/chiusura delle regole firewall tramite API o gestione della configurazione (Ansible/Chef). Eseguite controlli preflight automatici prima dell’apertura (verifica dell’integrità, controllo delle quote).

Integrità, firme e auditing

L’integrità va garantita su tre livelli: integrità dei file (checksum), integrità del trasferimento (TLS, data‑diode), e autenticità (firme GPG). Inoltre è necessario creare log di audit che attestino i movimenti dei supporti fisici e le azioni degli utenti.

# Manifest erstellen und signieren (Beispiel)
find /backupdir -type f -print0 | xargs -0 sha256sum > manifest.sha256
gpg --default-key backup-admin --detach-sign --armor manifest.sha256

Monitoring, alerting e controlli di sanità automatici

Monitorare le seguenti metriche: ora dell’ultimo trasferimento riuscito, numero di file verificati, risultato della verifica sha256, capacità disponibile dei supporti. Integrare allarmi (ad esempio tramite Prometheus Alertmanager o RZ‑Monitoring) per trasferimenti mancanti o manifest non validi.

Esempio: semplice script di healthcheck per nodo Air‑Gapped

Questo script combina verifica di integrità e conteggio dei file e RESTituisce codici di uscita per i sistemi di monitoraggio.

#!/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

Trappole tipiche e come evitarle

• Affidarsi a un unico metodo: combinare checksum + firme + audit fisico.
• Errori umani durante la re‑isolazione: automatizzare la re‑isolation dove possibile o richiedere il principio delle due persone.
• Mancanza di test di RESTore: senza test regolari non saprete se i backup sono effettivamente utilizzabili.
• Gestione delle chiavi: non conservare mai le chiavi private nei sistemi di produzione; utilizzare HSM offline o chiavi separate in Air‑Gapped.
• Documentazione insufficiente: runbook e responsabilità devono essere aggiornati e accessibili.

Pianificazione della capacità, throughput e aspetti di performance

Pianificate la capacità non solo in base al volume attuale, ma tenendo conto delle finestre di RESTore e della crescita. Fattori che influenzano l’RTO:

• Throughput di scrittura della sorgente (durata del job di backup)
• Throughput di trasferimento (rete o velocità di streaming su nastro)
• IO di RESTore sulla destinazione (quanto rapidamente i dati possono essere ripristinati)

Esempio: una data‑diode da 1 Gbit/s ha teoricamente ~125 MB/s. Considerando overhead, protocolli e crittografia, realisticamente si considerano 80–90 MB/s in buone condizioni. Per diversi terabyte questo significa molte ore; documentate queste finestre temporali nel vostro runbook.

Deduplicazione, compressione e strategie di storage

Deduplicazione e compressione riducono il volume dei dati, ma possono influenzare il percorso di RESTore e la compatibilità. Gli store deduplicati richiedono in genere strumenti di RESTore specializzati; nel contesto Air‑Gapped molti team preferiscono formati semplici e portabili (tar, stream compressi) per la conservazione a lungo termine. Se utilizzate dedupe, testate sempre RESTore completi da store deduplicati.

Gestione delle chiavi, HSM e requisiti forensi

Per firme e cifratura i secret non devono mai risiedere nella rete di produzione online. Opzioni:

• Chiavi GPG offline su un laptop Air‑Gapped
• HSM (Hardware Security Module) o Cloud‑HSM con RESTrizioni di accesso
• Approvazione a due persone basata su smartcard/token per firme critiche

Documentate rotazione delle chiavi, retention e protocolli di accesso alle chiavi. Per la raccolta di prove forensi è essenziale una catena di custodia tracciabile: chi ha spostato e verificato quale supporto e quando.

Checklist pratica per il troubleshooting

Se un trasferimento fallisce o la verifica del manifesto riporta errori, procedete in modo sistematico:

1. Verificate i file di log (rsync/xtrabackup/gpg/syslog).
2. Confrontate il numero di file e la dimensione totale tra sorgente e destinazione.
3. Verificate i fingerprint delle chiavi GPG rispetto a una lista attendibile.
4. Se –prepare di XtraBackup fallisce: verificate che tutti i redo log necessari siano presenti e che i backup incrementali siano stati collegati correttamente.
5. Se i supporti sono danneggiati: provate una copia bit a bit (dd) e l’analisi dei settori difettosi; catalogate il supporto difettoso per le verifiche di audit.

Migrazione e implementazione graduale

Un passaggio completo a nodi air‑gapped è operativamente oneroso. Percorso graduale consigliato:

1. Pilota con un basso volume di dati (dati di configurazione, database meno critici).
2. Automatizzare la creazione e la firma dei manifest.
3. Introdurre un monitor di healthcheck e esercitazioni di RESTore trimestrali.
4. Scalare a volumi maggiori e riallineare gli obiettivi RTO/RPO.

Conclusione

I nodi di backup air‑gapped sono un elemento efficace in una strategia di backup integrata, in particolare quando integrità e protezione dalla manomissione sono prioritarie. Richiedono però disciplina nei processi, una solida gestione di chiavi e supporti e test di RESTore regolari. Dal punto di vista tecnico, data diode, finestre di trasferimento controllate e rotazione fisica dei supporti implicano compromessi diversi tra automazione, costi e isolamento — scegliete la soluzione che si allinea ai vostri obiettivi RTO/RPO e al vostro team operativo.

Concentratevi sul piano operativo su manifest verificabili, chiavi di firma gestite offline, runbook documentati e test di RESTore regolari. Così eviterete gli errori più frequenti e garantirete che i vostri nodi di backup air‑gapped reagiscano in modo affidabile in caso di necessità.

Per questo argomento sono inoltre importanti Air Gap e progettazione della rete di backup. Il contributo inquadra questi aspetti in modo chiaro e mostra a cosa pRESTare attenzione nella pratica.