Soru

Zorluk: Çok zorSecurity and Compliance Control Design

A government organization is launching a public service portal to process sensitive citizen applications. The architecture uses AWS Organizations and separates workloads into different accounts. A processing application runs on Amazon ECS tasks using AWS Fargate within a processing account (111122223333111122223333). The application must stream and archive finalized application data to an Amazon S3 bucket named `citizen-applications-archive` located in a centralized compliance account (444455556666444455556666). The security architecture must enforce the following security controls: (1) All archived data must be encrypted at rest using a Customer Managed Key (CMK) owned by the compliance account (444455556666444455556666). (2) The ECS tasks in the processing account must be write-only; they must be able to upload archives but must be strictly prevented from decrypting or deleting any archived objects once written. (3) IAM administrators within the processing account (111122223333111122223333) must not be able to bypass the encryption requirements or upload unencrypted data. Which combination of actions must a Solutions Architect perform to design a compliant solution? (Select TWO.)

  1. In the compliance account (444455556666444455556666), configure the key policy of the Customer Managed Key (CMK) to grant the ECS task role in the processing account (111122223333111122223333) permissions to perform `kms:GenerateDataKey` and `kms:DescribeKey` actions. In the processing account, attach an IAM policy to the ECS task role that allows these same actions on the CMK.Cevap
  2. Attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing the processing account (111122223333111122223333) that denies `s3:PutObject` actions on the target bucket unless the request headers enforce server-side encryption with AWS KMS (`x-amz-server-side-encryption` is set to `aws:kms`) and specify the CMK ARN in the compliance account as the key ID.Cevap
  3. C
    In the compliance account (444455556666444455556666), configure the S3 bucket to use the AWS-managed S3 key (`aws/s3`) for default encryption, and configure the S3 bucket policy to allow the ECS task role in the processing account (111122223333111122223333) to perform `s3:PutObject` actions.
  4. D
    Attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing the processing account (111122223333111122223333) that explicitly grants the ECS task role permissions to write objects to the S3 bucket in the compliance account, preventing local IAM administrators from revoking the access.
  5. E
    In the compliance account (444455556666444455556666), configure the S3 bucket policy to allow the ECS task role to write objects, and include a Deny statement in the S3 bucket policy that prevents the processing account's ECS task role from calling the `kms:Decrypt` and `s3:DeleteObject` actions.

Cevap

Configuring the Customer Managed Key policy and the workload's IAM policy to grant `kms:GenerateDataKey` and `kms:DescribeKey` permissions, and attaching an SCP to the processing account's OU to enforce the specific CMK via S3 upload headers.
To write objects to an S3 bucket in a different account using cross-account KMS encryption, the writing principal must have permissions to generate a data key from the destination account's key. This requires configuring the key policy of the Customer Managed Key (CMK) in the compliance account to allow the ECS task role in the processing account to perform `kms:GenerateDataKey` and `kms:DescribeKey`, along with a corresponding IAM policy attached to the ECS task role in the processing account. Furthermore, to prevent local IAM administrators in the processing account from bypassing the compliance controls or uploading unencrypted data, a Service Control Policy (SCP) must be attached to the Organizational Unit (OU) of the processing account. This SCP blocks any `s3:PutObject` actions unless the request headers require server-side encryption with AWS KMS using the specific CMK ARN.

Adım Adım Çözüm

1
Configure the key policy for the Customer Managed Key (CMK) in the compliance account (444455556666444455556666) to allow cross-account operations.
The key policy explicitly permits the ECS task role principal in the processing account (111122223333111122223333) to execute `kms:GenerateDataKey` and `kms:DescribeKey` actions.
Because the KMS key is in a different account than the principal performing the encryption, the resource policy must explicitly delegate trust to the external principal.
2
Grant the ECS task role the necessary KMS and S3 permissions via an IAM policy in the processing account (111122223333111122223333).
The ECS task role is granted `kms:GenerateDataKey` and `kms:DescribeKey` permissions on the compliance account's CMK, and `s3:PutObject` on the destination S3 bucket.
Cross-account access requires explicit permission settings on both sides: the resource policy (KMS key policy) and the user identity policy (IAM policy).
3
Implement write-only controls on the destination S3 bucket in the compliance account (444455556666444455556666).
The S3 bucket policy permits `s3:PutObject` for the processing account's ECS task role, while withholding `s3:GetObject` and `s3:DeleteObject` permissions.
This guarantees that the application can upload the archives but cannot read, decrypt, or delete any data once written.
4
Establish an organization-level Service Control Policy (SCP) to prevent policy evasion by administrators in the processing account.
An SCP attached to the processing account's OU denies `s3:PutObject` calls to the telemetry bucket unless the request uses KMS encryption and specifies the target CMK ARN.
Because local IAM administrators in the workload account can modify IAM configurations, an SCP is required to restrict their ability to upload unencrypted objects or use unauthorized KMS keys.

Anahtar Kavram

Cross-account S3 uploads using a Customer Managed Key (CMK) under organization-level compliance controls.
Bu soruyu puanla