Backup dei dati di rete: la strategia specifica che ti mette al sicuro da ransomware e incidenti

Una rete affidabile non si misura solo in throughput o latenza. La differenza, quando un attacco o un incidente spegne i servizi, la fa un disegno di backup capace di salvare configurazioni, dati e stati operativi in modo coerente. È il punto su cui insiste da anni Flavio Morandi, tecnico di rete cresciuto tra cablaggi e controller Wi‑Fi, abituato a ripristinare ambienti eterogenei con tempi di fermo misurati in minuti.

Dal rischio all’impatto: cosa succede senza una strategia

Le interruzioni non nascono tutte uguali. Ransomware, errori di configurazione, aggiornamenti falliti, guasti elettrici o storage corrotto colpiscono livelli diversi dello stack. Senza un piano, l’effetto a catena è immediato: directory utente irraggiungibili, DHCP indisponibile, tunnel VPN instabili, controller SD‑WAN fermi.

I costi si misurano in RTO (Recovery Time Objective) mancati, ma anche in sanzioni e danni reputazionali. Per i dati personali e i log di sicurezza, gli obblighi di conservazione e notifica del GDPR impongono tracciabilità e ripristino tempestivo. In parallelo, policy ispirate a ISO/IEC 27001 e 27040 richiedono evidenze di backup verificati e protetti da manomissioni.

Potrebbe interessarti anche

Zero Trust nelle infrastrutture digitali: perché ora è il modello di sicurezza più richiesto?Come rilevare dispositivi non autorizzati sulla LAN: la scansione intelligente che anticipa le minacceCome funzionano i load balancer di rete? Errori da evitare quando distribuisci il trafficoChe vantaggi porta IPv6 per dispositivi IoT? Semplifichi la scalabilità senza complicare la gestione

Morandi distingue tre macro‑categorie critiche: configurazioni di apparati (switch, router, firewall, AP), dati applicativi (file share, database, VM) e metadati di rete (DNS, DHCP, IPAM, controller). Ognuna richiede strumenti e frequenze diverse.

Il principio guida: 3‑2‑1‑1‑0 applicato alla rete

La regola 3‑2‑1‑1‑0, adattata agli ambienti di rete, è una sintesi operativa:

• 3 copie: produzione più due copie di backup.
• 2 media differenti: ad esempio NAS locale e storage a oggetti.
• 1 off‑site: fisicamente o logicamente separata dalla LAN.
• 1 immutabile/air‑gapped: non modificabile per il periodo di retention.
• 0 errori alla verifica: controlli automatici su integrità e ripristinabilità.

Tradotto sul campo, significa: snapshot consistenti su file server, export configurazioni periodici di apparati via API, replica cifrata su storage a oggetti con Object Lock, e una cassetta di sicurezza fisica o logica per backup isolati. La componente “0” è spesso trascurata; Morandi la rende misurabile con report di checksum, test di mount e ripristino a campione.

RPO e RTO per dati e apparati: misure prima dei mezzi

Definire quanto dato si può perdere (RPO) e in quanto tempo si deve tornare operativi (RTO) guida ogni scelta successiva. Valori tipici in PMI e PA locale:

• Servizi vitali di base (DHCP, DNS, autenticazione): RPO 15 minuti, RTO 60 minuti.
• Controller Wi‑Fi e SD‑WAN: RPO 30 minuti, RTO 2 ore.
• File share dipartimentali: RPO 1 ora, RTO 4 ore.
• Configurazioni di firewall e core switch: RPO 15 minuti, RTO 60 minuti.
• Log di sicurezza e NetFlow: RPO 1 ora, RTO 24 ore, con retention coerente con policy e audit.

La granularità conta: per le configurazioni, backup differenziali frequenti riducono l’RPO senza saturare banda; per i file, snapshot incrementali con deduplica abbassano finestra e costi.

Architetture e protocolli: spostare e fissare i dati in modo sicuro

Nel disegno di Morandi, i percorsi di backup sono segmentati e autenticati forte. Le scelte comuni includono:

• SMB/NFS per share, con snapshot coerenti a livello file system (VSS su Windows, ZFS/Btrfs su Unix‑like) per garantire consistenza applicativa.
• Rsync su SSH o SFTP per dataset incrementali, con compressione e verifica di checksum a blocchi.
• API S3 per storage a oggetti, con server on‑prem S3‑compatibili o cloud pubblico, abilitando versioning e Object Lock.
• NETCONF/RESTCONF o SCP per esportare configurazioni di apparati; TFTP evitato in produzione salvo segmenti isolati.
• TLS 1.2+ e cifratura a riposo (AES‑256) su repository, gestione chiavi in HSM o servizi KMS con rotazione periodica.

