AWS have released a new Beta feature for SNS called “AWS SNS Message Data Protection”. Given that I am one of those rare people who get excited about security topics, I thought I would give you an overview of what this service is all about, and how it might be used.
Note: This service is a Public Preview
Benefits of Data Protection
When designing – and deploying – infrastructure, I work under the mantra that unless there is a reason not to use a security feature, it should be used. In doing so, we make sure that all infrastructure we deploy (either in Development or Production) uses the same standards, avoiding issues when publishing infrastructure in higher environments.
Further, many of our clients are under strict requirements to ensure data is protected. Whether these are PCI DSS, NCSC, or a client’s INFOSEC requirements, etc., making every effort to protect your infrastructure and the data it supports avoids building technical debt for the future.
What can SNS Message Data Protection be Used for?
There are 2 main use cases for this feature:
- Preventing a message being published to a topic that contains sensitive information – this can guard against someone sending message to an SNS topic inadvertently (or deliberately) that is sensitive. Another example could be where a log message is sent to an SNS topic. If that log message contains sensitive information, then we may wish to prevent it being sent [Inbound];
- Selectively logging messages based on the content of those messages – this is useful where you want to send an Event to CloudWatch when a message is received containing certain information. From there, remedial action can be taken, or the fact can be logged [Outbound / Inbound];
- Preventing messages being sent downstream (if someone has, for example, subverted a process and injects sensitive information to a message for exfiltration) [Outbound]
It should the noted that
What types of Data Protection Selectors can be used?
Amazon provide a full list of services here: Understanding data protection policies – Amazon Simple Notification Service
Typical identifies such as Name, National Insurance Number, AWS Keys, PGP Private Keys, etc., can all be intercepted.
You may be familiar with the AWS Macie service which takes a similar approach to identifying sensitive information in AWS S3 Buckets.
How can I use it?
The service is currently in Public Preview. This means that the service is subject to change. However, anyone can use the service where they can currently use SNS.
Demo
I have created a Pulumi script that will:
- Create an SNS Topic with KMS Encryption enabled by default;
- Create a Message Data Protection Policy and attach it to the SNS Topic.
Creating this script was a real <selectively insert rude word> pain. Because I always use IaC approaches for deploying infrastructure, I naturally selected an IaC framework. Using the AWS CLI was an option, however, this is not a very flexible or extensible approach. Further, although this feature is in Public preview it will take time for Pulumi, Hashicorp, etc. to add the feature to their own code-bases.
Until the IaC frameworks provide first-class support, I needed to create the infrastructure using Pulumi, and perform the final task – adding an SNS Message Data Protection Policy to the topic – using the AWS CLI. Naturally, I didn’t want the instructions to say “run pulumi”, then “run this CLI command”, so I wanted to create a demo that did everything using the same framework. This was the first time that I had had to take this approach with Pulumi. I have explained the challenges inline in the code. So that part of the script may be ugly – but it works 🙂
Running the Script
Follow the README.md in the project for instructions on deploying the infrastructure. You will need to have:
- The latest version of the AWS CLI installed;
- Node and Pulumi installed (also recommend latest versions of each).
Once you have completed the prerequisites you should update your variables. Here are the variables that I have used for this demo:
let response = await sns.createTopic(
name: "sns-dataprotection-test",
main: {}, // The main object can be used to update default configuration for the SNS Topic
dataProtection: true,
dataProtectionIdentifiers: ["Name", "CreditCardNumber"]
});{This will ensure that Names and Credit Card numbers cannot be sent to SNS.
Note that this is Demo code. The next step for anyone interested would be to extend this code to support Deny Policies, Logging Policies, etc. That, however, seemed overkill for a demo!
Script Results
The following shows a Successful result:
Console View
When you look at the SNS topic in the console, you will now be able to see the Data Protection Policy as shown below:
Test – Failure Expected
In the Console, choose “Publish Message” under the newly created SNS Topic – I will opt to use my name rather than my Credit Card Number for this test! This is the message content:
Stephen McMaster
And here is the result:
The message cannot be published.
Test – Success Expected
This is the message content:
This is a test
And here is the result:
This concludes the demo
Suggested follow-up
- Consider where such a feature may be used where you are currently using SNS Messages;
- Test the accuracy of the Data Protection Policies (i.e. will all names truly be identified as names?)
Material
Source code can be found here: GitHub – mcmastercloud/Pulumi-SNS-DataProtection-Demo
Note: This article is an opinion and does not constitute professional advice – any actions taken by a reader based on this article are at the discretion of the reader, who is solely responsible for the outcome of those actions.
