Flash: nel 2020 Adobe interromperà supporto e distribuzione

L'annuncio della dismissione di Flash su Twitter

Il tweet che ha annunciato la dismissione di Flash.

Dopo oltre vent’anni di servizio, la prima versione risale al 1996, Flash si prepara ad uscire di scena – “finalmente!” diranno i detrattori del software Adobe. La nota azienda ha ufficializzato la dismissione di Flash via Twitter:

We’ll stop updating & distributing Flash Player by the end of 2020. More about our plans & a look on what’s next adobe.ly/2vGjSxe

La fase discendente del player è iniziata alcuni anni fa (anche se la “scomunica” più famosa risale al 2010 e fu lanciata da Steve Jobs) quando diverse compagnie hanno ritenuto necessario bloccare il plugin (es: Google su Chrome, Mozilla con Firefox) o a rimpiazzare il software con alternative considerate più sicure (passaggio di YouTube ed Amazon ad HTML5).

Altri indizi circa l’approssimarsi della dismissione di Flash sono arrivati ad inizio 2016 con la modifica al nome di uno dei servizi messi a disposizione dalla piattaforma Creative Cloud (da Flash Professional CC ad Adobe Animate CC).

Secondo i siti specializzati, l’azienda che acquistò Flash nel lontano 2005, quando era ancora presente nel 98% dei computer connessi ad Internet, ha dimostrato proprio in quell’occasione di aver preso atto della situazione “problematica” del player –  WebGL e soprattutto HTML5, quest’ultimo definito dalla stessa Adobe “uno degli standard predominanti sul Web”, erano utilizzati dagli utenti per produrre quasi la metà dei progetti sviluppati con Creative Cloud.

Fase di transizione

In attesa che la “spina” sia definitivamente staccata, Adobe continuerà naturalmente a fornire aggiornamenti di sicurezza e supporto al celebre player. Perchè aspettare ancora e non “farla finita” subito, si chiederanno molti utenti.

Semplicemente perchè, nonostante le varie problematiche che si porta dietro ormai da anni, è ancora utilizzato da diversi software, portali ed attività: il tempo che ci separa dalla dismissione dovrà essere utilizzato per preparare la Rete ad un futuro senza Flash, come dichiarato da Google:

[servirà parecchio lavoro di squadra] con Adobe, gli altri browser, ed i principali publisher per essere sicuri che il Web sia pronto [ad un futuro senza il software Adobe]. […] Lavoreremo con chiunque voglia migliorare ulteriormente il Web.

Fonti: 1, 2

 

Windows Hello disabilitato con Windows 10 (Version 1607,1703) in dominio

Dalla versione 1607 di Windows 10, Microsoft ha cambiato il modo in cui gestisce l’impostazione del PIN e della biometria nei computer joinati ad un dominio di Active Directory. Nei computer, ad esempio il Surface Pro 4 che ha il riconoscimento facciale e il PIN con la funzione di Windows Hello, facendo l’upgrade alle versioni 1607 o 1703 l’utente non sarà più in grado di impostare i settaggi relativi alla biometria e all’accesso col PIN. Infatti se si apre la pagina sotto Impostazioni – Account – Opzioni d’accesso si potrà notare che alcuni settaggi sono in grigetto e una dicitura in rosso comunica che “alcune impostazioni sono gestite dalla vostra organizzazione” (Vedi figura qui sotto). Con account locale invece è tutto sbloccato.

 

Per poter gestire queste funzionalità l’amministratore di rete deve abilitare alcune Group Policy dal Domain controller.

  • Se non lo si è già fatto, importare gli ADMX files aggiornati di Windows 10 nell’archivio centrale, cartella PolicyDefinitions, del DC nel percorso \\miodominio\SYSVOL\miodominio\Policies, fare riferimento all’articolo “Download the new ADMX Templates” su Technet.
  • Creare una nuova GPO o aggiungere ad una esistente i seguenti settaggi in Computer Configuration/Policies/Administrative Templates..

    –> …/System/Logon/ Turn on convenience PIN sign-in => Enabled
    –> …/Windows Components/Biometrics/ Allow domain users to log on using biometrics => Enabled
    –> …/Windows Components/Windows Hello For Business/ Use biometrics => Enabled

