Archivi categoria: Cybersecurity

Classifica delle soluzioni di sicurezza endpoint secondo Gartner nel triennio 2016-2018

Facebooktwittergoogle_plusredditlinkedin

Introduzione

La corretta gestione di una moderna infrastruttura IT dipende principalmente dalle scelte dei prodotti software e una delle scelte più importanti è sicuramente la scelta della soluzione di sicurezza degli endpoint (workstations, smartphones e tablets) ovvero software antivirus, antimalware di ultima generazione.

In questo articolo vi proponiamo un approccio basato sulla comparazione dei report di Gartner dell’ultimo triennio per analizzare l’evoluzione del posizionamento dei Vendor di soluzioni Endpoint Protection Platforms (EPP) nel quadrante magico (QM) di Garner.

Lo scopo è quello di fornire una rapida panoramica di come, secondo Gartner, i Vendor si sono posizionati e di quale sia il loro l’attuale Trend senza fermarsi alla sola analisi dell’ultimo report annuale.

Le soluzioni di EPP hanno subito negli ultimi anni un’evoluzione tale da richiedere una rivisitazione da parte di Gartner della definizione di EPP e dei parametri di valutazione (a riguardo si veda il report Redefining Endpoint Protection for 2017 and 2018 – Published: 29 September 2017 – ID: G00337106) e quindi la valutazione di come un Vendor si è posizionato nel corso degli ultimi anni e del suo Trend può essere un’informazione in sede di scelta di una soluzione di Endpoint Security.

Struttura dell’analisi

Gartner è una importante azienda nel mondo IT che si occupa di Analisi e ricerche di mercato/prodotto e advisoring e il cui obiettivo è quello di supportare le decisioni strategiche con consulenze e report che hanno lo scopo di fornire un punto di vista “super partes” sullo stato generale di un mercato, di una azienda o dei suoi prodotti.

Uno dei report prodotti da Gartner più famosi è il quadrante magico (QM) che è di semplice comprensione perché permette rapidamente di avere una panoramica, secondo Gartner, sul posizionamento che hanno gli attori del mercato. L’analisi del QM va però sempre approfondita con la lettura del documento a cui è affiancato in cui viene motivato in dettaglio le ragioni del posizionamento e che quindi vanno poi contestualizzate negli specifici scenari in cui si sta eseguendo la valutazione perché alcune motivazioni potrebbero essere poco influenti per le scelte necessarie. L’elenco dei Magic Quadrant è disponibile al seguente Gartner Magic Quadrant.

L’analisi dei Vendor di prodotti classificati da Gartner come Endpoint Protection Platforms basata sui seguenti report:

Gartner definisce la categoria Endpoint Protection Platforms come segue:

“The endpoint protection platform provides security capabilities to protect workstations, smartphones and tablets. Security and risk management leaders of endpoint protection should investigate malware detection effectiveness, performance impact on the host machines and administrative overhead.”

Nell’analisi saranno presi in considerazione i Vendor che sono stati inseriti nel report nell’anno in corso (2018) e per semplicità di verranno ordinati in base ad uno Score calcolato sulla base del QM a cui verrà attribuito il seguente valore:

  • 4 = Leaders
  • 3 = Challengers
  • 2 = Visionaries
  • 1 = Niche Players
  • 0 = Non Classificato

Lo Score attributo a ciascun Vendor, sulla base del quale sono stati ordinati dal valore maggiore a minore, è stato ottenuto con la seguente formula per pesare maggiormente il valore del QM degli ultimi anni:

  • Se QM 2018 > 0 allora lo Score vale (100* QM 2018) + (10 * QM 2017) + QM 2016
  • Se QM 2018 = 0 allora lo Score vale 0

L’obbiettivo è quello di ottenere una classifica del Vendor di soluzioni EPP ordinata in base al miglior posizionamento nei quadrante Gartner nel triennio e in base al miglior Trend di posizionamento nel corso degli anni.

Di seguito i tre MQ di gartner sulla base dei quali è stata eseguita l’analisi:

Risultato

Di seguito i Vendor ordinati in base allo Score calcolato, in base alla considerazioni precedenti dal valore maggiore al minore:

Vendor

QM 2016

QM 2017

QM 2018

Score

Trend

Sophos

4

4

4

444

«

Symantec

4

4

4

444

«

Trend Micro

4

4

4

444

«

ESET

2

1

3

312

­

Kaspersky Lab

4

4

2

244

¯

Microsoft

3

3

2

233

¯

Cylance

2

2

2

222

«

SentinelOne

2

2

2

222

«

Carbon Black

0

2

2

220

«

CrowdStrike

0

2

2

220

«

F-Secure

2

1

2

212

­

Panda Security

2

1

2

212

­

Malwarebytes

0

1

2

210

­

Cisco

0

0

2

200

Endgame

0

0

2

200

McAfee

0

0

2

200

Palo Alto Networks

0

2

1

120

¯

Bitdefender

2

1

1

112

«

Comodo

0

1

1

110

«

FireEye

0

0

1

100

Fortinet

0

0

1

100

In base alla classifica ottenuta i leader della categoria Endpoint Protection Platforms del triennio 2016-2018 sono Sophos, Symantec e Trend Micro mentre ESET sta aumentato la sua competitività.

Di seguito gli aspetti positivi dei primi 3 Vendor della classifica ottenuta evidenziati nel report Gartner del 2018:

Pro di Sophos

  • Intercept X clients report strong confidence in not only protecting against most ransomware, but also the ability to roll back the changes made by a ransomware process that escapes protection.
  • Intercept X is available as a stand-alone agent for organizations that are unable to fully migrate from their incumbent EPP vendor.
  • The exploit prevention capabilities focus on the tools, techniques and procedures that are common in many modern attacks, such as credential theft through Mimikatz.
  • The Sophos Central cloud-based administration console can also manage other aspects of the vendor’s security platform, from a single console, including disk encryption, server protection, firewall, email and web gateways.
  • Root Cause Analysis provides a simple workflow for case management and investigation for suspicious or malicious events.
  • Root Cause Analysis capabilities are available to macOS, along with protection against cryptographic malware.

Pro di Symantec

  • Symantec seems to have finally found a stable footing with its management team bringing stability across the company.
  • SEP 14 and, most recently, SEP 14.1 have proven to be very stable and efficient on resources. Clients report that the addition of ML and other advanced anti-malware capabilities have improved threat and malicious software detection, and containment.
  • Symantec ATP, its EDR-focused solution, provides good capabilities for detection and response, and existing SEP customers will benefit from its use of the existing SEP agent.
  • Symantec has started to embrace a cloud-first strategy with the introduction of its latest product updates, including SEP Cloud and EDR Cloud, which provide a cloud-based console with feature parity to the on-premises management console.
  • Symantec’s broad deployment across a very large deployment population of both consumer and business endpoints provides it with a very wide view into the threat landscape across many verticals.

Pro di Trend Micro

  • Trend Micro participates in a wide range of third-party tests, with good results overall, and the OfficeScan client delivers functionality that other traditional vendors provide in their separate EDR add-on, such as IOA-driven behavioral detection.
  • The virtual patching capabilities can reduce pressure on IT operational teams, allowing them to adhere to a strategic patch management strategy without compromising on security.
  • For customers looking for a single strategic vendor, Trend Micro has strong integration across the endpoint, gateway and network solutions to enable real-time policy updates and posture adjustments.
  • Trend Micro offers managed detection and response services, in its Advanced Threat Assessment Service, to augment the technology with expert analysis and best practices.

Di seguito invece gli aspetti negativi dei Vendor che hanno avuto un trend in discesa rispetto al 2017, inteso come cambio di quadrante, evidenziati nel report Gartner del 2018.

Contro di Kaspersky Lab secondo Gartner

  • Gartner clients report that the management console, Kaspersky Security Center, can appear complex and overwhelming, especially when compared to the fluid, user-centric design of newer EPP and EDR vendor management consoles.
  • The mainstream EDR capabilities were introduced into the Kaspersky Anti Targeted Attack Platform in late 2017, one of the last vendors to begin adding these features.
  • The EDR investigation lacks step-by-step, guided investigations for less experienced organizations, but Kaspersky Lab can provide training on using its products for advanced topics like digital forensics, malware analysis and incident response.
  • The Kaspersky Endpoint Security Cloud — a cloud-based management solution — is currently available only for SMB customers. Larger organizations looking for cloud-based management must deploy and maintain the management server in AWS or Azure.

