Securing data in Amazon RDS using AWS KMS encryption

This post has been reviewed and/or updated on June 2022.

Data privacy is essential for organizations in all industries. Encryption services provide one standard method of protecting data from unauthorized access. However, encryption changes data in a way that makes it unreadable without the correct decryption key.

Amazon Relational Database Service (Amazon RDS) can encrypt data using an AWS managed key or a Customer managed key (CMK). However, some customers prefer to encrypt data using non-default keys. When using non-default keys, robust key creation, management, and deletion tools and processes are vital to data security. Such tools and processes also help prevent key expiration from affecting data availability.

In this post, I discuss how AWS Key Management Service (AWS KMS) simplifies data encryption and key management processes for data stored in RDS. Topics covered include:

• Key management
• Creating keys
• Creating encrypted databases
• Creating and copying encrypted database snapshots
• Rotating keys
• Controlling key access

Introducing AWS KMS

You can use AWS KMS to encrypt data stored in AWS services such as Amazon RDS. Key permissions fully integrate with AWS Identity and Access Management (IAM). Plus, all KMS API calls write to AWS CloudTrail, providing a full audit trail of key creation, usage, and deletion. AWS KMS keys are 256 bit in length and use the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM). For more details, see AWS Key Management Service Cryptographic Details.

You can use an AWS managed key, or you can create customer managed keys. The following table shows the three main key types used in AWS KMS. For more information, see AWS Key Management Service Concepts.

AWS owned keys are a collection of AWS KMS keys that an AWS service owns and manages for use in multiple AWS accounts.

AWS creates and fully manages AWS managed keys. Customer managed keys are CMKs in your AWS account that you create, own, and manage.

The source key material used to encrypt and decrypt data with a customer managed CMK can be provided by multiple sources, as shown in the following table.

The custom key store also requires provisioning from an HSM. For more information, see Announcing AWS KMS Custom Key Store.

Creating keys

Open the AWS KMS console and create a Customer Managed Key. For more information see Creating Keys in the AWS KMS documentation. You will use this key in the next step to create an encrypted RDS database cluster.

Creating an encrypted RDS database cluster

To encrypt a database, you must identify an AWS KMS key during database cluster creation. This key encrypts all data stored on the volume(s) used by RDS. After data is encrypted, it is inaccessible without AWS KMS key permissions. Attempts to restore an RDS snapshot or start a stopped RDS instance fail without that permission.

Open the RDS console and create a database cluster. Ensure you select the AWS KMS key created earlier in the Additional Configuration section. For more detailed information and a walkthrough of the process see Encrypting Amazon RDS Resources.

Encrypted database snapshots

All the database snapshots that you create from an encrypted RDS instance retain their encryption, sharing the same AWS KMS key. You can build a new database from such a snapshot, but only if you have access to the AWS KMS key used to encrypt the DB snapshot.

Creating RDS snapshots

To create an RDS snapshot, select the database cluster instance, and choose Actions, Take snapshot.

Copying encrypted RDS snapshots to other AWS Regions

After you create RDS snapshots, you can copy encrypted RDS snapshots to other AWS Regions by following the steps described in this section. AWS KMS keys are Regional constructs. So, to copy a snapshot to another Region, you first must create an AWS KMS key in the destination Region. Use this new key to encrypt the snapshot in the destination Region.

1. First, choose your destination Region and create a key in that Region using the same procedure described earlier. Record the key-id and key-alias values for the newly created key.
2. Open the RDS console in the Region where the current RDS snapshot resides.
3. Choose Snapshots and select the RDS snapshot to copy. Choose Action, Copy Snapshot.
4. Select the destination Region and give the snapshot a friendly identifier. Copy any tags to align with your tagging strategy.
5. Under Encryption, select the new key in the destination Region, and choose Copy Snapshot.

Use the following bash script to copy database cluster snapshots to different Regions at regular intervals automatically. You might find this practice helpful for testing purposes or as part of a disaster recovery solution.

To use this script, copy and paste the text into a local file and modify the top-level variables to suit your environment. Also, be sure to modify the permissions of the local file to include the execute permission. Finally, configure your AWS CLI with a suitable IAM user or role, then run the script.

#!/bin/bash

# Adjust these variables
DBINSTANCE=rds-demo-cluster
SRC_AWS_ACCOUNT=111111111111
SRC_AWS_REGION=eu-west-1
DEST_AWS_REGION=eu-central-1
DEST_KMS_KEYID=1111111-2222-3333-4444444444444444

# ----------------------------------------
# Don't change anything else after this
# ----------------------------------------
DATESR=$(date "+%Y%m%d%H%m")

# Dynamically generate snapshotId based on date
SNAPSHOTNAME=$DBINSTANCE-snapshot-$DATESR

# Generate snapshot Arn
SRCSNAPSHOTID=arn:aws:rds:$SRC_AWS_REGION:$SRC_AWS_ACCOUNT:cluster-snapshot:$SNAPSHOTNAME

echo "Creating snapshot for DB Instance: $DBINSTANCE"
aws rds create-db-cluster-snapshot \
--db-cluster-identifier $DBINSTANCE \
--db-cluster-snapshot-identifier $SNAPSHOTNAME \
--region $SRC_AWS_REGION

