Tutti gli articoli di Nicola Ferrini

Implementare reti wireless sicure con 802.1x ed EAP-TLS con Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Per permettere l’accesso alle nostre reti wireless molto spesso utilizziamo delle chiavi di cifratura WPA2, che rimangono le stesse per diverso tempo, e che spesso vengono anche consegnate ad utenti ospiti delle nostre reti. Chiunque disponga della chiave può quindi accedere alla WLAN e non sempre nelle nostre infrastrutture ci preoccupiamo di cambiarla periodicamente, considerando anche che dovremmo farlo su tutti gli access point e su tutti i client.

Per garantire un metodo più affidabile di autenticazione e autorizzazione, da anni è possibile implementare una struttura di protezione WLAN basata sul protocollo 802.1x, uno standard IEEE per l’autenticazione dell’accesso alla rete che può anche essere utilizzato per la gestione delle chiavi di protezione WPA2. Il suo utilizzo non è limitato alle reti senza fili, ma può essere implementato in numerosi switch di fascia alta nelle reti LAN cablate. Per approfondimenti sul funzionamento del protocollo 802.1x vi rimando alla pagina https://it.wikipedia.org/wiki/IEEE_802.1x

In questo articolo vedremo come implementare l’uso del protocollo 802.1x per le nostre reti wireless (ma analogo ragionamento può essere fatto per le reti cablate) utilizzando un server di autenticazione RADIUS creato con Windows Server 2016 ed EAP-TLS. EAP-TLS offre un processo di autenticazione molto sicuro, che sostituisce le semplici password con certificati digitali lato client e lato server, tramite l’utilizzo di una Certification Authority (PKI), creando di fatto quella che viene chiamata Mutual Authentication.

EAP-TLS con Mutual Authentication è attualmente l’implementazione più sicura per l’accesso alle reti wireless o alle reti cablate. I client autenticano il server RADIUS ed il server RADIUS chiede ai client di autenticarsi, richiedendo loro un certificato digitale.

Pertanto questo tipo di autenticazione, basato su certificati digitali sia computer che utente, permette l’accesso solo a chi possiede il certificato corretto e, nel caso la connessione avvenga tramite rete wireless, subito dopo l’autenticazione viene rilasciata una chiave WPA2 unica per utente (o per computer) ed unica per ogni sessione di connessione!

Per creare una infrastruttura di accesso che supporti questo protocollo affronteremo diversi passaggi:

  1. Creazione della Certification Authority e relativa configurazione
  2. Configurazione dei gruppi di accesso in Active Directory
  3. Creazione del server RADIUS di autenticazione utilizzando il ruolo Network Policy Server (NPS)
  4. Rilascio dei certificati per i client
  5. Configurazione degli Access Point per il supporto all’802.1x
  6. Configurazione dei client per il supporto all’EAP-TLS nelle reti wireless

Figura 1: Schema dell’infrastruttura necessaria all’implementazione del protocollo 802.1 con EAP-TLS

Creazione della Certification Authority (CA)

Per creare una certification authority si utilizza il ruolo Active Directory Certificate Services. Procedete all’installazione del ruolo in una macchina Windows Server.

Figura 2: Installazione del ruolo Active Directory Certificate Services in Windows Server 2016

Aggiungete il Role Services di Certification Authority e di Certification Authority Web Enrollment, che vi darà la possibilità di rilasciare i certificati per i vostri client anche attraverso un’interfaccia web.

Figura 3: Aggiunta dei Role Services per il ruolo di CA

Terminata l’installazione sarà necessario configurare la nostra Certification Authority. Cliccate quindi sul link Configure Active Directory Certificate Services in the destination computer.

Figura 4: Installazione del ruolo completata. È necessario però configurarlo

Dopo aver cliccato sul link si aprirà un wizard di configurazione. Configurare entrambi i Role Services che avete appena installato, come mostrato in figura:

Figura 5: Scelta dei Role Services da configurare

Il primo passaggio consiste nell’indicare se volete creare una CA di tipo Enterprise o Standalone. Nel nostro ambiente di dominio utilizzeremo una CA di tipo Enterprise.

Figura 6: Scelta del tipo di Certification Authority da installare

Poiché si tratta del primo server che installiamo, scegliamo di creare una Root CA. Per chi è poco pratico di Certification Authority e vuole conoscere nel dettaglio le differenze, consiglio la lettura dell’articolo Types of Certification Authorities

Figura 7: Scelta del tipo di Certification Authority da utilizzare

Per poter rilasciare i certificati, la vostra Root CA deve avere una chiave privata. Scegliete di creare una nuova Private Key e proseguite con il wizard.

Figura 8: Creazione della nuova chiave privata per la Root CA

La scelta del provider per la crittografia può avere un impatto determinante per la sicurezza, le performance e la compatibilità dei certificati rilasciati dalla vostra CA. Lasciate le impostazioni predefinite e proseguite nel wizard. Poiché le Cryptographic Options sono molto importanti, vi rimando alla lettura dell’articolo Cryptographic Options for CAs

Figura 9: Scelta del provider per la crittografia

Scegliete il nome della vostra CA, in modo che sia facilmente riconoscibile.

Figura 10: Scelta del nome della Certification Autority

Scegliete il periodo di validità del certificato della Root CA

Figura 11: Scelta del periodo di validità del certificato della Root CA

Specificate dove volete che venga salvato il database ed il file di log della CA

Figura 12: Percorsi di installazione del database del file di log della CA

Confermate tutte le configurazioni che avete inserito nel wizard e cliccate sul pulsante Configure:

Figura 13: Conferma delle configurazioni degli Active Directory Certificate Services

Dopo pochi istanti avrete creato e configurato la vostra Certification Authority!

Figura 14: Creazione della CA completata

Configurazione del Network Policy Service (NPS)

Per implementare la nostra infrastruttura basata su RADIUS e protocollo 802.1x ci serviremo di un server Windows in cui installeremo il ruolo di Network Policy Service (NPS). Indipendentemente dal metodo di autenticazione che utilizzerete per le vostre reti wireless (EAP-TLS, PEAP-TLS oppure PEAP-MS-CHAP v2), sarà obbligatorio installare sul Server NPS un certificato digitale che ne permetta il riconoscimento come server di autenticazione.

Per questo motivo sarà necessario distribuire tramite la nostra CA il certificato corretto, creato dal template RAS and IAS Server. Un certificate template viene utilizzato dalla CA per definire il formato ed il contenuto del certificato, per specificare quale utente o quale computer potranno richiederlo e per definirne tutte le caratteristiche e gli usi. Per maggiori informazioni potete leggere l’articolo Certificate Templates Overview

Aprite quindi la console della Certification Authority e dal nodo Certificate Template fate clic col tasto destro scegliendo New –> Certificate Template to Issue

Figura 15: Scelta del nuovo certificate template da distribuire

Per permettere al vostro server NPS di ottenere il certificato valido per poter essere utilizzato con RADIUS server, aggiungetelo in Active Directory al gruppo RAS and IAS Servers. Il gruppo infatti ha la possibilità, di default, di ottenere il certificato dal template RAS and IAS Server che abbiamo appena distribuito.

Figura 16:Aggiunta del server NPS01 al al gruppo RAS and IAS Servers in Active Directory

Riavviate il server NPS in modo tale che possa ottenere nel proprio token Kerberos il SID del gruppo RAS and IAS Servers e, dopo esservi autenticati, aprite una nuova console MMC, aggiungete lo snap-in dei Certificati Computer e procedete alla richiesta del certificato per il server NPS01, come mostrato in figura:

Figura 17: Richiesta di un nuovo certificato sul server NPS01

Se avrete effettuato correttamente tutte le operazioni, vedrete tra le opzioni disponibili la possibilità di richiedere il certificato dal template RAS and IAS Server.

Figura 18: Richiesta del certificato dal template RAS and IAS Server

Installazione del ruolo di Network Policy and Access Services sul server RADIUS

Procedete all’installazione del ruolo Network Policy and Access Services sul server NPS01, come mostrato nelle due figure:

Figura 19: Aggiunta del ruolo Network Policy and Access Services

Figura 20: Aggiunta del ruolo NPS completata

Lanciate la console del Network Policy Server e dalla scheda Getting Started scegliete dal menù a tendina che volete implementare lo scenario di RADIUS Server for 802.1x Wireless or Wired Connections. Cliccate sul link Configure 802.1x, come mostrato in figura:

Figura 21: Scelta dello lo scenario di RADIUS Server for 802.1x Wireless or Wired Connections nella scheda Getting Started

Partirà un wizard che vi guiderà nella configurazione. Nella prima schermata scegliete lo scenario. Nel nostro caso vogliamo rendere sicura una rete wireless.

Figura 22: Scelta del tipo di connessione per l’802.1x

Nella seconda schermata aggiungere il vostro RADIUS Client, cioè l’Access Point che invierà le richieste di connessione al vostro server NPS. Indicate anche uno Shared Secret, che dovrete successivamente inserire nel pannello di configurazione dell’Access Point.

Figura 23: Aggiunta del RADIUS Client (Wireless Access Point)

Figura 24: Potete aggiungere tutti i RADIUS Client che volete utilizzare nella vostra rete wireless sicura

Nella terza schermata scegliete il metodo di autenticazione. Nel nostro caso utilizzeremo i certificati digitali da installare sui pc client che vogliono accedere alla rete wireless (protetta con 802.1x ed EAP-TLS). Scegliete Microsoft: Smart Card or other certifcate e dal pulsante Configure assicuratevi di selezionare il certificato corretto per il vostro server NPS (cioè il certificato generato dal template RAS and IAS Server della vostra CA):

Figura 25: Scelta del metodo di autenticazione

Nella quarta schermata scegliete il gruppo di utenti o di computer di Active Directory che sarà autorizzato ad accedere alla rete wireless. Io ho aggiunto il gruppo Domain Computers

Figura 26: Scelta del gruppo di Active Directory che sarà autorizzato ad accedere alla rete wireless

Se utilizzate le VLAN nella vostra infrastruttura, sarà necessario effettuare ulteriori configurazioni. Maggiori informazioni sono contenute nell’articolo Configure Network Policies

Figura 27: Configurazioni relative alle VLAN

A questo punto il vostro wizard sarà terminato e verranno create una Connection Request Policy ed una Network Policy, entrambe chiamate Secure Wireless Connections.

Figura 28: Configurazione del server NPS completata

Configurazione dei computer client

Terminata la configurazione del server RADIUS è necessario configurare i client. Come prima operazione ci occuperemo di distribuire i certificati ai client che saranno autorizzati ad accedere alla rete wireless. Per poterlo fare ci serviremo di un template e delle group policy. Per poter distribuire i certificati utilizzando le GPO dovremo creare un template adatto a tale scopo.

Creazione del template per la distribuzione dei certificati ai computer del dominio

Dalla console Certificate Templates duplicate il template chiamato Computer per poterne generare uno nuovo, come mostrato in figura:

Figura 29: Duplicazione del template Computer

Dalle proprietà del nuovo template, provvedete a configurare un nuovo nome, ad indicare una durata per i certificati emessi e ad aggiungere alla scheda Security il gruppo di Computer di Active Directory che potrà richiederne i certificati che verranno da esso generati. Se volete utilizzare le GPO per la distribuzione dei certificati non dimenticatevi di selezionare l’opzione AutoEnroll, come mostrato nelle figure seguenti:

Figura 30: Definizione del nome del nuovo template certificati

Figura 31: Permesso di esportare la chiave privata

Figura 32: Aggiunta del gruppo di Active Directory autorizzato e selezione dell’AutoEnroll

Figura 33: Scelta delle informazioni da inserire nei certificati emessi

Terminata la creazione del template, collegatevi alla console di gestione della Certification Authority e distribuite il nuovo template certificato che avete creato, come mostrato nelle figure seguenti:

Figura 34: Aggiunta del nuovo certificate template alla CA

Figura 35: I due certificate template creati e distribuiti dalla nostra CA

Distribuzione del certificato computer utilizzando le Group Policy