Faccio presente che, per i computer Upgradati alla versione 1607 con le funzionalità già abilitate prima dell’upgrade, possono comunque accedere tramite PIN, cambiarlo, resettarlo o cancellarlo.

Registrazione domini: i risultati del Q1 2017

Verisign ha pubblicato in questi giorni il periodico report “The Domain Name Industry Brief”. I dati del primo trimestre 2017 sono sicuramente molto attesi dagli addetti ai lavori perchè in grado di dare preziose indicazioni su quel che sarà l’andamento generale del settore. Il rapporto si apre come sempre con un paragrafo nel quale sono riportate varie cifre e percentuali, in sintesi:

  • la base di domini registrati (tutti i TLD) raggiunge quota 330.6 milioni. Rispetto al q4 2016 la crescita è pari allo 0.4% (+1.3 milioni di domini). Su base annuale la crescita è del 3.7%;
  • i ccTLD passano da 142.7 milioni a 143.1 milioni (la cifra è da considerarsi parte dei 330.6 milioni citati nel punto precedente), in crescita dello 0.3%.

Non del tutto positivi i risultati del duo .COM e .NET: sebbene il primo abbia nuovamente superato la “soglia psicologica” delle 128 milioni di registrazioni (126.9 milioni nel q4 2016, 128.4 milioni al 31 Marzo 2017), il secondo è passato da 15.3 milioni a 15.2 milioni. Anche la somma delle nuove registrazioni .COM e .NET effettuate nel q1 2017 è in calo e passa da 10 milioni (q1 2016) a 9.5 milioni.

Registrazione domini nel q1 2017

La maggior parte delle estensioni nella top10 generale ha incrementato il numero di registrazioni totali rispetto al q4 2016. Le estensioni che hanno avuto un calo sono .TK, .NET e .XYZ. Fonte: Verisign.

Andamento dei ccTLD

Come evidenziato nel paragrafo precendente, la base di ccTLD registrati cresce dello 0.3% (+ 408,242 domini) su base trimestrale e dell’1.7% su base annuale. Rispetto al q1 2016 la top10 resta invariata :

ccTLD: classifica in base al numero di registrazoni totali. Fonte: Verisign.

Andamento dei gTLD

In calo anche la base di gTLD registrati che passa da 25.6 milioni (q4 2016) a 25.4 milioni. Nella seguente immagine i gTLD sono messi a confronto con la domain base globale:

Registrazione domini nel q1 2017

I gTLD rappresentano il 7.7% della domain base globale. Fonte: Verisign.

La sintesi del rapporto Verisign si chiude con il confronto tra i gTLD a tema geografico ed i corrispettivi ccTLD (es: .TOKYO e .JP). Rispetto al q4 2016 le percentuali restano invariate. Entrambi i gruppi presi in esame incrementano leggermente la rispettiva domain base (da 62.8 milioni a 63 milioni per i ccTLD; da 559,696 a 564,524).

Registrazione domini nel q1 2017

I gTLD geografici non riescono ancora a raggiungere l’1% del totale. Fonte: Verisign.

Fonte: 1

 

 

Come effettuare un PenTest – Parte 3: Target Discover

Eccoci qui.

Siamo arrivati alla parte di Target Discover, nonché la terza fase del PenTest. Cercheremo di descrivere dei metodi per identificare un target utilizzando sempre alcuni fantastici Tools. Occorre ricordare che il successo di questa fase e delle prossime dipende solo ed esclusivamente da un buon approccio alla fase 2 (Information Gathering).

I tool che introdurremo, alcuni di uso comunissimo per operazioni di troubleshooting, saranno utilizzati per identificare una host target che dovrà essere sfruttato per condurre le fasi successive del pentest. Prima di condurre la fase di “Identification” è importante rileggere le condizioni di ingaggio assegnate dal cliente: una possibile richiesta di mascherare tutte le nostre attività e renderle non rilevabili da IDS/IPS, deve modificare il nostro approccio in modo da rispettare tale richieste. (es. evasion techniques)

Ping

Chi di voi non conosce il ping?

Per chi non lo conoscesse, il “ping” è un comando universale (Windows/Unix) che permette di comprendere se un host è disponibile o meno. Basato su invio/ricezione di un pacchetto ICMP “Echo Request/ Echo Reply” verso l’host target. Se host è disponibile ed un eventuale FW non blocca i pacchetti ICMP esterni avremo la risposta che l’host è attivo.

