Strategia di backup contro il ransomware: backup immutabili, Air-Gap e ripristino rapido

Una strategia di backup contro il ransomware oggi è meno una questione di “abbiamo backup?” e più di “riusciamo, dopo un attacco mirato, a ripristinare davvero in modo pulito?”. I gruppi di ransomware non cifrano più solo le condivisioni file, ma prendono di mira server di backup, repository, account admin, host hypervisor e database. In molti incidenti il vero disastro non è la cifratura in sé, ma che le copie di sicurezza siano state cifrate insieme, cancellate, manomesse o semplicemente non siano ripristinabili.

Questo contributo mostra in modo pratico come combinare tre elementi: Immutable Backups (copie non modificabili), Air-Gap (una separazione tecnica o organizzativa) e un ripristino rapido tramite runbook testati. Il focus è sulla realtà operativa: identità, diritti, percorsi di rete, conservazione, monitoraggio, validazione del RESTore – e sulle tipiche trappole che in situazione di crisi costano minuti o giorni. Poiché molte infrastrutture aziendali usano MariaDB (ad es. per portali, monitoraggio, strumenti per asset o software aziendale personalizzato), la guida include inoltre best practice concrete per backup consistenti per MariaDB e per il point-in-time recovery.

Strategia di backup contro il ransomware: perché il ransomware prende di mira i backup oggi

Il ransomware è ormai spesso un attacco multi-step: initial access (ad es. via phishing, gateway VPN sfruttati, web service non patchati), movimento laterale, escalation dei privilegi e poi il mirato “rollout” della cifratura. I backup sono un obiettivo primario perché backup funzionanti vanificano l’estorsione.

Punti di attacco tipici nel contesto dei backup:

• Server di backup come „Single Point of Control“: se la console di backup può scrivere/cancellare a livello di dominio, basta un account admin compromesso per causare il disastro totale.
• Manipolazione dei repository: cancellazione dei punti di ripristino, riduzione dei periodi di conservazione (retention) o backup “sintetici” che continuano a includere dati già cifrati.
• VSS/Snapshot e snapshot di storage: Windows VSS (Volume Shadow Copy Service) e snapshot di storage vengono cancellati per rimuovere punti di ripristino rapidi.
• Credential harvesting: le credenziali di backup spesso si trovano in chiaro in script, su jump-host o come service account riutilizzati.
• Compromissione delle catene di backup: catene incrementali (ad es. forever incremental) possono essere “avvelenate” se la base non è protetta.

La conseguenza: un disegno di backup non deve solo «copiare dati», ma limitare i vettori di attacco, impedire la manipolazione e rendere il ripristino pianificabile.

Definire chiaramente gli obiettivi di protezione: RTO, RPO e „Clean RESTore“

Prima di scegliere la tecnologia, definite gli obiettivi di protezione:

• RPO (Recovery Point Objective): quale perdita di dati è accettabile al massimo? Esempio: 15 minuti per una MariaDB, 24 ore per un archivio.
• RTO (Recovery Time Objective): quanto rapidamente un servizio deve tornare operativo? Esempio: 2 ore per autenticazione/integrazioni ERP, 8 ore per il reporting.
• Clean RESTore: ripristino in uno stato pulito. Significa: prevenire di ripristinare malware, account compromessi o configurazioni manomesse.

Nei scenari di ransomware il recovery fallisce spesso per mancanza di ordine (cosa prima?), per credenziali mancanti (Break-Glass), per l’assenza di supporti d’installazione/chiavi o perché i processi di ripristino sono troppo lenti, in quanto mai testati realisticamente. Un buon concetto di backup è pertanto anche sempre un piano di ripartenza.

Componente 1: Comprendere correttamente gli Immutable Backups (e impiegarli correttamente)

Immutable Backups sono copie di backup che per un periodo definito non possono essere modificate o cancellate – neppure dagli amministratori. A seconda della tecnologia ciò si realizza come WORM (Write Once, Read Many), come «Object Lock» nello storage oggetti compatibile S3 o come immodificabilità nativa del repository.

Aspetti pratici dell’immutabilità

L’immutabilità è efficace solo quanto il controllo sui «comandi»:

