acquires Cloud Conformity
Open menu

SQS Cross Account Access

Cloud Conformity allows you to automate the auditing process of this resolution page. Register for a 14 day evaluation and check your compliance level for free!

Start a Free Trial Product features
Knowledge Base Best practice rules for Amazon Web Services AWS SQS Best Practices SQS Cross Account Access
Security
Risk level: High (not acceptable risk)
Rule ID: SQS-002

Ensure that all your AWS SQS queues are configured to allow access only to trusted AWS accounts in order to protect against unauthorized cross account entities. Prior to running this rule by the Cloud Conformity engine, you need to provide the ID of each trusted AWS account (e.g. 575392584085) that can access your queues by using the rule settings available on the Cloud Conformity Console.

This rule can help you with the following compliance standards:

This rule can help you work with the AWS Well-Architected Framework

This rule resolution is part of the Cloud Conformity Security & Compliance tool for AWS

Allowing untrustworthy cross account access to your SQS queues can lead to unauthorized actions such as intercepting, deleting or sending queue messages without permission. To prevent data leaks, data loss and avoid unexpected costs on your AWS bill, limit access only to the trusted entities by implementing the necessary SQS policies.

Audit

To determine if there are any AWS SQS queues that allow unknown cross account access, perform the following:

Using AWS Console

01 Sign in to the AWS Management Console.

02 Navigate to SQS dashboard at https://console.aws.amazon.com/sqs/.

03 Select the SQS queue that you want to examine.

04 Select the Permissions tab from the bottom panel.

05 In the Principals column of each policy statement, identify the AWS account ID e.g.

identify the AWS account ID

available within each principal Amazon Resource Name (ARN).

06 Sign in to your Cloud Conformity Console, access the SQS Cross Account Access conformity rule settings and compare the AWS account ID(s) found at the previous step against each ID listed within the rule configuration section. If the identity (account) ID selected does not match any of the trusted entities IDs listed on your Cloud Conformity Console, the cross account access to the AWS SQS queue is not secured.

07 Repeat steps no. 3 – 6 for each SQS queue available in the current AWS region.

08 Change the AWS region from the navigation bar to repeat the process for other regions.

Using AWS CLI

01 Run list-queues command (OSX/Linux/UNIX) to list the URLs of all SQS queues available in the selected AWS region: 

aws sqs list-queues
	--region us-east-1

02 The command output should return the SQS queues metadata (URL(s)): 

{
    "QueueUrls": [
        "https://queue.amazonaws.com/123456789012/MyWebAppQueue"
    ]
}

03 Run get-queue-attributes command (OSX/Linux/UNIX) using the queue URL returned at the previous step as identifier to return the selected AWS SQS queue access policy: 

aws sqs get-queue-attributes
	--region us-east-1
	--queue-url https://queue.amazonaws.com/123456789012/MyWebAppQueue
	--attribute-names Policy

04 The command output should return the selected queue policy document (readable format): 

{
  "Version": "2012-10-17",
  "Id": "arn:aws:sqs:us-east-1:123456789012:MyWebAppQueue/DefaultPolicy",
  "Statement": [
    {
      "Sid": "Sid1473405897122",
      "Effect": "Allow",
      "Principal": {
        "AWS": ["arn:aws:iam::637846703055:root"]
      },
      "Action": [
        "SQS:SendMessage",
        "SQS:ReceiveMessage",
        "SQS:DeleteMessage",
        "SQS:PurgeQueue"
      ],
      "Resource": "arn:aws:sqs:us-east-1:123456789012:MyWebAppQueue"
    }
  ]
}

05 Identify the Principal policy object returned at the previous step and verify the AWS account ID (e.g. 637846703055) available within the principal ARN returned as the object value.

06 Sign in to your Cloud Conformity Console, access the SQS Cross Account Access conformity rule settings and compare the AWS account ID found at the previous step against each ID listed within the rule configuration section. If the identity ID returned does not match any of the trusted entities IDs listed on your Cloud Conformity Console, the cross account access to the selected AWS SQS queue is not secured.

