Applying best practices for securing sensitive data in Amazon DynamoDB

October 2023: This post was reviewed and updated to include the integration of Amazon DynamoDB Dataplane operations in AWS CloudTrail.

The first post of the series, Best practices for securing sensitive data in AWS data stores, described some generic security concepts and corresponding AWS security controls that you can apply to AWS data stores. Using these, you can create a stronger security posture around your data. The second post, Applying best practices for securing sensitive data in Amazon RDS, demonstrated how to implement these concepts to Amazon RDS databases. This third and final post demonstrates how you can implement these concepts in Amazon DynamoDB.

Data classification and security-zone modeling

It’s important to understand what data you are processing and any specific requirements for handling, which may be regulatory or generated internally as part of your organization. For example, you might not need some of the specialized security controls, such as tokenization of data, as described later in this post. You should always try to raise the bar with security, but also make sure you are delivering appropriate controls to manage well-understood risks.

After you design your security zones, implement them using network access control lists (ACLs), as described later in this post. This step defines coarse-grained network zones and allows more specific micro-segmentation within these zones using security groups.

When implementing security-zone modeling, carefully consider your networking design. The size of your CIDR ranges determines the number of IP addresses each of your subnets can sustain. Design your CIDR ranges to support growth within a subnet (more IP addresses) and in the number of subnets. Balance this out with any requirements to have nonconflicting IP address space between your Amazon VPC and on-premises data center or between VPCs. For more information, see AWS Single VPC Design.

For a more in-depth description than provided here and for the concepts behind data classification and security-zone modeling, see Best practices for securing sensitive data in AWS data stores.

Preventative controls

The following diagram is from the first post in this series, which describes in detail the concept of defense in depth. There are two main categories of controls: preventative controls and detective controls. Let’s discuss preventative controls first.

DDoS protection

You can help protect your application and database from distributed denial of service (DDoS) attacks by working with AWS Shield. All AWS customers benefit from the automatic protections of AWS Shield Standard, at no additional charge. AWS Shield Standard defends against most common, frequently occurring network and transport layers that target your website or applications. When you use AWS Shield Standard with Amazon CloudFront and Amazon Route 53, you receive comprehensive availability protection against all known infrastructure (layer 3 and 4) attacks.

You can subscribe to AWS Shield Advanced, which provides access to the DDoS response team and additional metrics. For more information about the additional protections available, see AWS Shield Features.

To enable AWS Shield Advanced, complete the following steps:

On the AWS Management Console, choose AWS WAF and AWS Shield.

If you have not yet enabled AWS WAF or AWS Shield Advanced, the following page appears, as opposed to the dashboard page.

Choose AWS Shield.
The page shows a comparison between Standard and Advanced.

Choose Activate AWS Shield Advanced.

On the Activate service section, select all the check boxes agreeing to the terms.
.
Choose Activate service.

Application-level threat prevention

To help with application-level threat prevention, you can use AWS WAF.

Your web application needs to access data stored in your database. Thus, it’s important to protect the data against leakage by using attacks described in the Open Web Application Security Project (OWASP) Top Ten Project. Configure AWS WAF to protect your application against these threats. AWS WAF operates at a global level with Amazon CloudFront and also at the regional level with regional resources, such as ALB and API Gateway.

To get started protecting against the OWASP top 10 with AWS WAF, create a web ACL using AWS CloudFormation and the owasp_10_base.yml template.

Network isolation

A key security consideration for your sensitive data in DynamoDB is the network isolation of traffic to and from your DynamoDB tables. The fundamental design component that enables this security isolation is Amazon VPC.

To create a VPC, complete the following steps:

Open the VPC console.
Choose Your VPCs.
Choose Create VPC.
For Name tag, choose a name for your VPC.
For IPv4 CIDR block, specify a CIDR range.
Leave IPv6 CIDR block with the default value “No IPv6 CIDR Block”.
Leave Tenancy with the value “Default”.
The following screenshot shows that this post enters the name demoVPC and the range 10.0.0.0/16.

Choose Create.

You must make sure that database traffic to and from your DynamoDB remains within the privacy of your VPC. DynamoDB is a regional service, which means that you make sure traffic to and from the database remains on your VPC private networking by creating a VPC Endpoint.