Conro di Microsoft secondo Gartner

  • The biggest challenge continues to be the scattered security controls, management servers, reporting engines and dashboards. Microsoft is beginning to center its future management and reporting around the Windows Defender Security Center platform, which is the management interface for the whole Windows Defender suite, including ATP. Microsoft Intune is replacing System Center as the primary management tool.
  • To access advanced security capabilities, organizations need to sign up for the E5 tier subscription, which clients report as being more expensive than competitive EPP and EDR offerings, reducing the solution set’s overall appeal.
  • Microsoft relies on third-party vendors to provide malware prevention, EDR and other functionality on non-Windows platforms, which may lead to disparate visibility and remediation capabilities and additional operational complexities.
  • The advanced security capabilities are only available when organizations migrate to Windows 10. It does much less to address all other Windows platforms currently in operation.

Contro di Palo Alto Networks secondo Gartner

  • There is currently no cloud-based management option; customers must use an on-premises management server.
  • While Traps collects endpoint forensics data, it does not provide any response capabilities or postevent remediation tools. Organizations that do not use a Palo Alto Networks NGFW will need to take a multivendor approach to gain these capabilities.
  • Traps lacks EDR capabilities beyond simple IOC searching, making investigation hard without an additional product.
  • Palo Alto Networks acquired LightCyber in early 2017, but has not yet used the technology to improve the limited detection and response capabilities in Traps.
  • Traps displayed a high rate of false positives in AV-TEST testing between August and October 2017.

Conclusioni

Ovviamente come già scritto precedente prima di trarre conclusioni è necessaria la lettura del documento a cui è affiancato il QM Gartner, inoltre le considerazioni relative ai vendor ovviamente prendono in esame la situazione che vi era alla data di pubblicazione del report, quindi, ad esempio, nel caso del QM Gartner del 2018 ovviamente alcune affermazioni relative a funzionalità del prodotto o alle scelte tecno – commerciali del Vendor che hanno portato al posizionamento potrebbero non essere corrette se valutate dopo il 24 gennaio 2018.

L’analisi dell’evoluzione del posizionamento nel quadrante sulla base della formula che abbiamo proposto può ovviamente non essere condivisibile, ma sicuramente la valutazione del Vendor sulla base di più report può aiutare a determinare la scelta di un prodotto della categoria Endpoint Protection Platforms che dovrà essere utilizzato per alcuni anni sebbene debba essere impiegato per gestire una delle problematiche IT più dinamiche come la protezione di workstations, smartphones e tablets da rischi di sicurezza. In ogni caso la classifica può essere rivista inserendo nel calcolo dello Score dei parametri che vadano a pesare la presenza e l’implementazione di determinate funzionalità indispensabili nell’infrastruttura IT oggetto della valutazione.

L’analisi che abbiamo proposto può quindi essere utilizzata come metro di valutazione per la scelta di una soluzione EPP, ma anche come parametro di confronto per valutare una soluzione presentata durante un incontro commerciale o ancora come strumento per giustificare le propria scelta nei confronti della Direzione aziendale.

Utilizzo di Azure DNS per la validazione automatica di Let’s Encrypt

Facebooktwittergoogle_plusredditlinkedin

In ICTPower ci siamo occupati a più riprese della Certification Authority Let’s Encrypt, ed abbiamo visto come è possibile utilizzarla in diversi scenari.

In Ambienti OpenSource, con la validazione basata su Apache, In un altro articolo abbiamo proposto lo scenario che si può utilizzare con IIS come base per la validazione.

In questo articolo vediamo quali sono le modalità di validazione per il rilascio ed il rinnovo dei certificati sulla base di ambienti DNS, in questo modo è possibile utilizzare un servizio DNS, anche in hosting, per la gestione del ciclo di vita dei certificati gestiti da Let’s Encrypt. Le procedure proposte si basano sul client Win-Acme (WACS) e quindi in ambiente Windows.

Let’s Encrypt utilizza, analogamente a quanto visto per la validazione tramite servizi WEB, un’automazione che provvede a gestire determinati record all’interno del DNS.

Figura 1 Validazione tramite servizio DNS generico

Nella figura 1 è riportato un esempio di come Win-Acme, tramite le opzioni avanzate, permette di utilizzare il DNS per la validazione.

Nell’esempio sopra Win-Acme ricerca uno script a cui passare “hostname, record name e token“, e se opportunamente eseguito interagisce con il servizio DNS in modo da “scrivere” all’interno queste informazioni che lette dalla CA prima del rilascio del certificato, attestano che il richiedente è il reale proprietario del dominio.

E’ quindi chiaro che la disponibilità da parte del fornitore del servizio DNS ad una gestione automatizzata è fondamentale.

Nel panorama Italiano, Aruba non permette questo tipo di automazione (almeno da richiesta fatta al supporto tecnico nel mese di febbraio 2018), ma come vedremo in seguito questo non è necessariamente un limite.

Esistono diversi gestori di servizi DNS che rilasciano nelle gallery relative alle automazioni, script nati per far interagire i client CertBot con il loro DNS in modo da automatizzare le richieste verso Let’s Encrypt.

La maggioranza delle automazioni finora sono relative ad ambienti Linux.

Nel nostro caso utilizziamo invece Azure-DNS per la validazione da parte della CA, non ci occuperemo di come effettuare la delega al servizio Azure della risoluzione per il dominio, questa attività è trattata in dettaglio in questo articolo e si presuppone sia già stata effettuata.

Prima di procedere con la richiesta del certificato vero e proprio è necessario configurare il servizio Azure-DNS in modo che permetta l’accesso ad un “utente” con le credenziali minime per poter creare e cancellare record all’interno del Database DNS.

Questa tipologia di accesso è possibile con la creazione di un Service Principal Account
che possiamo definire come una identità di livello applicativo.

     Assign permissions to the app identity that are different than your own permissions. Typically, these permissions are restricted to exactly what the app needs to do.

Per poter creare una identità di questo tipo possiamo utilizzare Azure Powershell e con l’utilizzo di alcune command let procedere alla sua creazione, l’accesso all’ambiente PS avviene direttamente dal portale Azure

Figura 2 accesso alla Cloud Shell

La preparazione dell’ambiente non è immediata e può richiedere anche più di un minuto, terminato l’accesso, disponiamo di un ambiente comandi direttamente sulla sottoscrizione.

Per procedere alla creazione del Principal account che verrà utilizzato per l’automazione è sufficiente utilizzare questi comandi

$Password = ConvertTo-SecureString -String “InserireQuiLaPassword” -AsPlainText -Force

New-AzureRmADServicePrincipal -DisplayName LetsEncrypt -Password $Password

Figura 3 creazione del service principal

In questo modo è stato creato l’account “Letsencrypt” con la relativa password ed è necessario assegnare i permessi di accesso alla zona DNS relativa al dominio per il quale stiamo richiedendo il certificato

Figura 4 attribuzione dei permessi

Accedendo alla gestione della zona robimassa.cloud tramite Access Control (IAM) si attribuisce il ruolo di DNS Zone Contributor al Service Principal Letsencrypt creato in precedenza.

La preparazione dell’ambiente relativo al servizio DNS è completata e prima di procedere alla generazione del certificato è utile recuperare alcune informazioni che saranno poi richieste dal client Win-Acme.

  • Tenant ID (directory ID) ossia l’identificativo della Directory a cui ci stiamo riferendo
  • Client ID l’identificativo del Service Principal creato prima
  • Secret la password definita per il Principal
  • DNS Subscription ID l’identificativo del Servizio DNS in questo caso (robimassa.cloud)
  • DNS Resource Group Name il resource group definito per la risorsa DNS pubblica

In questa guida si fa riferimento al dominio robimassa.cloud, forse è superfluo specificarlo, ma il dominio DEVE essere un dominio pubblico regolarmente raggiungibile e quindi acquistato tramite i normali canali commerciali, nello specifico questo dominio è stato acquistato da Aruba.

Generazione del certificato

Il client Win-Acme dovrà essere eseguito con l’opzione –centralsslstore in modo da permettere l’archiviazione dei certificati (SAN o singolo Host) all’interno di una cartella, questo è necessario nel nostro caso in quanto i certificati rilasciati non vengono associati in automatico ad un Host Web, ma sono archiviati per un utilizzo successivo.

letsencrypt.exe –centralsslstore C:\letsencrypt-san\

vengono richieste a questo punto le impostazioni di base che sono quelle viste in figura 1 ad eccezione della validazione, per la quale dovremo selezionare l’opzione 1 ossia [dns-01] Azure DNS

Figura 5 richiesta validazione su Azure DNS

Proseguendo dovremo fornire le indicazioni relative all’accesso automatico del client come riportato sopra, ed al termine completata l’esecuzione, verranno salvati i certificati nella directory.

Figura 6 richiesta certificato