#ping 127.0.0.1

In linux, il comando ping non si interrompe mai, fin quando non viene premuta la combinazione CTRL + C.

Il ping può essere usato con ulteriori opzioni che possono essere molto utili come:

-c
corrisponde al numero di pacchetti echo request che devono essere inviati;

-I
permette di identificare su quale Inteface address si vuole agire;

-s
determina la dimensione del pacchetto; Per default un pacchetto echo request è di 56 byte che viene traslato in 64 ICMP byte + 6 byte di header data.

Fping

Variante del comando ping è Fping che viene usato per inviare pacchetti multipli ICMP echo request verso più host contemporaneamente. È possibile specificare una lista di hosts via shell o via file.

Fping invia solo 3 pacchetti echo request e si preoccupa di analizzare le risposte di ogni host. Se un host risposte lo elimina dalla lista target, se non riceve risposta entro un limite di tempo, lo marca come unreacheble.

#fping -h


È possibile anche modificare il numero di tentativi verso il target utilizzando opzione -r (retry limit).

-s
può essere utilizzato per mostrare statistiche cumulative

Arping

Questo comando è molto utile in una LAN, in quanto opera a livello 2 nella pila OSI (network layer) e non può essere direzionato tra routers o gateway. Permette di sfruttare un comando legittimo e difficilmente individuabile da sonde IDS/IPS.

# arping

Hping3

Questo tool permette di generare pacchetti e di analizzare le possibili risposte. La possibilità di creare pacchetti custom permette di essere usato per security test come por scanning, test di firewall, test di performance network, exploit di vulnerabilità nello stack TCP/IP o test su IDS.

# hping3

-0 permette di inviare pacchetti IP raw;

-1 Invia pacchetti ICMP;

-2 Invia pacchetti UDP

-8 Indica la modalità “scan”;

-9 Indica la modalità “listen”.

Tramite questo tool è possibile generare un pacchetto TCP con flag personalizzati come:

-S SYN

-A ACK

-R RST

-F FIN

-P PUSH

-U URG

-X XMAS (Tutti i flag attivi)

-Y YMAS

Un esempio di utilizzo di hping3 è stato già affrontato qui: https://www.ictpower.it/sicurezza/come-funziona-un-attacco-dos-blacknurse.htm

Nbtscan

Un tool utile in caso di target discover dove i target sono prettamente ambienti Windows è nbtscan.

Esso permette di recuperare le informazioni dal NETBIOS. Permette di produrre un report dove vengono raccolte info come IP, Host Name, servizi disponibili, username di chi è loggato e MAC dell’host.

#nbtscan 192.168.x.x (per una scansione di una classe di IP usare -r 192.168.x.x/24)


Per una scansione dei servizi utilizzare l’opzione -hv.

Dopo aver elencato una lista utile per la target discovery, passiamo ad analizzare i target identificati.

Os fingerprint è il processo che determina il sistema operativo usato da un host presente in rete; esistono due metodologie: attiva e passiva:

  • Nella modalità attiva, più intrusiva e più veloce, andiamo a generare dei pacchetti e analizzare le risposte;
  • nella tecnica passiva, si osserva l’attività di rete dell’host tramite sniffing senza andare a produrre pacchetti. (modalità stealth).

P0f

Il primo tool che analizziamo permette di ottenere un OS fingerprint in maniera passiva. Analizza gli host che scambiano pacchetti TCP con flag (SYN, SYN+ACK, RST).

Nmap

Il tool più famoso per il port scan è NMAP. Anche questo tool possiede la possibilità di ottenere OS fingerprint.

# Nmap -O 192.168.x.x


Per chi volesse approfondire il funzionamento dell’OS fingerprint di Nmap vi rimando al link: https://nmap.org/man/it/man-os-detection.html a mio avviso più completo di qualsiasi altra spiegazione.

Nel prossimo articolo sfrutteremo Nmap per affrontare la fase di enumerazione che consiste nel processo di raccolta di informazioni riguardo porte, sistema operativo e servizi disponibili sull’host target.

Gestione backup GLPI v9.1.4 in ambiente Windows

