Perché i backup NAS falliscono durante gli attacchi ransomware: RAID, snapshot e accesso condiviso spiegati

Un NAS può avere un RAID integro, snapshot pianificati e processi di backup completati correttamente, e tuttavia non offrire un percorso di ripristino utilizzabile dopo un attacco ransomware. Le domande decisive sono se rimane uno stato precedente pulito, se l’aggressore può modificarlo e se è possibile ripristinarlo senza affidarsi a credenziali o sistemi compromessi.

Le notizie sul ransomware Synology di ottobre 2026 offrono un punto di partenza attuale, ma questa è un’analisi dell’architettura di storage, non un’affermazione che riguarda ogni vittima. RAID, snapshot, sincronizzazione e backup indipendenti risolvono problemi diversi. Il ripristino fallisce quando non si comprendono i confini tra questi sistemi o quando copie apparentemente separate condividono la stessa autorità.

Foto di apertura: Korrupt / Wikimedia Commons, CC BY 4.0. Ritagliata e ridimensionata; il ritaglio fotografico mantiene la stessa licenza. Foto contestuale di hardware NAS, non di un dispositivo colpito o di una scena dell’incidente verificati.

Perché lo storage NAS è un bersaglio del ransomware?

Un NAS rende disponibili le informazioni in rete, di solito a più persone, applicazioni o computer. Questo è il suo scopo. Significa anche che esistono diversi modi in cui modifiche indesiderate possono raggiungere i file. Un aggressore potrebbe compromettere direttamente il NAS, prendere il controllo di un account autorizzato oppure controllare una workstation che dispone di accesso in scrittura a una cartella condivisa in rete.

Questi percorsi non richiedono difese identiche. Applicare una patch a una vulnerabilità di un servizio di gestione non revoca i permessi di condivisione già presenti su una workstation infetta. Al contrario, limitare le cartelle in cui un utente può scrivere non corregge un’applicazione di gestione vulnerabile. L’analisi dell’incidente nell’articolo correlato su C3RB3R e DSM spiega perché è importante distinguere il percorso di accesso.

Il ripristino solleva una seconda domanda: la stessa identità o lo stesso piano di controllo possono danneggiare le copie che dovrebbero essere utili in seguito? In tal caso, il numero di dischi, alloggiamenti o destinazioni cloud può far sembrare maggiore la separazione effettiva. Conta con la stessa attenzione i confini di guasto indipendenti e le copie.

Il RAID protegge i dati dal ransomware?

Le configurazioni RAID ridondanti sono progettate per tollerare guasti specifici dei dischi. Non stabiliscono se una scrittura dall’aspetto legittimo contenga un documento utile o dati crittografati inutilizzabili. In un esempio con RAID 1, quando un’applicazione autorizzata sovrascrive un file, il mirror ne conserva le modifiche. L’array può rimanere integro mentre il file diventa inutilizzabile.

Il meccanismo non è un aggiramento speciale del ransomware. Il mirroring svolge il suo compito normale: mantenere lo stato corrente dello storage su tutti i membri. Non conserva di per sé una versione pulita selezionabile del giorno prima. Il RAID 0 non è affatto ridondante; i diversi livelli RAID non devono essere considerati equivalenti in termini di tolleranza ai guasti.

Il RAID rimane utile. In una configurazione ridondante che funziona correttamente, il guasto di un disco durante il normale utilizzo non deve necessariamente causare un'interruzione del servizio. L'errore è aspettarsi che la resilienza dei dischi offra anche un ripristino storico, una separazione degli accessi o una protezione dalla perdita dell'intero enclosure. La guida sul RAID e il backup approfondisce questa distinzione. Anche le indicazioni di Synology per il backup dei NAS trattano le copie di ripristino come un aspetto distinto della pianificazione.

Il ransomware può eliminare o crittografare gli snapshot di un NAS?

