Hacker News new | ask | show | jobs
by sakopov 1058 days ago
Doesn't matter. The database still is on a public subnet on customer's network. All it takes is for someone to jack up some kind of white list or access rule and the entire database is exposed. It's an attack vector. You can't do this nearly as easily when the database is in a private subnet w/ no access to internet.
3 comments

I mostly agree, but do want to emphasize that it really depends and there are multiple ways to secure this that range in complexity and maintenance overhead.

The top thing that comes to mind is creating a separate ‘read replica’ DB that logically replicates target table(s) from the source DB, creates a materialized view with a subset of the replicated data in the replica db, and then exposes only the materialized view to a specific 3rd party user.

That way you:

1) Run your primary db in a private subnet — addressing your concern with ip whitelisting

2) Run the replica in a public subnet with extremely limited access(ip-whitelisting and limited access controls to data).

This is definitely a more complex setup to reason about and creates more moving parts that can fall out of sync, but it does greatly decrease the blast radius of a breach, and for some orgs, that may be a worthwhile trade-off. In my opinion, the OP would probably benefit from some basic security walkthroughs on these different implementations to help engineering teams get onboarded/make a better case for their solution if they hit friction with legal or security teams.

All it takes is someone to both “Jack up some kind of whitelist” and leak their production database credentials.

Your private IP database isn’t unhackable either. A simple phishing attack can probably get someone’s VPN creds a nonzero percentage of the time.

I believe the alternative is a VPN, secure tunnel, authenticated proxy, or similar. Those also have accidental failure modes that would permit access to the DB regardless of which subnet it's in. I'd consider each of those as a second factor, in addition to the DB password.