Security continues to be a top concern for those considering a move to the cloud – and just because you’ve decided to deploy a private cloud instead of “going public” doesn’t mean you don’t have to worry about security. For the most part, private cloud security shares most of the same characteristics and requirements as security in the traditional datacenter. That is, you need to secure the facility, the hardware infrastructure, the network, the applications and the data in a private cloud in the same way that you need to secure the data in a traditional data center. However, there are a few significant differences between a traditional data center and the private cloud, and that’s what we’re going to look at in this article.
One of those significant differences is that almost all private clouds use virtualization. It is important to note that virtualization is not a requirement of private cloud. You could use blade servers instead of virtual machines to accomplish almost all of the same capabilities that you would have in a private cloud based on virtual machines. However, the cost of the blades is likely to be quite a bit higher, so for most companies, virtualization is the private cloud enabling technology of choice. And in a Microsoft shop, that increasingly means Hyper-V.
In a private cloud based on Microsoft Hyper-V, there are a number of things you need to consider when it comes to security. Some basic best practices include:
- Disable processor based virtualization if you’re not using it
- Use Windows server core to reduce attack surface and updating
- Use Bitlocker volume encryption
- Do not run applications and services on the Host operating system
- Dedicate a NIC for management purposes
- Do not mix security zones
- Make sure that Hyper-V integration services are installed
- Update virtual machine images offline
- Use appropriate delegation of administration
Disable processor based virtualization if you’re not using it
Processor based virtualization assistance such as Intel VT enables virtual machines to work optimally by enhancing many memory management and isolation processes. You definitely want these technologies enabled when you are using the server to host Hyper-V based virtual machines. But if you decide to decommission the server and use it in a non-virtual server role, then you should disable these processor extensions, because they can potentially increase the attack surface on that machine. And since the machine isn’t hosting virtual machines, there’s no reason to enable those extensions. Turn them off if you’re not using them.
Use Windows server core to reduce attack surface and updating
Windows Server core deployments represent a minimal installation, which includes only the core components of the Windows Server 2008 or Windows Server 2008 R2 operating system that are required to get the operating system to run and enable installation of applications and services. Because there is a significant reduction in the number of binaries included in a Server core installation, the attack surface is reduced and there are fewer updates needed since the components that typically need updating (such as Internet Explorer) are not included in the installation.
It’s highly recommended that you run your Hyper-V virtual servers on top of a Server Core installation. After you install the Server Core version of Windows, you can then enable the Hyper-V role and install and configure virtual machines on the Server Core deployment by using a remote Hyper-V console or using the System Center Virtual Machine Manager (SCVMM).
Use BitLocker volume encryption
BitLocker is a volume based disk encryption system that enables you to encrypt entire volumes and entire hard disks. BitLocker works together with TPM (Trust Platform Modules) chips on the motherboard to increase the level of security and ensure that the boot environment has not been compromised by an intruder or malware.
BitLocker is important in all deployment scenarios. However, it is even more important when the physical security of the server is less than optimal, such as in branch office scenarios and many small and medium sized businesses. BitLocker protects you from offline attacks, where the intruder attempts to load another operating system and access the disk directly, thus allowingthe intruder to bypass the security controls that are included in the Windows operating system. When BitLocker encrypts the disk, offline attacks fail because the alternate OS used to access the disk is unable to break the BitLocker encryption to access the information on the disk.
You can use BitLocker to secure the boot operating system installed on the boot disk to protect core operating system components. You can also use BitLocker to secure the volumes where the virtual machines are stored. In addition, if you have data that is accessed by the virtual machines on other disks, you can use BitLocker to secure those volumes as well. In general, it’s a good idea to use BitLocker to secure all Windows hosted assets in your data center. While there is processing overhead, with today’s powerful multi-core Nehalem-based processors, the overhead is nominal.
Do not run applications and services on the Host operating system
The purpose of the host operating system is to provide an environment to host the hypervisor, which in this case is Hyper-V. You should not install any applications or services on the host operating system that are not related to supporting the virtualization environment. This is one of the advantages of using a Server Core installation; for example, you can’t use the Web browser on the machine and it’s very difficult, or even impossible, to install many applications and services that might run in non-Server Core installations.
Many organizations today are trying to do more with less, and so might consider installing low overhead services such as DNS, DHCP or Certificate Services on the Hyper-V host operating system. Don’t do it! Each application or service that you install on the host operating system will increase the attack surface and also require more updating of the host operating system. If you want to run additional services, run them in a virtual machine that is hosted by the host operating system.
Dedicate a NIC for management purposes
Your Hyper-V virtual server is going to have multiple physical network interfaces. You’ll probably dedicate a network interface that connects to the production network, while another network interface may connect the server to the Internet, another might connect the machine to a DMZ and another might connect to a partner network. The virtual machines can then be bound to these physical network interfaces so that they can connect only to the resources to which they need to connect. These interfaces should not be assigned IP addressing information and should not be reachable by any host on the network. They should be dedicated for virtual machine use only.
In addition to these interfaces, you should have a dedicated interface for management purposes. These interfaces can be assigned IP addressing information and you can use Windows Firewall with Advanced Security to control who can connect to that interface, perhaps by controlling access by IP address. In addition, you can require authentication and encryption at the network level when connecting to the management interface by using IPsec authentication and encryption.
Do not mix security zones
In Hyper-V arrays (or clusters), it’s possible for virtual machines to be moved automatically so that no single server in the array is overloaded from a memory, processor or network perspective. Because of this, you might find yourself in a situation where you don’t know at a particular point in time where a given virtual machine will be located. This creates a scenario where virtual machines that belong to different security zones can be co-located on the same host virtual server. This is a less than optimal security design because it makes the high security zone virtual machine potentially liable to compromise by the low security zone virtual machine.
When designing your Hyper-V arrays, think about the workloads that will be running on the virtual machines. If you have virtual machines that will be providing remote access services, such as a TMG firewall, or UAG SSL VPN server, or a conventional RRAS based remote access VPN server, then you will need to make sure that you dedicate an array to these Internet facing devices and not mix them with non-Internet facing virtual machines, such as a SQL server or SharePoint server that is tasked with intranet duties only.
Make sure that Hyper-V integration services are installed
Hyper-V integration services do a lot of things, and one of the most important duties of the integration services is to make sure that the time on the virtual machines is synchronized with the host operating system. This makes it possible for you to move the virtual machines around, even to different time zones, and the time on the virtual machines will be automatically synced with the host operating system. This also helps when restoring virtual machine snapshots.
Update virtual machine images offline
In a private cloud deployment, you will be providing a self-service environment where your users will be able to provision their own virtual machines without the need for you to be involved in the request chain. Because users will be provisioning their own resources, you need to make sure that the virtual disk images that are used to spin up these new virtual machines are secure.
In a non-private cloud environment, you would install the operating system and then run Windows Update immediately after installing the operating system. You control this process from end to end so you know that this vital step is going to be performed. But in a virtual environment, it’s possible that users who are less aware of security issues will provision virtual machines and then not update them properly.
You can fix this by using offline update tools to install updates to the virtual machine templates. When the virtual machine templates are updated offline, the virtual machines that are deployed based on those templates will always be up to date with security fixes and updates. You can use the Virtual Machine Servicing Tool (VMST) to accomplish this.
Use appropriate delegation of administration
Finally, make sure that you delegate administration correctly. Make sure that the administrators of the virtual infrastructure or private cloud fabric do not have permissions to access the virtual machine operating systems and that the administrators of the operating systems running on the virtual machines do not have access to the virtual infrastructure or fabric. In fact, you should consider exercising more granular controls over the virtual infrastructure or fabric by using Role Based Access Control. You can accomplish this through the user of Authorization Manager in Windows Server 2008 and Windows Server 2008 R2.
In this article, we took a look at some of the major issues involved with hypervisor security in the Microsoft Private Cloud. For the most part, security requirements in the private cloud are similar to those found in a traditional data center. One of the most obvious examples of where security requirements and considerations differ is hypervisor security, since most private cloud deployments use virtualization as an enabling technology. With this list of security considerations in mind, you can move forward to increase the overall security of your Microsoft private cloud solution.