Uno snapshot può essere una risposta efficace alle modifiche indesiderate dei file. In molte implementazioni degli snapshot, la modifica dei file attivi non sovrascrive i blocchi precedenti conservati per uno snapshot. Non bisogna quindi dare per scontato che un malware con normali autorizzazioni di condivisione dei file disponga automaticamente dei privilegi di amministrazione degli snapshot.

La distinzione importante è tra modificare i file e controllare il meccanismo che conserva gli stati precedenti. Gli snapshot ordinari potrebbero essere eliminabili da un amministratore con privilegi sufficienti. Altri offrono protezioni aggiuntive. Synology documenta gli snapshot immutabili per i sistemi supportati, con restrizioni temporanee che proteggono anche le strutture di storage che li contengono dalla cancellazione durante il periodo previsto. Sarebbe inesatto affermare che gli amministratori possano sempre eliminare tutti gli snapshot.

Chiedi quali snapshot esistono, quali controlli li proteggono e quando scade la loro protezione. Un periodo di conservazione breve può far sì che, quando ci si accorge dei danni, siano rimaste solo versioni successive alla crittografia. Gli snapshot locali, inoltre, non creano un altro dispositivo fisico: furto, distruzione fisica o perdita dello storage sottostante comportano problemi di ripristino diversi.

Perché i backup in rete possono essere compromessi tutti insieme?

Immagina un NAS principale che copia i file ogni notte su un secondo NAS. Se il sistema principale conserva credenziali che consentono di sovrascrivere la destinazione e cancellarne le vecchie versioni, una compromissione del sistema principale può mettere a rischio entrambe le copie. Un case diverso introduce una separazione hardware, ma non necessariamente una separazione amministrativa.

Lo stesso ragionamento vale per l'archiviazione cloud. Un archivio può trovarsi geograficamente lontano, mentre le credenziali per eliminarne i contenuti restano memorizzate su un host compromesso. Le indicazioni dell'NCSC del Regno Unito sui backup offline riguardano le copie locali connesse e quelle nel cloud, nonché l'importanza di controllare l'accesso dei client. La sola distanza fisica non limita ciò che una richiesta API autorizzata può eliminare.

La segmentazione della rete può contribuire a ridurre i servizi raggiungibili, ma una connessione consentita con autorizzazioni ampie può comunque essere pericolosa. Valuta l'identità effettiva usata dal processo, l'amministrazione dell'archivio e le autorizzazioni di conservazione. «Rete diversa» e «account diverso» sono descrizioni iniziali utili, non la prova che una richiesta distruttiva verrà rifiutata.

Sincronizzazione e backup: perché sono diversi?

In genere, la sincronizzazione cerca di fare in modo che le destinazioni rispecchino le modifiche apportate alla sorgente. Immagina una cartella del portatile sincronizzata con un NAS. Un malware cifra i file del portatile e il client di sincronizzazione carica i contenuti modificati. Lo stato di sincronizzazione può indicare correttamente un esito di ripristino fallito: la destinazione ora contiene fedelmente i file attuali danneggiati.

La cronologia delle versioni o il recupero dei file eliminati possono migliorare il risultato, ma solo se le versioni precedenti pertinenti restano accessibili. Verifica il periodo di conservazione, come vengono gestite le modifiche rapide, se un utente malintenzionato può cancellare la cronologia e se l'applicazione protegge le cartelle che ti interessano davvero. La sola etichetta «sincronizzazione» non risponde a nessuna di queste domande.

Una configurazione di backup utile conserva intenzionalmente uno stato ripristinabile, che può differire da quello della sorgente attuale. Deve conservarlo abbastanza a lungo da coprire i tempi di rilevamento e risposta. Una cartella copiata e sovrascritta continuamente non equivale a un archivio che conserva le versioni precedenti con controlli di protezione separati.

Perché è importante una strategia di backup 3-2-1?

Le opzioni di backup dei dati della CISA descrivono la regola di base più nota: tre copie delle informazioni importanti, inclusa la copia di lavoro; due tipi di supporto; e una copia fuori sede. L’obiettivo è evitare che un singolo guasto locale distrugga tutte le copie. È un utile schema per l’inventario, non una garanzia contro ogni attacco.

