Description

Ensure that every Amazon Redshift provisioned cluster has encryption at rest enabled. When encryption is enabled, the data blocks, system metadata and snapshots of the cluster are encrypted with an AWS KMS key.

Rationale

Without encryption at rest, data blocks and snapshots can be read if the storage or backups are accessed by unauthorized parties. This puts the confidentiality of the data warehouse at risk and allows bulk data theft of sensitive analytics data. All clusters should be encrypted, preferably with a customer managed KMS key, with least-privilege access to the key and restricted access to snapshots and cross-region copies.

Impact

  • Protects cluster data and snapshots at rest from unauthorized access

  • While encryption is being applied to an existing cluster, the cluster is available in read-only mode, so the change should be made in a maintenance window

  • Using a customer managed KMS key adds key management and KMS request costs

Default Value

Newly created Amazon Redshift provisioned clusters are encrypted by default. Clusters created before this default was introduced may still be unencrypted.

Pre-Requisites

  • IAM permissions: redshift:DescribeClusters and redshift:ModifyCluster

  • If a customer managed key is used: kms:DescribeKey and kms:CreateGrant on that key, and a key policy that allows Amazon Redshift to use it

  • A maintenance window, because the cluster is read-only while the data is being encrypted

Remediation

Test Plan

Console:

  1. Sign in to the AWS Management Console at https://console.aws.amazon.com.

  2. Open the Amazon Redshift console and select Clusters.

  3. Select each cluster and open the Properties tab.

  4. In Database configurations, check that Encryption is enabled.

  5. Repeat for each region in use.

  6. If any cluster is not encrypted, follow the implementation steps.

CLI:

List all clusters with their encryption setting and KMS key:

aws redshift describe-clusters --region <REGION> --query "Clusters[].[ClusterIdentifier,Encrypted,KmsKeyId]" --output table

A cluster fails if Encrypted is False.

Implementation Steps

Console:

  1. Sign in to the AWS Management Console at https://console.aws.amazon.com.

  2. Open the Amazon Redshift console and select Clusters.

  3. Select the cluster and open the Properties tab.

  4. In Database configurations, choose Edit, then Edit encryption.

  5. Enable encryption and choose the AWS managed key or a customer managed KMS key.

  6. Choose Save changes and wait until the cluster status returns to Available.

  7. Repeat for each affected cluster in each region in use.

CLI:

Enable encryption at rest on a cluster (add --kms-key-id <KMS_KEY_ID> to use a customer managed key):

aws redshift modify-cluster --region <REGION> --cluster-identifier <CLUSTER_ID> --encrypted

Backout Plan

Before making changes, save the current cluster settings:

aws redshift describe-clusters --region <REGION> --cluster-identifier <CLUSTER_ID> > redshift-cluster-backup.json

To roll back by turning encryption off:

  1. Sign in to the AWS Management Console at https://console.aws.amazon.com.

  2. Open the Amazon Redshift console, select the cluster and open the Properties tab.

  3. In Database configurations, choose Edit, then Edit encryption.

  4. Select no encryption.

  5. Choose Save changes and wait until the cluster status returns to Available.

CLI:

aws redshift modify-cluster --region <REGION> --cluster-identifier <CLUSTER_ID> --no-encrypted

Warning: turning encryption off re-introduces the finding and runs a migration of the cluster's data, which can take a long time on large clusters.

Alternatively, to roll back only a key change:

  1. Sign in to the AWS Management Console at https://console.aws.amazon.com.

  2. Open the Amazon Redshift console, select the cluster and open the Properties tab.

  3. In Database configurations, choose Edit, then Edit encryption.

  4. Select the previous KMS key, or the AWS managed key if a customer managed key causes access problems.

  5. Choose Save changes.

Note: returning the cluster to an unencrypted state is not recommended, because it exposes the data at rest again.

Reference