Protecting your Databases through Encryption
The course is part of these learning paths
This course looks at the different encryption mechanisms that can be utilized across different AWS Database services, thereby enhancing the security posture and protection of your data. We'll take a look at encryption in Amazon RDS, DynamoDB, and ElastiCache.
If you have any feedback relating to this course, please let us know about it at firstname.lastname@example.org.
- Define and examine encryption across Amazon RDS, Amazon DynamoDB, and Amazon ElastiCache
- Understand both encryption at rest and encryption in transit
This course has been designed to assist those who are responsible for securing, designing, and operating AWS Database solutions, as well as anyone looking to take the AWS Certified Database - Specialty exam.
To get the most out of this course, you should have a basic awareness of AWS database services. You can brush up on these services with part one of our AWS Fundamentals course here. An awareness of the AWS Key Management Service (KMS) would also be advantageous, but not essential.
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:
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.
Sign only – This will sign the attribute and include the attribute in the item signature
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.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.