La Fibonacci Rule of Backup Security: estendere la 3-2-1-1-0 per la sicurezza dei backup moderna

Perché le strategie di backup mature stanno fallendo nel 2026

Per anni la regola di backup 3-2-1 è stata il fondamento della protezione dei dati. Il fotografo Peter Krogh afferma di aver coniato il termine mentre scriveva la prima edizione di The DAM Book, e la sua guida al backup per il progetto dpBestflow dell'ASMP la espone così: tre copie di ogni file importante, su due tipi di supporto diversi, con una copia offsite. La formula si è diffusa ben oltre la fotografia. Il documento della CISA sulle opzioni di backup dei dati la ripropone per i dati personali e aziendali.

Ha funzionato. Finché non ha smesso di funzionare.

Il 2025 Data Breach Investigations Report di Verizon ha rilevato ransomware nel 44% dei breach analizzati, rispetto al 32% dell'edizione precedente. Quell'edizione copre gli incidenti da novembre 2023 a ottobre 2024; l'edizione 2026, che copre il periodo da novembre 2024 a ottobre 2025, porta la quota al 48%. Il team di ricerca di GuidePoint Security, che monitora le vittime pubblicate dai gruppi ransomware, ha registrato un aumento del 58% su base annua delle vittime di ransomware nel 2025, l'anno più attivo da quando effettua il monitoraggio. Ancora più rilevante per i risk officer aziendali: negli interventi di incident response di Mandiant del 2025, il Google Threat Intelligence Group ha osservato un furto di dati confermato o sospetto in circa il 77% delle intrusioni ransomware, contro circa il 57% del 2024. Quando i dati sono già stati sottratti, un restore impeccabile riporta in funzione i sistemi ma non risolve il breach.

La regola 3-2-1 è stata pensata per guasti hardware, interruzioni regionali e cancellazioni accidentali. Non è stata pensata per attaccanti che prendono di mira specificamente i repository di backup, né per insider con credenziali amministrative valide. Gli attaccanti sanno che distruggere i backup toglie alla vittima l'alternativa al pagamento. Lo stesso report di Google osserva che gli attori ransomware "often disabled or deleted backups to inhibit and/or limit recovery options" (spesso disattivavano o eliminavano i backup per impedire e/o limitare le possibilità di ripristino).

Per questo la regola è stata estesa. Veeam descrive la propria estensione, 3-2-1-1-0, come l'aggiunta di una copia immutabile e di zero errori di ripristino. In BackupSec proponiamo un ulteriore passo, che chiamiamo Fibonacci Rule of Backup Security e scriviamo 5-3-2-1-1-0. È il nostro framework, non uno standard di settore. Si legge come la successione di Fibonacci al contrario e aggiunge un sesto elemento: cinque principi di sicurezza fondamentali che devono sostenere ogni livello sottostante.

Per le organizzazioni che gestiscono ambienti di backup maturi, questo articolo ridefinisce che cosa dovrebbe significare "protezione completa dei dati" nel 2026.

Da 3-2-1 a 3-2-1-1-0: un breve riepilogo

Prima di presentare la Fibonacci Rule, vale la pena ricordare come ci siamo arrivati.

La regola 3-2-1 originale richiedeva tre copie dei dati su due tipi di supporto diversi, con una conservata offsite. Si concentrava sulla ridondanza, partendo dal presupposto che nessun singolo evento fisico potesse distruggere tutte e tre le copie contemporaneamente.

La regola 3-2-1-1-0, estensione dell'originale proposta da Veeam e oggi ampiamente adottata, ha aggiunto due affinamenti:

• Una copia immutabile o in air gap che non può essere modificata né eliminata, nemmeno da un attaccante con credenziali amministrative.
• Zero errori nella verifica dei backup, così che ogni backup sia noto come ripristinabile, non semplicemente presente.

Questa evoluzione ha colmato due lacune significative: il ransomware che prende di mira i backup e il fallimento silenzioso di backup mai testati fino al momento del disastro. Ma la regola non cerca di definire l'intera architettura di sicurezza attorno a quelle copie: separazione delle identità, accessi privilegiati, segmentazione, monitoraggio continuo e contenimento del blast radius.

