As far as protocol is concerned, if you're using TLS, a client certificate, and a strong password, sure, opening your database servers to world accessible should be fine.
The problem is that it's possible, and very likely, there are exploits in the wild for your database server -- that are known but you failed to update for a day, or are 0 day exploits -- which are exploitable without having an authenticated account. Those issues can't be exploited if you firewall your database server to known IPs, but once you make it world accessible, all bets are off.
You may be interested to know that Heroku exposes all PostgreSQL databases publically, and unless you are an enterprise customer there is no way to turn that ‘feature’ off:
How would that exploit get exploited if you have mutual TLS authentication protecting your database connection? Or are you saying it's likely that particular piece of the database infrastructure is likely to have an exploit?
Just using SSL connections doesn't cover it, for two reasons:
1. You can't force MySQL to only accept connections over SSL. You can only enable SSL, and set specific accounts to only allow SSL logins. This means that any sort of "unauthenticated attack" on MySQL will work -- if you can exploit MySQL without a valid login, enabling SSL for users won't help you.
2. Amazon RDS supports using SSL connections, and will issue your MySQL server an SSL cert from their certificate authority, so your client can validate the server. It does not, however, support client SSL certificates, for the server to validate the client. Which means the only thing SSL connection is doing for you is encrypting the connection -- it's not in any way validating the client, and anyone can download the RDS region's CA certificate and then connect/exploit your MySQL connection normally.
Yeah, if the database doesn’t support mutual tls, it is clear that wouldn’t be sufficient protection. Having a proxy in between client and server that handles this (e.g. envoy) would be a good option.
The problem with just using something like Lambda on a VPC (so you can use a traditional firewall to protect your MySQL server) is that the cold start times are 10-15 seconds, to get your local network interface and connect to the server.
You're suggesting that from the time a user makes a request to the function, the function should load up, and then create a client VPN connection to the database server, and then create a Database connection? Pretty sure that'd end up pushing towards the same cold start time. Also, no managed database provider is going to offer a VPN connection to it, so you're now definitely maintaining your own database server, when part of the point of getting into serverless is to not worry about servers.
The problem is that it's possible, and very likely, there are exploits in the wild for your database server -- that are known but you failed to update for a day, or are 0 day exploits -- which are exploitable without having an authenticated account. Those issues can't be exploited if you firewall your database server to known IPs, but once you make it world accessible, all bets are off.