Un tema a mio avviso ancora troppo sottovalutato è quello della recovery verification: va bene avere il backup dei nostri dati, ma siamo sicuri che quel backup sia valido e funzionante quando dovremo utilizzarlo?
Se non viene effettuato nessun test, potremmo andare incontro a potenziali problemi latenti di corruzione del dato di backup e all’impossibilità di utilizzarlo in caso di necessità.
Molte aziende, per motivi di compliance sono tenute ad effettuare dei test di restore periodicamente.
Tante altre, però, non hanno sempre la stessa attenzione.
Mentre prima dell’avvento dei ransomware la regola era “avere un backup, possibilmente in uno storage diverso da quello di produzione”, al giorno d’oggi una solida strategia di data protection non può prescindere dalle best practices indicate nella Golden Rule 3-2-1-1-0:
Come possiamo vedere, la recoverability del backup è d’obbligo, ed è nostro dovere implementarla!
In questo post scopriremo che configurare i test di verifica utilizzando Veeam Backup & Replication è semplice e veloce, quindi perchè non farlo?
SURE BACKUP
La funzionalità Veeam SureBackup consente di impostare un task, schedulato o manuale, per la verifica della effettiva restorabilità dei nostri dati di backup.
Il job di SureBackup può essere impostato in due diverse modalità:
Full recoverability testing: consente di ripristinare dal backup le VM e di riaccenderle in un ambiente isolato, in modo da poter testare la piena funzionalità delle applicazioni
Backup verification and content scan only: consente di effettuare una integrity check dei file di backup, oltre ad una analisi del contenuto per verificare la presenza di malware o di dati sensibili
Full recoverability testing
Questa modalità si basa essenzialmente su due funzionalità di Veeam: l’instant recovery e il virtual lab.
Grazie alla prima funzionalità, le VM possono essere riaccese nel nostro hypervisor mantenendo i virtual disk e i file di configurazione direttamente nel repository di backup, senza la necessità di doverli preventivamente copiare sullo storage di produzione.
La seconda funzionalità, invece, è quella che si occupa di creare on demand un ambiente virtuale isolato, automatizzando la configurazione nel nostro hypervisor di virtual switch e virtual network dedicati ai test di restore. Ci occuperemo della corretta configurazione del virtual lab in un post successivo.
Un concetto fondamentale in questa modalità è quello degli application group, ovvero un oggetto contenente una o più VM con dipendenze tra loro, in modo da poter testare il ripristino di uno stack applicativo completo (es: database server/application server, domain controller primario/domain contoller secondario, ecc..).
Il nostro Sure Backup job sarà quindi composto da:
1 application group
1 virtual lab.
Un’altra funzionalità importante è sicuramente la customizzazione dei test di verifica: Veeam, infatti, consente di selezionare all’interno dello Sure Backup job diversi tipi di controlli automatici sulle VM, da quelli standard come l’hearthbeat, il ping e su applicazioni/porte predefinite (DNS, Domain Controller, SQL Server, ecc..), fino alla possibilità di lanciare script custom per verificare applicazioni specifiche.
Prerequisiti: Licenza VUL valida, o a socket almeno Enterprise (con la licenza di tipo Standard saranno possibili solo i test manuali).
Nota: è possibile effettuare una recovery verification anche su repliche di VM, utilizzando i job di SureReplica, che si basa sempre i concetti di virtual lab e application group.
Backup verification and content scan only
Scegliendo questa modalità, il virtual lab e l’application group non sono più necessari, in quanto l’obiettivo è solamente quello di verificare la consistenza del dato e di controllare l’eventuale presenza di malware o di dati sensibili di cui si vuole tenere traccia.
Veeam verifica le VM in maniera sequenziale, andando ad utilizzare il motore nativo Veeam Threat Hunter o l’antivirus presente nel mount server per scongiurare la presenza di malware.
In maniera opzionale, è possibile scegliere di utilizzare anche YARA rule totalmente customizzabili per identificare tracce di possibili attività malevole sulle VM oggetto dei controlli o semplicemente di dati sensibili presenti nel server.
CONCLUSIONE
Come abbiamo appena visto, lo SureBackup job ci consente di testare la corretta recovery dei nostri dati di backup in maniera semplice e automatizzata.
Forza, corriamo a tutti configurare questa fantastica funzionalità! 💚
Lo scorso 3 Settembre 2025 è stata rilasciata la tanto attesa Veeam Backup & Replication versione 13 (build 13.0.0.4967), chiamata anche Veeam Software Apppliance.
Si perchè, come anticipato in un precedente articolo, la novità principale di questa release è la disponibilità di una appliance pronta all’uso!
In questo primo rilascio sarà disponibile solo per nuove installazioni. A fine 2025, invece, verrà rilasciata la versione completa Veeam Data Platform 13.0.1, che includerà la tradizionale versione Windows e consentirà gli upgrade dalle precedenti versioni.
Nota: nei prossimi mesi verrà reso disponibile da Veeam un tool per la migrazione da classico VBR Windows a VSA Linux. È possibile registrarsi sin da ora in questa pagina ufficiale per essere poi supportati non appena il tool sarà reso pubblico.
Le novità introdotte sono veramente tantissime, proviamo a descrivere quelle più interessanti.
Veeam Software Appliance (VSA)
Il cuore di questa nuova versione: il software di backup è stato pacchettizzato con un sistema operativo Linux based, con componenti minimi per il suo corretto funzionamento (JeOS), e pre hardenizzato secondo le regole DISA STIG per limitare la superficie di attacco. Anche i servizi core sono stati rivisti in ottica sicurezza, e ridisegnati per lavorare con account di sistema non amministrativi.
Un deploy veramente semplice e veloce, con una gestione minima post installazione, anche grazie ad una console web-based e agli aggiornamenti automatizzati (OS, software e componenti di terze parti).
È scaricabile in formato ISO oppure come OVA per l’installazione su ambienti virtuali.
True Zero Trust & Lockdown Mode
Per impedire modifiche critiche all’infrastruttura di backup, è possibile designare un utente con ruolo di Security Officier che sarà incaricato di approvare le operazioni più sensibili.
È prevista inoltre la possibilità di attivare la modalità lockdown, per prevenire qualsiasi aggiunta non autorizzata di nuovi componenti all’infrastruttura.
All in One
Per ambienti piccoli, come ad esempio le sedi remote, la nuova VSA consente di avere all’interno dell’appliance, non solo OS e software, ma anche ma anche un repository immutabile (VHR).
Ovviamente, sebbene la best practice consigli di tenere separate le due funzionalità, è un pur sempre un’opzione da poter tenere in considerazione in casi specifici.
Veeam Infrastructure Appliance (VIA)
Basata sullo stesso JeOS della VSA, consente di scalare i componenti core dell’infrastruttura di backup in maniera semplice e veloce. In particolare, troviamo tre possibili profili da poter installare:
una appliance general purpose, può ricoprire qualsiasi ruolo nella nostra infrastruttura di backup
una appliance con componenti iSCSI e NVME da utilizzare in caso di backup direct SAN
una appliance di tipo VHR (Veeam Hardened Repository)
Scaricabile dalla sezione “Extensions and other” dei download nel sito ufficiale Veeam.
Veeam LiveOS
Questa ISO è stata resa disponibile per effettuare boot dalla VSA in caso di problemi di accesso, ad esempio se la console web risulta non raggiungibile.
Funzionalità richiesta da molto tempo dalla Community Veeam, consente di installare due nodi VSA in modalita active/passive, e minimizzare RPO/RTO in caso di fail del VBR primario.
L’HA è garantita grazie ad una replica continua del config DB tra i componenti del cluster, supportando anche reti ad alta latenza.
Unica nota dolente: è richiesta la licenza di tipo Premium.
RBAC
La v13 introduce la possibilità di creare dei ruoli Veeam custom, andando a selezionare in maniera molto granulare quali operazioni sono consentite e su quali workload.
Single Sign On (SSO)
L’integrazione con identity provider esterni ora possibile anche per l’accesso alla console di backup garantisce una gestione centralizzata e più sicura dell’autenticazione.
Linux only
Da questa versione è possibile utilizzare solo componenti Linux nella nostra infrastruttura di backup.
Piccole eccezioni nel caso di workload con file system di tipo ReFS o che utilizzano Windows deduplication.
Nutanix AHV
L’appliance per AHV è ora completamente integrata all’interno di VBR, e non necessità di una gestione separata.
Enterprise Application
Ora anche il backup degli application plugin supporta la scrittura diretta su repository di tipo object storage.
La lista delle novità continua..di seguito seguito i link della documentazione ufficiale per continuare l’approfondimento:
Il tema della sicurezza è ormai all’ordine del giorno per noi addetti ai lavori del mondo IT: le notizie di attacchi hacker, data breach, e richieste di riscatto non sono più una novità, ma rappresentano purtroppo la quotidianità.
💡: per rimanere sempre aggiornati sugli ultimi attacchi ransomware nel mondo ed esplorare tanti altri approfondimenti sul tema suggerisco di dare un’occhiata al sito Ransomware Live
In questo scenario, Veeam Data Platform 12.3 ci aiuta a proteggere i nostri dati e a ridurre gli impatti di un cyberattacco.
Andiamo a scoprire quali sono tutte le funzionalità orientate alla sicurezza integrate nel software.
SECURITY FEATURES
L’ultima versione Veeam 12.3 porta con se numerose funzionalità di sicurezza introdotte e migliorate gradualmente in questi anni dall’azienda americana leader nella Data Protection.
Security and Compliance Analyzer
Un tool integrato nella console di VBR analizza alcune configurazioni dei componenti dell’infrastruttura di backup verificando la compliance alle best practice di sicurezza suggerite
Alcuni esempi: disabilitazione di protocolli obsoleti/vulnerabili, presenza di repository hardened/immutabili, regola del 3-2-1, complessità della password di encryption, presenza delle ultime patch disponibili
💡: è possibile schedulare lo scan automatico ed inviarlo via email
Malware detection
Il vero motore della cybersecurity integrata in Veeam 12.3, comprende le seguenti funzionalità:
Supportato per backup di VMWare, Hyper-V, Nutanix e Veeam Agent for Windows, consente di effettuare lo scan degli indici di un file system (previa abilitazione dell’opzione “guest file system indexing” sul job di backup) e di segnalare con un evento specifico nella VBR console eventuali file/estensioni sospette.
Questa funzionalità è gestita dal Veeam Data Analyzer Service, che al termine di ogni backup compara il contenuto dell’indexing con il file “SuspiciousFiles.xml“, dov’è contenuta appunto una lista (customizzabile) dei file e delle estensioni sospette.
💡: per backup server che hanno la navigazione verso internet bloccata anche verso gli indirizzi Veeam, è possibile aggiornare manualmente l’elenco dei file sospetti scaricando il file “SuspiciousFiles.xml” seguendo questa KB
Questo file xml contiene anche un elenco degli IoC (Indicators of Compromise) selezionati dalla matrice sviluppata dal MITRE ATT&CK, ovvero file non malevoli ma che possono indicare la presenza di attività sospette in corso. In questo caso, il Veeam Data Analyzer Service compara il file di indexing degli ultimi due restore point (creati a distanza di almeno 25 ore e massimo 30 giorni), andando a cercare appunto eventuali indicatori di compromissione. È possibile anche qui scegliere quali IoC predefiniti monitorare e quali no.
Altra funzionalità gestita sempre dal Veeam Data Analyzer Service è quella che identifica eventuali cancellazioni multiple di file: comparando il file di indexing degli ultimi due restore point (creati in una finestra temporale di 25 ore e massimo 30 giorni), se sono presenti almeno 100 file di una specifica estensione e nell’ultimo restore point ne risultano eliminati più del 50% del totale viene creato un evento di malware detection. Le estensioni vengono registrate nel file “TrackedFiles.xml”, che può essere customizzato modificando i parametri di “Thresholdpercent” e “Thresholdfiles”, o anche aggiungendo estensioni specifiche o ignorando dei path del file system che non intendiamo monitorare.
Infine, con la stessa logica di comparazione degli indici di due restore point, viene anche identificata la presenza di Multiple Extension Changes; in base al verificarsi di determinate condizioni, questa volta non customizzabili, come almeno 200 file con nuova estensione e non presente nel SuspiciousFiles.xml, scaturisce un evento di malware detection.
💡: i log degli eventi di malware detection, oltre che nella sezione dedicata all’interno della VBR console, possono essere consultati nel percorso di default “C:\ProgramData\Veeam\Backup\Malware_Detection_Logs”
💡: bisogna inoltre considerare che di default i dati di indexing sono mantenuti nel Veeam Catalog per 14 giorni. Se si vuole incrementare questo valore, è possibile utilizzare il Veeam Enterprise Manager, che si occuperà di mantenere una copia extra del Catalog con durata configurabile
Mentre le funzionalità appena descritte si basano sull’analisi post backup a livello di file system, l’inline scan agisce a livello di immagine/blocco durante un backup, individuando la possibile entropia generata da un malware, come file criptati o i cosiddetti artifact, file di testo che possono contenere onion links o ransomware notes.
Tecnicamente, durante ogni sessione di backup sul Veeam Proxy utilizzato vengono generati dei file in formato RIDX (un file per ogni virtual disk processato) contenenti i metadati del disco (disk name, creation time, disk size, used size, sector size, partition table) e i ransomware data (encrypted data, file types, onion addresses, ransomware notes). Al termine del backup, questi file vengono copiati nel VBR Catalog, e scansionati dal solito Veeam Data Analyzer Service, che salverà poi i risultati della sua analisi nel file RansomwareIndexAnalyzeState.xml. Al comparire di un nuovo restore point, il servizio compara il più recente e il più vecchio RIDX file (creati in una finestra temporale di 25 ore e massimo 30 giorni), andando ad aggiornare il file RansomwareIndexAnalyzeState.xml. Se viene individuato qualcosa di sospetto, viene creato un evento di malware detection e l’oggetto, la specifica virtual machine, marcato come suspicious.
💡: per verificare nel dettaglio quali file sono stati identificati come “encrypted data”, utilizzare il procedimento presente in questa KB
💡: la funzionalità di inline scan è disabilitata di default; in caso la si voglia abilitare, è necessario tenere presente che aumenta l’utilizzo di CPU dei proxy e della RAM/Disk space del VBR
Utilizzando questa funzionalità è possibile trovare un restore point pulito (non infetto da malware) o individuare informazioni specifiche, come ad esempio dati sensibili. Al momento è supportato lo scan solo di server Windows (VM o agent) tramite, appunto, un Veeam mount server Windows.
Gli engine utilizzabili per lo scan sono tre:
veeam threat hunter, servizio Veeam automaticamente installato sui mount server e che gira in background. Prima di ogni scan viene effettuato il check per eventuali update delle malware signature. 💡: è possibile impostare una chiave di registry per configurare le exclusion di file e cartelle dallo scan
3rd party av, in alternativa al veeam threat hunter, è possibile utilizzare un antivirus di terze parti installato preventivamente sul mount server; è possibile trovare le informazioni sugli av predefiniti e aggiungerne di custom utilizzando il file “AntivirusInfos.xml” presente nel mount server.
yara rule: utilizzando file con una sintassi ben definita, è possibile ricercare restore point infetti o dati sensibili. Nel primo caso, se non viene trovato un restore point pulito viene generato un evento di malware detection.
Ogni volta che lo scan individua un restore point non pulito, questo viene marcato come infected. Se la sessione di scan trova almeno un restore point pulito, termina in “success”, in caso contrario in “failed”.
💡: è possibile fare il suppress della generazione dell’evento inserendo l’apposito tag “SuppressMalwareDetectionNotification” per una specifica regola all’interno del file yara: <rule SearchFileHash : SuppressMalwareDetectionNotification>
💡: i log completi dello scan si possono trovare nella directory “C:\ProgramData\Veeam\Backup\FLRSessions\Windows\FLR__<machinename>_\Antivirus”del mount server
Secure restore
Questa funzionalità consente di sfruttare gli engine di scan descritti sopra durante un restore.
Nello specifico sono supportati i seguenti scenari:
Instant Recovery
Virtual Disks Restore
Entire VM Restore
Restore to Microsoft Azure
Restore to Amazon EC2
Restore to Google Compute Engine
Disk Export
💡: è possibile schedulare lo scan automatico dei backup tramite lo SureBackup
💡: se avete VRO installato, potete sfruttare al massimo le funzionalità di restore automatizzato in un ambiente clean room
Incident API
Veeam non si limita a sfruttare le proprie funzionalità di malware detection, ma offre anche la possibilità di integrare tool di terze parti.
Grazie all’esposizione di specifiche REST API di Veeam, tool esterni di monitoraggio e analisi riescono ad automatizzare i processi di incident management e incident response fino a coinvolgere anche l’infrastruttura di backup.
Infatti, è possibile lanciare un quick backup automatico a seguito della ricezione di un evento esterno di threat detection.
Syslog integration
All’interno di Veeam è possibile configurare l’inoltro di eventi verso dei syslog esterni, seguendo lo standard RFC 5424.
È possibile escludere l’invio di determinati eventi, inserendoli manualmente nell’interfaccia o tramite file xml.
💡: l’elenco completo degli eventi gestiti da Veeam 12.3 potete trovarlo qui
💡: per configurazioni avanzate fare riferimento a questa KB
Analytics View – Veeam Threat Center
È possibile integrare all’interno della VBR console la vista di alcune dashboard di Veeam ONE, come ad esempio quella di Veeam Threat Center, che racchiude un insieme di informazioni sullo stato globale di security e compliance della nostra infrastruttura di backup.
Recon scanner
Questa funzionalità è una delle ultime arrivate in casa Veeam Data Platform, e si basa sulla tecnologia sviluppata da Coveware, azienda leader nella Cybersecurity Incident Response area acquisita da Veeam nell’aprile 2024.
Consiste nell’installazione di un agent negli ambienti VBR che colleziona continuamente dati al fine di identificare proattivamente possibili attività sospette o l’utilizzo di TTPs.
Ad ogni scansione completa del sistema, l’agent i risultati possono essere visualizzati direttamente nel portale Coveware dedicato.
💡: necessita della versione Veeam Data Platform Premium
External projects: Veeam decoy / Veeam vScan
È doveroso inoltre citare due progetti open source esterni, ma sempre gestiti dalla community di Veeam. Si tratta di Veeam Decoys e Veeam vScan, che ricadono sempre nell’ambito security.
Il primo è un sistema simulamolteplici servizi Veeam e Windows, come i servizi di Veeam Backup Server, Veeam Hardened Repository, Veeam Windows Repository, Veeam Backup Enterprise Manager, ecc. .
Tutti i tentativi di connessione catturati, comprendenti informazioni come porta sorgente, ip sorgente o credenziali utilizzate, posso essere inviati ad un syslog centralizzato o tramite email.
Il secondo consente di effettuare dei vulnerability assessment su dati di backup esistenti, utilizzando i tool open source Trivy e Grype.
CONCLUSIONE
Insomma, come abbiamo visto le funzionalità di sicurezza presenti in Veeam Data Platform 12.3 sono numerose ed utili.
Aspettiamo ora di scoprire le novità delle prossime versioni! 💚
Qualche giorno fa il product management di Veeam ha scelto di condividere in anteprima con gli utenti del forum R&D alcune informazioni utili circa la futura v13, in uscita nel secondo semestre di questo 2025.
Andiamo a vedere nel dettaglio i punti più interessanti.
SYSTEM REQUIREMENTS
Per quanto riguarda i requisiti di sistema degli OS, è importante segnalare che non saranno più supportati sistemi operativi a 32 bit. Inoltre, saranno fuori anche gli OS più vecchi, come Windows Server 2008 e 2012, Debian 10, RHEL 7 e tra i sistemi client Windows 7 e 8, Mac OS 10. Fuori supporto ovviamente anche CentOS, ormai in End of Life.
Verificando gli hypervisor, troviamo anche qui delle importanti novità: per quanto riguarda Vmware, la minima versione supportata di vCenter/Esxi sarà la 7.0, per vCloud Director la 10.4; per Hyper-V andranno fuori supporto le versioni 2012 e 2012 R2, la versione minima supportata sarà la 2016; per Nutanix AHV invece servirà almeno la versione 6.8.
Andiamo ora a controllare le novità per le applicazioni: per quanto riguarda Microsoft, eliminato il supporto per i vecchi Exchange 2013, Sharepoint 2013, SQL server 2008; fuori supporto anche SAP HANA 1.0 .
Paragrafo a parte per i sistemi che fanno parte della infrastruttura di backup: qui i requirements sono ancora più stringenti, per garantire una maggiore sicurezza all’ambiente Veeam. Le minime versioni di OS supportati per l’installazione di Backup Server, Console e Enterprise Manager saranno Windows Server 2016 e Windows 11 22H2. Menzione speciale alla Rocky Linux 9.2 (managed by Veeam), grande futura novità di questa v13. Inoltre, se si sceglie il DB Microsoft SQL, la versione minima dovrà essere SQL Server 2016.
Per quanto riguarda il supporto degli storage primari, sarà eliminato il supporto per alcune famiglie e versioni più legacy, come ad esempio Dell VNX/VNX2/VNXe e Netapp ONTAP 7.
DEPRECATED AND DISCONTINUED FEATURES
Alcune funzionalità non saranno disponibile nelle nuove installazioni v13 e nei nuovi job creati in ambienti provenienti dalla v12. Saranno poi completamente rimosse a partire dalla v14, lasciando a tutti il tempo di adeguarsi a queste modifiche.
Tra quelle più importanti troviamo:
Reversed incremental backup mode
Retention su numero di restore point (sarà disponibile solo la retention time-based)
Non per-machine backup chains (saranno disponibili esclusivamente catene di backup di tipo per-machine)
Active Directory based authentication per i Veeam Cloud Connect tenants.
Ci sono poi alcune funzionalità che saranno eliminate già a partire dalla v13, quindi se presenti non consentirannodi andare avanti conl’upgrade:
Jobs con backup metadata non ancora aggiornati al formato v12
Backup Copy jobs in legacy mode
Installazioni di Veeam Agent for Windows precedenti alla v6
CONCLUSIONE
A mio avviso, questa comunicazione è un’ottima cosa per noi utilizzatori del software, poichè ci consente di conoscere in anticipo questi due aspetti fondamentali per il futuro upgrade.
Come riportato in un precedente articolo, infatti, per pianificare al meglio l’aggiornamento del software è fondamentale verificare la matrice di compatibilità con i vari componenti che fanno parte della nostra infrastruttura.
Inoltre, conoscere le future funzionalità che saranno eliminate dal software ci permette di valutare potenziali criticità e mettere in campo le opportune modifiche prima dell’upgrade.
NB: il supporto alla v12 è stato prolungato di un anno (fino a febbraio 2027), per consentire anche a chi si trova a gestire infrastrutture più legacy di avere il tempo di aggiornare i sistemi necessari a soddisfare la futura matrice di compatibilità.
Come tutti sapete, durante lo scorso VeeamON 2024 è stato annunciata la tanto attesa versione Linux per l’installazione del Veeam Backup Server.
Chi come me ha la fortuna di far parte del programma Veeam100, in questi giorni sta avendo la possibilità di testare la prossima versione Veeam Data Platform v13.
Ovviamente si tratta di una Technical Preview, quindi la futura versione ufficiale, che sarà GA nel Q2 2025, potrebbe variare un pò per quando riguarda la user experience e le funzionalità implementate.
Bene, iniziamo a svelare qualche dettaglio!
Innanzitutto, la TP si presenta come un OVA installabile sul nostro hypervisor (ad esempio VMWare).
Secondo le informazioni attuali, in futuro dovrebbero esserci tre opzioni per l’installazione del software (Rocky) Linux-based:
Virtual Appliance (OVA/OVF)
Bootable ISO
Linux installation (rpm)
Le prime due opzioni sono ovviamente le più consigliate, perchè includono anche il sistema operativo e sono ottimizzate nonchè compliant con gli standard DISA-STIG e FIPS. Una volta installato l’OVA, l’accesso sarà consentito solo con utenza non root.
Altra informazione, seguendo i principi di zero trust, anche i servizi del software sono associati ad account non privilegiati.
Per quanto riguarda la console, la grande novità riguarda la nuova colorata interfaccia web integrata nell’installazione Linux, che inizialmente andrà ad affiancare la classica VBR console.
Questa console molto probabilmente non avrà sin da subito tutte le funzionalità della console installata su Windows, ma è comunque un buon punto di partenza per andare a sostituire completamente la “sorella legacy”.
Una opzione secondo me molto interessante introdotta in questa nuova console, è la possibilità di gestire gli update del software in una sezione dedicata, il Veeam Updater.
Molto simile a quanto già accade nelle appliance dedicate al backup dei Public Cloud (Veeam for Azure/AWS/GCP), questa sezione consente l’aggiornamento personalizzato dei componenti, nonchè un settaggio per forzare l’appicazione automatica dei security update entro un certo numero di giorni dalla loro disponibilità.
Passiamo ora all’anteprima della VBR console Windows.
Possiamo notare una grafica più light e accattivante, con possibilità di attivare anche il tema dark mode.
Dal punto di vista delle nuove funzionalità, da segnalare la probabile introduzione di SAML authentication per l’integrazione con provider esterni e del ruolo Veeam Security Officer (ad oggi Veeam Security Administrator) per la gestione delle operazioni più sensibili.
Per il momento ci fermiamo qui, in attesa della versione beta e ovviamente della GA! 💚
Al giorno d’oggi , purtroppo, gli attacchi ransowmare sono in continua crescita, e difendersi è una sfida sempre più complessa.
Se prima i backup venivano considerati come un qualcosa di poco importante, magari utili solo in caso di eventuali danni agli storage, oggi sono diventati l’ultima frontiera per mettere in salvo i nostri dati.
Per questo motivo, uno dei principali obiettivi durante un cyber attacco è proprio l’infrastruttura di backup: se i threath actor riescono a metterla fuori gioco, la strada verso il pagamento di un riscatto sarà tutta in discesa.
Le notizie di collaborazioni e integrazioni di prodotti tra i grandi vendor di data protection e quelli di security sono ormai all’ordine del giorno, in ultimo quella tra Veeam e Palo Alto Network Cortex XSIAM/XSOAR.
Tutto questo ci fa capire quanto sia importante focalizzarsi sulla sicurezza di tutti i sistemi, comprese le infrastrutture di backup.
Una delle tante best practice consigliate da Veeam, ad esempio, è quella di cercare di rendere quanto più possibile anonimi i suoi componenti.
Assegnare ai server e ai repository di backup un nome non riconducibile al loro ruolo può essere un primo tentativo per evitare di rendere proprio tutto così facile ad eventuali malintenzionati.
Un altro metodo per cercare di identificare e magari di rallentare un attacco in corso consiste nell’utilizzo degli honeypot: trappole, esche utilizzate per attirare i threat actor e farli uscire allo scoperto.
L’honeypot è un componente che simula il sistema di produzione, magari con le stesse applicazioni, ma con dati non reali.
Nel caso di Veeam Data Platform, l’idea potrebbe essere quella di creare un VBR server aggiuntivo che funge da esca, magari con tanto di backup funzionanti.
Ovviamente questo potrebbe richiedere un effort non indifferente, perchè si dovrebbero utilizzare dei sistemi sacrificabili e non di produzione, con il solo scopo di attirare i malintenzionati e far si che i nostri software di anomaly detection rilevino i tentativi di instrusione o manomissione dell’honeypot.
Questo sistema simula molteplici servizi Veeam e Windows, come i servizi di Veeam Backup Server, Veeam Hardened Repository, Veeam Windows Repository, Veeam Backup Enterprise Manager, SSH, RDP, Netbios.
Supporta l’utilizzo di più schede di rete, per cui ogni servizio può essere a una determinata VLAN, in modo da essere pronto a scenari realistici di attacco con utilizzo di tattiche di lateral movement (TA0008).
Il sistema non riceve alcun traffico in ingresso, per cui ogni connessione riconducibile all’utilizzo di tattiche di discovery (TA0007) dovrebbe rappresentare un tentativo di intrusione.
Questo tool è scaricabile come appliance OVA (compatibile solo con vSphere 8.0) oppure installabile su una Rocky Linux minimal.
La console si presenta con una interfaccia molto semplice ma al tempo stesso completa, dove possiamo gestire lo stato dei servizi di decoy, le interfacce di rete associate e visualizzare in tempo reale porte in uso e log delle connessioni su ogni specifico servizio.
Tutti i tentativi di connessione catturati, comprendenti informazioni come porta sorgente, ip sorgente o credenziali utilizzate, posso essere inviati ad un syslog centralizzato o tramite email, in modo tale da attivare un alerting che può essere prontamente gestito da un SOC.
Certo, non ci aspettiamo che sia la nostra arma più efficace contro i cyber attacchi, ma in questa lotta tra i due mondi è pur sempre un’opzione in più! 💚
Quando parliamo di repository di backup in Veeam, non possiamo fare a meno di menzionare gli object storage, tecnologia che sta prendendo sempre più piede negli ultimi anni.
Dalla versione 12 di Veeam B&R, infatti, è possibile scrivere direttamente un backup su questo tipo di repository.
Dalla versione 12.1, inoltre, è possibile fare il backup dei dati presenti su un object storage.
A differenza di architetture storage di tipo file system, che gestiscono i dati in maniera gerarchica all’interno di directory, l’architettura dello storage ad oggetti è piatta, ed è disegnata per memorizzare dati non strutturati, come ad esempio i backup.
Nello specifico, i dati vengono suddivisi in blocchi a cui vengono associati dei metadati e degli identificativi univoci, utilizzati dal sistema in caso di accesso.
Tra i principali vantaggi, può contenere grandi quantità di dati ad un costo non eccessivo, è facilmente scalabile ed è compatibile con protocolli HTTP/HTTPS e REST API.
Wasabi è uno degli object storage di tipo cloud based, e possiamo quindi paragonarlo ai più conosciuti S3 di AWS o ad Azure Blob Storage di Microsoft.
A differenza dei grandi vendor sopra citati, il prezzo/TB è di molto inferiore, e non ci sono costi per il traffico di ingress/egress o per le chiamate API.
Wasabi è presente nella directory di compatibilità Veeam Ready come backup target di tipo object storage (S3 compatibile), e con il supporto nativo della funzionalità di immutability (object lock).
La prima cosa da fare per utilizzare Wasabi per i nostri backup Veeam è creare uno storage account registrandosi alla trial gratuita di 30 giorni; successivamente è possibile continuare ad utilizzare l’account in modalità Pay As You Go o Reserved Capacity Storage.
Una volta registrati ed acceduti alla dashboard, generare una nuova coppia di access key/secret key , e creare il bucket che ospiterà i nostri backup Veeam:
Ora possiamo andare nella nostra console di Veeam B&R, e dal menu principale cliccare su “Add Repository”, selezionando poi “Object Storage” e “Wasabi Cloud Storage”:
Appena inizia il wizard, inserire il nome che vogliamo dare su Veeam al nostro repository Wasabi:
Successivamente, inserire i dettagli dello storage account e della region sulla quale abbiamo creato il nostro bucket:
A questo punto, inserire i dettagli del bucket e della folder da utilizzare per i nostri backup:
NB: per questo tutorial in ambiente di laboratorio non è stato attivato il flag di immutability, ma per ambienti di produzione è sempre consigliato utilizzarlo
Infine, specificare il mount server e completare il wizard:
Ecco qua il nostro repository Wasabi da utilizzare per i nostri job di backup!
Questo aggiornamento viene incontro soprattutto a quei clienti che per esigenze di utilizzo devono mantenere la compatibilità con vecchi hypervisor (ad esempio VMware vSphere/Esxi 5.5).
La patch contiene alcune fix del prodotto, ed anche qualche correzione di sicurezza di componenti di terze parti presenti nel software, come ad esempio VDDK, OpenSSL, liblz4, zlib e Putty:
Nota importante: se decidete di installare questa patch, non potrete più passare alla V12.1, ma dovrete attendere l’uscita del prossimo minor update V12.2 (previsto nella seconda metà del 2024).
Per cui, se siete alla V11 e non avete problemi di compatibilità con il resto dell’infrastruttura, il consiglio è di passare all’ultima versione V12.1, sfruttando subito le tante funzionalità aggiuntive.
Di seguito un ultimo link che può risultare utile durante la pianificazione degli aggiornamenti, quello dell’upgrade-path di Veeam B&R.
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!
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!
