From VDI replacement to complementary use: Part 2 Stefano Alei

In the first part of this VDI blog series, we discussed the two major use cases of access granularity and traffic inspection and how Zscaler can support these with the help of the Zero Trust Exchange platform. In this blog, we will focus on more use cases and ways to integrate Zscaler as complementary solution to VDI to cover security related aspects.

Data residency restriction
This use case deserves a deeper investigation, because although we can say that it is supported, there could be specific instances in which Zscaler cannot replace the VDI environment. Zscaler Cloud Browser Isolation (CBI) prevents data to leave the corporate boundary. We can define what level of restriction applies to the data exchange between the actual application and the isolated container. The recent introduction of Endpoint DLP capabilities could further help our conversation when stricter security requirements are required.

Zscaler Cloud Browser Isolation is inherently non-persistent; the virtual machine is terminated after each session. Now, imagine the scenario of a developer working remotely on a virtual desktop where he has his own environment and data can’t leave the company area. This individual would need a persistent desktop to work, and the user environment shouldn’t be destroyed when he closes the working session. This use case could be challenging for a VDI replacement. This use case could be addressed by leveraging the Private Remote Access (PRA) and RDP. In the above example, an RDP session could be launched toward a machine where the developer can work and log in, where their development environment sits and where communication is local, and data won’t leave the company boundary. Obviously, the organisation’s environment must be assessed carefully to validate the pros and cons of the proposed alternative.

Traffic localization
In this scenario, the goal is to keep the communication local to the data centre due to performance issues. From a Zscaler point of view, the area of potential replacement exists once we validated the possibility to leverage Private Remote Access (PRA) and RDP with the customer, where a remote session is launched toward a machine that interacts locally with the server.

Desktop or software license management / reduction
The discussion about this scenario under the assumption to keep the VDI environment up and running needs a preamble. ZCC does not support multiple, simultaneous user sessions from a single host operating system. The main problem to address is supporting ZIA and ZPA services on multi-user VDI environments.

Zscaler now offers the ability to inspect all ports and protocols for multi-session, non-persistent VDI deployments in the public cloud and on-prem data centers through the use of a VDI agent. Enterprises can apply granular threat and data protection policies per individual user session, enabling enterprises to maintain common security policies across all environments.

Multi-user VDI can be hosted on a public cloud (Azure, AWS, etc.) or private data centers (VMWare or KVM, etc.). Cloud/Branch Connector can be used to direct traffic from the VDI users to the Zscaler cloud and extend ZIA and ZPA services to the VDI users. However, Cloud/Branch Connector does not have any user/VM context to the traffic and will enforce a single security policy to all the VDI users. To fix this issue, we leverage a VDI agent, that is a lightweight software package running in the user space of the VDI session. It is responsible for authenticating users, establishing a tunnel to Branch or Cloud Connector (Control and Data) and exchanging user context with the Branch or Cloud Connector (see below diagram).

The VDI Agent maintains proprietary, lightweight tunnels (UDP encapsulation) to the local Cloud or Branch Connector. These tunnels carry both user session data in the payload, as well as user context information in the UDP header. These tunnels are stateless, which ensures that – in the event of a Branch or Cloud Connector failure – they can failover to other active appliances.

With that said, we have now the possibility to extend Zscaler services to multi-user VDI environments.

Legacy app support
Although this scenario is becoming more and more niche due to applications and architecture evolution, that’s an area where VDI could help customers. The Zscaler Client Connector supports the latest software version and the two previous versions for each software product. See more details on the Zscaler Help page.

At a higher level – digging into why organisations use VDI in the first place is important. Walking through their use cases and applications to explore the scope is important to move customers beyond the assumptions that flow from the on-premises/on-network mindset. In some cases, Zscaler can be integrated in the existing environment to simply provide the appropriate level of security.

There are two main aspects to consider:

Most applications are now web-based and could be securely made available to users regardless of VDI.
Even if VDI is not replaced for all users, there are multiple reasons to integrate with ZIA/ ZPA.

Just think about users like financial advisors and insurance agents. Many firms have moved to web-based apps, DocuSign, etc. There may no longer be a hard requirement for those thousands of users to have VDI. This requires going beyond what the network team may see, and engaging architects, app owners, etc.

If we focus on the second aspect; rather than replacing the VDI infrastructure, another approach is to complement it. If we think about those use cases, organisations could still have security concerns around the user’s connectivity to the VDI environment (e.g. VMware Knowledge Base). In these scenarios, ZPA could protect that user traffic: it can secure access “to” the VDI environment and access “from” the VDI environment like shown in the below diagram.

The protection of traffic aimed to Internet/SaaS is addressed by ZIA services.

Connectivity to the VDI environment:

Organisations may either put the VDI on the edge with its own DMZ infrastructure, firewall, security gateway, load balancer, etc. and have users connect directly or leverage a VPN-like technology to put the user on the network to access the VDI. ZPA, with Client Connector, enables a customer to either replace their internet-facing components or replace their VPN that is putting users onto the network.

Connectivity from the VDI environment:

Organisations want to further segment what users have access to from their trusted device. ZPA with Client Connector can assist with setting up granular access on an application level.

Complete alternative to VDI:

Organisations can leverage alternatives to VDI such as Zscaler Browser Isolation to replace their traditional VDI architecture. The benefits remain the same if a user has a browser managed by the enterprise which is isolated from the endpoint, the organisations admin remains in control of what can be egressed. Benefits of such an approach is the significantly lowered overhead to manage such a capability.

The Zscaler Client Connector can be installed on the user’s device along with the VDI client, and ZPA carries the VDI traffic as a private application.

Another option is installing ZCC on the virtual desktop instance (Citrix XenDesktop, Azure WVD, Amazon WorkSpaces) to control what the user has access to internally. Existing customers are deploying this model with WVD and Amazon Workspaces using ZCC for both ZIA and ZPA. Benefits in such a scenario are centralized visibility and control, single access control policy config for VDI, and other forms of access, creating a consistent user experience.

Finally, a hybrid approach is feasible. In this case, organisations want to offer direct ZPA access to employees, but VDI-only access to third parties, and want to extend ZPA’s centralized visibility and control for VDI users accessing private applications.

All these examples show that there are multiple ways to either completely exchange or complement the existing VDI installation.  

​

In the first part of this VDI blog series, we discussed the two major use cases of access granularity and traffic inspection and how Zscaler can support these with the help of the Zero Trust Exchange platform. In this blog, we will focus on more use cases and ways to integrate Zscaler as complementary solution to VDI to cover security related aspects.

Data residency restriction

This use case deserves a deeper investigation, because although we can say that it is supported, there could be specific instances in which Zscaler cannot replace the VDI environment. Zscaler Cloud Browser Isolation (CBI) prevents data to leave the corporate boundary. We can define what level of restriction applies to the data exchange between the actual application and the isolated container. The recent introduction of Endpoint DLP capabilities could further help our conversation when stricter security requirements are  required. 

Zscaler Cloud Browser Isolation is inherently non-persistent; the virtual machine is terminated after each session. Now, imagine the scenario of a developer working remotely on a virtual desktop where he has his own environment and data can’t leave the company area. This individual would need a persistent desktop to work, and the user environment shouldn’t be destroyed when he closes the working session. This use case could be challenging for a VDI replacement. This use case could be addressed by leveraging the Private Remote Access (PRA) and RDP. In the above example, an RDP session could be launched toward a machine where the developer can work and log in, where their development environment sits and where communication is local, and data won’t leave the company boundary. Obviously, the organisation’s environment must be assessed carefully to validate the pros and cons of the proposed alternative.

Traffic localization

In this scenario, the goal is to keep the communication local to the data centre due to performance issues. From a Zscaler point of view, the area of potential replacement exists once we validated the possibility to leverage Private Remote Access (PRA) and RDP with the customer, where a remote session is launched toward a machine that interacts locally with the server. 

Desktop or software license management / reduction

The discussion about this scenario under the assumption to keep the VDI environment up and running needs a preamble. ZCC does not support multiple, simultaneous user sessions from a single host operating system. The main problem to address is supporting ZIA and ZPA services on multi-user VDI environments. 

Zscaler now offers the ability to inspect all ports and protocols for multi-session, non-persistent VDI deployments in the public cloud and on-prem data centers through the use of a VDI agent. Enterprises can apply granular threat and data protection policies per individual user session, enabling enterprises to maintain common security policies across all environments.

Multi-user VDI can be hosted on a public cloud (Azure, AWS, etc.) or private data centers (VMWare or KVM, etc.). Cloud/Branch Connector can be used to direct traffic from the VDI users to the Zscaler cloud and extend ZIA and ZPA services to the VDI users. However, Cloud/Branch Connector does not have any user/VM context to the traffic and will enforce a single security policy to all the VDI users. To fix this issue, we leverage a VDI agent, that is a lightweight software package running in the user space of the VDI session. It is responsible for authenticating users, establishing a tunnel to Branch or Cloud Connector (Control and Data) and exchanging user context with the Branch or Cloud Connector (see below diagram).

The VDI Agent maintains proprietary, lightweight tunnels (UDP encapsulation) to the local Cloud or Branch Connector. These tunnels carry both user session data in the payload, as well as user context information in the UDP header. These tunnels are stateless, which ensures that – in the event of a Branch or Cloud Connector failure – they can failover to other active appliances.

