Windows Virtual Desktop is a full desktop and application virtualization service available in Azure that, in a period like this, where work from home has increased exponentially, has seen wide adoption. Enabling your employees to work from home requires organizations to address major changes in their IT infrastructure in terms of capacity, network, security and governance. The Virtual Desktop Infrastructure solution (VDI) in Azure can help business companies effectively address these evolutions, but you need to protect access to these VDI environments appropriately. This article describes how you can structure networking in Azure to effectively protect Windows Virtual Desktop deployments.
In order to adopt the right approach, it is necessary to evaluate which are the components of Windows Virtual Desktop (WVD) and their iterations. The service is distributed according to a shared responsibility model and sees:
- RD Clients connected to the desktops and applications provided by the WVD service. The environment can be reached from any location with Internet access and client management falls under the customer's responsibilities.
- Managed Azure Services responsible for piloting connections between RD clients and Windows virtual machines in Azure. These are the server roles that are required for this environment, such as Gateways, Web Access, Brokers and Diagnostics, fully managed by Microsoft.
- Virtual machines in Azure attested on a virtual network, whose management is totally in charge of the customer.
Figure 1 – Shared Responsibility model di Windows Virtual Desktop
To secure your Windows Virtual Desktop environment, you must define the most appropriate network topology and the necessary communication flows.
Hub-Spoke Network Topology for Windows Virtual Desktop
In a Hub-Spoke network architecture, theHub is a virtual network on Azure that serves as the point of connectivity to the on-premises network. This connectivity can be done through VPN Site to site or through ExpressRoute. TheSpoke are virtual networks running the peering with the Hub and can be used to isolate workloads. A good approach would therefore be to structure Azure networking by adopting this network topology right away and place the Windows Virtual Desktop virtual machines on a Spoke network. This network architecture is also designed to place in the Hub network a network virtual appliance (NVA) to control network flows centrally. Control of network communications can be assigned to a network virtual appliance (NVA) or to Azure Firewall, Microsoft's managed and fully integrated public cloud service, that allows you to secure the resources present on the Virtual Networks of Azure.
Figure 2 – Hub-spoke network topology in Azure
Communication flows required for Windows Virtual Desktop
There are several communication flows that need to be predicted and that thanks to the Hub-Spoke network topology you can easily and centrally govern.
Figure 3 – Communication flows for the Windows Virtual Desktop environment in the Hub-Spoke topology
Windows Virtual Desktop does not require that you have to open inbound communication streams to the virtual network on which its virtual machines are attested.
However, in order for the service to work properly, you must provide access from WVD machines, attested on the spoke virtual network, towards specific Fully Qualified Domain Names (FQDNs). The full list of addresses required for Windows Virtual Desktop to work can be found in this Microsoft's document. To simplify this configuration, Azure Firewall has the appropriate tag FQDN called WindowsVirtualDesktop, that you can use in a specific application rule. In this regard, it is good to specify that this tag does not include access to the storage and service bus accounts required for Windows Virtual Desktop pool hosts. As deployment-specific URLs, you can go to allow https traffic on time to specific URLs, or you can use the wildcard for the following FQDNs: *xt.blob.core.windows.net, *eh.servicebus.windows.net and *xt.table.core.windows.net. These FQDN tags are also present in third-party Virtual Appliances to facilitate configuration.
Windows Virtual Desktop machines must also have access to DNS servers, KMS service for activation jobs and NTP servers for time synchronization.
Depending on your business needs, you may also need to enable Internet access for end users, optionally applying specific navigation rules. A secure web gateway located on-premises or the network virtual appliance located in the Hub network can be used to filter Internet traffic.
Finally, you should allow the necessary communication flows between Windows Virtual Desktop machines, placed in the Spoke network, resources that reside in the on-premises environment.
Conclusions
One of the first aspects to consider when you implement solutions in the cloud is the network architecture to be adopted. Establishing the most appropriate network topology from the outset allows you to have a winning strategy and avoids being in the condition of having to migrate workloads later, to adopt different network architectures, with all the complications that ensue. The Hub-Spoke network architecture also lends itself well for Windows Virtual Desktop deployment scenarios, as it allows to obtain a high level of control on aspects related to network security and to segregate network traffic by adopting Azure Firewall or third-party Network Virtual Appliance.
