Determine how to secure application tiers - AWS Service Encryption
The course is part of this learning path
Outline: Designing Secure Applications and Architectures.
In this course, we learn to recognize and explain what encryption is at a high level. We will then cover the various encryption options provided by AWS and how we can secure application tiers by applying encryption to AWS services such as Amazon S3, Amazon Athena, Amazon Kinesis, Amazon Elastic Map Reduce, Amazon RDS and Amazon Redshift
If you are new to Amazon Athena, Amazon Kinesis, Amazon EMR or CloudHSM please see our existing courses here:
Hello and welcome to this short lecture covering RDS encryption options. RDS allows you to set up a relational database using a number of different engines such as MySQL, Oracle, SQL Server etc. During the creation of your RDS database instance, you have the opportunity to Enable Encryption at the Configure Advanced Settings screen under Database Options and Enable Encryption.
By enabling your encryption here, you are enabling encryption at rest for your storage, snapshots, read replicas and your back-ups. Keys to manage this encryption can be issued by using KMS. It's not possible to add this level of encryption after your database has been created. It has to be done during its creation.
However, there is a workaround allowing you to encrypt an unencrypted database as follows. You can create a snapshot of your unencrypted database, create an encrypted copy of that snapshot, use that encrypted snapshot to create a new database and then, finally, your database would then be encrypted.
If the KMS key that was used for the encryption is disabled, then you'll 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 encrypted 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.
In addition to encryption offered by RDS itself at the application level, there are additional platform level encryption mechanisms that could be used for protecting data at rest including Oracle and SQL Server Transparent Data Encryption, known as TDE, and this could be used in conjunction with the method order discussed but it would impact the performance of the database MySQL cryptographic functions and Microsoft Transact-SQL cryptographic functions.
If you want to use the TDE method, then you must first ensure that the database is associated to an option group. Option groups provide default settings for your database and help with management which includes some security features. However, option groups only exist for the following database engines and versions.
Once the database is associated with an option group, you must ensure that the Oracle Transparent Data Encryption option is added to that group. Once this TDE option has been added to the option group, it cannot be removed. TDE 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.
RDS offers the ability to encrypt instances in all regions other than the China Beijing region and across the following Instance Types only. In comparison to EMR, applying encryption at rest for RDS is simplified thanks to the built in application encryption option which EMR does not have.
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 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. For more information on the implementation of this encryption for the following database engines, take a look at the link shown on the screen.
If you are using Oracle with RDS, then instead of using SSL encryption between a client and the database you could use Oracle's Native Network Encryption, NNE, which will encrypt all connections to and from the database. It is, however, not possible to use both SSL and NNE together for encryption. You must use one or the other if required.
To enable NNE, you must add the NATIVE_NETWORK_ENCRYPTION to the database options group. More information on Oracle NNE can be found here.
That brings us to the end of this lecture. Coming up next I shall be looking at the encryption across big data frameworks starting with Amazon Kinesis Firehose.
About the Author
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data centre and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 60++ courses relating to Cloud, most within the AWS category with a heavy focus on security and compliance
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.