You should also use existing security practices to identify that the person modifying data within your infrastructure is authorized to do so. If you transform all of your existing end-user service offerings into virtual machines (VMs) and run them as virtual service offerings (VSOs), then traditional approaches to security must continue within this layer.
Unfortunately, the resource pool layer, which provides resources to VSOs, isn't designed to interact with users. Physical machines within the resource pool are simply host servers that run a virtualization engine, meaning that only administrators and technicians should deal with them. Each of these environments -- resource pools and VSOs -- runs within a given security context that's usually supported by a central directory service. Consider creating segregated security contexts for both infrastructures.
In fact, end users have nothing to do with resource pools. End users don't interact with routers or switches in your network, so you must create segregated security contexts for both the resource pool and the VSOs. For example, if you run VMware or Citrix hypervisors and a network of services that rely on Windows Server, then the security context of the resource pool would automatically be separate from the VSO security (Figure 1). This is because the host environment often runs a different OS -- a custom form of Linux -- than the VSOs, which segregates the two contexts naturally.
However, if you run host servers that rely on the same OS as the VMs you run, you'll need to segregate the security context of the resource pool and the VSOs. For example, you would do this when you run a Windows network and rely on the Microsoft Hyper-V hypervisor. The same is true when you run a Linux network and rely on the hypervisor from the same Linux distribution.
In the case of a Windows network, you would have to create separate Active Directory forests for the resource pool and the VSOs, and then make sure there is no link between them. Creating this type of separate security context between the two infrastructures prevents leaks from one environment to the other.
Isolate the resource pool
Creating a segregated context for the resource pool is the first step in securing a virtual infrastructure. You should also supplement this segregation with other security measures. Here are just a few additional considerations:
- Control access to the resource pool so that only trusted individuals have permissions for it. Each individual accessing the resource pool should have a named account that's different from the account he or she uses to interact with virtual service offerings.
- Control access to resource pool management tools. Only trusted individuals should have access to the tools used to control resource pool components -- physical servers, hypervisors, virtual networks and shared storage.
- Manage virtual engine or hypervisor access and the virtual machines they run. All VMs should be built and secured through administrative staff first. If certain users, such as developers, testers or trainers, interact with VMs in your network, resource pool administrators should build and manage those machines.
- Secure all folders containing VMs and the files that comprise them with appropriate access rights. Both online and offline VM files should be tightly controlled. Ideally, you should also audit VM file access.
- Reduce host attack surfaces by running minimal installations on your host servers. Be sure that your hypervisor installation is as secure as possible.
- Implement appropriate security tools. To support a proper security policy, your infrastructure should include systems management, inventory, auditing and monitoring tools as well as standard security equipment.
- Segregate network traffic. A proper resource pool includes private network connections for management traffic, live-motion traffic and storage traffic. Segregate all of these networks from public network traffic in your infrastructure.
Harden the resource pool
In addition to security context segregation, consider in-depth strategies for your virtual infrastructure. The castle defense system (CDS) model, a defense strategy endorsed by Resolutions Enterprises Ltd., an independent data center consulting group in Victoria, B.C., uses "defense in depth" to secure an infrastructure. Many organizations use defense in-depth strategies for traditional service networks and should carry them over to secure the resource pool (see Figure 2). Apply this defense model to either resource pools or VSOs.
Prevent over administration
Another way to secure your resource pool is to limit the number of administrators assigned to it. Two administrators with full access to the environment should be enough. Once they are assigned, you can give them appropriate delegation roles based on the size of your data center and who needs to do what within it. Resource pool administrators shouldn't manage the VSO network. If you have enough personnel, it's best to segregate the roles. If you don't, then make sure your administrators use different privileged accounts in each environment and know that when they perform a given task in one environment, they have different responsibilities when performing a separate task in a different environment.
Finally, protect your VMs at all times. For example, at-rest VMs can be at greater risk than active ones. When virtual machines are in a saved state, or "parked," they generate a file with the in-memory contents of the VM. This file could be analyzed to discover privileged account names and passwords. VMs can also be at risk if someone steals files and takes them out of the building. Once a hacker has a virtual machine in a private environment, he or she can easily break into it and access its contents.
Danielle Ruest and Nelson Ruest are IT experts focused on continuous service availability and infrastructure optimization. They are authors of multiple books, including Virtualization: A Beginner's Guide and Windows Server 2008, The Complete Reference for McGraw-Hill Osborne. Contact them at firstname.lastname@example.org.
This was first published in November 2009