Backup immutabili: impedisci al ransomware di eliminare le copie di recupero

Il ransomware non si limita più a crittografare i file di produzione. Un attacco efficace cerca anche i sistemi che potrebbero annullare i danni: server di backup, console di gestione, archivi di snapshot e repository cloud. Se gli attaccanti possono eliminare o crittografare queste copie prima di chiedere il riscatto, l’organizzazione perde la via più sicura per tornare alla normalità operativa.

I backup immutabili affrontano proprio questa vulnerabilità. Creano punti di ripristino che non possono essere modificati o eliminati durante un periodo di conservazione definito, anche quando un attaccante ha ottenuto credenziali con privilegi elevati. Sono quindi un elemento fondamentale della protezione dal ransomware, ma da soli non costituiscono una strategia di ripristino completa. Anche crittografia, custodia delle chiavi, controlli degli accessi, monitoraggio e ripristini verificati sono importanti.

Per le aziende che gestiscono i propri server, Safenix offre backup off-site archiviati in Germania. I dati di backup sono crittografati con una chiave che Safenix non possiede e le copie sono immutabili per la durata del periodo di conservazione selezionato. Il risultato è un livello di ripristino separato dall’ambiente di produzione e protetto dall’eliminazione non autorizzata. Safenix protegge i server controllati dal cliente; non offre piani di backup per siti web che utilizzano hosting condiviso.

Perché il ransomware attacca i sistemi di backup

Molte organizzazioni considerano il backup una raccolta di file in attesa di essere ripristinati. Gli attaccanti vedono qualcosa di più prezioso: una mappa della resilienza aziendale. Una volta ottenuto l’accesso a un account amministratore di server, a una piattaforma di virtualizzazione, a una console di backup o a un’identità cloud privilegiata, possono scoprire dove sono archiviate le copie e per quanto tempo vengono conservate.

La sequenza dell’attacco spesso comprende diverse fasi:

• Rubare o indovinare le credenziali di un utente privilegiato.
• Disabilitare la protezione degli endpoint e il monitoraggio.
• Spostarsi dal sistema iniziale ai file server, ai database e agli host di virtualizzazione.
• Cercare software di backup, repository, snapshot e account di servizio.
• Eliminare i punti di ripristino o ridurne le impostazioni di conservazione.
• Crittografare i dati di produzione e qualsiasi copia di backup ancora raggiungibile.
• Chiedere un pagamento sostenendo che il ripristino sia impossibile senza la chiave dell’attaccante.

Un repository di backup semplicemente collegato allo stesso sistema di identità o alla stessa rete può quindi essere esposto anche se si trova su hardware separato. La separazione fisica è utile, ma non rende automaticamente sicura una copia. Se un amministratore compromesso può impartire un comando di eliminazione, il repository potrebbe fallire proprio quando serve.

La protezione dal ransomware deve considerare la possibilità che l’attaccante disponga di accesso a livello amministrativo. La domanda non è soltanto se gli utenti non autorizzati possano raggiungere il sistema di backup. Bisogna chiedersi se chiunque, compreso un account legittimo compromesso, possa rimuovere l’ultimo punto di ripristino integro.

Cosa impediscono realmente i backup immutabili

Un backup immutabile è un punto di ripristino protetto da modifiche o eliminazioni per un periodo definito. Durante tale periodo, i dati non possono essere sovrascritti, alterati o rimossi tramite le normali operazioni amministrative. La protezione si applica all’oggetto archiviato o al record di backup, invece di affidarsi soltanto a una policy che ordina all’amministratore di non eliminarlo.

L’immutabilità va considerata un meccanismo di applicazione. Una policy di conservazione stabilisce che una copia debba rimanere disponibile per 30, 90 o 365 giorni. Una policy di conservazione immutabile rende tecnicamente difficile o impossibile ignorare questo requisito prima della scadenza. La differenza diventa decisiva quando le credenziali vengono rubate.

Supponiamo che un’azienda disponga di backup giornalieri con conservazione di 90 giorni. Se un attaccante accede alla console di backup e modifica l’impostazione portandola a un giorno, la policy non offre alcuna protezione pratica. Se gli stessi punti di ripristino sono bloccati contro l’eliminazione fino alle rispettive date di scadenza, la modifica della console non rimuove gli oggetti bloccati.