With that said, we have now the possibility to extend Zscaler services to multi-user VDI environments.

Legacy app support

Although this scenario is becoming more and more niche due to applications and architecture evolution, that’s an area where VDI could help customers. The Zscaler Client Connector supports the latest software version and the two previous versions for each software product. See more details on the Zscaler Help page.

At a higher level – digging into why organisations use VDI in the first place is important. Walking through their use cases and applications to explore the scope is important to move customers beyond the assumptions that flow from the on-premises/on-network mindset. In some cases, Zscaler can be integrated in the existing environment to simply provide the appropriate level of security.

There are two main aspects to consider: 

Most applications are now web-based and could be securely made available to users regardless of VDI.Even if VDI is not replaced for all users, there are multiple reasons to integrate with ZIA/ ZPA.

Just think about users like financial advisors and insurance agents. Many firms have moved to web-based apps, DocuSign, etc. There may no longer be a hard requirement for those thousands of users to have VDI. This requires going beyond what the network team may see, and engaging architects, app owners, etc.

If we focus on the second aspect; rather than replacing the VDI infrastructure, another approach is to complement it. If we think about those use cases, organisations could still have security concerns around the user’s connectivity to the VDI environment (e.g. VMware Knowledge Base). In these scenarios, ZPA could protect that user traffic: it can secure access “to” the VDI environment and access “from” the VDI environment like shown in the below diagram.

The protection of traffic aimed to Internet/SaaS is addressed by ZIA services.

Connectivity to the VDI environment:

Organisations may either put the VDI on the edge with its own DMZ infrastructure, firewall, security gateway, load balancer, etc. and have users connect directly or leverage a VPN-like technology to put the user on the network to access the VDI. ZPA, with Client Connector, enables a customer to either replace their internet-facing components or replace their VPN that is putting users onto the network.

Connectivity from the VDI environment: 

Organisations want to further segment what users have access to from their trusted device.  ZPA with Client Connector can assist with setting up granular access on an application level.

Complete alternative to VDI: 

Organisations can leverage alternatives to VDI such as Zscaler Browser Isolation to replace their traditional VDI architecture. The benefits remain the same if a user has a browser managed by the enterprise which is isolated from the endpoint, the organisations admin remains in control of what can be egressed. Benefits of such an approach is the significantly lowered overhead to manage such a capability.

The Zscaler Client Connector can be installed on the user’s device along with the VDI client, and ZPA carries the VDI traffic as a private application.  

Another option is installing ZCC on the virtual desktop instance (Citrix XenDesktop, Azure WVD, Amazon WorkSpaces) to control what the user has access to internally. Existing customers are deploying this model with WVD and Amazon Workspaces using ZCC for both ZIA and ZPA. Benefits in such a scenario are centralized visibility and control, single access control policy config for VDI, and other forms of access, creating a consistent user experience.

Finally, a hybrid approach is feasible. In this case, organisations want to offer direct ZPA access to employees, but VDI-only access to third parties, and want to extend ZPA’s centralized visibility and control for VDI users accessing private applications.

