Sign in Subscribe
AWS

RDS Revealed? Time to Give It Some Shade!

RDS Revealed? Time to Give It Some Shade!

By: John Poulin

At Cloud Security Partners, we have audited thousands of customer AWS accounts as part of our security reviews. Across our customers, roughly 5% of the AWS Relational Database Service (RDS) instances we analyze are publicly accessible. A general rule of thumb across the security industry is that resources generally should not be directly accessible on the Internet, especially databases. More often than not, resources can be deployed behind controls, such as Load Balancers, Private Subnets, etc. In this blog post, we will be digging into Amazon RDS to understand what it means to be considered a publicly accessible resource and when this may be required. 

As part of AWS’ shared responsibility model, for Software as a Service (SaaS) products it is important to understand that while AWS is responsible for the security of the underlying infrastructure, the customer is responsible for the security of the configuration. Amazon RDS is effectively a SaaS, which suggests that the user’s responsibility is to securely configure their RDS resources. In the event of a public exploit against RDS, or a particular DBMS (such as MySQL), it is AWS’ responsibility to patch the underlying infrastructure. Even with a fully patched system, however, AWS will not protect you from credential stuffing attacks, and adversaries may still find a way to connect to your instance. 

How should RDS instances be accessible?

First and foremost, the best practice to lock down RDS instances is to place them inside a VPC and assign a restrictive Security Group. The security group should then grant access to the desired port (typically 3306, but it depends on the DBMS) to the necessary resources. This approach works best if all of the resources that communicate with the instance are also hosted in the same AWS account. Otherwise, we have to leverage VPC peering and other techniques to ensure that resources are routable across the internal AWS data centers.

Connecting from EC2 instances or Lambda

Both EC2 instances and Lambda functions can be deployed into VPCs and associated with one or more security groups – we can utilize this to our to communicate. If the RDS instance and the target application are hosted within the same VPC, it’s fairly easy to get them communicating securely.

Within the RDS security group, we can add a security group rule to open port 3306 to our entire application security group. This will ensure that the resources continue to have only private IP association.

Determine if your instances are public

To determine whether you have any publicly accessible instances, we recommend utilizing the AWS CLI. That, coupled with JQ, make this an easy check across the entire account:

aws rds describe-db-instances --profile csp-lab | jq -r ".DBInstances[] | select(.PubliclyAccessible == true)"

From the web console, you can determine if a specific database is accessible within the Connectivity & Security tab. Within this tab is an attribute “Publicly accessible” which details whether the RDS instance is configured to be publicly accessible.

Instances that are considered “Publicly accessible” have public IP addresses assigned to them. From that point, access is granted via the assigned Security Group. To further understand the access potential, it is necessary to review the security group rules.

Best Practices for RDS Connectivity

  • RDS instances should not be made publicly accessible.
    • Perform regular auditing and monitoring of all RDS instances
  • Deploy RDS instances into the same VPC as the application servers whenever possible. Utilize Security Groups to enable intranet connectivity.
  • If resources cannot be deployed into the same VPC, utilize VPC peering to enable intranet connectivity. 

Conclusion

In most cases, RDS instances should not be publicly accessible. In fact, AWS now does a great job of reducing the likelihood of resources being deployed into public subnets by automating the association between EC2 instances and RDS instances upon creation. Many legacy resources, however, are likely still configured to be accessible. Perform regular auditing and monitoring to ensure that these resources are being properly accounted for.

Cloud Security Partners works with our customers to better understand their needs and to make tailored recommendations as to how they can securely deploy cloud-based resources, such as RDS. If you have any questions or concerns, we would be happy to continue the conversation.

About the author:

John Poulin is the CTO of Cloud Security Partners and an experienced Application and Cloud Security Practitioner with over 10 years of experience in software development and security. Over his tenure, John has worked with many Fortune 500 companies and startups alike to perform secure code reviews, architecture, and design discussions, as well as threat modeling.

References

Read next