L’immutabilità non significa che ogni backup sia permanente. Normalmente le copie diventano eliminabili dopo la scadenza del periodo di conservazione. Inoltre, non garantisce che i dati siano utilizzabili. Un database danneggiato, un backup applicativo incompleto o una procedura di ripristino mai testata possono comunque causare un errore di recupero. Lo storage immutabile protegge l’esistenza e l’integrità della copia; non convalida automaticamente ciò che contiene.

Immutabilità e conservazione ordinaria a confronto

La conservazione ordinaria è una pianificazione. Determina quanti punti di ripristino il sistema deve mantenere e quando è possibile rimuovere quelli più vecchi. Questa pianificazione è necessaria per gestire i costi di archiviazione, ma può essere controllata dalla stessa console e dagli stessi account amministrativi presi di mira dagli attaccanti.

La conservazione immutabile aggiunge una restrizione tecnica alla pianificazione. Una volta confermata, una copia non può essere eliminata prima della scadenza del blocco. Un buon progetto mantiene separata la decisione sulla conservazione dalla gestione quotidiana dei backup, così un operatore compromesso non può abbreviare la finestra dopo l’inizio di un incidente.

I due controlli funzionano insieme:

• Conservazione definisce quanto indietro nel tempo l’organizzazione desidera poter recuperare i dati.
• Immutabilità impedisce che una copia protetta venga rimossa o modificata prima di quel momento.
• Versioning può conservare più stati di ripristino invece di una sola copia continuamente aggiornata.
• Test di ripristino confermano che i dati conservati possano effettivamente supportare un recupero.

L’immutabilità non equivale a una copia offline

Un backup offline è scollegato dai sistemi di produzione, dalle reti o dalle interfacce amministrative. Può essere molto efficace perché il ransomware non può crittografare o eliminare direttamente una copia che non riesce a raggiungere. Un nastro conservato lontano dalla rete è un esempio tradizionale. Un disco rimovibile ricollegato regolarmente per il backup può offrire meno protezione se rimane connesso durante un attacco.

Lo storage offline e quello immutabile risolvono problemi correlati ma diversi. Le copie offline riducono la superficie di attacco eliminando la connettività. Le copie immutabili rimangono accessibili per il backup e il ripristino automatizzati, bloccando però le modifiche durante il periodo di blocco. Un’architettura resiliente può utilizzare entrambi, soprattutto quando i requisiti di ripristino giustificano lo sforzo operativo.

Esistono dei compromessi. I supporti completamente offline possono rendere più difficili i backup frequenti, il monitoraggio e i ripristini rapidi. È necessario ruotare i supporti, proteggerli fisicamente, tenere traccia della versione disponibile e assicurarsi che sia leggibile quando serve. Lo storage immutabile online o off-site può essere più semplice da gestire, ma deve essere isolato correttamente dalle identità e dai sistemi di gestione compromessi.

Il punto importante è non considerare automaticamente sicura qualsiasi copia scollegata. Un disco offline può essere perso, danneggiato, infettato prima del distacco o sovrascritto per errore. Ha bisogno di controlli di inventario, restrizioni di accesso e test di ripristino, proprio come qualsiasi altro backup.

Lo storage con accesso controllato non è automaticamente immutabile

Limitare l’accesso a un repository è essenziale, ma il controllo degli accessi da solo non impedisce l’eliminazione. Un amministratore può essere l’unica persona autorizzata ad accedere allo storage e avere comunque il permesso di cancellare ogni punto di ripristino. Se l’account amministrativo viene compromesso, il controllo diventa una capacità nelle mani dell’attaccante.

Il principio del privilegio minimo dovrebbe quindi essere applicato su più livelli. L’account che scrive i backup non deve necessariamente poterli eliminare. L’account che gestisce i processi di backup non deve necessariamente poter modificare i blocchi di conservazione. La persona che approva un ripristino non dovrebbe avere automaticamente accesso alle chiavi di crittografia o alla configurazione del repository.