• Identità indipendente: Se gli stessi account di Domain-Admin possono modificare anche le Object-Lock-Policies, l’immutabilità è vulnerabile. L’obiettivo è un mondo di identità e privilegi separati.
• Policy-„Write-Protect“: Idealmente la retention non può essere ridotta (Compliance/ Governance Mode vs. vera interdizione). Verificate se un account «Root» può rimuovere il blocco.
• Sicurezza temporale: In alcuni design il tempo/clock è un fattore. Se un attaccante manipola le fonti temporali o porta la policy a «scaduta», la situazione diventa critica. Utilizzate sorgenti NTP sicure e monitoraggio della deriva temporale.
• Minimizzare i percorsi di rete: Minori sono i sistemi che hanno diritti di scrittura sul repository immutabile, meglio è.

Trappole tipiche con gli Immutable Backups

• Immutabilità solo „sulla carta“: Uno Storage-Snapshot non è automaticamente immutabile se il Storage-Admin può cancellarlo.
• Retention troppo breve: Molti attacchi vengono scoperti tardivamente. Se i vostri backup immutabili durano solo 7 giorni, potrebbe non bastare.
• Mancanza di test di RESTore: Immutabile non significa automaticamente leggibile o consistente. Corruzione, cataloghi errati o chiavi mancanti sono rischi reali.

Regola pratica: L’immutabilità è un meccanismo di controllo contro la manipolazione, non un sostituto per copie multiple e non un Air-Gap.

Componente 2: Air-Gap – tecnico, organizzativo o entrambi

Air-Gap significa separazione: i backup non sono permanentemente raggiungibili dalla rete compromessa. Questo può essere implementato in modo „duro“ (supporti fisicamente separati) o „morbido“ (percorsi di rete temporaneamente separati, credenziali separate, trasferimenti unidirezionali).

Varianti di Air-Gap che funzionano in esercizio

• Supporti offline: Tape (LTO) o unità di storage rimovibili, che dopo il backup vengono separate fisicamente. Vantaggio: molto robusti contro attacchi di rete. Svantaggio: disciplina del processo, logistica, tempo di RESTore.
• Rete di backup isolata: server/repository di backup in un segmento separato, con regole firewall RESTrittive e senza accesso generico a Internet. Importante: la segmentazione non è un Air-Gap se un attaccante può comunque muoversi tramite account amministrativi.
• One-Way-Transfer / Staging: un repository di „landing“ accetta i backup, un secondo sistema estrae (pull) i dati ed è non scrivibile dalla zona di produzione. Questo riduce il rischio che account di produzione cancellino l’ultima copia di backup.
• Cloud-Object-Storage mit Object Lock: non è un Air-Gap classico, ma in combinazione con una netta separazione delle identità e permessi API minimi spesso costituisce un componente offsite molto robusto.

Importante è la domanda: Come impedisce il vostro design che un Domain-Admin compromesso possa anche „amministrare“ l’Air-Gap? La risposta è di norma: identità separate, sistemi separati, percorsi di accesso separati (Jump-Hosts), e flussi di dati preferibilmente basati su pull.

Componente 3: il ripristino rapido è un obiettivo di progetto, non un ripensamento

„Rapido“ non dipende solo da banda e storage, ma da procedure e parallelizzazione. Nei casi di Ransomware spesso occorre contemporaneamente reinstallare, ruotare le credenziali, isolare la rete, effettuare acquisizioni forensi e dare priorità ai servizi.

Priorità di RESTore: cosa deve tornare operativo per primo

Definite una sequenza tecnica di riavvio. Spesso consigliata:

1. Identità e servizi di base: DNS, NTP, servizi di directory (con particolare cautela), PKI/ certificati, Jump-Host.
2. Livello di virtualizzazione/compute: gestione degli hypervisor, accessi allo storage, eventualmente orchestrazione dei container.
3. Piattaforma dati: MariaDB/PostgreSQL/SQL Server, Message Queues, servizi file centrali.
4. Applicazioni core: soluzioni software vicine al processo, integrazioni, interfacce (API-Gateways).
5. Sistemi a valle: BI/reporting, Dev/Test, archiviazione.

Questa sequenza deve adattarsi al vostro panorama infrastrutturale. Fondamentale: evitare dipendenze che blocchino il RESTore (p. es. „le chiavi di backup si trovano nel file share cifrato“).

La regola 3-2-1-1-0 come guida (e cosa non risolve)

La nota regola 3-2-1 (3 copie, 2 supporti, 1 offsite) viene nel contesto Ransomware spesso estesa a 3-2-1-1-0:

• 3 copie: dati di produzione + almeno due copie di backup.
• 2 supporti/Targets diversi: p. es. Disk + Object Storage o Disk + Tape.
• 1 offsite: separato fisicamente (Cloud o secondo centro dati).
• 1 copia offline o immutable: questa è la leva anti-ransomware.
• 0 errori nella verifica: controlli regolari e test di RESTore, non solo „job segnato come riuscito“.

Cosa la regola non risolve: permessi errati, account amministrativi compromessi, runbook mancanti, chiavi/password assenti o percorsi di RESTore troppo lenti. Per questo servono misure operative concrete.

Architettura di backup contro il Ransomware: pattern di riferimento per il operativo

Un pattern pratico per ambienti di medie dimensioni è una catena di backup multilivello:

• Repository di backup primario (veloce): per RTO brevi, RESTore rapidi (p. es. ultimi 7–30 giorni), possibilmente vicino al compute (ma segmentato separatamente).
• Repository immutable/Offsite-Repository: Object Storage con immutabilità o secondo sistema con funzione WORM, retention prolungata.
• Copia offline opzionale: nastri o supporti offline esportati periodicamente per lo „scenario peggiore“ (ad es. se gli account cloud sono compromessi).

Importanti sono le direzioni di accesso: accesso in scrittura solo dove strettamente necessario; per la copia „ultima“ preferire meccanismi pull. Meno sistemi possono cancellare i backup, meglio è.

Identità e diritti: la causa più frequente per cui i backup muoiono con il sistema

Molti design di backup falliscono non per lo storage, ma per identità e accesso. Alcuni principi robusti:

• Gli account di backup non sono amministratori di dominio: separare i ruoli. Il backup di norma richiede diritti di lettura sulle sorgenti e diritti definiti sulle destinazioni, ma non privilegi completi nella directory.
• Percorsi amministrativi separati: console di backup e amministrazione del repository solo tramite jump-host rafforzati (non un notebook amministrativo normale).
• MFA e accesso condizionale: dove possibile, forzare. Particolarmente per le API cloud e la gestione del backup.
• Account Break-Glass: accessi di emergenza documentati offline, strettamente monitorati e utilizzati solo per il recovery.
• Gestione dei segreti: non nascondere password/chiavi in script o scheduler di task. Utilizzare un vault per i segreti o almeno store di credenziali sicuri nativi del sistema operativo.

Se dovete dare priorità a una sola misura: proteggere le identità di backup con la stessa forza delle vostre identità root di dominio o cloud. Negli incidenti è proprio quella la leva che decide se siete in grado di ripristinare.

MariaDB sotto pressione da ransomware: backup coerenti, PITR e ripristini rapidi

MariaDB è spesso un componente centrale per soluzioni aziendali digitali. In caso di ransomware il database è doppiamente critico: (1) contiene dati operativi, (2) è spesso oggetto di danni indiretti (LUN di storage cifrate, binlog manipolati, tablespace InnoDB distrutti).

Quali tipi di backup MariaDB sono adatti a cosa

• Backup logico (dump): esporta i contenuti SQL. Vantaggio: portabile, facilmente verificabile. Svantaggio: con grandi volumi di dati è lento, il ripristino richiede tempo, non ideale per RTO brevi.
• Backup fisico (basato su file/blocco): copia i file del database (es. InnoDB). Vantaggio: ripristino più rapido possibile. Svantaggio: la consistenza richiede un meccanismo affidabile (strumento di hot-backup o snapshot correttamente orchestrati).
• Point-in-Time-Recovery (PITR): combinazione di backup completo + binlog (Binary Logs). Vantaggio: RPO fino a minuti/secondi. Svantaggio: i binlog devono essere completi, intatti e temporalmente coerenti.

Per il ripristino da ransomware il PITR è spesso la differenza tra „l’ultimo backup notturno“ e „perdiamo solo pochi minuti“. Tuttavia il PITR è valido solo quanto la vostra disciplina sui binlog (rotazione, trasmissione, protezione, monitoring).

Setup pratico: backup completo + trasferimento dei binlog (con destinazione immutabile)

Un modello consolidato: backup completi regolari (es. notturni) e copia continua dei binlog in una destinazione separata e, preferibilmente, immutabile. In questo modo è possibile tornare a un momento prima della cifratura.

Requisiti importanti in MariaDB:

• Binary Logging attivo: i binlog sono i registri delle modifiche. Senza di essi non esiste PITR.
• GTID o gestione pulita delle posizioni: facilita il replay riproducibile, ma dipende dal vostro modello di replica/operativo.
• Percorso di esportazione separato: non conservare i binlog solo localmente sullo stesso volume del database.

