1. Origine e limiti strutturali del modello 3-2-1

La regola 3-2-1 nasce in un contesto di risk model prevalentemente accidentale:

• failure hardware,
• errori umani,
• eventi locali (incendio, allagamento, blackout).

Il modello presupponeva implicitamente:

• minacce non coordinate,
• assenza di attaccanti con persistenza,
• sistemi di backup separati ma fidati.

Dal punto di vista tecnico, il 3-2-1 garantiva:

• ridondanza dei dati,
• diversificazione dei supporti,
• protezione da eventi site-specific.

Ciò che non copriva (e non poteva coprire):

• attacchi con privilegi amministrativi,
• compromissione delle identity,
• movimenti laterali e attacchi “living off the land”,
• cancellazione o cifratura coordinata dei backup.

2. Il nuovo threat model: attacchi distruttivi e compromissione sistemica

Nel threat landscape attuale, i backup sono diventati target primari.
Gli attaccanti non puntano più solo alla cifratura dei dati di produzione, ma a:

• cancellare i repository di backup,
• corrompere i cataloghi,
• cifrare snapshot e copie secondarie,
• alterare retention e policy,
• sabotare i meccanismi di ripristino.

Dal punto di vista tecnico-operativo, questo significa che:

• la raggiungibilità di rete diventa una vulnerabilità,
• le credenziali condivise rappresentano un single point of failure,
• la separazione solo logica non è sufficiente.

Un backup compromesso è, di fatto, equivalente a un backup inesistente.

3. Dal backup alla recovery assurance

Il passaggio chiave non è tecnologico, ma concettuale:
dal backup come asset al backup come capability.

In termini BCM:

• non conta quante copie esistono,
• conta se e come possono essere ripristinate entro gli RTO/RPO definiti,
• conta la probabilità di successo del restore in condizioni avverse.

Questo introduce il concetto di Recovery Assurance, che richiede:

• isolamento,
• verificabilità,
• testabilità,
• governance.

4. Analisi tecnica della regola 3-2-2-1-1-0

La regola 3-2-2-1-1-0 non è una formula mnemonica, ma un framework di controllo del rischio.

3 copie dei dati

Ridondanza minima per gestire:

• errori di scrittura,
• corruzione silente,
• failure durante il backup o il restore.

2 supporti differenti

Riduzione del rischio di:

• bug sistemici,
• failure di firmware,
• vulnerabilità comuni di piattaforma.

Esempi:

• disco + object storage,
• NAS + tape,
• on-prem + cloud.

2 copie realmente separate

Elemento spesso sottovalutato.

La separazione deve essere:

• fisica (siti diversi),
• logica (account, tenancy, subscription),
• amministrativa (identity e ruoli separati).

Una separazione solo logica all’interno dello stesso dominio di sicurezza è insufficiente contro un attaccante persistente.

1 copia off-site

Protezione da:

• eventi distruttivi locali,
• incidenti ambientali,
• indisponibilità prolungata del sito primario.

Dal punto di vista BCM, questa copia è essenziale per la disaster recovery.

1 copia isolata o immutabile

È il vero salto di paradigma.

Soluzioni tipiche:

• air-gapped (fisico o logico),
• immutable storage (WORM, object lock),
• backup con retention non modificabile,
• separazione completa delle credenziali.

Caratteristica chiave:

anche con privilegi amministrativi compromessi, la copia non può essere alterata o cancellata.

Questa copia rappresenta l’ultima linea di difesa contro eventi cyber distruttivi.

0 errori nei test di ripristino

Il requisito più severo.

Significa:

• restore test automatizzati e periodici,
• verifica di integrità dei dati,
• misurazione reale di RTO e RPO,
• test anche in scenari degradati o di compromissione.

Un backup mai testato è un assunto, non un controllo.

5. Integrazione con BCM e BIA

Dal punto di vista del Business Continuity Management:

• la strategia di backup deve derivare dalla Business Impact Analysis,
• i dati devono essere classificati in base alla criticità dei processi,
• RTO/RPO non possono essere definiti dall’IT in modo autonomo.

Il backup diventa una misura di continuità, non un servizio infrastrutturale generico.

Questo implica:

• mapping dati ↔ processi critici,
• differenziazione delle policy di backup,
• allineamento con piani di crisi e di risposta agli incidenti.

6. Coerenza con resilienza operativa e requisiti normativi

Il framework 3-2-2-1-1-0 è pienamente coerente con i principi richiesti dai moderni requisiti di resilienza operativa:

• capacità di resistere a eventi estremi ma plausibili,
• capacità di recupero dimostrabile,
• evidenze oggettive di test,
• riduzione del single point of failure.

Non viene richiesto “di avere backup”, ma di:

• ripristinare funzioni critiche,
• entro tempi definiti,
• anche in presenza di attacchi distruttivi.

7. Conclusione tecnica

In un contesto moderno:

• il backup non è più una funzione IT,
• è una capability di resilienza operativa.

Senza isolamento, separazione reale e test rigorosi,
la presenza di backup non riduce il rischio di interruzione grave.

Le domande operative da porsi

• Qual è il livello di compromissione massimo che i nostri backup possono sopportare?
• Esiste almeno una copia non alterabile anche con identity compromise?
• I test di restore misurano davvero gli RTO/RPO dichiarati?
• La strategia di backup è progettata sui processi critici o sull’infrastruttura?

Perché, in ultima analisi, la resilienza non è una dichiarazione architetturale, ma una capacità verificata sotto stress

---