3 Ways to Keep Your RDS Instances Secure
So you’ve gone ahead and done what tens of thousands of other companies are doing, and moved your database operations into the cloud. This can be quite advantageous, freeing up your developers’ time, and facilitating patching and DB maintenance.
On the other hand, it comes with another set of problems: the complexity of AWS’ offerings can make it difficult to know whether or not you are following best practices and keeping your databases secure. Here are 3 things you should make sure you are doing in order to protect your data and database operations:
1. Check that your RDS instances aren’t publicly accessible
If you only do one thing on this list, this should be it. The public internet can be a scary place, and there is no point in having your database instances open to the world if they don’t have to be. There are plenty of bots out there automatically scanning for database ports in the hope of finding security weaknesses to compromise your data.
The solution? Implement a multi-layered security system. And the foundation of any multi-layered security system that keeps your databases safe is to make sure that your databases are not publicly accessible.
So how can you restrict access to your RDS instance? It’ll depend on your specific use case, but here are some of the most common ways to secure your RDS:
A. Remove its Public IP address. You can set up communication with your instance directly via IAM roles, which is more secure than having an open IP address and DB port.
B. Restrict access with Security Groups. This will define the inbound and outbound ports that can communicate with your RDS instance. Make sure that you’re limiting the IPs to a set of known IPs that need to have access to your DB.
C. Use a private subnet. By leveraging a private VPC (Virtual Private Cloud), you’ll keep your DB out of the public internet. VPN into your instance if you still need to access it.
2. Check that you have enabled encryption for your RDS instances
So what is the next step for setting up your multi-layered security system that protects your RDS instances? Ensuring that you are encrypting data wherever it is feasible. Securely encrypted data ensures that data that makes its way into the hands of malicious agents then cannot be read, unless they also have the encryption key.
There are a couple of different encryption types — encryption of data in transit, and at rest. In this case, we’ll be talking about encryption at rest, since that is the easiest to configure via the AWS console, though obviously leveraging encryption throughout your infrastructure is a good idea.
You can enable encryption for an RDS instance when you are creating it, or encrypt an already-created RDS instance:
Now, is encryption at this level some sort of panacea that will keep anyone from accessing your data, ever? No. However, it’s invaluable in certain cases. For instance, if someone finds a way to access your data outside of the EC2 service (such as if AWS’ premises were compromised), as long as you keep your encryption keys safe, your data will stay safe as well.
RDS does a good job of keeping the encryption under the hood — encrypting and decrypting will happen at the hypervisor layer, so you can use the RDS endpoints and AWS APIs just as you were using them before. Also, according to AWS, the impact on performance of enabling encryption on RDS instances is null to minimal. With no additional dev costs, and negligible performance costs, it just makes sense to make use of this type of encryption where you can.
3. Check that you are automatically backing up your RDS instances
Finally, keeping your data secure means protecting the integrity of said data as well. You don’t want to be in a situation where you have to apologetically tell your customers that you lost months of their data that was entrusted to you. This means backing up your data, and ensuring that the backups themselves don’t open you up to additional security vulnerabilities.
It used to be the case that backing up database instances was somewhat complicated, usually involving some crons and external data backup systems. If you’re using RDS, though, you can just make sure that automated backups are turned on for your instance.
You can either turn on automated backups when creating an instance, or edit the backup configurations for an already-existing instance.
Once you have automated backups turned on, you’ll be able to restore your DB instance to any point, down to the second, within your retention window. With a maximum retention window of 35 days, this should give your dev team some peace of mind.
Finally, you can also manually create DB snapshots. These are basically point-in-time images of the way that your database looked when the snapshot was taken. You should make sure that encryption is enabled for your snapshots, and that you are controlling access to the snapshot if it can be/will be shared (for more info about sharing snapshots, check out the AWS docs here).
Enjoyed the article? If you’re interested in AWS security, you’d probably like Beacon — a tool that lets you monitor your AWS environments’ security via Slack. You’ll be able to automatically check that all of these security best practices are in place for your infrastructure, and get an alert when they aren’t.
Save time and protect yourself from security vulnerabilities by adding Beacon to your Slack team now!
