Hello and welcome to this lecture covering the encryption options when working with Amazon DynamoDB.

Firstly, I want to begin by looking and the encryption at rest options to protect your data being stored within the Database.

By default, when creating your tables within DynamoDB, they are automatically encrypted by default and there is NO option to create them without encryption being applied.  This encryption is provided within its integration to the AWS Key Management Service (KMS), as a result, you do have the option to specify a different Customer Master Key depending on your requirements.  

As you can see, there are 3 options for encryption at rest, each relating to a different type of CMK.  We already discussed Customer managed and AWS managed Keys in the previous lecture, but to recap:

Customer managed CMKs offer the greatest level of flexibility and control.  You are able to create, disable or delete the key, configure the key policies, and more.  Do be aware that if you disable your customer-managed CMK, then your DynamoDB table will be inaccessible. If it is not re-enabled within 7 days then your Table will be archived and DynamoDB will create an on-demand backup for you, and your original table will no longer be accessible.  

AWS Managed Keys are used by AWS services that integrate with KMS directly, such as DynamoDB, and the keys can be identified by its alias, such as AWS/DynamoDB.  This key will only be created the first time you use the AWS managed key in DynamoDB.

However, the DEFAULT option is another type of CMK, an AWS owned CMK.  These are again used by AWS services to encrypt your data, but you can’t see or manage these keys within the KMS console or anywhere within your account, neither do you have the ability to audit and track their usage, they are essentially abstracted from your AWS account.  However, because they can be used by services used within your AWS account, those services do have the capabilities to use those keys to encrypt your data within your account.

When it comes to the rotation of AWS-owned CMKs, it is down to the particular service that manages that particular key and so the rotation period is varied from service to service.  

To give you another example of an AWS owned CMK, would be when using Amazon S3 encryption using the S3 Master key (SSE-S3). 

So getting back to DynamoDB, when you have selected your CMK for encryption at rest, the encryption will apply to all data in your table, which of course will include your primary key, both you local and global secondary indexes, your global tables, and DynamoDB streams, in addition to your backups.  Also, if you’re using DynamoDB Accelerator (DAX), the clusters will also be encrypted.  

For more information on DAX, please see our existing course here.

When encryption is in place, the cryptographic operations happen transparently to the end-user, and if you change your mind on which CMK you would like to use, then you can at any point change the type of CMK you’d like, for example, you can go from the AWS Owned CMK, to a customer-managed CMK, or from an AWS Managed CMK to the AWS Owned CMK.

Do be aware though, that when using the AWS owned CMK, there is no charge for the encryption services that are applied throughout DynamoDB tables and the associated resources.  However, if you decide to use the AWS managed or customer-managed CMKs then there is a small charge for the use of the CMK per month and the number of cryptographic operations carried out.  

Normally when your applications communicate with Amazon DynamoDB, they do so using HTTPS, which is an encrypted protocol, and therefore enforcing a level of encryption in transit.  However, in this section, I want to focus on the DynamoDB encryption client which provides the ability to encrypt your table data before you send it to DynamoDB across the network, and so again, adding a level of encryption in transit.  

As you may be aware, a DynamoDB table contains a number of items, and for every item, you will have a collection of different attributes, and each of these attributes are named and have a value associated. The encryption client works by encrypting these values, not the name, of your DynamoDB attributes which are then protected by a signature to help prevent unauthorized changes to your database, such as replacing encrypted values, and so the signature acts as an integrity checker. 

The client itself has been designed specifically to work with your applications that are interacting with DynamoDB, and provides a transparent level of encryption and decryption to your table items.  The key material used for the cryptographic operations can be sourced from your own key material, or by using AWS KMS, or CloudHSM.  

The encryption client libraries are open source and available on GitHub and currently support both Java and Python. Interestingly, the programming languages supported are interoperable, therefore you could encrypt using one language, and then decrypt the same data using another.

You should however be aware that the DynamoDB encryption client is not compatible with the following:

• The Amazon S3 Encryption Client, which is used for client-side encryption on S3, including CSE-KMS (Client-Side Encryption using KMS managed keys) and CSE-C (Client-Side Encryption using Customer managed keys)
• Or the AWS Encryption SDK, which is another client-side encryption library adhering to industry best practices

There are a number of components that you should be aware of if you are planning to encrypt data using the DynamoDB encryption Client, so let’s take a look at some of them.

When working with the encryption client you will need to specify a CMP, as the result of your selection will determine how the remaining configurable components are implemented.  The CMP carries out a number of tasks:

• It gathers and assembles the required cryptographic materials needed by the Item Encryptor to perform encryption, decryption, and signing of your data.
• It defines which algorithm is used to perform the encryption and how to create the required keys for encryption and signing
• It directly communicates with the Item Encryptor providing cryptographic materials

We already know that the Item Encryptor interacts with the CMP to request cryptographic material, but the Item Encryptor is the actual component that performs the encryption, decryption and signing operations which are provided by the DynamoDB Encryption Client.  

There are 3 different attribute actions that can be performed on each attribute of your DynamoDB items, and it’s the Attribute Action component that instructs the Item Encryptor which action should be applied.

The 3 options are:

1. Encrypt and sign – This will both encrypt and sign the attribute.  Only the value of the attribute will be encrypted, but both the name and value of the attribute will be included in the item signature.

2. Sign only – This will sign the attribute and include the attribute in the item signature

3. Do nothing – No encryption or signing takes place against the attribute

An important point to note is that you should never encrypt the primary key attributes, this is to prevent your DynamoDB from running a table scan to find a single item. Instead, you should use Sign only as an attribute action for your partition and sort keys.

This contains information on the specific encryption algorithms that are used against an encrypted table.  As a result, the CMP stores this Material description as it collates cryptographic material for the Item Encryptor.  This information is then analyzed when retrieving data as a point of reference as to which algorithms to follow to decrypt the data.