Su ICTPower.it è stato pubblicato l’articolo Gestione backup GLPI v9.1.4 in ambiente Windows che ho scritto a due mani con Roberto Massa, nell’articolo vengono descritti i passi per la gestione del backup di GLPI 9.1.4 installato in IIS con PHP 7.1.1 in ambiente Windows Server 2012 R2.

Per un articolo sull’installazione di GLPI (Gestion Libre de Parc Informatique) si veda il nostro articolo Installazione GLPI v9.1.4 in ambiente Windows, mentre per un articolo sulla configurazione dell’autenticazione Windows si veda Configurazione autenticazione Windows in GLPI v9.1.4.

Consentire ad utenti non amministratori di aggiungere computer a dominio

Come descritto nelle KB243327 Default limit to number of workstations a user can join to the domain, KB251335 Domain Users Cannot Join Workstation or Server to a Domain e KB314462 “You Have Exceeded the Maximum Number of Computer Accounts” Error Message When You Try to Join a Windows XP Computer to a Windows 2000 Domain per impostazione predefinita in Windows 2000 e successi tutti gli utenti autenticati possono eseguire il join a dominio di 10 computer, tale limite non vale per i membri dei gruppi di Active Directory Administrators e Domain Administrators:

By default, Windows 2000 allows authenticated users to join ten machine accounts to the domain.

This default was implemented to prevent misuse, but can be overridden by an administrator by making a change to an object in Active Directory.

Note that users in the Administrators or Domain Administrators groups, and those users who have delegated permissions on containers in Active Directory to create and delete computer accounts, are not restricted by this limitation.

Per consentire ad un utente o ad un gruppo di utenti di eseguire il join a dominio senza limitazione è possibile utilizzare più metodi:

Metodo 1: Creare prima l’account computer e assegnarlo al gruppo o all’utente che eseguirà il join a dominio

Metodo 2: Modificare il limite di default relativo al numero di computer di cui è possibile eseguire la join a dominio

Per modificare tale limite è possibile avviare Adsiedit.msc con le credenziali di amministratore di dominio per modificare l’attributo ms-DS-MachineAccountQuota del dominio.

Per disabilitare il limite è possibile non impostare alcun valore.

Per sicurezza è consigliabile che gli Autheticated Users non possano eseguire la join a dominio dei computer modificando la Default Domain Policy per consentire l’aggiunta di workstation al dominio solo all’utente o al gruppo designato.

In alternativa è possibile creare una Group Policy connesso all’Organization Unit Domain Controllers per sovrascrivere l’impostazione “Aggiunta di workstational dominio”:

Il blocco del join a dominio da parte degli Authenticated Users è anche una best practices suggerita nel post Who can add workstation to the domain da Rafal Sosnowski (membro del Microsoft Dubai Security PFE Team):

During my numerous Security Audits and Assessments I deliver to customers, I usually discover too wide permissions and user rights configured in Active Directory. One of them is “Add Workstation to the Domain”

It is important to control who can add new machines to our AD environment. Although we can enforce various security settings via GPO on newly added machines, user could join machine which is not configured according to our security standards and at the same time having ownership of various objects in the system (local admin account, ACLs on file system etc.).

Si noti che la Group Policy Add workstations to domain si applica solo ai domain controllers.

Metodo 3: Concedere i privilegi Access Control Entries (ACEs) “Create Computer Objects” e “Delete Computer Objects” Access Control Entries (ACEs) al gruppo o all’utente che eseguirà il join a dominio

Tale privilegi dovranno essere concessi sul container Compters mediante il tab Sicurezza delle proprietà oppure è possibile utilizzare la delegation, a riguardo si vedano i seguenti:

Utilizzando la Delegation l’impostazione del limite definito in ms-DS-MachineAccountQuota verrà ignorata, inoltre volendo è possibile cambiare il default Computer container per utilizzare una OU specifica tramite il comando redircmp.

Conclusioni

Tramite la Delegation è possibile controllare in modo granulare non solo chi può eseguire la join a dominio, ma anche le atre attività e quindi nonostante l’implementazione della Delegation richieda un carico amministrativo più elevato se nella gestione dell’infrastruttura si vogliono suddivide le attività su utenti e gruppi differenti questa è l’approccio più corretto come indicato anche da Rafal Sosnowski:

I do recommend using delegation and remove all users from “Add workstation to the Domain” from Default Domain Controller Policy except Administrators (as contingency plan). Also you can reduce ms-DS-MachineAccountQuota value to 0.

Se invece esiste un solo utente o gruppo che deve occuparsi dell’amministrazione dei computer può essere sufficiente utilizzare la GPO Add workstations to domain per concedere solo a tale utente o gruppo il privilegio di aggiungere i computer al dominio e non impostare alcun valore nell’attributo ms-DS-MachineAccountQuota.

Si noti che come già indicato nella KB243327 e ribadito anche da Rafal Sosnowski, i membri dei gruppi di Active Directory Administrators e Domain Administrators hanno sempre per delega i privilegi per aggiungere computer a dominio:

So you might ask: although I configure delegation only on specific OU, and “Add workstation to the domain” is empty why Domain Admins can still add machines to the domain?

This is because “Administrators” group (containing Domain Admins) has direct and explicit ACL permissions to create Computer objects. This permission is assigned on the domain level with propagation enabled.

Microsoft Security Risk Detection: fuzz testing nel cloud

Fonte: sito ufficiale Microsoft

Microsoft Security Risk Detection (MSRD), noto precedentemente come Project Springfield, sta per entrare ufficialmente nel porfolio Microsoft Azure. Lo sviluppo del progetto interno di Redmond giunge così a buon fine dopo quasi 10 anni di gestazione. Di cosa si tratta esattamente?

MSRD è uno strumento pensato per il fuzz testing, ovvero l’individuazione di eventuali bug in un’applicazione. L’idea alla base del fuzz testing è molto semplice: inviare svariate tipologie di dati ad un’applicazione per metterla in difficoltà ed evidenziare potenziali criticità nel codice.

Appoggiarsi all’intelligenza artificiale ed al cloud permette di ottenere naturalmente risultati migliori, come spiegato sul blog ufficiale dal ricercatore che ha guidato il team assegnato a Springfield (David Molnar):

“Impieghiamo l’IA per automatizzare i medesimi ragionamenti che io o tu faremmo per individuare un bug [estendendoli alla potenza del cloud].” […]

Il fuzz testing è una delle tante misure di sicurezza che gli esperti raccomandono per preservare la sicurezza dei sistemi. [Il fuzz testing] va in cerca di vulnerabilità che potrebbero consentire a malintenzionati di lanciare attacchi o semplicemente mandare in crash il sistema.

Il fuzz testing è stato pensato per individuare queste vulnerabilità; gli sviluppatori possono successivamente usare altri strumenti per correggere i bug, mitigare i rischi o vagliare altre soluzioni.

Il servizio MSRD […] utilizza l’IA per porsi una serie di domande “e se” e cercare di individuare ciò che potrebbe portare ad un crash e risultare come una problematica per la sicurezza. Ogni volta che viene eseguito, MSRD migliora [le proprie conoscenze] negli ambiti più critici, cercando vulnerabilità che [potrebbero passare inosservate ad altri strumenti “non intelligenti”].

Altri dettagli

MSRD è destinato all’analisi di applicazioni Windows/Linux  e sarà acquistabile via Microsoft Service nel corso dell’estate.

MSRD potrà essere utilizzato su applicazioni installate in VM Azure. Il cliente avrà a disposizione diverse varianti del tool (fuzzers) e potrà impiegare MSRD per mettere alla prova anche la sicurezza di un portale – MSRD non è però in grado di identificare vulnerabilità comuni come il cross-site scripting.

La data di lancio ufficiale ed i prezzi di listino non sono ancora noti ma saranno rivelati probabilmente a breve.

Fonti: 1, 2

“Il mio VMworld”: i ricordi di David Baldinotti, Computer Gross

David Baldinotti, Business Unit Manager di J.Soft, divisione software di Computer Gross

Il primo VMworld al quale ho partecipato è stato quello del 2012 di Barcellona, era un momento in cui il tema legato alla virtualizzazione dell’infrastruttura stava andando a una velocità clamorosa. Intorno al Software-Defined Data Center c’era un forte interesse e tutti avevamo la grande curiosità e la voglia di essere partecipi di questo cambiamento così significativo, ossia reinterpretare l’IT lato infrastruttura.

