Archivi categoria: Microsoft Azure

Come crittografare una VM su Azure utilizzando Key Vault e lo standard BitLocker

Microsoft Azure mette a disposizione nuovi strumenti per la sicurezza dei nostri dati. Utilizzando pochi comandi PowerShell e concetti base su Key Vault in questo articolo vedremo come crittografare il disco di una VM con lo standard BitLocker.

Prerequisiti:

  • Azure PowerShell
  • Configurazione di un Key Vault

Per soddisfare i prerequisiti potete consultare il precedente articolo https://www.ictpower.it/guide/configurare-microsoft-azure-keyvault.htm

Configurare la VM

Creiamo una nuova VM associata al resource group NewResourceGroup, che avevamo creato nel precedente articolo, utilizzando Resource Manager come modello di deployment.

Figura 1: Scelta del deployment model

Figura 2: parametri per la creazione della nuova VM

Assicuriamoci che tutte le configurazioni siano relative al resource group corretto, cioè quello dentro il quale abbiamo abilitato Key Vault.

Al termine della creazione della VM, cliccando su Disks è possibile constatare che il disco non è crittografato.

Figura 3: Verifica che il disco creato non è crittografato

Scarichiamo dal repository GitHub ufficiale di Azure lo script denominato Azure Disk Encryption Prerequisite Setup, che si occuperà di soddisfare i prerequisiti necessari.

Utilizzando PowerShell ISE, configuriamo il contesto nel quale lo script verrà eseguito con i comandi:

Login-AzureRmAccount

Set-AzureRmContext -SubscriptionId <SubscriptionID>

Eseguiamo lo script:

Figura 4: Esecuzione dello script che verifica i prerequisiti per Azure Disk Encryption

Durante l’esecuzione, lo script chiederà alcune informazioni:

  • Il resource group da utilizzare
  • Il nome di una chiave; se non presente sarà creata automaticamente
  • L’area geografica
  • Il nome di un’applicazione: questa verrà usata per scrivere il segreto nel Key Vault; se non presente, verrà anch’essa creata automaticamente.

Figura 5: Inserimento dei parametri nello script di verifica

Crittografare la VM

Per crittografare la VM è necessario alcuni comandi PowerShell. Dichiariamo qual è il resource group da utilizzare e il nome della VM interessata utilizzando i comandi:

$resourceGroupName ‘NewResourceGroup’

$vmName ‘VMtestKV’

Dopo aver configurato il contesto corretto, possiamo utilizzare il seguente comando per eseguire l’azione di crittografia:

Set-AzureRmVMDiskEncryptionExtension -ResourceGroupName $resourceGroupName -VMName $vmName -AadClientID $aadClientID -AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $keyVaultResourceId -VolumeType All

Confermiamo per concludere l’operazione:

Figura 6: richiesta di conferma prima dell’abilitazione della crittografia del disco

Al termine dell’esecuzione, lo script ritorna il seguente output:

Figura 7: Crittografia del disco completata

Verificando nuovamente nei dettagli della macchina potremo constatare che l’operazione è avvenuta correttamente.

Figura 8: Il disco della VM risulta crittografato

Conclusioni

Azure fornisce diverse soluzioni in ambito crittografico e quella descritta in questo articolo è particolarmente utile soprattutto se il monitoraggio delle macchine viene effettuato tramite Azure Security Center. Inoltre, con pochi click è possibile applicare la stessa procedura agli storage account in merito a files e blob, rispettando lo standard BitLocker e aumentando la sicurezza delle nostre infrastrutture su cloud.

Creare una connessione Site-to-Site in Microsoft Azure

Microsoft Azure è la soluzione di cloud pubblico che permette di poter eseguire facilmente gran parte dei workload aziendali utilizzando le risorse hardware messe a disposizione online. Io sono dell’idea che un cloud ibrido, in cui alcuni workload sono online ed altri sono on-premises possa essere la soluzione più interessante per le aziende italiane.

In questo articolo voglio mostrarvi come connettere la rete aziendale on-premises con la rete virtuale di Azure (VNET), in modo tale che il cloud sia una naturale estensione della nostra infrastruttura. Per poterlo fare verrà creato un tunnel VPN IPsec/IKE (IKEv1 o IKEv2) tra due dispositivi: il primo dispositivo si troverà nella nostra infrastruttura (Local Network Gateway) e sarà raggiungibile dal cloud tramite un secondo dispositivo creato su Azure (Virtual Network Gateway).

