Learn how to effectively protect sensitive data in Amazon Simple Notification Service (SNS) messages from accidental exposure using inbound message data protection policies and the De-identify operation. Discover the best solution to ensure your application components securely publish messages without risking sensitive data leaks in transaction and debug logs.
Table of Contents
Question
A company is investigating controls to protect sensitive data. The company uses Amazon Simple Notification Service (Amazon SNS) topics to publish messages from application components to custom logging services.
The company is concerned that an application component might publish sensitive data that will be accidentally exposed in transaction logs and debug logs.
Which solution will protect the sensitive data in these messages from accidental exposure?
A. Use Amazon Made to scan the SNS topics for sensitive data elements in the SNS messages. Create an AWS Lambda function that masks sensitive data inside the messages when Macie records a new finding.
B. Configure an inbound message data protection policy. In the policy, include the De-identify operation to mask the sensitive data inside the messages. Apply the policy to the SNS topics.
C. Configure the SNS topics with an AWS Key Management Service (AWS KMS) customer managed key to encrypt the data elements inside the messages. Grant permissions to all message publisher IAM roles to allow access to the key to encrypt data.
D. Create an Amazon GuardDuty finding for sensitive data that is transmitted to the SNS topics. Create an AWS Security Hub custom remediation action to block messages that contain sensitive data from being delivered to subscribers of the SNS topics.
Answer
B. Configure an inbound message data protection policy. In the policy, include the De-identify operation to mask the sensitive data inside the messages. Apply the policy to the SNS topics.
Explanation
The best solution to protect sensitive data in Amazon SNS messages from accidental exposure is to configure an inbound message data protection policy and include the De-identify operation to mask the sensitive data inside the messages (Option B).
Here’s a detailed explanation of why this solution is the most appropriate:
- Inbound message data protection policies: These policies allow you to define custom rules to protect the data in your SNS messages. By creating a policy, you can specify the actions to be taken on the messages before they are delivered to subscribers or stored in logs.
- De-identify operation: The De-identify operation is a built-in feature of inbound message data protection policies. It allows you to mask sensitive data elements within the messages, replacing them with placeholder values or hashes. This ensures that the original sensitive data is not exposed in logs or to unauthorized subscribers.
- Applying the policy to SNS topics: Once you have created the inbound message data protection policy with the De-identify operation, you can apply it to the specific SNS topics that handle messages containing sensitive data. This ensures that all messages published to these topics are automatically processed by the policy, and sensitive data is masked before delivery or logging.
The other options have the following limitations:
- Option A: Using Amazon Macie to scan SNS topics and create a Lambda function to mask sensitive data is a reactive approach. It doesn’t prevent the initial exposure of sensitive data and requires additional resources and complexity to set up and maintain.
- Option C: Encrypting the data elements inside the messages using AWS KMS is a good security practice, but it doesn’t prevent the exposure of sensitive data if the messages are logged or delivered to unintended subscribers. Encryption protects data at rest, but not during processing or transmission. Additionally, granting permissions to all publisher IAM roles may not be granular enough and could lead to over-privileged access.
- Option D: Creating an Amazon GuardDuty finding and using AWS Security Hub to block messages containing sensitive data is a detective and reactive approach. It doesn’t prevent the initial exposure of sensitive data and may result in legitimate messages being blocked, impacting the application’s functionality.
In summary, configuring an inbound message data protection policy with the De-identify operation (Option B) is the most effective and proactive solution to protect sensitive data in Amazon SNS messages from accidental exposure.
Amazon AWS Certified Security – Specialty SCS-C02 certification exam practice question and answer (Q&A) dump with detail explanation and reference available free, helpful to pass the Amazon AWS Certified Security – Specialty SCS-C02 exam and earn Amazon AWS Certified Security – Specialty SCS-C02 certification.