In the last post we broke down each of the six use cases that the VMware NSX platform can provide for Secure End-User computing environments. Each of these use cases providing a Healthcare organization a different business value depending on their needs.
As we start to break each use case down, the first one we’ll be looking at is around Micro-segmentation of a Virtual Desktop Infrastructure (VDI) environment that a Healthcare organization may run.
Speaking with my Healthcare customers running VDI systems, there wasn’t many security-based controls to protect traffic between each desktop. These systems were fully allowed to communicate with each other regardless of an actual need to. Not only that, but those VDI systems could scale up or down as demanded. The security posture must be able to scale up and down in a similar fashion. These use cases for NSX are quite simple and easy to implement. By blocking unnecessary communications between these systems, we can ensure that if one desktop is compromised, could transition and compromise other desktops. Several times in discussions, my Healthcare customers were using one or more technologies as they transitioned from one to the other or as part of a legacy acquisition. We’ll take the top two VDI software providers, Citrix and Horizon and show that it doesn’t matter which one a customer is using, both can be secured in an identical fashion.
Healthcare organizations also had different types of uses for example, clinicians and HR users. There could be a need to create separate pools for each of these different types of users. There are other ways to address this problem with other products and utilizing a single pool but in this case, we’re focusing on customers with this model. In a later blog we’ll also explore how Identity-based Firewall in NSX can help as well.
Let’s look at our use case.
Use case – Augment an existing VDI deployment using VMware Horizon with NSX and secure traffic between each system and providing isolation for desktop pools
- Block all VDI to VDI
- Isolate HR and Clinician Desktop pool from each other
- Maintain the existing infrastructure as much as possible and without major changes
Technology used –
- External Client-01a – Windows 10 – HR User
- External Client-02a – Windows 10 – Clinician User
- EMR-VDI-01a > EMR-VDI-02a (HZN)
- HR-VDI-01a > HR-VDI-02a (CTX)
- Allow EMR-VDI pool to expand and contract based on Clinician need
- Horizon View
Applications in question –
Open Source Healthcare Application:
- OpenMRS – Open Source EMR system
- Apache/PHP Web Server
- MySQL Database Server
Open Source HR Application:
- IceHRM – Open Source HR system
- Apache/PHP Web Server
- MySQL Database Server
In this environment, the customer has a Citrix VDI environment and a Horizon VDI environment. They are in the middle of a transition from one platform to another, however security needs to remain consistent. The HR VDI systems need to be able to access the HR application, and the Clinicians need to be able to access the EMR application. Neither should be able to talk to the other application and neither pool of desktops should be able to talk to each other.
We also need to provide a security posture for when the EMR Desktop pool needs to expand due to Clinician need.
We’ll start by building out our NSX grouping constructs and putting in each of the different objects into their respective containers. We’ll also mock up our firewall rule sets
The groupings are shown here for use in our rule sets. Each of these NSX Security Groups will enable the DFW rule sets to scale as the environment scales without the need to make modifications to the DFW rules. If more VDI systems are created, they will simply land in their appropriate Security Group, and the DFW policy will be applied. We’ll be exploring the concept of automation for VDI in another post.
HR Application Communications:
EMR Application Communications:
The rule sets are simple to segment out each of the different VDI systems from their appropriate application servers. Also, by nesting all VDI VMs into one Security Group, we can keep the block communications between the systems to one rule. With all the necessary components to create our security policy, we can start putting it into the NSX DFW.
All the rules are in place; we can now perform verification to see that our rules are working and the requirements have been achieved.
HR users can get to their HR application and EMR users cannot get to the HR application
EMR users can get to their EMR application and HR users cannot get to the EMR application
VDI desktops are not allowed to talk to each other
Now that we’ve verified that the HR user and the Clinician can access their VDI desktops and the relevant applications they need, we’ll scale up the EMR VDI systems by adding one more desktop and attempt to connect to the newest desktop the same as we did in the previous verification.
Currently, there are only two VDI desktop machines in our pool. We’ll increase that to 3 as a customer may need a new desktop should more clinicians need to login during rush periods, where not enough desktops are online already. The main consideration here, is that we want to keep the same security posture as above, regardless of how many desktops we have in the pool.
With the pool increased, our dynamic criteria has added the newly built machine into the Security Group as it should. All the rules associated with this Security Group will now apply to this newly built VDI desktop as well. Let’s verify.
Our pings to the other VDI systems, including the new one we just built drop as we’d expect them to drop. This fulfills the requirements of the customer.
Micro-segmentation for Secure End-User starts with securing VDI desktops. Regardless of the implementation technologies, Horizon or Citrix, NSX can provide a security posture surrounding the VDI desktops and the application systems they require access to. In future posts I’ll be showing how NSX can provide ever further value for the other Secure End-User use cases.