A VPC endpoint for DynamoDB enables Amazon EC2 instances in your VPC to use their private IP addresses to access DynamoDB with no exposure to the public internet. Your EC2 instances do not require public IP addresses, and you do not need an internet gateway, NAT device, or virtual private gateway in your VPC. You use endpoint policies to control access to DynamoDB. Traffic between your VPC and the AWS service does not leave the Amazon network. For more information, see Amazon VPC Endpoints for DynamoDB.

Security groups and network ACLs

Network ACLs and security groups do not apply to DynamoDB directly. However, you can achieve network separation using VPC endpoints and VPC endpoint policy.

You use network ACLs to implement security zone modeling. For more information, see Network ACLs. A security zone provides a well-defined network perimeter that contains assets with a similar trust level. A security zone also enables clarity and ease of reasoning for defining and enforcing network flow control into and out of the security zone based on its characteristics.

The following diagram represents one approach to security zone modeling.

Creating a DynamoDB VPC endpoint and applying an endpoint policy

To implement security zone modeling, create a DynamoDB VPC endpoint for each subnet. To separate data plane and control plane traffic, apply the appropriate policy to each VPC endpoint.

Create two DynamoDB VPC endpoints and attach one to the App Tier subnet and the other to the Control plane subnet with the following steps:

On the VPC console, choose Endpoints.
You must perform these steps two times to create a DynamoDB VPC endpoint for both subnets.

For Service category, choose AWS services.
For Service name, choose the Gateway interface type.

For VPC, enter the VPC to which you want to attach this VPC endpoint.
For Configure route tables, select the subnet associated with App Tier and Control Plane.
Selecting a route table creates a new privately addressable route to DynamoDB via the VPC endpoint. Make sure that your route table has the correct subnets associated with it.

For Policy, choose Custom.

Enter the relevant policy for either App Tier or Control Plane.
To make sure that only data plane traffic is allowed from the App Tier subnet, apply the following policy to the DynamoDB VPC endpoint:

VPC Endpoint Policy
{
    "Version": "2008-10-17",
    "Statement": [
        {
            "Sid": "DataPlane",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "dynamodb:GetItem",
                "dynamodb:PutItem",
                "dynamodb:Scan",
                "dynamodb:Query"
            ],
            "Resource": "arn:aws:dynamodb:[your_region]:[your_AWS_account_id]
:table/*/index/*"
        }
    ]
}

To make sure that control plane operations are only allowed from the Control Plane subnet, apply the following policy to the DynamoDB VPC endpoint:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ControlPlane",
            "Effect": "Allow",
            "Action": [
                "dynamodb:CreateTable",
                "dynamodb:CreateBackup",
                "dynamodb:DeleteTable",
                "dynamodb:UpdateTable"
            ],
            "Resource": "arn:aws:dynamodb: [your_region]:[your_AWS_account_id]:table/*"
        }
    ]
}

Navigate to the VPC console and choose Endpoints
Select each endpoint, click Edit Policy and attach the respective VPC endpoint policy.

Identity and Access Management

IAM is the fundamental control available to customers building on AWS. It is the first of the five best practices of the Security pillar of the AWS Well-Architected Framework. The framework enables you to learn architectural best practices for designing and operating reliable, secure, efficient, and cost-effective systems in the cloud.

To begin working with IAM and before defining individual user, group, and role access requirements, separate those access requirements by control plane operations and data plane operations.

Control plane operations

Control plane operations are management functions on DynamoDB such as CreateTable, DeleteTable, UpdateTable, and CreateBackup. Because these are higher-privileged operations, apply care and rigor when assigning the related privileges to users or roles.

The following example code grants a limited set of administrative actions on DynamoDB. You can attach this policy to a user, group, or role.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "LimitedAdmin",
            "Effect": "Allow",
            "Action": [
                "dynamodb:CreateTable",
                "dynamodb:CreateBackup",
                "dynamodb:DeleteTable",
                "dynamodb:UpdateTable"
            ],
            "Resource": "arn:aws:dynamodb: [your_region]:[your_AWS_account_id]:table/*"
        }
    ]
}

Data plane operations

Data plane operations typically refer to actions that Get, Put, and Delete data in a DynamoDB table. There are two parts to enabling the data plane operations on an Amazon DynamoDB: database authentication and database access control.

Database authentication refers to who is allowed to access the DynamoDB tables. You set up authentication with IAM. For human users, this can be authentication either via a federated identity (such as Microsoft Active Directory) using IAM roles, or by providing IAM credentials directly. For application access, attach IAM roles directly to the applications to enabled authenticated access.

Access control is what level of access a user or application has. You define access control for DynamoDB also using IAM. Start by creating an IAM Policy for application access with the principle of least privilege. Identify your read and write use cases and craft individual IAM policies for each.

The following example code grants data plane access to a specific DynamoDB table. Attach it to a specific IAM user or a role that relates to a particular application.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "App1Access",
            "Effect": "Allow",
            "Action": [
                "dynamodb:PutItem",
                "dynamodb:GetItem",
                "dynamodb:Scan",
                "dynamodb:Query",
                "dynamodb:UpdateItem"
            ],
            "Resource": "arn:aws:dynamodb:[your_region]:[your_AWS_account_id]:table/[App 1 table name]"
        }
    ]
}

To apply micro-segmentation within your DynamoDB environment, use a more restrictive user or role data plane IAM policy. For example, while the DynamoDB VPC endpoint IAM policy may allow Get, Put, and Delete operations from all principles to all tables, the specific user or role IAM policy only allows access to specific tables.

The following diagram demonstrates this micro-segmentation approach.

Encryption and tokenization

Encryption and tokenization are key to database security. Enabling encryption at rest ensures that you can only read the data stored within the DynamoDB database and DynamoDB table backups outside of the AWS account with AWS KMS encryption key permissions explicitly granted, in addition to DynamoDB table permissions.

Tokenization replaces sensitive data with unique identifiers that you use to find the original sensitive data in another data source. In contrast, encryption applies a cypher to sensitive data to encode the data for only authorized parties to read.

Server-side encryption

Data at rest is encrypted using a KMS key. You can choose between an AWS managed KMS key or an AWS owned KMS key. Use AWS managed KMS key because it enables you to audit their use in AWS CloudTrail logs.

To enable encryption at rest when creating a new DynamoDB table, complete the following steps:

For Table settings, deselect Use default settings.

For Encryption at Rest, choose KMS.
From the drop-down menu, choose your KMS key.
Choose Create.

Client-side encryption

Use the DynamoDB Encryption Client for client-side encryption, in which you encrypt your table data before you send it to DynamoDB. You may choose to do this based on your data’s sensitivity and your application’s security requirements. For more information, see Client-Side and Server-Side Encryption.

Use KMS to manage your client-side encryption key. Enable access to encrypted data to applications using KMS key grants. One benefit of using client-side encryption is that you can direct the DynamoDB Encryption Client to calculate a signature over all or part of a table item, including the primary key attributes and the table name. This signature allows you to detect unauthorized changes to the item as a whole, including adding or deleting attributes, or swapping attribute values.

Encryption in transit

Encryption in transit ensures that the data remains encrypted when its moving between your application and DynamoDB tables. DynamoDB endpoints are accessible over HTTPS endpoints regardless of whether you use the AWS Management Console, CLI, or AWS SDK for DynamoDB.

Tokenization

Tokenization is an alternative to encryption that can help to protect specific data elements that have high sensitivity or a specific regulatory compliance requirement such as PCI. Separating the sensitive data into its own dedicated, secured data store and using tokens in its place helps avoid the potential cost and complexity of end-to-end encryption. It also helps reduce risk through the use of temporary, one-time-use tokens.

Tokenization is an application-level implementation concern. Typically, you implement it by using a dedicated data store to persist the mapping between tokens and their corresponding sensitive data values. The tokens are stored in application databases in place of sensitive data values and replaced by the application at runtime with real values from the dedicated token data store.

The following diagram illustrates an example of the tokenization process.

This diagram has the following steps:

The application presents sensitive data, such as a credit card number, to the tokenization API.
The tokenization API requests authentication of the application user.
The authentication API authenticates the user.
The tokenization API generates a token for the credit card number and stores and links the token and the credit card number in the tokenization database.
The tokenization API returns the token to the application.
The application stores the token in the application database in place of the credit card number.

Detective controls

Detective controls are also important to database security.

There are a few different ways you can implement detection of unauthorized traffic, such as monitoring VPC Flow Logs and CloudTrail logs with custom logic to identify anomalies. For more information about VPC Flow Logs, see VPC Flow Logs. For more information about CloudTrail logs, see Working with CloudTrail Log Files.

DynamoDB is integrated with CloudTrail. Using the information CloudTrail collects, you can determine the request made to DynamoDB, the IP address from which the request was made, who made the request, when it was made, and additional details. There are two types of operations you can perform on DynamoDB: control plane and data plane.

DynamoDB publishes control plane event activity automatically to CloudTrail, such as CreateTable, ListTables, and UpdateTable API calls. For more information, see Logging DynamoDB Operations by Using AWS CloudTrail.

Enabling Amazon GuardDuty

To automatically monitor network traffic and detect and alert anomalous behavior using machine learning, enable Amazon GuardDuty. Complete the following steps:

On the AWS Management Console, choose Amazon GuardDuty.
Choose Get started.

Choose Enable GuardDuty.

Creating CloudWatch rules

Create CloudWatch rules that monitor and act on GuardDuty findings. You can set up notification alerts through Amazon SNS and also automated remediation actions through AWS Lambda. Complete the following steps:

Open the Amazon CloudWatch console.
Under Events, choose Rules.
Choose Create rule.
For Event Source, select Event Pattern.
From the drop-down menu, choose Build custom event pattern.

Enter the following code:

{
	"source": ["aws.guardduty"],
	"detail": {
		"type": ["UnauthorizedAccess: IAMUser / MaliciousIPCaller.Custom"]
	}
}

For Targets, choose Add target.
From the drop-down menu, choose SNS topic.
For Topic, choose your SNS topic name.
Choose Configure details to provide a name and a description for the rule to complete the process.

The following screenshot shows these completed steps.

Configuration drift

In configuration drift, modifications to a system after its initial deployment can cause a system’s current security configuration to drift away from its desired hardened state.

You can identify configuration drift on-demand with AWS CloudFormation drift detection. To continually monitor the configuration of databases against baseline settings and send alerts when the configuration deviates from the baseline, use AWS Config.

To set this up, complete the following steps:

Open the AWS Config console.
Under Events, choose Rules.
You might go through an initial setup process if you’re enabling AWS Config for the first time.
Choose Add rule.
In the search box, enter dynamodb.
Choose the DynamoDB config check that you want to enable.
You can either search for and choose predefined rules for DynamoDB, or create a new custom rule.

Fine-grained audits

You can perform additional fine-grained audits for greater database security with control plane operations or data plane operations. For more information, see Identity and Access Management in Amazon DynamoDB.

Control plane operations

DynamoDB control plane operations refer to management functions on the DynamoDB table such as CreateTable, DescribeTable, and ListTables. All Amazon DynamoDB control plane operations are logged by CloudTrail and documented in the DynamoDB API.

Creating a new trail enables all CloudTrail logs to be stored in Amazon S3 for audit purposes. For more information, see Logging DynamoDB Operations by Using AWS CloudTrail.

To create a new trail, complete the following steps:

Open the CloudTrail console.
Choose Trails.
Choose Create trail.

To create an Amazon CloudWatch rule that matches all DynamoDB API calls logged by CloudTrail and can trigger a user-defined notification or action, complete the following steps:

Open the CloudWatch console.
Under Events, choose Rules.
Choose Create rule.
For Event Source, select Event Pattern.
From the drop-down menu, select Build custom event pattern.
For Service Name, choose DynamoDB.
For Event Type, choose AWS API Call via CloudTrail.
Select Any operation.
For Targets, choose Add target.
From the drop-down menu, choose SNS topic.
For Topic, choose your SNS topic name.

The following screenshot shows these completed steps.

Data plane operations

Enable logging of data plane API activity in AWS CloudTrail to monitor, alarm, and archive item-level activity in your Amazon DynamoDB tables. Data plane events can be filtered by resource type, for granular control over which DynamoDB API calls you want to selectively log and pay for in CloudTrail. Learn more about on how to enable data plan logging into CloudTrail in Logging DynamoDB operations by using AWS CloudTrail.

A best practice is to implement least privilege. For example, to restrict the access to specific attributes of an item in a DynamoDB table, use fine-grained access control. With fine-grained access control, you can restrict who can view, edit, and delete an item. For more information, see Using IAM Policy Conditions for Fine-Grained Access Control.

Apply attribute-based access control (ABAC) by using IAM policy conditions for specifying user names and attribute names to restrict access. For more information, see AWS re:Inforce 2019: Scale Permissions Management in AWS w/ Attribute-Based Access Control on YouTube.

To specify a user name, you can use the substitution variable ${www.amazon.com:user_id}, which replaces the user name with the user making the call to DynamoDB with the combination of the “dynamodb:LeadingKeys” condition key. This allows you to restrict access to an item to that specific user.

For example, you have employees EMP001, EMP002, EMP003, who are reporting to managers MNG001 and MNG002. The following table contains their emergency contact details.

`ManagerID` (Partition key)	`Reporting_Employee` (Sort key)	`Emergency_Contact`
MNG001	EMP001	1234
MNG001	EMP002	456
MNG002	EMP003	987

After creating the items in the preceding table, add the following policy to each IAM user and role that represents a manager:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAccessToOnlyItemsMatchingUserID",
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem",
                "dynamodb:BatchGetItem",
                "dynamodb:Query",
                "dynamodb:PutItem",
                "dynamodb:UpdateItem",
                "dynamodb:DeleteItem",
                "dynamodb:BatchWriteItem"
            ],
            "Resource": [
                "arn:aws:dynamodb:us-west-2:[YOUR ACCOUNT ID]:table/[TABLE NAME]"
            ],
            "Condition": {
                "ForAllValues:StringEquals": {
                    "dynamodb:LeadingKeys": [
                        "${www.amazon.com:user_id}"
                    ]
                }
            }
        }
    ]
}

With the preceding policy attached, the manager can only see their own details and the emergency contact details of users reporting to them.

For more information about applying fine-grained access control at item level and attribute level, see Using IAM Policy Conditions for Fine-Grained Access Control.

Swim-lane isolation

To enforce strict subnet-level separation between databases and applications of different business domains, implement swim-lane isolation. To implement swim-lane isolation for DynamoDB, use VPC endpoints, as described previously. For more information about swim-lane isolation, see Best practices for securing sensitive data in AWS data stores.

Summary

This post demonstrated how to take the generic data security patterns described in the first post of this series and apply them to a DynamoDB database. Doing this can help you create a strong security posture around your sensitive data.

The post also showed how to protect your DynamoDB database by using a layered approach to create defense in depth. This approach uses network security zones using network ACLs and subnets within your VPCs.

In addition, you learned how to enable a combination of AWS preventative security controls within AWS networking, IAM, and database services. The post also covered how to enable defense in depth for your data by setting up detective controls using Amazon GuardDuty, AWS Config, and CloudTrail. Learn more about DynamoDB in the DynamoDB getting started guide and as always, AWS welcomes feedback, so please leave comments or questions below.

About the Authors

Syed Jaffry is a solutions architect with Amazon Web Services. He works with Financial Services customers to help them deploy secure, resilient, scalable and high performance applications in the cloud.

Masudur Rahaman Sayem is a solutions architect at Amazon Web Services. He works with AWS customers to provide guidance and technical assistance about database projects, helping them improve the value of their solutions when using AWS.

AWS Database Blog

Applying best practices for securing sensitive data in Amazon DynamoDB

Data classification and security-zone modeling

Preventative controls

DDoS protection

Application-level threat prevention

Network isolation

Security groups and network ACLs

Creating a DynamoDB VPC endpoint and applying an endpoint policy

Identity and Access Management

Control plane operations

Data plane operations

Encryption and tokenization

Server-side encryption

Client-side encryption

Encryption in transit

Tokenization

Detective controls

Enabling Amazon GuardDuty

Creating CloudWatch rules

Configuration drift

Fine-grained audits

Control plane operations

Data plane operations

Swim-lane isolation

Summary

About the Authors

Resources

Blog Topics

Follow