Archivi categoria: Microsoft

SQL Server: i retroscena del porting Linux

SQL Server 2017

Fonte: sito ufficiale Microsoft

Questa settimana è stata rilasciata la release candidate 1 (RC1) di SQL Server 2017, prossima major release (sviluppata a tempo di record) del noto RDBMS Microsoft. All’indomani dell’annuncio ufficiale, TechChrunch ha avuto modo di parlare direttamente con uno dei membri del team che ha supervisionato il complesso e delicato porting di SLQ Server su Linux:  Rohan Kumar (general manager Database Systems group presso Microsoft).

A rendere possibile lo sbarco di SQL in ambienti Linux è stata la nomina di Satya Nadella a CEO della compagnia. Lo conferma indirettamente Kumar in questo passaggio:

In passato abbiamo avuto un paio di colloqui [sulla questione del porting Linux ma il progetto non fu approvato]. Non era qualcosa che veniva considerato strategico per il [nostro business]”. Ma tre anni fa – con Satya Nadella ai vertici della compagnia – il team decise di riproporre nuovamente il progetto. ” La cosa più sorprendente è che ci aspettavamo [diverse esitazioni da parte dei piani alti]. Fu una sorpresa constatare la rapidità con la quale fu presa la decisione [di approvare il progetto].

In seconda battuta bisogna poi ricordare i feedback ricevuti dalle aziende. Kumar afferma che, sebbene SQL Server venisse sempre più di frequente utilizzato per workload mission critical, quindi un ottimo segnale per Redmond, diverse compagnie trovavano limitante il dover utilizzare obbligatoriamente Windows Server – tenendo conto della crescente popolarità degli ambienti di lavoro misti (Windows/Linux) in ambito enterprise. Molte aziende cercavano poi un’alternativa ai prodotti Oracle: a coloro che volevano utilizzare un database relazionale proprietario (avvalendosi del supporto enterprise) su Linux il mercato non offriva molte soluzioni.

Parlando con le imprese [abbiamo capito che il porting era necessario]. Stavamo obbligando i nostri clienti ad utilizzare Windows come piattaforma principale.

E’ il caso di notare come il giornalista sottolinei il cambio di mentalità in casa Microsoft: in passato (in un’altra “incarnazione” di Microsoft) quanto appena evidenziato da Kumar non sarebbe stato giudicato come un fattore negativo.

Pianificazione del porting SQL Server

Una volta ottenuta l’approvazione dei piani alti, il team di Kumar si è trovato davanti ad un problema apparentemente insormontabile: come effettuare il porting Linux di milioni di linee di codice senza sacrificare funzionalità ed altre caratteristiche? Sono stati due gli elementi che hanno consentito ai programmatori di rendere possibile l’arrivo di SQL Server su Linux: Drawbridge e SQLOS.

Il primo è un progetto sperimentale (interno all’azienda) avviato nel 2011 e riscoperto, per fortuna di Kumar e colleghi, proprio in quel periodo. L’idea alla base di Drawbridge era quella incrementare la sicurezza delle VM: per ottenere questo risultato si era pensato ad un container con una versione minale di Windows in grado di eseguire applicazioni, gestire la memoria ed altre importanti funzioni integrandosi allo stesso tempo con il sistema operativo sottostante.

SQLOS è invece una parte fondamentale del database relazionale Microsoft pensata per eseguire funzioni solitamente ad appannaggio dei sistemi operativi. Nell’articolo si spiega sinteticamente che ad SQL Server la piattaforma Windows Server stava “stretta”, era necessario gestire “in prima persona” determinate task – come la gestione della memoria. Ed è grazie all’OS Layer che SQL Server è stato in grado di gestire ad esempio la memoria in Drawbridge, osserva l’editorialista. Il passo successivo è stato quello di far convergere l’SQL OS Layer e Drawbridge nell’SQL Platform Abstraction Layer – grazie al quale SQL Server è in grado di funzionare sia su Windows che Linux.

Per quanto riguarda le prossime release…

Anche se SQL Server Linux raggiungerà la disponibilità generale entro la fine dell’anno, alcune compagnie hanno già avuto l’occasione di testarlo in produzione constatando, afferma l’articolo, prestazioni allineate alla controparte Windows (logicamente a parità di hardware).