Fuori sede descrive la posizione. Offline descrive la connettività. Immutabile descrive le restrizioni alle modifiche per un periodo definito. Un repository cloud può trovarsi fuori sede ed essere sempre raggiungibile; un’unità USB scollegata può essere offline ma conservata accanto al NAS. Nessuna delle due descrizioni sostituisce l’altra.

In caso di ransomware, amplia l’inventario con domande su chi può modificare ciascuna copia e se una versione integra sopravvivrà all’incidente. Le indicazioni della CISA sul ransomware raccomandano backup offline e crittografati, nonché test regolari di ripristino. La crittografia dei backup protegge la riservatezza, ma da sola non impedisce a un aggressore autorizzato di eliminare il repository crittografato.

Cosa rende davvero indipendente un backup?

L’indipendenza è una relazione tra una copia di ripristino e uno specifico tipo di guasto, non una proprietà che si acquisisce comprando un altro disco. Inizia presumendo che l’amministrazione della produzione sia stata compromessa. L’amministratore può cancellare il repository, ridurre il periodo di conservazione, revocare l’accesso al ripristino o rimuovere l’unica copia di una chiave di crittografia?

Identità separate e autorizzazioni applicate possono limitare tale accesso. A chi scrive i backup può essere consentito creare nuovi punti di ripristino senza autorizzazione a eliminare quelli protetti meno recenti. L’amministrazione del repository e le credenziali di ripristino possono essere tenute separate dalla produzione. Verifica il modello di autorizzazioni effettivo del prodotto: non tutti i protocolli supportano questa separazione.

Prelevare i dati da un server di backup può tenere alcune credenziali lontane dal NAS di produzione, ma il «prelievo» non è intrinsecamente sicuro e l’«invio» non è intrinsecamente insicuro. Esamina dove risiedono le credenziali e cosa può fare ciascuna. Anche una rotazione offline richiede una procedura controllata di riconnessione: un’unità precedentemente isolata diventa raggiungibile durante la sessione di backup successiva.

Come fai a sapere se un backup può essere ripristinato?

Un processo completato è la prova che un'operazione è stata portata a termine, non che il servizio previsto possa essere ripristinato. Prova a ripristinare i dati in una destinazione pulita. Apri documenti rappresentativi, ripristina i permessi importanti e verifica che il database dell'applicazione sia coerente con i relativi file. Verifica anche che il punto selezionato preceda le modifiche indesiderate.

L'obiettivo del punto di ripristino, o RPO, indica l'intervallo massimo di perdita di dati accettabile. L'obiettivo del tempo di ripristino, o RTO, indica il tempo massimo accettabile per ripristinare il servizio. Una pianificazione oraria non dimostra un RPO di un'ora se i punti di ripristino recenti sono danneggiati o non disponibili. Ripristinare rapidamente un file non dimostra che l'intero servizio rispetti il suo RTO.

Come limite minimo a titolo esemplificativo, trasferire 2 TB di dati decimali tramite una connessione da 1 Gbit/s richiede circa 4,4 ore con un utilizzo perfetto della banda. Il ripristino reale comporta tempi aggiuntivi per la verifica, la gestione dei file di piccole dimensioni e le operazioni sulle applicazioni. Questo calcolo non è un benchmark NAS. Mostra perché un obiettivo di ripristino dovrebbe essere misurato considerando l'intero flusso di lavoro.

La pubblicazione del NIST sulla pianificazione dei backup sottolinea l'importanza di eseguire, mantenere e testare i backup. Anche la sua guida al ripristino dell'integrità dei dati considera attendibili i dati recuperati un obiettivo. La disponibilità dei byte e la fiducia in quei byte sono risultati correlati, ma distinti.

Che aspetto ha un'architettura NAS resiliente ai ransomware?

Un progetto pratico combina più livelli, invece di dichiarare sufficiente una sola funzionalità. L'accesso in scrittura alle condivisioni di produzione è limitato. Un RAID ridondante supportato gestisce i guasti dei dischi previsti. Gli snapshot forniscono versioni precedenti utili, con conservazione protetta ove disponibile. Un repository di backup controllato separatamente e una copia isolata o resa immutabile in modo appropriato offrono ulteriori possibilità di ripristino.