È questa la lacuna che la Fibonacci Rule of Backup Security è pensata per colmare.

Perché Fibonacci? La logica dietro i numeri

La successione di Fibonacci (0, 1, 1, 2, 3, 5, 8, 13...) è uno degli schemi più eleganti della matematica: ogni numero è la somma dei due che lo precedono. Leggendo il nostro framework al contrario (5, 3, 2, 1, 1, 0), vale la stessa logica cumulativa: ogni livello di protezione si fonda su quelli sottostanti.

• 5 principi di sicurezza fondamentali. Cinque principi che governano come viene progettato il backup.
• 3 copie dei dati. Almeno tre copie di ogni dataset critico.
• 2 supporti o tipi di storage/piattaforma diversi. Conservate su due supporti, piattaforme di storage o stack tecnologici diversi.
• 1 copia offsite. Una copia in una località geograficamente separata.
• 1 copia aggiuntiva immutabile, isolata o comunque protetta. Un'ulteriore copia protetta da modifica o distruzione.
• 0 backup non verificati o errori di ripristino irrisolti. Nessun backup lasciato senza verifica, nessun errore di ripristino lasciato aperto.

La regola 3-2-1-1-0 originale rispondeva alla domanda operativa "Quante copie, dove e in quale stato?" Il "5" che abbiamo aggiunto risponde a una domanda architetturale più fondamentale: "Che cosa significa davvero che un backup è sicuro?"

Senza questi cinque principi, il resto della catena è vuoto. Un backup che esiste in tre copie, su due supporti, in stato immutabile, ma governato da controlli di accesso inadeguati o raggiungibile da una workstation amministrativa compromessa, non è protetto. È la documentazione di un'esposizione.

Il "5": cinque principi fondamentali della sicurezza dei backup

Questi cinque principi dovrebbero orientare ogni decisione architetturale nel vostro ambiente di backup, dalla scelta della piattaforma alla policy di retention fino alla governance degli accessi.

1. Architettura cyber-resiliente by design

La sicurezza dei backup non si può aggiungere a posteriori. Deve essere un vincolo di progettazione fin dal primo giorno.

Un'architettura di backup cyber-resiliente tratta ogni componente (il catalogo, il livello di storage, il management plane, l'ambiente di ripristino) come un potenziale bersaglio. Presuppone la violazione, pianifica la compromissione e garantisce che nessun singolo guasto, tecnico, umano o causato da un avversario, possa propagarsi fino alla perdita totale della capacità di ripristino.

In pratica, questo significa:

• Difesa in profondità: più controlli indipendenti proteggono ogni livello, così che il cedimento di uno non esponga il sistema.
• Contenimento del blast radius: la compromissione dell'ambiente di produzione non può propagarsi all'infrastruttura di backup, e la compromissione di un livello di backup non può propagarsi agli altri.
• Progettazione orientata al ripristino: le architetture vengono valutate non solo per quanto bene eseguono il backup dei dati, ma per quanto affidabilmente riescono a ripristinarli in condizioni ostili: quando il DNS non funziona, gli identity provider sono compromessi o il sito primario è irraggiungibile.
• La cifratura come primitiva architetturale, non come funzionalità: ogni backup, in ogni stato, deve essere protetto con una cifratura robusta e conforme agli standard di settore, a riposo e in transito, con chiavi di cifratura gestite in modo indipendente dall'infrastruttura di backup ovunque sia possibile, idealmente in un HSM dedicato o in un servizio di gestione delle chiavi con una titolarità amministrativa separata. Se le chiavi risiedono accanto ai dati, non avete cifratura; avete offuscamento. Per le aziende con flussi di dati transfrontalieri, la sovranità delle chiavi (chi può imporne la divulgazione, in quale giurisdizione, con quali tempi) diventa una decisione di progettazione, non un problema di incident response.