Prerequisiti

Per poter realizzare una connessione Site-to-Site tra la vostra sede aziendale e Microsoft Azure è necessario che vengano rispettati alcuni prerequisiti:

  • Avere a disposizione in azienda un dispositivo VPN compatibile
  • Un indirizzo IP IPv4 pubblico esterno per il dispositivo VPN. L’indirizzo IP non può trovarsi dietro NAT

Figura 1: Schema di funzionamento di una connessione Site-to-Site

Configurazione della connessione

Per prima cosa è necessario avere una Virtual Network (VNET) all’interno della propria sottoscrizione Azure. Alla VNET verranno collegate tutte le macchine virtuali e i servizi che volete ospitare nel cloud. Scegliete di creare una nuova Virtual Network e indicate i parametri relativi al nome della rete, allo spazio di indirizzi da utilizzare e alle sottoreti ed ovviamente alla Regione di Azure dove volete crearla, come mostrato in figura:

Figura 2: Creazione della VNET

Figura 3: VNET creata – Visualizzazione Subnet

Una volta che è stata creata la VNET sarà necessario creare una subnet per il Gateway. In genere è sufficiente utilizzare una sottorete /27 o /28. Per poterlo fare vi basterà selezionare la VNET creata e scegliere il comando per aggiungere la Gateway Subnet. Il Nome per la subnet verrà compilato automaticamente con il valore ‘GatewaySubnet’. Questo valore è obbligatorio per consentire ad Azure di riconoscere la subnet come GatewaySubnet, quindi non modificatelo.

Figura 4: Aggiunta della Gateway Subnet

A questo punto siete pronti per la creazione del Gateway, che farà da Endpoint per la connessione VPN. Si tratta di due macchine virtuali messe in alta disponibilità e create da Microsoft che assicureranno la connessione con il dispositivo VPN che avere in casa.

Cliccate su Nuovo (+) à Networking à Virtual Network Gateway ed inserite i dati richiesti: nome, tipo di Gateway, SKU, Virtual Network a cui associarlo e indirizzo IP pubblico, come mostrato in figura:

Figura 5: Creazione del Virtual Network Gateway

Quando si crea il Virtual Network Gateway è necessario specificare un tipo di VPN. Il tipo di VPN scelto dipende dal tipo di connessione che si desidera creare. Ad esempio, una connessione Point-to-Site (P2S) richiede obbligatoriamente un tipo di VPN RouteBased. Dopo avere creato un gateway non è possibile modificare il tipo di VPN. È necessario eliminare il gateway e ricrearne uno nuovo. Lo SKU del Gateway VPN stabilisce il numero massimo di connessioni e la velocità effettiva aggregata. Attualmente sono disponibili le seguenti configurazioni:

SKU

Tunnel S2S/
rete virtuale-rete virtuale

Connessioni
P2S

Velocità effettiva
aggregata

VpnGw1

Max. 30

Max. 128

500 Mbps

VpnGw2

Max. 30

Max. 128

1 Gbps

VpnGw3

Max. 30

Max. 128

1,25 Gbps

Basic

Max. 10

Max. 128

100 Mbps

Per maggiori informazioni potete visitare la pagina https://docs.microsoft.com/it-it/azure/vpn-gateway/vpn-gateway-about-vpn-gateway-settings#gwsku

La creazione del gateway può richiedere fino a 45 minuti. Nell’attesa potete procedere alla creazione del Local Network Gateway, che rappresenta il dispositivo VPN che avete in azienda e che volete usare per la connessione Site-to-Site. Per crearlo è sufficiente cliccare su Nuovo (+) à Networking à Local network gateway e compilare i campi indicando la rete (o le reti) presente in azienda e l’indirizzo IP pubblico del dispositivo VPN aziendale, come mostrato in figura:

Figura 6: Creazione del Local Network Gateway

Dopo aver atteso il completamento della creazione del Virtual Network Gateway, siamo pronti per creare la connessione Site-to-Site. Selezionate il Gateway e nel tab Settings cliccate su Connections, come mostrato in figura:

Figura 7: Scheda Connections del gateway VPN appena creato

Cliccando su Add avrete la possibilità di scegliere il Tipo di connessione, il Local Network Gateway e la Pre-Shared Key (PSK) necessaria a configurare la connessione IPSEC/IKE, come mostrato in figura:

Figura 8: Configurazione della connessione Site-To-Site

A questo punto il Gateway avrà lo Status Connecting fino a quando non avrete configurato il dispositivo in azienda.

Figura 9: Creazione VPN Site-to-Site completata

Configurazione del dispositivo VPN aziendale

Maggiori informazioni su come configurare i dispositivi VPN e sui parametri IPsec/IKE per le connessioni del Gateway VPN possono essere visualizzate alla pagina https://docs.microsoft.com/it-it/azure/vpn-gateway/vpn-gateway-about-vpn-devices . Microsoft ha predisposto un elenco dei dispositivi VPN dei maggiori vendor con relativa configurazione.

Personalmente nei miei laboratori utilizzo come endpoint Microsoft RRAS installato su Windows Server 2012 R2. È possibile configurarlo manualmente per la connessione IKEv2 oppure potete trovare uno script di configurazione al link https://github.com/Azure/Azure-vpn-config-samples/tree/master/Microsoft

Conclusioni

La connessione VPN Site-to-Site ci permette di poterci collegare alle VNET create in Microsoft Azure ed utilizzare il cloud come estensione delle nostre reti aziendali, dandoci di fatto l’opportunità di accedere alle notevoli risorse di calcolo offerte, come se fossero disponibili in azienda.

Abilitare la nested virtualization con le nuove Azure VM Dv3 ed Ev3

Sono disponibili solo da un paio di giorni (e non in tutte le Regioni di Azure) le nuove macchine virtuali della Serie Dv3 ed Ev3. Queste macchine virtuali sono le prime ad essere ospitate su host Hyper-V basati su Windows Server 2016 e sono le prime che usano la tecnologia Hyper-Threading.

L’utilizzo dell’Hyper-Threading permetterà di creare macchine virtuali con più core e quindi migliorerà le performance e l’efficienza delle VM. I processori utilizzati sono Intel® Broadwell E5-2673 v4 2.3GHz e Intel® Haswell 2.4 GHz E5-2673 v3.

Grazie all’host Windows Server 2016 è adesso possibile abilitare la Nested Virtualization, che permette di poter eseguire il ruolo di Hyper-V anche in una macchina virtuale e di farci girare macchine virtuali annidate oppure Hyper-V Containers. Per maggiori informazioni su cosa sia la virtualizzazione annidata e come abilitarla in Windows Server 2016 vi rimando alla lettura dell’articolo https://docs.microsoft.com/it-it/virtualization/hyper-v-on-windows/user-guide/nested-virtualization

Alla pagina https://azure.microsoft.com/it-it/blog/introducing-the-new-dv3-and-ev3-vm-sizes/ potrete trovare un elenco dettagliato delle nuove VM disponibili, dei tagli previsti e delle Regioni dove attualmente sono abilitate.

Creazione di una nuova VM di tipo Ev3 su Azure

Per poter sfruttare la Nested Virtualization è necessario creare una macchina virtuale di tipo Dv3 oppure Ev3 in una delle regioni abilitate. Io ho deciso di utilizzare una macchina E4s_v3 e l’ho creata in West Europe, scegliendo come sistema operativo Windows Server 2016.

Figura 1: Creazione della VM in West Europe

Figura 2: Scelta della dimensione della VM

Figura 3: Configurazione dello storage, della rete e dell’IP pubblico della VM

Figura 4: Schermata riassuntiva con le scelte selezionate

Al termine della creazione della VM potete collegarvi in desktop remoto per configurarla. Dal Server Manager aggiungete il ruolo di Hyper-V e vedrete che non riceverete nessun messaggio di errore, come mostrato in figura:

Figura 5: Abilitazione del ruolo Hyper-V nella nested VM in Azure

Abilitazione della Nested Virtualization

Per semplificare l’abilitazione e la creazione di macchine virtuali annidate, potete scaricare uno script in PowerShell realizzato da Charles Ding, ingegnere del gruppo di sviluppo Microsoft Azure, all’indirizzo https://aka.ms/azurenestedvirtualization. Lo script vi permetterà di configurare il ruolo di Hyper-V e tutte le altre caratteristiche necessarie alla creazione della Nested VM.

Eseguite lo script in PowerShell ISE (lanciato con privilegi elevati) e la prima volta lo script provvederà ad installare il ruolo di Hyper-V, come mostrato in figura:

Figura 6: Esecuzione dello script che installa Hyper-V e che crea la VM annidata

L’installazione di Hyper-V richiede un paio di riavvii, quindi verrete disconnessi dal desktop remoto. Dopo qualche minuto, potrete ricollegarvi e rilanciare lo script per creare la VM. Modificate il valore $VMName “NestedVM-Level2” scegliendo il nome che volete assegnare alla vostra Nested VM e rilanciate lo script. Lo script verificherà che i prerequisiti sia tutti rispettati e creerà la macchina virtuale, abilitando tutte le estensioni necessarie alla virtualizzazione annidata, come mostrato in figura:

Figura 7: Lo script ha creato la VM annidata

Dopo aver avviato la VM annidata, nel mio caso chiamata NestedVM-Level2, potete installare il sistema operativo, come mostrato in figura:

Figura 8: Accensione della nested VM e installazione del sistema operativo

Se volete permette alla macchina annidata di navigare, poiché il MAC Address spoofing non è abilitato su Azure per motivi di sicurezza, sarà necessario creare una rete NAT nell’hypervisor (la VM su Azure) e poi assegnare alla Nested VM un indirizzo statico oppure potete usare il DHCP.

Per prima cosa create nella macchina “host” (la VM su Azure) un nuovo internal switch chiamato NAT utilizzando il comando PowerShell (lanciato con privilegi elevati):

#Creazione di uno switch di tipo Internal

New-VMSwitch -SwitchName “NAT” -SwitchType Internal

Con il comando Get-NetAdapter individuate l’indice assegnato alla nuova interfaccia di rete creata

Figura 9: Interfaccia di rete creata dallo switch di tipo Internal

A questo punto potete assegnare alla nuova scheda di rete un indirizzo IP statico (nel mio caso ho scelto 192.168.0.1), che poi verrà utilizzato dalla nested VM come gateway:

#Assegnazione dell’IP alla nuova interfaccia (sarà il gateway della rete)

New-NetIPAddress -IPAddress 192.168.0.1 -PrefixLength 24 -InterfaceIndex 13

Figura 10: Assegnazione dell’IP statico alla nuova interfaccia di rete

Create la rete di NAT utilizzando il comando PowerShell (lanciato con privilegi elevati):

#Creazione della rete di NAT

New-NetNat -Name NATnetwork -InternalIPInterfaceAddressPrefix 192.168.0.0/24

Adesso che avete completato la configurazione della rete potete collegare la Nested VM al virtual switch NAT che avete creato in precedenza, come mostrato in figura:

Figura 11: La nested VM viene collegata al virtual switch chiamato NAT

Potete installare sulla macchina Azure il servizio DHCP e quindi fare in modo che gli indirizzi vengano assegnati automaticamente. In alternativa potete configurare la scheda di rete della Nested VM con un IP statico, come mostrato in figura:

Figura 12: Configurazione dell’IP statico nella Nested VM

Come è possibile vedere dalla figura sotto, adesso la Nested VM è in grado di navigare in Internet.

Figura 13: La nested VM è connessa ad Internet

Conclusioni

La Nested Virtualization su Azure permette di utilizzare la nuova funzionalità di Windows Server 2016 e di eseguire macchine virtuali annidate oppure gli Hyper-V Containers di Docker. Un possibile caso d’uso della virtualizzazione annidata potrebbe essere la configurazione di un laboratorio di Hyper-V in un ambiente virtualizzato e il test di scenari a più computer (come ad esempio un cluster) senza la necessità di avere dei server fisici.

Configurare Microsoft Azure KeyVault

Azure KeyVault è un sistema di gestione di chiavi crittografiche e relativi segreti adoperati da applicazioni e servizi su Azure.

Con KeyVault è possibile crittografare chiavi di autenticazione, certificati .pfx, password ecc., utilizzando anche HSM.

Questo piccolo articolo è un’introduzione al concetto di sicurezza su Cloud e analizzerà come far comunicare un’applicazione con un’infrastruttura su Azure, attraverso l’utilizzo di una chiave crittografata. Tale configurazione viene effettuata tramite Azure PowerShell.

Per informazioni sui costi: https://azure.microsoft.com/it-it/pricing/details/key-vault/

Per velocizzare le cose utilizzeremo un’applicazione d’esempio che Microsoft mette a disposizione: https://www.microsoft.com/en-us/download/details.aspx?id=45343

