Security Considerations for SQS – AWS Security Fundamentals – SCS-C02 Study Guide

Security Considerations for SQS

Having gone over the functions of the SQS service along with how it differs from the SNS service, you can now examine some of the security best practices for SQS:

• Apply the principle of least privilege when granting access to SQS queues:

Create a specific role for the administration of the queues that do not have access to consume or publish messages. This administrative role would only be able to create, delete, and modify queues. In the same context, create a role that’s only to be used by consumers who can read and write to the queues but have no administrative privileges. You can break this role down further into producer and consumer roles.

• Implement server-side encryption:

SQS can store its data at rest encrypted using keys from the KMS service.

• Use VPC endpoints to access Amazon SQS:

Routing your requests from hosts in your VPC through VPC endpoints rather than the public internet limits topic access to only the hosts within a particular VPC.

• Tighten access policies so that SQS queues are not publicly available:

Name specific resources for the principal instead of using the wildcard * in access policies.

Where Would You Use SNS or SQS?

When deciding which messaging service to use, there is a rule you can use to help determine which one will serve you best. Ask yourself the following set of questions:

• Are my messages going to be consumed only by my application?

If the answer is yes, then SQS is going to be the best choice.

• Are my messages going to be consumed by multiple sources?

If the answer is yes, then SNS is going to be the best choice.

Using these two questions, you can determine whether you are dealing with a closed loop of gathering the messages and then processing them for use in the application (SQS) or you are creating the message to be consumed outside the application (SNS).

Simple Email Service (SES)

SES allows you to set up and send emails without most of the complexities of running an SMTP server.

Although emails can originate anywhere globally, SES only receives emails from three regional endpoints: us-east-1 (N. Virginia), us-west-2 (Oregon), and eu-west-1 (Ireland). The service has (at the time of writing) over 18 regions for sending emails via the SMTP protocol.

Amazon helps you and others verify where your sent mail is coming from and provides trust in the emails you send your customers by adding a series of DKIM records to the email headers, which can be verified by the recipient’s mail server.

Security Considerations for SES

• Use SES in conjunction with VPC endpoints. This will keep any emails (especially those going from services residing in AWS to your internal users) from traversing the public internet.
• Ensure that CloudTrail has been turned on in the region where your SES has been set up. This makes sure that any API activity is captured.
• Use IAM policies to restrict where the SES service can take requests from when sending emails. This helps to prevent a rogue spambot from using your SES service and sending emails with faux addresses. Refer to the following example policy:

{

“Version”:”2012-10-17″,

“Statement”:[

{

“Effect”:”Allow”,

“Action”:[

“ses:SendEmail”,

“ses:SendRawEmail”

],

“Resource”:”*”,

“Condition”:{

“StringEquals”:{

“ses:FromAddress”:”sales@test.com”

}

}

}

]

}

As you have now reviewed different types of messaging systems and delivery available in AWS, you can dive into the next section that discusses a very important access gateway, the API Gateway.