Costruire backup resilienti al ransomware

Perché il ransomware rende il backup un bersaglio, non una rete di sicurezza

Per anni il backup è stato l'eccezione che rendeva sopportabile un attacco ransomware: si cifrava la produzione, si ripristinava dal backup e si andava avanti. Gli attaccanti si sono adeguati. Nel report Veeam 2025 Ransomware Trends, condotto su 1.300 organizzazioni colpite, l'89% ha visto i propri repository di backup presi di mira come parte dell'attacco — non come un ripiego, ma come obiettivo primario nella kill chain. Distruggere o corrompere il fallback prima di cifrare la produzione è ormai prassi operativa standard, perché elimina il potere contrattuale della vittima ancora prima che arrivi la richiesta di riscatto.

Il risultato si riflette nei numeri di recovery. Il report Sophos State of Ransomware 2025 ha rilevato che solo il 54% delle organizzazioni ha utilizzato i backup per ripristinare i dati dopo un attacco — il tasso più basso nei sei anni in cui viene condotta la survey. Tra le organizzazioni che hanno finito per pagare più della richiesta iniziale dell'attaccante, il 38% ha indicato backup falliti o malfunzionanti come la ragione per cui non avevano alternative migliori. Un backup che esiste solo sulla carta non è la stessa cosa di un backup che si ripristina correttamente sotto pressione.

Questo divario — tra "abbiamo i backup" e "abbiamo backup resilienti al ransomware" — si riduce a tre pilastri: immutabilità, isolamento e recovery testata. Non sono controlli indipendenti da combinare a piacimento. Se ne manca anche solo uno, gli altri due non compensano: un backup immutabile che l'attaccante non può raggiungere è utile solo se viene effettivamente ripristinato, e un piano di restore ben testato non vale nulla se il backup da cui dipende è stato cancellato prima ancora che il test iniziasse.

I tre pilastri, nel dettaglio

1. Immutabilità: backup che un attaccante non può toccare

L'immutabilità significa che un backup non può essere alterato o cancellato all'interno della propria finestra di retention — né da uno script di retention mal configurato, né da un account amministratore compromesso, né dall'attaccante che ha già ottenuto credenziali di domain admin. In pratica viene implementata tramite object lock su storage cloud o a oggetti, hardware Write Once Read Many (WORM), oppure un repository Linux hardened con retention lock applicati a livello di storage, indipendenti dai controlli di accesso della stessa applicazione di backup.

La distinzione conta perché gli operatori ransomware moderni cercano attivamente i repository di backup raggiungibili con credenziali di produzione e li cancellano o cifrano per primi, prima ancora di toccare i dati primari. Se lo stesso account amministrativo che gestisce il software di backup può anche cancellare i restore point del mese scorso, l'immutabilità non è realmente in vigore — è un'impostazione che un attaccante sufficientemente privilegiato può disattivare in pochi minuti.

Le linee guida CISA sul ransomware sono esplicite su questo punto: mantenere backup offline, cifrati e immutabili, verificarli regolarmente e trattarli come l'ultima linea di difesa, non come il primo ostacolo che un attaccante deve superare.

2. Isolamento: un piano identitario separato e una copia del tutto irraggiungibile

L'immutabilità protegge il backup dall'essere modificato. L'isolamento lo protegge dall'essere raggiunto. I due concetti sono complementari, non intercambiabili, e le aziende che ne implementano solo uno tendono a scoprire il divario durante un incidente reale, non durante una design review.

L'isolamento ha due componenti. La prima è un piano identitario separato — l'infrastruttura di backup non dovrebbe fidarsi dello stesso dominio Active Directory, delle stesse credenziali amministrative o dello stesso segmento di rete flat della produzione. Un domain controller compromesso non dovrebbe automaticamente significare un ambiente di backup compromesso; se accade, significa che l'attaccante ha dovuto compromettere una sola cosa, non due. La seconda è una copia realmente offline o air-gapped — come minimo una copia dei dati critici priva di qualsiasi percorso di rete stabile dalla produzione, ottenuta tramite rotazione di nastri offline, un target di replica disconnesso che va online solo brevemente per ricevere i dati, oppure un tier cloud senza credenziali persistenti memorizzate in modo raggiungibile dall'ambiente di produzione.

La ricerca Veeam ha rilevato che le organizzazioni che danno priorità a questo tipo di resilienza isolata e a più livelli si riprendono da attacchi ransomware fino a sette volte più velocemente rispetto a chi non lo fa, con una perdita di dati significativamente inferiore lungo il percorso. È l'isolamento a rendere possibile questo divario: fa la differenza tra un attaccante che deve svolgere un lavoro aggiuntivo reale per raggiungere il vostro recovery point, e uno che ha già una sessione aperta su di esso perché condivide il piano identitario con i sistemi appena compromessi.

3. Recovery testata: dimostrare la ripristinabilità prima che serva

Il meno affascinante dei tre pilastri è anche quello che le organizzazioni saltano più spesso — e si vede nei risultati. In una survey di settore del 2025, il 62% delle organizzazioni ha dichiarato di non eseguire regolarmente test di backup-and-restore, e il 37% ha affermato di non essere riuscito a ripristinare entro il proprio recovery time objective (RTO) richiesto proprio perché i backup mancavano o non erano mai stati validati. Fiducia e realtà divergono nettamente: oltre il 60% delle organizzazioni crede di poter recuperare da un downtime nel giro di ore, ma solo circa un terzo ci riesce davvero quando viene messo alla prova.

