Examkin

Question

Difficulty: HardStrengthening Identity, Access, and Network Security

An enterprise is auditing its multi-account AWS environment to strengthen network and identity security. The environment consists of a central logging AWS account (Account A) and a production member account (Account B). Applications running in Account B currently write log files to an Amazon S3 bucket located in Account A. The S3 bucket is encrypted using the default AWS managed key (`aws/s3`), and the bucket policy allows wildcard access (`"Principal": "*"`) filtered by a condition restricting access to the organization's ID.

To improve the security posture, the company wants to implement the following changes:
1. Enforce encryption of the logs using a Customer Managed Key (CMK) that supports key rotation and cross-account access.
2. Restrict bucket access strictly to a specific IAM role (`AppLogRole`) in Account B.
3. Ensure all logging traffic is routed privately and securely, preventing access to the bucket from outside a specific VPC interface endpoint (`vpce-12345678`) deployed in Account B.

Which combination of actions will meet these security requirements?

  1. Create a customer managed key in Account A with a key policy that grants kms:GenerateDataKey and kms:Decrypt permissions to the AppLogRole in Account B. Update the S3 bucket policy in Account A to allow s3:PutObject permissions to the AppLogRole in Account B, while adding a policy statement that denies any S3 actions on the bucket if the aws:sourceVpce condition does not match vpce-12345678.Answer
  2. B
    Create a customer managed key in Account A. Apply a Service Control Policy (SCP) to Account B that allows the AppLogRole to perform kms:GenerateDataKey against Account A's key resource. Update the S3 bucket policy in Account A to allow s3:PutObject permissions to the AppLogRole in Account B, while adding a policy statement that denies any S3 actions if the aws:sourceVpc condition does not match the production VPC ID.
  3. C
    Modify the key policy of the default AWS managed S3 key (aws/s3) in Account A to grant kms:GenerateDataKey and kms:Decrypt permissions to the AppLogRole in Account B. Update the S3 bucket policy in Account A to allow s3:PutObject permissions to the AppLogRole in Account B, while adding a policy statement that denies any S3 actions if the aws:sourceVpce condition does not match vpce-12345678.
  4. D
    Create a customer managed key in Account A with a key policy that grants kms:GenerateDataKey and kms:Decrypt permissions to Account B's root account. Update the S3 bucket policy in Account A to allow s3:PutObject permissions to the AppLogRole in Account B, but do not restrict the VPC endpoint in the bucket policy, relying instead on a Service Control Policy (SCP) in Account B to block S3 API calls unless the request originates from vpce-12345678.

Answer

Create a customer managed key in Account A with a key policy that grants kms:GenerateDataKey and kms:Decrypt permissions to the AppLogRole in Account B. Update the S3 bucket policy in Account A to allow s3:PutObject permissions to the AppLogRole in Account B, while adding a policy statement that denies any S3 actions on the bucket if the aws:sourceVpce condition does not match vpce-12345678.
The correct option addresses all security requirements securely and operationally. First, it implements a customer managed key (CMK) in Account A and grants permissions to the application role in Account B, which is necessary because default AWS managed keys (such as aws/s3) cannot be shared across accounts. Second, it configures the S3 bucket policy in Account A to allow s3:PutObject permissions to the specific IAM role in Account B. Finally, it uses a Deny statement with the aws:sourceVpce condition in the S3 bucket policy to ensure that no traffic can access the S3 bucket from outside the designated VPC interface endpoint (vpce-12345678).

Step-by-Step Solution

1
Address the encryption requirement by replacing the default AWS managed key (aws/s3) with a customer managed key in Account A.
A customer managed KMS key is created in Account A. Unlike AWS managed keys, its policy can be modified to trust external accounts.
AWS managed keys do not support policy modification and cannot be shared across different AWS accounts.
2
Configure the customer managed key policy in Account A to allow cross-account access.
The key policy is updated to grant kms:GenerateDataKey and kms:Decrypt permissions to the AppLogRole in Account B.
This allows the application role in the member account to encrypt the logs when uploading them to the S3 bucket.
3
Configure the S3 bucket policy in Account A to restrict access and enforce the network boundary.
The bucket policy is updated to permit s3:PutObject only to the AppLogRole in Account B and includes a Deny statement for all S3 actions if the aws:sourceVpce condition does not match vpce-12345678.
Enforcing the VPC endpoint restriction at the bucket policy level prevents any traffic from reaching the bucket unless it originates from the specified interface VPC endpoint, securing the resource perimeter.

Key Concept

Cross-account resource access security using customer managed KMS keys and S3 bucket policies with VPC endpoint conditions.
Estimated Time:2m 30s
Rate this question

Topics

Strengthening Identity, Access, and Network Security