Narrator: So now let's talk about RDS Security
and the first topic I want to talk about is encryption.
So we have at rest encryption
which is data that's not in movement,
and there's a possibility to encrypt the master database
and the read replicas using AWS KMS
which is the Key Management Service of AWS,
using AES-256 encryption.
So when you do encryption, you define it at launch time
and if the master is not encrypted,
the read replicas cannot be encrypted,
so that is a common scenario question of the exam as well.
You can also enable Transparent Data Encryption,
also called TDE for Oracle and SQL Server
and that provides you an alternative way
of encrypting your database.
Now there's in-flight encryption
which is always going to be around SSL certificates
and they're used to encrypt data to RDS while in flight,
so while being sent from your clients into your database.
For this, you provide SSL options with a trust certificate
when connecting to the database
and you will have established an SSL connection.
To enforce SSL to make sure that all the clients
must use SSL.
If you're using Postgres,
there is a console parameter group you need to set
called rds.force ssl = 1.
That's pretty explicit
and you're using my sequel within the database.
You need to run this sequel statement
called Grant Usage On To MySQL user Require SSL.
Again, it's pretty obvious what it does.
Just so you know, Postgres is a parameter group
and MySQL is going to be a sequel command
within the database.
So now let's talk about network and IAM security.
For network security,
well our RDS database are usually deployed
within a private subnet, not a public one,
so make sure not to expose your database
to the worldwide web,
and RDS security works by leveraging security groups
that you attach to your RDS instance.
They're exactly the same concept as for EC2 instances,
and it controls which IP or which security groups
can communicate with RDS.
For access management, which is user management and so on
and permissions,
you have IAM policies.
They help you only control who can manage AWS RDS,
so who can create a database, who can delete a database,
who can create a read replica and so on,
and for traditionally connecting to the database,
you need to use a traditional username and password, okay?
To login into the database.
Or, as we'll see in the next slide,
for just RDS MySQL and RDS PostgreSQL,
you can use IAM-based authentication, okay?
So bottom line is,
the database security usually is from within the database.
Now let's talk about how we can connect to RDS
using IAM authentication.
So as I said, it is only for MySQL and Postgres
and you don't need a password this time,
you just need something called an authentication token
and that can be obtained directly
using IAM and RDS API calls.
We'll see this in the diagram in a second.
And the authentication token because it's short-lived,
it has a lifetime of 15 minutes.
So here's the example.
We have our EC2 security group and our EC2 instance
and then we have our MySQL RDS database
in RDS security group.
So the EC2 instance will have something called an IAM role
and we'll see what that means
when we get deep into IAM roles for EC2.
But the idea is that the EC2 instance,
thanks to that IAM role,
is going to be able to issue an API call to the RDS service
to get back an authentication token
and using the token,
it's going to pass that token all the way to
while connecting to the MySQL database,
and make sure the connection is encrypted by the way,
and then it will connect securely to your MySQL database.
Fairly easy.
The benefits of this approach is that the network in and out
must be encrypted using SSL.
IAM is going to be used to centrally manage users
instead of managing users from within the database,
so it's a more central type of authorization,
and you can leverage IAM roles and EC2 instances profiles
for easy integration and as I said,
we'll see what IAM roles and EC2 instance profiles are
very, very soon.
So summary for RDS security.
You have encryption at rest which is done
only when you first create the database instance
and if it's by the way unencrypted,
you need to create a snapshot,
copy the snapshot to encrypt it
and then you create a new database
from the encrypted snapshot
and that will encrypt your database.
And your responsibility is to check all the ports,
IP security groups' inbound rules
for your database security group.
Or take care of all the in-database user creation
and permissions or,
as we saw from before, manage them through IAM
for MySQL and Postgres.
Create a database with or without public access
so is it going to be in a public subnet
or in a private subnet?
Ensure the parameter groups and the database
is properly configured to only allow SSL connections
so making sure encryption is happening.
And what is Amazon's Web Services' responsibility?
Well is to make sure that you don't have SSH access,
that you don't have to do database patching,
you don't have to do OS patching,
AWS will do this for you,
and you don't have a way to look at the underlying instance.
Again, that is AWS' responsibility.
So the RDS is a service offered to you
and you can leverage it or not but to me,
honestly it's one of the best service of AWS
so it makes a lot of sense to use RDS.
All right, that's it for this lecture.
I will see you in the next lecture.