Risks involved with publicly accessible AWS RDS databases

user_4816322 0
Viewed 1002

I've come across multiple guidelines stating that AWS RDS instances should not be configured to be publicly accessible, because it is a major security risk. Example:RDS Publicly Accessible - RDS best practice

If the RDS instance is configured with a sufficiently strong and unique password which is practically impossible to brute-force, is it still a security risk? Wouldn't a strong and unique password make the instance reasonably safe, even if it is publicly accessible?

amazon-rds amazon-web-services
4 Answers

You would still be open to brute force and other denial of service attacks.

The best practice is to have the DB server on a private subnet, and only allow known IP from the local subnet to have access, via security groups.

Some go further, and secure the VPC with network access control lists.

Its pretty easy to set up up a properly secured RDS server in this way. I would not rely on a single layer of defense if you really want to protect sensitive data.

user_54514920

It is a significant risk due to other aspect involved

  • Normally, how many time you change the DB password? I suspect not a lot
  • How easy it is to change the DB password? Shall it impact the running applications?
  • Do you properly restrict access to DB to a handful IPs ( which would limit the access surface to around the same level as a private subnet do ) - or you will just let any IP access? If that's the case, once the password is leaked, you have no protection
  • Do you / your customer value the data? Most of the time, databases are highly valued property which need adequate protection
user_38443530

Remember that by having your Database publicly accessible you are effectively removing that top layer of security you have.

Despite you having a strong password, attackers could be developing several ways of getting in (not just brute force of a password).

Even if they don't get in they could potentially stop you being able to access it through a series of attacks, whether they overwhelm the resources (CPU, Memory, Disk) or maximise total available connections or ports.

I would go as far as saying that your DB should never need directly public access, at very minimum look at using some kind of bastion host, or look at using either a Client VPN (AWS managed or OpenVPN) if you're on a tight budget (you can always turn them off when not using).

If time permits take a look at the security pillar of the Well-Architected Framework.

user_134609330

Also consider people. If somebody who knows the database password wants to alter or destroy the data, can they do it?

Let's say somebody just left your company. You could take away their VPN access or AWS credentials, but they could still access the database unless the password is changed.

Let's say a current staff member wants to do some mischief. In a properly-secured network, only the application server should be able to access the database. However, if the database was public, then the staff member could access the database and nobody would even know it was them!

It really comes down to your 'risk appetite'. If this is just for a small project then losing the data (or having the data exposed) does not have a big impact. However, if you are a big company, it might mean the end of your business if the data was lost or exposed. If the data is valuable to other people, then people will attempt to get to it. In such a case, it would be best to architect a more-secure platform.

user_1747770
Related