L’autenticazione a più fattori, le identità amministrative separate, le restrizioni di rete e i flussi di approvazione riducono la possibilità che una password rubata porti a una compromissione completa. Sono misure di sicurezza importanti, ma non sostituiscono l’immutabilità. Un attaccante può aggirare un controllo tramite un endpoint vulnerabile, un token di sessione rubato o l’ingegneria sociale. Un punto di ripristino bloccato offre protezione dopo il fallimento dei controlli preventivi.

Object lock, WORM e repository isolati

Esistono diversi modi per implementare backup immutabili. La terminologia varia tra i prodotti, ma i principi di progettazione sono coerenti: confermare i dati in una posizione protetta, applicare un periodo di conservazione e impedire l’eliminazione o l’alterazione fino alla scadenza. Le aziende devono capire cosa viene effettivamente bloccato, chi può modificare la policy e se un amministratore può abbreviare il blocco.

Storage con object lock

L’object lock viene utilizzato comunemente con lo storage a oggetti. Ogni oggetto di backup riceve un timestamp di conservazione e il servizio di storage rifiuta le richieste di eliminazione o sovrascrittura prima di tale data. Alcune implementazioni offrono una modalità di governance che consente override autorizzati e una più rigida modalità di conformità, progettata per impedire tali override anche agli amministratori.

La distinzione è importante. Un blocco in stile governance può essere sufficiente per gli errori operativi ordinari, ma meno adatto quando il modello di minaccia include il furto dell’identità di un amministratore. Una modalità più rigida offre una protezione maggiore, ma richiede un’attenta pianificazione della conservazione, perché gli errori non possono essere corretti semplicemente eliminando l’oggetto.

L’object lock può funzionare bene per repository di grandi dimensioni e flussi di backup automatizzati. È comunque necessario proteggere l’account di storage, le credenziali API, la configurazione del bucket, le impostazioni di replica e i log. Un attaccante potrebbe non riuscire a eliminare gli oggetti bloccati, ma potrebbe tentare di interrompere i nuovi backup, modificare la pianificazione dei processi o attaccare il livello di gestione.

Storage WORM

WORM significa “write once, read many”, ovvero scrivi una volta, leggi molte volte. Un sistema WORM consente di scrivere e leggere i dati, ma impedisce che vengano modificati o rimossi durante il periodo di protezione. Il WORM può essere implementato nello storage a oggetti, in appliance specializzate o in altre architetture di storage.

WORM descrive il comportamento dello storage, ma non garantisce che ogni prodotto che utilizza questo termine offra lo stesso livello di sicurezza. Chiedi se il periodo di conservazione è applicato dal livello di storage, se un amministratore può ignorarlo, come il sistema gestisce le modifiche dell’orologio e cosa accade in caso di problemi di capacità o replica.

Repository di backup isolati

Un repository isolato separa i dati di backup dalla rete di produzione, dalla directory delle identità e dal piano di gestione. L’isolamento può essere fisico, logico o entrambi. Può includere un account separato, credenziali diverse, percorsi di rete limitati, un canale di backup unidirezionale e un processo amministrativo dedicato.

L’isolamento è particolarmente prezioso quando un cliente gestisce diversi server o sedi. Anche se un ambiente di produzione viene compromesso, l’attaccante non dovrebbe ottenere automaticamente l’accesso a ogni repository. Il repository dovrebbe ricevere solo i permessi necessari per acquisire e fornire i backup, mentre l’eliminazione e le modifiche alla conservazione dovrebbero rimanere protette da un controllo separato.

Per un confronto pratico tra questi approcci, compresi i concetti di backup immutabile e protezione dal ransomware, consulta le indicazioni aggiornate sugli approcci ai backup immutabili per la protezione dal ransomware insieme alla documentazione tecnica della piattaforma di storage considerata.

Perché contano la crittografia e la custodia delle chiavi

L’immutabilità impedisce a un attaccante di eliminare o modificare un backup. La crittografia protegge i contenuti se qualcuno accede allo storage, copia i dati o ottiene l’accesso all’infrastruttura sottostante. Entrambi i controlli sono necessari, perché un backup che sopravvive al ransomware ma espone informazioni su paghe, clienti, aspetti legali o salute crea un incidente di sicurezza diverso.

La crittografia dovrebbe coprire i dati in transito e quelli a riposo. L’agente di backup dovrebbe inviare i dati tramite una connessione protetta e i dati archiviati dovrebbero rimanere crittografati nel repository. La crittografia riduce il valore di uno storage rubato, ma solo se le chiavi sono gestite separatamente dai dati e non sono disponibili a ogni amministratore che può accedere alla piattaforma di backup.

