Redshift Security: Data Backups and Encryption Best Practices

In this blog post, second in a series, we focus on risks that come from a misconfigured Redshift, like encryption, backups and logs. We’ll explore security features and best practices that can prevent data leakage.

You can catch up with the previous blog post, Redshift Security: Access and Data Flows Explained. When you're ready, let's dig in.

Configuring Data Encryption in Redshift

Redshift provides two types of encryption to help with protecting sensitive data, at-rest and in-transit.

Protecting Sensitive Data in Transit

Encryption of data in transit is important to avoid data manipulations, leaks and repudiations. Redshift allows data movements between the clusters to and clients over JDBC/ODBC, or between Redshift cluster and other AWS services such as S3 and DynamoDB.

Amazon Redshift uses SSL for communication with Amazon S3 or Amazon DynamoDB for copying and unloading data.
By default, Redshift accepts connections either using SSL or not.

Pro Tip

It’s recommended to configure your cluster to require SSL connections, by setting the require_SSL parameter in the cluster's parameter group to true.

Enforce encryption in transit with CLI:

Enforce encryption in transit with console:

Under the “Properties” tab we can see the parameter group attached to our Redshift cluster, click on the parameter group (showing “ofir-redshift-parametergroup” in the image below):

Now to change the parameters click on “Edit”:

Set the require_ssl parameter to true then hit “Save”:

Why Encrypt Data at Rest?

• When encryption is enabled, snapshots of the cluster are encrypted, which ensures that the data is protected in any form outside your Redshift cluster, even when the snapshot is moved between regions or accounts.
• The regulations governing your data may also require you to use encryption.

Redshift encryption uses envelope encryption, which means that you can rotate keys without having to re-encrypt data blocks. The key hierarchy consists of four tiers:

• Root key
• Cluster encryption key (CEK)
• Database encryption key (DEK)
• Data encryption keys

Related article: Database encryption for Amazon Redshift using AWS KMS

Encrypting Sensitive Data Using KMS / CMS

It’s possible to use AWS KMS or customer managed keys (CMS) for encryption, which offer more flexibility including the ability to create, rotate, disable, define access control and audit encryption keys.

Encrypting Data Using HSM

If you don't use AWS KMS for key management, you can use a hardware security module (HSM) for key management with Amazon Redshift.

Key Rotation for Amazon Redshift Cluster

Redshift lets you rotate encryption keys for encrypted clusters. Whenever a key rotation is initiated, the Redshift CEK is rotated for the specified clusters and any automated or manual snapshots. In the same way, Redshift rotates the DEK for the cluster, but not for snapshots, since they’re stored internally in an internal S3 bucket.

Pro Tip

It’s recommended to enable encryption at rest, to check if your cluster is encrypted look for the encryption setting under the properties tab.

Enable encryption at rest with CLI:

Enable encryption with the console:

Under the “Properties” tab, on “Database configurations” section, click on “Edit” then “Edit encryption”.
Choose the desired encryption type:

Sensitive Data Backups

Creating a fresh backup of Redshift’s clusters is a best practice for data compliance, data redundancy and data availability. However, managing multiple backups, knowing where they are, and securing them against exposure and exfiltration can be challenging. To keep our sensitive data safe, we must understand Redshift's snapshot capabilities and features.

DB Snapshots

Snapshots are point-in-time backups of clusters. Snapshots are either automatically or manually generated and they’re stored internally in Amazon S3 using an SSL connection.

Automated DB Snapshots

Redshift clusters create “automated snapshots” by default. These snapshots are deleted automatically when the retention period expires (default is 1 day), when automated snapshots are disabled, or when the cluster is deleted.

Pro Tip

By setting the retention period to 0, automated snapshots are disabled. Make sure all your clusters are configured to take automatic snapshots (retention period != 0).

Setting the retention for any future automated snapshot with CLI:

Setting the retention for any future automated snapshot with the AWS console:
Under the cluster page, click on “Edit” then under the “Backup” section set the retention for automated and manual snapshots:

Manual DB Snapshots