Per distribuire il certificato Computer nel nostro dominio tramite le Group Policy vi basta creare una nuova GPO, collegarla alla OU dove si troveranno i computer autorizzati ad utilizzare la rete wireless e da Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies modificare la voce Certificate Services Client – Auto-Enrollment come mostrato in figura:

Figura 36: Auto-Enrollment dei certificati tramite GPO

Tutti i template certificato che saranno configurati per l’Auto-Enrollment per i gruppi di computer di Active Directory verranno distribuiti tramite questo metodo. Nessuno ovviamente vi vieta di installare manualmente i certificati sui vostri computer.

Effettuate un gpupdate sui vostri computer, magari utilizzando la PowerShell Invoke-GPUpdate e assicuratevi che abbiano ricevuto un certificato digitale

Figura 37: Certificati digitali emessi dalla CA e distribuiti tramite Group Policy

Figura 38: Certificato ricevuto dal client tramite la GPO

Configurazione degli Access Point per il supporto all’802.1x

La configurazione dei Wireless Access Point per il supporto all’802.1x varia da modello a modello. In genere trovate la configurazione sotto la voce Wireless
Security, scegliendo WPA2-Enterprise, WPA-Enterprise oppure Open with 802.1X. Nel mio caso ho scelto di utilizzare una chiave WPA2, che verrà data al computer solo dopo che sarà avvenuta l’autenticazione. Ho ovviamente dichiarato qual è il server RADIUS da utilizzare (NPS01) e lo Shared Secret che avevo precedentemente impostato nel wizard di creazione della Network Policy.

Figura 39: Configurazione del Wireless Access Point per l’utilizzo di WPA2-Enterprise

Configurazione dei client per la connessione alla rete wireless

Per configurare manualmente il client a connettersi alla rete protetta con il protocollo 802.1x è necessario effettuare delle operazioni. Spostatevi nel pannello di controllo del vostro client (Io sto usando Windows 10 versione 1709), andate in Network and Sharing Center e scegliete di configurare una connessione manuale verso una rete wireless, come mostrato in figura:

Figura 40: Connessione manuale ad una rete wireless in Windows 10

Inserite il nome della rete wireless a cui volete collegarvi e scegliete come Security type la voce WPA2-Enterprise

Figura 41: Scelta del nome della rete wireless e del metodo di autenticazione

Nel passaggio successivo cliccate sul pulsante Change Connection setting

Figura 42: Modifica delle opzioni della connessione

Spostatevi nella scheda Security e assicuratevi che nel Security type ci sia WPA2-Enterprise, nell’Encryption type ci sia AES e in Authentication method ci sia Microsoft: Smart Card or other certificate. Cliccate sul pulsante Settings per selezionare se volete utilizzare una Smart Card oppure un certificato presente sul computer e controllate di aver selezionato Use Simple Certificate Selection, nel caso sul vostro computer siano installati diversi certificati.

Figura 43: Modifica delle configurazioni di Security per la rete wireless

Cliccando sul pulsante Advanced settings potrete anche forzare come metodo di autenticazione la Computer Authentication, come mostrato in figura:

Figura 44: Opzioni avanzate della scheda Security

Confermate le impostazioni cliccando su OK e provate a collegarvi alla rete wireless. Se tutto sarà stato configurato correttamente vi riuscirete a collegare in pochissimi istanti.

È possibile verificare le configurazioni della rete wireless in qualsiasi momento accedendo al Network and Sharing Center, cliccando sul nome della rete wireless e scegliendo Wireless Properties dalla scheda Wi-Fi status, come mostrato in figura:

Figura 45: Modifica delle configurazioni della rete Wi-Fi

Configurazione dei client per la connessione alla rete wireless tramite Group Policy

Per semplificare la connessione alla rete wireless protetta con 802.1x è possibile anche utilizzare le Group Policy. In effetti la connessione manuale è alquanto impegnativa, non alla portata di tutti gli utenti ed è necessario collegarsi a tutti i pc client per poterla effettuare. Con le GPO, esattamente come abbiamo fatto con i certificati digitali per i computer, l’operazione diventa invece molto semplice.

Create una Group Policy e collegatela alla OU dove si trovano i computer che volete configurare. Spostatevi nel ramo Computer Configuration\Policies\Windows Settings\Security Settings\Wireless Network (IEEE 802.11) Policies e cliccando con il tasto destro scegliete Create a New Wireless Network Policy for Windows Vista and Later Releases, come mostrato in figura:

Figura 46: Creazione di una nuova Wireless Network Policy

Nella scheda che si aprirà, scegliete un nome per la vostra policy e cliccate su Add per aggiungere le configurazioni di una nuova rete wireless di tipo Infrastruttura, come mostrato in figura:

Figura 47: Aggiunta della nuova rete wireless

Nelle proprietà del nuovo profilo della rete wireless che volete aggiungere, inserite il nome dell’SSID della rete e cliccate sul pulsante Add

Figura 48: Aggiunta dell’SSID della rete wireless

Cliccate sulla scheda Security e configuratela con le informazioni visualizzate nella figura seguente:

Figura 49: Configurazione delle Security per la rete wireless

Completate la configurazione cliccando su OK.

Figura 50: Completamento della configurazione

Da questo momento il profilo verrà distribuito attraverso le group policy. Effettuate un gpupdate sui vostri computer client oppure utilizzate la PowerShell Invoke-GPUpdate dal domain controller e assicuratevi che i client possano accedere alla rete Wi-Fi protetta.

Conclusioni

La sicurezza è una condizione determinante per la protezione delle nostre infrastrutture e della nostra produzione. Filtrare l’accesso alle reti wireless o alle reti cablate servendosi del protocollo di autenticazione 802.1x con EAP-TLS certamente incrementa il lavoro da fare ma allo stesso tempo permette di essere sicuri che alle nostre reti possano accedere solo i computer autorizzati.

Migrazione di server fisici verso Microsoft Azure con Azure Site Recovery

Facebooktwittergoogle_plusredditlinkedin

Anche se ormai gran parte delle nostre infrastrutture sono virtualizzate, potrebbe capitare che in alcune aziende ci siano ancora delle macchine fisiche. Azure Site Recovery è una funzionalità offerta da Microsoft Azure per poter effettuare il disaster recovery dei nostri server fisici oppure per poterli definitivamente migrare verso il Cloud.

In questo articolo ci occuperemo della migrazione dei server fisici, ma se siete interessati alla migrazione di macchine virtuali vi invito a leggere l’articolo https://www.ictpower.it/sistemi-operativi/migrazione-di-macchine-virtuali-vmware-verso-microsoft-azure-con-azure-site-recovery.htm e l’articolo https://www.ictpower.it/sistemi-operativi/migrazione-delle-macchine-virtuali-vmware-verso-microsoft-azure-con-lutilizzo-di-azure-migrate.htm

Per eseguire la migrazione di un server fisico è necessario abilitare la replica del server ed eseguirne il failover in Azure.

Creazione del Recovery Service Vault

Il Recovery Service Vault è un servizio di Azure che ospita i dati e le configurazioni delle macchine virtuali. Per sapere nel dettaglio le caratteristiche del servizio potete leggere l’articolo https://docs.microsoft.com/it-it/azure/backup/backup-azure-recovery-services-vault-overview

Per creare un nuovo Recovery Service Vault è sufficiente aprire il portale di Azure e, facendo clic su New, cercare Backup and Site Recovery (OMS). Inserite quindi il nome del vostro Vault, il Resource group da utilizzare e la location dove volete che venga creato, come mostrato in figura:

Figura 1: Creazione di un nuovo Azure Recovery Vault

Terminata la creazione del Vault ne potete visualizzare le caratteristiche utilizzando la scheda Overview. Cliccate sulla scheda Site Recovery e iniziate la preparazione dell’infrastruttura, indicando cosa volete proteggere (Protection Goal). Nel mio caso, visto che voglio proteggere delle macchine fisiche on-premises, ho dichiarato che le macchine non sono virtualizzate, come indicato in figura:

Figura 2: Preparazione del Protection Goal

Nel secondo passaggio vi verrà chiesto di scaricare e testare il Deployment Planner, uno strumento gratuito che vi consente di profilare i vostri server fisici senza alcun impatto sulla produzione e di determinare i requisiti di larghezza di banda e spazio di archiviazione di Azure per le operazioni di replica e failover. Vi consiglio di leggere l’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-deployment-planner per conoscere le potenzialità di questo strumento.

Figura 3: Deployment Planning

Nel passaggio successivo dovrete selezionare il Configuration Server da utilizzare per la replica dei dati della vostra macchina fisica. Il Configuration Server funge da coordinatore tra i servizi di Site Recovery e l’infrastruttura locale (on-premises). Per i requisiti hardware e software del Configuration Server vi rimando all’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-manage-configuration-server. Provvedete a scaricare il Microsoft Azure Site Recovery Unified Setup (sono circa 1,5 GB) e ad installarlo nella vostra infrastruttura in una macchina Windows Server 2012 R2 (va bene anche la versione Evaluation e la macchina può essere anche in workgroup). Seguite tutte le istruzioni indicate nel blade del portale Azure, come mostrato in figura:

Figura 4: Aggiunta del Configuration Server e procedura di installazione

Installazione di Microsoft Azure Site Recovery Unified Setup

L’installazione del software che provvederà a creare il nostro Configuration Server è molto semplice ed è descritta nelle immagini che seguono. Assicuratevi di rispettare i Requisiti di dimensione per un server di configurazione e, dopo aver installato un server con Windows Server 2012 R2, dategli un IP statico e lanciate il setup di configurazione.

Figura 5: Prima schermata di installazione del Configuration Server

Figura 6: Inserimento della Site Recovery Registration Key che avete precedentemente scaricato dal portale di Azure

Figura 7: Verifica dei prerequisiti per l’installazione del Configuration Server

Figura 8: Inserimento della password di root e di svsystems user per il database MySQL

Figura 9: Indicazione che vogliamo proteggere server fisici e non macchine virtuali

Figura 10: Schermata riassuntiva del Setup del Configuration Server

Figura 11: Installazione del Configuration Server completata

A questo punto vi verrà chiesto di riavviare. Terminato il riavvio del server, subito dopo il login, vi apparirà il messaggio che vi indica quale sarà la passphrase da utilizzare per collegare l’agent del Mobility Service al vostro Configuration Server. Il Mobility Service è un servizio che si occupa di trasferire i file generati dal vostro server fisico verso il Configuration Server, che si occuperà poi di inoltrarli Ad Azure Site Recovery. Salvate la passphrase in un file di testo, perché potrebbe esservi richiesta se vorrete installare manualmente l’agent di Azure Site Recovery Mobility Service. In ogni caso è sempre possibile rigenerarla seguendo le indicazioni contenute nell’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-manage-configuration-server

Figura 12: Passpharse per il collegamento degli agent di Azure Site Recovery al Connection Server

Lanciate dal Desktop il collegamento al Cspsconfigtool, che vi darà la possibilità di aggiungere le credenziali per installare il Mobility Service sulle vostre macchine fisiche. Esistono diverse modalità di installazione di questo servizio e per approfondimenti vi rimando alla lettura dell’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-install-mob-svc

Figura 13: Aggiunta dell’account necessario all’installazione del Mobility Service sulle macchine fisiche

Terminata l’installazione del Configuration Server potete tornare nel portale Azure e dal blade dello Step 3 adesso sarà possibile selezionare il server appena installato, come mostrato in figura:

Figura 14: Selezione del Connection Server appena installato

Proseguite con lo Step 4, indicando la Subscription Azure da utilizzare, il Deployment model e assicurandovi di avere uno storage account ed una virtual network dove migrare i vostri server fisici on-premises.

Figura 15: Individuazione del target Azure dove replicare le macchine fisiche on-premises

L’ultimo passaggio di preparazione dell’infrastruttura consiste nella creazione di una Replication Policy da associare al vostro Configuration Server. La Replication Policy stabilisce la frequenza di replica delle vostre macchine fisiche on-premises. Maggiori informazioni sono disponibili al link https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-setup-replication-settings-vmware

