AWS SQS
Best practices and references below are based on published guidance from the cloud service provider and may reference native capabilities the cloud service provider offers. If you are not using the native security capabilities, the same security requirement can be met using other security capabilities your organization utilizes
AWS Security Best Practices
There are a number of security considerations when attempting to secure your SQS instances. See below for some key considerations. Refer to oak9's security blueprint for S3 for more details.
Make sure that queues aren't publicly accessible
Unless you explicitly require anyone on the internet to be able to read or write to your Amazon SQS queue, you should make sure that your queue isn't publicly accessible (accessible by everyone in the world or by any authenticated AWS user).
- Avoid creating policies with
Principalset to"". - Avoid using a wildcard (
*). Instead, name a specific user or users.
Implement least-privilege access
When you grant permissions, you decide who receives them, which queues the permissions are for, and specific API actions that you want to allow for these queues. Implementing least privilege is important to reducing security risks and reducing the effect of errors or malicious intent.
Follow the standard security advice of granting least privilege. That is, grant only the permissions required to perform a specific task. You can implement this using a combination of security policies.
Amazon SQS uses the producer-consumer model, requiring three types of user account access:
- Administrators – Access to creating, modifying, and deleting queues. Administrators also control queue policies.
- Producers – Access to sending messages to queues.
- Consumers – Access to receiving and deleting messages from queues.
Use IAM roles for applications and AWS services which require Amazon SQS access
For applications or AWS services such as Amazon EC2 to access Amazon SQS queues, they must use valid AWS credentials in their AWS API requests. Because these credentials aren't rotated automatically, you shouldn't store AWS credentials directly in the application or EC2 instance.
You should use an IAM role to manage temporary credentials for applications or services that need to access Amazon SQS. When you use a role, you don't have to distribute long-term credentials (such as a user name, password, and access keys) to an EC2 instance or AWS service such as AWS Lambda. Instead, the role supplies temporary permissions that applications can use when they make calls to other AWS resources.
Implement server-side encryption
To mitigate data leakage issues, use encryption at rest to encrypt your messages using a key stored in a different location from the location that stores your messages. Server-side encryption (SSE) provides data encryption at rest. Amazon SQS encrypts your data at the message level when it stores it, and decrypts the messages for you when you access them. SSE uses keys managed in AWS Key Management Service. As long as you authenticate your request and have access permissions, there is no difference between accessing encrypted and unencrypted queues
Enforce encryption of data in transit
Without HTTPS (TLS), a network-based attacker can eavesdrop on network traffic or manipulate it, using an attack such as man-in-the-middle. Allow only encrypted connections over HTTPS (TLS) using the
aws:SecureTransport condition in the queue policy to force requests to use SSL.Consider using VPC endpoints to access Amazon SQS
If you have queues that you must be able to interact with but which must absolutely not be exposed to the internet, use VPC endpoints to queue access to only the hosts within a particular VPC. You can use queue policies to control access to queues from specific Amazon VPC endpoints or from specific VPCs.
Amazon SQS VPC endpoints provide two ways to control access to your messages:
- You can control the requests, users, or groups that are allowed through a specific VPC endpoint.
- You can control which VPCs or VPC endpoints have access to your queue using a queue policy.
Design Guidance:
Kms Data Key Reuse Period Seconds | ||
Kms Master Key Id |
Design Guidance:
Maximum Message Size |
Message Retention Period |
Design Guidance:
Queue Name | ||
Tags |
Design Guidance:
Policy Document | ||
Policy Document-Statement | ||
Statement-Effect | ||
Statement-Action | ||
Statement-Principal | ||
Statement-Resource | ||
Statement-Condition | ||
Queues |
Last modified 6mo ago