Which steps should the solutions architect take to meet these requirements?
Create an AWS CloudHSM cluster. Create a new CMK in AWS KMS using AWS_CloudHSM as the source for the key material and an origin of AWS_CLOUDHSM. Enable automatic key rotation on the CMK with a duration of 1 year. Configure a bucket policy on the logging bucket that disallows uploads of unencrypted data and requires that the encryption source be AWS KMS.
Provision an AWS Direct Connect connection, ensuring there is no overlap of the RFC 1918 address space between on-premises hardware and the VPCs. Configure an AWS bucket policy on the logging bucket that requires all objects to be encrypted. Configure the logging application to query the on-premises HSMs from the AWS environment for the encryption key material, and create a unique CMK for each logging event.
Create a CMK in AWS KMS with no key material and an origin of EXTERNAL. Import the key material generated from the on-premises HSMs into the CMK using the public key and import token provided by AWS. Configure a bucket policy on the logging bucket that disallows uploads of non-encrypted data and requires that the encryption source be AWS KMS.
Create a new CMK in AWS KMS with AWS-provided key material and an origin of AWS_KMS. Disable this CMK, and overwrite the key material with the key material from the on-premises HSM using the public key and import token provided by AWS. Re-enable the CMK. Enable automatic key rotation on the CMK with a duration of 1 year. Configure a bucket policy on the logging bucket that disallows uploads of non-encrypted data and requires that the encryption source be AWS KMS.
Explanations:
AWS CloudHSM is an AWS service for managing keys, but it cannot directly integrate into AWS KMS as a source of key material. The solution does not meet the requirement of using on-premises HSMs for key generation.
While Direct Connect can enable communication between on-premises HSMs and AWS, the solution does not address the use of an on-premises HSM for key generation in AWS KMS, nor does it correctly enforce the encryption requirement in AWS KMS.
This option correctly uses the EXTERNAL origin in AWS KMS to import key material generated by on-premises HSMs. It also meets the requirement to enforce encryption using AWS KMS via a bucket policy.
Disabling the CMK and overwriting key material with the public key and import token is not a valid approach. Key material cannot be imported into a CMK with an origin of AWS_KMS once it is created. The process described is flawed.
If I’m not mistaken, the answer is:
Create a CMK in AWS KMS with no key material and an origin of EXTERNAL. Import the key material generated from the on-premises HSMs into the CMK using the public key and import token provided by AWS. Configure a bucket policy on the logging bucket that disallows uploads of non-encrypted data and requires that the encryption source be AWS KMS.