Question

Difficulty: MediumSecurity and Compliance Control Design

An enterprise is designing a secure transaction logging system. The application runs in a Production Account (Account ID: 444455556666444455556666) and needs to write transaction logs to an Amazon S3 bucket located in a centralized Logging Account (Account ID: 111122223333111122223333). The logs must be encrypted at rest using AWS KMS. The security team requires that key management remains centralized in the Logging Account and that access follows the principle of least privilege. Which of the following configurations are required to support this cross-account writing and encryption pattern? (Select TWO.)

  1. In the Logging Account, configure the S3 bucket policy to grant s3:PutObject permissions to the IAM role of the application in the Production Account.Answer
  2. In the Logging Account, create a customer managed KMS key and configure its key policy to grant the application's IAM role in the Production Account permissions for kms:GenerateDataKey and kms:Decrypt.Answer
  3. C
    In the Logging Account, configure the S3 bucket to use the default AWS managed key (aws/s3) for encryption, and update its key policy to allow the Production Account's IAM role to perform cryptographic operations.
  4. D
    Attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing the Production Account to grant s3:PutObject and kms:GenerateDataKey permissions directly to the application.
  5. E
    Configure the S3 bucket policy in the Logging Account to trust a federated SAML identity provider (IdP) using sts:AssumeRoleWithSAML to enable the Production Account's application to upload logs directly without an IAM role.

Answer

In the Logging Account, configure the S3 bucket policy to grant s3:PutObject permissions to the IAM role of the application in the Production Account, and in the Logging Account, create a customer managed KMS key and configure its key policy to grant the application's IAM role in the Production Account permissions for kms:GenerateDataKey and kms:Decrypt.
The correct solution involves two main components for secure cross-account logging: first, modifying the destination S3 bucket policy to allow the source account's IAM role to upload objects via the s3:PutObject permission. Second, establishing a customer managed KMS key in the logging account and updating its key policy to trust the source account's application IAM role with the kms:GenerateDataKey and kms:Decrypt permissions, which are required to write encrypted objects to S3.

Step-by-Step Solution

1
Analyze cross-account bucket access requirements.
Cross-account access to Amazon S3 requires both an IAM policy on the sender side allowing s3:PutObject and a bucket policy in the receiving account allowing the same action for the sender's identity.
By default, cross-account access is denied unless explicitly authorized on both the identity side (IAM) and the resource side (bucket policy).
2
Analyze KMS key requirements for cross-account encryption.
AWS managed keys (aws/s3) cannot be shared across accounts because their key policies cannot be modified. A customer managed key must be used instead, and its key policy must explicitly list the Production Account's IAM role as a principal allowed to perform kms:GenerateDataKey and kms:Decrypt.
Security controls require centralized key management, which is achieved by hosting the customer managed KMS key in the Logging Account and delegating access via its key policy.

Key Concept

Cross-account S3 access combined with cross-account KMS key encryption requires a customer managed key with explicit key policy delegation and an S3 bucket policy that authorizes the cross-account role principal.
Rate this question