Reading Time: 6 minutes

Molte soluzioni di storage on-prem, di cloud storage e soluzioni di backup promettono sempre di più una sorta di immutabilità dei dati.

Naturalmente, l’immutabilità è una funzionalità chiave importante, ma non implica automaticamente che la soluzione sia sicura (o che sia automaticamente più sicura).

Può dare un falso senso di sicurezza se non implementato correttamente. In caso di configurazione errata, è possibile eliminare dati apparentemente immutabili, ad esempio manipolando le impostazioni di data/ora sul dispositivo di archiviazione per aggirare i meccanismi di applicazione della conservazione.

L’immutabilità in sè e per sè è solo un concetto: i backup immutabili (o non modificabili) sono copie di file e dati che non possono essere alterati o manomessi per un periodo di tempo prestabilito. L’archiviazione immutabile consente la conservazione inalterabile degli oggetti archiviati.

Ma la realtà può essere diversa e almeno dovremmo dividerla in due categorie principali:

  • immutabilità hard (o fisica): dove la protezione da scrittura è direttamente a livello dell’hardware eventualmente selezionabile (come i nastri con protezione da scrittura), o è insita direttamente nella tecnoglia usata a livello hardware (come i nastri WORM o CDR/DVD-R) o dove i dati sono totalmente isolati (tramite soluzioni offline e/o air-gapped).
  • immutabilità soft (o logica): l’archiviazione hardware rimane in modalità lettura/scrittura (come i dischi) ma vengono aggiunte alcune protezioni a livello software, come le funzionalità di blocco della scrittura (di solito per un certo periodo) o dall’utilizzo di funzionalità specifiche del filesystem.

L’immutabilità hard può fornire una migliore sicurezza in base alla progettazione, ma meno flessibilità perché richiede dispositivi speciali o operazioni manuali…

L’immutabilità non protegge dalla cancellazione o dal furto dei dati

Sarà un’osservazione ovvia, ma bisogna ricordarlo. Immutabile è comunque leggibile… quindi facile da “rubare” visto che basta farne una copia.

E immutabile non significa che non si possa distruggere totalmente il contenitore dei dati “immutabili”. Ad esempio formattando un disco. E persino per backup offline è possibile portare attacchi (chi ha visto “Mr. Robot – Stagione 1” sa di cosa sto parlando). Se è possibile per soluzioni di immuabilità hard, figuriamoci quando possa essere più fattibile per soluzioni di immutabilità soft!

L’immutabilità senza l’hardening è totalmente inutile

Questo discorso si applica soprattutto per i casi di immutabilità soft.

L’attività di hardening è assolutamente necessaria per migliorare la sicurezza, mitigare l’efficacia di attacchi diretti a basso livello (ad esempio distruggere le partizioni o i volumi), applicare le funzionalità di blocco/sicurezza e ridurre la superficie di attacco.

Ad esempio, per un repository Veeam su un server Linux, un repository di tipo hardening è obbligatorio per abilitare l’immutabilità… ma questo non implica che non si possano applicare altre soluzioni di hardening. Soprattutto per evitare situazioni paradossali, come avere il repository su una VM (invece che su un hardware dedicato, protetto e sottoposto ad hardening) oppure mantenendo attivate molte funzionalità di gestione remota del sistema Linux (aumentando il perimetro di attacco).

Hardening con MAC o RBAC

Uno dei grossi problemi sui normali sistemi operativi (come Windows, ma anche Linux) è il modello di autenticazione predefinito: il Discretionary Access Control (DAC) non è sufficiente per un sistema che deve garantire l’immutabilità.

Sono necessari altri modelli che dovrebbero essere implementati per rendere possibile, almeno, una separazione dei compiti e dei ruoli, dove l’utente che gestisce i dati non può modificare e rimuovere blocchi o etichette immutabili e dove gli amministratori di sistema non possono accedere ai dati protetti (o almeno non possono modificare le impostazioni di immutabilità). Solo gli utenti della sicurezza con accesso non diretto ai sistemi dovrebbero essere in grado di modificare (se necessario) le impostazioni immutabili.

Questi modelli si chiamano MAC (Mandatory Access Control) o RBAC (Role Based Access Control). Per maggiori informazioni: https://www.twingate.com/blog/other/access-control-models

Naturalmente, per gli appliance di archiviazione questo è molto più semplice da implementare (visto che già previsto in molti modelli) e per il cloud pubblico la separazione dei ruoli è by design (il provider e il consumer)!

Ci possono essere poi altri principi, come ad esempio il four-eyes principle (dove servono due persone diverse per approvare una particolare azione)… ma se il modello usato è DAC, allora questi principi possono essere aggirati facilmente (un amministratore di sistema che sia anche amministratore dei backup puo creare un altro finto amministratore e auto-approvare le sue azioni).

Se è online è attaccabile

Qualunque IP raggiugibile in rete, qualunque porta TCP/UDP aperta in ascolto è un potenziale problema visto che è una possibile superficie di attacco. Gli attacchi in rete (anche da rete interna o di tipo laterale dalla stessa rete) sono molto comuni!

Chiudere le porte di SSH/RDP può non bastare se la destinazione rimane collegata alla rete e i dati vengono inviati alla destinazione in modalità push (che prevede almeno una porta in ascolto). Usare VLAN dedicate o cavi di rete “cross” può mitigare alcuni attacchi, ma comunque rimane una risorsa online e raggiugibile via rete.

Le uniche soluzioni sono di lavorare in modalità offiline o in modalità air-gapped.

Ad esempio in sistema “immutabile” rimane in modalità off-line (con la rete scollegata) e periodicamente è lui che va prendere i dati da proteggere in modalità get (in modo che non siano necessarie porte in ascolto ma solo porte in modalità client). Soluzioni di “vault” come queste sono sempre più comuni.

Ricordiamoci però che ogni sistema deve rimanere aggiornato, quindi aggiornamenti e patch non sono opzioni o derogabili a tempo indefinito!

Immutabile non implica coerente o corretto

Un’altra minaccia comune relativa ai sistemi immutabili è il cosidetto poisoning (avvelenamento) dei dati. Se i sistemi di backup sono stati attaccati, è possibile manomettere la destinazione immutabile con processi di backup compromessi, avvelenare i dati prima che venga eseguito il backup in modalità immutabile e renderli inutilizzabili in fase di ripristino. Se l’attacco rimane inosservato per un periodo sufficientemente lungo (ad esempio, diversi mesi), è possibile avviare un attacco ransomware e le vittime rimangono senza backup coerenti da cui eseguire il ripristino.

Altro problema tipico potrebbero essere gli attacchi di tipo DoS (Denial of Service). Ad esempio è possibile riempire la destinazione immutabile con molti dati o molte connessioni cercando di renderla inutilizzabile (o per l’archiviazione su cloud pubblico, facendo aumentare esponenzialmente i costi). Assicurati di porre alcuni limiti alle connessioni e alla quantità di dati trasferiti per ridurre al minimo questo problema.

Share