Figura 16: Creazione di una Replication Policy da associare al Configuration Server

Verranno create ed associate due Replication Policy: una per il Failover ed un’altra per il Failback, come mostrato in figura:

Figura 17: Creazione ed associazione delle Replication Policy

Completate la preparazione della vostra infrastruttura facendo clic sul pulsante OK.

Figura 18: Completamento della preparazione dell’infrastruttura

Replica dei server fisici

Per dichiarare quali sono i server fisici da replicare con Azure Site Recovery fate clic sulla scheda Step 1: Replicate Application e configurate il Source con i parametri inseriti in figura:

Figura 19: Configurazione del Source per la Replica

Configurate nel secondo passaggio il Target del Recovery, in particolar modo indicando lo Storage Account dove verranno salvati i dati dei server fisici e la rete virtuale dove collegare le macchine replicate in Azure.

Figura 20: Configurazione del Target in Azure Site Recovery

Nel terzo passaggio indicate quali sono i server fisici da replicare in Azure, indicando un nome, l’indirizzo IP e il tipo di sistema operativo, come mostrato in figura:

Figura 21: Scelta dei server fisici da replicare in Azure

Figura 22: Aggiunta dei server fisici da replicare in Azure

Dichiarate quale sarà l’account (che avete precedentemente creato sul Configuration Server) da utilizzare per l’installazione dell’agent di Mobility Service sulle macchine fisiche, e quali dischi del server fisico volete escludere dalla replica, come mostrato in figura:

Figura 23: Configurazione delle proprietà della replica, scelta dell’account per l’installazione del Mobility Service

L’ultimo passaggio vi chiede di confermare quale Replication Policy utilizzare per la replica dei server fisici scelti.

Figura 24: Replication Policy da utilizzare per la replica dei server fisici scelti

Completate lo Step 1: Replicate Application cliccando sul pulsante Enable Replication.

Figura 25; Completamento dello Step 1: Replicate Application e abilitazione della replica

Lo Step 2: Manage Recovery Plans consiste nella creazione di un Recovery Plan (o piano di ripristino), che permette di stabilire quali macchine devono essere avviate ed in quale ordine. Aggiungetene un nuovo Recovery Plan e configuratelo con i parametri richiesti, come mostrato in figura:

Figura 26: Creazione di un nuovo Recovery Plan

A questo punto il Configuration Server installerà il Mobility Service sui server fisici che avete deciso di migrare e abiliterà la replica della macchina. Potete anche installare manualmente il Mobility Service usando la procedura indicata dall’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-install-mob-svc#install-mobility-service-manually-by-using-the-gui. Il file di installazione dell’agent si trova nel percorso C:\ProgramData\ASR\home\svsystems\pushinstallsvc\repository del Configuration Server.

Figura 27: Abilitazione della replica

Dopo circa 20 minuti dall’abilitazione, inizierà la replica dei dati verso Azure Site Recovery. Attendete che tutti i dati siano stati replicati visualizzando la scheda Replicated Items del vostro Azure Site Recovery Vault.

Figura 28: replica dei dati del server fisico completata

Failover Test

Per verificare che tutto funzioni correttamente è necessario testare il Failover della macchina virtuale presente in Azure. Cliccando su Replicated Items nel Recovery Service Vault dal portale di Azure, selezionate la macchina virtuale da testare e dal menù scegliete Test Failover, come mostrato in figura:

Figura 29: Test failover della macchina virtuale in Azure

Nel blade che vi si aprirà scegliete il Recovery Point da testare e la rete virtuale a cui collegare la VM di test. Cliccate su OK e attendete alcuni minuti fino a quando la VM di test non sarà stata creata.

Figura 30: Scelta del Recovery Point e della rete virtuale per il test del Failover

Collegatevi alla VM di test che è stata creata in Azure ed effettuate tutte le verifiche che ritenete necessarie per assicurarvi che la vostra macchina abbia tutti i dati e che funzioni correttamente. Al termine di tutte le procedure di controllo, sarà possibile effettuare il Cleanup test failover, che distruggerà la VM Azure di test che è stata creata.

Figura 31: Test failover Cleanup

Cliccando su Replicated Items nel Recovery Service Vault dal portale di Azure è possibile configurare le proprietà della macchina replicata. Potete scegliere il nome che verrà visualizzato in Azure, il Resource Group dove metterla, la dimensione della VM, la virtual network ed anche dargli un IP statico. Nel caso ne abbiate i diritti, attivate l’Hybrid Use Benefit, che vi permette un risparmio considerevole sulle licenze del sistema operativo. Maggiori informazioni sull’Hybrid Use benefit le trovate leggendo l’articolo https://docs.microsoft.com/it-it/azure/virtual-machines/windows/hybrid-use-benefit-licensing

Figura 32: Configurazione dei parametri della VM

Migrazione della macchina fisica in Azure

Per completare la migrazione della macchina fisica è necessario effettuare due passaggi: Failover e Complete Migration. Prima di eseguire un failover, eseguite sempre un failover di test per verificare che tutto funzioni come previsto. Maggiori dettagli sono disponibili leggendo l’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-failover

Figura 33: Failover della macchina fisica

Terminata la procedura di Failover ed dopo esservi accertati che tutto funzioni perfettamente, potete effettuare la procedura di Complete Migration. Il processo di migrazione viene completato, viene arrestata la replica della macchina virtuale e viene arrestata la fatturazione di Site Recovery per la macchina virtuale. D’ora in poi pagherete però l’esecuzione delle VM in Azure.

Figura 34: Completamento della migrazione

Conclusioni

Migrare i server fisici verso Azure è un’operazione molto semplice se viene effettuata con Azure Site Recovery. Per eseguire la migrazione di un server è sufficiente abilitare la replica del server ed eseguirne il failover in Azure. In questo modo l’intera macchina, con tutti i dati, viene migrata con un minimo downtime e senza impatto sull’infrastruttura e sulla produzione. Migrare i server fisici verso il Cloud non è mai stato così facile!

Migrazione di macchine virtuali VMware verso Microsoft Azure con Azure Site Recovery

Facebooktwittergoogle_plusredditlinkedin

Azure Site Recovery è un servizio che permette di proteggere le nostre macchine virtuali automatizzandone la replica verso il Cloud. Le macchine che possono essere protette da Azure Site Recovery (ASR) possono essere fisiche, macchine virtuali VMware oppure macchine virtuali Hyper-V. Il compito di ASR è quello di coordinare e gestire la replica continua dei dati e automatizzare il ripristino dei servizi nel caso di un’interruzione nel data center primario.

Abbiamo visto nel precedente articolo Migrazione delle macchine virtuali VMware verso Microsoft Azure con l’utilizzo di Azure Migrate come il servizio Azure Migrate semplifica la migrazione delle macchine virtuali VMware vSphere verso il cloud Microsoft Azure e può fornirvi assistenza attraverso tutti passaggi necessari per poterla effettuare, dall’assessment alla migrazione vera e propria. Compito di questo articolo sarà quello di mostrarvi il passaggio successivo al discovery e all’assessment, cioè la migrazione vera e propria delle VM.

Utilizzeremo quindi Azure Site Recovery per migrare le nostre macchine virtuali VMware verso Azure.

Figura 1: Architettura della migrazione da VMware ad Azure

Figura 2: Processo di replica di macchine VMware verso Azure

Creazione del Recovery Service Vault

Il Recovery Service Vault è un’entità di archiviazione di Azure che ospita i dati e le configurazioni delle macchine virtuali. Per maggiori informazioni potete leggere l’articolo https://docs.microsoft.com/it-it/azure/backup/backup-azure-recovery-services-vault-overview

Per creare un nuovo Recovery Service Vault è sufficiente aprire il portale di Azure e, facendo clic su New, cercare Backup and Site Recovery (OMS). Inserite quindi il nome del vostro Vault, il Resource group da utilizzare e la location dove volete che venga creato, come mostrato in figura:

Figura 3: Creazione di n nuovo Azure Recovery Service Vault

Al termine della creazione del Vault vi apparirà la schermata mostrata in figura:

Figura 4: Creazione del Vault completata

Cliccate su Site
Recovery e successivamente su Prepare Infrastructure, indicando come primo passaggio qual è il vostro Protection Goal. Nel mio caso, voglio proteggere alcune macchine virtuali VMware in Azure.

Figura 5: Creazione del Protection Goal

Nel secondo passaggio vi verrà chiesto di scaricare e testare il Deployment Planner, che verificherà che abbiate banda a sufficienza e quanto storage servirà per soddisfare le vostre necessità. Questo strumento consente di profilare le virtual machine VMware senza alcun impatto sulla produzione e di determinare i requisiti di larghezza di banda e archiviazione di Azure per operazioni di replica e failover. Vi consiglio di approfondire questo argomento leggendo l’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-deployment-planner

Figura 6: Deployment Planning

Installazione del Configuration Server

Il terzo passaggio consiste nel dichiarare quale Configuration Server volete utilizzare in Site Recovery. Il Configuration Server funge da coordinatore tra i servizi di Site Recovery e l’infrastruttura locale (on-premises). Per i requisiti hardware e software del Configuration Server vi rimando all’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-manage-configuration-server. Provvedete a scaricare la virtual appliance del server di configurazione (sono circa 16,5 GB) e ad importarla nella vostra infrastruttura VMware. Seguite tutte le istruzioni indicate nel blade del portale Azure:

Figura 7: Download della virtual appliance del Configuration Server

Figura 8: importazione della virtual appliance del Configuration Server

Dopo aver avviato il Configuration Server e configurato un account amministrativo, la virtual appliance verificherà la presenza della connessione Internet e vi chiederà di loggarvi con le credenziali per amministrare il Tenant Azure.

Figura 9: Connessione al Tenant di Azure

Dopo pochi minuti, il server si configurerà in Azure Active Directory e sarà necessario il riavvio della VM.

Figura 10: Configurazione del Server in Azure Active Directory

Dopo il riavvio potete loggarvi alla macchina ed in automatico vi si aprirà una pagina web per la gestione del Configuration Server. Nel caso non dovesse aprirsi, potete utilizzare il collegamento presente sul Desktop. Seguite le istruzioni riportate nella pagina web e configurate la scheda di rete che volete utilizzare per collegarvi ad Azure. Subito dopo vi verrà chiesto di selezionare il Recovery Services Vault da utilizzare.

Figura 11: Selezione del Recovery Services Vault

Il passaggio successivo consiste nell’installazione del software MySQL Community Server e VMware PowerCLI. Procedete all’installazione dei due software e confermate cliccando sul pulsante Continue.

Figura 12: Installazione del software aggiuntivo MySQL e PowerCLI

A questo punto l’appliance verifica che le proprie configurazioni siano corrette (spazio libero sul disco, IP statico, memoria del sistema, ecc.), come mostrato in figura:

Figura 13: Verifica della configurazione della virtual appliance

Per poter effettuare la connessione al vCenter è necessario fornire le credenziali di accesso, che dovrete aggiungere a questo punto della configurazione, come mostrato in figura:

Figura 14: Aggiunta delle credenziali di accesso al vCenter

Per installare Azure Site Recovery mobility service all’interno delle VM è necessario fornire delle credenziali amministrative. Il servizio mobility di Azure Site Recovery acquisisce i dati da una macchina virtuale VMware o da un server fisico e le inoltra al Process Server (che è installato nella stessa macchina del Configuration Server). Per maggior informazioni su questo servizio vi rimando alla lettura dell’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-install-mob-svc

Figura 15: Inserimento delle credenziali amministrative delle VM da proteggere

A questo punto non resta altro da fare che cliccare sul pulsante Finalize configuration. La configurazione dura alcuni minuti.

Figura 16: Configurazione del server completata

Completamento della preparazione dell’infrastruttura

Tornate nel pannello di Microsoft Azure Site Recovery e continuate la configurazione del Source. Vi appariranno sia il Configuration Server che avete appena installato e configurato, sia il vCenter che avete indicato nel wizard di configurazione, come mostrato in figura:

Figura 17: Selezione del Configuration Server e del vCenter

Il passaggio 4 consiste nel configurare il Target, cioè lo Storage Account dove volete replicare le VM e la Network a cui volete collegarle. È possibile anche creare di nuovi, se quelli già esistenti non soddisfano le vostre esigenze.

Figura 18: Preparazione del Target

Completate la parte di preparazione dell’infrastruttura creando una nuova Replication
policy e associandola al vostro Configuration Server. La Replication Policy stabilisce la frequenza di replica delle vostre VM on-premises. Maggiori informazioni sono disponibili al link https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-setup-replication-settings-vmware

Figura 19: Creazione ed associazione delle Replication Policy

Dopo pochi minuti, vedrete apparire nel portale di Azure le diverse policy che vengono create. Terminate la configurazione cliccando su OK.

Figura 20: Preparazione dell’infrastruttura completata

Abilitare la replica delle VM

Per abilitare la replica delle VM è sufficiente fare clic su Step1:
Replicate Application e seguire le indicazioni contenute nel blade che si aprirà. Configurate come prima cosa il Source Environment, completando le informazioni come mostrato in figura:

Figura 21: Definizione del Source Environment

Nel Target Setting for Recovery inserite la sottoscrizione da utilizzare, lo storage account in cui inserire le VM replicate, la virtual network da utilizzare e gli altri parametri richiesti.

Figura 22: Configurazione dei Target Settings per la replica delle VM

Selezionate nel passaggio 3 le macchine virtuali on-premises da replicare, come mostrato in figura:

Figura 23: Selezione delle VM da replicare

Indicate quali credenziali utilizzare per l’installazione degli agent di Azure e, se la VM ha più dischi, decidete quali dischi escludere dalla replica.

Figura 24: Configurazione delle proprietà delle VM

Terminate a questo punto l’abilitazione della replica configurando nell’ultimo passaggio la Replication Policy da utilizzare e scegliendo se volete raggruppare le macchine, in modo tale che vengano replicate tutte insieme, per assicurare la consistenza delle applicazioni nel caso in cui queste utilizzino macchine diverse. Nel mio caso ho una webapp che usa due webserver di frontend ed un database server di backend e quindi voglio che siano replicati insieme verso Azure.

Figura 25: Configurazione del Replication Settings e dei Replication Groups

Non vi resta a questo punto che monitorare la prima replica delle vostre VM on-premises. Selezionate il nodo Replicated Items dal portale di Azure e controllate lo stato di sincronizzazione delle macchine virtuali.

Figura 26: Monitoraggio delle repliche delle VM

Nel caso di errori cliccate sulla VM e cercate di individuarne i motivi. Nella schermata sotto è indicato uno dei probabili avvisi o errori che vi possono apparire:

Figura 27: Warning sulla Replica di una VM

Creazione del Recovery Plan

Il Recovery Plan (o piano di ripristino) permette di stabilire quali macchine devono essere avviate ed in quale ordine. Cliccate su Step 2: Recovery Plans e aggiungetene uno nuovo, configurandolo con i parametri richiesti:

Figura 28: Creazione di un Recovery Plan

Una volta che il Recovery Plan è stato creato potete personalizzarlo a vostro piacimento, raggruppando le macchine virtuali da avviare insieme, come mostrato in figura:

Figura 29: Personalizzazione del Recovery Plan

Test del Failover

Una volta che avete terminato la replica di tutte le macchine virtuali potrete provare a testare il Failover delle VM in Azure. Cliccando su Overview nel Recovery Service Vault dal portale di Azure, potrete avere un’idea di come sia configurata la vostra infrastruttura e informazioni sullo stato di replica delle vostre VM.

Figura 30: Overview della vostra infrastruttura di replica in Azure

Cliccate sul vostro Recovery Plan e successivamente sul pulsante Test failover. Dal blade che vi si aprirà scegliete il Recovery Point da testare e scegliete la virtual network Azure a cui collegare le VM di test che verranno create. Vi consiglio di utilizzare una VNET di test, in modo tale da non avere problemi.

Figura 31: Failover Test del Recovery Plan

A questo punto verranno create delle macchine di test nel vostro Tenant Azure. Collegatevi alle macchine in Desktop remoto e verificate che tutto funzioni correttamente.

Figura 32: Failover test avviato per il Recovery Plan scelto

Figura 33: Site recovery job e dettagli delle operazioni

Al termine di tutte le procedure di controllo, sarà possibile effettuare il Cleanup test failover, che distruggerà tutte le VM Azure di test che sono state create.

Figura 34: Lancio del Cleanup test failover

Figura 35: Dettaglio delle operazioni del Cleanup test failover

A questo punto avete completato tutte le operazioni per la protezione delle VM on-premises in Azure. Con questo tipo di configurazione Azure è diventato il vostro sito di Disaster Recovery e lo potrete utilizzare nel caso non sia possibile utilizzare il Datacenter principale.

Migrazione

Se il vostro obiettivo è invece migrare le macchine VMware on-premises, allora basterà dichiarare il Failover e lasciare che le macchine vengano avviate in Azure. Prima di effettuare questa operazione assicuratevi che ogni macchina sia configurata con le dimensioni corrette, con la VNET corretta e, nel caso ne abbiate i diritti, attivate l’Hybrid Use Benefit, che vi permette un risparmio considerevole sulle licenze del sistema operativo.

Figura 36: Configurazione di ogni singola macchina virtuale

Cliccate sul vostro Recovery
Plan e dichiarate il Failover, come mostrato in figura:

Figura 37: Failover dei Recovery Plan

Scegliete il Recovery Point da utilizzare per il Failover e, nel caso, selezionate la casella per spegnere le macchine virtuali on-premise prima del Failover, in modo tale da avere una situazione consistente. Se scegliete Latest (lowest RPO) verrà scelto il Recovery Point più recente e verranno sincronizzate le ultime modifiche apportate alla VM on-premises.

Figura 38: Scelta del Recovery Point del Failover

Il processo di Failover creerà le nuove macchine virtuali nel vostro tenant Azure, secondo le caratteristiche che avete definito precedentemente.

Figura 39: Esecuzione del Failover e dettaglio delle operazioni

Terminate tutte le operazioni, le macchine virtuali saranno create nel vostro Tenant Azure e saranno visibili nel Resource Group di destinazione che avete scelto.

Figura 40: Macchine virtuali accese nel Resource Group di Azure di destinazione

Effettuate l’ultima operazione, che consiste nell’eseguire, per ogni singola VM, il Complete
Migration. Nella finestra che vi si aprirà confermate con OK. Dopo alcuni minuti la migrazione sarà terminata!

Figura 41: Esecuzione del comando Complete migration su ogni VM

Figura 42: Conferma della migrazione per ogni singola VM da migrare ad Azure

NOTA: la macchina virtuale in Azure avrà un indirizzo IP dinamico nella VNET che avete scelto. Assicuratevi, nel caso ne abbiate bisogno, di mettere un indirizzo IP statico. Per maggiori informazioni sulla procedura corretta vi rimando all’articolo https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface-addresses

Per completare la migrazione potete cancellare il Recovery Service Vault. Seguire tutte le indicazioni contenute nell’articolo https://docs.microsoft.com/en-us/azure/site-recovery/delete-vault

Figura 43: Cancellazione dell’Azure Recovery Vault

Conclusioni

Azure Site Recovery è sicuramente uno strumento potente per effettuare il Disaster Recovery delle nostre macchine virtuali VMware o dei nostri server fisici e può essere facilmente utilizzato per poter effettuare una migrazione verso il cloud Azure. Microsoft si è impegnata molto per fornire alle aziende strumenti utili a valutare la migrazione delle VM on-premises con lo strumento Azure Migrate https://www.ictpower.it/sistemi-operativi/migrazione-delle-macchine-virtuali-vmware-verso-microsoft-azure-con-lutilizzo-di-azure-migrate.htm e offrire la possibilità di migrarle facilmente con Azure Site Recovery.

Migrazione delle macchine virtuali VMware verso Microsoft Azure con l’utilizzo di Azure Migrate

Facebooktwittergoogle_plusredditlinkedin

Pochi mesi fa è stato annunciato un nuovo servizio chiamato Azure Migrate https://azure.microsoft.com/it-it/blog/announcing-azure-migrate/

Obiettivo di questo servizio è semplificare la migrazione delle macchine virtuali VMware vSphere verso il cloud di Microsoft Azure e di fornirvi assistenza attraverso tutti passaggi necessari per poterla effettuare, dall’assessment alla migrazione vera e propria. Dopo aver individuato le informazioni sulle macchine virtuali VMware ospitate nel Datacenter locale (utilizzo di CPU e memoria, dimensioni del disco e connessione alle diverse reti), sarà possibile ottenere consigli sul corretto dimensionamento delle risorse cloud (come ad esempio la dimensione della VM ospitata in Azure), in modo tale da avere un maggior controllo sui costi di migrazione in base ad un utilizzo efficiente della VM in Azure.

Dopo aver eseguito una valutazione della propria infrastruttura on-premises con Azure Migrate, sarà possibile quindi iniziare la migrazione delle macchine virtuali locali verso Azure, utilizzando i servizi messi a disposizione da Microsoft, come ad esempio Azure Site Recovery e Azure Database Migration Service.

Azure Migrate consente quindi di:

  • Valutare l’idoneità per Azure: valutare se le VM on-premises possono essere eseguite in Azure.
  • Ottenere informazioni sulle dimensioni consigliate: ottenere informazioni per dimensionare correttamente le VM in Azure in base alla cronologia delle prestazioni delle macchine virtuali on-premises.
  • Stimare i costi mensili: ottenere una stima dei costi per l’esecuzione delle VM in Azure.
  • Facilitare la migrazione: visualizzare le dipendenze delle VM on-premises per creare gruppi di VM di cui eseguire la migrazione insieme.

Figura 1: Principio di funzionamento di Azure Migrate

Per cominciare a familiarizzare con questo nuovo strumento potete collegarvi al portale di Azure e cercare Azure Migrate. Attualmente la funzionalità è in Preview.

Figura 2: Ricerca della funzionalità di Azure Migrate (Preview) nel portale di Azure

Cliccate sul pulsante Create e iniziate un nuovo progetto di migrazione, inserendo tutti i parametri richiesti, come mostrato in figura. Attualmente è possibile creare un progetto Azure Migrate solo nell’area Stati Uniti centro-occidentali (West Central US). Ciò non impedisce, tuttavia, di pianificare una migrazione per una diversa regione di Azure di destinazione e quindi ad esempio eseguire le macchine virtuali in West Europe. La località del progetto di migrazione viene usata solo per l’archiviazione dei metadati individuati nell’ambiente on-premises e che serviranno successivamente a definire il progetto.

Figura 3: Creazione del nuovo progetto di migrazione

La prima operazione da effettuare consiste nel “Discover & Assess“, che si compone essenzialmente di due fasi: Il primo step consiste nell’individuare quali sono le macchine virtuali VMware presenti nella propria infrastruttura, mentre il secondo step consiste nel creare un assessment. È possibile individuare fino a 1000 VM in una singola individuazione (discover) e fino a 1500 VM in un singolo progetto. È inoltre possibile valutare fino a 400 VM in una singola valutazione (assess).

Figura 4: Discover e Assess – Schermata iniziale per l’avvio delle due fasi

Figura 5: Prima fase – Individuazione dell’ambiente on-premises e delle VM VMware

Dopo aver cliccato sul pulsante “Discover machines” vi verrà presentata una pagina con 4 passaggi da effettuare. Azure Migrate usa una VM da far girare on-premises (una appliance) con a bordo un agente che si occuperà di raccogliere ed individuare i computer on-premises. Per utilizzare l’appliance, scaricate il file di installazione in formato Open Virtualization Appliance (con estensione OVA) e importatelo come macchina virtuale nel server vCenter locale.

Figura 6: Download della virtual appliance di Azure Migrate

Figura 7: importazione della virtual appliance di Azure Migrate nel vCenter locale

