SQS encryption options

Table of Contents

When building distributed applications on AWS, Amazon Simple Queue Service (SQS) often becomes a crucial component in managing message flow between services. Ensuring the security of these messages is important, especially when dealing with sensitive data across multiple AWS accounts. In this post, we’ll explore different encryption options available for SQS and choosing the best option for scenarios like cross-account access.

In-Transit (as it travels to and from Amazon SQS) Encryption
#

You can protect data in-transit using HTTPS (TLS). This ensures that messages are protected as they travel between your application and SQS, preventing attacks such as man-in-the-middle. You can enforce only encrypted connections over HTTPS (TLS) using aws:SecureTransport condition in the queue policy.

"Condition": {
   "Bool": {
       "aws:SecureTransport": "true"
   }
}

Another option for in-transit encryption is using client-side encryption where you encrypt data before sending it to SQS. Here you have to manage the encryption-decryption mechanism yourself.

Server-Side Encryption
#

Server-side encryption (SSE) adds an extra layer of security by encrypting the contents of your queue at the storage level. SSE protects the contents of messages in queues using SQS-managed encryption keys (SSE-SQS) or keys managed in the AWS Key Management Service (SSE-KMS).

SSE-SQS (SQS Managed Keys)
#

This is the simplest option, where Amazon SQS takes care of the encryption keys for you. SQS generates, manages, and uses the encryption key, requiring no additional configuration on your part. Since October 2022, this is by default enabled for any new SQS queue.

SSE-KMS (AWS Key Management Service Keys)
#

This option provides more control by allowing you to use AWS Key Management Service (KMS) to manage the encryption keys. With SSE-KMS, you can use an existing KMS key or create a new one specifically for your SQS queue. This method enables finer-grained access control and auditing capabilities compared to SSE-SQS.

Cross-account access with SSE
#

As one of the most used messaging services between software components, cross account access is a very common scenario for SQS. Still, we need to make sure the messages that are exchanged between SQS queues are secured.

In general, you can manage the cross account access for a SQS using its access policy.

Below is an IAM policy of my_sqs_queue in account 111111111111. This has granted the account 222222222222 to send messages to my_sqs_queue.

{
      "Sid": "cross_account_access",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::222222222222:root"
      },
      "Action": [
        "sqs:GetQueueAttributes",
        "sqs:GetQueueUrl",
        "sqs:SendMessage"
      ],
      "Resource": "arn:aws:sqs:eu-west-1:111111111111:my_sqs_queue",
      }
    }

Depending on the server side encryption used in the queue, there will be additional permission required to grant send messages to my_sqs_queue.

If SSE-SQS is used
#

Good news is if SSE-SQS is used, there are no additional encryption related permissions required by account 222222222222. Which means above IAM permission is sufficient to send messages to my_sqs_queue.

If SSE-KMS is used
#

If this encryption is used, additional permission for the KMS key must be set in order to successfully send messages to my_sqs_queue.

Let’s assume my_sqs_queue is encrypted using a KMS key in the same account 111111111111 which has the alias my_kms_key. In the my_kms_key, you have to grant permission for account 222222222222 as follows:

{
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::222222222222:root"
    },
    "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
    ],
    "Resource": "arn:aws:kms:eu-west-1:111111111111:key/[key-id]"
}

Further, in the account 222222222222, there should be permission kms:GenerateDataKey for the KMS key as follows:

{
    "Effect": "Allow",
    "Action": "kms:GenerateDataKey",
    "Resource": "arn:aws:kms:eu-west-1:111111111111:key/[key-id]"
}

Conclusion: What SSE method to choose?
#

Both SSE-SQS and SSE-KMS support cross-account access for SQS queues. The key difference lies in how much control and responsibility you want over the encryption process.

SSE-SQS is ideal when you need simple, effective encryption without the additional complexity of managing KMS keys. It’s ideal for most general use cases where ease of setup and management is a priority.

Use SSE-KMS when you require more control over your encryption keys and need to meet strict security and compliance requirements. This option is suited for environments where key management and detailed access control are critical.