I restore mai testati falliscono in modi che restano invisibili fino al momento in cui contano di più: catene di backup interrotte, dipendenze di application-consistency mancanti, credenziali di service account scadute mesi prima, oppure runbook scritti per una topologia infrastrutturale che non esiste più. Saltare la validazione comporta un rischio più grave del semplice downtime — si stima che il 63% delle organizzazioni rischi di reintrodurre un'infezione durante il ripristino perché salta i controlli di integrità e la scansione malware sotto la pressione del tempo, finendo di fatto per ripristinare lo stesso payload che aveva causato l'interruzione.

Un vero programma di recovery testata prevede drill di restore completi e pianificati in un ambiente di recovery isolato — non semplici notifiche di "job di backup riuscito" — validati rispetto agli RTO di cui il business ha realmente bisogno, non a cifre che sembrano solo rassicuranti in una slide.

Come si presenta la situazione quando i tre pilastri reggono

I dati Sophos del 2025 offrono un utile controesempio alle statistiche più eclatanti: tra le organizzazioni che hanno effettivamente subito la cifratura dei dati da parte di un attaccante, il 97% è comunque riuscito a recuperarli. La differenza tra questo gruppo e la piccola minoranza che non ci è riuscita quasi sempre si riconduce a uno dei tre pilastri più debole nella pratica di quanto sembrasse sulla carta — un retention lock che poteva essere aggirato dal ruolo sbagliato, una rete di backup "separata" che in realtà si fidava ancora dello stesso dominio, oppure un restore che non era mai stato realmente provato end-to-end.

Il costo di sbagliare

I tre pilastri non sono una checklist astratta di best practice — si traducono direttamente in quanto costa un incidente ransomware e quanto dura. Il costo medio per riprendersi da un attacco ransomware, escluso l'eventuale riscatto pagato, si aggira intorno a $1.53 million. Solo il 53% delle vittime è stato pienamente ripristinato entro una settimana; il resto ha trascorso più di sette giorni in uno stato di disservizio, con downtime, produttività persa e costi di incident response che si accumulavano giorno dopo giorno.

La postura di backup è una delle poche variabili di questa equazione che un'organizzazione controlla pienamente. Il successo o il fallimento della prima mossa di un attaccante contro il vostro repository di backup è determinato interamente da decisioni prese mesi prima — non durante l'incidente stesso. Nel momento in cui un threat actor ha credenziali di domain admin e sta sondando la vostra piattaforma di backup, immutabilità, isolamento e recovery testata sono già in vigore oppure non lo sono; non c'è modo di implementarli retroattivamente sotto pressione.

Errori comuni che minano silenziosamente tutti e tre i pilastri

Alcuni pattern ricorrono sistematicamente nelle review post-incidente:

• Confondere gli snapshot con i backup. Uno snapshot VMware è un delta point-in-time salvato sullo stesso datastore della VM che protegge — non una copia indipendente. Cresce in modo illimitato, degrada le performance e scompare nel momento stesso in cui sparisce il datastore. Gli snapshot sono una funzionalità comoda per rollback a breve termine, non una strategia di recovery.
• Trattare "immutabile" come una casella da spuntare invece che una proprietà verificata. Object lock e retention policy vanno testati contro l'esatto ruolo amministrativo che gestisce la piattaforma di backup, non semplicemente documentati in una guida di configurazione.
• Definire "isolata" una seconda copia nello stesso dominio identitario. Se le stesse credenziali compromesse in produzione possono autenticarsi sul repository di backup, la separazione geografica o di piattaforma non garantisce un isolamento reale.
• Misurare il successo dal completamento del backup, non dalla verifica del restore. Un segno di spunta verde sul job dell'ultima notte vi dice che i dati sono stati scritti da qualche parte. Non vi dice che i dati sono recuperabili, application-consistent e privi del malware che ha reso necessario il restore.

Dove entra in gioco BackupSec

In BackupSec aiutiamo i team enterprise a gestire i propri ambienti di backup esattamente su questi tre pilastri — non sostituendo la loro piattaforma di backup, ma rendendo la sicurezza del backup osservabile, consultabile e dimostrabile.

Il nostro approccio combina tre livelli:

• ZeroMON offre observability continua sull'intero estate di backup — monitoring Veeam-ready con tracking dei job in tempo reale, controlli di sicurezza automatizzati, audit trail forensi per il configuration drift e report di compliance a un click. È il livello che trasforma "l'immutabilità è configurata" da assunzione in evidenza.
• ZeroTAM fornisce advisory dedicata di esperti su architettura di backup, design dell'isolamento e pianificazione della recovery da ransomware — il livello umano di cui la maggior parte delle enterprise ha bisogno per interpretare cosa il proprio ambiente di backup sta realmente comunicando, e per progettare un isolamento che regga l'impatto di un incidente reale.
• ZeroPEN effettua pentest sulla vostra infrastruttura di backup come farebbe un vero avversario — puntando su management plane, controlli di accesso e impostazioni di immutabilità — per poi eseguire scenari di restore reali che validano la capacità di recuperare in modo pulito, completo ed entro l'RTO dichiarato, non solo che un job di backup abbia riportato successo.

BackupSec viene distribuito on-premise, si collega alle vostre applicazioni di backup tramite accesso API in sola lettura e non sposta mai i dati di backup al di fuori del vostro ambiente.

Parlate con BackupSec della vostra postura di sicurezza dei backup →

Volete scoprire se i vostri backup reggerebbero davvero? Valutate il vostro ambiente con il Backup Security Assessment gratuito.