Figura 8: Schermata finale prima dell’importazione dell’appliance di Azure Migrate

  1. Terminata l’importazione dell’appliance, procedete al suo avvio e configuratela. L’appliance è una macchina virtuale con Windows Server 2012 R2 e sul desktop troverete un link chiamato “Run Collector” che farà partire l’agente di raccolta che si occuperà dell’individuazione delle VM on-premises. L’agente di raccolta raccoglie i metadati delle VM usando cmdlet di VMware PowerCLI. L’individuazione non comporta installazioni nelle VM o negli host VMware e i metadati raccolti includono informazioni sulle VM come numero di core, quantità di memoria, numero di dischi, dimensioni dei dischi e schede di rete. Vengono anche raccolti dati sulle prestazioni delle VM, tra cui utilizzo di CPU e memoria, operazioni di I/O al secondo e velocità effettiva (in MBps) dei dischi e output di rete (in MBps).

Figura 9: Installazione dei prerequisiti del Collector di Azure Migrate

Figura 10: Connessione al vCenter da parte del Collector di Azure Migrate

Dopo aver terminato l’installazione dei prerequisiti ed esservi connessi al VMware vCenter on-premises, inserite il Project ID e la Project Key che sono stati generati durante la creazione del progetto di Azure Migrate e che sono disponibili sul portale di Azure, come mostrato in figura:

Figura 11: Inserimento dei dati del progetto di migrazione

A questo punto comincerà l’individuazione delle vostre macchine virtuali, che potrebbe durare qualche minuto (dipende dal numero delle VM che avete on-premises).

Figura 12: Raccolta delle informazioni da parte del Collector di Azure Migrate

Dopo alcuni minuti, potrete tornare nel portale Azure e visualizzare un messaggio che vi avvisa che l’individuazione delle VM è terminata e che è possibile passare alla seconda fase, quella dell’assessment.

Figura 13: Discover delle VM on-premises completato

Il processo di individuazione può essere ripetuto anche diverse volte, cliccando su Discover
machines e seguendo le istruzioni riportate nel blade, come mostrato in figura:

Figura 14: Ripetizione del processo di individuazione delle VM on-premises

Creazione dell’assessment

Un assessment è un gruppo di macchine virtuali che devono essere migrate insieme. Nel mio caso ho bisogno di migrare una WebApp composta da un database di backend e da due web server di frontend. Dal portale di Azure cliccate quindi sul vostro progetto di migrazione e sul pulsante “Create assessment“. Nella schermata che vi si aprirà date un nome al gruppo di macchine da migrate (nel mio caso l’ho chiamato WebApp) e selezionate le VM da migrare, come mostrato in figura:

Figura 15: Creazione del gruppo di macchine da migrare (assessment)

Cliccando sull’assessment appena creato potrete avere una Overview delle informazioni che sono state raccolte dall’appliance di Azure Migrate. In particolar modo potrete vedere tutte le macchine virtuali che possono essere migrate ad Azure senza problemi ed il loro costo mensile stimato, sia per il computing che per lo storage. Facendo clic su Edit properties avrete anche la possibilità di modificare alcuni parametri, come ad esempio la Region di destinazione ed il tipo di valuta.

Figura 16: Overview dell’assessment

Nella Azure readiness potrete anche avere un dettaglio delle diverse VM da migrare con la dimensione che dovranno avere le rispettive macchine Azure.

Figura 17: Azure readiness delle VM on-premises

Per sapere qual è il modo migliore di migrare le vostre macchine virtuali (che apparirebbe nella colonna SUGGESTED TOOL) è necessario installare un agente nelle VM on-premises. L’agente vi aiuterà anche a valutare le diverse dipendenze tra le VM. Per maggiori informazioni fate riferimento alla pagina https://docs.microsoft.com/it-it/azure/migrate/how-to-create-group-machine-dependencies#prepare-machines-for-dependency-mapping

Figura 18: dettaglio dei costi per ogni singola VM

È anche possibile esportare l’assessment in formato Excel, per avere una reportistica dettagliata, come mostrato in figura:

Figura 19: Esportazione dell’assessment in formato Excel

Migrazione delle macchine virtuali VMware verso Azure

Adesso che avete completato l’individuazione delle VM on-premises e avete valutato il vostro ambiente, siete pronti per migrare verso il Cloud. Per poterlo fare potete utilizzare lo strumento Azure Site Recovery e seguire i passaggi descritti nell’articolo https://www.ictpower.it/guide/protezione-delle-macchine-virtuali-vmware-e-dei-server-fisici-con-azure-site-recovery.htm

Conclusioni

Il servizio Azure Migrate vi permette di individuare le macchine virtuali VMware idonee per la migrazione verso il cloud Azure e vi fornisce degli strumenti di analisi che vi daranno anche la possibilità di stimare i costi di mantenimento della vostra infrastruttura. Se volete esercitarvi con questo nuovo strumento, che per il momento è ancora in Preview, potete utilizzare questo Laboratorio pratico su Azure Migrate. Interessante è anche il video Migrating to Azure using Azure Migrate and Azure Site Recovery – BRK3243 , registrato durante la conferenza Ignite 2017.

Gestire l’accesso alle macchine virtuali in Microsoft Azure con la funzionalità JIT (Just-in-Time)

Facebooktwittergoogle_plusredditlinkedin

Mai come in questo periodo il tema della sicurezza informatica sta monopolizzando gli articoli e gli avvisi che ci arrivano dai diversi vendor hardware e software e gli attacchi si stanno non solo evolvendo come complessità, ma soprattutto stanno aumentando. Difendersi dagli attacchi è sempre impegnativo e non bisogna mai sottovalutare nulla, ma io sono dell’idea che prevenire sia meglio che curare e quindi nell’approccio alla sicurezza la cosa più importante è ridurre la superficie di attacco.

Avevo già parlato in un precedente articolo di una funzionalità di sicurezza introdotta in Windows Server 2016 e chiamata Just Enough Administration (JEA), che ha come scopo quello di aumentare la sicurezza nella gestione e nella delega dei privilegi in Windows Server. In questo articolo invece vi parlo di una funzionalità di Microsoft Azure, attualmente in PREVIEW e che si chiama Just in time VM Access, che può essere usata per bloccare il traffico in ingresso verso le porte dei protocolli di amministrazione (RDP per Windows oppure SSH per Linux) delle macchine virtuali di Azure, riducendo l’esposizione agli attacchi.

Figura 1: Attivazione della funzionalità di Just in time VM Access in Azure Security Center

Questo tipo di funzionalità non è pero disponibile gratuitamente e fa parte del piano Standard del Centro Sicurezza di Azure (Security Center), che offre la gestione unificata della sicurezza e la protezione avanzata dalle minacce per tutti i workload in esecuzione in Azure, in locale nella propria rete aziendale e in altri cloud. È possibile aggiornare tutta la sottoscrizione di Azure al piano Standard, che viene ereditato da tutte le risorse all’interno della sottoscrizione oppure è possibile aggiornare a un solo gruppo specifico di risorse (Resource Group). Per poterlo fare è sufficiente modificare la Security Policy del Security Center come mostrato in figura:

Figura 2: Modifica delle Security Policy e del Pricing Tier in Azure Security Center

Nel momento in cui attivate la funzionalità di Just in time VM Access, Il Security Center protegge il traffico in ingresso verso le macchine virtuali creando una regola nel Network Security Group (NSG) utilizzato dalle schede di rete della VM, che blocca le porte di gestione. Quando avrete necessità di accedere in modalità amministrativa alla VM, vi basterà richiedere l’accesso e indicare per quanto tempo necessitate di amministrare la macchina. Il Security Center provvederà a modificare le regole sul Netowrk Security Group consentendo il traffico in entrata verso le porte di gestione per il periodo di tempo specificato. Al termine di questo periodo, il Security Center ripristinerà le regole preesistenti.

Attivazione del Just in time VM Access

La prima volta che vorrete usare la funzionalità di Just in time VM Access vi verrà chiesto di attivare (in prova gratuita per i primi 60 giorni) il piano Standard, come mostrato in figura:

Figura 3: Attivazione del Piano Standard per Azure Security Center

Una volta che avrete attivato il piano Standard potrete tornare nella console del Just in time VM access e visualizzare le informazioni per ogni macchina virtuale, divise in 3 categorie:

  • Configured – Macchine virtuali che sono state configurate per supportare l’accesso Just-In-Time. I dati visualizzati sono relativi all’ultima settimana e includono, per ogni macchina virtuale, il numero di richieste approvate, la data dell’ultimo accesso e l’ultimo utente che ha effettuato l’accesso.
  • Recommended – Macchine virtuali che possono supportare l’accesso Just-In-Time, ma che non sono state ancora configurate.
  • No Recommandation – I motivi per cui una macchina virtuale può risultare non raccomandata sono:
    • Network Security Group mancante – La soluzione Just-In-Time richiede la presenza di un gruppo di sicurezza di rete.
    • Macchina virtuale classica – L’accesso Just-in-Time alle macchine virtuali attualmente supporta solo VM distribuite tramite Azure Resource Manager.
    • Endpoint Protection non installato – Il Centro sicurezza di Azure monitora lo stato della protezione antimalware e verifica che nella VM sia installato Endpoint Protection

Figura 4: Macchine virtuali su cui non può essere abilitata il Just in time VM access

Per abilitare la funzionalità è sufficiente selezionare la VM, cliccare sul pulsante Enable JIT on VM e nel blade che si apre cliccare su Save, come mostrato in figura:

Figura 5: Abilitazione della funzionalità di Just in time VM access

Richiedere l’accesso a una macchina virtuale

Per richiedere l’accesso ad una macchina virtuale è sufficiente selezionare la VM nella scheda Configured e cliccare sul pulsante Request Access. Nel blade che verrà aperto definite quale porta aprire, a quali indirizzi IP permettere la connessione, per quanto tempo permettere la connessione. Al termine della scelta dei criteri cliccate sul pulsante Open Ports, come mostrato in figura:

Figura 6: richiesta di apertura delle porte di amministrazione

In qualsiasi momento potete modificare la configurazione dell’accesso JIT alla VM, visualizzarne le proprietà e i log delle attività, come mostrato in figura:

Figura 7: Modifica della configurazione dell’accesso JIT alla VM

È sempre possibile aggiungere altre porte alla configurazione dell’accesso JIT alla VM e per ognuna di loro stabilirne anche la durata, che in ogni caso non potrà superare le 24 ore.

Figura 8: Aggiunta di una nuova regola alla configurazione dell’accesso JIT alla VM

Visualizzando la scheda Networking della macchina virtuale potrete visualizzare quali regole sono state applicate al Network Security Group della VM. Sono state inserire le regole di SecurityCenter-JIT che hanno una priorità più bassa e quindi hanno precedenza rispetto alle altre regole create.

Figura 9: Regole di SecurityCenter-JIT applicate al Network Security Group della VM

Conclusioni

La semplicità con cui è possibile configurare l’accesso Just in Time alle VM di Azure permette di poter ridurre drasticamente la superfice d’attacco verso le VM esposte, come ad esempio le Jump Box con IP pubblico, ed impedisce di fatto tutti gli attacchi verso il Desktop Remoto o verso Secure Shell che cercano di indovinare le credenziali amministrative. Un modo semplice ed efficace per proteggerci e per mitigare gli attacchi di forza bruta aprendo le porte solo durante la connessione per eseguire attività di gestione o manutenzione sulle VM.

Creare un Guarded Fabric con l’Admin-trusted attestation e le Shielded VMs in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Introduzione

Spesso nei Datacenter il ruolo dei diversi amministratori è ben definito e le mansioni sono ben separate: ci sono gli Storage Administrator, i Network Administrator, i Backup Operator e i Virtualiztion-host Administrator. Ognuno di loro ha privilegi limitati quando lavora sui diversi server fisici. Nelle infrastrutture virtuali, in contrasto con quanto appena affermato, può capitare che spesso questi amministratori abbiano privilegi maggiori rispetto a quelli che gli dovrebbero essere permessi.