La custodia delle chiavi richiede particolare attenzione. Se il fornitore del servizio possiede l’unica chiave di decrittografia utilizzabile, una compromissione dei suoi sistemi o un’azione interna non autorizzata potrebbe esporre i dati. Se il cliente controlla la chiave, ottiene un controllo più forte sulla riservatezza, ma assume anche la responsabilità di proteggerla e mantenere un processo di ripristino utilizzabile.

Safenix utilizza chiavi di crittografia controllate dal cliente, che Safenix non possiede. Questo approccio aiuta a separare il ruolo di storage del fornitore dalla capacità del cliente di decrittografare i propri dati. Le aziende che valutano questo modello possono leggere informazioni sull’approccio di Safenix alla crittografia e alle chiavi custodite dal cliente, quindi verificare come funzioneranno nel proprio ambiente la generazione, il backup, la rotazione, l’accesso e il ripristino di emergenza delle chiavi.

La custodia delle chiavi dovrebbe essere documentata prima di un incidente. Decidi chi può accedere alla chiave, come viene autorizzato l’accesso, dove viene conservata una copia di emergenza e come l’organizzazione potrà recuperare i dati se l’amministratore abituale della chiave non è disponibile. Una chiave persa può rendere irrecuperabile un backup immutabile altrimenti integro.

Progettare la conservazione dei backup per il ripristino dal ransomware

Non esiste una risposta universale alla domanda: “Per quanto tempo devono essere conservati i backup immutabili?”. Il periodo corretto dipende dalla rapidità con cui viene rilevato un attacco, dal tempo durante il quale un attaccante può rimanere inosservato, dagli obblighi legali e contrattuali dell’organizzazione e dal tempo necessario per analizzare e ricostruire i sistemi.

Una finestra di conservazione breve può essere adeguata per un ambiente ridotto, con rilevamento rapido e bassa complessità dei dati. Può essere pericolosa per un’organizzazione in cui una compromissione può rimanere nascosta per settimane. Se i file crittografati o alterati vengono inclusi nei backup giornalieri per 30 giorni prima della scoperta, una finestra immutabile di 30 giorni potrebbe non lasciare alcun punto di ripristino integro.

Fattori che dovrebbero influenzare la finestra di conservazione

• Tempo di rilevamento: stima quanto potrebbe servire per identificare crittografia anomala, abuso degli account o corruzione silenziosa dei dati.
• Tempo di analisi: conserva punti integri abbastanza a lungo da analizzare l’attacco senza distruggere le prove o ripristinare dati provenienti da un periodo contaminato.
• Tempo di recupero: includi il tempo necessario per ricostruire l’infrastruttura, convalidare le applicazioni e recuperare i dati per fasi.
• Impatto sul business: i sistemi critici possono giustificare una conservazione più lunga e punti di ripristino più frequenti.
• Conformità e contratti: alcuni dati richiedono una conservazione più lunga, anche se la conservazione dei backup non dovrebbe essere considerata una policy completa di gestione dei documenti.
• Costo dello storage: una conservazione più lunga consuma più spazio, quindi utilizza livelli o pianificazioni adeguati al valore e alla frequenza di modifica di ogni carico di lavoro.

Un approccio utile consiste nel combinare backup operativi a intervalli brevi con punti di ripristino conservati più a lungo. Per esempio, un’organizzazione può mantenere copie recenti frequenti per un recupero rapido, copie giornaliere per diverse settimane e alcuni punti settimanali o mensili per periodi più lunghi. La pianificazione esatta dovrebbe basarsi sugli obiettivi di ripristino, non su un’impostazione predefinita.

Non lasciare che la conservazione scada mentre un incidente è ancora in fase di analisi. Se viene scoperta una possibile compromissione, conserva i punti immutabili rilevanti ed estendi il periodo o esporta separatamente ciò che serve per l’analisi forense e il ripristino, in base alle capacità dell’architettura di storage. Il team che gestisce l’incidente deve sapere quali copie sono bloccate e quando scadranno.

Ripristino quando le credenziali amministrative vengono rubate

