This question will probably only apply directly to UK users involved with the upcoming Payment Card Initiative (PCI) compliance rules (though feedback from anyone who's had experience of using ESX in highly compliant environments would be appreciated).
As part of our effort to ensure we are PCI compliant when the new rules come in next year, we're looking at the consequences PCI has for VMs that willl probably need to be segregated from the internal network in some way (because they store or use PCI-controlled data).
Our solution of choice is to construct a separate ESX cluster with firewalls between each ESX host and between the cluster and the rest of the network. This address the requirements of the PCI rules but it does add complication to our existing VMware infrastructure.
I'd be interested to know what others with similar challenges have done - is there a better way of doing this?
We're doing a similar thing.
I plan to have a separate ESX cluster and VC in the DMZ
With separate secure VLans for both the SC/VC, and for vmotion.
Also aim to secure the config of the SC as much as possible (good chapter on that in Texiwill's recent book)
Firewall will be between the DMZ and our internal network, and between the DMZ and the internet.
Have no plans to put an additional firewall between the ESX servers - but will have the standard esx firewall on the default high settings.
PCI compliance is an area I see a lot of people trying to deal with. I work for Altor Networks, and we will soon be releasing a Virtual Network Firewall (VNF) which can help to address PCI compliance in a virtual environment.
There are a lot of ways that people try to build in security, but most have big impacts on ease of management and efficiency. Rather than completely separating virtual infrastructure, we allow securing the virtual network from within. The firewall enforcement is done at a vswitch level, you can control not only who is allowed to access the VMs from the Internet and your internal network, but you can also control which other Virtual Machines have access to the sensitive VMs.
VNF was built from the ground up to work in a virtualized environment, so it can handle things like vmotion and maintain security through VM migrations, new VMs appearing, etc. So, you can still take advantage of vmotion, DRS, etc. while maintaining a secure network.
There is some more info on our www site: http://altornetworks.com/
If you're interested in taking a look at the firewall or have questions, e-mail firstname.lastname@example.org
Moved to the Security and Compliance forum.
I know people are using ESX within the PCI space, but you also need to consider that ESX is a hybrid device that contains network, storage, memory, and compute resources. So it should never be considered just a server. It is more than that.
Edward L. Haletky
VMware Communities User Moderator
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.
CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354
As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization
The DMZ paper is already out. You can find it here.
As far as PCI compliance with VMware, the issue is that it very much depends on the auditor and their interpretation of the standard as there is no specific guidance within the standard with regards to virtualization. VMware is actively working on getting this type of specific guidance into the standard in one form or another so it is not left up to the interpretation of an auditor. That said there are many companies that have passed their audits with various types of configurations. Anywhere from what you are planning on doing as well as using Firewall/IDS/IPS virtual appliances from companies like Altor (mentioned above), Reflex, Bluelane and others. Using these tools allows for the collocation of PCI servers and non-PCI servers on the same host. So it is absolutely a viable and legitimate thing to do and I think that what you are doing is just as good as any solution. The key is to be able to justify the configuration to your auditor.
One more note is that the post that mentioned the isolation of the service consoles VC above is right on the money for just general security. This is a big step in securing your virtual infrastructure due to the power that root or adminstrator access to these interfaces hold. There are obviously many other things like the hardening of the different components, but isolation of the service console and VC is probably one of the easiest things you can do to decrease your risk level significantly. Again, its not the only thing you should do, but is definitely a good start.
Note this document is only available via the direct URL as it is yet to be approved for publication.
The doc quickly recaps on the DMZ with VI whitepaper, then shows how we selected on of the approaches and then how it was implemented. It's a brief document and its purpose is to outline an approach that others can use to better inform their decisions.
The VI:OPS pilot is an extension to these communities and is a new place for you to request information about proven practices as well as contribute your own. Join in, let us know what you think about the pilot so we can shape it to your needs before we launch it proper.
You said...."PCI compliance is an area I see a lot of people trying to deal with. I work for Altor Networks, and we will soon be releasing a Virtual Network Firewall (VNF) which can help to address PCI compliance in a virtual environment. "....
Perhaps you have a use case / implementation that we can write another proven practice document on the VI:OPS pilot?