Question

Difficulty: EasySecurity and Compliance Control Design

A company is designing a new integration between two workloads deployed in separate AWS accounts. An application running on Amazon EC2 instances in Account A (111111111111) needs to retrieve and process encrypted messages from an Amazon Simple Queue Service (Amazon SQS) queue located in Account B (222222222222). The security requirements state that the SQS queue must be encrypted at rest, and access must follow the principle of least privilege. The application's IAM role in Account A has already been configured with the necessary SQS and KMS permissions.

Which two configuration steps must be performed in Account B to allow the cross-account application to successfully receive and decrypt messages from the queue? (Select TWO.)

  1. Enable server-side encryption on the SQS queue using a Customer Managed Key (CMK), and configure the CMK's key policy to allow the application's IAM role in Account A to perform the kms:Decrypt action.Answer
  2. Configure the SQS queue policy to allow the application's IAM role in Account A to perform the sqs:ReceiveMessage and sqs:DeleteMessage actions.Answer
  3. C
    Enable server-side encryption on the SQS queue using the default AWS-managed KMS key for Amazon SQS (aws/sqs), and update the key policy of aws/sqs to allow the application's IAM role in Account A to perform the kms:Decrypt action.
  4. D
    Create a Service Control Policy (SCP) at the root of the AWS Organization that grants the application's IAM role in Account A permissions to perform sqs:ReceiveMessage and kms:Decrypt on resources in Account B.
  5. E
    Configure the application in Account A to assume a cross-account role in Account B, using a SAML 2.0 federated trust relationship on the role in Account B that specifies the sts:AssumeRole action in its trust policy instead of sts:AssumeRoleWithSAML.

Answer

To configure secure cross-account access to the encrypted SQS queue, you must use a Customer Managed Key (CMK) and grant kms:Decrypt permissions to the application role in the key policy. You must also configure the SQS queue policy to grant sqs:ReceiveMessage and sqs:DeleteMessage permissions to the application role.
To allow cross-account access to an encrypted SQS queue, both the SQS queue policy and the KMS key policy in Account B must be updated to grant permissions to the IAM role in Account A. Additionally, because AWS-managed keys (like aws/sqs) cannot have their policies modified and cannot be shared across accounts, a Customer Managed Key must be used for SQS encryption. Therefore, the solutions architect must configure SQS with a Customer Managed Key and update its key policy to allow decryption, and also update the SQS queue policy to grant receive and delete permissions to the external IAM role.

Step-by-Step Solution

1
Ensure the SQS queue is encrypted with a Customer Managed Key (CMK) rather than an AWS-managed key.
Allows key policy modifications needed for cross-account sharing.
AWS-managed KMS keys do not support policy modifications and cannot be used across accounts.
2
Modify the key policy of the Customer Managed Key (CMK) in Account B.
Grants the application's IAM role in Account A kms:Decrypt permissions.
The calling application must be able to decrypt the payload encrypted by the key.
3
Modify the SQS queue policy in Account B.
Grants the application's IAM role in Account A sqs:ReceiveMessage and sqs:DeleteMessage permissions.
Resource-based SQS queue policies must authorize the cross-account principal to access the queue.

Key Concept

Cross-account access to AWS KMS-encrypted Amazon SQS queues requires updating both SQS resource policies and Customer Managed Key (CMK) policies, as AWS-managed keys cannot be shared across accounts.
Rate this question