07 Repeat steps no. 3 – 6 for each SQS queue available in the current AWS region.

08 Change the AWS region by updating the --region command parameter value and repeat steps no. 1 - 7 to perform the audit process for other regions.

Remediation / Resolution

To update your AWS SQS queues permissions in order to allow cross account access only from trusted entities, perform the following:

Using AWS Console

01 Sign in to the AWS Management Console.

02 Navigate to SQS dashboard at https://console.aws.amazon.com/sqs/.

03 Select the SQS queue that you want to update.

04 Select the Permissions tab from the bottom panel.

05 Identify each insecure policy statement (see Audit section part I) and click the pencil icon:

Identify each insecure policy statement (see Audit section part I) and click the pencil icon

to edit the selected policy statement. You can also open and edit directly the entire policy document by using the Edit Policy Document (Advanced) button.

06 Inside the Add a Permission to <queue name> dialog box, select Deny to explicitly deny the access to the specified principal, which represents the untrustworthy AWS account. If you choose to edit the queue policy document directly, just change the Effect property value to Deny for the unsafe principal(s) available then click Review Policy.

07 Click Save Changes to update the selected policy statement.

08 Repeat step no. 3 – 7 for each SQS queue that you want to update, available in the current AWS region.

09 Change the AWS region from the navigation bar to repeat the entire process for other regions.

Using AWS CLI

01 Run get-queue-attributes command (OSX/Linux/UNIX) using the URL of the SQS queue that you want to secure as identifier to return its access policy: 

aws sqs get-queue-attributes
	--region us-east-1
	--queue-url https://queue.amazonaws.com/123456789012/MyWebAppQueue
	--attribute-names Policy

02 The command output should return the selected queue policy document (raw format): 

{
    "Attributes": {
        "Policy": "{\"Version\":\"2012-10-17\",\"Id\":\"arn:aws:sqs:us-east-1:123456789012:MyWebAppQueue/SQSDefaultPolicy\",\"Statement\":[{\"Sid\":\"Sid1473405897122\",\"Effect\":\"Allow\",\"Principal\":{\"AWS\":\"arn:aws:iam::637846703055:root\"},\"Action\":[\"SQS:SendMessage\",\"SQS:ReceiveMessage\",\"SQS:PurgeQueue\",\"SQS:DeleteMessage\"],\"Resource\":\"arn:aws:sqs:us-east-1:123456789012:MyWebAppQueue\"}]}"
    }
}

03 To update the policy document returned at the previous step change the Effect property value to Deny for the unsafe principal(s) available (as shown in the example below) and remove the Attributes property. Once the policy document is ready save it in a JSON file named sqs-queue-new-policy.json: 

{
"Policy": "{\"Version\":\"2012-10-17\",\"Id\":\"arn:aws:sqs:us-east-1:123456789012:MyWebAppQueue/SQSDefaultPolicy\",\"Statement\":[{\"Sid\":\"Sid1473405897122\",\"Effect\":\"Deny\",\"Principal\":{\"AWS\":\"arn:aws:iam::637846703055:root\"},\"Action\":[\"SQS:SendMessage\",\"SQS:ReceiveMessage\",\"SQS:PurgeQueue\",\"SQS:DeleteMessage\"],\"Resource\":\"arn:aws:sqs:us-east-1:123456789012:MyWebAppQueue\"}]}"
}

04 Run set-queue-attributes command (OSX/Linux/UNIX) using the URL of the SQS queue as identifier and the policy document defined at the previous step to update the selected queue access policy (the command does not return an output): 

aws sqs set-queue-attributes
	--region us-east-1
	--queue-url https://queue.amazonaws.com/123456789012/MyWebAppQueue
	--attributes file://sqs-queue-new-policy.json

05 Repeat steps no. 1 – 4 for each SQS queue that you want to update, available in the current AWS region.

06 Change the AWS region by updating the --region command parameter value to repeat the process for other regions.

References

Publication date Sep 10, 2016

Related SQS rules

Thanks!

A verification email has been sent to

Thanks!

A verification email has been sent to

Thanks!

A verification email has been sent to