An online booking system runs in a production AWS account under an AWS Organizations organization. The application uploads travel reservation documents containing personally identifiable information (PII) to an Amazon S3 bucket located in a separate dedicated compliance AWS account. The security team must ensure that all uploaded documents are encrypted at rest using a customer managed key (CMK) managed within the compliance account. The solution must enforce this encryption requirement for all uploads and allow the application to write to the bucket with minimal administrative overhead. Which combination of configurations will meet these requirements?
- In the compliance account, create a KMS CMK and update its key policy to allow the production account's IAM role to perform kms:GenerateDataKey and kms:Decrypt operations. Configure the S3 bucket policy to deny s3:PutObject requests that do not specify aws:kms as the encryption type and do not specify the compliance account's CMK ARN. In the production account, attach an IAM policy to the application's IAM role allowing s3:PutObject on the compliance S3 bucket, and kms:GenerateDataKey and kms:Decrypt on the compliance account's CMK.Answer
- BIn the compliance account, enable default bucket encryption using the AWS managed KMS key (aws/s3). Configure the S3 bucket policy to deny s3:PutObject requests unless they use the aws/s3 key for server-side encryption. In the production account, attach an IAM policy to the application's IAM role allowing s3:PutObject on the compliance S3 bucket and kms:GenerateDataKey on the aws/s3 key.
- CIn the compliance account, create a KMS CMK and enable default bucket encryption using this CMK. Configure the S3 bucket policy to allow s3:PutObject actions originating from the production account's IAM role. In the production account, attach an IAM policy to the application's IAM role allowing s3:PutObject on the compliance S3 bucket, without configuring any KMS permissions in either account, relying on the bucket's default encryption configuration to automatically apply the key.
- DIn the compliance account, create a KMS CMK and configure the S3 bucket policy to deny unencrypted uploads. In AWS Organizations, attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing the production account that permits kms:GenerateDataKey and kms:Decrypt on the compliance account's CMK for all principals, assuming this SCP grants the necessary permissions.
Answer
In the compliance account, create a KMS CMK and update its key policy to allow the production account's IAM role to perform kms:GenerateDataKey and kms:Decrypt operations. Configure the S3 bucket policy to deny s3:PutObject requests that do not specify aws:kms as the encryption type and do not specify the compliance account's CMK ARN. In the production account, attach an IAM policy to the application's IAM role allowing s3:PutObject on the compliance S3 bucket, and kms:GenerateDataKey and kms:Decrypt on the compliance account's CMK.
The correct option outlines the proper cross-account security setup for S3 and KMS. A Customer Managed Key must be used because its key policy can be modified to trust external accounts. Permissions must be explicitly declared on both the KMS key policy (in the destination account) and the IAM policy (in the source account) for the upload to succeed. The S3 bucket policy then acts as a compliance guardrail by denying uploads that do not specify the correct KMS key.
Step-by-Step Solution
Key Concept
Cross-account S3 bucket uploads with AWS KMS encryption require explicit permissions on both the S3 bucket and the KMS key policy, which can only be achieved using Customer Managed Keys (CMKs) and not AWS managed keys.