A questo punto il certificato è correttamente salvato in formato pfx e disponibile ad essere utilizzato, può ancora essere definito un utente con cui verrà eseguita periodicamente la task di rinnovo.

Se fosse necessario verificare i certificati emessi è possibile, sempre client Win-Acme la procedure di verifica.

Figura 7 verifica dei certificati emessi

Riferimenti

Generazione di certificati SAN con Let’s Encrypt ed utilizzo in Microsoft Exchange

Facebooktwittergoogle_plusredditlinkedin

Come abbiamo già avuto modo di analizzare in articoli precedenti, Let’s Encrypt, in quanto CA, permette anche il rilascio di certificati di tipo SAN (Subjet Alternative Names), ossia certificati che sono emessi e quindi sono validi per più nomi host di uno stesso dominio oppure per nomi host differenti di domini differenti.

La possibilità di ottenere certificati come indicato, non è da confondere con l’emissione di certificati di tipo Wildcard (*) ossia di un certificato valido per tutti gli host di un singolo dominio

Sono esempi di certificati di tipo SAN rilasciati da Let’s Encrypt i seguenti

  • mail.robimassa.cloud
  • autodiscover.robimassa.cloud

esempi di certificati per uno stesso dominio ma per host differenti

  • web.robimassa.it
  • portale.robimassa.cloud

esempi di certificati per host in domini differenti.

Per quanto riguarda i certificati Wildcard, Let’s Encrypt ha annunciato che nel gennaio del 2018 avrebbe emesso questo tipo di certificati, ma recentemente stato pubblicato un annuncio che informa dello slittamento del rilascio di questa funzione.

Exchange può utilizzare certificati di questo tipo emessi da Let’s Encrypt

Nel caso di questo sevizio, per l’accesso alle risorse mail dobbiamo dichiarare in DNS un record di tipo “A” riferito al portale webmail, ed un record, sempre di tipo “A” con nome autodiscover

Per una descrizione più dettagliata sull’uso e sulla funzione di questa informazione dichiarata in DNS è possibile leggere l’articolo Autodiscover service

In modo molto semplicistico possiamo dire che l’informazione ottenuta con “autodiscover” sia essa in un record di tipo A o in un record di tipo SRV permette una identificazione automatica di risorse di servizi di collaborazione come Exchange a partire da un indirizzo mail in formato utente@dominio.com.

Fatta questa premessa, passiamo ad analizzare in quale modalità è possibile ottenere certificati di tipo SAN con Let’s Encrypt

In ambiente Windows è utilizzabile il tool Let’s Encrypt-win-simple di Lone Coder, che proprio recentemente ha cambiato il nome del proprio programma

New name

This is the first release of this program under a new name. Going forward we will call it “Windows ACME Simple”, which can be shortened to “win-acme” or “WACS”. The reason is that we want to avoid any confusion people might have about this programs relationship with the ISRG sponsored Let’s Encrypt project.

To be clear, we are not an ISRG supported client, just an independent group of people who want to help people managing Microsoft Windows machines to secure the web.

Let’s Encrypt literally wrote the book on the ACME protocol and is obviously the most popular service implementing it, but in fact everyone is free to run their own ACME server and we might see a lot more of them in the future. Therefore it also makes sense to drop “Let’s Encrypt” from the name of this program.

Per effettuare la richiesta del certificato alla CA è necessario scaricare il tool da github e copiarlo localmente per poi estrarre il contenuto.

Il client ACME (Automatic Certificate Management Environment) quale è appunto win-acme, è gestibile a riga di comando, pertanto dovremo prima creare una cartella in cui saranno salvati i certificati in formato .pfx rilasciati dalla CA e successivamente eseguire il comando letsencrypt.exe –centralsslstore C:\letsencrypt-san\

L’opzione –centralsslstore è utilizzata per
definire il percorso per il salvataggio dei certificati che dovranno poi essere importati in Exchange tramite Powershell

Figura 1 richiesta certificato

Dovremo selezionare la modalità per il rilascio di nuovi certificati con opzioni avanzate “M” e successivamente specificare i vari nomi fqdn per cui stiamo richiedendo i certificati, ognuno separato da virgola nell’esempio che è indicato la richiesta è per l’host mail.robimassa.cloud ed autodiscover.robimassa.cloud

Figura 2 Impostazioni per la validazione

Successivamente verrà chiesta la modalità di validazione, ed il modo più rapido, se si esegue la richiesta dei certificati da un server IIS, è di consentire la verifica automatica direttamente tramite il server Web.

Procedendo con la richiesta vera e propria, e conclusa la procedura, nella cartella C:\letsencrypt-san\ troviamo i due certificati in formato PFX, uno per sito.

Sarà sufficiente procedere all’importazione del certificato in IIS che verrà utilizzato per OWA

Figura 3importazione certificato in IIS

Oppure in caso di sistemi distribuiti su più Web Server Bilanciati, utilizzare la funzione di centralized ssl certificate support a questo punto il https è attivo con il certificato SAN segnato per i due host

Importazione del certificato in Exchange

Per quanto riguarda invece l’importazione dei certificati in Exchange sarà necessario eseguire il cmd-let Powershell Import-ExchangeCertificate come descritto in questo articolo.

Metodi di validazione alternativi

Esistono altri metodi di validazione da parte di Lets’Encrypt per determinare che il richiedente del certificato sia effettivamente il proprietario del dominio, uno di questi è il metodo basato su DNS.

Il client Acme in questo caso si deve “appoggiare” ad un programma esterno che ricevendo in input I parametri corretti si occupa di creare sul DNS il TXT record opportunamente configurato. Questo record, sarà poi letto dalla CA prima dell’emissione dei certificati.

Siccome il processo di rinnovo è automatizzato e quindi eseguito periodicamente alla scadenza dei certificati, il servizio DNS deve poter consentire un interoperabilità di questo tipo.

E’ consigliabile quindi la verifica della disponibiltà di automazione da parte del DNS.

Figura 4 validazione tramite DNS

Figura 5 certificato SAN

Considerazioni

Anche in questo caso Let’s Encrypt si dimostra una Certification Authority che in modo gratuito permette di attivare i protocolli di sicurezza sui propri servizi. Come già detto in precedenza, è di prossimo rilascio l’emissione di certificati WildCard, che completerà l’offerta dei servizi della CA.

Riferimenti

https://letsencrypt.org/

https://www.ictpower.it/guide/utilizzo-e-configurazione-di-lets-encrypt-in-ambiente-linuxapache.htm

General Data Protection Regulation (GDPR) e utilizzo aziendale di WhatsApp

Facebooktwittergoogle_plusredditlinkedin

WhatsApp è una delle applicazioni di messaggistica istantanea più popolari e il suo funzionamento è così semplice da rappresentare un ottimo sostituto di SMS e MMS permettendo di inviare e ricevere messaggi di testo, chiamate, suoni, note vocali, video, fotografie, note e informazioni di contatto. La grande diffusione di WhatsApp ha talvolta fatto sì che questa venisse utilizzata anche per gestire scambio di messaggi in ambito aziendale sebbene l’applicazione sia pensata per l’utilizzo in ambito privato in quanto gli stessi produttori hanno rilasciato una versione focalizzata su scenari aziendali denominata WhatsApp Business dedicata alle piccole e medie imprese e disponibile in Italia da qualche giorno, ma solo su piattaforma Android. In vista dell’adozione del Regolamento europeo in materia di protezione dei dati personali (in inglese GDPR General Data Protection Regulation- Regolamento UE 2016/679) prevista il 25 maggio 2018 le aziende sono chiamate ad analizzare gli strumenti utilizzati per il trattamento di dati personali documentando le ragioni che hanno motivato la scelta di tali strumenti.