La stessa curiosità che ho oggi alla vigilia del VMworld 2017 Europe, dal quale mi aspetto di approfondire la strategia di VMware soprattutto alla luce di tecnologie nuove su cui si sta puntando, come ad esempio l’iperconvergenza e la virtualizzazione delle reti. C’è sempre molta curiosità anche intorno all’area del Solution Exchange, dove è possibile incontrare player emergenti che presentano specifiche tecnologie. È un aspetto interessante del VMworld, perché VMware in questo senso spesso anticipa alcune tendenze ed è in grado di tracciare la direzione dell’IT e l’evoluzione di alcune tecnologie chiave.

Dal punto di vista delle novità che mi piacerebbe vedere annunciate quest’anno, il mio desiderio è uno sviluppo ulteriore dei temi legati ai servizi cloud, ossia che il Canale diventi un attore importante del processo. Penso ad esempio all’accordo con AWS e auspico un coinvolgimento importante dell’ecosistema di Partner.

E come parte del Canale VMware, per Computer Gross il VMworld rappresenta un momento di incontro e di scambio utile: partecipare ci permette di capire meglio la vision dell’azienda, di toccare con mano le novità, di comprenderne la portata. E, soprattutto, il VMworld è il momento in cui poter intrattenere relazioni a 360 gradi, che è alla base della nostra strategia, ma anche avere il punto di vista di chi gestisce Paesi e aree più vaste e arricchire così le proprie conoscenze che possono essere corroborate da una vision più ampia.

Se guardo al passato, un episodio che mi piace ricordare è legato al VMworld 2014: Computer Gross è stata premiata come “VMware EMEA Innovative Distributor of the year” all’interno della “EMEA VMware Partner Award”. È stato il risultato di un forte impegno che ci ha permesso di portare concreto valore al nostro Canale grazie a una condivisione degli obiettivi. Chissà che anche il 2017 non ci riservi qualcosa di importante.


Il VMworld 2017 sarà il più incredibile di sempre e noi abbiamo deciso di renderlo anche il più divertente!
Pubblica una tua foto ricordo significativa di un VMworld passato e lancia la sfida ai tuoi colleghi utilizzando l’hashtag #VMworldMemories.

 

Il cloud privato è più conveniente del cloud pubblico

451 Research e report sul cloud privato

Si discute ormai da anni su quale sia la soluzione ideale per le aziende: secondo Google è il cloud pubblico a garantire il miglior rapporto prezzo/prestazioni; Amazon e Microsoft hanno invece optato per il cloud ibrido; le dirette interessate hanno fornito invece risposte non univoche (Dropbox ha abbandonato ad esempio la piattaforma AWS, Netflix ed Evernote hanno invece deciso di migrare la propria infrastruttura nella nuvola).

Lo scorso Febbraio 451 Research, su richiesta di VMware, ha interpellato 150 IT decision maker “scoprendo” che in due casi su cinque il cloud privato, contravvenendo quindi alla vulgata, garantisce all’azienda dei costi operativi inferiori a quelli del cloud pubblico. Il report “Can private cloud be cheaper than public cloud?” ha evidenziato una serie di interessanti dettagli che riportiamo qui di seguito.

Cosa incide sulla scelta?

  • La protezione dei dati è citata nel 71% dei casi come motivazione principale della scelta di una soluzione cloud privato.
  • Il rapporto costo-efficienza nel  54% dei casi. Gli interpellati lo indicano come uno dei fattori trainanti d’adozione.
  • La proprietà degli asset nel 43% dei casi.
  • L’integrazione con i processi di business chiude la classifica al 42%.

Costi operativi

  • Il 24% del campione ha affermato di pagare un 10% di costi aggiuntivi in meno optando per una soluzione cloud privata.
  • Per il 41% dei decision maker i costi del cloud privato sono inferiori a quelli del pubblico.
  • Se i prezzi del cloud pubblico fossero la metà di quelli del cloud privato, gli interpellati non sposterebbero più del 50% dei propri workload nel cloud pubblico.

Che cosa consente di ridurre i costi operativi in un ambiente cloud privato?

  • Gli strumenti di pianificazione della capacità (in riferimento alle risorse da adottare) sono indicati dal 18% del campione.
  • Costi delle licenze favorevoli e software di automazione seguono al 17%.
  • Strumenti per la gestione dei costi/budget sono al 15%.
  • Il report parla infine di altri espedienti adottati dalle aziende per abbassare ulteriormente i costi come la negoziazione dei contratti con hardware vendor e software (aziende di un “certo peso” possono permetterselo) o il riutilizzo di licenze già esistenti.

