Indice dei contenuti
- Il backup come rituale, non come strategia
- Backup cifrati dal ransomware: quando la copia è complice
- Restore che richiede giorni invece di ore
- Backup immutabili configurati male: sicurezza solo apparente
- Il punto cieco: nessuno testa il restore in condizioni realistiche
- Il falso senso di sicurezza come rischio organizzativo
- Restore testing: da evento eccezionale a routine operativa
- Il vero valore: scoprire i problemi prima dell’attacco
- Il backup non è una polizza, è una capacità
Nel mondo della cyber security c’è una convinzione tanto diffusa quanto pericolosa: “Abbiamo i backup, quindi siamo al sicuro”.
È una frase che rassicura manager, IT e board. Una frase che chiude discussioni, rimanda investimenti, spegne dubbi.
Eppure, nella pratica, è una delle illusioni più costose che un’organizzazione possa coltivare.
Questo articolo nasce da un angolo editoriale preciso: il falso senso di sicurezza.
Perché il backup, da solo, non salva nessuno. A salvare davvero è il restore testato, misurato, ripetibile. Tutto il resto è teoria.
Il backup come rituale, non come strategia
In moltissime aziende il backup è trattato come un obbligo amministrativo, non come un processo critico di resilienza.
Si installa una soluzione, si pianificano job automatici, si guardano dashboard verdi e si archivia il tema come “coperto”.
Il problema è che il backup viene verificato solo in scrittura, quasi mai in lettura.
- Il job è andato a buon fine? ✔
- I file risultano presenti? ✔
- Lo storage non segnala errori? ✔
Ma nessuno si chiede davvero:
“Se domani dovessimo ripristinare tutto, quanto tempo ci metteremmo?
E funzionerebbe davvero?”
Il backup diventa così un rituale rassicurante, non una strategia di sopravvivenza.
Backup cifrati dal ransomware: quando la copia è complice
Uno degli scenari più frequenti (e più ignorati) negli incidenti ransomware moderni è questo:
il backup esiste, ma è cifrato insieme ai dati di produzione.
Come succede?
- Backup online sempre connessi
- Credenziali di backup identiche o accessibili dal dominio
- Nessuna separazione reale tra produzione e protezione
- Nessun controllo su chi può cancellare o cifrare i backup
Il ransomware moderno non si limita a colpire i server.
Cerca attivamente:
- repository di backup
- snapshot
- volumi secondari
- console di gestione
E quando li trova, li tratta come il resto.
Il risultato è devastante:
l’azienda scopre di avere backup perfettamente inutilizzabili, cifrati con la stessa chiave dell’infrastruttura primaria.
In quel momento, la frase “abbiamo i backup” diventa una beffa.
Restore che richiede giorni invece di ore
Un altro grande mito è che il restore sia “automaticamente veloce”.
In realtà, la velocità di ripristino è quasi sempre una sorpresa sgradita.
Durante un incidente reale emergono problemi che nessun documento aveva previsto:
- restore seriali invece che paralleli
- colli di bottiglia di rete
- storage troppo lento per il volume reale dei dati
- dipendenze applicative non documentate
- servizi che richiedono ordine preciso di avvio
Quello che sulla carta doveva richiedere 2 ore, nella realtà ne richiede 48 o 72.
E qui nasce il vero danno:
- sistemi ERP fermi
- produzione bloccata
- fatturazione sospesa
- clienti persi
- reputazione compromessa
Il backup c’è, ma non rispetta gli RTO dichiarati.
E un RTO non rispettato è, di fatto, un fallimento del piano di continuità.
Backup immutabili configurati male: sicurezza solo apparente
Negli ultimi anni i backup immutabili sono diventati una sorta di parola magica.
WORM, object lock, retention policy: tutto sembra finalmente “a prova di ransomware”.
Ma l’immutabilità non è un interruttore, è una configurazione delicata.
Gli errori più comuni:
- retention troppo breve
- possibilità di cancellazione da account amministrativi
- replica sincrona che propaga la distruzione
- test di restore mai eseguiti su dati immutabili
- console di gestione esposta o non segregata
Il risultato è paradossale:
backup dichiarati immutabili che spariscono o non sono ripristinabili quando servono davvero.
Perché nessuno ha mai verificato cosa succede dal punto di vista del restore, non della protezione teorica.
Il punto cieco: nessuno testa il restore in condizioni realistiche
Il vero problema non è tecnico. È culturale.
Il restore:
- è lento
- è scomodo
- “rompe” ambienti
- richiede coordinamento
- espone errori
E quindi viene evitato.
Quando viene fatto, spesso è:
- su singoli file
- su ambienti di test irrealistici
- senza misurare tempi reali
- senza coinvolgere applicativi complessi
Ma un restore che non simula un incidente reale non vale nulla
Un vero test di restore dovrebbe rispondere a domande scomode:
- Quanto tempo serve davvero?
- Chi deve intervenire?
- Quali sistemi dipendono da altri?
- Cosa non riparte automaticamente?
- Quali dati risultano corrotti o incompleti?
Finché queste domande restano senza risposta, il backup è solo una promessa.
Il falso senso di sicurezza come rischio organizzativo
Il danno più grave del backup non testato non è tecnico.
È decisionale.
Un’azienda convinta di essere protetta:
- investe meno in prevenzione
- sottovaluta il rischio ransomware
- non allena il team
- non prepara la comunicazione
- non pianifica scenari di crisi
Quando l’incidente arriva, lo shock è doppio:
- l’attacco
- la scoperta che il piano non funziona
Ed è in quel momento che emergono panico, improvvisazione e scelte sbagliate.
Restore testing: da evento eccezionale a routine operativa
Testare il restore non deve essere un evento straordinario.
Deve diventare una routine strutturata.
Non significa ripristinare tutto ogni settimana, ma:
- test periodici su dataset realistici
- simulazioni di perdita completa
- misurazione oggettiva dei tempi
- documentazione aggiornata
- coinvolgimento di IT, sicurezza e business
Il restore testing non è un costo inutile.
È l’unico modo per trasformare il backup in resilienza reale.
Il vero valore: scoprire i problemi prima dell’attacco
Ogni restore testato male è una fortuna.
Perché rivela un problema prima che lo faccia un criminale.
Meglio scoprire oggi che:
- il backup è lento
- la procedura è incompleta
- le dipendenze non sono chiare
piuttosto che scoprirlo alle 3 di notte, con i sistemi cifrati e il CEO al telefono.
Il backup non è una polizza, è una capacità
Il backup non è un’assicurazione automatica.
È una capacità operativa, che va allenata come qualsiasi altra.
Finché il restore non viene testato:
- il backup è un’illusione
- la sicurezza è teorica
- la resilienza è solo dichiarata
La domanda giusta non è:
“Abbiamo i backup?”
Ma:
“Siamo in grado di ripartire davvero, quando tutto va male?”
Se non hai mai testato il restore, la risposta è probabilmente no.