Interessante infine il commento di Kumar circa la finestra di rilascio della prossima major release (SQL Server 2018): sebbene occorra innovare costantemente le proprie soluzioni per restare altamente competitivi nel settore, non tutti i clienti Microsoft gradiscono aggiornare frequentemente i propri sistemi mission critical – procedura alquanto delicata. Questo significa che SQL Server 2018 uscirà più tardi del previsto? Il giornalista di TechCrunch non ne è molto sicuro.

Fonte: 1

 

 

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

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

Prerequisiti:

  • Azure PowerShell
  • Configurazione di un Key Vault

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

Configurare la VM

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

Figura 1: Scelta del deployment model

Figura 2: parametri per la creazione della nuova VM

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

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

Figura 3: Verifica che il disco creato non è crittografato

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

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

Login-AzureRmAccount

Set-AzureRmContext -SubscriptionId <SubscriptionID>

Eseguiamo lo script:

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

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

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

Figura 5: Inserimento dei parametri nello script di verifica

Crittografare la VM

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

$resourceGroupName ‘NewResourceGroup’

$vmName ‘VMtestKV’

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

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

Confermiamo per concludere l’operazione:

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

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

Figura 7: Crittografia del disco completata

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

Figura 8: Il disco della VM risulta crittografato

Conclusioni

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

Creare una connessione Site-to-Site in Microsoft Azure

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

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

Prerequisiti

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

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

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

Configurazione della connessione

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

Figura 2: Creazione della VNET

Figura 3: VNET creata – Visualizzazione Subnet

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

Figura 4: Aggiunta della Gateway Subnet

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

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

Figura 5: Creazione del Virtual Network Gateway

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

SKU

Tunnel S2S/
rete virtuale-rete virtuale

Connessioni
P2S

Velocità effettiva
aggregata

VpnGw1

Max. 30

Max. 128

500 Mbps

VpnGw2

Max. 30

Max. 128

1 Gbps

VpnGw3

Max. 30

Max. 128

1,25 Gbps

Basic

Max. 10

Max. 128

100 Mbps

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

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

Figura 6: Creazione del Local Network Gateway

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

Figura 7: Scheda Connections del gateway VPN appena creato

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

Figura 8: Configurazione della connessione Site-To-Site

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

Figura 9: Creazione VPN Site-to-Site completata

Configurazione del dispositivo VPN aziendale

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

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

Conclusioni

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

Configurare un site-aware failover cluster e la node fairness in Windows Server 2016

Il Site-Aware failover è una novità relativa alla funzionalità di Failover Clustering che è stata introdotta in Windows Server 2016. Anche se in realtà già in Windows Server 2012 R2 era possibile realizzare un cluster i cui nodi erano funzionanti in due regioni geografiche diverse, non c’era modo per indicare in quale di queste regioni si trovassero i diversi nodi, in modo tale da poterli gestire in maniera diversa e poter indicare ai diversi servizi di poter fare “failover” nella stessa area geografica.

Con Windows Server 2016 è stata invece introdotta la possibilità di raggruppare i nodi in base alla loro posizione fisica in modo tale da poter, ad esempio, permettere alle risorse del cluster di poter essere trasferite su un nodo nello stesso sito in caso di manutenzione o draining di un altro nodo.

Per poter implementare la site awareness è possibile procedere in due modi, uno automatico ed uno manuale.

Se si utilizza il modo automatico è possibile utilizzare i Site di Active Directory. Quindi se avete già definito dei Site dentro i quali avete messo i vostri Domain Controller e a cui avete associato delle subnet, vi basterà digitare il comando PowerShell (lanciato con privilegi elevati):

(Get-Cluster).AutoAssignNodeSite 1

Se volete utilizzare la modalità manuale sarà invece prima necessario definire quali sono i Site e successivamente aggiungervi i nodi, utilizzando i comandi PowerShell (lanciati con privilegi elevati):

#Creazione dei Site

New-ClusterFaultDomain –Name Roma –Type Site –Description “Datacenter Primario” –Location “Datacenter Roma”

New-ClusterFaultDomain –Name Milano –Type Site –Description “Datacenter Secondario” –Location “Datacenter Milano”

#Assegnazione dei nodi ai Site