Le credenziali rubate non neutralizzano automaticamente i backup immutabili. Se l’attaccante può accedere alla console di backup ma i punti di ripristino sono bloccati nello storage, potrebbe riuscire a interrompere i processi futuri o disturbare le operazioni senza eliminare le copie protette. Questa separazione è uno dei motivi principali per usare lo storage immutabile.

La risposta deve comunque essere immediata e metodica:

1. Isola i sistemi interessati. Scollega, quando possibile, i server o i segmenti di rete compromessi. Non permettere all’attaccante di continuare a crittografare i dati o raggiungere altri sistemi.
2. Disabilita e ruota le credenziali. Revoca le sessioni rubate, reimposta le password privilegiate e ruota le credenziali dei servizi. Controlla chiavi API, token e account che possono accedere ai repository o ai sistemi di crittografia.
3. Proteggi l’ambiente di backup. Limita l’accesso alla console, blocca gli indirizzi di origine sospetti, esamina le modifiche amministrative e conferma che i blocchi di conservazione siano ancora attivi.
4. Blocca le automazioni distruttive. Metti in pausa i processi o le integrazioni che potrebbero sovrascrivere dati integri, preservando le copie immutabili già confermate.
5. Identifica l’ultimo punto sicuramente integro. Utilizza log, prove sugli endpoint e controlli applicativi per determinare quando è iniziata la compromissione. Non presumere che il backup più recente sia sicuro.
6. Ricostruisci un’infrastruttura affidabile. Ripristina i componenti fondamentali di identità, rete e gestione da fonti sicuramente integre, invece di riutilizzare sistemi compromessi.
7. Ripristina in un ambiente controllato. Recupera prima un sistema rappresentativo, analizzalo, convalidane la configurazione e verifica che applicazioni e dati funzionino correttamente.
8. Documenta decisioni e prove. Registra quale punto di ripristino è stato utilizzato, chi lo ha approvato, cosa è stato ripristinato e quali indicatori di compromissione sono stati rilevati.

Non testare mai un recupero ripristinando direttamente sopra l’unica copia di produzione ancora disponibile. Quando possibile, utilizza una rete isolata o una destinazione separata. In questo modo eviti che un backup corrotto o compromesso danneggi l’ambiente integro e offri al team un luogo sicuro per convalidare il ripristino.

I test di ripristino fanno parte della sicurezza dei backup

Una copia immutabile che non può essere ripristinata è un archivio costoso, non un piano di recupero affidabile. I processi di backup possono segnalare un esito positivo pur omettendo un database applicativo, escludendo un file di configurazione necessario, non acquisendo uno stato coerente o producendo un ripristino con dipendenze irrisolte.

I test di ripristino dovrebbero essere eseguiti regolarmente e riflettere i sistemi di cui l’azienda ha realmente bisogno. Un test a livello di file è utile, ma non dimostra che un’intera applicazione possa tornare online. Verifica diversi tipi di recupero:

• Ripristina singoli file e conferma autorizzazioni, proprietari e timestamp.
• Ripristina un database e convalida le transazioni e gli indici dell’applicazione.
• Recupera un server completo o una macchina virtuale in un ambiente isolato.
• Ricostruisci un servizio critico quando l’infrastruttura originale non è disponibile.
• Verifica che le chiavi di crittografia siano disponibili e utilizzabili dal personale autorizzato al ripristino.
• Misura la durata del recupero e confrontala con l’obiettivo di ripristino aziendale.

Utilizza con attenzione i dati di test. Un ambiente di ripristino può contenere informazioni personali o riservate, quindi necessita di controlli degli accessi e procedure di smaltimento adeguati. Conserva una registrazione scritta dei risultati dei test, degli errori e delle azioni correttive. Un test che individua una dipendenza mancante è utile solo se in seguito viene modificata l’architettura di backup.

Almeno un’esercitazione dovrebbe simulare la perdita dell’ambiente di produzione e della console di backup. In questo modo verifichi che l’organizzazione sappia individuare le copie protette, autenticarsi al servizio di ripristino, accedere alle chiavi controllate dal cliente e ripristinare i dati senza dipendere da un server di gestione compromesso.

Monitoraggio e privilegio minimo intorno alle copie immutabili