La sicurezza aggiunta a un sistema di backup progettato per un panorama di minacce più vecchio tende a mostrare le sue lacune nel pieno di un incidente, quando l'architettura stessa si rivela il punto debole. La resilienza va progettata fin dall'inizio.

2. Accesso Zero Trust e autenticazione forte

Il principio è semplice: non fidarsi mai, verificare sempre. Ogni richiesta di lettura, scrittura o modifica di un backup deve essere autenticata e autorizzata nel momento in cui viene effettuata, indipendentemente dalla provenienza di rete.

In termini pratici, ciò richiede:

• Autenticazione a più fattori (MFA) per ogni identità amministrativa che interagisce con l'infrastruttura di backup, idealmente con metodi resistenti al phishing come i token hardware.
• Controllo degli accessi basato sui ruoli (RBAC) che applichi il principio del privilegio minimo con granularità fine.
• Identità amministrative separate per i sistemi di produzione e di backup. Un domain admin compromesso non dovrebbe avere accesso alla vostra ultima linea di difesa.
• Privileged access management (PAM) con elevazione just-in-time, registrazione delle sessioni e flussi di approvazione per le operazioni sensibili, come le modifiche alle policy di retention.

Nell'indagine State of Ransomware 2025 di Sophos su 3.400 organizzazioni colpite da ransomware, le vittime hanno indicato le credenziali compromesse come causa principale del 23% degli attacchi, la seconda causa tecnica più comune dopo le vulnerabilità sfruttate (32%). Se il vostro ambiente di backup si affida alla stessa infrastruttura di identità che protegge la produzione, avete un single point of failure travestito da difesa a più livelli.

3. Immutabilità e storage WORM

L'immutabilità, la proprietà per cui i dati, una volta scritti, non possono essere modificati né eliminati per un periodo di retention definito, è passata da "best practice" a "irrinunciabile". Che sia implementata tramite Object Lock sullo storage cloud, supporti Write Once Read Many (WORM) o blocchi di retention imposti a livello hardware, l'immutabilità è una delle difese architetturali più efficaci contro gli attaccanti che vanno a caccia proprio dei repository di backup.

Per le aziende soggette a norme sulla conservazione dei documenti, l'immutabilità può anche supportare la compliance. La SEC Rule 17a-4 consente ai broker-dealer di conservare i documenti elettronici con un audit trail completo e marcato temporalmente oppure "in a non-rewriteable, non-erasable format" (in un formato non riscrivibile e non cancellabile). La HIPAA Security Rule richiede un piano di backup dei dati che crei e mantenga "retrievable exact copies" (copie esatte recuperabili) delle informazioni sanitarie protette in formato elettronico. La superficie di controllo che vi protegge dal ransomware è spesso la stessa su cui vi interroga il vostro auditor.

La CISA è più cauta della maggior parte dei vendor. La sua #StopRansomware Guide indica alle organizzazioni di "maintain offline, encrypted backups of critical data" (mantenere backup offline e cifrati dei dati critici) e di testarne regolarmente disponibilità e integrità. Menziona lo storage immutabile dei cloud vendor solo accompagnandolo con un avvertimento: "does not meet compliance criteria for certain regulations" (non soddisfa i criteri di conformità di alcune normative), e una configurazione errata può comportare costi significativi. L'immutabilità mantiene intatti i backup contro un attaccante che possiede già credenziali amministrative. Non sostituisce una copia offline né un restore testato.

4. Verifica continua e test di ripristino

Un backup che non avete testato non è un backup. È un'ipotesi.

Lo "0" di 3-2-1-1-0 richiede zero errori, ma l'unico modo per dimostrarlo è testare di continuo. I programmi maturi implementano controlli di integrità automatizzati, esercitazioni periodiche di restore completo, ambienti di ripristino isolati per la validazione ed esercitazioni tabletop strutturate che mettono sotto stress i livelli umani e di processo con lo stesso rigore di quelli tecnici.