Per quanto riguarda la privacy di WhatsApp e in particolare la condivisione di informazioni con terze parti è possibile ricavare alcune informazioni dalle FAQ ufficiali nella sezione Generale – Avviso per utenti UE, di seguito riportiamo alcuni passi dalle seguenti:

    • “Condividiamo informazioni con il gruppo di aziende di Facebook (e con terze parti fidate) in qualità di fornitori di servizi.”
    • “Questo ci consente, ad esempio, di analizzare e capire come vengono usati i nostri servizi e come mettere i dati a confronto con l’uso all’interno del gruppo di aziende di Facebook.”
    • “Quando WhatsApp condivide informazioni con il gruppo di aziende in questi modi, il gruppo di aziende di Facebook funge da fornitore di servizi per aiutare WhatsApp e l’intero gruppo di aziende. Ciò significa che tale fornitore di servizi non può utilizzare le informazioni che condividiamo con lui per i propri scopi ma deve invece agire per conto di WhatsApp.”
    • “Se sei un utente WhatsApp dell’Unione europea, in seguito alle discussioni con il Commissario per la protezione dei dati irlandese, WhatsApp non sta ancora condividendo le tue informazioni con Facebook al fine di migliorare i tuoi prodotti Facebook o offrirti esperienze con le inserzioni più pertinenti su Facebook finché non raggiungerà un accordo con il Commissario per la protezione dei dati irlandese su un meccanismo che in futuro consentirà tale utilizzo.”
    • “Se eri già un utente WhatsApp ad agosto 2016, quando è stato effettuato l’aggiornamento, avevi la possibilità di usare un comando per impedire a Facebook di usare le tue informazioni per migliorare i tuoi prodotti Facebook e offrirti esperienze con le inserzioni più pertinenti su Facebook, un nuovo scopo incluso nei Termini di servizio e nell’Informativa sulla privacy aggiornati. Gli utenti esistenti hanno avuto a disposizione 30 giorni per prendere questa decisione a partire dal primo accesso al loro account in seguito all’aggiornamento di agosto 2016.”
    • “Se hai effettuato l’iscrizione a WhatsApp in seguito all’aggiornamento di agosto 2016, non ti è stata offerta questa possibilità perché hai aderito al servizio in un momento in cui WhatsApp faceva già parte del gruppo di aziende di Facebook e quando hai iniziato a usare WhatsApp erano già in vigore i Termini di servizio e l’Informativa sulla privacy relativi a questi usi delle tue informazioni.”
    • “Se cambi idea in merito ai Termini di servizio e all’Informativa sulla privacy dopo aver aderito a WhatsApp, puoi smettere di usare i nostri servizi ed eliminare il tuo account tramite la funzione “Elimina il mio account” nell’app. WhatsApp eliminerà le tue informazioni e anche le informazioni condivise con Facebook e con gli altri membri del gruppo di aziende di Facebook.”
    • “Ecco in cosa consistono le informazioni: il numero di telefono che hai verificato al momento dell’iscrizione a WhatsApp, alcune informazioni sul tuo dispositivo (identificatore del dispositivo, versione del sistema operativo, versione dell’app, informazioni sulla piattaforma, codice Paese e codice di rete del cellulare e contrassegni per il monitoraggio dell’accettazione dell’aggiornamento e dei comandi scelti), alcune informazioni sull’uso (quando hai usato WhatsApp l’ultima volta, la data in cui hai registrato l’account per la prima volta, il tipo di funzioni che usi e con quale frequenza).”
    • “WhatsApp non condivide i tuoi contatti di WhatsApp con Facebook né con altri membri del gruppo di Facebook e non intendiamo farlo in futuro. Inoltre, WhatsApp non condivide i tuoi messaggi con Facebook. In più, WhatsApp non può leggere i tuoi messaggi perché sono crittografati end-to-end per impostazione predefinita se tu e le persone con cui scambi messaggi utilizzate la versione più recente dell’app. Solo le persone con cui scambi messaggi possono leggere i tuoi messaggi; non può farlo WhatsApp, né Facebook, né nessun altro.”
    • “Le informazioni descritte qui possono essere condivise per gli scopi specifici descritti nel presente documento per tutti gli utenti di WhatsApp che decidono di usare il servizio WhatsApp e accettano i nostri Termini di servizio e l’Informativa sulla privacy. Potrebbero essere inclusi anche gli utenti WhatsApp che non sono utenti Facebook poiché, se necessario, dobbiamo avere la possibilità di condividere le informazioni per tutti gli utenti in modo da poter ricevere servizi utili dal gruppo di aziende di Facebook e soddisfare gli scopi importanti spiegati qui.”

Quindi per quando riguarda la gestione della condivisione d’informazioni da parte di WhatsApp con terze parti si può sintetizzare quanto segue:

  • WhatsApp condivide informazioni con il gruppo di aziende di Facebook e con terze parti che ritiene fidate.
  • Per gli utenti dell’Unione europea, WhatsApp non sta ancora condividendo le informazioni con Facebook, in seguito alle discussioni con il Commissario per la protezione dei dati irlandese.
  • Gli altri utenti non appartenenti all’Unione europea che non si desiderano tale condivisione d’informazioni devono eliminare l’account WhatsApp, ovvero non utilizzare WhatsApp
  • Le informazioni che vengono condivise possono consentire l’identificazione dell’utilizzatore (numero di telefono, identificatore del dispositivo, versione del sistema operativo, versione dell’app, informazioni sulla piattaforma, codice Paese e codice di rete del cellulare) e la sua profilazione circa dell’utilizzo dell’applicazione (data ultimo utilizzo, data registrazione dell’account, tipo di funzioni utilizzate e frequenza di utilizzo)

La condivisione dei dati con il gruppo di aziende di Facebook da parte di WhatsApp è già stata oggetto di attenzione più volte si vedano ad esempio:

    • “Il Garante per la protezione dei dati personali ha avviato un’istruttoria a seguito della modifica della privacy policy effettuata da WhatsApp a fine agosto che prevede la messa a disposizione di Facebook di alcune informazioni riguardanti gli account dei singoli utenti di WhatsApp, anche per finalità di marketing.”
    • “The WP29 notes the new “Notice for EU users” published by WhatsApp on 16 August 2017 among the “Frequently asked questions” (“FAQ”) on its website. This notice provides certain additional information regarding the nature and purposes of the sharing of personal data by WhatsApp with the Facebook family of companies. The publication of this Notice does not, however, sufficiently address the issues of non-compliance with data protection law. Whilst the WP29 notes that the data protection issues of non-compliance arising in this case have already been clearly explained to both WhatsApp and Facebook, a further explanation of how the actions of the respective parties are considered deficient is detailed below.”

Per quanto riguarda invece la sicurezza di WhatsApp come tutte le applicazioni software può essere soggetta a vulnerabilità dirette o indirette dovute ad esempio al sistema operativo dello smartphone su cui viene eseguita. Scendendo nei nettagli le vulnerabilità documentate relative a WhatsApp sono state la CVE-2015-1157 del 27 maggio 2015 e la CVE-2017-8769 del 18 maggio 2017 (anche se il vendor non la riconosce come security issues), mentre il 6 gennaio 2018 i ricercatori Rösler, Mainka e Schwenk della Ruhr-University Bochum hanno pubblicato un’analisi relativa ad una vulnerabilità a carico delle chat di gruppo (More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema), a riguardo si veda l’articolo WhatsApp Security Flaws Could Allow Snoops to Slide Into Group Chats pubblicato da Wired.

L’adozione GDPR implicherà una serie di problematiche che imprese e soggetti pubblici dovranno tenere presenti, a riguardo si veda la Guida all’applicazione del Regolamento europeo in materia di protezione dei dati personali. Infatti come sintetizzato nell’Libro Bianco: “Il Futuro della Cybersecurity in Italia: Ambiti Progettuali Strategici” del 2018, pubblicato dal CINI (Consorzio Interuniversitario Nazionale per l’Informatica) nella sezione del sito dedicata al LIBRO BIANCO SULLA CYBERSECURITY, il GDPR introdurrà le seguenti novità:

  • “General Data Protection Regulation (GDPR) o Regolamento generale sulla protezione dei dati che è stata introdotta nel regolamento UE 2016/6791 del 27 aprile 2016 e che abroga la precedente direttiva 95/46/CE.”
  • “La direttiva 95/46/CE e la normativa GDPR sono profondamente diverse: la prima prevedeva una serie di prescrizioni, assimilabili a una check list, mentre la seconda indica gli obiettivi da raggiungere, lasciando alla discrezionalità degli operatori la scelta degli strumenti più opportuni in relazione al contesto, ma impone al contempo l’obbligo di documentare le ragioni che hanno motivato tali scelte.”
  • “Premesso che per dati personali si intendono tutte le informazioni relative a un individuo e alla sua figura professionale e pubblica, il concetto di protezione dei dati che caratterizza il GDPR comprende anche gli obblighi relativi alla loro gestione, che riguardano sia la sicurezza sia ambiti ulteriori come la conservazione, la riservatezza, l’anonimizzazione e la cancellazione a richiesta del soggetto interessato.”
  • “Il GDPR distingue tra il titolare del trattamento (ovvero il controller della versione inglese), il responsabile del trattamento (in inglese il processor) e il soggetto interessato, vale a dire il soggetto a cui i dati si riferiscono.”
  • Il nuovo regolamento rivede il concetto di accountability (responsabilizzazione): la responsabilità del trattamento è in capo al titolare del trattamento e non al responsabile del trattamento (che è il processor).”
  • “Il GDPR impone, inoltre, l’applicazione del principio della data protection by design che richiede di considerare la protezione dei dati fin dalla fase di ideazione e progettazione di un sistema per il trattamento o la gestione di dati personali, coinvolgendo quanti si occupano dello sviluppo di servizi, prodotti, applicazioni che fanno uso di dati personali.”
  • “Poiché nessuna banca dati è sicura in Internet, alcuni dei principi fondamentali del GDPR sono proprio volti a limitare il campo di esposizione ai rischi:
    • minimizzazione dei dati — raccolgo solo i dati necessari e non altri;
    • limitazione delle finalità — non posso decidere di fare ciò che voglio dei dati, ma solo perseguire la finalità per cui li ho raccolti;
    • limitazione della conservazione — sono chiamato a eliminare i dati appena finisce lo scopo per cui li ho raccolti.”
  • Le aziende che non si adeguano alle previsioni del GDPR entro la scadenza sono soggette a sanzioni fino a 20 milioni di euro, o fino al 4% del volume d’affari globale registrato nell’anno precedente. È inoltre previsto il diritto all’azione risarcitoria da parte di chiunque subisca un danno materiale o immateriale causato dalla violazione della normativa.”