Scopo di questo articolo è mostrarvi come rendere più sicura l’infrastruttura virtuale e come creare un Guarded Fabric, cioè l’insieme degli host di virtualizzazione Hyper-V ed il loro Host Guardian Service (HGS), che può gestire e far girare macchine virtuali protette (Shielded VM)

Guarded Fabric

Con il rilascio di Windows Server 2016, Microsoft ha introdotto un nuovo modello di sicurezza per la virtualizzazione che è progettato per proteggere gli Hosts e le loro VM. Poiché una VM è un insieme di file, è necessario proteggerla da tutti quegli attacchi che possono avvenire via rete, sullo storage o mentre vengono salvate durante il backup. Questa è una necessità che prescinde dalla piattaforma di virtualizzazione utilizzata, sia che si tratti di Hyper-V, VMware o altre tecnologie di virtualizzazione. Se una macchina dovesse essere spostata fuori dall’azienda (sia accidentalmente che intenzionalmente), questa VM potrebbe essere eseguita in qualsiasi altro sistema non aziendale e quindi si potrebbe avere accesso ai dati contenuti nella VM.

Per proteggersi dalla possibilità che l’infrastruttura (Fabric) possa essere compromessa e si possa accedere ai file delle VM, Windows Server 2016 ha introdotto le Hyper-V Shielded VM, macchine virtuali (Generation 2) che hanno un virtual TPM (Trusted Platform Module), cifrate utilizzando Bitlocker Drive Encryption e che possono essere eseguite solo su alcuni Host di virtualizzazione approvati all’interno del Fabric.

Un Guarded Fabric è formato da un Host Guardian Service (HGS), che generalmente è un cluster a tre nodi, uno o più guarded hosts e una serie di Shielded VM. Vi consiglio prima di cominciare illaboratorio di dare un’occhiata all’articolo https://blogs.technet.microsoft.com/datacentersecurity/2017/03/14/shielded-vms-a-conceptual-review-of-the-components-and-steps-necessary-to-deploy-a-guarded-fabric/

Attestation Modes nei Guarded Fabric

L’Host Guardian Service (HGS) supporta due tipi differenti di deployment (attestation modes) di un guarded fabric: TPM-Trusted Attestation (Hardware based) e Admin-Trusted Attestation (Active Directory based). Il TPM-Trusted Attestation è la modalità che offre la protezione migliore, ma richiede che gli Host Hyper-V utilizzino UEFI 2.3.1 e TPM 2.0. L’Admin-Trusted Attestation è pensato per supportare gli Host che non hanno un TPM 2.0. I Guarded Hosts che fanno girare le Shielded VM vengono approvati dall’HGS in base alla loro appartenenza a un gruppo di sicurezza di Active Directory.

Figura 1: Infrastruttura Guarded Fabric che utilizza Admin-Trusted Attestation (Active Directory based)

Host Guardian Service (HGS)

Il nuovo ruolo server HGS introdotto in Windows Server 2016 è composto dall’Attestation Service e dai Key Protection Services, che permettono ad Hyper v di far girare le Shielded VM. L’Attestation Service verifica l’identità e la configurazione dell’Host Hyper-V (Guarded Host) e il Key Protection Services (KPS) genera la transport key che è necessaria a sbloccare e a far girare le shielded VM. Le Shielded VM proteggono i dati delle macchine virtuali supportando il Virtual TPM che permette di abilitare Bitlocker Encryption sui dischi delle macchine virtuali.

Figura 2: Funzionamento dell’Host Guardian Service

Per i requisiti hardware e software di un server HGS si faccia riferimento all’articolo https://docs.microsoft.com/en-us/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-prepare-for-hgs

Installazione del Server HGS

In questo articolo verrà mostrato come configurare un server HGS per supportare Admin-Trusted attestation.

Per installare il Server HGS (che nel mio caso è una macchina chiamata LON-SRV1 che è in workgroup) è sufficiente lanciare con privilegi elevati la cmdlet

Install-WindowsFeature –Name HostGuardianServiceRole –IncludeManagementTools –Restart

Figura 3: Schema di funzionamento del laboratorio

Dopo il riavvio, aprite un command prompt di PowerShell con privilegi elevati e digitate i seguenti comandi:

$adminPassword ConvertTo-SecureString -AsPlainText ‘Pa55w.rd’ –Force

Install-HgsServer -HgsDomainName ‘contoso.com’ -SafeModeAdministratorPassword $adminPassword –Restart

Verrà a questo punto installato l’Host Guardian Service, che prevede l’installazione di una nuova foresta chiamata Contoso.com.

Figura 4: Installazione dell’Host Guardian Service, con relativa creazione del dominio

Figura 5: Installazione del Server HGS completata

NOTA: In ambiente di produzione, L’HGS dovrebbe essere installato in un cluster per assicurarsi che l’accesso alle Shielded VM sia mantenuto anche nel caso in cui uno dei nodi HGS non sia disponibile. Pertanto installate il ruolo Server HGS sul primo nodo, che sarà anche il domain controller del dominio HGS di gestione, e successivamente aggiungete gli altri nodi per dominio HGS esistente. Per aggiungere gli altri nodi al Cluster HGS seguite le istruzioni contenute nell’articolo https://docs.microsoft.com/en-us/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-configure-additional-hgs-nodes

Guardian

Guardian è il termine che viene utilizzato per descrivere la copia di certificati (uno per il signing, l’altro per l’encryption) che protegge la chiave di cifratura simmetrica che viene utilzizata per cifrare il virtual TPM (vTMP) delle Shielded VM. I Guardians contengono solo le chiavi pubbliche, mentre le chiavi private vengono conservate dall’Host Guardian Service (HGS).

Dopo aver nuovamente riavviato il Server HGS, loggatevi come amministratore di dominio (contoso\administrator). Avete bisogno di due certificati per poter inizializzare il vostro server HGS: uno per la firma ed uno per la crittografia. Come prima operazione dovrete creare un certificato (signing.contoso.com) che utilizzerete per la firma. Da un prompt di PowerShell con privilegi elevati digitate i seguenti comandi:

md c:\HGS

$certificatePassword ConvertTo-SecureString -AsPlainText ‘Pa55w.rd’ –Force

$signingCert New-SelfSignedCertificate -DnsName “signing.contoso.com”

Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath ‘C:\HGS\signingCert.pfx’

Figura 6: Creazione ed esportazione del certificato per la firma completata

A questo punto create ed esportate il certificato che userete per la crittografia (encryption.contoso.com) utilizzando i seguenti comandi:

$encryptionCert New-SelfSignedCertificate -DnsName “encryption.contoso.com”

Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath ‘C:\HGS\encryptionCert.pfx

Figura 7: Creazione ed esportazione del certificato per la cifratura completata

Per visualizzare i certificati appena creati potete utilizzare il comando certutil -viewstore “Shielded VM Local Certificates” oppure utilizzare una MMC vuota e lo snap-in dei certificati Computer, come mostrato in figura:

Figura 8: Visualizzazione dei certificati creati utilizzando il comando certutil

Figura 9 Visualizzazione dei certificati creati utilizzando lo snap-in dei certificati Computer

Inizializzazione dell’Host Guardian Service (HGS)

Il passaggio successivo consiste nell’inizializzazione del server HGS. Inizializzate il server HGS con la modalità Admin-Trusted attestation usando il comando PowerShell

Initialize-HGSServer -HgsServiceName ‘hgs’ -SigningCertificatePath ‘C:\HGS\signingCert.pfx’ -SigningCertificatePassword $certificatePassword -EncryptionCertificatePath ‘C:\HGS\encryptionCert.pfx’ -EncryptionCertificatePassword $certificatePassword -TrustActiveDirectory

Figura 10: Inizializzazione del server HGS con la modalità Admin-trusted attestation

Terminata l’operazione di inizializzazione siete pronti ad utilizzare il vostro Server HGS! Per maggiori informazioni vi rimando all’articolo https://docs.microsoft.com/en-us/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-initialize-hgs-ad-mode-default

Per verificare che tutto sia stato configurato correttamente potete lanciare il comando PowerShell Get-HgsTrace -RunDiagnostics

Figura 11: Inizializzazione del server HGS completata correttamente

Creazione del trust tra il dominio HGS ed il dominio in cui sono attestati gli Host Hyper-V

Per poter utilizzare la Admin-Trusted attestation (Active directory based) è necessario creare un trust unidirezionale tra il dominio del Fabric (nel mio caso Adatum.com) ed il dominio HGS (nel mio caso Contoso.com).

Figura 12: Trust unidirezionale tra il dominio del Fabric (Adatum.com) ed il dominio HGS (Contoso.com)

Configurate il DNS sul LON-SVR1 in modo tale da creare un conditional forwarder che possa risolvere il dominio adatum.com e create un trust di foresta unidirezionale dal dominio HGS verso il dominio fabric utilizzando i due comandi:

Add-DnsServerConditionalForwarderZone -Name “adatum.com” -ReplicationScope “Forest” -MasterServers 172.16.0.10

netdom trust contoso.com /domain:adatum.com /userD:adatum.com\Administrator /passwordD:Pa55w.rd /add

Figura 13: Crazione del trust tra il dominio del fabric ed il dominio HGS

Configurazione del Fabric Domain Server

Aggiungete sul domain controller del fabric (adatum.com) un conditional forwarder che possa risolvere il dominio contoso.com utilizzando il comando PowerShell

Add-DnsServerConditionalForwarderZone -Name ‘contoso.com’ -ReplicationScope “Forest” -MasterServers 172.16.0.11

Create nel dominio Adatum.com un nuovo gruppo chiamato HGSHosts e inserite nel gruppo gli Host di virtualizzazione Hyper-V che ospiteranno le Shielded VM (nel mio caso ho aggiunto LON-HOST1).

Figura 14: Creazione del gruppo che conterrà gli Host di virtualizzazione

Verificate con il comando Get-ADGroup HGShosts qual è il SID del gruppo appena creato. Il SID verrà utilizzato per configurare poi sul Server HGS (LON-SVR1) l’Attestation Host Group ed individuerà tutti gli Host autorizzati a far girare le Shielded VM.

Figura 15: Verifica del gruppo appena creato

Spostatevi quindi sul computer LON-SVR1 e digitate il comando Add-HgsAttestationHostGroup -Name HGSHosts –Identifier <SID>, sostituendo il paramento <SID> con il valore del SID del gruppo che avete precedentemente visualizzato.

Figura 16: aggionta dell’Host Attestation Group al Server HGS

Lanciate il comando Get-HgsTrace -RunDiagnostics per verificare che tutto sia stato configurato correttamente e dopo qualche minuto ricevere lo status di Pass in verde, come mostrato in figura:

Figura 17: Verifica della configurazione del Server HGS

A questo punto avrete terminato la creazione del server HGS e la creazione di un Fabric Domain Server con un Attestation Host Group.

Configurazione dei server Hyper-V (Guarded Host)

Per configurare Hyper-V all’utilizzo di un server HGS e trasformarlo in un Guarded Host in modo tale che possa ospitare Shielded VM, è sufficiente aggiungere ad una macchina Windows Server 2016 il ruolo di Host Guardian Service, sia utilizzando PowerShell con il comando Install-WindowsFeature HostGuardian –IncludeManagementTools –Restart sia utilizzando l’interfaccia grafica di aggiunta e rimozione dei ruoli.

Figura 18: Aggiunta del Ruolo di Host Guardian Service

Figura 19: Installazione del ruolo di Host Guardian Service e di tutti i prerequisiti

Terminata l’installazione ed il successivo riavvio, possiamo configurare il nostro Host Hyper-V come client HGS (Guarded Host) utilizzando il comando PowerShell

Set-HgsClientConfiguration -AttestationServerUrl ‘http://LON-SVR1.Contoso.com/Attestation’ -KeyProtectionServerUrl ‘http://LON-SVR1.Contoso.com/KeyProtection’

Figura 20: Aggiunta del client HGS

