Backup a prova di ransomware e conformi alla ISO 27001

C'è un assunto ancora diffuso: se l'azienda ha i backup, allora può riprendersi da un ransomware. È vero solo a metà. Il ransomware moderno non si limita a cifrare i dati di produzione. Prima cerca le console di backup, le credenziali salvate, i repository raggiungibili, gli snapshot, le share di rete e le copie sincronizzate. Se riesce a distruggere o cifrare anche quelle, il backup esisteva solo sulla carta.

Per questo una strategia di backup moderna non va progettata pensando al guasto di un disco, ma a un avversario attivo che ha già compromesso una parte dell'infrastruttura.

Il problema non è fare la copia

Fare una copia è facile. Renderla recuperabile sotto attacco è un altro mestiere.

Gli errori più comuni sono sempre gli stessi:

• server di backup unito allo stesso dominio Active Directory della produzione;
• repository raggiungibile con credenziali amministrative ordinarie;
• snapshot sullo stesso storage dei dati primari, senza separazione reale;
• backup sincronizzati automaticamente, ma senza versioning o immutabilità;
• nessun test di restore recente;
• nessuna evidenza del tempo effettivo di ripristino.

Un attaccante che ottiene privilegi elevati non vede "backup": vede un secondo obiettivo. Se può cancellare la retention, eliminare snapshot, disabilitare job o distruggere il repository con le stesse credenziali usate per amministrare la produzione, quella non è resilienza. È una copia comoda.

La regola 3-2-1-1, letta bene

La regola 3-2-1 resta una buona base:

• 3 copie dei dati;
• 2 supporti o sistemi diversi;
• 1 copia fuori sede.

Oggi aggiungo una quarta condizione:

• 1 copia immutabile o realmente isolata.

Questa ultima riga è quella che cambia il modello di minaccia. Le prime tre proteggono da guasti, errori locali e perdita di sito. La quarta protegge da un attaccante che cerca deliberatamente di toglierti la possibilità di ripristinare.

La parola chiave è deliberatamente. Non stiamo difendendo solo da un errore umano. Stiamo difendendo da qualcuno che prova a cancellare tutto ciò che rende inutile il riscatto.

Immutabilità, snapshot e air gap non sono la stessa cosa

Qui serve precisione, perché molti progetti falliscono proprio sul linguaggio.

Immutabilità WORM. Write Once Read Many significa che una versione dell'oggetto non può essere modificata o cancellata prima della scadenza della retention. Un esempio forte è S3 Object Lock in compliance mode: durante la retention, la versione protetta non può essere cancellata o sovrascritta nemmeno dall'utente root dell'account. È una proprietà dello storage, non un permesso applicativo.

Governance mode. È utile, ma meno forte: utenti con permessi specifici possono bypassare la retention. Va bene per test, ambienti meno critici o modelli operativi controllati, ma non va venduto internamente come equivalente al compliance mode.

Snapshot locali. Snapshot ZFS, Btrfs o storage enterprise sono preziosi per recovery rapidi e protezione da errori. Ma se chi compromette il sistema può amministrare anche lo storage, può provare a eliminarli. Sono una difesa, non una garanzia assoluta.

Air gap. Un vero air gap è una separazione operativa: la copia non è raggiungibile dalla rete compromessa. Può essere fisico, temporale o logico molto rigido, ma deve resistere alla domanda più scomoda: se il dominio Windows è compromesso, l'attaccante può arrivare al backup?

Uno stack realistico per una PMI

Una configurazione difendibile non deve essere spettacolare. Deve essere coerente.

Un modello pratico:

• backup locale veloce per restore operativi rapidi, su NAS o server dedicato non unito al dominio;
• snapshot locali con retention breve, protetti da account separati e accesso amministrativo limitato;
• copia off-site cifrata su storage S3 compatibile con Object Lock;
• Object Lock in compliance mode sui set più critici, con retention coerente con RPO/RTO e obblighi di conservazione;
• credenziali separate per backup, console e storage, con MFA e privilegi minimi;
• test di restore trimestrale, documentato con tempi, dati ripristinati e anomalie rilevate;
• procedura di emergenza per ripristino senza dipendere dal dominio compromesso.

Il punto non è usare un marchio specifico. Acronis, Veeam, Borg, Restic, repository S3, NAS Linux, appliance dedicate: gli strumenti cambiano. Il criterio resta: una compromissione della produzione non deve implicare automaticamente la compromissione del backup.

Le evidenze che contano in audit

Sul piano ISO/IEC 27001, il backup non è solo tecnologia. È un controllo che deve lasciare prove. ISO/IEC 27001 è un sistema di gestione: richiede che il rischio sia governato, che i controlli siano scelti in modo coerente e che la loro efficacia sia verificabile.

In una verifica seria, le evidenze più utili sono:

Evidenza	Cosa dimostra
Politica di backup e retention	Esiste una regola approvata su cosa salvare e per quanto
Job di backup riusciti	Il processo gira davvero, non solo sulla carta
Test di restore	Il backup è utilizzabile e il tempo di ripristino è noto
Separazione degli account	Le credenziali della produzione non bastano per distruggere i backup
Object Lock / retention WORM	La copia critica non può essere cancellata prima della scadenza
Log delle operazioni	Modifiche, errori e accessi sono tracciabili
Runbook di recovery	Il ripristino non dipende dalla memoria del singolo tecnico

La frase che uso spesso è questa: un backup mai ripristinato non è una garanzia, è un'ipotesi. Un test di restore, invece, è un fatto.

Collegamento con NIS2

Anche NIS2 spinge nella stessa direzione. L'articolo 24 del D.Lgs. 138/2024 include continuità operativa, gestione dei backup, disaster recovery e gestione delle crisi fra gli elementi minimi delle misure di gestione del rischio. Non basta quindi avere copie: bisogna poter dimostrare che sono integrate nella continuità operativa.

Questo cambia la domanda interna. Non è più: "abbiamo il backup?". È:

• chi decide quali sistemi sono critici?
• quanto tempo serve per ripristinarli?
• quando è stato fatto l'ultimo restore?
• il backup sopravvive a una compromissione delle credenziali principali?
• chi può modificare retention e policy?
• dove sono le evidenze?

Se queste risposte sono chiare, il backup diventa una misura di resilienza. Se non lo sono, è solo un costo ricorrente.

Fonti principali

• AWS - Amazon S3 Object Lock
• ISO - ISO/IEC 27001:2022
• D.Lgs. 138/2024, art. 24 - misure di gestione dei rischi
• CISA - Ransomware Guide

La regola operativa, alla fine, è una sola: non aspettare l'attacco per scoprire se sai ripristinare. Un piano di backup vale quanto l'ultimo restore riuscito, documentato e ripetibile.