VMware NSX provides network virtualization for a software-defined data center, abstracting Layer 2 through Layer 7 networking functions such as switching, firewalling, and routing. NSX embeds the networking and security functionality (typically managed by hardware) in the ESXi hypervisor.
This abstraction enables security and efficiency that were previously infeasible. For example, you can apply micro-segmentation with distributed stateful firewalling and dynamic security policies attached directly to individual workloads.
In addition, vSphere includes several settings to manage the allocation of IP addresses, ports, and encryption. Through hypervisor, VMware decouples the virtual machines from the host providing fault and security isolation at the hardware level.
Preventing the use of hard-coded MAC addresses and virtual span ports
vSphere provides several schemes for automatic allocation of MAC addresses in vCenter Server. You can select a scheme that suits your requirements. For example, you can use generated MAC addresses that are assigned by vCenter Server or the ESXi host. You can also use a range-based or a prefix-based allocation scheme to generate MAC addresses. For more information, see MAC Address Management and MAC Address Assignment from vCenter Server.
With vSphere networking, the security policy of a virtual switch includes a MAC address changes option. This option affects the traffic that a VM receives. When this option is set to Reject, ESXi does not honor requests to change the effective MAC address to an address that differs from the initial MAC address. This setting protects the host against MAC impersonation. The port that the VM adapter used to send the request is deactivated, and the VM adapter does not receive any more frames until the effective MAC address matches the initial MAC address. The guest operating system does not detect that the MAC address change request was not honored. For more information, see MAC Address Changes.
Port mirroring, known as span ports, is turned off in vSphere by default. You can turn it on by creating a port mirroring session. For more information, see Working with Port Mirroring.
VMware recommends that you do not turn on port mirroring. If you turn it on, for example, to meet a compliance request or a monitoring requirement, ensure that distributed virtual switch port mirror traffic is sent only to authorized collector ports or VLANs.
A vSphere Distributed Switch can mirror the traffic from one port to another to allow the packet capture devices collect specific traffic flows. This mirrored traffic captures the entire data in the packets, resulting in total compromise of that data if misdirected. If port mirroring is required, verify that all port mirror destination VLAN, port, and uplink IDs are correct. For more information, see General Networking Security Recommendations.
Encrypting data at rest
VMware vSphere and vSAN store data at rest to prevent data exfiltration. VMware vSphere uses the ESXi hypervisor to perform encryption without modifying the VM. The security architecture of ESXi achieves this goal at the hypervisor layer to yield the following benefits:
No modification to VM operating systems: No changes to existing applications are required. A common method of encryption is provided across any operating system supported by vSphere.
No specialized hardware or infrastructure is required: Encryption works with existing storage devices and storage fabrics.
Policy-based enforcement: vSphere SDK and tools such as VMware vSphere® PowerCLI™ supports policy-based enforcement, providing easy integration into current and future provisioning solutions.
Because all VM files that contain sensitive information are encrypted, the entire VM is protected. Only administrators with encryption privileges can perform encryption and decryption tasks.
The following types of files can be encrypted:
VM files
Virtual disk files
Host core dump files
Encryption is a storage policy that is applied to a VM. After the policy is applied, the VM is automatically encrypted. The encryption policy can be applied on the Storage Policy screens in the vSphere Web Client or programmatically through the vSphere Storage APIs or vSphere PowerCLI. These encryption operations can be performed across many VMs simultaneously, regardless of the type of operating system.
Because of this policy-based enforcement, automation of VM encryption is simple, and it is easy to integrate with an overall provisioning workflow.
With VM encryption, there is assurance of the device doing the encryption, in this case the ESXi hypervisor. This assurance is accomplished in vSphere by enabling Secure Boot on the ESXi host to ensure that only digitally signed code is run.
The following types of keys are used for VM encryption:
Data Encryption Key (DEK): The ESXi host generates and uses internal keys to encrypt VMs and disks. These XTS-AES-256 keys are used as DEKs.
Key Encryption Key (KEK): The vCenter Server instance requests AES-256 keys from the KMS. vCenter Server stores only the ID of each KEK but not the key itself.
When an ESXi host requires a key, the vCenter Server system transfers VM KEKs to the host. The ESXi host encrypts the DEK using the KEK and stores the encrypted internal key on disk. The ESXi host does not store the KEK on disk. If an ESXi host reboots, the vCenter Server instance requests the KEK with the corresponding ID from the external KMS and makes it available to the host. The ESXi host can then decrypt the DEKs as needed.
Similarly, vSAN can perform data-at-rest encryption to protect data in a vSAN cluster.
When the vSAN encryption is turned on, all files are encrypted, protecting VMs and their data. Only administrators with encryption privileges can perform encryption and decryption tasks. Data is encrypted after all other processing such as deduplication is performed. Data-at-rest encryption protects data on storage devices in case a storage device is removed from the cluster.
vCenter Server requests encryption keys from an external KMS. The KMS generates and stores the keys, and vCenter Server obtains the key IDs from the KMS and distributes them to the ESXi hosts. vCenter Server does not store the KMS keys, but keeps a list of key IDs.
To summarize vSAN uses encryption keys as follows:
vCenter Server requests an AES-256 Key Encryption Key (KEK) from an external KMS. vCenter Server stores only the ID of the KEK, but not the key itself.
The ESXi host encrypts disk data using the industry standard AES-256 XTS mode. Each disk has a different randomly generated Data Encryption Key (DEK).
Each ESXi host uses the KEK to encrypt its DEKs and stores the encrypted DEKs on disk. The host does not store the KEK on disk. If a host reboots, it requests the KEK with the corresponding ID from the KMS. The host can then decrypt its DEKs as needed.
A host key is used to encrypt core dumps, not data. All hosts in the same cluster use the same host key. When collecting support bundles, a random key is generated to re-encrypt the core dumps. You can specify a password to encrypt the random key.
For more information, see Using Encryption on a vSAN Cluster.
The technical and operational mechanism of data encryption in the virtualization fabric might vary with the version of vSphere or vSAN and other VMware technology that is in use. For more information, see VMware vSphere Virtual Machine Encryption.
With vSphere, VMware has built one of the most secure and robust virtualization platforms. Encryption is now available through software policies that are independent of the operating system and applications, while maintaining operational efficiencies inherent to vSphere and preserving the security of VMs.
Encrypting data in transit
The ESXi host manages several aspects of the encryption workflow, including encrypting data in transit by using VMcrypt:
Performs the encryption of VM disks
Ensures that the guest data for encrypted VMs is not sent over the network without encryption.
Encryption is performed using the industry-standard OpenSSL libraries and algorithms described in VMware vSphere Virtual Machine Encryption. VM encryption does not require new hardware, but a processor that supports the AES-NI instruction set is required to accelerate the encryption and decryption operations.
Because of the processing cost involved in encryption, using both vSAN datastore encryption and VMcrypt might impair performance for some use cases. You might have to evaluate the performance trade-off of encryption in relation to the security context, the type of data, your hardware, compliance regulations, and other requirements. For more information, see Understanding vSAN Datastore Encryption versus VMcrypt Encryption.
Blocking access to the underlying hardware
By default, VMs are configured to block direct access to the underlying physical hardware. Hence, hackers cannot find a security vulnerability in a VM and run code directly on the physical hardware. You must tightly control privileged access to the ESXi host by using the principles of separation of duties and least privilege.
Emerging security standards rely on segmentation at various levels, including the separation of the management network from the data network. Installing appropriate hardware with sufficient physical ports provides the flexibility to separate traffic in the management and data planes. The hardware without sufficient physical ports can lead to problems in managing API management traffic and separating management functions by security level.
For example, if an application is granted permission to access the vSphere API at a highly privileged level, it creates an attack vector exposing access to the underlying hardware. By applying the principles of least privilege and separation of duties, you can ensure that all systems, applications, and users have the appropriate level of access to the virtual infrastructure. With vSphere and a VIM from VMware, you can use role-based access control to tightly control privileged access in a multi-tenant environment.
The following examples illustrate the importance of tightly controlling privileged access to the virtualization plane:
To maximize the use of hardware resources, some telco operators use an element manager to gauge the load of the underlying hardware in a vSphere environment. However, this approach can expose a vector through which an attacker could gain access to the hardware.
For API-based hardware-level management through the Common Information Model (CIM) interface, root credentials must not be used to access the Input–Output Memory Management Unit (IOMMU) interface. Instead, create a less-privileged vSphere user account for these applications and use the VIM API ticket function to generate a sessionId or ticket to this less-privileged user account for authenticating to the CIM.
VMware writes CIM providers that monitor server hardware, ESXi storage infrastructure, and virtualization-specific resources. These lightweight providers run within the ESXi host.
To ensure that the CIM interface is secure, provide only the minimum access necessary to these remote applications. If you provision a remote application with a root or administrator account and the application is compromised, the virtual environment might also be compromised. For more information, see Control Access for CIM-Based Hardware Monitoring Tools.