Installare Azure PowerShell da PowerShell Gallery

Verifichiamo l’installazione di PowerShellGet:

Get-Module PowerShellGet -list Select-Object Name,Version,Path

Se il risultato è quanto segue, abbiamo già cosa serve:

In caso contrario, installiamo il seguente update:

https://www.microsoft.com/en-us/download/details.aspx?id=51451

Eseguendo PowerShell come amministratore, lanciamo il comando:

Install-Module AzureRM

Nel caso in cui fosse la prima volta che utilizziamo PowerShell Gallery, ci verrà richiesta una conferma prima di installare il modulo.

Confermiamo quindi l’installazione e, una volta terminata, importiamo i nuovi moduli con il comando:

Import-Module AzureRM

A questo punto siamo pronti per iniziare!

Configurare il KeyVault

Il primo passo consiste nell’effettuare il login alla propria sottoscrizione su Azure:

Login-AzureRmAccount

Selezioniamo la specifica sottoscrizione con i comandi:

Get-AzureRmSubscription

Set-AzureRmContext -SubscriptionId <subscription ID>

Creiamo un nuovo Resource Group, che con molta poca fantasia chiameremo “NewResourceGroup”, nel quale effettuare le nostre configurazioni:

New-AzureRmResourceGroup –Name ‘NewResourceGroup’ –Location ‘West Europe’

A questo punto possiamo creare un nuovo KeyVault associato al resource group:

New-AzureRmKeyVault -VaultName ‘FKeyVault’ -ResourceGroupName ‘NewResourceGroup’ -Location ‘West Europe’


L’output di quest’ultimo comando mostra una delle proprietà più importanti: il Vault URI. Tutte le applicazioni che dovranno utilizzare il nuovo KeyVault attraverso le API Rest lo faranno attraverso questo URI.

Aggiungiamo una key al nostro KeyVault:

$key Add-AzureKeyVaultKey -VaultName ‘FKeyVault’ -Name ‘NewKey’ -Destination ‘Software’

Per verificare l’URI, utilizziamo il comando:

$Key.key.kid


Per configurare una stringa a questa chiave, ad esempio una password chiamata “Segreto” il cui valore è “123password”, è necessario effettuare due operazioni:

  • convertire la stringa in una stringa sicura;
  • associare la stringa sicura alla chiave.

$secretval ConvertTo-SecureString ‘123password’ -AsPlainText –Force

$secret Set-AzureKeyVaultSecret -VaultName ‘FKeyVault’ -Name ‘Segreto’ -SecretValue $secretval

Per verificarne l’URI:

$secret.Id


Per verificare quanto appena configurato:

Get-AzureKeyVaultKey –VaultName ‘NKeyVault’

Get-AzureKeyVaultSecret –VaultName ‘NKeyVault’

Configurare l’applicazione

Dopo aver scaricato l’applicazione d’esempio, apriamo la solution con Visual Studio


Contestualmente nella directory scripts troveremo lo script GetAppConfigSettings.ps1 da modificare ed eseguire.


È sufficiente modificare le prime righe configurando ciò che abbiamo appena creato:

  • Nome del KeyVault
  • Nome del Resurce Group
  • Nome dell’applicazione


Eseguiamo lo script.

Quando richiesto, inseriamo una password per il certificato.

Al termine dell’esecuzione dello script in output avremo delle chiavi da inserire all’interno del file app.config dell’applicazione.


Caricando lo snap-in dei certificati relativi all’account locale è possibile comprovare l’avvenuta creazione del certificato, senza il quale l’applicazione non sarà in grado di verificare le credenziali su Azure.


Le applicazioni che utilizzano KeyVault devono autenticarsi utilizzando un token generato da Active Directory, nel nostro caso Azure Active Directory.

Per farlo, clicchiamo su “Azure Active Directory”, successivamente su “App registrations” e cerchiamo la nostra applicazione HelloKeyVault.


Abilitiamo l’applicazione all’utilizzo della chiave copiando il clientID (Application ID) e utilizziamo il seguente comando:

Set-AzureRmKeyVaultAccessPolicy -VaultName ‘FKeyVault’ -ServicePrincipalName 341efa38-faf5-459e-903a-05e9a5ad7309 -PermissionsToKeys all