Set-ClusterFaultDomain –Name Nodo1 –Parent Roma

Set-ClusterFaultDomain –Name Nodo2 –Parent Roma

Set-ClusterFaultDomain –Name Nodo3 –Parent Milano

Set-ClusterFaultDomain –Name Nodo4 –Parent Milano

Questo tipo di configurazione permette di migliorare notevolmente il failover, il placement delle macchine virtuali, gli heartbeat tra i nodi e il quorum.

Ad esempio la Failover Affinity permette che le risorse vengano spostate su un nodo dello stesso sito, prima di tentare di spostarle in un sito differente. Inoltre durante la Node Drain le macchine virtuali vengano spostate localmente, su un nodo vicino.

Il Cross-Site Heartbeat da’ la possibilità di configurare in maniera accurata alcuni parametri come ad esempio il CrossSiteDelay (il tempo tra due heartbeat inviati tra nodi in siti diversi) e il CrossSiteThreshold (il numero di heartbeat persi tra due nodi in site diversi). Entrambi i valori sono configurabili con i comandi PowerShell (lanciati con privilegi elevati)

(Get-Cluster).CrossSiteDelay 1000    #valore di default

(Get-Cluster).CrossSiteThreshold 20  #valore di default

Un’altra interessante novità di Windows Server 2016 riguarda la Virtual Machine Node Fairness, che è già abilitata di default ma che viene disabilitata se utilizzate la funzionalità Dynamic Optimization di System Center Virtual Machine Manager. La VM Node Fairness permette di bilanciare le macchine virtuali tra i diversi nodi del cluster: dopo aver valutato l’utilizzo del processore e della memoria, le macchine vengono automaticamente migrate (utilizzando la Live Migration) da un nodo più carico ad un nodo scarico. Il bilanciamento può essere configurato per ottenere le migliori performance nel cluster, utilizzando il comando PowerShell (eseguito con privilegi elevati) per configurare la percentuale di utilizzo del nodo:

(Get-Cluster).AutoBalancerLevel 2

riprendendo i valori dalla seguente tabella:

AutoBalancerLevel

Aggressiveness

Host load percentage

1 (default)

Low

80%

2

Medium

70%

3

High

60%

Oppure è possibile configurare ogni quanto tempo deve essere utilizzata la node fairness, utilizzando il comando PowerShell (eseguito con privilegi elevati):

(Get-Cluster).AutoBalancerMode 2

riprendendo i valori dalla seguente tabella:

AutoBalancerMode

Behavior

0

Disabled

1

Balance on node join only

2 (default)

Balance on node join and every 30 minutes

Conclusioni

Queste due importanti novità relativa al cluster di Windows Server 2016 sono pensate sia per la gestione del Disaster Recovery geografico tra diversi siti della nostra infrastruttura, sia per l’ottimizzazione delle performance dei nodi, senza dover ricorrere a prodotti a pagamento come SCVMM. Sicuramente un grosso passo in avanti per rendere i nostri datacenter più performanti ed avere lo stesso livello di funzionalità offerte dal Cloud pubblico.

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

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

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

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

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

Creazione di una nuova VM di tipo Ev3 su Azure

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

Figura 1: Creazione della VM in West Europe

Figura 2: Scelta della dimensione della VM

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

Figura 4: Schermata riassuntiva con le scelte selezionate

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

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

Abilitazione della Nested Virtualization

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

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

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

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

Figura 7: Lo script ha creato la VM annidata

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

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

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

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

#Creazione di uno switch di tipo Internal

New-VMSwitch -SwitchName “NAT” -SwitchType Internal

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

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

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

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

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

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

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

#Creazione della rete di NAT

New-NetNat -Name NATnetwork -InternalIPInterfaceAddressPrefix 192.168.0.0/24

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

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

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

Figura 12: Configurazione dell’IP statico nella Nested VM

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

Figura 13: La nested VM è connessa ad Internet

Conclusioni

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

Intervista a Scott Guthrie: Azure Stack e piattaforme per gli sviluppatori

Scott Guthrie

Pare che Scott Guthrie indossi frequentemente t-shirt rosse.

