Introduction
There is a reason why virtualization was the last Big Thing (the current Big Thing is cloud computing, which has dependencies on virtualization). You can use client and server virtualization technologies to reduces the size of your datacenter and client footprints, you can consolidate clients and servers to reduce your overall power requirements and energy expenditures, and you can put a stop to rack space issues by moving servers from multiple physical machines to many fewer virtual servers. Virtualization is a success because it solves real world problems and it works.
However, there is one area that virtualization does not address: security. Virtualization technologies are not security technologies. In fact, virtualization introduces security issues that mirror those in physical environments. Security becomes even more important in virtualized environments because of the potential multiplicative effects of compromised virtual servers.
For this reason you need to be even more mindful of core security concepts and their implementation. One of the most important concepts that you need to apply in all networks, and especially in virtualized client and server networks, is that of security zoning. A security zone is a collection of resources that share a common security exposure or security risk. There are several ways to characterized security zones, such as:
- All members of the same security zone share a common risk exposure
- All members of the same security zone share similar value to the organization. High value assets are never in the same security zone as low value assets
- Internet facing hosts are always in a different security zone that non-Internet facing hosts
- A compromise in one security zone should not be able to lead to compromise in other security zones; damage to the compromised security zone should be isolated to that zone and not impact other zones
- Security zones must be separated by physical or logical segmentation; access control devices or software must be used to enable least privilege access between members of different security zones. You could use a firewall to create physical segmentation, or advanced software methods such as IPsec to create virtual network segmentation
Security zoning and segmentation should be considered in virtual as well as physical environments. To illustrate some examples of how you can do this, let’s look at how you might address segmentation in a simple three zone configuration:
- Internet edge security zone
- Client systems security zone
- Network services security zone
The figure below shows an example of how a simple server consolidation focused virtualization project might be set up. There is a single virtual server and this virtual server hosts the firewall, the domain controller, the mail server and the file server. These virtual machine are connected to the same physical network as the client systems.
This is a poor security model because:
- Internet facing virtual machines are co-located on the same virtual server as the network services virtual machines. A break-out in the Internet facing firewall virtual machines could have negative impact on network services machines, which belong to a different security zone
- Client systems are on the same physical network as the network services virtual machines. A break-out on the client systems segment could have an adverse effect on the network services virtual machines. Client systems need to be segmented away from the network services virtual machines and their security zone
While this is a common design in simple server consolidation projects, it’s an exceptionally poor design from a security point of view. Let’s see what we can do to improve this situation.
Figure 1
The figure below shows a slightly better security configuration. This design adds a second virtual server. The first virtual server hosts only edge security devices; this effectively segments the Internet facing firewalls away from non-Internet facing hosts, thus successfully segmenting the firewall security zone away from the network services security zone. Should be virtual firewalls or the virtual server on which the firewalls run be compromised, there is reduced risk that a break out on these devices will have an adverse impact on the virtual machines located on a second virtual server.
The second virtual server hosts only virtual machines that belong to the network services security zone. However, the client systems are still on the same physical network as the network services virtual machines. This is not an optimal configuration because if there is a break out in the client systems security zone, there are no access control or security devices in between these security zones to limit the potential impact of the breakout.
So while this design is better than the first one where virtual machines from all security zones are co-located on the same virtual server, there is still more we can do to create a secure configuration.
Figure 2
The figure below shows an improvement in the design, where all security zones are segregated from one another. The virtual server on the edge of the network contains only a firewall array. Notice that in order to create such a robust design, you’ll need to use a “software” firewall. With virtualization taking front stage in so many networks, it’s only a matter of time where edge firewalls will be routinely virtualized on edge virtual servers. You can do this now with virtual offerings from a number of vendors, such as Check Point firewalls or Microsoft ISA or TMG firewalls. There are also a number of Linux based virtual firewalls available.
We still have a second virtual server, but notice that the network services virtual server is physically segmented from the client systems network by the edge virtual server hosting the firewalls. In this example the edge system could host virtual firewalls that are multihomed and thus connect to the network services physical network and the client systems physical network, or you could create a more complex firewall environment on the edge virtual server, where separate firewalls connect systems on the client systems network to the network services network.
The key here is that there is some type of physical or logical (or both) segmentation between systems that belong to different security zones. The Internet is isolated from all internal networks, the network services virtual machines are isolated from the client systems and the client systems are isolated from the network services virtual machines.
With this design virtual machines belonging to different security zones are placed to different physical virtual servers. Non-virtualized assets are physically or logically isolated using network choke points, such as the virtualized firewalls on the edge virtual server.
Figure 3
As virtualization technologies advance, you will likely find that client side virtualization will become more popular. One way to virtualizing the client side is to create a “virtual desktop infrastructure”. There are a number of ways to approach VDI; one way to do this is to host multiple distinct virtual client systems on a virtual server. Users then connect with thin clients to these dedicated client virtual machines. This approach has an advantage over “presentation virtualization”, which is the terminal service client experience, in that users are actually connecting to full operating systems on virtual clients instead of the somewhat watered down client side experience terminal services clients often see.
In the figure below you can see that we have added a third virtual server that hosts the VDI. Many client systems are installed on this virtual server and users with thin client systems can be located anywhere, since the thin client has almost no attack surface due to the OS being located on the virtual server, not on the thin client. In this example think of the operating system contained on the client virtual machines as being “streamed” to the thin client.
To optimize the security of this infrastructure, we still need to consider security zoning. To help insure proper segmentation of the identified security zone, you will need to deploy a third virtual machine for the VDI and segment that virtual server from the other security zones, as seen in the figure below. Again, the take home message is that resources belonging to different security zones must not be hosted on the same virtual server, and that the virtual servers hosting virtual machines belonging to different security zones need to be physically or logically isolated from one another.
Figure 4
Summary
In this article we examined a key consideration when assessing the security of a virtualized environment: network security zoning. In many virtualization projects, administrators will focus more on designing the virtualization architecture and forget that virtualization is not a security technology and that the same principles of security employed on physical networks need to be enacted on virtual networks. We saw in this article that one way to deal with this situation is to identify the different security zones on your network and then co-locate virtual machines belonging to the same security zone on the same virtual server. In addition to avoid the mixing virtual machines belonging to different security zones to the same virtual server (or virtual cluster), we also pointed out the importance of placing network security devices that perform access controls between different security zones so that a compromise in one zone does not impact assets in other security zones. Going forward, you’ll need to consider VDI and other client virtualization technologies and consider how to isolate the virtual clients from resources that belong to high security zones.