È possibile visualizzare in qualsiasi momento la configurazione eseguendo la cmdlet Get-HgsClientConfiguration

Creazione di una Shielded VM

Per creare una Shielded VM è necessario creare una macchina virtuale Generation 2. Nel mio caso la macchina si chiamerà ShieldedVM01

Figura 21: Creazione di una nuova VM Generation 2

Terminata la creazione della macchina procedete all’installazione del Sistema operativo

Figura 22: Installazione del Sistema operativo

Terminata l’installazione della VM ricordatevi di abilitare il Desktop Remoto, in quanto dopo che avremo reso la VM “shielded” non sarà più possibile utilizzare la console di Hyper-V per potervi accedere.

Figura 23: Abilitazione del Desktop remoto nella VM da proteggere

A questo punto arrestate la macchina virtuale, che potrà essere protetta solo se è spenta.

Protezione della VM

Dall’Host di virtualizzazione LON-HOST1 collegatevi al Key Protection Web Service ospitato sul Server HGS (LON-SVR1) e salvate la configurazione localmente utilizzando il comando:

MD C:\HGS

Invoke-WebRequest http://LON-SVR1.contoso.com/Keyprotection/service/metadata/2014-07/metadata.xml -OutFile ‘C:\HGS\HGSGuardian.xml’

Rendete a questo punto LON-HOST1 un local HGS Guardian, utilizzando il file xml che avete generato, digitando il comando PowerShell

$Owner =  New-HgsGuardian –Name ‘Owner’ –GenerateCertificates

$Guardian Import-HgsGuardian -Path ‘C:\HGS\HGSGuardian.xml’ -Name ‘TestFabric’ –AllowUntrustedRoot

Figura 24: Creazione dell’Host Guardian

Create un Key Protector, che definisce quale Fabric è autorizzato ad eseguire la macchina virtuale protetta con il comando:

# Creazione di un Key Portector, che stabilisce quale fabric potrà avviare la VM

$KP New-HgsKeyProtector -Owner $Owner -Guardian $Guardian -AllowUntrustedRoot

# Abilitazione dello shielding della VM

Set-VMKeyProtector –VMName ShieldedVM01 –KeyProtector $KP.RawData

Il passaggio finale consiste nell’abilitare la Security Policy sulla VM e di fatto trasformarla in una Shielded VM.

# Configura la policy di sicurezza della VM

Set-VMSecurityPolicy -VMName ShieldedVM01 -Shielded $true

Figura 25: Configurazione della VM e trasformazione in una Shielded VM

Per abilitare il virtual TPM sulla macchina virtuale è invece sufficiente eseguire il comando Enable-VMTPM -VMName ShieldedVM01.

Adesso la macchina virtuale ShieldedVM01 può essere avviata e se aprite il Virtual Machine Connector riceverete una schermata come quella mostrata in figura, che vi avvisa che d’ora in poi potrete connettervi alla VM utilizzando solo il Desktop remoto.

Figura 26: La connessione in console è proibita sulle Shielded VM

Da questo momento la macchina è protetta e potrà essere eseguita solo sugli Host autorizzati. Infatti se provate ad avviare la macchina su un Host non autorizzato riceverete il seguente messaggio di errore:

Figura 27: Esecuzione di una Shielded VM su un Host non autorizzato e relativo messaggio di errore

Se provate a montare il disco di una VM che è stata protetta riceverete invece il seguente messaggio di errore

Figura 28: Il tentativo di montare il VHD di una Shielded VM fallisce con un errore

Shielded VM in Windows 10 Client Hyper-V

Da Windows 10, versione 1709, anche Client Hyper-V può ospitare le Shielded VM utilizzando l’Attestation con un Server HGS remoto, mentre prima di questa versione era possibile farlo solo utilizzando il local mode, cioè facendo in modo che le encryption key del vTPM venissero salvate localmente. Per approfondimenti vi rimando all’articolo https://blogs.technet.microsoft.com/datacentersecurity/2018/01/05/shielded-vm-local-mode-and-hgs-mode/

Conclusioni

Windows Server 2016 è la versione più sicura tra i sistemi operativi server rilasciati da Microsoft e nell’era dell’Hybrid Cloud la sicurezza rappresenta la sfida maggiore proprio per la natura distribuita dei worloads su diverse piattaforme. Host Guardian Service e le Hyper-V Shielded VM rappresentano un’ottima soluzione per proteggere le macchine virtuali dagli attacchi esterni e dagli accessi non autorizzati da parte degli Hyper-V Administrators.

Virtual Hard Disk Sharing in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

IIn Windows Server 2012 R2 sono stati introdotti gli Shared Disk (che avevano l’estensione .VHDX), pensati per poter condividere uno o più hard disk tra più macchine virtuali e semplificare la creazione dei Guest Cluster. In questo modo è infatti possibile proteggere i servizi e le applicazioni all’interno delle VM ed in particolar modo gli Shared Disk si prestano ad ospitare i file dei database SQL Server e i dati dei File Server creati all’interno delle VM. Gli Shared VHDX avevano però tutta una serie di limitazioni (no resize, no host level backup, no ckeckpoint, no Hyper-V Replica support, no storage live migration) che di fatto ne hanno limitato fortemente l’adozione.

In Windows Server 2016 gli Shared Disk sono stati sostituiti dai VHD Set (hanno l’estensione .VHDS), che hanno il vantaggio di poter essere ridimensionati online, di poter essere replicati utilizzando Hyper-V Replica e di poter essere salvati durante le normali procedure di backup con Backup Host based. Rimane in ogni caso ancora non disponibile la possibilità di fare Storage Live Migration e la creazione dei Checkpoint.

I VHD Set devono necessariamente essere salvati all’interno dei Cluster Shared Volumes (CSVs) o dei Clustered Storage Spaces e possono essere a dimensione fissa o ad espansione dinamica.

Figura 1: Creazione dei VHD Set utilizzando i Cluster Shared Volumes (CSVs)

In alternativa è anche possibile salvarli in cartelle di rete ospitate da Scale-Out File Server che utilizzano il protocollo SMB 3.0

Figura 2: Salvataggio dei VHD Set in uno Scale Out File Server con SMB 3.0

Creazione di un VHD Set

Per creare un nuovo Shared Drive in Windows Server 2016 è sufficiente lanciare il wizard di creazione di un nuovo disco virtuale oppure modificare le impostazioni di una VM e creare il disco collegandolo al Controller SCSI. Gli Shared Drive infatti utilizzano SCSI-persistent reservations e vengono esposti alle VM come virtual disk SAS. Le SCSI-persistent reservations permettono alle diverse VM di coordinare l’ownership dello storage e quindi è possibile trasferire lo storage da un nodo all’altro, se uno dei due smette di funzionare.

Figura 3: Aggiunta di un nuovo Shared Drive alla VM

Figura 4: Wizard per la creazione del nuovo VHD Set

Figura 5: Creazione del disco virtuale condiviso all’interno di una cartella contenuta in un Cluster Shared Volume (CSV)

Figura 6: Scelta della dimensione dello Shared Drive

Terminato il wizard di creazione, potrete notare che nella cartella che avete scelto sono presenti due file, uno con estensione .VHDS (molto piccolo) che contiene i metadati necessari a permettere a tutte le VM che lo utilizzeranno di poter accedere contemporaneamente al disco virtuale e uno con estensione .AVHDX (Automatic VHDX) che conterrà i dati che saranno memorizzati dalle VM. Il file .AVHDX associato al file .VHDS è un hard disk virtuale (fisso o dinamico) gestito automaticamente. Se provate a rinominare il file .AVHDX in .VHDX (quando non è in uso) potrete anche collegarlo alla macchina Host e verificare che al suo interno ci sono i dati che avete memorizzato. ATTENZIONE: questa procedura non va fatta in produzione, ma solo in un ambiente di test al solo scopo di verifica.

Figura 7: File creati durante la creazione dello Shared Drive

È possibile aggiungere il disco virtuale creato anche alle altre VM, collegandolo al controller SCSI ed effettuando la ricerca del file .VHDS come mostrato in figura:

Figura 8: Aggiunta di un disco condiviso esistente ad una VM

Figura 9: Il disco condiviso viene correttamente collegato alla seconda VM

Il disco condiviso viene visto, come già scritto prima, come virtual disk SAS e può essere inizializzato e formattato dal sistema operativo della VM.

È anche possibile salvare i VHD Set all’interno di Scale-Out File Server cluster. Il wizard per la creazione del disco è identico, basta solo scegliere la condivisione di rete ospitata sullo Scale-Out File Server, come mostrato in figura:

Figura 10: Creazione del VHD Set in uno Scale-Out File Server cluster

Nel caso in cui cerchiate di salvare il file in una normale Share di rete invece che in uno Scale-Out File Server oppure all’interno di una cartella che non sia in un Cluster Shared Volume riceverete un messaggio di errore come quello in figura:

Figura 11: Errore nella creazione dello Share Drive a causa della posizione di salvataggio non supportata

Una valida alternativa all’interfaccia grafica è l’utilizzo dei comandi PowerShell. Per creare un VHD Set è infatti sufficiente utilizzare il comando:

New-VHD -path C:\ClusterStorage\VMs\SharedVHDX\Shared01.vhds -Dynamic -SizeBytes 500GB

Mentre per collegarlo alle VM è sufficiente utilizzare il comando:

Add-VMHardDiskDrive -VMName VM01 -ControllerNumber -ControllerLocation -Path C:\ClusterStorage\VMs\SharedVHDX\Shared01.vhd -ShareVirtualDisk

Add-VMHardDiskDrive -VMName VM02 -ControllerNumber -ControllerLocation -Path C:\ClusterStorage\VMs\SharedVHDX\Shared01.vhd -ShareVirtualDisk

Conclusioni

I VHD Set e gli Shared Drive semplificano di molto la creazione di Guest Cluster senza l’utilizzo di storage condiviso che richiederebbe configurazioni più complesse all’interno delle VM, come ad esempio connessioni iSCSI oppure l’utilizzo di Virtual Fiber Channel. In questo modo non siete più vincolati al tipo di storage e alla sua tecnologia e potete utilizzare dischi virtuali.

Limitare i privilegi amministrativi utilizzando la Just Enough Administration (JEA)

Facebooktwittergoogle_plusredditlinkedin

La Just Enough Administration (JEA) è una delle novità di sicurezza del Windows Management Framework 5.0 che permette di limitare le sessioni amministrative solo ad un particolare set di comandi e aumenta di fatto la sicurezza nella gestione dei nostri sistemi.

Questo tipo di funzionalità, basata sull’amministrazione PowerShell remota (Windows PowerShell Remoting), permette di configurare degli endpoint in modo tale che quando un utente si connette per eseguire delle cmdlet di PowerShell remote, gli venga concesso l’utilizzo di solo alcuni script e di alcuni comandi. Ad esempio, potreste limitare per un utente la possibilità di amministrare il DNS e di eseguire solo alcune delle cmdlet relative alla sua gestione. Se il ruolo DNS è installato sul controller di dominio Active Directory (come di regola avviene), gli amministratori DNS richiedono privilegi di amministratore locale per risolvere problemi con il server DNS, e per fare ciò è necessario che siano membri del gruppo di sicurezza con privilegi elevati “Domain Admins”.

JEA permette di evitare l’uso di account privilegiati. L’utente si connette all’endpoint remoto JEA utilizzando uno speciale virtual account privilegiato invece che il proprio account utente. I vantaggi di questo tipo di approccio sono molteplici:

  • Le credenziali dell’utente non verranno memorizzate nel sistema remoto e nel caso questo venga compromesso non sarà possibile rubare le credenziali
  • L’utente che utilizzate per l’amministrazione remota non dovrà essere privilegiato e potrà essere un normale utente di dominio
  • Il virtual account è valido solo nell’host dove si trova e non può essere riutilizzato per connettersi ad altri sistemi remoti
  • Il virtual account ha privilegi amministrativi sull’host, ma limitati alle attività che saranno stabilite per la JEA

