The vShield security suite has expanded beyond virtual firewalls to cover other aspects of VMware security. This vShield security overview covers these five components:
- vShield Manager, which centralizes vShield management;
- vShield Zones, which is a virtual firewall;
- vShield App, which is the upgraded version of vShield Zones and adds additional virtual network security;
- vShield Edge, which offers security and gateway services to isolated virtual machines (VMs); and
- vShield Endpoint, which provides antivirus protection for guest operating systems.
Before installing vShield components, you should know which aspects of your infrastructure you want to protect and how you will secure these virtual machines (VMs). Base your zoning policies on these three factors: the types of applications running on VMs, regulatory compliance and how you want to segment the virtual, private and public networks.
For networking, you want to create protection zones and place VMs in virtual LANs. In most cases, you should isolate certain VMs from each other. A DMZ is one example where you want to keep VMs isolated on a public network and control their communication.
Never have a DMZ public network on the same vSwitch as a private network. You typically have multiple vSwitches on a host that can be configured for one or more VLANs. Physical network interface cards (NICs) are dedicated to vSwitches and cannot be shared between two vSwitches. Multiple vSwitches can prevent different traffic types from mixing on the same physical NICs.
With compliance, the scope of Payment Card Industry (PCI) checks is all about the network. More specifically, if credit card traffic flows over a network, anything on that network falls under PCI regulations. Segmenting traffic for VMs that handle credit card data onto their own virtual network can reduce the scope of PCI. Basically, put traffic into groups and isolate it from other groups, as seen below:
- vSwitch1: Management console/VMkernel
- vSwitch2: Storage network (iSCSI)
- vSwitch3: Accounting department
- vSwitch4: General traffic
- vSwitch5: DMZ
After perusing this vShield security overview, you should gain a better grasp of these requirements and considerations.
VShield security overview: Deployment considerations
The vShield Manager VM can migrate from host to host, and it fully supports Distributed Resource Scheduling and High Availability. When a vShield Manager VM is unavailable, VShield agents are unaffected. But you should make vShield Manager highly available and deploy it to shared storage. It's recommended that vShield Manager is deployed as a thick disk, because it takes up only 8 GB.
Plan on deploying a vShield Zones/App agent on every cluster host -- which ensures that VMs remain protected after migrating to a new host. If a VM migrates to a host without an agent, it's no longer protected.
The vShield Zones/App agents should never migrate to another host. Each host has an agent, which needs to stay on the host. To prevent accidental migrations of Zones/App agents, install the agent VMs to the host's local disk so they cannot move via vMotion.
Finally, make sure to meet the vShield Zones requirements. The hardware requirements are pretty basic: The vShield Manager VM needs 3 GB of memory and 8 GB of disk space, and the VShield Zones/App agents require 1 GB of memory and 5 GB of disk space. Memory reservations are automatically created to ensure that the vShield Manager and agent VMs are guaranteed physical memory.
VMware vShield components require VCenter Server 4.0 Update 1 or greater, and they also support ESX/ESXi hosts version 4.0 Update 1 or greater. You also need a version of ESX that comes with a vShield license.
For a closer look at each component, check out the other sections of this vShield security overview.
This was first published in April 2011