Scopri come configurare backup immutabili, definire retention, accessi e test di ripristino per proteggere dati e continuità operativa aziendale oggi.

Un ransomware non deve necessariamente cifrare tutti i server per fermare un'azienda. Se raggiunge il repository di backup, elimina gli snapshot o modifica le policy di conservazione, il ripristino diventa impossibile proprio quando serve. Capire come configurare backup immutabili significa progettare una copia dei dati che non possa essere alterata o cancellata prima della scadenza stabilita, nemmeno da un account amministrativo compromesso.

L'immutabilità non è una funzione da attivare alla fine di un progetto. È una scelta architetturale che coinvolge dati, identità, infrastruttura, tempi di ripristino e responsabilità operative. Per una PMI, l'obiettivo non è accumulare copie ovunque, ma poter ripartire con dati coerenti entro un tempo compatibile con il business.

Cosa rende immutabile un backup

Un backup immutabile viene scritto su uno storage che applica una regola di conservazione non modificabile fino a una data precisa. Durante quel periodo, il file non può essere sovrascritto, eliminato o modificato attraverso le normali credenziali di gestione.

Il concetto è vicino al modello WORM - Write Once, Read Many. La piattaforma di backup invia i dati, lo storage registra il periodo di retention e impedisce ogni operazione distruttiva fino alla scadenza. È una difesa efficace contro ransomware, errori amministrativi, script mal configurati e cancellazioni intenzionali.

Non tutti gli snapshot sono immutabili. Uno snapshot sullo stesso datastore del server, gestito dallo stesso account e senza protezioni aggiuntive, può essere cancellato da chi compromette l'ambiente. Anche un backup copiato su un NAS condiviso resta vulnerabile se l'account di backup dispone di privilegi di eliminazione.

L'immutabilità reale dipende quindi dal punto in cui viene applicato il vincolo. Può essere ottenuta con object storage dotato di Object Lock, repository Linux hardened con protezioni a livello file system, appliance dedicate oppure servizi cloud con retention lock. La tecnologia scelta conta, ma conta di più verificare che il vincolo non sia revocabile con le credenziali usate ogni giorno per amministrare i sistemi.

Prima della configurazione: definire dati, RPO e RTO

Configurare una retention senza conoscere il valore dei dati porta quasi sempre a due problemi: costi di storage inutili o copie insufficienti. Prima di scegliere il repository, occorre classificare i sistemi.

Un gestionale, un database e-commerce, i documenti contabili e le caselle di posta non hanno necessariamente gli stessi requisiti. Per ogni servizio va definito l'RPO, cioè la perdita di dati massima accettabile, e l'RTO, il tempo massimo entro cui il servizio deve tornare operativo. Un database con RPO di un'ora richiede backup frequenti o log di transazione; un archivio documentale meno dinamico può seguire una pianificazione giornaliera.

Va definita anche la durata della conservazione. Per molte aziende ha senso mantenere copie operative a breve termine per il ripristino rapido, copie immutabili per alcune settimane o mesi e copie archiviate per esigenze amministrative o normative. Non esiste un numero valido per tutti: una retention troppo breve espone al rischio di scoprire tardi una compromissione; una retention eccessiva aumenta costi e complessità.

Un riferimento utile è la regola 3-2-1-1-0: almeno tre copie dei dati, su due supporti o domini differenti, una copia esterna, una copia offline o immutabile e zero errori verificati nei test di ripristino. Non sostituisce l'analisi tecnica, ma aiuta a evitare un errore frequente: chiamare "backup" una sola copia disponibile nello stesso ambiente di produzione.

Come configurare backup immutabili: architettura e accessi

La configurazione parte dalla separazione. Il server o il servizio che esegue il backup non dovrebbe condividere le stesse credenziali privilegiate, la stessa rete piatta e lo stesso dominio di amministrazione dei workload protetti. Se un attaccante ottiene l'accesso completo al tenant cloud o all'infrastruttura di virtualizzazione, deve incontrare un ulteriore confine prima di poter intervenire sulle copie.

Un'architettura pragmatica prevede un repository separato, con account dedicati e privilegi minimi. Il software di backup deve poter scrivere e leggere i dati necessari al restore, ma non modificare arbitrariamente la configurazione di immutabilità. Gli account amministrativi ordinari non devono avere la possibilità di accorciare la retention o disabilitare il blocco senza un processo controllato.

Quando si usa object storage, la policy di Object Lock va applicata al bucket prima del caricamento dei dati. In modalità governance, utenti con privilegi specifici possono talvolta aggirare il vincolo: è utile in contesti con esigenze operative particolari, ma riduce la protezione contro un amministratore compromesso. In modalità compliance, il blocco non può essere rimosso prima della scadenza, nemmeno dal proprietario dell'account. È la scelta più forte, ma richiede attenzione: un errore nella durata di retention può rendere indisponibile lo spazio o conservare dati oltre il necessario.