L’immutabilità riduce l’impatto dei tentativi di eliminazione, ma il monitoraggio aiuta a rilevare l’attacco prima che sia necessario il ripristino. Controlla variazioni nella frequenza dei backup, volumi di dati insoliti, processi falliti, nuovi amministratori, modifiche alle policy di conservazione, accessi da luoghi non familiari e tentativi improvvisi di enumerare i repository.

Gli avvisi dovrebbero raggiungere persone che non dipendono esclusivamente dall’ambiente di produzione potenzialmente compromesso. Se il ransomware disabilita email o strumenti di monitoraggio, una notifica relativa a un errore di backup inviata solo tramite tali strumenti potrebbe non essere mai vista. Proteggi i log dalle alterazioni e conserva una cronologia sufficiente per analizzare chi ha avuto accesso al servizio di backup e cosa ha tentato di fare.

Il privilegio minimo deve essere riesaminato periodicamente, non configurato una volta e poi dimenticato. Rimuovi gli account inattivi, separa le identità umane da quelle dei servizi, limita le reti di origine che possono raggiungere le interfacce di gestione e richiedi l’autenticazione a più fattori per gli accessi privilegiati. Quando possibile, usa credenziali separate per scrittura dei backup, ripristino, amministrazione e gestione della conservazione.

Non concedere a un application server ampi permessi per eliminare i dati del repository. Un server compromesso dovrebbe poter inviare i dati necessari al proprio backup, non amministrare l’intero ambiente di backup. Lo stesso principio vale per le agenzie che gestiscono più ambienti cliente.

Proteggere più ambienti cliente senza rendere impraticabili i ripristini

Le agenzie, i fornitori di servizi gestiti e i team IT devono spesso proteggere diverse aziende contemporaneamente. La centralizzazione può migliorare la coerenza, ma può anche creare un obiettivo di grande valore. Se un unico account amministrativo condiviso o una sola console di gestione controlla tutti i repository dei clienti, una credenziale rubata potrebbe esporre l’intero portafoglio.

Un modello multi-cliente più sicuro separa tenant, credenziali, policy e permessi di ripristino. Ogni ambiente cliente dovrebbe avere il proprio confine logico e una titolarità chiara delle chiavi di crittografia. Un tecnico che deve ripristinare il server di un cliente non dovrebbe poter consultare o eliminare automaticamente i backup di un altro.

La semplicità operativa resta importante. Una separazione eccessiva può rendere il recupero lento o confuso, soprattutto durante un incidente grave. Le agenzie dovrebbero mantenere un catalogo chiaro dei servizi per ogni cliente, includendo:

• Server e applicazioni protetti.
• Frequenza dei backup e periodo di conservazione.
• Stato dello storage immutabile e date di scadenza.
• Proprietà delle chiavi di crittografia e procedura di accesso di emergenza.
• Contatti approvati per il ripristino e requisiti di autorizzazione.
• Priorità di recupero e dipendenze tra sistemi.
• Ultimo test di ripristino riuscito e problemi ancora irrisolti.

Utilizza policy standard quando i carichi di lavoro sono simili, ma rendi esplicite le eccezioni. Un piccolo file server, un cluster di database e un domain controller possono richiedere pianificazioni e sequenze di ripristino diverse. I modelli aiutano a evitare omissioni, ma non devono sostituire i test specifici per ogni carico di lavoro.

Le agenzie dovrebbero anche esercitarsi in uno scenario di isolamento del cliente. Supponi che l’account amministrativo di un cliente sia compromesso e verifica che il team possa sospendere l’accesso di quel tenant senza interrompere gli altri. Esegui quindi un ripristino usando la chiave, il percorso di approvazione e la destinazione corretti. In questo modo confermi che i confini di sicurezza non creino un vicolo cieco operativo.

Errori comuni che indeboliscono la protezione dei backup immutabili

Conservare l’unico backup sul server di produzione

Un backup locale può essere rapido e utile, ma condivide i rischi del server di produzione. Un processo ransomware con privilegi amministrativi può crittografare sia i file attivi sia la directory di backup locale. Anche un guasto hardware, un incendio o un furto possono eliminare entrambe le copie contemporaneamente. I backup locali dovrebbero supportare il recupero rapido, non essere l’unico livello di ripristino.

