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 email@example.com.
- 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 RDS encryption options. You may want to implement encryption for your databases to enhance the security posture of your deployment or to meet compliance requirements. Either way, it is simple and easy to implement and protects your data being stored by your DB instance.
Amazon RDS offers the ability to apply encryption at rest, in addition to the connectivity to your databases. Let’s take a look at the methods used to accomplish this.
If you want to encrypt your database then you must specify the encryption option during its creation, and when encryption has been enabled, you are effectively enabling encryption at rest for your RDS storage, snapshots, read replicas, and your back-ups.
It is not possible to simply enable encryption on a database instance after it has been provisioned. If you want to encrypt an unencrypted database you must create a snapshot of your unencrypted database. Then create an encrypted copy of that snapshot and use that encrypted snapshot to create a new database. This new database instance would then be encrypted.
During the creation of your RDS database instance, you have the opportunity to Enable Encryption via a tick box.
This example has been taken from the MySQL database engine type, and when encryption has been selected, you must specify a CMK, which is a Customer Master Key. CMKs are used by the KMS service, which is used to store and generate encryption keys that can be used by other AWS services and applications to encrypt your data, such as RDS. So KMS is a fundamental security service offered by AWS to help you manage your cryptographic operations.
The CMK, the customer master key is the main key type within KMS and it contains the key material that is used to encrypt your data and RDS uses 2 different types, Customer Managed and AWS Managed.
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.
AWS Managed Keys are as the name suggests are managed by AWS. They are used by AWS services that integrate with KMS directly, such as RDS, and RDS uses its own AWS Managed Key and can be identified by its alias. As you can see in the screenshot, the AWS managed key is names AWS/RDS in the key selection list.
One point to note is that if you selected a customer-managed CMK and then that key was disabled, you would not be able to read or write to your database and RDS will move your database instances into a terminal state where it can no longer be accessed. At this stage, the only option in retrieving your data is to reinstate the KMS key and then recover your database from a previous back-up. The previous RDS instance in a terminal state will still not be accessible.
Read replicas follow the same encryption pattern as defined by the database source. So, for example, if your database had encryption at rest enabled, then the read replica will also be encrypted. It would not be possible to have an encrypted read replica if the database itself was not encrypted.
If you would like to learn more about KMS, please see our existing course here.
Encryption is available across all DB engines offered by RDS, but it is not supported across all instance types, for the latest list of non-supported instances, please see the following AWS documentation.
In addition to encryption offered by RDS using the Key Management Service (KMS), Amazon RDS also supports Transparent Data Encryption, known as TDE as supports SQL Server Enterprise Edition and Oracle Enterprise Edition. TDE will automatically encrypt your data before it’s written to RDS storage, and then automatically decrypt the data when it's read. As with KMS encryption, the cryptographic operations and actions of TDE are seemingly transparent to the end-user.
TDE can be used in conjunction with the previous method discussed, however it may impact the performance of the database cryptographic functions.
If you wish to use TDE with Oracle or SQL Server Enterprise, you must first ensure that the database is associated with an option group. Option groups provide default settings for your database and help with management which includes some security features.
Once the database is associated with an option group, the Oracle Transparent Data Encryption option must be added to that group. Once this TDE option has been added to the option group, it cannot be removed. If you need to change the option group of the database, then you can only do so if the new option group also has the TDE option added.
Transparent Data Encryption can use two different encryption modes, firstly, TDE tablespace encryption which encrypts entire tables, and secondly, TDE column encryption which just encrypts individual elements of the database.
From a performance perspective, then it is recommended by AWS that you separate your unencrypted and encrypted databases on different instances to avoid running into free disk space issues due to the transaction log size of encrypted databases being larger than unencrypted logs.
Also, when using TDE there is a minimal and unavoidable performance impact, and so if you are running a DB solution where you require high performance and low latency, it is recommended that you use provisioned IOPS on at least an M3.Large DB instance class.
Now we have discussed encryption at rest for your RDS database, let’s take a look at the methods of encryption for the connection between your RDS database and a client, so essentially encryption in transit.
When looking at Encryption in Transit for communication between your application and RDS, then you can secure this communication using SSL/TLS which is Secure Sockets Layer Transport Layer Security which are both cryptographic protocols. This method is supported by MySQL, MariaDB, SQL Server, Oracle, and PostgreSQL database engines.
This is always recommended if you have to abide by specific compliance and governance controls or when the data being sent to RDS is highly sensitive such as containing customer details. The method in which this process is carried out varies dependent on which database type you have.
When you provision an RDS instance, RDS will create an SSL certificate which is signed by a certificate authority. The certificates themselves are then installed on the RDS DB instance. To help prevent and reduce spoofing attacks, the SSL certificate uses the database endpoint as the common name (CN).
Depending on the DB engine type used, the implementation of SSL/TLS is different and varies between configurations. If you are interested in deep diving into these between the DB engines you can use the following resources:
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.