Per verificare che tutto sia andato a buon fine proviamo a eseguire l’applicazione dal sistema in cui è installato il certificato. In questo modo vedremo come questa utilizzi il KeyVault generato e la relativa chiave, con la possibilità di eseguire tutte le operazioni che il KeyVault stesso mette a disposizione:


Conclusioni

La sicurezza è sempre una tematica attuale e, spesso, sottovalutata.

In questo contesto, Azure fornisce delle soluzioni pratiche anche per quei clienti spaventati dall’avere i propri dati sul Cloud.

Fornire agli sviluppatori delle chiavi crittografate, centralizzandone la gestione e mantenendo uno standard di sicurezza adeguato è solo uno dei pregi di questa soluzione, benché sia facilmente intuibile di aver trattato solo scalfito la superficie di quest’ampia tematica.

VeeamON 2017 Recap

Si è da poco conclusa la seconda Keynote del VeeamON 2017, che ha visto diversi annunci e novità presentate. Oltre 2500 professionisti IT sono presenti alla più importante conferenza dedicata all’Availability, con tantissimi partner presenti e sponsor di alto profilo, che hanno presentato le loro soluzioni per l’Always Connect. Ecco gli annunci più importanti presentati durante le due Keynote:

Veeam Agent for Microsoft Windows v2

Il prodotto era già stato rilasciato settimana scorsa ma da ieri il prodotto è ufficialmente sul mercato. La nuova versione consente di effettuare la protezione più avanzata delle proprie macchine fisiche e virtuali, rispetto al precedente Endpoint Backup. Confermati i tre livelli di licensing: Free, Workstation e Server, con diverse funzionalità ed integrazioni.

Veeam Availability for AWS

Grazie alla collaborazione con N2WS, la soluzione permette di proteggere applicazioni e dati presenti all’interno di Amazon Web Services, il tutto in modo agentless. Attualmente l’intera gestione è demandata al partner ma prossimamente si dovrebbero vedere dei cambiamenti.

Veeam Backup for Office 365 v1.5

Nuova build della soluzione dedicata alla protezione delle mailbox posizionate in Office 365. La v1.5 introduce le seguenti novità:

  • Multi-Tenant
  • Multi-Repository con retention differenziate
  • Supporto a RestAPI e PowerShell per automatizzare e creare script per backup e restore

Durante la seconda giornata è stato annunciato il supporto a SharePoint e OneDrive for Business a partire dalla versione 2.0. Un grande colpo che permette di mettere in sicurezza anche i dati aziendali e personali, soprattutto in ottica Ransomware.

Veeam Management Pack v8 Update 4

L’aggiornamento di MP v8 introdurrà nuove dashboard e strumenti per offrire informazioni sempre più dettagliate e utili agli amministratori IT, che utilizzato System Center Operations Manager, oltre al supporto per Hyper-V 2016 e VMware vSphere v6.5. La grande novità riguarda l’estensione delle informazioni all’interno di Microsoft Operations Management Suite, la piattaforma di monitoring basata sul cloud. Le dashboard attualmente disponibili saranno:

Veeam Disaster Recovery in Microsoft Azure

La soluzione si compone di due elementi: Direct Restore for Azure e Veeam Power Network. Quest’ultimo è un prodotto gratuito che si può attivare all’interno dell’Azure Marketplace che permette di creare VPN in modo facile e di rendere le operazioni di Disaster Recovery più semplici e rapide. Nel momento in cui effettuate il Failover di una vostra macchina locale su Azure, potete attivare la connessione VPN, tramite una console web presente on-premises, per fare in modo che i vostri utenti possano collegarsi sempre alle risorse aziendali. La configurazione globale delle varie VPN viene gestita tramite una console web e file XML.

Veeam PN for Microsoft Azure è già disponibile a questo link: https://www.veeam.com/cloud-disaster-recovery-azure-download.html

Il dettaglio della soluzione è disponibile a questo link: https://www.veeam.com/cloud-disaster-recovery-azure.html

Veeam Availability Console v2

Sbarca la versione 2.0 del VAC che introduce diverse funzionalità, tra cui la gestione remota delle console Veeam Backup & Replication, tramite Cloud Connect, ma anche di quelli che sono gli Agent Windows e Linux. Il prodotto nasce prevalentemente per i Service Provider ed è implementato all’interno di una soluzione Cloud (Azure o AWS) per poter garantire sempre la disponibilità del gateway primario. Tra le altre novità troviamo la possibilità di avere più report, poter gestire meglio gli storage tier dei vari clienti e nuove policy di configurazione.