Inoltre come indicato nei documento della Guida all’applicazione del Regolamento europeo in materia di protezione dei dati personali occorre anche tenere presente le seguenti:

    • “In particolare, occorre verificare che la richiesta di consenso sia chiaramente distinguibile da altre richieste o dichiarazioni rivolte all’interessato (art. 7.2), per esempio all’interno di modulistica. Prestare attenzione alla formula utilizzata per chiedere il consenso: deve essere comprensibile, semplice, chiara (art. 7.2). I soggetti pubblici non devono, di regola, chiedere il consenso per il trattamento dei dati personali (si vedano considerando 43, art. 9, altre disposizioni del Codice: artt. 18, 20).”
    • il titolare DEVE SEMPRE specificare i dati di contatto del RPD-DPO (Responsabile della protezione dei dati-Data Protection Officer), ove esistente, la base giuridica del trattamento, qual è il suo interesse legittimo se quest’ultimo costituisce la base giuridica del trattamento, nonché se trasferisce i dati personali in Paesi terzi
      e, in caso affermativo, attraverso quali strumenti (esempio: si tratta di un Paese terzo giudicato adeguato dalla Commissione europea; si utilizzano BCR di gruppo; sono state inserite specifiche clausole contrattuali modello, ecc.).”
    • “Il diritto di accesso prevede in ogni caso il diritto di ricevere una copia dei dati personali oggetto di trattamento.”
    • “il titolare deve essere in grado di trasferire direttamente i dati portabili a un altro titolare indicato dall’interessato, se tecnicamente possibile.”

Quindi il GDPR implicherà per aziende e pubbliche amministrazioni un cambio di approccio nella gestione dell’adozione di soluzioni software tramite cui si eseguano attività di trattamento di dati personali, ed in particolare vanno tenute in considerazione le seguenti:

  • obbligo di documentare le ragioni che hanno motivato la scelta della soluzione software;
  • gestione dei dati personali (informazioni relative a un individuo e alla sua figura professionale e pubblica) implica occuparsi della sicurezza, conservazione, riservatezza, anonimizzazione e cancellazione a richiesta del soggetto interessato;
  • applicazione del principio della data protection by design;
  • limitazione dell’esposizione ai rischi che si traduce in scelte che rispettino la minimizzazione dei dati raccolti, la limitazione delle finalità e la limitazione della conservazione;
  • la richiesta di consenso deve essere chiaramente distinguibile, comprensibile, semplice e chiara;
  • occorre specificare la base giuridica del trattamento e se e tramite quali strumenti
    avvengono trasferimenti di dati personali in Paesi terzi
  • occorre prevedere la possibilità che il soggetto interessato possa ricevere una copia dei dati personali oggetto di trattamento

Tornando quindi al tema dell’articolo e quindi se dal punto di vista aziendale l’utilizzo di WhatsApp sia o meno adottabile nell’ottica del rispetto del GDPR ovviamente non esiste una risposta definitiva, ma occorre un’attenta valutazione dello scenario d’uso. In ogni caso ciò che deve guidare la scelta di adottare o meno una soluzione è il principio del data protection by design e la limitazione dell’esposizione ai rischi.

Quindi si può in prima approssimazione affermare che se l’adozione di WhatsApp è motivata principalmente dalla volontà di utilizzare un mezzo di comunicazione più comodo o pratico rispetto ad altri esistenti (mail, PEC, sms, sito web aziendale/istituzionale) in cui la gestione della sicurezza, la limitazione dell’esposizione a rischi siano di più semplice gestione l’utilizzo di WhatsApp non è consigliabile in quanto verrebbe meno il principio del data protection by design.

WhatsApp condivide informazioni con il gruppo di aziende di Facebook e con terze parti (anche se al momento per utenti dell’Unione europea tale condivisione non è ancora attiva) quindi può risultare difficile o non possibile soddisfare il requisito del “diritto di accesso”, del “diritto all’oblio” e della “portabilità dei dati” richiesti dal GDPR. Infatti l’utilizzo di WhatsApp comporta che la rubrica di un utente con tutti i contatti, inclusi indirizzi e-mail e numeri di telefono, viene trasferita su WhatsApp e quindi su FaceBook (gli utenti UE sono al mento esclusi dal trasferimento su FaceBook) e questo comporta anche che occorre avere il consenso esplicito per trasferire dati personali a WhatsApp.

Utilizzare la Azure Multi-Factor Authentication con Remote Desktop Gateway in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Come avete visto nella guida Configurare Remote Desktop Gateway in Windows Server 2016, l’accesso da Internet alle risorse aziendali, alle RemoteApp e al desktop remoto dei server è enormemente semplificato dall’installazione del Remote Desktop Gateway. RD Gateway inoltre garantisce che le comunicazioni tra Internet e le risorse della rete aziendale siano sicure, grazie all’utilizzo del protocollo HTTPS per incapsulare il traffico RDP.

Ma poiché la sicurezza non è mai troppa, poiché gli utenti possono salvare le credenziali di connessione e perdere i dispositivi da cui si connettono, poiché dobbiamo difendere le nostre risorse aziendali, in questa guida vi illustrerò come implementare la Multi-Factor Authenticazion con il Remote Desktop Gateway.

Utilizzando infatti Microsoft Azure Multi-Factor Authentication Server, l’utente per potersi autenticare dovrà inserire le proprie credenziali e una one-time password (oppure un PIN, rispondere ad un SMS, rispondere ad una telefonata, utilizzare token hardware, ecc…)

La procedura di autenticazione sarà quindi:

  1. L’utente si collega al portale web delle RemoteApp e inserisce le proprie credenziali
  2. L’utente fa doppio clic sull’icona dell’applicazione per lanciare la RemoteApp
  3. Se è stato abilitato il Web SSO sul Remote Desktop Web Access non verrà chieste all’utente di reinserire le credenziali di accesso alla RemoteApp
  4. L’utente riceve una telefonata oppure un SMS o una one-time password dal suo token (secondo fattore di autenticazione)
  5. L’utente è autenticato e la RemoteApp si apre

Come funziona la Multifactor Authentication (MFA) con il Remote Desktop Gateway

Il Remote Desktop Gateway utilizza un server NPS (Network Policy Services) per poter autenticare ed autorizzare gli accessi. Il servizio NPS è installato quando installate il ruolo RD Gateway e dovete creare una Remote Desktop Connection Authorization Policy (RD CAP) ed una Remote Desktop Connection Authorization Policy (RD CAP) per permettere agli utenti di potersi loggare e accedere alla rete interna.

Il processo di autenticazione infatti funziona in questo modo:

  1. Le credenziali dell’utente vengono inviate al RD Gateway
  2. Il server NPS installato sull’RD Gateway controlla le credenziali e verifica se l’utente è abilitato ad entrare controllando le Remote Desktop Connection Authorization Policy (RD CAP)
  3. Se le credenziali sono valide, il server RD Gateway controlla le Remote Desktop Connection Authorization Policy (RD CAP) per capire verso quali risorse della rete interna permettere l’accesso all’utente

Se invece aggiungete un Multi-Factor Authentication Server (MFA) il processo di autenticazione sarà diverso e seguirà queste fasi:

  1. Le credenziali dell’utente vengono inviate al RD Gateway
  2. Il server NPS controlla le credenziali e vede se l’utente è abilitato ad entrare controllando le Remote Desktop Connection Authorization Policy (RD CAP)
  3. Se le credenziali sono valide, il server NPS invia la richiesta di login al server MFA
  4. Il server MFA invia un sms o telefona all’utente (dipende da come avete deciso di impostare voi il controllo)
  5. Il server MFA riceve dall’utente la risposta (ad esempio il PIN corretto)
  6. Il server MFA comunica al server NPS che l’utente può/non può accedere
  7. Il server RD Gateway controlla Remote Desktop Connection Authorization Policy (RD CAP) per capire verso quali risorse della rete interna permettere l’accesso all’utente

