Resilienza dei Dati e strategie di Backup

Introduzione

La perdita di dati rappresenta uno dei rischi più concreti e costosi per qualsiasi organizzazione moderna. Comprendere le cause, adottare strategie di backup efficaci e pianificare il ripristino sono attività fondamentali per garantire la continuità operativa, tanto per le piccole imprese quanto per le infrastrutture critiche su larga scala.

Le cause della perdita dei dati

I dati possono andare persi per ragioni molto diverse tra loro, che spaziano dall'errore umano agli eventi catastrofici. Le principali categorie di rischio sono:

• Errore umano: cancellazione o sovrascrittura accidentale di file e cartelle, spesso la causa più frequente nelle organizzazioni di qualsiasi dimensione.
• Guasti hardware: rottura meccanica del disco rigido, degrado dei settori magnetici o usura dei componenti elettronici, fenomeni inevitabili nel ciclo di vita di ogni supporto di archiviazione.
• Attacchi malware: ransomware che cifrano i file richiedendo un riscatto per il ripristino, con impatti devastanti sulla continuità aziendale e sulla reputazione.
• Problemi di alimentazione: spegnimenti improvvisi o sbalzi di tensione durante operazioni di scrittura, che possono corrompere file system e database in modo silenzioso e difficile da rilevare.
• Disastri naturali e fisici: incendi, allagamenti o furti che distruggono fisicamente i supporti di archiviazione e rendono irrecuperabili i dati in loco.

La regola del 3-2-1

La regola del 3-2-1 è uno standard de facto nella gestione dei backup e rappresenta il punto di partenza per qualsiasi strategia di protezione dei dati. Il principio si articola in tre requisiti fondamentali:

• 3 copie totali dei dati: la copia originale in produzione più due backup distinti e indipendenti.
• 2 supporti di archiviazione diversi: ad esempio un NAS locale e un disco esterno, oppure un server on-premise e un servizio cloud, per eliminare i single point of failure legati al tipo di supporto.
• 1 copia conservata fuori sede (offsite): fisicamente separata dagli altri backup per proteggersi da disastri locali come incendi, inondazioni o furti.

Questa regola si applica indipendentemente dalla tipologia di backup adottata. Esistono tre modalità principali, spesso usate in combinazione:

• Backup completo (Full): copia integrale di tutti i dati selezionati. Richiede più spazio e tempo, ma garantisce il ripristino più semplice e veloce.
• Backup incrementale: salva solo i dati modificati dall'ultimo backup (completo o incrementale precedente). Veloce ed efficiente in termini di spazio, ma il ripristino richiede l'intera catena di backup in sequenza.
• Backup differenziale: salva i dati modificati dall'ultimo backup completo. Rappresenta un compromesso tra velocità di esecuzione e semplicità del ripristino, richiedendo solo il backup completo più l'ultimo differenziale.

RPO e RTO: metriche fondamentali per il recovery

Prima di scegliere una strategia di backup, è indispensabile definire due metriche chiave che quantificano la tolleranza ai disastri di un'organizzazione e guidano le scelte tecniche e architetturali.

RPO (Recovery Point Objective)

L'RPO definisce la quantità massima di dati che un'organizzazione può permettersi di perdere, espressa come intervallo di tempo. Un RPO di 4 ore significa che, in caso di incidente, si accetta di perdere al massimo le ultime 4 ore di lavoro. Questo valore guida direttamente la frequenza con cui devono essere eseguiti i backup:

• RPO basso (minuti o secondi): richiede backup in tempo reale o near-real-time, con soluzioni come la replica sincrona o i database log shipping.
• RPO medio (ore): backup incrementali ogni poche ore sono generalmente sufficienti per la maggior parte dei workload aziendali.
• RPO alto (giorni): backup giornalieri o settimanali, accettabili per dati non critici o archivi storici.

RTO (Recovery Time Objective)

L'RTO determina il tempo massimo che un'organizzazione può permettersi di rimanere offline dopo un incidente, prima che l'impatto sul business diventi inaccettabile. Un RTO di 2 ore significa che i sistemi devono essere ripristinati operativi entro 2 ore dall'evento disruptivo.

RPO e RTO sono strettamente correlati: valori bassi richiedono investimenti maggiori in infrastrutture, automazione e ridondanza. La tabella seguente mostra orientativamente le tecnologie tipicamente associate a diversi livelli di obiettivo.

Tipologie di backup: locale, cloud e ibrido

Backup locale

