AWS recently introduced SSE (Server-Side Encryption) for AWS SQS (Simple Queue Service). I was in the office when I heard this and thought to myself, “well, that seems exciting. I want to know more.” So, I went to Mike and asked if he knew what all the fuss was about. This post is around that discussion and reasons why we should all be excited about Server-Side Encryption too!

Paul: So, what do we use AWS SQS for? Can you give me an example?

Mike: Sure! One of the best examples for using SQS are booking systems. For instance, a web application like AirBnB or Hotels.com, they first get a customer’s information and booking requirements and then search for any available rentals or hotel rooms. As all know, they then present the user with the results. Now, to handle this, the system can either get one request at a time and process it (which may take a while) or just place the requests in a queue so they get processed asynchronously which is where SQS comes in handy. Using AWS SQS, a Lambda function can put the customer rental request in the queue and a bunch of services (i.e. Lambda functions) can process those rental requests in the FIFO (First In, First Out) order. The services keep pulling the queue until they find a new item in there. Does that make sense so far?

Paul: Absolutely, though can I put an object in the queue?

Mike: By default, AWS SQS is for 256 KB text-based messages in any format. You can put JSON serialised objects and even binary messages in there. Although personally, I’d rather put an object ID instead of the whole object (state data) in the queue, so that my consumer Lambda can retrieve the object on its own.

Paul: Ok but why do we need encryption then? Is it necessary to encrypt that data if it’s just on its own?

Mike: Well, what if your queue gets compromised?

Paul: What do you mean? How can that happen?

Mike: What if you need to give access to a foreign AWS account to read from that queue? Or what if the developer who created the queue just didn’t configure it properly, so it becomes publicly accessible?

Paul: Um…Well, if you are only putting random object ID’s in the queue, how can that be useful to anyone anyway?

Mike: Understood but it’s not always so simple unfortunately! Using the booking systems example, user information might be included in the message. Another thing to consider is, if one of the Lambda functions exposes sensitive information on the queue. You wouldn’t want to risk that, would you?

When you use a queue with SSE, you only tell SQS that you want it to safely store and retrieve this data for you. In order to encrypt or decrypt the data, you need a service called AWS Key Management Service (KMS). From here, SQS uses KMS and takes care of encryption/decryption on your behalf. You wouldn’t even notice!

According to AWS Knowledge base, SSE encrypts messages as soon as AWS SQS receives them. The messages are stored in encrypted form and SQS decrypts messages only when they are sent to an authorized consumer.

This is pretty exciting! It means that even when an outsider with no access to KMS is able to see a compromised queue, they still can’t still any data from the queue, even the encrypted data. The reason being that SQS fails in retrieving data without properly decrypting it first. It really provides that extra layer of security around that queue.

Paul: Got it! How can I enable it on my AWS account?

Mike: Well, you can follow these steps:

  1. Open your AWS Management Console
  2. Go to your SQS dashboard and select a SQS queue
  3. Choose the Encryption tab from the bottom panel and verify the Server-Side Encryption (SSE) configuration for that queue

Remember though, this will only enable it for the selected region. If you need for the other region, you need to follow the same steps after selecting the new region.

Paul: Can we use it in every region?

Mike: Not yet, t’s been only introduced in the US West (Oregon) and US East (Ohio) regions for now but soon the rest will follow.

Paul: Is it added as a security rule to Cloud Conformity engine and do we have it in Cloud Conformity Knowledge Base along with the rest of security rules?

Mike: Not yet but it’s coming very soon.

Paul: Nice! Let’s go have lunch now, I’m starving!

Mike: Alrighty.

Cloud Conformity is a continuous assurance tool running over 500 checks against your AWS environments, assessing compliance to the Well-Architected Framework and other industry compliance standards. Check your security posture today with a 14-day free trial, giving full access to the platform including the API, Auto-Remediation and Real-Time Monitoring.