Figura 1: Sequenza dell’autenticazione effettuata tramite un Multi-Factor Authentication Server (MFA)

In questa guida utilizzerò il Microsoft Azure Multi-Factor Authentication Server (MFA) installato nella infrastruttura aziendale, quindi on-premises. Sul server MFA ho installato Windows Server 2016 e l’ho aggiunto al mio dominio demo.lab.

Prerequisiti

I prerequisiti per implementare la Multi-Factor Authentication con il Remote Desktop Gateway sono:

Installazione del server Microsoft Azure Multi-Factor Authentication Server (MFA)

Per quanti di voi non avessero dimestichezza sul funzionamento della Multi-Factor Authentication e su quale tipo di autenticazione utilizzare (Server MFA on-premises, server MFA nel Cloud) consiglio di leggere l’articolo Choose the Azure Multi-Factor Authentication solution for you.

Loggatevi al portale di Microsoft Azure e selezionate Azure Active Directory e successivamente MFA Server. Dalla scheda Overview lanciate la versione di prova di Azure Active Directory Premium che vi permetterà di utilizzare la Multi-Factor Authentication, come mostrato in figura. Azure Multi-Factor Authentication è disponibile come servizio da acquistare singolarmente, che offre la possibilità di fatturare per utente e per ogni autenticazione effettuata, oppure insieme ad Azure Active Directory PremiumEnterprise Mobility Suite e Enterprise Cloud Suite.

Figura 2: Attivazione della versione di prova di Azure Multi-Factor Authentication

Cliccando sul nodo Providers, dopo aver cliccato sul pulsante Add, inserite il nome di riferimento del vostro server MFA (io ho scelto RDGW-MFA), il tipo di utilizzo e di tariffazione (per utente o per singola autenticazione) e la sottoscrizione, come mostrato in figura:

Figura 3: Creazione del Provider di autenticazione

Terminata la creazione del Provider, selezionate il server RDGW-MFA creato e dal nodo Server settings efefttuate il download del software (che installerete sulla vostra macchina on-premises) e create le credenziali di attivazione del server MFA.

Figura 4: Download del software e creazione delle credenziali di attivazione del server MFA

Dopo aver scaricato il software nella macchina che volete utilizzare come server MFA (la mia si chiama mfa01.demo.lab) lanciate il setup ed installate i prerequisiti, come mostrato in figura:

Figura 5: Installazione dei prerequisiti per il server MFA

Subito dopo l’installazione dei prerequisiti si avvierà il setup del Multi-Factor Authentication Server. Procedete all’installazione seguendo le indicazioni delle figure sotto:

Figura 6: scelta della cartella in installazione del server MFA

Figura 7: Installazione del server MFA completata

Dopo l’installazione vi verrà chiesto se volete lanciare il wizard di configurazione. Mettete il segno di spunta per poterlo saltare e fate clic su Next

Figura 8: Attivazione e configurazione manuale del server MFA

Procedete quindi all’inserimento delle credenziali di attivazione che avete generato sul portale di Azure. Prestate attenzione perché le credenziali sono valide solo per 10 minuti, quindi se non dovessero funzionare ricreatele dal portale Azure.

Figura 9: attivazione del server MFA

È possibile configurare il server MFA in modo tale che utilizzi gli utenti di Active Directory. Selezionate il pulsante Users e importate gli utenti da vostro dominio, seguendo le indicazioni mostrate nella figura sotto:

Figura 10: Importazione degli utenti di Active Directory nel vostro server MFA

Dopo aver importato gli utenti, è possibile configurarli in modo tale da scegliere per ognuno di loro un metodo di autenticazione (chiamata telefonica, SMS, PIN, App per il cellulare, ecc,.) come mostrato in figura:

Figura 11: Scelta del fattore di autenticazione per ogni utente

Adesso il vostro server Azure Multi-Factor Authentication è pronto per poter essere utilizzato.

Configurazione del Remote Desktop Gateway, del server NPS e del server MFA

Il prossimo passaggio da eseguire è configurare il Remote Desktop Gateway, il NPS ed il server MFA in modo tale che possano parlare tra di loro.

Configuriamo il server RD Gateway in modo tale che usi come server di autenticazione non più il server NPS installato sulla stessa macchina, bensì il server MFA. Sarà infatti d’ora in poi il server MFA ad essere interrogato per primo quando arriva una richiesta di connessione.

Dal Server Manager del vostro RD Gateway scegliete Tools–>Remote Desktop Services–> RD Gateway Manager. Aprite le proprietà del server RDGW e dalla scheda RD CAP Store indicate come server NPS l’indirizzo IP o il nome del vostro server MFA, come mostrato in figura:

Figura 12: Modifica del server che gestirà le policy RD CAP (Connection Authorization Policy)

Figura 13: Configurazione del nuovo server NPS completata

Configuriamo ora il server NPS che è installato sul RD Gateway in modo tale che parli con il server MFA. Entrambi utilizzeranno il protocollo RADIUS per potersi scambiare i messaggi di autenticazione. Pertanto, aggiungete come RADIUS client il vostro server MFA, configurandolo come mostrato in figura, in modo tale che possa accettare le autenticazioni RADIUS dal server MFA. Ho utilizzato come Friendly Name MFA01 (ci servirà in seguito).

Figura 14: Il server MFA diventa un RADIUS client per il server NPS

Nel momento in cui avete installato il ruolo RD Gateway si è installato anche il servizio NPS e nel nodo Remote RADIUS Server è stato creato automaticamente un gruppo di server chiamato TS GATEWAY SERVER GROUP. Dalle Proprietà selezionate il server MFA e dalla scheda Authentication/Accounting modificate le porte e lo shared secret (che dovrete poi configurare sul server MFA) come mostrato in figura:

Figura 15: Modifica delle porte e dello Shared Secret

Cliccate ora sulla scheda Load Balancing e aumentate il timeout ad almeno 60 secondi, come mostrato in figura. Questo timeout è necessario per permettere all’utente di avere il tempo di rispondere alla richiesta di seconda autenticazione (telefonata, sms, ecc…).

Figura 16: Timeout di risposta del server

Configurazione delle Policy di connessione

Sarà necessario modificare due Connection Request Policy nel server NPS: una servirà a inoltrare le richieste verso il server MFA e l’altra a ricevere le richieste che tornano dal server MFA.

Figura 17: Schema di funzionamento della verifica delle Connection Request Policy

Come prima operazione duplicate la policy di default TS GATEWAY AUTHORIZATION POLICY, come mostrato in figura:

Figura 18: Duplicazione della TS GATEWAY AUTHORIZATION POLICY

Cliccate col tasto destro sulla TS GATEWAY AUTHORIZATION POLICY originale e modificatene le condizioni. Aggiungete come Client Friendly Name il nome del RADIUS client che avete scelto prima (nel mio caso MFA01)

Figura 19: Modifica delle Conditions della TS GATEWAY AUTHORIZATION POLICY originale

Continuate a modificare la stessa policy andando nella scheda Settings e modificando l’Authentication in modo tale da scegliere Authenticate requests on this server, come mostrato in figura

Figura 20: Modifica dei Settings di Authentication della TS GATEWAY AUTHORIZATION POLICY originale

Nella scheda Settings della TS GATEWAY AUTHIRIZATION POLICY originale modificate l’Accounting, rimuovendo il segno di spunta da Forward accounting requests to this remote RADIUS server group

Figura 21: Modifica dei Settings di Accounting della TS GATEWAY AUTHORIZATION POLICY originale

Il risultato finale è quello mostrato nella figura sotto. Accertatevi che questa policy sia la prima ad essere processata!

Figura 22: Modifica delle policy originale completata

Non toccate nulla della policy che avete duplicato in precedenza (copy of TS GATEWAY AUTHIRIZATION POLICY) e assicuratevi che sia ordinata come seconda. Per chiarezza ho indicato in figura il significato delle due policy

Figura 23: Configurazione delle Network policy completata

Configurazione del server Multi-Factor Authentication

