Windows Virtual Desktop è un servizio completo di virtualizzazione dei desktop e delle applicazioni disponibile in Azure che, in un periodo come questo, dove il lavoro da casa è aumentato esponenzialmente, ha visto un’ampia adozione. Consentire ai propri dipendenti di lavorare da casa richiede alle organizzazioni di affrontare cambiamenti importanti della propria infrastruttura IT in termini di capacità, rete, sicurezza e governance. La soluzione Virtual Desktop Infrastructure (VDI) in Azure può aiutare le realtà aziendali ad affrontare in modo efficace queste evoluzioni, ma è necessario proteggere l’accesso a questi ambienti VDI in modo opportuno. In questo articolo viene descritto come è possibile strutturare il networking in Azure per proteggere in modo efficace i deployment di Windows Virtual Desktop.
Per poter adottare il giusto approccio è necessario valutare quali sono i componenti di Windows Virtual Desktop (WVD) e le loro iterazioni. Il servizio è distribuito secondo un modello di responsabilità condivisa e vede:
- RD Clients che si collegano ai desktop e alle applicazioni erogati dal servizio WVD. L’ambiente può essere raggiunto da qualsiasi postazione con accesso Internet e la gestione dei client ricade nelle responsabilità del cliente.
- Servizi Azure gestiti che hanno il compito di pilotare le connessioni tra i client RD e le macchine virtuali Windows in Azure. Si tratta dei ruoli server necessari per questo ambiente, quali Gateway, Web Access, Broker e Diagnostics, in modalità totalmente gestita da Microsoft.
- Macchine virtuali in Azure attestate su una virtual network, la cui gestione è totalmente in carico al cliente.
Figura 1 – Shared Responsibility model di Windows Virtual Desktop
Per mettere in totale sicurezza l’ambiente Windows Virtual Desktop è necessario definire la topologia di rete più opportuna e i flussi di comunicazione necessari.
Topologia di rete Hub-Spoke per Windows Virtual Desktop
Nell’architettura di rete di tipologia Hub-Spoke, l’Hub è una rete virtuale in Azure che funge da punto di connettività verso la rete on-premises. Tale connettività può avvenire tramite VPN Site to site oppure tramite ExpressRoute. Gli Spoke sono le reti virtuali che eseguono il peering con l’Hub e possono essere usate per isolare i carichi di lavoro. Un buon approccio potrebbe quindi essere quello di strutturare il networking di Azure adottando fin da subito questa topologia di rete e posizionare le macchine virtuali Windows Virtual Desktop in una rete di Spoke. Questa architettura di rete è pensata anche per posizionare nella rete di Hub una network virtual appliance (NVA) per controllare i flussi di rete in modo centralizzato. Il controllo delle comunicazioni di rete può essere demandato a una network virtual appliance (NVA) di terze parti oppure ad Azure Firewall, il servizio gestito e totalmente integrato nel cloud pubblico di Microsoft, che consente di mettere in sicurezza le risorse presenti sulle Virtual Network di Azure.
Figura 2 – Hub-spoke network topology in Azure
Flussi di comunicazione necessari per Windows Virtual Desktop
Diversi sono i flussi di comunicazione che è necessario prevedere e che grazie alla topologia di rete Hub-Spoke è possibile governare facilmente e in modo centralizzato.
Figura 3 – Flussi di comunicazione per l’ambiente Windows Virtual Desktop nella topologia Hub-Spoke
Windows Virtual Desktop non richiede di dover aprire dei flussi di comunicazione in ingresso verso la virtual network su cui sono attestate le relative macchine virtuali.
Per consentire un corretto funzionamento del servizio è però necessario prevedere l’accesso dalle macchine WVD, attestate sulla virtual network di spoke, verso specifici Fully Qualified Domain Names (FQDNs). La lista completa degli indirizzi necessari per il funzionamento di Windows Virtual Desktop è possibile consultarla in questo documento Microsoft. Per semplificare questa configurazione, in Azure Firewall è disponibile l’apposito FQDN tag chiamato WindowsVirtualDesktop, che è possibile utilizzare in una application rule specifica. A questo proposito è bene specificare che questo tag non contempla l’accesso agli storage e service bus accounts necessari per gli host pool di Windows Virtual Desktop. Trattandosi di URL specifici per deployment è possibile andare a consentire il traffico https in modo puntuale verso gli URL specifici oppure si può utilizzare il wildcard per i seguenti FQDNs: *xt.blob.core.windows.net, *eh.servicebus.windows.net e *xt.table.core.windows.net. Questi FQDN tag sono presenti anche nelle Virtual Appliance di terze parti per facilitare la configurazione.
Le macchine Windows Virtual Desktop devono inoltre poter accedere ai server DNS, al servizio KMS per i processi di attivazione e ai server NTP per la sincronizzazione dell’orario.
In base alle esigenze aziendali può inoltre essere necessario abilitare l’accesso a Internet per gli utenti finali, applicando opzionalmente specifiche regole per la navigazione. Per filtrate il traffico Internet può essere utilizzato un secure web gateway posizionato on-premises oppure la network virtual appliance posizionata nella rete di Hub.
Infine, è opportuno prevedere l’abilitazione dei flussi di comunicazione necessari tra le macchine Windows Virtual Desktop, posizionate nella rete di Spoke, e le risorse che risiedono nell’ambiente on-premises.
Conclusioni
Uno dei primi aspetti da tenere in considerazione quando si decide di implementare soluzioni nel cloud è l’architettura di rete da adottare. Stabilire fin dall’inizio la topologia di rete più opportuna consente di avere una strategia vincente ed evita di trovarsi nella condizione di dover migrare in seguito i workloads, per adottare architetture di rete differenti, con tutte le complicazioni che ne conseguono. L’architettura di rete Hub-Spoke si presta bene anche per scenari di deploy di Windows Virtual Desktop, in quanto consente di ottenere un elevato livello di controllo sugli aspetti legati alla sicurezza di rete e di effettuare una segregazione del traffico di rete adottando Azure Firewall oppure Network Virtual Appliance di terze parti.