Il giornalista che ha recentemente intervistato Scott Guthrie afferma di averlo incontrato per la prima volta nel 2000. A quei tempi supervisionava il progetto ASP+, un framework di sviluppo che sarebbe stato rinominato successivamente ASP.NET ed implementato nella piattaforma Microsoft. Guthrie si è poi occupato dello “sfortunato” Silverlight.

Nel 2011 Scott inizia la sua avventura in Azure, piattaforma ancora “giovane” in cerca di una propria identità e di un solido porftfolio: le funzionalità che arrivarano di lì a poco (durable VM, scalable Azure website ed un nuovo portale per gli Admin) rappresentarano sicuramente un passo  avanti per la piattaforma cloud che iniziò a presentarsi come una delle valide competitrici di AWS.

In occasione di un evento (Business Forward) tenutosi il mese scorso a Londra , il giornalista di The Register ha avuto modo di scambiare nuovamente due chiacchere con l’attuale VP della divisione Cloud and Enterprise Microsoft (carica che ricopre dal 2014).

 Di seguito le parti più interessanti; per l’intervista completa vi rimandiamo come sempre al link menzionato nella sezione delle fonti.

The Register (TR): In passato la creazione di ASP.NET fu il tentativo di semplicare la programmazione Web. Quale è invece l’attuale strategia Microsoft [per il mondo degli sviluppatori]?

