Guide: Redshift Security Guide

Understanding Redshift Encryption

What is AWS Redshift Encryption?

Amazon Redshift is a data warehouse designed and powered by Amazon Web Services (AWS). A Redshift warehouse is composed of nodes organized into clusters. A Redshift engine runs inside each cluster. A cluster can hold more than one database.

Redshift security features include data protection capabilities for data in transit and data at rest. To protect data in transit, you can use SSL or client-side encryption. Redshift offers two main features for protecting data at rest—server-side encryption and client-side encryption.

When using server-side encryption, you essentially send a request to encrypt data before it is saved on disks in the allocated Redshift data center. Redshift decrypts the data only when you download objects.

When using client-side encryption, you do the encryption and then upload your encrypted data to Redshift. This process requires you to manage the encryption process, keys, and any related tooling you integrate into this process.

In this article, you will learn:

  • How Does Redshift Cluster Encryption Work?
  • How Does Redshift Database Encryption Work?
  • Redshift Encryption at Rest
  • Redshift Encryption in Transit

How Does Redshift Database Encryption Work?

AWS lets users enable encryption on databases in a new cluster, using keys provided through Amazon Key Management Service (KMS). Users can employ either a customer-managed key (CMK) or use an AWS-managed one. When enabling encryption on a cluster, the cluster’s data automatically migrates to a new cluster that is encrypted, and AWS also encrypts pre-existing snapshots of that cluster.

Redshift’s four-tier key-based data architecture consists of separate keys for data, clusters, and databases, as well as a master key. Randomly generated data encryption keys encrypt each Redshift cluster data block. Randomly generated database keys, in turn, encrypt those block encryption keys.

The system then stores the database keys in a disk located in a network that is isolated from the redshift cluster, and transmits them back to the cluster over a secure communication channel. Finally, the cluster key encrypts the redshift cluster’s database key.

Redshift Encryption in Transit

Redshift supports encryption of data in transit between SQL clients and Amazon Redshift, via Java Database Connectivity (JDBC) and Open Database Connectivity (ODBC) connections:

  • Redshift creates and installs certificates issued by AWS Certificate Manager (ACM) for each cluster to support SSL connections.
  • Amazon Redshift supports secure socket layer (SSL) connections, encrypting data and server certificates, to enable validation of server certificates by the client. For this, the client connects to a Redshift cluster’s leader node.

Redshift employs hardware-accelerated SSL for protecting data in transit within Amazon’s cloud when communicating with Amazon S3 or DynamoDB:

  • Redshift uses hardware-accelerated SSL for COPY, UNLOAD, backup, and restore operations on DynamoDB.
  • Redshift encrypts data in transit to S3 using Key Management Service (KMS).
  • Redshift Spectrum enables server side encryption (SSE) on S3 using keys managed by KMS.

Redshift Encryption at Rest

Amazon Redshift offers two options for encrypting data at rest—server-side and client-side encryption.

On the server side, Redshift encrypts your data as it is written to Redshift data centers, and decrypts it when accessed.

Client-side encryption requires you to manage the encryption process. You can use it for any data stored on Amazon S3 (not just Redshift data). Client side encryption uses the AES-256 encryption algorithm.

You can manage client-side encryption using the AWS Key Management Service (AWS KMS). KMS lets you create encryption keys and specify policies that define how keys should be used. Additionally, if you need to audit key usage, you can integrate KMS with CloudTrail.

Changing Cluster Encryption

AWS lets you create unencrypted clusters and then add encryption using AWS Key Management Service (AWS KMS). You can use your own customer-managed key (CMK) or keys managed by AWS. Once you enable encryption with AWS KMS, Redshift migrates all of your data to a new, encrypted cluster.

Here are important aspects to consider when changing your cluster encryption:

  • Before modifying cluster encryption – disable the option that enables cross-AWS Region snapshot copies.
  • During the migration process – clusters are available in read-only mode, and status is changed to “resizing”.

Here is how you change database encryption for a cluster using the AWS console:

  • In the AWS Console, visit the Amazon Redshift console. Select CLUSTERS, and choose the cluster for which you want to change encryption.
  • Select Modify > Database configuration > Encryption > Modify cluster

Here is how to change cluster encryption using the CLI:

Run the modify-cluster  CLI command and specify:

  • –-encrypted  to start encrypting an unencrypted cluster
  • –no-encrypted  to turn encryption off
  • To specify a customer-managed key, add the –kms-key-id  option

The full commands look like this:

Last updated on

May 11, 2021

The information provided in this article and elsewhere on this website is meant purely for educational discussion and contains only general information about legal, commercial and other matters. It is not legal advice and should not be treated as such. Information on this website may not constitute the most up-to-date legal or other information. The information in this article is provided “as is” without any representations or warranties, express or implied. We make no representations or warranties in relation to the information in this article and all liability with respect to actions taken or not taken based on the contents of this article are hereby expressly disclaimed. You must not rely on the information in this article as an alternative to legal advice from your attorney or other professional legal services provider. If you have any specific questions about any legal matter you should consult your attorney or other professional legal services provider. This article may contain links to other third-party websites. Such links are only for the convenience of the reader, user or browser; we do not recommend or endorse the contents of any third-party sites.