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:

MariaDB: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MariaDB.html#MariaDB.Concepts.SSLSupport

SQL Server: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html

MySQL: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.SSLSupport

Oracle: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html#Oracle.Concepts.SSL

PostgreSQL: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.SSL