Update 5th November 2020 with i3EN in-transit hardware level encryption between instances within the SDDC boundaries.
This post will describe the various options to encrypt data residing on VMware Cloud on AWS or in-transit to and from VMware Cloud on AWS.
In my conversations with customers, one topic will invariably come up: how do we ensure data confidentiality and integrity?
It applies to many of my customers but in particular one legal firm was especially keen to understand the various ways we protect data – where it’s at rest on VMware Cloud on AWS or transiting to/from the Cloud from DC or encryption within the Cloud. And of course a law firm would be concerned about its clients’ data and with the ever-growing list of compliance and regulation standards, so are we.
Here is a closer look at the encryption models.
Encryption at rest
Today, VMware Cloud on AWS currently provides encryption capabilities for our customers.
Encryption at the physical layer
All customer data is encrypted at rest via self-encrypting drives that use AES-256-XTS to protect all information stored on a VMware Cloud on AWS cluster. The physical hard drives and the keys for these drives are managed by AWS, VMware has no access to the keys. In the event that a hard drive is removed from a customer environment, the drive is cryptographically erased by destroying the encryption key. When a storage device has reached the end of its useful life, AWS decommissions media using techniques detailed in NIST 800-88.
Amazon EC2 NVMe instance storage is encrypted using an XTS-AES-256 block cipher. Encryption keys are unique to each NVMe instance storage device .
Note that NVMe instance storage encryption is always on, and cannot be disabled.
Also be aware that customers cannot bring in their own keys to use with NVMe instance storage.
Read more on encryption of the NVME devices on the AWS FAQ.
Encryption at the guest level
For customers who require additional encryption requirements (FIPS, KMS support, HSM backed etc.) VMware fully supports the use of encryption technologies deployed by our customers within the guest operating systems of their virtual machines.
This enables customers to deploy the same security technologies they use in their datacenters today from the vendors of their choice.
Customers can configure their in-guest encryption and security software to use the encryption algorithms and key management systems they have currently deployed in order to retain industry compliance and full control of the key management lifecycle.
With a properly configured encryption solution, it will not be possible for VMware or AWS to ever see the customer’s data in the clear.
For example, we support the likes of HyTrust and Gemalto/Thales Vormetric for VMs running on VMware Cloud on AWS. Check out the marketplace for up-to-date details on the supported solutions.
VMware does not provide an in-guest encryption application and at this time, VMware vSphere Virtual Machine Encryption is NOT supported on VMware Cloud on AWS and VMware does not currently have a timeline to offer this functionality.
Encryption at the virtual storage level
VMware also offers vSAN encryption for our VMware Cloud on AWS customers. This encryption is be done at a virtual storage level and is FIPS compliant.
All customer virtual machines stored on the SDDC, will be encrypted using vSAN encryption which supports the de-duplication and compression benefits that vSAN currently provides.
vSAN encryption will not replace the self-encrypting drives, it will add an additional layer of encryption for our customers. vSAN encryption will be backed by the AWS Key Management Server (AWS KMS) deployed in the same Virtual Private Cloud as the customer’s Software Defined Data Center (SDDC).
Glenn Sizemore recently published a great article on vSAN encryption and especially some of the decisions behind using AWS KMS for the key management server.
Customers will be able to rotate their encryption keys through the VMware Cloud on AWS interface as needed in order to meet their security and compliance needs.
It’s pretty straight-forward to regenerate the encryption keys:
The vSAN Encryption feature backed by AWS KMS is FIPS 140-2 compliant.
With Self-Encrypting Drives, vSAN Encryption and In-Guest encryption, customers have the potential to implement three layers of encryption in VMware Cloud on AWS. This portfolio of encryption options gives customers extensive control over their security configurations and should meet the requirements of the most stringent regulations.
Encryption in transit
Encryption to/from the Cloud
All data to and from the Cloud can be encrypted through IPSec VPN. The default encryption mechanism is AES-256. The customer is in control of the pre-shared keys.
| VPN Types | Policy-based VPN or Route based VPN |
| IKE | IKEv1, IKEv2, IKE Flex |
| DH Group | DH 2, 5, 14, 15, 16 |
| Digest Algo | SHA1, SHA256, Null |
| Encryption Alg. | AES128, AES256, AES GCM128, AESGCM192, AES GCM 256 |
If you use HCX for data migration, we even go to Suite-B standards (that’s the cryptographic standard recommended by the NSA so yes, it’s pretty secure).
Encryption within the Cloud
With i3EN hosts:
With i3EN instances, we added in-transit hardware level encryption between instances within the SDDC boundaries. This encryption also leverages the AWS KMS mentioned above.
With i3 hosts:
The traffic within a VMware Cloud on AWS SDDC made of i3 instances is not encrypted in transit. Essentially, I would follow the guidelines describes in AWS’s following blog post.
We would equally recommend that organisations implement encryption of sensitive information in motion wherever possible.
One thing that is supported however is encrypted vMotion: it is available between hosts inside the Cloud SDDC.
I hope this post helped you in understanding the various encryption options in VMware Cloud on AWS.
nicovibert.com 