Un piccolo ufficio ipotetico potrebbe usare snapshot locali a intervalli brevi per proteggersi dalle modifiche accidentali, un repository versionato amministrato separatamente e una copia disconnessa a rotazione, conservata altrove. Questa configurazione è un esempio da valutare, non un'affermazione su una vittima di ottobre né una prescrizione universale. I dettagli dipendono dalla sensibilità dei dati, dal personale disponibile e dagli obiettivi di ripristino.

Traccia un importante set di dati attraverso il progetto. Individua il suo ultimo punto noto integro, le credenziali necessarie per ripristinarlo, dove si trovano le chiavi e quale macchina pulita è in grado di leggerlo. Poi ripeti l'esercizio supponendo che il NAS di produzione non sia disponibile. I passaggi mancanti rivelano più di una dashboard che mostra diversi processi di backup completati correttamente.

FAQ

RAID 1 conserva una copia non crittografata se il ransomware modifica un file?

No. Il mirroring normalmente replica le scritture correnti, comprese le modifiche indesiderate effettuate con accesso sufficiente. Non è una copia storica automatica. Per ripristinare uno stato precedente serve uno snapshot ancora disponibile, un backup con versioni o un’altra fonte adeguata.

Gli snapshot sono inutili contro il ransomware?

No. Possono conservare stati precedenti e consentire un ripristino rapido. La protezione dipende da autorizzazioni, conservazione, implementazione e controlli di immutabilità disponibili. Anche uno snapshot locale dipende fisicamente dal proprio sistema di archiviazione, un limite diverso dalla protezione a livello di file.

Un backup cloud fuori sede è automaticamente isolato?

No. «Fuori sede» indica una posizione diversa, non necessariamente un’autorità diversa o una connessione offline. Verifica chi può eliminare le versioni, se i sistemi di produzione dispongono di quelle credenziali e se la cronologia protetta resta disponibile dopo la compromissione di un account.

Crittografare un backup impedisce al ransomware di eliminarlo?

No. La crittografia protegge la riservatezza dei contenuti dei backup. L’autorità di eliminazione è una questione distinta. Proteggi le autorizzazioni e i criteri di conservazione del repository e mantieni accessibili le chiavi di ripristino tramite una procedura che non dipenda esclusivamente dal sistema compromesso.

Per quanto tempo conservare snapshot e versioni di backup?

Non esiste una durata valida per tutti. La conservazione deve coprire il tempo durante il quale le modifiche indesiderate potrebbero passare inosservate, il tempo necessario per le indagini e le esigenze di ripristino, tenendo conto dei limiti di archiviazione. Consulta la guida alla conservazione delle versioni dei file dopo un attacco ransomware per pianificare la scelta di un punto pulito. Verifica che la policy selezionata offra un punto di ripristino pulito e accessibile, non solo versioni danneggiate recenti.

Qual è il test di ripristino iniziale più utile?

Ripristina un set di dati importante in una posizione pulita usando le credenziali e gli strumenti che avresti a disposizione durante una vera interruzione del servizio. Verifica il contenuto dei file, le autorizzazioni, la coerenza delle applicazioni e il tempo impiegato. Poi controlla che il risultato rispetti gli obiettivi di perdita di dati e tempi di inattività accettabili.

Conclusione

RAID, snapshot e backup restano utili se si comprendono i rispettivi ruoli. Il problema più profondo è lasciare che i dati di lavoro e tutte le opzioni di ripristino dipendano dalla stessa autorità distruttiva, oppure scoprire troppo tardi che una copia conservata non può essere ripristinata. Conta le copie, ma verifica anche autorizzazioni, isolamento, conservazione e ripristino testato. L’analisi dell’incidente Synology esamina l’altra metà del problema: cosa dimostrano e cosa non dimostrano le prove pubbliche sull’accesso iniziale.