A managed database is still a database on a network, and Amazon RDS gives you two settings that decide whether the internet can reach it. Publicly accessible controls whether a public address is assigned. The security group decides who may connect. Get both wrong and your customer data is one password away from anybody, which is the kind of finding the ICO takes a close interest in after the event.
How instances end up public
Almost always through a shortcut that made sense at the time. A developer needs to connect a local tool during a migration, so the instance is created in a public subnet with public accessibility enabled and a security group allowing their office address. The migration finishes, the office moves, and the rule is widened to any address because someone was working from home. Copies compound it: restoring a production snapshot into a test account often recreates the public setting, and the test copy holds the same personal data as production with none of the monitoring.
What a tester checks beyond the network
Reachability is the first question and not the only one. We look at whether the master username is still the default, since that removes half of the guessing work for anyone attempting a password attack. We check whether transport encryption is enforced rather than merely available, because most engines accept unencrypted connections unless a parameter forces otherwise. Encryption at rest matters for snapshot handling, and snapshot sharing settings matter more than people expect: a snapshot marked public can be restored by anyone with an AWS account, which is a data breach that leaves no trace in your own environment.
“The database finding that actually gets exploited is rarely the one on the internet, because most teams close that within a day of being told. It is the test copy in a sandbox account with production data, no monitoring and a password from a wiki page. If you refresh test databases from live, treat those accounts as production, or stop refreshing them from live.”
William Fieldhouse, Director, Aardwolf Security Ltd
Access that does not rely on a password
Move authentication to IAM where the engine supports it, and the standing password problem disappears. IAM database authentication issues a short-lived token, which removes the credential from configuration files and makes access revocable in the console rather than through a schema change. Where the application must use a password, keep it in Secrets Manager with automatic rotation, and give the application role permission to read only that secret. Then check what else in the account can read it, since a broadly scoped secretsmanager:GetSecretValue permission quietly undoes the whole arrangement.
Making the fix stick
Prevent the setting rather than correcting it repeatedly. A service control policy that denies creation of publicly accessible instances stops the shortcut at source, and AWS Config rules will flag anything that slips through a different route. Put the instances in private subnets and reach them through a bastion or session manager, which removes the need for a public address entirely. AWS cloud security testingwill confirm the current position and, more usefully, show which internal roles can still reach the data, while scheduled vulnerability scanningcovers the engine versions that support the platform.
Frequently asked questions about RDS security
These questions come up whenever a cloud database review is booked.
Does AWS patch the database for you?
It applies engine patches during your maintenance window when you allow automatic minor upgrades. Major versions and the timing remain your decision, and deferring them repeatedly is how instances end up years behind.
Is a private subnet enough on its own?
It removes internet exposure and leaves everything inside the account able to reach the instance. Pair it with tight security groups so only the application tier can connect, then test that from a different subnet.