Without specifying a retention period when you create manual snapshots, Redshift manual snapshots remain forever, even after the cluster itself is deleted. Leaving behind an unmanaged sensitive data creates an exposure that can be exploited by attackers who are looking for easy targets.

Pro Tip

It’s recommended to always set a retention when creating or copying manual snapshot from an automated snapshot. Note that it isn’t mandatory to set the retention and if not set, the snapshot will exist forever.

Creating manual snapshot with retention period — with CLI:

Setting retention for an existing manual snapshot with CLI:

Setting retention for manual snapshots with the AWS console:
Inside the desired snapshot click on “Actions” then “Manage access”:

Now under “Manual snapshot retention period” choose the wanted retention:

Pro Tip

It’s recommended to set a retention period for future snapshots.

‍Sharing Snapshots

One of the features of snapshots is sharing, it’s possible to share snapshots between AWS accounts. A snapshot that is shared with different accounts can be restored on that account.

Pro Tip

It’s recommended to remove shares with any unnecessary account to reduce attack surface and data leakage.

To authorize the specified AWS account to restore the specified snapshot with CLI:

To check with which AWS accounts the snapshot is shared check the “AccountsWithRestoreAccess” when describing the snapshot:

To remove AWS account share on snapshot with CLI:

To remove AWS account share on snapshot with AWS console:
Inside the desired snapshot click on “Actions” then “Manage access”:

Now under “Manage access” click on :”Remove account” to remove the unwanted account:

Disable Automatic Copying Snapshots Between AWS Regions

Some compliance and regulations like GDPR prevent data movement between restrictive areas e.g data containing EU-based PII can’t exist in a US storage location. To ensure your organization remains in compliance, it’s recommended to disable the option to copy snapshots between regions.

Pro Tip

It’s recommended to disable snapshot copy if not required.

Disable cross-region snapshot copy with CLI:

Disable cross-region snapshot copy with AWS console:
Under the cluster page, click on “Actions” then choose “Configure cross-region snapshot”:

Choose “No” and click on “Save”:

Enable Logs on Sensitive Data

Monitoring is an important part of the ongoing effort in defending sensitive data inside Redshift. Monitoring can also help detect suspicious activity and respond in time to prevent a leak. In our next blog, we’ll share specific examples of data attacks.

Redshift supports two types of monitoring:

• CloudTrail: Audit management activity in AWS & API events
• Audit logs: Audit activity connections and queries inside the Redshift cluster

Enable CloudTrail

CloudTrail management events are enabled by default (after a trail is created). It’s important to regularly monitor the management events related to your Redshift cluster and make sure that no configuration changes put your data at risk. For example Redshift cluster made public, suspicious temporary credentials created etc.

Pro Tip

It’s recommended to enable CloudTrail.

Enable Audit Log

Audit logs consist of the following log types:

• Connection log – Logs authentication attempts, connections and disconnections
• User log – Logs information about changes to database user definitions
• User activity log – Logs each query before it's run on the database

We’ll explore Redshift logging capabilities more deeply while trying to hunt suspicious activities in our next blog.

Connection and user logs are enabled by default and kept inside the database system tables STL_USERLOG and STL_CONNECTION_LOG respectively.
When enabling Redshift audit log, it exports the logs from within the database to S3 bucket or CloudWatch.

Pro Tip

It’s recommended to enable audit logs for security reasons, occasionally check for failed logins, suspicious GRANTs, user creation and more.

Enable Redshift audit logs export with CLI:

To enable User Activity Log, it’s necessary to enable the database parameter “enable_user_activity_logging” by setting its value to “true” (it’s disabled by default).

Enable Redshift user activity log with CLI:

Enable Redshift audit logs with the AWS console:
Under the “Properties” tab, on “Database configurations” section, click on “Edit” then “Edit audit logging”:

To turn on the activity log, go to the Redshift parameter group and modify the value of enable_user_activity_logging:

Learn More

As we continue to explore the different security features of Redshift, we hope you find this useful and will consider these steps to further reduce the risk of exposing your data in Redshift.

What's Next?

The next blog post in the series will cover some of the novel attack vectors our research team has discovered in Redshift. This is where the real action begins. Stay tuned and secure!