È arrivato il momento di configurare Azure Multi-Factor Authentication Server in modo tale che possa parlare con il server NPS. Spostatevi quindi sulla vostra macchina MFA e selezionate il pulsante RADIUS Authentication. Abilitate con un segno si punta la voce Enable RADIUS Authentication nella scheda Clients e aggiungete l’indirizzo IP o il nome del vostro RD Gateway (che è anche il server NPS), insieme allo Shared Secret che avete aggiunto nella Central CAP Store configuration del vostro RD Gateway Manager.

Figura 24: Configurazione del server NPS come RADIUS Client

Spostatevi nella scheda Target della stessa schermata e aggiungete lo stesso server anche come RADIUS Target, come mostrato in figura:

Figura 25: Configurazione del server NPS come RADIUS Target

La configurazione del nostro ambiente è completata. Non vi resta altro che testare il suo funzionamento.

Test di funzionamento

Per testare l’efficacia della configurazione fatta, collegatevi all’infrastruttura RDS utilizzando il portale web. Inserite le credenziali di login di un utente su cui avete abilitato la Multi-Factor Authentication e accedete al portale.

Figura 26: Login al portale web con le credenziali di un utente a cui abbiamo abilitato la Multi-Factor Authentication

Dopo aver effettuato il login, cliccate su una delle RemoteApp e lanciate la connessione.

Figura 27: Login al portale web effettuato e lancio della RemoteApp

Confermate che la connessione alla RemoteApp stia avvenendo utilizzando il Remote Desktop Gateway, come mostrato in figura:

Figura 28: Connessione alla RemoteApp attraverso il Remote Desktop Gateway

Reinserite le credenziali di login del vostro utente (se non avete abilitato il web Single Sign-on nella vostra infrastruttura RDS).

Figura 29: Reinserimento delle credenziali di login dell’ utente

A questo punto la connessione remota rimane in attesa che avvenga la verifica della vostra identità utilizzando il secondo fattore di autenticazione

Figura 30: Attesa di ricevere conferma dell’avvenuta verifica dell’identità del l’utente

Riceverete una telefonata al numero che avete inserito in Active Directory o sul server MFA. Rispondete alla telefonata e quando vi verrà chiesto confermate la vostra identità premendo il simbolo # (cancelletto – pound key) sul tastierino del telefono.

Figura 31: Telefonata per conferma dell’identità dell’utente

Finalmente la vostra identità è confermata e potrete cominciare ad utilizzare la vostra RemoteApp.

Figura 32: Apertura della RemoteApp di Word 2016

