Preventing sensitive information from reaching the wrong people while ensuring appropriate, authorized access to a company's data is a fundamental problem summed up as confidentiality or privacy. VxRail addresses the confidentiality of data in use, data in motion, and data at rest.

vSphere encryption

Individual VMs can be encrypted using vSphere Encryption, and VMs in motion can be encrypted using vMotion encryption. This encryption is embedded into the VMware solution and can be used without the use of any additional third-party software. The keys for vSphere encryption are controlled at the hypervisor level; thus, VMs do not have access to them.

VM Encryption provides the flexibility to enable encryption on a per-VM basis, which means a single cluster can have encrypted and non-encrypted VMs. VM Encryption follows the VM wherever it is hosted. So even if the VM were moved to a datastore outside VxRail, it would remain encrypted.

VxRail supports encrypted vMotion, where VMs are encrypted when they are moved between hosts. This includes vMotion migrations within a VxRail and vMotion migrations to or from a VxRail cluster within a vCenter instance. Encrypted vMotion can be used with vSAN encryption to have data at rest encryption and data-in-transit encryption. Encrypted vMotion is enforced for VMs with vSphere Encryption enabled.

vSAN encryption

Data-at-rest encryption (D@RE) from vSAN, which offers FIPS 140-2 verified security, can be used with VxRail to encrypt a datastore. In addition to protecting your workloads, vSAN encryption is the easiest and most flexible way to encrypt data at rest because the entire vSAN datastore is encrypted with a single setting. This encryption is cluster-wide for all VMs using the datastore. Encrypted VM data typically does not benefit from space-reduction techniques such as deduplication or compression. However, with vSAN, encryption is performed after deduplication and compression, so the full benefit of these space reduction techniques is maintained.

Figure 6. VM encryption vs. vSAN encryption

Key Management Server (KMS)

Except for Encrypted vMotion, where vSphere provides the temporary keys that are used to encrypt the data in motion, a Key Management Server (KMS) is required for the secure generation, storage, and distribution of the encryption keys. When encryption is enabled, vCenter establishes a trust relationship with the KMS, and then passes the KMS connection information to the ESXi hosts. The ESXi hosts request encryption keys directly from the KMS and perform the data encryption and decryption. vCenter connectivity is only required for the initial setup.

Because the KMS is a critical component of the security infrastructure, it should have the same level of redundancy and protection that is typically applied to other critical infrastructure components, Such as DNS, NTP, and Active Directory. It is important to remember that the KMS should be run physically separate from the elements that it encrypts. During startup, the ESXi hosts will request the keys from the KMS. If the KMS is unavailable, the system cannot complete the startup.

VxRail and VMware support KMSs that are compatible with Key Management Interoperability Protocol (KMIP) v1.1 or higher. VMware maintains a Compatibility Guide of KMSs that have been validated with vSphere here: https://www.vmware.com/resources/compatibility/search.php?deviceCategory=kms

Within vSphere, encryption is handled by a common set of FIPS 140-2 validated modules. These common modules are designed, implemented, and validated by the VMware Secure Development Lifecycle. Having a set of common modules for encryption allows VxRail to make encryption easier to implement, manage, and support.

Encryption is enabled on VxRail through a simple configuration setting in vCenter. Access controls ensure that only authorized individuals are allowed to enable or disable encryption. A "No Cryptography Administrator" role empowers an administrator to do everyday administrative tasks but without the authority to alter encryption settings.

Encryption is a powerful tool for protecting the confidentiality of information, and VxRail has built in encryption capabilities to protect data in use, in motion, and at rest. However, the data security that is provided by encryption is only as good as the generation, protection, and management of the keys used in the encryption process.

Encryption keys must be available when they are needed, and access to the keys during decryption activities must be preserved for the lifetime of the data. The proper management of encryption keys is essential to the effective use of cryptography. Many organizations centralize key management across the enterprise to simplify management, enforce policy, and provide reporting and auditing for compliance.

VxRail and vSphere support the Key Management Interoperability Protocol (KMIP), allowing it to work with many enterprise key management systems. For organizations that have existing key management services, VxRail and vSphere easily integrate, providing a single point of key management across the enterprise. VMware offers a list of compatible key management servers.

VxRail Manager FIPS 140-2 Level 1

As part of FIPS 140-2 Level 1 compliance, VxRail added the following capabilities to VxRail Manager virtual appliance as of VxRail 7.0.010 release.

• VxRail Manager - Implemented the Dell OpenSSL FIPS validated crypto modules to protect data-in-transit
• VxRail Manager - FIPS mode enabled in VxRail Manager operating system
• VxRail Manager - Storage of keys and credentials using Dell BSAFE Crypto-C Micro Edition and two FIPS validated cryptographic modules using AES 256-bit

Note: Dell uses the Dell FIPS-compliant crypto module. 

Hardware based encryption

In VxRail satellite nodes, hardware based encryption is supported through support of Self-Encrypting Drives, or SED’s. SED’s protect against physical theft of drives, and the subsequent compromise of data privacy. If a cyber-criminal were to attempt to access the data stored on the drive, he or she will not know the required locking key passphrase and therefore be thwarted from accessing the encrypted drive data.

To support key management for the SED’s, VxRail has a solution called Secure Enterprise Key Manager (SEKM). SEKM enables the customer to use either an external Key Management Server (KMS) or the iDRAC Key Manager to manage the keys that encrypt or decrypt SEDs on the VxRail appliance.

Note: Hardware encryption (SED’s) is available using iDRAC through the Native Key Provider with VxRail satellite nodes. Please contact your Dell sales rep for use in vSAN based VxRail nodes.

Lockdown mode

For environments needing even greater security with flexibility, lockdown mode can be configured for the ESXi. In lockdown mode, the ability to perform management operations on individual hosts is further limited, forcing management task completion to occur through vCenter where they can be logged against the user who performed them.

Lockdown in "Normal" mode allows a select group of users to be on an allow list, enabling them to manage the servers locally instead of through vCenter; this allow list must include VxRail management accounts.

In strict lockdown mode, no users are allowed to manage the servers locally. VxRail does not support lockdown in "Strict" mode.

Secure management with HTTPS

Unsecured management traffic is a significant security risk. Because of that, VxRail management interfaces communicate over a TLS channel with various components vCenter, iDRAC, and HCI System software components to ensure the data-in-flight is secure over HTTPS protocol. Reference support material for current TLS versions as they are subject to change. In addition, access to the command line of the ESXi servers must use SSH.