Quando si parla di crittografia nelle architetture di backup, si tende a concentrarsi sugli aspetti sbagliati. Si sente parlare di crittografia in transito, crittografia a riposo, crittografia punto‑punto—termini che suonano rassicuranti ma non rispondono all’unica domanda che conta: i dati sono mai stati in chiaro, anche solo per un istante, in qualunque punto tra la produzione e lo storage finale del backup? Se la risposta è sì, anche solo brevemente, avete introdotto un rischio di sicurezza.
La crittografia end‑to‑end elimina questa debolezza architetturale. Nel momento in cui Veeam legge i dati dallo storage di produzione, li cifra quando è attiva la crittografia dei file di backup. Da quel punto in avanti, i dati non tornano mai in uno stato non cifrato fino a quando Veeam non li ripristina. Non importa attraverso quanti data mover, gateway o reti transitino. Non importa quante copie vengano create. I dati vengono cifrati una volta e restano cifrati, finché Veeam non li ripristina.
Questo è il gold standard. Tutto il resto è un compromesso sulla sicurezza. Per questo la crittografia end‑to‑end è richiesta da varie normative, enti di vigilanza e contratti assicurativi.
Definire la crittografia end‑to‑end


In un modello di crittografia end‑to‑end, la crittografia avviene immediatamente alla sorgente. Veeam legge i dati di produzione, genera una chiave di sessione univoca per l’esecuzione di quel backup e cifra i dati sul proxy sorgente. Quella chiave non viene mai condivisa con reti, dispositivi di storage, Object First o chiunque altro nella catena. Se qualcuno intercetta i dati, ottiene solo testo cifrato.
Questo è anche il motivo per cui le appliance di deduplica faticano con la crittografia end‑to‑end. Richiedono dati non cifrati per eseguire il pattern matching. Ma nel momento in cui consentite che dati in chiaro escano dal sistema di produzione sorgente, avete rotto il modello di sicurezza. Avete creato finestra(e) in cui gli attaccanti possono vedere o manipolare i vostri dati. Per questo la deduplica è il più plateale violatore dei principi end‑to‑end: vi obbliga a presumere che non accada nulla di male durante quegli stati non cifrati.
Non è un modello di fiducia su cui oggi qualcuno dovrebbe fare affidamento.
Perché la crittografia end‑to‑end è essenziale per backup resilienti al ransomware
La progettazione resiliente al ransomware consiste nell’eliminare i punti deboli. Qualsiasi momento in cui i dati sono in chiaro o modificabili è un momento che un attaccante può sfruttare. Se cifrate qui, decifrate là, e ricifrate altrove, fate affidamento su un mosaico di protezioni e assunzioni. Esistono sfide simili anche se consentite dati modificabili. State creando un sistema complesso con molteplici punti di guasto. State anche creando più chiavi da gestire, più stati da tracciare e più opportunità di errata configurazione e complessità durante il ripristino.
Quando i dati sono cifrati end‑to‑end, il modello di sicurezza diventa drasticamente più semplice. Se qualcuno intercetta i dati in qualunque punto, vede solo oggetti cifrati. Se qualcuno compromette le credenziali dello storage o del bucket, può leggere il bucket—ma tutto ciò che vedrà sarà sempre e solo dato cifrato. Se qualcuno viola un server intermedio o un gateway, non può comunque decifrare nulla. La crittografia non smette mai di proteggervi.
È la stessa logica alla base del nostro principio di Immutabilità immediata. Volete che i dati siano immutabili nel momento in cui arrivano sullo storage e che siano cifrati nel momento in cui lasciano la produzione. Ogni gap tra questi due stati amplia le superfici di rischio. La crittografia end‑to‑end riduce quella superficie.
Come funziona la crittografia end‑to‑end tra Veeam e Object First
Il ciclo di vita inizia abilitando la crittografia del job in Veeam. È la funzionalità che attiva la crittografia end‑to‑end. Quando un job di backup parte, Veeam genera una nuova chiave di sessione—univoca per quell’esecuzione—e cifra i dati mentre li legge. Anche se eseguite il backup degli stessi identici dati un’altra volta, l’output cifrato apparirà completamente diverso perché viene cifrato con una chiave differente. Questo modello di chiavi a rotazione, non riutilizzabili, è importante perché impedisce l’analisi dei pattern e rafforza la crittografia. Se continuaste a cifrare gli stessi dati con la stessa chiave, gli attaccanti potrebbero iniziare a fare pattern matching. La rotazione delle chiavi lo impedisce.
Una volta cifrati, i dati attraversano l’infrastruttura Veeam—proxy, gateway, reti—e alla fine arrivano nel repository di backup. In nessun punto qualcuno diverso da Veeam possiede la chiave. I dispositivi Storage non ce l’hanno. La rete non ce l’ha. I proxy non ce l’hanno. Se qualcuno intercetta i dati, ottiene solo testo cifrato.
Quando gli oggetti arrivano in Object First (o in Veeam Data Cloud Vault), li memorizziamo esattamente come li riceviamo. Non sappiamo se siano cifrati o in chiaro, e non ci serve saperlo. Non ci aiuta vedere dati in chiaro e non ci danneggia archiviare dati cifrati.
L’integrità viene preservata attraverso più livelli. Veeam, prima della crittografia, comprime le singole istanze e incorpora checksum e metadati in ogni oggetto, così se qualcosa viene manomesso, Veeam lo sa immediatamente. In questo modo Veeam crea una catena di custodia dei dati di backup e delle copie. Eseguiamo anche controlli e scansioni di integrità nostri. E poiché i dati sono immutabili, gli attaccanti non possono modificarli o eliminarli anche se ottengono le credenziali di storage.
Durante il ripristino, il nostro ruolo è intenzionalmente minimo. Non reidratiamo, non decifriamo e non trasformiamo nulla. Restituiamo semplicemente l’oggetto. Veeam gestisce decifratura, decompressione e reidratazione. Questa separazione mantiene pulito il perimetro di crittografia e rispecchia il modello ZTDR di separazione del software di backup dallo storage di backup.
Questo modello si estende in modo pulito anche alla regola 3‑2‑1 Backup. Quando Veeam copia i dati dal backup primario verso un tier di capacità o di archiviazione SOBR oppure tramite un copy job, i dati restano cifrati con la chiave di sessione originale. Non vengono mai decifrati e ricifrati lungo il percorso. Questo è il vantaggio di farlo correttamente fin dall’inizio.
Crittografia e Immutabilità Assoluta: ridurre il blast radius del ransomware
La crittografia e l’Immutabilità Assoluta sono componenti strettamente interconnesse di Resilienza dei dati e della sicurezza. Si rafforzano a vicenda in un modo che cambia radicalmente ciò che un attaccante può e non può fare all’interno del vostro ambiente di backup.
La crittografia end‑to‑end garantisce che ogni componente tra la produzione e lo storage di backup veda sempre e solo dati cifrati. Anche se qualcuno li intercetta o ottiene accesso al bucket, ottiene solo testo cifrato. E poiché Veeam ruota le chiavi per ogni sessione di backup, anche dati identici non appaiono mai uguali due volte. Non c’è alcun pattern da analizzare, nessun appiglio per fare reverse engineering.
L’Immutabilità Assoluta interviene dove la crittografia si ferma. In Object First, l’immutabilità è istantanea nel momento in cui l’oggetto viene scritto, grazie a S3 Object Lock. Una volta impostata la retention, nessuno—nemmeno un amministratore—può modificare o eliminare l’oggetto.
La crittografia impedisce agli attaccanti di comprendere i dati; l’Immutabilità Assoluta impedisce loro di alterarli o distruggerli. Una protegge la riservatezza; l’altra protegge l’integrità e impone una catena di custodia. Insieme, chiudono le due vie su cui gli attori ransomware fanno maggior affidamento: corruzione dei dati ed esfiltrazione dei dati.
Questa combinazione è particolarmente importante in un approccio Assume Breach. Dovete presumere che qualcuno o qualche software malevolo otterrà credenziali elevate. Dovete presumere che il bucket verrà letto. Dovete presumere che le difese falliranno—per questo entrambi i livelli sono necessari. Se un attaccante compromette le credenziali di storage, l’Immutabilità Assoluta gli impedisce di modificare o eliminare i backup. Se prova a usare la compromissione per esfiltrare dati, la crittografia garantisce che non possa usare nulla di ciò che ruba. Capisce rapidamente che è una fatica inutile e sposta l’attenzione su bersagli più facili.
Il risultato pratico è un modello di protezione e sicurezza dei dati semplice ma altamente efficace, che riduce drasticamente il rischio. Anche in uno scenario peggiore—con il server VBR fuori uso, credenziali di storage compromesse e attaccanti con piena visibilità sul vostro storage—potete comunque ricostruire da zero l’intero ambiente software di backup e riprendere le operazioni. La crittografia end‑to‑end garantisce che i dati siano inutilizzabili da chiunque tranne Veeam. L’Immutabilità Assoluta garantisce che i dati siano integri. E poiché Veeam mantiene il perimetro di crittografia e la catena di custodia, il processo di ripristino resta pulito e controllato.
Questa è l’architettura che mantiene le organizzazioni resilienti durante eventi catastrofici. Quando crittografia e immutabilità lavorano insieme, i backup smettono di essere un’ulteriore passività e diventano la parte più sicura e meno complessa del vostro ambiente.
Errate configurazioni e criticità comuni
La maggior parte dei fallimenti non è tecnica—sono decisioni e processi operativi.
L’errore più grande è semplicemente non abilitare la crittografia ovunque. Questo aggiunge il vostro ambiente di backup alla matrice delle minacce di esfiltrazione dei dati. Con Veeam, potete attivare la crittografia per i job di backup e ottenere i benefici della crittografia end‑to‑end; oppure potete configurare la crittografia in più posizioni, repository e dispositivi di storage. In quest’ultimo caso, basta dimenticare o configurare male un passaggio e avete spezzato la catena end‑to‑end.
Un altro problema comune è non separare il software di backup dallo storage di backup. Se gli attaccanti compromettono uno, non dovrebbero compromettere automaticamente anche l’altro. Qui si applicano i principi Zero Trust e ZTDR.
L’errore più catastrofico è gestire male password/chiavi di crittografia per il ripristino. Se perdete le password che inizializzano la crittografia di Veeam, né Veeam né Object First possono aiutarvi. Quelle chiavi devono essere conservate in modo ridondante, fisico e sicuro. È una buona idea condividerle e mantenerle con diversi membri senior del personale e non online. I backup di configurazione cifrati devono essere eseguiti regolarmente. Questo è il costo della crittografia end‑to‑end—non la crittografia in sé, ma la disciplina operativa necessaria per gestirla e per garantire che, in caso di catastrofe, possiate ricreare il vostro ambiente Veeam e fornirgli le password di crittografia iniziali per completare il ripristino della configurazione.
Il futuro dello storage cifrato backup immutabile
Il ransomware si evolve, e così anche la crittografia. La migrazione verso una crittografia sicura post‑quantum è stata avviata da Veeam ed è architetturalmente allineata al report NIST IR 8547 “Transition to Post-quantum cryptographic standards”, e il passaggio alla crittografia post‑quantum continuerà a plasmare il modo in cui i dati di backup vengono protetti.
Guardando avanti, i principi architetturali che contano di più sono gli stessi che contano oggi. Create e mantenete un ambiente sicuro e semplice con quanto segue: principi di Data Resilience Zero Trust, un approccio Assume Breach, separazione del software di backup dallo storage, Immutabilità Assoluta, la regola 3‑2‑1 Backup e test regolari. Sono queste le pratiche che garantiscono di poter recuperare i vostri dati qualunque cosa accada.
La tendenza più ampia è che le organizzazioni devono proteggere tutti i dati, non solo quelli di produzione. I backup sono l’ultima linea di difesa—e sempre più spesso i primi bersagli degli attacchi. La crittografia end‑to‑end, combinata con l’immutabilità, è una componente chiave per restare un passo avanti al ransomware.