La funzionalità di Just Enough Administration (JEA) è disponibile di default in:

  • Windows Server 2016
  • Windows 10, version 1511 or later

Ma funziona anche se avete installato Windows Management Framework 5.0 in:

  • Windows Server 2012 R2
  • Windows Server 2012
  • Windows Server 2008 R2
  • Windows 8.1
  • Windows 8
  • Windows 7

In realtà Windows Server 2008 R2 ed Windows 7 non supportano i virtual accounts JEA e tutte le attività vengono eseguite dall’utente che si connette al JEA Endpoint.

Configurare JEA non è semplicissimo, perché bisogna sapere esattamente quali sono le attività che verranno svolte e quali sono i comandi che dovranno essere eseguiti. In ogni caso se avete attività da svolgere spesso o script da eseguire, JEA è un ottimo modo per ridurre la superficie di attacco ed implementare RBAC (Role Based Access Control). Un altro limite evidente è sicuramente quello che JEA funziona SOLO con PowerShell.

Per mostrarvi come funziona JEA, darò la possibilità ad un semplice utente di dominio di effettuare alcune operazioni sul server DNS (nel mio caso il domain controller DC1). Ho creato un utente di dominio e l’ho aggiunto ad un gruppo chiamato DNSOps.Il gruppo DNSOps è anch’esso un gruppo che non ha privilegi amministrativi.

Figura 1: Creazione dell’utente limitato ed aggiunta al gruppo DNSOps

Creazione del Role-Capability file

Il Role-Capability file permette di specificare cosa potrà essere fatto nelle sessioni remote di PowerShell. È possibile creare un nuovo file, che avrà estensione .psrc, e aggiungere le cmdlet, le funzioni e tutti i comandi necessari. Per avere una lista completa dei parametri utilizzabili e delle diverse parti del file .psrc vi rimando alla lettura dell’articolo https://docs.microsoft.com/en-us/powershell/jea/role-capabilities e dell’articolo https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/new-psrolecapabilityfile?view=powershell-5.1

Per creare un nuovo Role-Capability File è sufficiente eseguire sul domain controller o sul server DNS (nel mio caso si chiama DC1) PowerShell ISE, con privilegi elevati, e lanciare le seguenti cmdlet di PowerShell:

Cd ‘c:\Program Files\WindowsPowerShell\Modules’
Mkdir DNSOps
Cd DNSOps
New-ModuleManifest .\DNSOps.psd1
Mkdir RoleCapabilities
Cd RoleCapabilities
New-PSRoleCapabilityFile -Path .\DNSOps.psrc
Ise DNSOps.psrc

In questo modo verrà creato un nuovo file chiamato DNSOps.psrc che utilizzeremo per poter gestire il DNS.

Figura 2: Creazione di un Role-capability file DNSOps.psrc

Configurazione del Role-Capability file

Dopo aver creato il Role-Capability file DNSOps.psrc, è necessario configurarlo per i nostri scopi. Se avete eseguito la cmdlet Ise DNSOps.psrc nel passaggio precedente potrete già modificare il file. Come prima operazione consentiamo di riavviare solo il servizio DNS. Posizionatevi quindi sotto la riga che inizia per # VisibleCmdlets = e digitate:

VisibleCmdlets = @{ Name 'Restart-Service'; Parameters = @{ Name='Name'; ValidateSet = 'DNS'}}

Per consentire l’utilizzo di solo alcune cmdlet riferite alla gestione del DNS posizionatevi sotto la riga che inizia per # VisibleFunctions = e digitate:

VisibleFunctions = 'Add-DNSServerResourceRecord', 'Clear-DNSServerCache', 'GetDNSServerCache', 'Get-DNSServerResourceRecord' , 'Remove-DNSServerResourceRecord'

Per consentire l’utilizzo di solo alcuni eseguibili (nel mio caso whoami.exe) posizionatevi sotto la riga che inizia per # VisibleExternalCommands = e digitate:

VisibleExternalCommands = 'C:\Windows\System32\whoami.exe'

Salvate il file DNSOps.psrc. Il risultato è quello mostrato nella figura sotto:

Figura 3: Modifica del Role-capabilty file DNSOps.psrc

Creazione del Session-configuration file

Il Session-configuration file serve a definire cosa può essere fatto in una sessione JEA. Se una cmdlet, un parametro, il valore di un determinato parametro, un alias, uno script esterno o un eseguibile non sono presenti nel session-configuration file, allora non potranno essere utilizzati in una sessione JEA configurata per utilizzare quel session-configuration file.

Per creare un nuovo file, che avrà l’estensione .pssc, è sufficiente utilizzare la cmdlet New-PSSessionConfigurationFile. Per avere una lista completa dei parametri utilizzabili e delle diverse parti del file .pssc vi rimando alla lettura dell’articolo https://docs.microsoft.com/en-us/powershell/jea/session-configurations e dell’articolo https://docs.microsoft.com/it-it/powershell/module/Microsoft.PowerShell.Core/New-PSSessionConfigurationFile?view=powershell-5.1

Creiamo un nuovo file eseguendo sul nostro server DNS (nel mio caso si chiama DC1) da PowerShell ISE con privilegi elevati le seguenti cmdlet:

Cd ‘c:\Program Files\WindowsPowerShell\Modules\DNSOps’
New-PSSessionConfigurationFile -Path .\DNSOps.pssc -Full
Ise DNSOps.pssc

Dopo aver creato il file è possibile modificarlo. Da PowerShell ISE, nella scheda DNSOps.pssc, modificate il valore SessionType ‘Default in

SessionType = 'RestrictedRemoteServer'

Navigate fino alla linea #RunAsVirtualAccount = $true e rimuovete il comment # in modo tale che ci sia solo

RunAsVirtualAccount = $true

Spostatevi quindi alla linea che comincia con #RoleDefinitions e subito sotto scrivete il nome del gruppo di AD che volete usare per la gestione (nel mio caso DEMO\DNSOps):

RoleDefinitions = @{ 'DEMO\DNSOps' = @{ RoleCapabilities 'DNSOps' };}

Salvate il file DNSOps.pssc. Il risultato è quello mostrato nella figura sotto:

Figura 4: Modifica del session-configuration file DNSOps.pssc

Creazione del JEA Endpoint

Un JEA Endpoint è un endpoint PowerShell che è configurato in modo tale che solo alcuni utenti possano connettersi e abbiano accesso alle cmdlet, ai parametri e ai valori definiti dal session-configuration file. Un server può avere diversi JEA Endpoint ed ognuno di loro può essere utilizzato per diversi scopi amministrativi. Una volta che un utente si collega al JEA Endpoint avrà i privilegi assegnati al virtual account che è stato definito nel session-configuration file. Per approfondimenti sui JEA Endpoint vi rimando all’articolo https://docs.microsoft.com/en-us/powershell/jea/register-jea

Per creare un JEA Endpoint è possibile utilizzare la cmdlet Register-PSSessionConfiguration. Sul vostro server DNS da PowerShell ISE lanciate le seguenti cmdlet:

Register-PSSessionConfiguration -Name DNSOps -Path .\DNSOps.pssc
Restart-Service WinRM
Get-PSSessionConfiguration

Il risultato è quello mostrato in figura:

Figura 5: Creazione del JEA Endpoint

Verificate che DNSOps sia elencato tra gli Endpoint disponibili.

Se avete sbagliato a configurare un Endpoint potete sempre eliminarlo utilizzando la cmdlet Unregister-PSSessionConfiguration

Creazione di una sessione amministrativa

Per verificare che tutto funzioni correttamente utilizzerò una macchina remota per effettuare l’amministrazione. Da una macchina del dominio che voglio usare come postazione di amministrazione, dopo essermi loggato come Domain Admin (demo\administrator), mi collego con una sessione PowerShell remota a DC1 e verifico quali sono i permessi che ho a disposizione usando le seguenti cmdlet:

Enter-PSSession -ComputerName DC1
(Get-Command).count
Whoami.exe

Come si può notare dalla figura sotto, ho la possibilità come domain admin di usare 2006 cmdlet diverse:

Figura 6: Sessione remota PowerShell con privilegi da domain admin

Creazione di una sessione di Just Enough Administration (JEA)

Dalla stessa macchina di dominio che voglio utilizzare come postazione di amministrazione mi loggo questa volta come domain user (demo\nicferr) che fa parte del gruppo DEMO\DNSOps (che ho autorizzato nel Session-configuration file) e mi collego con una sessione PowerShell remota a DC1. Se lanciassi la cmdlet Enter-PSSession -ComputerName DC1 riceverei un messaggio di errore perché essendo un domain user non ho privilegi amministrativi su DC1. Ma se lancio Enter-PSSession -ComputerName DC1 -ConfigurationName DNSOps (dichiarando quindi di voler utilizzare una configurazione JEA) riesco a connettermi. Verifico quali sono i permessi che ho a disposizione usando le seguenti cmdlet:

Enter-PSSession -ComputerName DC1 -ConfigurationName DNSOps
(Get-Command).count
Whoami.exe

Figura 7: Connessione alla macchina DC! utilizzando la configurazione JEA

Come si può vedere dalla figura 7, il comando Whoami.exe non restituisce il logon name dell’utente (demo\nicferr) bensì quello del virtual account utilizzato da JEA (winrm virtual users\winrm va_1_demo_nicferr).

Provo quindi ad eseguire alcuni comandi per la gestione del DNS (ovviamente saranno concesse solo le cmdlet che ho definito nel role-capability file):

Get-DNSServerResourceRecord -zonename demo.lab
Add-DNSServerResourceRecord -zonename ‘demo.lab’ -A -Name ‘SVR1’ -IPv4Address ‘10.0.0.101’
Add-DNSServerResourceRecord -zonename ‘demo.lab’ -A -Name ‘SVR2’ -IPv4Address ‘10.0.0.102’
Remove-DNSServerResourceRecord -zonename ‘demo.lab’ -RRTYPE ‘A’ -Name ‘SVR2’ -Confirm

I risultati sono mostrati in figura:

Figura 8: Esecuzione dei comandi abilitati nel role-capability file

Provo anche a riavviare il servizio DNS utilizzando la cmdlet Restart-Service DNS ed in effetti il servizio viene riavviato. Se invece provo a riavviare un altro servizio non consentito nel role-capability file (ad esempio utilizzando la cmdlet Restart-Service WinRM) ricevo un messaggio di errore, come mostrato in figura:

Figura 9: Errore dovuto all’esecuzione di un comando non contenuto nel role-capability file

Distribuzione della configurazione JEA ad un altro computer

Una volta che avete validato la vostra configurazione JEA, sarà possibile distribuirla su tutti i computer che volete amministrare. Per poter riutilizzare la configurazione JEA che avete creato su vostro server DNS (nel mio caso DC1), potete copiare tutto il contenuto della cartella C:\Program Files\WindowsPowerShell\Modules\DNSOps del vostro server e incollarla nel nuovo server da gestire nello percorso C:\Program Files\WindowsPowerShell\Modules. Successivamente potete creare il nuovo JEA Endpoint utilizzando i comandi PowerShell:

Cd ‘c:\Program Files\WindowsPowerShell\Modules\DNSOps\RoleCapabilities’
Register-PSSessionConfiguration -Name DNSOps -Path .\DNSOps.pssc
Restart-Service WinRM

Figura 10: Copia della configurazione JEA sul nuovo server da gestire

Verificate con la cmdlet Get-PSSessionConfiguration che DNSOps sia disponibile come Endpoint.

Figura 11: Creazione del JEA Endpoint sul nuovo server da gestire

Conclusioni

La Just Enough Administration (JEA) consente di migliorare le condizioni di sicurezza, riducendo di fatto il numero di amministratori nei computer. Ciò avviene tramite la creazione per gli utenti di un Endpoint per eseguire attività amministrative in maniera limitata, per prevenire usi impropri. Poiché JEA consente di eseguire i comandi di amministratore senza avere accesso come amministratore, è possibile rimuovere gli utenti dai gruppi di sicurezza con privilegi elevati e renderli quindi utenti standard, adottando il principio di privilegio minimo.