Presumere che gli snapshot siano immutabili

Gli snapshot sono punti temporali comodi, ma molti possono essere eliminati dallo stesso amministratore che controlla la piattaforma di produzione. Alcuni snapshot sono inoltre esposti al ransomware tramite volumi montati o autorizzazioni ereditate. Considera uno snapshot immutabile solo quando lo storage sottostante applica un blocco che gli amministratori interessati non possono aggirare.

Usare un solo account per ogni attività

Un unico account che crea processi, modifica la conservazione, elimina i dati e gestisce la crittografia dispone di troppo potere. Inoltre, rende difficile l’analisi perché non esiste una reale separazione dei compiti. Utilizza identità dedicate e documenta quali azioni può eseguire ciascuna.

Ignorare il processo di recupero delle chiavi

La crittografia controllata dal cliente è efficace solo quando il cliente può recuperare e utilizzare la chiave durante un’emergenza. Conserva le istruzioni di recupero in modo sicuro, verifica l’accesso con personale autorizzato e pianifica le assenze dei dipendenti. Non lasciare una copia non protetta della chiave accanto al repository di backup.

Testare solo quando qualcosa va storto

Un’emergenza è il momento peggiore per scoprire che un agente di backup ha escluso un database, che una credenziale è scaduta o che una destinazione di ripristino non ha spazio sufficiente. Pianifica i test e tratta i test falliti come problemi di sicurezza, assegnando responsabili e scadenze.

Checklist pratica per la sicurezza dei backup immutabili

Utilizza le seguenti domande per esaminare un’architettura di backup esistente o valutare un servizio off-site:

• Il ransomware eseguito con privilegi amministrativi di produzione può eliminare i punti di ripristino archiviati?
• Il blocco di conservazione è applicato dal livello di storage, invece di dipendere soltanto da un’impostazione della console di backup?
• Un amministratore può abbreviare o ignorare il periodo di blocco?
• I backup sono archiviati lontano dalla rete e dal sistema di identità di produzione?
• I dati in transito e quelli a riposo sono crittografati?
• Chi possiede la chiave di crittografia e l’organizzazione può recuperarla se l’amministratore della chiave non è disponibile?
• I permessi di backup, ripristino, eliminazione e gestione delle policy sono separati?
• L’autenticazione a più fattori è attiva per gli accessi privilegiati?
• Vengono monitorati modifiche, processi falliti e tentativi di accesso sospetti?
• La finestra di conservazione considera il probabile tempo di permanenza del ransomware nell’ambiente?
• Sono stati testati ripristini completi delle applicazioni, non solo di singoli file?
• L’organizzazione può ripristinare i dati se la console di backup di produzione è stata compromessa?
• Per più clienti, tenant, credenziali, chiavi e permessi di ripristino sono separati?

I backup immutabili sono una base, non l’intero piano di ripristino

La resilienza al ransomware dipende da più livelli. Protezione degli endpoint, applicazione delle patch, sicurezza delle identità, segmentazione della rete e consapevolezza del personale riducono la probabilità di compromissione. I backup immutabili off-site limitano i danni quando questi controlli falliscono. La crittografia e le chiavi controllate dal cliente proteggono la riservatezza. Il monitoraggio rende visibili le attività sospette. I test di ripristino trasformano i dati archiviati in una capacità di recupero realmente utilizzabile.

La distinzione più importante è tra un backup che esiste e un punto di ripristino che rimane disponibile durante un attacco. La conservazione ordinaria, un repository con accesso controllato o uno snapshot sulla piattaforma di produzione potrebbero non sopravvivere a un amministratore compromesso. Lo storage immutabile è progettato proprio per questo scenario: conserva i punti di ripristino per la finestra concordata, anche quando qualcuno in possesso di credenziali rubate tenta di eliminarli.

Per le aziende che controllano i propri server, un’architettura di backup off-site con crittografia, chiavi custodite dal cliente, archiviazione dei dati in Germania e immutabilità può offrire un solido livello di ripristino indipendente. Le misure di sicurezza devono essere riesaminate e testate regolarmente, perché lo storage immutabile non sostituisce i ripristini verificati. Rende possibile un ripristino affidabile; una pratica di recupero disciplinata dimostra che funzionerà.