VCTR-67-000066 - The vCenter Server must have new Key Encryption Keys (KEKs) reissued at regular intervals for vSAN encrypted datastore(s).

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

The KEK for a vSAN encrypted datastore is generated by the Key Management Server (KMS) and serves as a wrapper and lock around the Disk Encryption Key (DEK). The DEK is generated by the host and is used to encrypt and decrypt the datastore.

A mustow rekey is a procedure in which the KMS issues a new KEK to the ESXi host that rewraps the DEK but does not change the DEK or any data on disk. This operation must be done on a regular, site-defined interval and can be viewed as similar in criticality to changing an administrative password.

If the KMS is compromised, a standing operational procedure to rekey will put a time limit on the usefulness of any stolen KMS data.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

If vSAN encryption is in use, ensure that a regular rekey procedure is in place.

See Also

https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_VMW_vSphere_6-7_Y22M04_STIG.zip

Item Details

References: CAT|II, CCI|CCI-000366, Rule-ID|SV-243121r719606_rule, STIG-ID|VCTR-67-000066, Vuln-ID|V-243121

Plugin: VMware

Control ID: fc6ecdf24627b7b17611f280092507502c81b6e50a4c3ec272c543d86e8309fe