La rete che trasporta il backup è a sua volta protetta: VLAN dedicate, ACL minimali, autenticazione a chiave pubblica, e registrazione su syslog centralizzato. Il traffico pianificato in finestre a bassa congestione riduce l’impatto su servizi interattivi.

Immutabilità e air‑gap: dal concetto alla pratica

La protezione da ransomware richiede almeno una copia non modificabile per un periodo definito. Due approcci complementari:

• Immutabilità logica: Object Lock in modalità Compliance o Governance su bucket S3, WORM su file system enterprise, snapshot ZFS con hold. L’accesso è autenticato a ruoli minimi e privo di chiavi permanenti sulle macchine di produzione.
• Air‑gap fisico/logico: nastri LTO ruotati e custoditi off‑site, repository offline attivato a finestra, o segmenti isolati raggiungibili solo da jump host non permanenti. Un “data diode” logico vieta sessioni inverse.

Il quadro si allinea a controlli del NIST sulla resilienza e ai principi Zero Trust: si presume compromissione e si riducono superfici e privilegi. Le retention sono bilanciate tra esigenza di rollback e costi: 7‑30 giorni per snapshot frequenti, 90‑365 giorni per copie mensili immutabili, archivi annuali su nastro per conservazione storica.

Test, ripristino e runbook: senza prove il backup non esiste

Ogni ciclo prevede prove di ripristino. Morandi suggerisce tre livelli:

• Verifica automatica: test di checksum, mount simulato, lettura a campione di file e restore di config su device virtuali.
• Drill periodico: ripristino end‑to‑end in sandbox che replica DNS/DHCP/AD, convalidando RTO e playbook.
• Revisione del runbook: documenti eseguibili, con ordini di ripristino (prima DHCP, poi DNS, poi autenticazione, quindi file e applicazioni), punti di controllo e ruoli assegnati.

Quando possibile, l’infrastruttura è descritta come codice (IaC) per accelerare rebuilding: template di configurazione, backup parametrizzati e versionati, golden image di VM e container registrate con hash verificabili.

Tabella comparativa: media di backup per reti

Implementazione graduale: una roadmap praticabile

Per PMI e enti locali, Morandi propone una sequenza in cinque passi:

• Censimento e classificazione: asset, dati, dipendenze; definizione RPO/RTO per servizio.
• Piano 3‑2‑1‑1‑0: scelta media e sedi; VLAN/ACL dedicate al traffico di backup.
• Automazione: scheduler centralizzato, backup consistenti, esport di configurazioni via API sicure.
• Immutabilità e air‑gap: abilitare Object Lock o WORM; definire rotazione nastri e custodia.
• Test e audit: drill trimestrali, verifiche “0 errori”, revisione di retention e costi.

Un’attenzione particolare va ai segreti: chiavi API, credenziali di apparati e token non devono mai risiedere in chiaro nei job. Vault centralizzati con rotazione e segregazione dei privilegi riducono il rischio di escalation.

Errori comuni da evitare

• Concentrare backup e produzione sullo stesso dominio di fault (stesso rack, stessa SAN, stesse credenziali).
• Affidarsi a snapshot senza replica off‑site o immutabilità.
• Non includere configurazioni di rete e firmware nell’ambito del backup.
• Trascurare il ripristino ordinato dei servizi base (DHCP/DNS) che sbloccano tutto il resto.
• Dimenticare la verifica: backup “verdi” che non si ripristinano sono un falso senso di sicurezza.

Indicatori di efficacia e governance

Per misurare i progressi, Morandi usa metriche semplici: percentuale di job con verifica integrità, tempo medio di ripristino in drill, percentuale di dati coperti da immutabilità, numero di runbook aggiornati e versionati. La governance si affida a ruoli chiari, segregazione delle funzioni e report periodici verso direzione e audit.

La strategia non è un prodotto ma una pratica. Media e software cambieranno; principi come 3‑2‑1‑1‑0, immutabilità, segmentazione del traffico e test regolari restano. Con questi pilastri, un attacco o un errore umano diventano incidenti gestibili, non crisi prolungate.