Backup anti-ransomware: immutabile non significa già ripristinabile

Per configurare backup resistenti al ransomware, imposta una conservazione che impedisca di modificare o cancellare in anticipo le copie, separa gli accessi di backup da quelli di produzione e mantieni una copia scollegata dalla rete ordinaria. Attiva avvisi sulle operazioni distruttive e controlla che i backup previsti vengano creati.

Completa la configurazione con una prova di ripristino in un ambiente isolato: scegli una versione precedente alla compromissione ipotizzata, recupera anche le dipendenze del servizio e misura il tempo fino al suo funzionamento. Una copia intatta può contenere dati già corrotti oppure risultare illeggibile se credenziali e chiavi non sono disponibili durante l’emergenza.

Definisci il servizio da recuperare e i tempi ammessi

Per ogni servizio essenziale fissa l’RPO, cioè la massima perdita di dati accettabile espressa in tempo, e l’RTO, cioè il tempo massimo per tornare operativi. La guida del NIST sui backup, rivolta ai fornitori di servizi gestiti, raccomanda di stabilire questi obiettivi, mappare le dipendenze tra sistemi e misurare durante le prove sia l’integrità dei file sia i tempi di recupero.

Elenca dati, applicazione, configurazioni, identità, certificati, chiavi di cifratura e collegamenti necessari ad avviare il servizio. Se il database è stato recuperato ma mancano le credenziali per avviare l’applicazione, il servizio non è ancora operativo. Stabilisci quali elementi debbano avere anche una copia offline e ogni quanto aggiornarla: un supporto scollegato resiste alla cancellazione remota, ma una versione troppo vecchia può superare l’RPO.

Separa account, gestione e copia offline

Le credenziali con cui si amministrano i sistemi di produzione non devono consentire di eliminare le copie protette. I principi del NCSC per i backup locali indicano credenziali amministrative distinte, interfacce di gestione separate da quelle che ricevono i dati, autenticazione a più fattori per le azioni distruttive e supporti conservati fuori rete.

Assegna al processo automatico solo i permessi necessari a eseguire i job; riserva modifiche delle politiche e cancellazioni a un ruolo distinto. In un ambiente di prova, verifica che le credenziali di produzione non permettano di alterare le copie o disattivare gli avvisi. Prevedi inoltre un accesso d’emergenza che resti possibile se il sistema ordinario di identità aziendale è indisponibile.

Una copia su supporto rimovibile, custodita e scollegata tra gli aggiornamenti, offre un percorso di recupero separato. La prova deve includere anche il prelievo del supporto, l’accesso alle chiavi e la sua lettura effettiva: sono passaggi che possono consumare parte dell’RTO. Per questo distribuire le copie su supporti diversi ha valore operativo solo insieme alla verifica del recupero.

Conserva le versioni e rendi rilevabile la cancellazione

Imposta una durata di conservazione che lasci disponibili versioni precedenti alla possibile compromissione, poi blocca la modifica o l’eliminazione anticipata secondo le capacità del sistema. Preferisci una politica basata sul tempo a un semplice numero di versioni: una sequenza di nuovi backup con dati corrotti non deve espellere rapidamente tutte le copie precedenti. Prima di fissare un vincolo irreversibile, verifica spazio, frequenza dei backup e necessità di conservazione dei diversi dati.

Immutabilità e cancellazione ritardata svolgono funzioni diverse. La prima protegge una copia da modifiche e rimozioni nel periodo stabilito; la seconda concede una finestra per intervenire dopo una richiesta di eliminazione. Quest’ultima è utile solo se l’avviso arriva a qualcuno che può agire prima della scadenza. Sorveglia anche job interrotti, cambi delle politiche di conservazione e degli account amministrativi, tentativi di cancellazione e spazio residuo, usando un canale di notifica raggiungibile durante un guasto alla produzione.

Le funzioni concrete dipendono dal servizio. La documentazione di Microsoft per Azure Backup descrive la cancellazione reversibile, l’autorizzazione aggiuntiva tramite Resource Guard per operazioni critiche, gli avvisi e i ripristini di prova. Quando valuti una soluzione, verifica separatamente quali copie sono protette, chi può ridurre la conservazione e quali azioni richiedono un’altra autorizzazione.

Ripristina in un ambiente isolato e prova il servizio

Prepara un ambiente con capacità sufficiente a ospitare i sistemi da recuperare, separato dalla rete di produzione. Per l’esercitazione definisci una finestra di compromissione ipotetica e scegli un punto precedente, annotando il motivo della scelta. La copia più recente potrebbe già contenere file cifrati o modificati: se il primo punto non supera i controlli, prova una versione anteriore e registra perché hai scartato la prima.

1. Recupera la copia con gli account, i supporti e le chiavi previsti per l’emergenza, senza dipendere dalle credenziali ordinarie di produzione.
2. Ricostruisci identità, configurazioni e altri prerequisiti, poi ripristina dati e applicazioni nell’ordine definito dalla mappa delle dipendenze.
3. Controlla errori di lettura, integrità dei file e coerenza dei dati. Cerca anche segnali di compromissione nei contenuti recuperati prima di considerarne il ritorno in produzione.
4. Avvia il servizio nell’ambiente isolato ed esegui le operazioni essenziali, verificando che utilizzino i dati recuperati.

Il completamento del job dimostra che il software ha eseguito il trasferimento, non che il servizio funzioni. Un controllo di integrità può rilevare errori dei file; la prova funzionale fa emergere configurazioni errate, dipendenze mancanti e dati incoerenti. Registra distintamente i due esiti, così un controllo superato non nasconde un’applicazione inutilizzabile.

Confronta i tempi reali con RPO e RTO

Fai partire il conteggio dell’RTO dal momento di interruzione simulato e fermalo solo quando il servizio supera la prova funzionale. Annota quanto richiedono accesso alle copie, lettura o trasferimento dei dati, ricostruzione dei sistemi e verifica finale. Per l’RPO confronta il momento dell’interruzione simulata con quello dell’ultimo dato utilizzabile nel punto effettivamente ripristinato, non con l’orario del backup più recente disponibile.

Registra a parte se gli avvisi sono arrivati e se un tentativo di cancellazione o modifica delle politiche è stato bloccato. Se un limite non è rispettato, identifica il passaggio responsabile — per esempio trasferimento lento, chiave assente o identità non disponibile —, correggi configurazione e procedura, quindi ripeti la prova interessata. Ripeti l’esercitazione quando cambiano servizi, dipendenze, accessi o politiche di conservazione: sono questi cambiamenti a poter rendere obsoleto un risultato prima valido.

Leggi anche:

• Il backup 3-2-1 non basta se non provi davvero il ripristino
• Revocare l’accesso Google non cancella i dati già copiati dall’app
• DigComp 3.0: trasformare 21 competenze in un piano che non insegua ogni app