Estratti di configurazione di esempio (adattare path/parametri al vostro ambiente):

[mysqld]
log_bin = mariadb-bin
binlog_format = ROW
expire_logs_days = 3
sync_binlog = 1
server_id = 123

Perché è stato scelto così: i binlog basati su ROW sono per PITR e la replica in workload eterogenei generalmente più affidabili rispetto a STATEMENT (meno sorprese dovute a istruzioni non deterministiche). Un breve expire locale non protegge dagli attacchi, ma riduce l’occupazione locale dello storage – il concetto di protezione reale è lo shipping offsite/immutabile.

Trasferimento dei binlog con robusta gestione degli errori (esempio via rsync su SSH verso una destinazione separata, idealmente una destinazione che non conceda diritti di cancellazione di ritorno):

#!/usr/bin/env bash
set -euo pipefail

SRC_DIR="/var/lib/mysql"
DEST_HOST="backup-ingest.example.net"
DEST_DIR="/data/mariadb-binlogs/$(hostname -f)/"

# Nur Binlogs übertragen, keine Löschungen auf der Gegenseite auslösen.
# So vermeiden Sie, dass lokale Rotation remote historische Logs entfernt.
rsync -av --ignore-missing-args 
  --include='mariadb-bin.*' --exclude='*' 
  "${SRC_DIR}/" "${DEST_HOST}:${DEST_DIR}"

Quando questo fallisce: se il server di destinazione appartiene allo stesso dominio di identità e amministrazione della produzione, un attaccante può compromettere il server di destinazione o le chiavi SSH. Per scenari critici è più robusto un modello pull: il server di destinazione estrae i log; la produzione non ha diritti di scrittura sulla repository finale immutabile.

Runbook di ripristino per MariaDB: da „abbiamo backup“ a „siamo di nuovo online“

Un runbook minimo utilizzabile per il PITR include sempre:

• Quale versione del backup è „clean“? (punto temporale, indicatori, approvazione da parte dell’Incident Lead)
• Dove si trovano backup completo, chiavi, checksum, binlog?
• Ordine di ripristino: ripristinare il backup completo, poi applicare i binlog fino al punto temporale obiettivo
• Validazione: controlli sulle tabelle, health check dell’applicazione, verifica utenti/grant
• Rollback: se il PITR fallisce, tornare all’ultimo backup completo consistente

Prevedete inoltre un ambiente di isolamento per il ripristino: eseguire il ripristino prima in una rete isolata (nessuna fiducia nei client «puliti»), poi effettuare il failover.

Test di ripristino: cosa bisogna testare (e cosa viene spesso dimenticato)

“Backup-job riuscito” non è garanzia di ripristino. I test di ripristino devono essere realistici ma scalabili. In pratica funziona una combinazione di:

• Campionamento automatizzato: ripristini piccoli giornalieri/settimanali (una sottocartella di file share, un piccolo DB, un’istanza VM/container).
• Esercitazione di recovery trimestrale: riavvio completo di un servizio critico incluse le dipendenze, misurazione del tempo per l’RTO.
• Controlli di integrità: checksum, controllo del catalogo, confronto numerico di file/ACL, controlli di consistenza DB.

Per MariaDB validazioni sensate sono ad es. l’avvio, i log di recovery InnoDB, query a campione e un controllo di salute dell’applicazione definito (es. login + transazione core). Importante: i test non devono mettere a rischio il sistema di produzione; usate il ripristino in un ambiente di test o su host isolati.

Checklist: indurimento dell’infrastruttura di backup contro il ransomware

La checklist seguente è pensata come “quick audit”. Non sostituisce un concetto di sicurezza completo, ma copre le vulnerabilità più frequenti.

Repository e storage

• Almeno una copia è immutabile (WORM/Object Lock) o offline.
• La retention non può essere ridotta dagli amministratori ordinari.
• Il repository non è membro del dominio se non strettamente necessario.
• Nessuna condivisione SMB/NFS generale scrivibile da molti server.
• Monitoraggio di operazioni insolite di cancellazione/riscrittura (se il sistema fornisce eventi).

Rete e percorsi di accesso

• La rete di backup è segmentata; le regole del firewall sono minimali (sorgenti → backup, non “any-any”).
• L’accesso di gestione è consentito solo tramite Jump-Host; l’accesso amministrativo è registrato.
• Nessun accesso diretto a Internet per i server di backup, salvo eccezioni chiaramente giustificate (aggiornamenti tramite proxy/repository).