Il ripristino sta diventando più rapido. Nella stessa indagine Sophos, il 53% delle vittime di ransomware si è ripreso completamente entro una settimana, contro il 35% del 2024, e il 97% si era ripreso completamente entro tre mesi. Sophos ipotizza che il miglioramento possa riflettere gli investimenti nella preparazione agli incidenti e nella prontezza al ripristino. L'indagine non isola l'effetto dei piani testati, ma il consiglio di Sophos stessa è di creare backup di qualità e di esercitarsi regolarmente a ripristinarli.

La lezione per i responsabili del rischio: il test è ciò che distingue le organizzazioni che hanno backup da quelle che sono in grado di ripristinare.

5. Isolamento e segmentazione di rete

L'infrastruttura di backup dovrebbe essere fortemente segmentata rispetto alla produzione e, ove possibile, non dovrebbe dipendere dagli stessi confini di fiducia amministrativa che proteggono i sistemi di produzione.

La best practice moderna combina la segmentazione logica (VLAN separate, subnet dedicate, regole firewall rigorose, micro-segmentazione) con architetture in air gap o quasi air gap per almeno una copia di ogni backup. Immutabilità cloud con identity provider separati, rotazioni di nastri offline, ambienti di ripristino dedicati e isolamento dei tenant nelle infrastrutture condivise servono tutti lo stesso obiettivo architetturale: garantire che il blast radius di una singola compromissione non possa estendersi al livello di ripristino.

Se un attaccante presente sul vostro domain controller può raggiungere il repository di backup con le stesse credenziali, il vostro backup fa parte della superficie d'attacco, non ne è separato.

Il "3-2-1": una ridondanza che conta ancora

Con i cinque principi come fondamento, il livello classico 3-2-1 resta essenziale.

• 3 copie di ogni dataset critico: i dati di produzione più almeno due backup.
• 2 supporti o piattaforme di storage diversi: disco locale e cloud, oppure object storage on-premises e un cloud provider separato. L'obiettivo è garantire che un singolo guasto tecnologico, un'interruzione di un vendor o una categoria di attacco non possano distruggere tutte le copie contemporaneamente.
• 1 copia offsite: geograficamente separata dal sito primario, idealmente in un dominio di minaccia diverso e, se opportuno, in una giurisdizione normativa diversa.

Ciò che è cambiato da quando la regola è stata formulata per la prima volta è l'interpretazione. Due region cloud dello stesso provider non costituiscono "due supporti diversi". Un volume di backup su una SAN collocata accanto all'array di produzione non è "offsite" in alcun senso significativo. Il threat modeling aziendale moderno richiede una lettura più rigorosa di ogni requisito.

L'"1-1": offsite e immutabile o in air gap

I due "1" riguardano domini di guasto diversi.

Il primo richiede che una copia sia conservata offsite, geograficamente separata dall'ambiente primario, così che un incidente a livello di sito, un guasto infrastrutturale o un disastro fisico non possano eliminare tutte le opzioni di ripristino contemporaneamente.

Il secondo richiede che almeno una copia aggiuntiva sia protetta da modifica o distruzione tramite immutabilità, air gap o un meccanismo di isolamento equivalente. Il suo scopo è diverso: la separazione offsite protegge dal cedimento di una località, mentre l'immutabilità o l'isolamento proteggono da un attaccante che ha ottenuto accesso amministrativo.

Questi requisiti possono sovrapporsi nell'implementazione. Una copia offsite può anche essere immutabile, e gli ambienti maturi possono mantenere sia un livello di ripristino immutabile sia una copia offline o in air gap più profonda. Ciò che conta è che la sola distanza geografica non venga trattata come isolamento di sicurezza.

Questa distinzione spiega anche perché l'immutabilità compare tra i cinque principi di sicurezza della Fibonacci Rule. L'"1" numerico definisce un requisito minimo di protezione per una copia di backup; il principio di sicurezza richiede che l'immutabilità sia considerata in tutta l'architettura, compresi i controlli di retention, gli accessi amministrativi, la separazione delle identità e il management plane.

Lo "0": tolleranza zero per i backup non verificati

Ogni backup verificato. Ogni restore testato. Ogni lacuna documentata e chiusa.

