INTRODUZIONE
Le informazioni, ormai sempre più sotto forma di dati digitali, sono una risorsa fondamentale per tutte le aziende, dalle più piccole alle più grandi.
Lo standard ISO/IEC 27001 ci ricorda quali sono i requisiti e le best practice per gestire al meglio la sicurezza di queste informazioni.
I tre principi cardine sono:
- Riservatezza: non tutti possono accedere ad una determinata informazione privata, solo le persone con le giuste autorizzazioni
- Integrità delle informazioni: i dati che l'organizzazione utilizza per svolgere la propria attività o che tiene al sicuro per gli altri devono essere conservati in modo affidabile, assicurando che non vengano cancellati o danneggiati
- Disponibilità dei dati: i dati devono essere sempre disponibili, in modo tale chiunque sia autorizzato possa accedere alle informazioni ogni volta che è necessario
IL RUOLO DI VEEAM
Per proteggere questi dati, software come Veeam Backup & Replication sono indispensabili, perché contribuiscono a perseguire i tre suddetti principi cardine della sicurezza delle informazioni.
Nello specifico, Veeam ci consente di:
- creare dei backup e repliche dei nostri dati, ovvero copie ulteriori delle informazioni originali → aiuta a preservare l’integrità
- tenere i backup protetti da eventuali interventi malevoli, problemi hardware o eventi naturali disastrosi , sfruttando immutabilità, air gapped e offsite copy→ aiuta a tenere il dato sempre disponibile
- salvare i nostri dati attraverso protocolli sicuri e in maniera criptata → aiuta a mantenere la confidenzialità
Tutto questo si traduce nella regola fondamentale di Veeam, la famosa 3-2-1-1-0.
A questa regola, appunto, aggiungerei una caratteristica da applicare globalmente: l’encryption.
VEEAM ENCRYPTION – PERCHÈ E COME FUNZIONA
Così come l’encryption sul dato originale, l’encryption dei backup non è una pratica sempre utilizzata, a volte per motivi di “compatibilità” con le appliance di deduplica, altre volte perché ci si dimentica o non la si ritiene così necessaria.
A mio avviso, invece, è uno dei punti chiave per garantire la confidenzialità delle informazioni.
Sia se salviamo i backup su un cloud esterno, che all’interno del nostro datacenter, è indispensabile garantire che chiunque abbia accesso a questi dati non riesca a leggerli se non autorizzato.
L’esfiltrazione dei dati è una cosa che può impattare anche i nostri backup, e se non sono criptati qualunque istanza di VBR può leggerli.
Veeam garantisce sia l’encryption in transit, cioè durante la copia del dato originale verso il repository designato, che l’encryption at rest, cioè applicata al backup stesso.
La traffic encryption è basata su TLS (dall’ultima versione di Veeam v12.1 è supportato anche TLS 1.3).
L’encryption dei file di backup, invece, è basata sulle librerie Veeam Cryptographic Module and Microsoft Crypto API, che sono entrambi FIPS compliant.
Per criptare i dati, si utilizza un algoritmo di encryption single-key, ovvero una chiave unica per criptare e decriptare, sfruttando lo standard AES-256.
Senza andare troppo nel dettaglio di Cipher, KEX e quant’altro, quello che vorrei descrivere sono lo schema gerarchico e il workflow dell’encryption in Veeam:
Partendo dal basso, troviamo:
- session key: utilizzata sui data block di backup, cambia ad ogni sessione di backup
- metakey: utilizzata per criptare i metadati dei backup; come la session key, cambia ad ogni sessione di backup
- storage key: le due precedenti chiavi sono a loro volta crittografate dalla storage key, la quale viene utilizzata a livello di restore point; quando una catena di backup, infatti, subisce una trasformazione e alcuni backup data block vengono riscritti all’interno di un full (ad esempio durante operazioni di syntetic full, reverse incremental, forever forward incremental..), un singolo restore point conterrà più session keys. La singola storage key è in grado di agire sul singolo restore point. Essa viene mantenuta nel config db fino a scadenza della retention del restore point associato
- user key: quando il Veeam administrator crea una encryption password, e successivamente attiva l’encryption su un job di backup, questa password viene utilizzata per generare la user key. Questa chiave, che agisce appunto a livello di job, viene utilizzata per criptare le storage keys che saranno generate per ogni singolo restore point all’interno della catena di questo job
- backup server keys: coppia di chiavi opzionale, generata quando si aggancia un backup server al VBEM; secondo l’algoritmo asimmetrico RSA, la chiave pubblica viene passata al VBEM, mentre la chiave privata viene mantenuta nel db del VBR. La coppia di chiavi sarà utilizzata per identificare in maniera sicura il backup server durante l’eventuale richiesta di decriptazione verso l’Enterprise Manager, secondo la funzionalità di “password loss protection”
- enterprise manager keys: coppia di chiavi opzionale, generata quando si aggancia un backup server al VBEM; secondo l’algoritmo asimmetrico RSA, la chiave pubblica viene passata al backup server, ed è utilizzata per criptare le session keys allo stesso modo della user key; la chiave privata viene mantenuta nel db del VBEM ed utilizzata in caso di decriptazione, secondo la funzionalità di “password loss protection”
Durante un job di backup quindi, insieme ai data block criptati vengono salvati i crittogrami delle session key, metakey, storage key (una criptata con la user key e una con la EM public key), user key e EM public key, che serviranno poi per identificare le corrispondenti chiavi in fase di restore.
PASSWORD LOSS PROTECTION
Come anticipato in precedenza, esiste una funzionalità di Veeam Enterprise Manager che consente una seconda chance di decriptare i backup nel caso in cui nel nostro backup server non sia più presente la password, magari perché si tratta di vecchi backup che erano stati rimossi dalla configurazione.
Prerequisiti
- VUL o licenze socket di tipo almeno Enterprise
- EM e backup server originali connessi
Dalla Veeam 12.1, la funzionalità di password loss protection supporta anche l’integrazione con KMS.
La coppia di chiavi creata dall’EM è detta keyset. È possibile creare nuovi keyset, esportarli o importarli.
È possibile settare la generazione automatica di nuovi keyset, e il retention period degli stessi.
Il processo di restore senza password si compone dei seguenti passaggi:
1) il Veeam admin inizia il processo di “encryption key restore” dal backup server
2) questo wizard genera una request che contiene, in maniera crittografata, i riferimenti della storage key e della EM public key utilizzate in fase di backup per criptare quei dati
3) la request viene passata al EM admin
4) EM admin inizia il “password recovery” wizard nell’EM e inserisce la request ricevuta
5) EM trova il corrispondente keyset
6) EM, utilizzando la EM private key, decripta la storage key e la inserisce in un file di risposta
7) EM admin invia questa risposta al Veeam admin
8) il Veeam admin inserisce questa risposta nel wizard di “encryption key restore”, terminando così il processo di decriptazione
Limitazioni: se si perde il backup server, o l’EM, o il keyset dell’EM non si potrà utilizzare la procedura di recovery.
L’unico modo per essere veramente al sicuro quando si utilizza l’encryption è non perdere mai la user password.
Quindi, la regola fondamentale è: SALVARE LA PASSWORD DI ENCRYPTION IN MODO SICURO, magari applicando anche per questo dato la regola d’oro 3-2-1-1-0!
FEATURE REQUEST
Attivare l’encryption è un processo utile, ma anche rischioso se non si seguono i giusti accorgimenti.
Per aziende strutturate, con figure di riferimento interne come DPO e/o CISO, potrebbe essere di aiuto creare una procedura relativa all’attivazione dell’encryption sui dati di backup, documentando le varie attività necessarie anche ai fini di certificazioni e/o policy di compliance.
Pensando a come questo scenario si possa integrare in Veeam Backup & Replication mi vengono in mente alcune possibili funzionalità da introdurre:
1) Creare un nuovo ruolo di tipo “Security” all’interno del VBR, che può essere associato appunto alle figure di riferimento come DPO/CISO. Questo ruolo, che dovrà avere almeno due user associati, potrà essere utilizzato per l’attivazione e la modifica della password di encryption
2)Attivazione e modifica della password dovranno essere soggette a 4-eyes authentication, e potranno essere approvate da un Veeam Administrator o da un Security Role
3) Se le procedure di attivazione/modifica di una password di encryption sono state approvate da un “Security Role”, aggiungerei una spunta verde del tipo “security approval” o “approved by security” ( in maniera simile al check della “password loss protection”). Questo “certifica” che la procedura ha seguito il giusto iter interno, e consente ai backup administrator di valutare se la password di encryption sia stata effettivamente messa al sicuro nel modo corretto
4) integrare questo check nel Security & Compliance Analyzer
5) integrare gli eventi di queste nuove funzionalità nei già presenti log di VBR e negli alert/report di VEEAM ONE
CONCLUSIONE
In questi tempi in cui gli attacchi cyber sono sempre più frequenti, considerare i backup come qualcosa di secondario è un errore da non commettere, devono essere visti più come un’estensione indispensabile dei nostri dati.
Utilizzare le best practice è fortemente consigliato..regola 3-2-1-1-0 con encryption!
RIFERIMENTI
https://helpcenter.veeam.com/docs/backup/vsphere/data_encryption.html?ver=120
https://helpcenter.veeam.com/docs/backup/em/em_manage_keys.html?ver=120