Il backup locale archivia i dati su dispositivi fisici presenti nella stessa sede operativa (NAS, tape library, dischi esterni). Offre velocità di scrittura e lettura elevate, pieno controllo sull'infrastruttura e nessuna dipendenza dalla connettività internet. Tuttavia, è vulnerabile ai disastri fisici locali e agli attacchi ransomware che, una volta compromessa la rete interna, possono propagarsi e cifrare anche i backup direttamente collegati.

Backup cloud

I backup cloud distribuiscono i dati su infrastrutture geograficamente ridondanti e scalabili, accessibili da qualsiasi luogo con una connessione internet. Servizi come AWS S3, Azure Blob Storage e Google Cloud Storage offrono elevata durabilità (fino a undici nove di disponibilità), funzionalità avanzate come il versioning automatico e il blocco degli oggetti per l'immutabilità. Il limite principale è la dipendenza dalla banda disponibile e la latenza per il ripristino di volumi di dati molto grandi.

Backup ibrido

La strategia ibrida combina i vantaggi del backup locale (velocità, bassa latenza per ripristini operativi quotidiani) con la protezione geografica del cloud (resilienza ai disastri fisici, immutabilità). È l'approccio consigliato per la maggior parte delle organizzazioni di medie e grandi dimensioni e si allinea naturalmente con la regola del 3-2-1.

Backup immutabili e protezione avanzata

Un concetto di crescente importanza nel panorama attuale è quello del backup immutabile, basato sul paradigma WORM (Write Once, Read Many). Un backup immutabile non può essere modificato, cifrato o cancellato per un periodo di tempo configurato, anche in caso di compromissione delle credenziali amministrative. Questa caratteristica lo rende la difesa più efficace contro gli attacchi ransomware sofisticati che prendono di mira i sistemi di backup prima di cifrare i dati di produzione.

Principali piattaforme che supportano backup immutabili:

• AWS S3 Object Lock: blocca gli oggetti in modalità WORM per una durata configurabile tramite policy di retention, con modalità Governance e Compliance.
• Azure Immutable Blob Storage: impedisce la modifica o la cancellazione dei blob per intervalli di tempo definiti da time-based retention policy o legal hold.
• Veeam Backup & Replication: supporta repository hardened su Linux con immutabilità a livello di filesystem XFS, senza richiedere soluzioni cloud.

È fortemente consigliato abbinare l'immutabilità alla cifratura dei backup, sia in transito (TLS) che a riposo (AES-256), per garantire la riservatezza dei dati anche in caso di accesso fisico non autorizzato ai supporti.

Verifica e test dei backup

L'importanza della verifica

Un backup non verificato non è un backup affidabile. È possibile che un processo di backup completi senza errori apparenti ma produca archivi corrotti o incompleti. La verifica periodica è l'unico modo per accertarsi che i dati possano essere effettivamente ripristinati quando necessario, evitando la cosiddetta "falsa sicurezza" del backup.

Le verifiche dovrebbero includere almeno tre livelli:

• Test di integrità: controllo degli hash (SHA-256) dei file archiviati per rilevare corruzione silenziosa, confrontando i checksum al momento del backup con quelli calcolati al momento della verifica.
• Test di ripristino parziale: ripristino di un sottoinsieme di file in un ambiente di test isolato per validare la procedura completa end-to-end.
• Disaster recovery drill: simulazione completa di un'interruzione, misurando i tempi effettivi di ripristino e confrontandoli con gli obiettivi RTO e RPO definiti.

Automazione dei test

L'automazione riduce drasticamente il rischio di errori umani e garantisce continuità nel monitoraggio. Di seguito è riportato un esempio di script di backup automatizzato con rsync per ambienti Linux, completo di logging e notifica via email.

Salvare il contenuto seguente come /usr/local/bin/backup.sh e renderlo eseguibile con chmod +x:

#!/bin/bash
SOURCE="/var/data/"
DEST="/mnt/backup/$(date +%Y-%m-%d)/"
LOG="/var/log/backup.log"
mkdir -p "$DEST"
rsync -avz --delete "$SOURCE" "$DEST" >> "$LOG" 2>&1
if [ $? -eq 0 ]; then
  echo "Backup completato: $(date)" | mail -s "Backup OK" admin@example.com
else
  echo "Backup FALLITO: $(date)" | mail -s "[ALERT] Backup fallito" admin@example.com
fi

Per eseguire il backup automaticamente ogni notte alle 02:00, aggiungere la seguente voce al crontab con il comando crontab -e:

0 2 * * * /usr/local/bin/backup.sh

