Soru

Zorluk: Çok zorEnhancing Data Protection and Compliance

A multinational logistics company collects shipping manifests containing customer PII in regional business unit AWS accounts. These manifests are uploaded to a centralized Amazon S3 bucket in a dedicated Data Archive AWS account under AWS Organizations. Currently, the bucket uses default server-side encryption with the AWS managed key (aws/s3).

The security team mandates that the architecture be enhanced to meet these compliance requirements:
1. All archived data must be encrypted with a key that supports automatic rotation and allows immediate revocation.
2. Regional accounts must be prevented from uploading objects unless they are encrypted using this specific key.
3. No local administrators in the Data Archive account should be able to disable encryption, delete the key, or alter these bucket access rules.

Which combination of actions will meet these requirements with the least operational complexity?

  1. Create a customer managed KMS key in the Data Archive account with automatic rotation enabled. Set the key policy to grant kms:GenerateDataKey and kms:Decrypt permissions to the IAM roles in the regional accounts. Update the S3 bucket to use this key for default encryption. Configure an S3 bucket policy that denies s3:PutObject if the s3:x-amz-server-side-encryption-aws-kms-key-id condition does not match the customer managed key ARN. Apply an SCP at the Organization root that denies kms:PutKeyPolicy, kms:ScheduleKeyDeletion, s3:PutEncryptionConfiguration, and s3:PutBucketPolicy actions in the Data Archive account unless the principal is the central administration role.Cevap
  2. B
    Enable automatic rotation on the default AWS managed key (aws/s3) in the Data Archive account. Configure the S3 bucket policy to allow uploads from regional accounts while denying s3:PutObject if the encryption type is not aws:kms. Attach an SCP to the Data Archive account that denies s3:PutEncryptionConfiguration and s3:PutBucketPolicy actions for all local administrator IAM roles, delegating the key policy administration of aws/s3 to a central security role.
  3. C
    Create a customer managed KMS key in the Data Archive account. Attach an SCP to the Organizational Unit (OU) containing the Data Archive account that explicitly allows the regional accounts' IAM roles to perform s3:PutObject and kms:GenerateDataKey on the archive bucket and the KMS key. In the same SCP, deny kms:ScheduleKeyDeletion and s3:PutEncryptionConfiguration for all other principals in the Data Archive account, bypassing the need for local bucket policies or KMS key policies.
  4. D
    Create a customer managed KMS key in the Data Archive account with automatic rotation enabled. Update the S3 bucket default encryption to use this key. Configure the S3 bucket policy to deny s3:PutObject if the s3:x-amz-server-side-encryption header is not set to aws:kms. Rely on the default KMS key policy that grants root access to authorize the regional accounts' IAM policies to use the KMS key, and deploy an AWS Config rule to remediate any unauthorized changes to S3 or KMS configurations.

Cevap

Create a customer managed KMS key, configure its policy to allow the regional accounts to perform key operations, set S3 bucket default encryption to use it, apply a bucket policy denying uploads that do not use this specific key ARN, and attach an SCP restricting S3 policy and KMS key configuration changes to the central administrative role.
The correct solution involves creating a Customer Managed Key (CMK) to allow key policy modification for cross-account access and enable automatic key rotation. The S3 bucket policy must restrict uploads to only this specific key by using the s3:x-amz-server-side-encryption-aws-kms-key-id condition key. To enforce compliance and prevent local administrators in the Data Archive account from disabling encryption, modifying policies, or deleting the key, an SCP must be applied at the Organization level to deny those operations.

Adım Adım Çözüm

1
Select the correct KMS key type for the requirements.
Choose a customer managed KMS key (CMK) instead of the AWS managed key (aws/s3) because AWS managed keys do not support policy modification or rotation management for cross-account access.
Compliance requires immediate revocation and automatic rotation, which are only configurable on customer managed KMS keys, and cross-account access requires modifying the KMS key policy.
2
Configure permissions for regional accounts to write to the central bucket.
Update the KMS key policy in the Data Archive account to allow the IAM roles in the regional accounts to run kms:GenerateDataKey and kms:Decrypt. Ensure the regional accounts' IAM policies allow these actions.
For cross-account KMS-encrypted S3 uploads, the caller must have permissions on both the S3 bucket policy and the KMS key policy.
3
Enforce the use of the specific customer managed KMS key in S3.
Configure S3 default encryption to use the customer managed key, and add a bucket policy condition denying s3:PutObject if s3:x-amz-server-side-encryption-aws-kms-key-id does not match the key's ARN.
This guarantees that regional accounts cannot bypass the encryption rules by using another key (such as their own local KMS keys or the default aws/s3 key).
4
Implement governance boundaries to prevent policy drift and deletion.
Attach an SCP at the root of the organization that denies kms:PutKeyPolicy, kms:ScheduleKeyDeletion, s3:PutEncryptionConfiguration, and s3:PutBucketPolicy within the Data Archive account, except for the central administrative role.
SCPs act as fine-grained guardrails that restrict actions even for local administrators within member accounts, preventing configuration drift.

Anahtar Kavram

Cross-account S3 bucket access with custom KMS keys requires explicit configuration in both the S3 bucket policy and the KMS key policy. Enforcing a specific key is done using the s3:x-amz-server-side-encryption-aws-kms-key-id condition, while SCPs restrict policy changes and configuration drift for local administrators.
Bu soruyu puanla