AWS Database Blog

Securing data in Amazon RDS using AWS KMS encryption

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 RDS encrypts data by default, using AWS owned keys. 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 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

KMS can be used to encrypt data stored in AWS services such as RDS. Key permissions fully integrate with IAM. Plus, all KMS API calls write to AWS CloudTrail, providing a full audit trail of key creation, usage, and deletion. 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 (PDF).

While RDS supports all key types, the following table shows the three main key types used in KMS. For more information, see AWS Key Management Service Concepts.

CMK type Can view? Can manage? Is it used only for my AWS account?
AWS owned CMK No No No
AWS managed CMK Yes No Yes
Customer managed CMK Yes Yes Yes

AWS owned keys exist outside your AWS account and are part of a collection of customer master keys (CMKs) that AWS owns and manages.

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.

Customer managed CMK type Key material provided by
Customer managed AWS KMS
Customer managed external You (using an external source, that is, HSM or OpenSSL)
Custom key store You (using CloudHSM)

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 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 a 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 KMS key permission. 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 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 KMS key. You can build a new database from such a snapshot, but only if you have access to the 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. KMS keys are Regional constructs. So, to copy a snapshot to another Region, you first must create a 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 KMS

Keys are commonly rotated to limit the impact of potential key compromise. If your CMKs come from original 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 KSM key creation. See How to Enable and Disable Automatic Key Rotation for more information. For more detailed information about 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.

Controlling KMS key access

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

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

  • Disable the KMS key. This procedure is reversible as the key can be later enabled.
  • Delete the 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.

Auditing KMS key usage and lifecycles

To maintain security, monitor the creation, usage, modification, and deletion of KMS keys used to encrypt your organization’s data. Because all 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 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 KMS, and audit KMS activity in AWS.

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.