All these examples show that there are multiple ways to either completely exchange or complement the existing VDI installation. 

 [[{“value”:”In the first part of this VDI blog series, we discussed the two major use cases of access granularity and traffic inspection and how Zscaler can support these with the help of the Zero Trust Exchange platform. In this blog, we will focus on more use cases and ways to integrate Zscaler as complementary solution to VDI to cover security related aspects.

Data residency restriction
This use case deserves a deeper investigation, because although we can say that it is supported, there could be specific instances in which Zscaler cannot replace the VDI environment. Zscaler Cloud Browser Isolation (CBI) prevents data to leave the corporate boundary. We can define what level of restriction applies to the data exchange between the actual application and the isolated container. The recent introduction of Endpoint DLP capabilities could further help our conversation when stricter security requirements are required.

Zscaler Cloud Browser Isolation is inherently non-persistent; the virtual machine is terminated after each session. Now, imagine the scenario of a developer working remotely on a virtual desktop where he has his own environment and data can’t leave the company area. This individual would need a persistent desktop to work, and the user environment shouldn’t be destroyed when he closes the working session. This use case could be challenging for a VDI replacement. This use case could be addressed by leveraging the Private Remote Access (PRA) and RDP. In the above example, an RDP session could be launched toward a machine where the developer can work and log in, where their development environment sits and where communication is local, and data won’t leave the company boundary. Obviously, the organisation’s environment must be assessed carefully to validate the pros and cons of the proposed alternative.

Traffic localization
In this scenario, the goal is to keep the communication local to the data centre due to performance issues. From a Zscaler point of view, the area of potential replacement exists once we validated the possibility to leverage Private Remote Access (PRA) and RDP with the customer, where a remote session is launched toward a machine that interacts locally with the server.

Desktop or software license management / reduction
The discussion about this scenario under the assumption to keep the VDI environment up and running needs a preamble. ZCC does not support multiple, simultaneous user sessions from a single host operating system. The main problem to address is supporting ZIA and ZPA services on multi-user VDI environments.

Zscaler now offers the ability to inspect all ports and protocols for multi-session, non-persistent VDI deployments in the public cloud and on-prem data centers through the use of a VDI agent. Enterprises can apply granular threat and data protection policies per individual user session, enabling enterprises to maintain common security policies across all environments.

Multi-user VDI can be hosted on a public cloud (Azure, AWS, etc.) or private data centers (VMWare or KVM, etc.). Cloud/Branch Connector can be used to direct traffic from the VDI users to the Zscaler cloud and extend ZIA and ZPA services to the VDI users. However, Cloud/Branch Connector does not have any user/VM context to the traffic and will enforce a single security policy to all the VDI users. To fix this issue, we leverage a VDI agent, that is a lightweight software package running in the user space of the VDI session. It is responsible for authenticating users, establishing a tunnel to Branch or Cloud Connector (Control and Data) and exchanging user context with the Branch or Cloud Connector (see below diagram).

The VDI Agent maintains proprietary, lightweight tunnels (UDP encapsulation) to the local Cloud or Branch Connector. These tunnels carry both user session data in the payload, as well as user context information in the UDP header. These tunnels are stateless, which ensures that – in the event of a Branch or Cloud Connector failure – they can failover to other active appliances.

With that said, we have now the possibility to extend Zscaler services to multi-user VDI environments.

Legacy app support
Although this scenario is becoming more and more niche due to applications and architecture evolution, that’s an area where VDI could help customers. The Zscaler Client Connector supports the latest software version and the two previous versions for each software product. See more details on the Zscaler Help page.

At a higher level – digging into why organisations use VDI in the first place is important. Walking through their use cases and applications to explore the scope is important to move customers beyond the assumptions that flow from the on-premises/on-network mindset. In some cases, Zscaler can be integrated in the existing environment to simply provide the appropriate level of security.

There are two main aspects to consider:

Most applications are now web-based and could be securely made available to users regardless of VDI.
Even if VDI is not replaced for all users, there are multiple reasons to integrate with ZIA/ ZPA.

Just think about users like financial advisors and insurance agents. Many firms have moved to web-based apps, DocuSign, etc. There may no longer be a hard requirement for those thousands of users to have VDI. This requires going beyond what the network team may see, and engaging architects, app owners, etc.

If we focus on the second aspect; rather than replacing the VDI infrastructure, another approach is to complement it. If we think about those use cases, organisations could still have security concerns around the user’s connectivity to the VDI environment (e.g. VMware Knowledge Base). In these scenarios, ZPA could protect that user traffic: it can secure access “to” the VDI environment and access “from” the VDI environment like shown in the below diagram.

The protection of traffic aimed to Internet/SaaS is addressed by ZIA services.

Connectivity to the VDI environment:

Organisations may either put the VDI on the edge with its own DMZ infrastructure, firewall, security gateway, load balancer, etc. and have users connect directly or leverage a VPN-like technology to put the user on the network to access the VDI. ZPA, with Client Connector, enables a customer to either replace their internet-facing components or replace their VPN that is putting users onto the network.

Connectivity from the VDI environment:

Organisations want to further segment what users have access to from their trusted device. ZPA with Client Connector can assist with setting up granular access on an application level.

Complete alternative to VDI:

Organisations can leverage alternatives to VDI such as Zscaler Browser Isolation to replace their traditional VDI architecture. The benefits remain the same if a user has a browser managed by the enterprise which is isolated from the endpoint, the organisations admin remains in control of what can be egressed. Benefits of such an approach is the significantly lowered overhead to manage such a capability.

The Zscaler Client Connector can be installed on the user’s device along with the VDI client, and ZPA carries the VDI traffic as a private application.

Another option is installing ZCC on the virtual desktop instance (Citrix XenDesktop, Azure WVD, Amazon WorkSpaces) to control what the user has access to internally. Existing customers are deploying this model with WVD and Amazon Workspaces using ZCC for both ZIA and ZPA. Benefits in such a scenario are centralized visibility and control, single access control policy config for VDI, and other forms of access, creating a consistent user experience.

Finally, a hybrid approach is feasible. In this case, organisations want to offer direct ZPA access to employees, but VDI-only access to third parties, and want to extend ZPA’s centralized visibility and control for VDI users accessing private applications.

All these examples show that there are multiple ways to either completely exchange or complement the existing VDI installation.”}]]