Fonte: 1

Altaro VM Backup 7.5 configurare un Backup Copy in Azure

Altaro VM Backup 7.5 configurare un Backup Copy in Azure

vmbackup75whatsnew01

Altaro ha rilasciato Altaro VM Backup 7.5, la soluzione di backup virtuale per VMware vSphere e Microsoft Hyper-V introducendo il supporto per il backup in Azure.

La funzione di backup in Azure è disponibile solo per l’edizione Unlimited Plus di Altaro VM Backup e un confronto dei prezzi delle licenze può essere visionato nella pagina web dedicata di Altaro.

 

Novità nella versione 7.5

Oltre al disco locale, al percorso di rete o un Altaro Offsite Server, Altaro VM Backup può ora salvare una copia di backup in Azure.

vmbackup75whatsnew02

I principali benefici introdotti nella versione 7.5 sono i seguenti:

  • Gli amministratori possono utilizzare lo storage Azure Block Blob che è l’opzione di storage più economica in Azure
  • I backup possono essere ripristinati da Azure verso installazioni di Altaro VM Backup diverse
  • Supporto della compressione, criptazione di Altaro e la migliore deduplica del settore
  • Nessuna VM aggiuntiva deve essere installata in Azure

 

Configurare un Backup Copy in Azure

Per effettuare una copia di backup in Azure, è necessario configurare l’ambiente Azure ed impostare in VM Backup una Offsite Backup Location.

 

Configurazione dell’ambiente Azure

Per salvare i backup in Azure è necessario creare uno Storage Account. Per creare uno storage account, accedere al portale Azure ed inserire le proprie credenziali per effettuare il login.

vmbackup75whatsnew03

Dalla Dashboard, cliccare sull’opzione New > Storage e selezionare la voce Storage account – blob, file, table, queue come featured app.

vmbackup75whatsnew04

Inserire un Name, specificare General purpose come Account kind e creare una nuova Resource Group. Selezionare la Location da utilizzare e cliccare su Create.

vmbackup75whatsnew05

Accedere al nuovo Storage Account creato e selezionare Access Keys sotto la voce Settings. Questo valore è richiesto da Altaro per accedere allo storage account di Azure.

vmbackup75whatsnew06

 

Configurare l’Offsite Location di Altaro

Aprire l’applicazione Altaro e posizionarsi in Backup Location. Nel lato destro cliccare sul bottone Add Offsite Location.

vmbackup75whatsnew07

Selezionare l’opzione Cloud Backup to an Azure Storage Account e cliccare su Next.

vmbackup75whatsnew08

Inserire l’Azure Storage Account connection string e cliccare su Test Connection.

vmbackup75whatsnew09

Quando il test della connessione viene completato con successo, cliccare su Finish per salvare la configurazione.

vmbackup75whatsnew10

La nuova Azure Offsite Location è stata creata.

vmbackup75whatsnew11

 

Creare un Backup Copy in Azure

Per creare un Backup Copy in Azure, assegnare le VM da processare come backup offsite alla locazione offsite Azure appena creata.

vmbackup75whatsnew12

Posizionarsi nella sezione Take Offsite Copy e selezionare le VM da processare. Cliccare sul bottone Take Offsite Copy per avviare il task. Da tenere presente che un full backup deve essre disponibile prima di poter effettuare una copia di backup offsite.

vmbackup75whatsnew13

Le VM vengono processate e copiate in Azure.

vmbackup75whatsnew14

A seconda della dimensione delle VM, dopo alcuni minuti la copia viene completata mostrando il risultato dell’operazione.

vmbackup75whatsnew15

Dalla Dashboard di Azure, selezionare la voce All Resources > Storage Account’s name > Blob Service per identificare le virtual machine appena copiate.

vmbackup75whatsnew16

Una copia di backup delle proprie VM sono ora salvate in Azure e disponibili in caso di necessità.

signature

Copyright Nolabnoparty. All Rights Reserved.

Blog italiani (e in italiano) nel mondo IT/ICT