Hi...Rob Randell here again. In an earlier posting on the partner announcements at the RSA and HIMSS Conferences, I promised that I would go into detail on how we can leverage VMware View to provide what I like to call Desktop Security Zones and the Desktop DMZ. In this blog I am going to illustrate this in a use case on a hospital network.
Specifically, in this use case we have two primary sets of users: Doctors and Hospital Administrators. The doctors need to have access to the medical records of their patients. These records reside in a medical records app on the hospital’s internal network that they access via a browser.
The hospital administrators on the other hand need access to the billing and insurance information of these patients. This data resides on another set of servers also served up via a web application on the local hospital network.
The doctors have no reason to access the billing or insurance info for their patients and the hospital admins don’t need access to the medical information. Both the doctors and the hospital admins need access to the web though so they can do research and check on personal matters.
So based on this case study we are going to have three sets of virtual desktops:
- Doctor Desktops
- Hospital Administrator Desktops
- Web Browsing Desktops
We have two different users that we are going to demonstrate this use case for. The first is Doc Jones and the second is Hoss Admin. You can probably guess who is the doctor and who is the hospital admin.
The first step we need to take in our configuration is to put Doc Jones and Hoss Admin into Active Directory groups that match them to their roles. In our case, the AD groups are simply “Doctors” and “Hospital Administrators. These can be seen in the screenshot below.
The next step happens in vCenter where we need to create some resource pools for the housing of our different desktop pools. These will be necessary for our vShield App rule creation later. We need to create three resource pools for our different virtual desktops: “Browsing Desktops”, “DoctorDesktops”, and “HospitalAdminDesktops”. The screenshot below shows the three resource pools we created for our virtual desktops.
Now that we have created our groups in AD and resource pools in vCenter, we need to create the Desktop Pools within the View Manager. We will create three desktop pools to matchup with the roles we talked about earlier, BrowserDesktops, DocDesktops, and HospitalAdminDesktops. You can imagine having additional pools here for other roles within a hospital like nurses, pharmacists, etc… For our use case we will focus on the Doctors, the Hospital Admins and the browsing desktops. These can be seen in the screenshot below.
Next we configured the entitlements to give the user access to their desktop specific to their roles and the browsing desktop.
OK, now that we have our desktop pools provisioned. We need to create the rules necessary for the desktops to work properly. This includes ensuring that Windows works properly and can communicate with everything it needs like DNS, AD, NTP, etc… Lots of Windows rules to create as can be seen in the screenshot below. Click on the screenshot to see the full image.
Communication with the View Server needs to be opened up to allow for PCoIP, USB redirection (if needed), etc… We have up to 4 rules per desktop pool. TCP and UDP for PCoIP to allow the View Client to connect to the View Desktop to allow the PCoIP display protocol to work, JMS to allow the View Agent to communicate with the View Manager, and USB Redirection that is tunneled through the View Manager. Of course in a most cases I would argue that it is a good idea to block this traffic unless it is absolutely necessary. In this case, it would be reasonable, and likely that we would disable and block the USB Redirection as we probably wouldn’t want the Doctors and Hospital Admins to be able to copy data off of their virtual desktops to a USB drive. So in our case we will only have three rules per desktop pool (PCoIP (both tcp/udp) and JMS. Click on the screenshot to see the full image.
Note that the creation of these rules can be scripted so as new desktop pools are created, we can then run a quick script to add the necessary rules.
Next we need to create the rules to allow the doctors access to the medical app and the hospital admins access to the billing and insurance app. In this case, albeit very simple, it shows that the Doctors are entitled to the “Doctor Desktops”, which are restricted by vShield App to only have access to the Medical Servers. The Hospital Admins are entitled to the “Hospital Admin Desktops”, which are restricted by vShield App to only have access to the Billing Servers.
We used vApps to group the Medical Servers and Billing Servers. Doing this made creating our rules very easy as we just choose the “Medical Servers” and “Billing Servers” vApps for our destinations and the “HospitalAdminDesktops” and “DoctorDesktops” Resource Pools as opposed to doing some sort of IP subnet based rules. Both the medical app servers and the hospital app servers provide access via SSL.
Both need Internet access from the browsing desktops, as the other desktops are not allowed Internet access. Notice that we deny the “Browsing Desktops” access to all Internal IP Addresses. If a rule does not match these two rules, it means that the IP address is an external IP address where we allow these desktops HTTP and HTTPS access. If we wanted to we could allow additional protocols, but for the purposes of our hospital, they should only need these basic protocols. Also, if we wanted to send a syslog message anytime one of the browsing desktops attempted to access an internal resource and was denied we could check the “Log” checkbox in those rules. In this case we didn’t choose to do that.
The doctors and hospital administrators now have access to their desktop and any of the resources that their particular desktop is capable of connecting to. This network access is controlled through vShield App where the View Connection Server controls the access to the desktop. In this case, you can see the vShield App firewall rule that shows the DoctorDesktops have access to the Medical Servers. Notice that we created these rules based on the resource pool where View Composer deploys the doctor’s desktops (DoctorDesktops) as the source and the vApp that contains the medical application (Medical Servers) as the destination. Pretty simple, huh?
Interestingly, it was pointed out to me by Rob Babb that we could make this even simpler for the browsing desktops by setting up a proxy server. This could be the single point of access to the Internet and would make setting up the rules even simpler as we wouldn’t need the “Deny” rules to the internal networks for the BrowsingDesktops. All we would need is an allow rule for these desktops to the proxy server, as the deny to the rest of the network would be handled by the default deny rules we have setup at the bottom of our rule set.
Now it is time for the users to login. We will show the instance of a doctor logging in. The doctor will run the View Client on their iPad, Thin/Zero Client, laptop, or any other device. In this case we will show the login with the standard View Client from a Windows machine.
Doc Jones will then authenticate to the connection server. In this case he is using a standard AD Credentials, but we could use a Smartcard or SecureID as well.
Once authenticated the doctor will have a choice of whether they want to login to the “Doctor Desktops” or the “Web Browsing Desktop”. Once they decide on the desktop their login credentials they provided to the View Client will be automatically passed through using the single sign-on capabilities of VMware View.
In this case we are logging them into their main desktop so they can gain access to the medical server, but are not allowed access to anything else. This can be seen in the screenshots below.
Here we can see both the allowed and blocked connections for the docvm2, which is the desktop that Doc Jones was using.
So to summarize, in a minimal amount of work, we were able to setup two desktop pools that are entitled to specific sets of users, which protected with vShield App are restricted to access only a specific set of resources. Make note that these rules are good for one desktop or 1000 desktops as they apply to the resource pools as opposed to creating the rules for individual desktops. So we don’t have to constantly add rules as new desktops are added or old desktops are removed.
The cool thing about this is that we can automate this even more to make it even easier which I didn't address in this posting. I also didn’t talk about how we could use vShield Endpoint and vShield Edge in this use case. Not to mention adding in partner solutions for IDS/IPS protections as well. Stay tuned for more on all of this.