Scott Guthrie (SG): [Ci stiamo focalizzando sul rendere disponibili i servizi Office via API o blocchi integrabili. Ad esempio cose come Microsoft Teams ed il nostro Bot Framework. […] [Un altro esempio è] Office 365 che utilizza l’Azure Active Directory, quindi la possibilità di adoperare gli stessi meccanismi di autenticazione ed autorizzazione con tutte le tue app, VM, container e risorse. [Altre a questo, ci sono i 100 milioni di utenti Enterprise attivi ogni mese che utilizzano quotidianamente Office 365. Puoi incrementare il valore delle tue app e renderle ancora più semplici da utilizzare].

The Register (TR): Il Regno Unito ha una propria region Azure [che è stata aperta circa un anno fa]. Abbiamo tuttavia sentito parlare di diverse problematiche di “capienza” e di clienti ai quali è stato chiesto di [cambiare region]. Perchè tutti questi problemi?

(SG): Generalmente non abbiamo problemi di capienza nei data center. Continuiamo a costruire data center. A volte – e succede a tutti i cloud vendor – possiamo però avere [scarsa disponibilità] di particolari tipologie di VM e server. Su Azure clienti possono “riservare” una determinata quota [di risorse]. C’è stato un periodo tra Aprile e Maggio in cui per una settimana circa abbiamo imposto un limite alla quota riservabile dai nuovi clienti. La crescita della nostra region del Regno Unito è quattro volte superiore a quanto preventivato dal nostro business plan. Dovevamo attivare più server ed attualmente non abbiamo alcuna restrizione sulle quote riservabili.

The Register (TR): perchè Azure Stack è [un sistema chiuso] che richiede l’acquisto di un sistema preconfigurato?

(SG): Quel che ci è stato riferito dai clienti, ed il motivo per cui abbiamo optato per il supporto [al solo] hardware pre-certificato, sono alcune delle esperienze che la gente ha avuto con OpenStack ed altre tecnologie, con le quali hanno avuto serie difficoltà ad effettuare i deploy ed eseguire [varie soluzioni] in ambienti di produzione.

Il cloud non è solo [capacità di calcolo] ma anche reti, sistemi di storage e [vari elementi condivisi tra questi ultimi]. Se le performance subiscono un drastico calo, ti rivolgi al produttore del server, al produttore della strumentazione di rete, a quello del load balancer o dello storage? Solitamente [si assiste ad uno scaricabarile] e tu impiegherai settimane e mesi [a mettere in sesto il tuo ambiente cloud]. Abbiamo parlato con numerosi clienti che ci hanno detto “per favore non fatelo”. Il modello che abbiamo invece deciso di proporre contempla la collaborazione con il più ampio numero di hardware provider [:] HP, Dell, Lenovo, Cisco e Huawei. Questi sono i cinque più grandi produttori di server al mondo ed avranno sistemi che partono da tre nodi, [non si tratta quindi di acquisti impegnativi]. […] E potrai avere nel giro di uno o due giorni  un ambiente cloud operativo . […]

The Register (TR): Ora che Microsoft si è focalizzata sulle tecnologie cloud i suoi prodotti on-premise hanno perso rilevanza?

(SG): Penso che le soluzioni on premise stiano avanzando rapidamente. Prendiamo ad esempio SQL Server, in precedenza rilasciavamo una nuova versione ogni due o tre anni. L’anno scorso, con SQL 2016, abbiamo probabilmente avuto la più grande release SQL di sempre. […] Sei mesi fa abbiamo rilasciato SQL 2016 SP1. […] Questa estate rilasceremo SQL 2017 ed è la prima volta che rendiamo disponibile una major rev di SQL nell’arco di 12 mesi. Quella versione sarà eseguibile su Linux, Docker […].

Fonte: 1

Configurare Microsoft Azure KeyVault

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

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

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

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

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

Installare Azure PowerShell da PowerShell Gallery

Verifichiamo l’installazione di PowerShellGet:

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

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

In caso contrario, installiamo il seguente update:

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

Eseguendo PowerShell come amministratore, lanciamo il comando:

Install-Module AzureRM

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

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

Import-Module AzureRM

A questo punto siamo pronti per iniziare!

Configurare il KeyVault

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

Login-AzureRmAccount

Selezioniamo la specifica sottoscrizione con i comandi:

Get-AzureRmSubscription

Set-AzureRmContext -SubscriptionId <subscription ID>

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

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

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

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


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

Aggiungiamo una key al nostro KeyVault:

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

Per verificare l’URI, utilizziamo il comando:

$Key.key.kid


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

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

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

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

Per verificarne l’URI:

$secret.Id


Per verificare quanto appena configurato:

Get-AzureKeyVaultKey –VaultName ‘NKeyVault’

Get-AzureKeyVaultSecret –VaultName ‘NKeyVault’

Configurare l’applicazione

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


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


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

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


Eseguiamo lo script.

Quando richiesto, inseriamo una password per il certificato.

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


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


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

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


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

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

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


Conclusioni

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

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

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

Implementare Workgroup Cluster e Multi-Domain Cluster in Windows Server 2016

Mentre nelle precedenti versioni di Windows Server era necessario che tutti i nodi di un cluster fossero joinati ad un dominio di Active Directory, in Windows Server 2016 è stata introdotta la possibilità di creare cluster usando dei nodi in workgroup, permettendo quindi di non dover utilizzare un dominio ed implementare dei domain controller.

Nota: Con Windows Server 2016 è inoltre possibile creare cluster i cui nodi appartengono a domini diversi.

Per implementare un workgroup cluster o un multi-domain cluster è necessario però che vengano rispettati determinati prerequisiti:

  • Creare un account utente con lo stesso nome e la stessa password su tutti i nodi
  • Aggiungere l’account creato al gruppo Administrators locale
  • Se non si utilizza l’account predefinito Administrator è necessario creare la chiave di registro LocalAccountTokenFilterPolicy in HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System e metterla con valore 1
  • Il cluster deve essere creato nella modalità Active Directory-Detached Cluster, senza creare nessun oggetto in AD
  • È necessari creare il Cluster Network Name (chiamato anche Administrative Access Point) di tipo DNS
  • Ogni nodo deve avere un suffisso DNS
  • Nel caso di un multi-domain cluster, i suffissi DNS per tutti i domini del cluster devono essere presenti su tutti i nodi
  • Il Witness consigliato è un Cloud Witness oppure un Disk Witness. Non è supportato in entrambi i casi l’utilizzo del File Share Witness.

In questo articolo creeremo un workgroup cluster a due nodi (chiamati NODO1 e NODO2) utilizzando Windows Server 2016. Dopo aver preparato i nodi del cluster ed aver installato il sistema operativo ho provveduto a configurare il suffisso DNS su entrambi i nodi, come mostrato in figura:

Figura 1: Modifica del suffisso DNS

Dopo aver riavviato entrambi i nodi, ho provveduto a modificare il file HOSTS sulle macchine in modo tale che potessero risolvere i nomi dei nodi e il nome del cluster (che ho deciso di chiamare WRKGCLUSTER). Questa operazione è necessaria solo se non volete configurare un DNS. Nel caso abbiate un DNS in rete potete popolare la zona scelta (il suffisso DNS) per il vostro cluster (nel mio caso demo.lab).

Figura 2: Modifica del file HOSTS per la risoluzione del nomi

Ho provveduto quindi a creare su entrambi i nodi l’account di servizio ClusterSVC, ho impostato la stessa password e l’ho aggiunto al gruppo Administrators locale, come mostrato in figura:

Figura 3: Creazione dell’account per l’autenticazione NTLM

L’account è necessario affinché i nodi utilizzino l’autenticazione NTLM. Poiché non sto usando l’account Administrator è necessario inserire sui nodi la chiave di registro indicata nei prerequisiti. In maniera rapida ho eseguito sui due nodi, da un prompt PowerShell con privilegi elevati, il comando:

New-ItemProperty -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1

Figura 4: Inserimento della chiave di registro necessaria all’utilizzo degli account

Successivamente ho provveduto ad installare la feature del Failover Cluster sui due nodi. È possibile usare il Server Manager oppure il comando PowerShell
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Figura 5: Installazione della funzionalità di Failover Cluster tramite PowerShell

Terminata l’installazione ho avviato il Failover Cluster Manager e ho lanciato il wizard per la creazione del Cluster. Ho aggiunto i due nodi e ho cliccato su Next, come mostrato in figura:

Figura 6: Aggiunta dei due nodi

Nella schermata successiva ho deciso di lanciare il Validate Configuration Wizard che ovviamente mi ha riportato dei Warning, come mostrato in figura:

Figura 7: Validate Configuration Wizard

Figura 8: Warning relativo alla non appartenenza dei nodi del cluster al dominio

Nella schermata successiva del wizard ho indicato il nome del cluster e l’indirizzo IP scelto, come mostrato in figura:

Figura 9: Scelta del nome del cluster e dell’indirizzo

Terminata la verifica che non ci sia un server con lo stesso nome NETBOIS e non ci siano indirizzi IP duplicati nella stessa rete, appare la schermata riepilogativa mostrata in figura, che indica che il cluster utilizzerà per la registrazione solo il DNS:

Figura 10: Schermata riepilogativa relativa alla creazione del cluster

La stessa operazione poteva essere effettuata utilizzando il comando PowerShell

New-Cluster –Name WRKGCLUSTER.demo.lab -Node NODO1.demo.lab,NODO2.demo.lab -AdministrativeAccessPoint DNS -StaticAddress 10.10.0.5


Al termine della procedura ho ottenuto la schermata finale dell’avvenuta creazione del cluster

Figura 11: Creazione del cluster completata

Figura 12: Nodi del cluster attivi

Conclusioni

I Workgroup Cluster e i Multi-Domain Cluster sono decisamente un’importante novità introdotta in Windows Server 2016. I workload supportati sono SQL Server, File Server e Hyper-V. Per quanto riguarda Hyper-V la mancanza dell’autenticazione Kerberos in realtà complica le cose in quanto la Live Migration non è supportata, mentre è supportata la Quick Migration.

Privileged Access Management e Temporary Group Membership in Windows Server 2016 AD

Privileged Access Management (PAM) è una funzionalità introdotta in Windows Server 2016 che si basa sul principio dell’amministrazione Just In Time (JIT) e che permette di gestire quella che viene chiamata Just Enough Administration (JEA), che ha come scopo quello di aumentare la sicurezza nella gestione e nella delega dei privilegi in Windows Server.

JEA è un toolkit di Windows PowerShell che definisce un set di comandi per l’esecuzione di attività con privilegi. Limitando nel tempo i privilegi amministrativi è possibile anche aumentare il livello di sicurezza perché molto spesso si assegnano privilegi elevati e successivamente questi privilegi non vengono rimossi, o per dimenticanza o banalmente perché si sottovaluta il pericolo derivante dalla non adozione della modalità amministrativa del Least Administrative Privilege.

Se dobbiamo concedere ad esempio al gruppo di Help Desk o al consulente esterno di effettuare operazioni privilegiate adesso possiamo fare in modo che ci sia un limite di tempo all’appartenenza ad un gruppo amministrativo. Stesso discorso vale se dobbiamo eseguire degli script con un utente particolare.

Privileged Access Management (PAM) contribuisce quindi a risolvere il problema dell’accesso alle risorse di Active Directory ed evitare che gli autori di un attacco informatico possano ottenere le credenziali degli account amministrativi.

Prerequisiti

Per poter utilizzare PAM è necessario prima di tutto che il livello funzionale dalla Foresta di Active Directory sia Windows Server 2016. Inoltre PAM è una funzione che va abilitata, perché non è attiva di default.

Per verificare il livello funzionale della foresta e del dominio potete utilizzare la console Active Directory Administrative Center, come mostrato in figura:

Figura 1: Innalzamento del livello funzionale del Dominio e della Foresta

In alternativa potete anche usare i seguenti comandi PowerShell:

#Get the Active Directory Forest functional level

(Get-ADForest).ForestMode

#Get the Active Directory Domain functional level

(Get-ADDomain).DomainMode

Figura 2: Uso di PowerShell per la verifica dei livelli funzionali di dominio e di foresta

Per innalzare il livello funzionale del dominio e della foresta potete anche usare i comandi PowerShell:

#Raise livello funzionale del dominio a Windows 2016

Set-ADDomainMode -Identity demo.lab -DomainMode Windows2016

#Raise livello funzionale della foresta a Windows 2016

Set-ADForestMode -Identity demo.lab -ForestMode Windows2016

Abilitazione della funzionalità Privileged Access Management (PAM)

Una volta che vi siete accertati che la Foresta abbia il livello funzionale Windows Server 2016, potete installare la funzionalità PAM solo utilizzando PowerShell:

#Abilitazione della funzionalità Privileged Access Management (PAM)

Enable-ADOptionalFeature “Privileged Access Management Feature” -Scope ForestorconfigurationSet -Target demo.lab

Figura 3: Abilitazione della funzionalità Privileged Access Management (PAM)

Nota: Una volta abilitata la funzionalità non è possibile disabilitarla.

Per verificare se la funzionalità sia stata già installata è possibile usare la cmdlet

#Verifica dell’installazione della funzionalità Privileged Access Management (PAM)

Get-ADOptionalFeature “Privileged Access Management Feature”

Figura 4: Verifica dell’installazione della funzionalità Privileged Access Management (PAM) tramite PowerShell

Assegnazione temporanea dell’appartenenza di un utente ad un gruppo di Active Directory

Per poter assegnare temporaneamente uno o più utenti ad un gruppo di AD è necessario effettuare i seguenti comandi PowerShell:

#Definisco la durata di appartenenza al gruppo

$durata New-TimeSpan -Minutes 20

#Aggiungo al gruppo Domain Admind due utenti (attualmente Domain Users)

Add-ADGroupMember -Identity “Domain Admins” -Members nicferr,hector -MemberTimeToLive $durata

Figura 5: Aggiunta di due utenti al gruppo Domain Admins

Per verificare che i due utenti appartengano al gruppo Domain Admin vi basta poi lanciare la cmdlet

Get-ADGroup “Domain Admins” -Property Member -ShowMemberTimeToLive


Figura 6: Verifica dell’appartenenza al gruppo Domain Admins

Come si può notare dalla figura sopra, il risultato riporta:

Member : {<TTL=1068>,CN=Ettore Ferrini,CN=Users,DC=demo,DC=lab, <TTL=1068>,CN=Nicola Ferrini,CN=Users,DC=demo,DC=lab, CN=Administrator,CN=Users,DC=demo,DC=lab}

Accanto ai nomi dei due utenti aggiunti al gruppo Domain Admins c’è un campo TTL (espresso in secondi), che indica la durata rimanente dell’appartenenza al gruppo stesso.

Conclusioni

Privileged Access Management (PAM) è una funzionalità concepita appositamente per gli account amministrativi. Gli amministratori (o gli script) che necessitano solo occasionalmente dell’accesso per gruppi con privilegi, possono richiedere questo accesso e mantenerlo per un periodo limitato di tempo, garantendo la modalità amministrativa del Least Administrative Privilege ed aumentando di fatto la sicurezza della nostra infrastruttura di Active Directory.

Per maggiori informazioni vi rimando all’articolo https://docs.microsoft.com/it-it/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services