È possibile modificare il metodo di autenticazione dell’utente, scegliendolo dalla lista degli utenti presente sul Multi-Factor Authentication Server e modificandolo per esempio affinché inserisca un PIN durante la telefonata (invece che la semplice conferma alla risposta con il simbolo #) oppure risponda ad un SMS, inserendo il codice ricevuto tramite SMS più il suo PIN.

Figura 33: Inserimento di un PIN durante la telefonata di conferma

Figura 34: Inserimento di un codice + PIN tramite SMS

Figura 35: L’utente per verificare la propria identità deve rispondere all’SMS con un codice ricevuto ed il suo PIN personale

Conclusioni

La Multi-Factor Authentication ci aiuta a proteggere l’accesso ai nostri dati più importanti perché, oltre alla combinazione di username e password, richiede che venga fornita un’ulteriore prova della nostra identità. Moltissimi siti offrono la possibilità di utilizzarla (Microsoft, Facebook, Twitter, LinkedIn, Facebook, Google, Paypal per citarne solo alcuni) e adesso grazie a Azure Multi-Factor Authentication Server possiamo anche implementarla on-premises per le nostre applicazioni.

Configurare Remote Desktop Gateway in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Abbiamo visto nell’articolo Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016 come creare una Session Collection di RemoteApp e come configurare un’infrastruttura basata sui Remote Desktop Services di Windows Server 2016. In questa guida vedremo come rendere disponibile l’accesso alle applicazioni anche da Internet in maniera sicura tramite il ruolo Remote Desktop Gateway.

Il Remote Desktop Gateway è uno dei ruoli dell’infrastruttura di Remote Desktop per consente agli utenti remoti di connettersi a qualsiasi risorsa interna alla LAN da Internet, utilizzando una connessione crittografata, senza dover configurare connessioni VPN (Virtual Private Network) verso l’azienda. Il server trasmette il traffico RDP attraverso la porta 443, utilizzando un tunnel HTTP over TLS/SSL (Transport Layer Security/Secure Sockets Layer). Questo siginifica che , indipendentemente dai server remoti che vogliamo raggiungere, è sufficiente avere un unico server Remote Desktop Gateway (o più di uno per avere alta disponibilità) esposto ad Internet ed un’unica porta aperta (TCP 443) per poterci connettere a tutta l’infrastruttura aziendale.

Inoltre questo ruolo consente di configurare i criteri di autorizzazione (policy) per definire le condizioni che gli utenti remoti devono rispettare per connettersi alle risorse di rete interne. È possibile, ad esempio, specificare:

  • Utenti o gruppi autorizzati a connettersi alle risorse di rete interne
  • Risorse di rete, o gruppi di computer, a cui possono connettersi gli utenti.
  • Se i computer client debbano o meno essere membri di gruppi di sicurezza di Active Directory.
  • Se è consentito il reindirizzamento dei dispositivi (stampanti, porte USB, dischi locali del client).

Potete approfondire l’utilità di questo ruolo leggendo l’articolo Overview of Remote Desktop Gateway, che anche se un po’ datato vi darà un’idea ben chiara di tutte le funzionalità ed i vantaggi offerti dal Gateway.

Figura 1: Principio di funzionamento del Remote Desktop Gateway

Installazione del Remote Desktop Gateway (RDGW)

Per installare il Remote Desktop Gateway è sufficiente lanciare il wizard per l’aggiunta e la rimozione dei ruoli. Se volete creare delle policy di accesso al server che utilizzino i gruppi di Active Directory vi conviene aggiungere il server RDGW a dominio. Nel mio caso ho chiamato la macchina RDGW01 e l’ho aggiunta al dominio demo.lab

Figura 2: Aggiunta del ruolo Remote Desktop Services

Proseguite con il wizard fino ad arrivare alla scheda dei Role Services dei Remote Desktop Services e mettete il segno di spunta su Remote Desktop Gateway. Verranno automaticamente aggiunti tutti i ruoli e le feature necessarie al funzionamento del RDGW. Come potete notare verrà aggiunto anche il ruolo di Network Policy Server, il web server IIS e la funzione RPC over HTTP, che si occuperà di incapsulare il traffico RDP in un tunnel protetto HTTPS.

Figura 3: Aggiunta del role service e di tutte le funzionalità necessarie

Dopo pochi istanti verranno installati tutti i ruoli e le funzionalità per permettere il funzionamento del Remote Desktop Gateway.

Figura 4: installazione del ruolo Remote Desktop Gateway completata

Per poter configurare il RDGW è sufficiente lanciare la console RD Gateway Manager da Server Manager–>Tools–>Remote Desktop Services–> RD Gateway Manager

Figura 5: Console di gestione RD Gateway Manager

Per poter permettere che il traffico del vostro server RDGW sia sicuro è necessario importare ed installare nel server un certificato digitale. Sicuramente il server RDGW sarà quello che esporrete ad Internet ed è quindi necessario che il certificato digitale sia rilasciato da una Certification Authority pubblica, se volete permettere anche ad utenti non del vostro dominio di poter accedere alle applicazioni. Aprite le proprietà del server cliccando col tasto destro sul suo nome e dalla scheda SSL Certificate importate il certificato che vi site procurati preventivamente, come mostrato in figura:

Figura 6: Importazione del certificato nel RDGW

Nel mio caso ho utilizzato il certificato wildcard *.nicolaferrini.it, ma è sufficiente utilizzare un certificato che coincida con il nome del RDGW che darete ai vostri utenti.

Figura 7: Installazione del certificato completata

Per permettere ai vostri utenti di accedere al server RDGW è necessario creare una nuova Authorization Policy, che indicherà sia chi è autorizzato ad accedere alla rete interna sia a quali server specifici (risorse) è possibile accedere. Lanciate quindi il wizard come mostrato in figura:

Figura 8: wizard di creazione della Authorization Policy

Date un nome alla Remote Desktop Connection Authorization Policy (RD CAP) e cliccate su Next

Figura 9: Nome della Remote Desktop Connection Authorization Policy (RD CAP)

Decidete se gli utenti devono utilizzare per il login una password o anche una smart card e aggiungete un gruppo di utenti che avranno le autorizzazioni ad accedere al RDGW. I gruppi di utenti possono essere locali al RDGW oppure possono essere gruppi di sicurezza del vostro dominio (se il server RDGW è joinato ad un dominio):

Figura 10: Scelta del gruppo di utenti autorizzati ad accedere al RDGW

Proseguite nel wizard indicando se abilitare o disabilitare la possibilità da parte degli utenti di portare in sessione remota le risorse locali ed i dispositivi

Figura 11: Abilitazione della Device Redirection

È anche possibile specificare un limite alla durata della sessione (session timeout) oppure un limite di tempo (idle timeout) prima che la sessione utente venga chiusa, quando l’utente si disconnette invece che fare logoff.

Figura 12: Scelta di eventuali timeout per le sessioni utente

Ricontrollate le configurazioni della vostra policy Connection Authorization Policy (RD CAP) e proseguite con il wizard cliccando su Next

Figura 13: Configurazioni della Remote Desktop Connection Authorization Policy

Il wizard procede con la creazione di una Resource Authorization Policy (RD RAP), che indica quali risorse possono essere utilizzate dagli utenti che si connettono in remoto utilizzando il Remote Desktop Gateway. Potete dare alla RD RAP lo stesso nome che avete dato alla RD CAP.

Figura 14: Nome delle Remote Desktop Resource Authorization Policy (RD RAP)

Aggiungete i gruppi di utenti che dovranno essere associati alla Resource Authorization Policy (RD RAP). In genere sono gli stessi gruppi che avete indicato nella Connection Authorization Policy (RD CAP).

Figura 15: Gruppi che devono utilizzare la Resource Authorization Policy (RD RAP)

Nella schermata successiva del wizard potete scegliere a quali risorse interne alla rete (a quali computer) gli utenti potranno collegarsi in Desktop remoto. Se non avete particolari restrizioni potete anche permettere l’accesso a tutte le risorse.

Figura 16: Definizione delle risorse interne alla rete a cui è possibile accedere tramite RDGW

Scegliete a questo punto quali porte volete consentire per le connessioni. La porta RDP di default è la TCP 3389 ma se avete cambiato le porte interne dei vostri terminal server è possibile specificarle.

Figura 17: Scelta della porte su cui autorizzare le connessioni RDP

Terminate il wizard verificando di aver inserito in maniera corretta tutte le informazioni richieste per creare la Resource Authorization Policy (RD RAP).

Figura 18: Configurazione della RD RAP completata

Terminata la creazione delle due policy (RD CAP e RD RAP) potete fare clic su Close.

Figura 19: Creazione delle due policy completata

Adesso che avete terminato la configurazione del vostro Remote Desktop Gateway siete pronti per testare le vostre connessioni verso le risorse aziendali.

Verifica della connessione tramite client RDP

Per testare la connessione tramite client RDP di Windows basta aprire il Remote Desktop Connection client (mstsc.exe) e dalla scheda Advanced configurare la sezione Connect from anywhere, cliccando su Settings e configurando il client con le impostazioni visibili in figura:

Figura 20: configurazione del Remote Desktop gateway nel Connection client

Nel momento in cui cercherete di connettervi vi verrà chiesto di fornire le credenziali di accesso al server RDGW e successivamente le credenziali per connettervi al server di destinazione. Le credenziali da inserire possono coincidere oppure posso differire. Tutto dipende da come avete impostato le regole di connessione. Ad esempio, supponiamo che vogliate connettervi, da Internet e attraverso il vostro RDGW, al domain controller. Per connettervi al RDGW potreste usare le credenziali di un utente locale del RDGW o di un utente del dominio, mentre per accedere al domain controller potreste utilizzare le credenziali di un utente privilegiato.

Figura 21: inserimento delle credenziali di accesso a Remote Desktop Gateway

Figura 22: Inserimento delle credenziali di accesso al computer di destinazione

Se le credenziali saranno state inserite correttamente avrete il warning relativo al certificato presentato dal server di destinazione (nel mio caso DC01.demo.lab) e potrete accedere al suo desktop.

Figura 23: connessione effettuata al server di destinazione

Per verificare che effettivamente siate collegati al server remoto (nel mio caso il domainc ontroller) utilizzando il Remote desktop gateway potete utilizzare il comando netstat –na | find “443” | find “ESTABLISHED”, che vi mostrerà tutte le connessioni riuscite che utilizzando la porta indicata

Figura 24: Utilizzo del comando Netstat per la verifica della connessione attraverso al porta 443

Configurazione del Remote Desktop Gateway in una infrastruttura di Remote Desktop Services esistente

Per aggiungere il Remote Desktop Gateway appena creato ad una infrastruttura esistente, come ad esempio quella presentata nell’articolo Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016, in cui abbiamo realizzato un Session-based deployment, è sufficiente aggiungere al server Manager il server di Connection Broker in modo tale da poterlo amministrare da remoto. Maggiori informazioni su come amministrare un serve remoto sono reperibili leggendo l’articolo add Servers to Server Manager

Dal Server Manager selezionate il nodo dei Remote Desktop Service e dalla scheda Overview cliccate col tasto destro sull’icona RD Gateway e scegliete Add RD Gateway Servers, come mostrato in figura:

Figura 25: Aggiunta del server RDGW ad un’infrastruttura esistente

Nel wizard che si aprirà selezionate dall’elenco il server corretto e aggiungetelo, tramite il simbolo a forma di freccia, ai server selezionati.

Figura 26: Selezione del server RDGW da aggiungere al deployment

Nel passaggio successivo scegliete con quale nome il server dovrà essere individuato dagli utenti Internet. Verrà generato un certificato di tipo Self-Signed, che potrete successivamente sostituire con uno comprato da una Certification Authority pubblica.

Figura 27: Nome del certificato self-signed

Dopo qualche secondo la configurazione è completata.

Figura 28: aggiunta del server RDGW al deployment esistente completata

Vi consiglio di modificare subito il certificato esibito dal vostro server RDGW. Cliccate sul link Configure certificate che è apparso alla fine del wizard e approfittate per importare il certificato corretto. Nel mio caso ho utilizzato il wildcard *.nicolaferrini.it. Il certificato può essere modificato in qualsiasi momento dal Server Manager, Nodo Remote Desktop Services, selezionando Overview e da Tasks scegliendo Edit Deployment Properties.

Figura 29: Importazione e configurazione del certificato corretto per il RDGW

Rimanendo nella stessa finestra di Deployment Properties, cliccate su RD Gateway e aggiungete il server di Remote Desktop Gateway al vostro deployment. Selezionate l’opzione Use these RD Gateway Settings e configurate come mostrato in figura:

Figura 30: Il Deployment adesso utilizzerà il serve di Remote Desktop Gateway

A questo punto la configurazione è terminata e non vi resta atro che testare il vostro deployment.

Connessione alle RemoteApp della Session Collection attraverso il Remote Desktop Gateway

Loggatevi all’indirizzo del vostro Web Access. Nel mio caso l’host si chiama rds01.demo.lab, ma l’ho anche pubblicato esternamente con il nome apps.nicolaferrini.it. L’indirizzo completo a cui collegarvi è quindi https://apps.nicolaferrini.it/rdweb. Avendo installato un certificato valido non ottengo nessun messaggio di errore. Dalla schermata di login inserite le credenziali di un utente che avete aggiunto al gruppo autorizzato ad accedere alla vostra Session Collection, come mostrato in figura:

Figura 31: Connessione al Web Access

Dopo aver inserito le credenziali vi appariranno le icone delle applicazioni (RemoteApp) che sono disponibili nella vostra Session Collection. Cliccate su una delle icone per lanciare il programma.

Figura 32: RemoteApp disponibili nella Session Collection

Dopo aver lanciato la connessione verso l’applicazione, vi apparirà un messaggio in cui vi verrà chiesto se considerare attendibile il Publisher dell’applicazione. In più vi verranno date indicazioni anche sul computer remoto a cui vi state connettendo (rds01.demo.lab). Come potete notare dalla figura sotto, la connessione avverrà attraverso un Gateway server chiamato rdgw01.nicolaferrini.it

Figura 33: Connessione alla RemoteApp utilizzando il Remote Desktop Gateway

Inserite le credenziali richieste e finalmente sarete connessi alla vostra applicazione, ma questa volta attraverso un tunnel HTTPS:

Figura 34: Apertura della RemoteApp di Word 2016

Conclusioni

Il Remote Desktop Gateway è un ruolo molto importante dei Remote Desktop Services che permette l’accesso alle nostre applicazioni aziendali attraverso Internet. È possibile accedere ai desktop remoti e alle RemoteApp semplicemente utilizzando un unico server ed un’unica porta di connessione esposti ad Internet, con un vantaggio enorme in termini di configurazione e soprattutto con la sicurezza che le nostre connessioni saranno sempre cifrate. Davvero un bel vantaggio!

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.

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.