Per ambienti Windows Server, PowerShell offre funzionalità equivalenti tramite robocopy e il registro eventi di sistema per il monitoraggio centralizzato:

$source = "C:\Data\"
$dest = "D:\Backup\$(Get-Date -Format 'yyyy-MM-dd')\"
$log = "C:\Logs\backup.log"
New-Item -ItemType Directory -Force -Path $dest | Out-Null
robocopy $source $dest /MIR /LOG+:$log
if ($LASTEXITCODE -le 7) {
  Write-EventLog -LogName Application -Source "BackupScript" -EntryType Information -EventId 1 -Message "Backup completato con successo."
} else {
  Write-EventLog -LogName Application -Source "BackupScript" -EntryType Error -EventId 2 -Message "Backup fallito. Verificare il log in $log."
}

In entrambi i casi è consigliato integrare lo script con un sistema di alerting centralizzato (Zabbix, Nagios, Prometheus + Alertmanager) per ottenere visibilità sullo stato dei backup in tempo reale, senza dover analizzare manualmente i log.

Pianificazione della continuità aziendale

La pianificazione della continuità aziendale (BCP — Business Continuity Plan) e il piano di disaster recovery (DRP — Disaster Recovery Plan) sono due documenti complementari e interdipendenti che ogni organizzazione dovrebbe mantenere aggiornati e testati periodicamente.

Il BCP definisce le procedure per garantire che le funzioni aziendali critiche continuino a operare durante e dopo un evento disruptivo, includendo aspetti come la comunicazione interna ed esterna, la gestione delle risorse umane in emergenza e l'identificazione di processi alternativi (workaround manuali, sedi secondarie, fornitori alternativi).

Il DRP si concentra specificamente sul ripristino dei sistemi IT e dell'infrastruttura tecnologica, dettagliando:

• I sistemi critici da ripristinare per primi, con priorità basate sugli obiettivi di RTO e RPO definiti.
• Le procedure step-by-step per il ripristino da backup, incluse le dipendenze tra sistemi.
• I ruoli e le responsabilità del team di recovery, con chiara indicazione di chi fa cosa e in quale ordine.
• I contatti di emergenza con fornitori hardware, provider cloud e partner di supporto.

La sinergia tra una politica di backup robusta, metriche RPO/RTO ben definite e un BCP/DRP documentato, regolarmente aggiornato e periodicamente testato con drill operativi, costituisce la base della resilienza operativa aziendale. Un DRP mai testato è, nella pratica, equivalente a non averlo.

Case study: l'attacco ransomware all'HSE irlandese (2021)

Nel maggio 2021, il Health Service Executive (HSE), il sistema sanitario nazionale della Repubblica d'Irlanda, fu vittima di uno degli attacchi ransomware più gravi mai registrati nel settore healthcare a livello globale. Il malware responsabile fu identificato come Conti ransomware, distribuito da un gruppo criminale organizzato tramite un file Excel malevolo aperto da un dipendente mesi prima dell'attivazione del payload.

Le conseguenze operative furono immediate e devastanti:

• Cifratura di circa 80.000 endpoint e server dell'intera infrastruttura IT dell'HSE.
• Interruzione totale o parziale dei servizi in ospedali e cliniche su tutto il territorio nazionale, con annullamento di migliaia di appuntamenti, procedure diagnostiche e interventi non urgenti.
• Costo stimato per il ripristino e il rafforzamento dell'infrastruttura superiore a 100 milioni di euro.
• Mesi di lavoro per il ripristino completo dei sistemi, con alcune strutture operative in modalità cartacea per oltre tre settimane.

L'analisi post-incidente condotta da PricewaterhouseCoopers evidenziò carenze strutturali significative:

• Assenza di backup offline e immutabili per i sistemi critici, che permise al ransomware di raggiungere anche gli archivi di backup connessi alla rete.
• Segmentazione di rete insufficiente, che facilitò la propagazione laterale del malware attraverso l'intera infrastruttura.
• Mancata applicazione sistematica di patch di sicurezza su sistemi legacy ancora in produzione.
• Assenza di un piano di disaster recovery formalmente testato.

Nonostante il gruppo Conti rilasciò successivamente la chiave di decifratura senza ottenere il riscatto, il ripristino richiese comunque mesi di lavoro a causa dei danni all'infrastruttura. Il caso HSE è diventato un riferimento globale nella comunità della cybersecurity per illustrare le conseguenze reali di una strategia di backup, segmentazione e risposta agli incidenti inadeguata in ambienti ad alto impatto sociale.