echo "Waiting for cluster snapshot $SNAPSHOTNAME to be available"
while STATUS=$(aws rds describe-db-cluster-snapshots --region $SRC_AWS_REGION --query "DBClusterSnapshots[?DBClusterSnapshotIdentifier=='$SNAPSHOTNAME'].Status" --output text); test "$STATUS" != "available"; do sleep 1 && echo "State: $STATUS"; done;
echo "State: $STATUS"

echo "Copying DB Snapshot...this may take a while depending on the size of the snapshot"
aws rds copy-db-cluster-snapshot \
--source-db-cluster-snapshot-identifier $SRCSNAPSHOTID \
--target-db-cluster-snapshot-identifier $SNAPSHOTNAME \
--source-region $SRC_AWS_REGION \
--kms-key-id $DEST_KMS_KEYID \
--region $DEST_AWS_REGION

Rotating keys in AWS KMS

Keys are commonly rotated to limit the impact of potential key compromise. If your CMKs come from original AWS KMS key material, you can opt to have AWS automatically rotate your CMK every year. You can opt for automatic annual rotation either when prompted during key creation, or after AWS KMS key creation. See How to Enable and Disable Automatic Key Rotation for more information. For more detailed information about AWS KMS key rotation, see Rotating Custom Master Keys.

If you obtained the original key material from your hardware security module (HSM) or another external source, you must manually rotate your CMK. For RDS, you can create a new RDS instance or cluster from a re-encrypted snapshot copy using the following procedure:

1. Create a new CMK using the procedure outlined previously.
2. Create a snapshot of your existing instance or cluster using the procedure outlined previously. If you have a recent snapshot, you can skip this step.
3. Create a copy of the snapshot using the procedure described earlier in this post. However, you can also re-encrypt the new snapshot copy with the new CMK by selecting the new CMK in the Encryption
4. Select the new snapshot copy and choose Actions, Restore Snapshot.
5. Follow the online workflow to create a new RDS instance or cluster. The data is encrypted using the new CMK. For guidance, follow the new instance or cluster creation procedure described earlier.

Once the manual key rotation procedure is complete you may delete the old RDS instance and schedule the deletion of the previous CMK. However, note that service interruption may occur if other resources are using the previous CMK. You can track the usage of keys in AWS KMS using Amazon CloudTrail.

Also note that if you require the ability to restore from a backup, snapshot or logs for point-in-time-restore that were encrypted prior to rotating the key, the previous CMK must not be deleted. This is because the key is required to decrypt the previous backup, snapshot or logs. This is only needed when manually rotating keys and not required if automatic key rotation is enabled.

Controlling AWS KMS key access

You manage access to encrypted resources in AWS by controlling access to the respective AWS KMS keys. Take a look at Managing Access to AWS KMS CMKs for more information.

You can revoke access to an AWS KMS key, and thus revoke access to all AWS resources encrypted using that key, using any of the following methods:

• Disable the AWS KMS key. This procedure is reversible as the key can be later enabled.
• Delete the AWS KMS key. This procedure schedules the deletion of the key but doesn’t delete the key immediately. You specify a deletion period of between seven and thirty days. You can cancel the key deletion at any time within the specified deletion period. After that time, deletion is permanent. Warning: You cannot recover data encrypted using a deleted key.
• Remove externally provided key material. If you use externally provided key material, you can remove this key material. Removal effectively disables the key. This operation can be reversed by re-importing the key material. This option provides a high degree of confidence that the data cannot be accessed but also allows you to restore access at a later date.

If an AWS KMS key is unavailable to RDS for a period of time, either by revoking key access using one of the methods in this section, or if a configured key expiration date is reached, the RDS instance may report an “inaccessible-encryption-credentials” error and become inaccessible. This can occur if the AWS KMS key is unavailable and the underlying Amazon Elastic Compute Cloud (Amazon EC2) host changes for any reason, RDS attempts to save logs to support a future point-in-time-restore, or if automated backups are enabled.

To recover from an inaccessible-encryption-credentials state, the RDS instance must be restored from backup or point-in-time. However, the original AWS KMS key must be available for the restore to complete successfully. This is because the backup and logs are encrypted using the same AWS KMS key that was used to encrypt the database. Therefore the backup and logs must be decrypted using the same AWS KMS key during the restore or point-in-time-recovery procedure.

Auditing AWS KMS key usage and lifecycles

To maintain security, monitor the creation, usage, modification, and deletion of AWS KMS keys used to encrypt your organization’s data. Because all AWS KMS operations are API calls, you can monitor them using AWS CloudTrail. For more information, see Logging KMS API Calls with AWS CloudTrail.

Summary

In this post, I demonstrated how to use AWS KMS to protect data stored in RDS. I outlined how to create keys and encrypt data in RDS instances or clusters. I showed you how to create encrypted RDS snapshots and copy the snapshots to other AWS Regions. Finally, I explained how to rotate keys, control access to keys in AWS KMS, and audit AWS KMS activity.

You can now apply data protection techniques in RDS to secure data in line with your organization’s data protection policy. For more information, see Encrypting Amazon RDS Resources.

The concepts and methods outlined in this post also apply when protecting data in many other AWS services, such as Amazon EBS volumes attached to Amazon EC2 instances, Amazon S3, Amazon Redshift, and many others.

As always, AWS welcomes feedback. Please submit comments or questions below.

About the Author

Nicholas Ansell is a principal consultant with AWS Professional Services. He works closely with customers to help rapidly realize their goals using AWS services.