Lo "0" è il livello di disciplina operativa del framework. Richiede rigore: checksum automatizzati, validazione pianificata dei restore, rilevamento delle anomalie sui metadati dei job di backup (un improvviso picco nella dimensione di un job può indicare una fase di preparazione alla cifratura da parte di un attaccante), monitoraggio comportamentale delle attività amministrative sui backup e percorsi di escalation chiari quando la verifica fallisce.

Il ragionamento è semplice. Un attaccante che si prepara a distruggere i backup deve prima toccare il sistema di backup, e quelle modifiche compaiono nelle impostazioni dei job, nei valori di retention e negli audit log prima ancora che un restore fallisca. Zero errori non è una metrica di facciata. È la differenza tra fiducia e falsa fiducia nel momento in cui questa distinzione conta di più.

Cosa significa per i responsabili del rischio aziendale

Se la vostra organizzazione si affida a una strategia di backup progettata per un panorama di minacce diverso, il divario tra ciò che avete e ciò che vi serve non è più una questione accademica. Considerate la realtà finanziaria:

• L'indagine Sophos del 2025 ha rilevato un pagamento di riscatto mediano di 1 milione di dollari e un costo medio di ripristino, riscatto escluso, di 1,53 milioni di dollari.
• Il DBIR 2025 di Verizon riporta che il 64% delle organizzazioni vittime di ransomware non ha pagato, contro il 50% di due anni prima. Sophos, su un campione diverso, ha rilevato che il 49% delle vittime ha pagato il riscatto per riavere i propri dati. In entrambi i casi, pagare non è più la scelta predefinita, e un'organizzazione che rifiuta ha bisogno di un percorso di restore che funzioni.

Per le aziende dei settori regolamentati o che gestiscono ambienti ibridi complessi, il calcolo è ancora più stringente. Le società quotate negli Stati Uniti devono comunicare un incidente di cybersecurity rilevante tramite il Form 8-K, in genere entro quattro giorni lavorativi dalla determinazione della sua rilevanza, e molte altre giurisdizioni e settori impongono propri obblighi di notifica. Il costo di un incidente da cui non ci si può riprendere non è più solo operativo. È anche reputazionale e normativo.

Implementare la Fibonacci Rule non richiede di ricostruire l'infrastruttura da zero. Richiede una valutazione architetturale onesta, una remediation prioritizzata rispetto a un insieme chiaro di principi e un impegno di governance a trattare la sicurezza dei backup come una disciplina integrata, non come una voce di acquisto.

Il ruolo di BackupSec

In BackupSec aiutiamo i team a gestire i propri ambienti di backup Veeam secondo i principi sopra descritti. Non sostituiamo la piattaforma di backup; ne rendiamo la sicurezza osservabile, supportata da consulenza e testata.

• ZeroMON monitora Veeam Backup & Replication: stato di salute dei job, modifiche di configurazione con traccia di chi/cosa/quando, una checklist del Security Analyzer, report e un honeypot. Mostra lo stato di immutabilità così come lo riportano le impostazioni dei repository di Veeam; non verifica i lock a livello di oggetto sullo storage. Gli alert vengono inviati via email e tramite notifica in-app. Si installa on-premises come OVA, si connette con un account in sola lettura e non invia nulla a BackupSec né a terze parti.
• ZeroTAM vi mette a disposizione un advisor dedicato alla sicurezza dei backup per architettura, capacità, pianificazione del ripristino da ransomware e supporto prioritario in caso di crisi.
• ZeroPEN è un penetration test guidato dalle minacce su Veeam Backup & Replication, Veeam ONE ed Enterprise Manager: otto fasi della kill chain mappate su MITRE ATT&CK. L'engagement include anche la verifica dell'integrità del ripristino e dell'immutabilità. Non elimina mai backup reali, non esegue cifrature reali e non arresta servizi di produzione o di backup. Ottenete evidenze pronte per l'audit e un retest per le criticità gravi.
• ZeroVault è un object storage cloud immutabile compatibile S3 con Object Lock, per la copia immutabile offsite.

Parlate con BackupSec della vostra postura di sicurezza dei backup →