In order to reduce your attack surface as much as possible, you need to ensure that your RDS instances are only accessible by internal IPs. To do this, there are important configuration options during database setup that will allow you to define how much access is given into your databases. In this demo, AWS expert Mike Wise will walk through these configuration options and also take a look at security groups in association with VPCs and how that plays into database access control. 

For a visual guide on how to ensure RDS instances are only accessible by internal IPs, watch the full demo. To learn more about using RDS with VPCs, read here. 

Hello everyone! Welcome to today’s demo. Today, we’re going to talk about RDS, access into RDS, and some best practices for accessing the RDS. Let’s start off with the baseline of what RDS is. RDS is Amazon’s Managed Relational Database Service. Basically, it’s a managed data store that is very prevalent within Amazon; it’s probably one of Amazon’s most used services. It allows you to use a pick a different database engine, so you could use MySQL, PostgreSQL, etc. as your relational database store. 

When you’re setting up the databases, there’s a couple different configuration options that allow you to define how access is given into the environment. One of the important things is making sure that you’re only accessing these databases via internal IPs and not using an externally facing interface. The “why” for that is that you want to reduce the attack surface as much as possible. By making sure that only internal IP addresses can access this database, you put another layer of protection around the database in terms of access controls. 

We’re going to walk through a couple different things. One, we’re going to walk through a couple different things you need to look for during the database setup to make sure you’re not granting external access. Two, we’re going to be looking at security groups in association with VPCs and how that plays into external access to your database. 

When you log in to your AWS Management Console, you’re going to be presented with this screen. We’re going to search for “RDS” in the search bar, click on “RDS,” and this will take us to the RDS management screen. Let’s click on “Databases.” As you can see, we already have a database set up here. Before we go look at that database and how it’s configured, we’re going to look at the “Create Database” process so I can point out a very specific option that you need to pay attention to when you are creating your database. If we go to the “Create Database” screen, you can see that there’s a bunch of different options here, but the part that we’re going to be looking at in this demo is the “Connectivity” box. In the “Connectivity” box, there’s this “Public Access” section. There’s two ways you can set up RDS via this “Public Access” checkbox. You can either give it public access, which means that you will have an externally accessible IP address that’s going to be assigned to the instance and that instances outside of your VPC cannot connect to your database. Then you also have the “No” option. You can see that it defaults to “No” because Amazon best practices say not to assign an external IP address to your RDS instance. The “No” option will not assign a public IP address to the database. Only Amazon EC2 instances and devices inside the VPC can connect to your database. Basically, it’s saying that only internal instances and things within the VPC can hit the database, which provides that extra layer of security. When you’re setting up the database, it’s really important to make sure that you don’t check this “Yes” option unless you have a specific use case for it. You need to use this “No” piece for the additional layer of security that it will allow you. Within most things, you’re able to have some type of proxy that will do the interfacing with the AWS database and returning information through that proxy back to you. 

Now, let’s go look at the database itself. We’re going to go back to RDS management screen and click “Databases.” We’re going to look at this database that I’ve set up specifically for this demo and some things you’re going to look for to see if your already-created databases are externally accessible. Let’s go ahead and look at this. When you’re presented with this screen, it has a lot of really important information. It’s going to be talking about the connectivity and security of your database. You’ll have “Endpoint and Port” section. You’ll have “Networking” which will have this important piece (the VPC ID), you’ll have the subnet group and the subnets that is it attached to. You’re going to see the security group that it’s attached to. The key piece here is the “Public Accessibility” section. As you can see for this demo, I set up this database to be publicly accessible. That means that it’s going to get that external IP address and that it will be publicly accessible via the Internet. 

There is another layer on top of this, which is the security group. Let’s go look at the security group that’s attached to this to see how it layers on top of each other. We’re going to go to the AWS Management Console, click on “EC2,” and click on “Security Groups.” We have this security group called “rdsvpc” – one of the important things that I always do when I create a security group is to make sure I give it a description, so I know what the security group is for. This one is obviously specifically for RDS. Let’s go take a look at it. We have this “Inbound rules” section which identifies what is going to be able to access our database. In this case, there’s at least some kind of control there where we’re only allowing one IP access into the database and it’s giving it a specific port range (which is port 3306). When you are giving that public access, it layers security groups on top of it to make sure there’s the ability to restrict access. The best practice is going to be to not assign public access at all. Make sure that it’s only accessible via internal instances and make sure that public accessibility is set to “No.” Thank you for joining and have a great day!