Cosa dice davvero la regola 3-2-1-1-0
La regola 3-2-1-1-0 è una formula di data protection che stabilisce quante copie dei propri dati mantenere, su quali tipi di media, e come dimostrare che funzionano davvero:
- 3 copie dei dati — la copia di produzione più almeno due backup.
- 2 media o piattaforme di storage diversi, in modo che un singolo guasto tecnologico o un outage del vendor non possa distruggere tutte le copie in una volta.
- 1 copia conservata offsite, geograficamente separata dal sito primario.
- 1 copia aggiuntiva immutabile o air-gapped — irraggiungibile o immodificabile anche da un attaccante con credenziali amministrative.
- 0 errori: ogni backup verificato e ogni restore testato, non semplicemente dato per funzionante.
Sembra una progressione naturale, ma le due cifre aggiuntive — il secondo "1" e lo "0" — non facevano parte della formula originale. Sono state aggiunte anni dopo, in risposta diretta al fatto che il ransomware ha imparato a colpire specificamente i backup. Capire perché sono state aggiunte spiega la strategia di backup moderna molto più della semplice checklist.
Da dove nasce la regola
La parte "3-2-1" del nome è precedente al ransomware. Il fotografo Peter Krogh coniò la formula nel suo libro del 2006 The DAM Book: Digital Asset Management for Photographers, distillando in una formula semplice un insieme di pratiche osservate tra i professionisti IT — abbastanza semplice da poter essere seguita davvero anche dai fotografi professionisti, che si trovavano improvvisamente responsabili di archivi digitali insostituibili pur non essendo amministratori di sistema. Krogh non inventò l'idea sottostante delle copie ridondanti e offsite; le diede un nome memorabile. La regola gli venne poi formalmente attribuita in una pubblicazione US-CERT del 2012 sulle opzioni di backup dei dati, quando ormai era già diventata la raccomandazione predefinita in tutto l'IT enterprise, e resta oggi una baseline sostenuta sia da CISA che da NIST.
La regola 3-2-1 originale era pensata per le minacce della sua epoca: guasto del disco, incendio, allagamento, furto e cancellazione accidentale. L'assunto di fondo era che nessun singolo evento fisico potesse plausibilmente distruggere tre copie di dati distribuite su due tipi di media e due location. Per circa un decennio, questo assunto ha retto.
Perché il solo 3-2-1 ha smesso di bastare
L'assunto si è rotto quando gli operatori ransomware hanno iniziato a trattare l'infrastruttura di backup come un bersaglio primario anziché un ostacolo da aggirare. Tre copie su due tipi di media con una offsite soddisfano ancora pienamente il 3-2-1 anche se tutte e tre le copie sono raggiungibili dallo stesso set di credenziali di produzione compromesse — che è esattamente lo scenario che i moderni gruppi ransomware cercano.
La portata di questo cambiamento è netta. Il report Veeam 2025 Ransomware Trends ha rilevato che l'89% delle vittime di ransomware ha avuto i propri repository di backup direttamente presi di mira durante l'attacco, su 1.300 organizzazioni intervistate. Il report Sophos 2025 State of Ransomware ha registrato il tasso di recovery da backup più basso nei sei anni in cui viene condotta la survey: solo il 54% delle organizzazioni è stato in grado di utilizzare i backup per ripristinare i propri dati, e tra quelle che hanno finito per pagare più della richiesta di riscatto iniziale dell'attaccante, il 38% ha indicato backup falliti o malfunzionanti come causa diretta.
Tre copie geograficamente separate non fermano in alcun modo un attaccante che possiede già le credenziali per cancellarle tutte e tre. È esattamente questo il divario che le due cifre aggiuntive sono state progettate per colmare.
Il secondo "1": una copia che gli attaccanti non possono davvero raggiungere
Il secondo "1" richiede almeno una copia immutabile — protetta da modifica o cancellazione per un periodo di retention definito, tipicamente tramite object lock su storage cloud, hardware Write Once Read Many (WORM), oppure un repository hardened con retention applicata a livello di storage — oppure air-gapped, cioè priva di qualsiasi percorso di rete stabile dalla produzione.
È un requisito più rigido di quanto sembri a prima vista. Due region cloud dello stesso provider, entrambe raggiungibili con lo stesso account amministrativo, non lo soddisfano — la separazione geografica senza separazione delle credenziali non è una protezione reale contro un attaccante che ha già il domain admin. Le implementazioni realmente efficaci combinano tipicamente storage immutabile su cloud, per un recovery rapido, con una copia offline o air-gapped più profonda per lo scenario peggiore in cui persino il management plane del tier immutabile è stato compromesso.
Le linee guida CISA sul ransomware sono esplicite nell'affermare che i backup offline e cifrati vanno trattati come l'ultima linea di difesa proprio perché si trovano al di fuori del raggio d'azione che un'identità compromessa può raggiungere.
Lo "0": dimostrare che il backup funziona davvero
Lo "0" è la metà operativa della regola, ed è quella che le organizzazioni saltano più spesso. Richiede zero backup non verificati — ogni backup controllato per integrità, ogni percorso di restore testato periodicamente end-to-end, non semplicemente monitorato in attesa di una notifica verde di "job riuscito".
Il divario tra job di backup che riportano successo e restore che funzionano davvero è ampio e ben documentato. Una survey di settore del 2025 ha rilevato che il 62% delle organizzazioni non esegue regolarmente test di backup-and-restore, e il 37% non è riuscito a ripristinare entro il proprio recovery time objective richiesto proprio perché i backup mancavano o non erano mai stati validati. Quando i restore vengono tentati senza un'adeguata scansione di integrità e malware, si stima che il 63% delle organizzazioni rischi di reintrodurre la stessa infezione che aveva causato l'interruzione — trasformando un tentativo di recovery in un secondo incidente.
Lo "0" esiste perché un backup che non è mai stato ripristinato non è un controllo — è un'assunzione. La verifica, effettuata con una cadenza regolare e misurata rispetto a target di recovery-time realistici, è ciò che trasforma quell'assunzione in un dato di fatto su cui poter contare durante un incidente reale.
Errori comuni nell'implementazione del 3-2-1-1-0
- Considerare due region cloud come "due media". La diversità di tipo di media significa tecnologie o piattaforme di storage realmente diverse, non due istanze dello stesso object store.
- Considerare il secondo "1" soddisfatto da una qualsiasi copia offsite. Offsite risolve il problema della geografia; immutabile o air-gapped risolve il problema della compromissione delle credenziali. Una copia offsite conforme alla regola ma che condivide il piano identitario con la produzione non colma il divario che ha motivato l'aggiunta della cifra.
- Saltare lo "0" perché i job di backup riportano verde. Un job di backup riuscito conferma che i dati sono stati scritti. Non conferma che i dati siano ripristinabili, application-consistent o privi del malware che renderà necessario il restore.
- Applicare la regola in modo uniforme senza considerare la criticità dei dati. I sistemi tier-one richiedono generalmente verifiche più frequenti e RTO più brevi rispetto ai dati di archivio; un'unica policy di retention e testing su tutto l'estate tende a sotto-proteggere i sistemi che contano di più e a sovra-investire su quelli che contano di meno.
Il 3-2-1-1-0 è ancora sufficiente nel 2026?
Per la maggior parte delle organizzazioni, implementare correttamente il 3-2-1-1-0 — con il secondo "1" e lo "0" realmente applicati, non semplicemente spuntati — colma gran parte del divario che ha permesso al ransomware di iniziare a colpire i backup. Resta una solida baseline operativa, e sia CISA che NIST continuano a sostenerla come tale.
Dove non basta è sull'architettura: il 3-2-1-1-0 risponde a "quante copie, dove e in che stato", ma non dice nulla sulla governance degli accessi, sulla segmentazione di rete e sul monitoring continuo che determinano se quelle copie restano tali sotto attacco. È proprio questo il divario che la Fibonacci Rule of Backup Security di BackupSec (5-3-2-1-1-0) è costruita per colmare, aggiungendo cinque principi di sicurezza fondamentali alla base della stessa formula di conteggio delle copie. Per un'organizzazione che sta ancora mettendo in atto il 3-2-1-1-0 in modo completo e verificabile, però, questo è un passo successivo — non un prerequisito.
Dove entra in gioco BackupSec
In BackupSec aiutiamo i team enterprise a verificare che la loro implementazione del 3-2-1-1-0 sia reale — non solo documentata — 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 il requisito "0 errori" della regola da una speranza in un'evidenza.
- ZeroTAM fornisce advisory dedicata di esperti su architettura di backup, configurazione dell'immutabilità e pianificazione della recovery da ransomware — il livello umano di cui la maggior parte delle enterprise ha bisogno per confermare che il proprio secondo "1" sia realmente isolato, non solo geograficamente distante.
- 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 dimostrano la capacità di recuperare in modo pulito, completo ed entro l'RTO dichiarato.
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 come si posiziona il vostro ambiente? Valutatelo con il Backup Security Assessment gratuito.