Identità, segreti, esercizio

• Account di backup separati, nessun riutilizzo di password, MFA dove possibile.
• Rotazione regolare di chiavi/password e processo definito per la rotazione d’emergenza.
• Break-Glass documentato (offline), testato e monitorato.
• I Runbooks sono aggiornati: percorsi, IP, processo per le credenziali, priorità.

Troubleshooting: errori ricorrenti e controlli rapidi

«immutabile» può comunque essere cancellato

Controllo: chi può modificare le policy? Esiste un admin root/tenant che può ridurre la retention o disabilitare Object Lock? Verificate ruoli, API key e se il sistema di backup possiede «troppi» privilegi.

I backup ci sono, ma il ripristino è troppo lento

Controllo: il percorso di ripristino è spesso diverso da quello di backup. Misurate il throughput di ripristino verso il sistema di destinazione (I/O, rete, decompressione/de-dedup). Pianificate ripristini paralleli, dati prioritizzati (es. prima solo DB critiche) e ripristini a fasi (staged RESTore).

Il backup di MariaDB parte, ma il PITR fallisce

Controllo: segmenti di binlog mancanti, riferimento temporale errato, rotazione che elimina troppo pRESTo, o i binlog sono stati manipolati nell’attacco. Verificate la completezza (sequenza ininterrotta), la deriva dell’orologio e che i binlog finiscano in una destinazione resistente alla manipolazione.

Il ripristino riporta indietro dati cifrati/compromessi

Controllo incrociato: manca la scelta del momento e l’autorizzazione al „ripristino pulito“. In scenari ransomware è normale che i dati siano stati esfiltrati o manipolati già prima della cifratura. Definite un momento „Known Good“ e validate con controlli di anomalie (estensioni di file, modifiche di massa, aggiornamenti DB sospetti).

Attuazione per fasi: un percorso di migrazione realistico senza Big Bang

Se oggi eseguite un classico backup su disco nella stessa dominio, la transizione verso backup resilienti al ransomware può avvenire in modo graduale:

1. Dimostrare la capacità di RESTore: introdurre RESTore campione automatizzati, misurare RTO/RPO.
2. Indurire le identità: separare gli account di backup, istituire un jump host, migliorare MFA/gestione dei segreti.
3. Aggiungere una destinazione immutabile: attivare Object Lock/WORM per una copia aggiuntiva, definire la retention.
4. Aggiungere il componente Air-Gap: design offsite offline o basato su pull.
5. Runbook & esercitazioni: esercitazione di recovery per i servizi critici almeno trimestralmente.

In questo modo riducete il rischio in anticipo, senza dover cambiare tutto contemporaneamente.

Strategia di fallback: cosa fare se anche l’ecosistema di backup è compromesso?

Una strategia di fallback non è pessimismo, ma maturità operativa. Pianificate per il caso in cui server/account di backup siano compromessi:

• Copia offline indipendente: periodica e tracciabile, con documentazione su come venga letta.
• Ricostruzione da „bare metal“: Golden Images, IaC/Config-Management, repository di pacchetti, archivio licenze/chiavi.
• DNS/NTP di emergenza: una base piccola e isolata per poter eseguire i RESTore in modo corretto.
• Processo di comunicazione e approvazione: chi decide il „clean point“, chi autorizza il RESTore, chi documenta.

Il punto cruciale: i backup sono solo una parte. In scenari ransomware dovete parallelamente riconquistare le identità, reimpostare i permessi e assicurarvi di non riaprire immediatamente la stessa vulnerabilità.

Conclusione: i backup resilienti al ransomware sono un sistema complessivo

Una strategia di backup solida contro il ransomware nasce dall’interazione tra backup immutabili, un vero Air-Gap (tecnico o procedurale) e un ripristino rapido che viene esercitato regolarmente. Più che i singoli prodotti conta una architettura pulita: identità separate, privilegi minimizzati, flusso dati chiaro, retention tracciabile e validazione rigorosa dei RESTore.

Se dal testo portate via tre punti: (1) proteggete le identità dei backup come gioielli della corona, (2) costruite almeno una copia immutabile o offline, (3) testate il RESTore in modo che RTO/RPO diventino misurabili – in particolare per MariaDB inclusi i binlog e il Point-in-Time-Recovery. Così il backup smette di essere un „dovere“ e diventa uno strumento affidabile di riavvio.

Anche Air-Gap Backup e Ransomware Recovery sono rilevanti per questo tema. L’articolo colloca questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.