Per repository Linux, l'approccio corretto prevede una distribuzione aggiornata, accesso SSH limitato, autenticazione a chiave, servizi non necessari disabilitati e credenziali del repository separate da quelle della console di backup. Alcune soluzioni implementano un repository hardened dove l'account usato dall'applicazione non può rimuovere i backup per il periodo configurato. Questa protezione è valida solo se l'host non resta esposto con password condivise, accesso root ordinario o gestione remota aperta a tutta la rete.

La rete va segmentata. Il repository dovrebbe accettare connessioni solo dai nodi autorizzati e solo sulle porte necessarie. Esporre interfacce di amministrazione direttamente su Internet o consentire traffico laterale indiscriminato vanifica gran parte del lavoro fatto sullo storage.

Impostare retention, copie e verifiche

La retention immutabile deve essere allineata alla frequenza di backup e al tempo di permanenza tipico di un attacco. Se un malware resta inosservato per due settimane e le copie immutabili durano sette giorni, potrebbero essere disponibili solo backup già compromessi. In molti scenari aziendali, una finestra di 14-30 giorni per le copie giornaliere è un punto di partenza ragionevole, da estendere in base al rischio e al budget.

È utile mantenere più livelli di ripristino: backup recenti per recuperare velocemente un file o una macchina virtuale, backup immutabili per contrastare la manomissione e copie di lungo periodo per obblighi di conservazione. La copia immutabile non deve per forza essere quella più veloce da ripristinare. Un object storage esterno può avere tempi e costi di recupero superiori, ma offrire una separazione che un repository locale non garantisce.

Dopo aver definito la policy, bisogna controllare ciò che accade realmente. La console deve mostrare per ogni backup la data di scadenza dell'immutabilità e lo stato del job. I log devono essere centralizzati o almeno conservati fuori dal server di backup. Alert su errori di job, riduzione improvvisa delle dimensioni, cancellazioni anomale e modifiche alle policy consentono di intervenire prima che una situazione diventi un incidente.

Anche la cifratura è necessaria. I backup devono essere cifrati in transito e a riposo, con chiavi gestite in modo documentato. Ma attenzione: perdere la chiave equivale a perdere il backup. Le procedure devono prevedere custodia, rotazione e recupero delle chiavi, evitando che una sola persona detenga l'unico accesso possibile.

Il test di restore è la prova che conta

Un job concluso con esito positivo certifica solo che il software ha scritto dei dati. Non certifica che il database si avvierà, che l'applicazione funzionerà o che il ripristino rientrerà nell'RTO concordato.

I test devono includere almeno il recupero di file singoli, il ripristino di una macchina o di un container, il recupero coerente di un database e una simulazione di indisponibilità del sistema principale. Per un e-commerce o un gestionale, il test va esteso alla verifica applicativa: accesso utenti, integrità degli ordini, code, integrazioni e servizi esterni. Ripristinare un server senza verificare il servizio erogato non è sufficiente.

Ogni test dovrebbe produrre evidenze semplici: data, backup utilizzato, tempo impiegato, problemi riscontrati e azioni correttive. Questi dati trasformano il backup da adempimento tecnico a misura concreta di continuità operativa.

Errori che annullano la protezione

Il primo errore è rendere immutabile una sola copia che resta nello stesso dominio compromettibile della produzione. Il secondo è usare lo stesso account amministratore per hypervisor, backup, storage e cloud. Il terzo è impostare retention senza considerare capacità disponibile e tempi di rilevamento degli incidenti.

C'è poi un errore meno evidente: considerare il backup un progetto chiuso. Nuovi server, database, container Docker, bucket applicativi e integrazioni SaaS possono restare fuori dalle policy se non esiste una revisione periodica. Infrastruttura e software evolvono; la protezione deve evolvere con loro.

Per aziende che gestiscono applicazioni su misura, il backup va progettato insieme allo stack: database, file caricati dagli utenti, configurazioni, segreti, volumi persistenti e servizi esterni. Noventra affronta questo lavoro collegando requisiti applicativi, infrastruttura e procedure di ripristino, perché una copia valida deve riportare in servizio il processo aziendale, non solo ricreare una macchina.

Il risultato atteso non è una dashboard con molti job verdi. È la certezza operativa che, se un attacco o un errore colpisce l'ambiente, esista una copia protetta, recuperabile e abbastanza recente da consentire all'azienda di continuare a lavorare.