Veeam Backup & Replication v10

Non poteva non esserci la presentazione ufficiale della versione 10 del software più famoso della casa di San Pietroburgo. Molte le novità introdotte, tra cui:

Built-in management for Veeam Agent

Finalmente sarà possibile distribuire gli Agent su macchine fisiche e virtuali dalla console di B&R, sia Windows che Linux, andando a creare le relative policy di retention, scegliendo se configurare l’agent per essere centralizzato o stand-alone. La discovery degli oggetti può essere fatta tramite IP Range, file .csv e tramite Active Directory.

NAS backup support for SMB and NFS shares

Uno dei tasselli mancanti di Backup & Replication era la possibilità di proteggere share di rete presenti all’interno dei NAS, sia SMB che NFS. Con la versione 10 questo sarà possibile, grazie all’utilizzo di un File Proxy, una macchina Windows che ha il compito di recuperare i file dal NAS e spostarli dentro il Repository di destinazione. Molto utile la possibilità di effettuare una doppia retention e di poter creare delle shadow copies delle copie a retention lunga, per evitare la corruzione del dato (sempre in ottica CryptoLocker).

Scale-Out Backup Repository Archive Tier

Sarà possibile andare ad estendere il proprio Scale-Out Repository con uno storage posizionato su cloud, ad esempio Azure Blob Storage o Amazon S3, per ridurre i costi di gestione interna e spostare esternamente tutto quello che può essere definito “vecchio”. Questa funzionalità è molto utile per quelle aziende che non hanno una tape library ma che vogliono avere un sito di disastro con un costo più limitato.

Veeam CDP (Continuous Data Protection)

Il Continuous Data Protection è una modalità che consente di replicare una macchina virtuale all’interno di un altro sito, anche di un partner, con un tempo di RTO ed RPO bassissimi. Questo significa avere una consistenza del dato e dell’applicazione praticamente in realtime, garantendo appunto la Business Continuity. Vista la complessità dell’architettura, Veeam CDP è attualmente disponibile solo per ambienti VMware e la buona notizia è che non vengono utilizzate le snapshot.

Universal Storage Integration API

IBM, Lenovo e Infinidat, queste sono le tre nuove aziende partner di Veeam per la parte di storage. Proprio per invogliare le aziende ad offrire soluzioni integrate con Backup & Replication, è stato creato un nuovo framework chiamato Universal Storage Integration API. La validazione finale di tutto il processo rimane sempre in carico a Veeam e quindi non c’è il rischio che un vendor rilasci una soluzione non supportata.

La Technical Preview dovrebbe essere rilasciata a breve, mentre la RTM è attesa per la fine dell’anno.

Veeam Availability Orchestrator

Annunciata una nuova Preview di VAO, che in questo momento ha ancora dei limiti tecnici, tra cui il fatto di poter gestire solo ambienti VMware. Per chi non lo conoscesse, Orchestrator è la soluzione di gestione DR tra due siti in modo di tenere allineate le varie macchine virtuali e ridurre al minimo l’interruzione di servizio. La logica è quella già presente in Microsoft Azure Site Recovery.

Veeam Agent for Microsoft Windows 2.0

Da ieri è disponibile in GA la versione 2.0 di Veeam Agent for Windows, la soluzione di backup per ambienti fisici client e server. Del prodotto ne abbiamo già parlato all’interno di questo articolo. Tra le funzionalità più importanti troviamo:

  • Active full backups
  • Application-aware processing
  • File indexing and search
  • Instant Recovery to Microsoft Hyper-V VM
  • Integration with Veeam Backup & Replication
  • Server-specific scheduling and retention
  • Synthetic full backups
  • Transaction log backup for databases
  • Back up off site through Veeam Cloud Connect
  • Direct Restore to Microsoft Azure
  • Source-side encryption

Rispetto alla precedente versione, chiamata Endpoint, il supporto alle versioni server è dato a pieno grazie all’application-aware processing. Altre due funzionalità interessanti sono il backup su device USB con disconnessione automatica, o su cloud tramite Cloud Connect. Veeam Agent è disponibile in 3 licenze diverse, che abilitano funzionalità diverse tra di loro, come mostra la figura 2.

Download Veeam Agent for Windows 2.0