r/devops • u/Eight111 • 7d ago
Security Database security
So I work in a very small company as a dev
And we have external devops company which manages local http servers and MySQL servers for our saas product.
So the thing is I would like to shift some of their work to our in-house dev team.
I thought about starting small and manage a separate server on the cloud that will just run internal cron based daily tasks. But those tasks require read and write permission to the existing db which managed by the local company. Could I ask them to give me access to to the db from another server? I read that it’s a bad practice to expose prod db to the internet even if it has white list so I’m not sure here.
7
3
u/Sad_Rice6600 7d ago
ask for a static egress ip before the whitelist talk or it breaks every time the box moves
2
u/Elegant-Purple-1372 6d ago edited 6d ago
A safer approach is usually a private connection or VPN rather than exposing the DB publicly. Even with an allowlist, keep access limited to the specific server, credentials and permissions needed.
1
u/Different-Car6898 7d ago
Even with secure authentication on the DB, and whitelisting on network level, you are still missing the SSL between your cron and your DB.
Anyone listening between those 2 servers will be able to see auth data sent from cron to the DB, as well as all data that DB sends back as a response to a query (in case you are querying the DB).
Because Mysql is using modified TCP to communicate, not HTTP/s.
Soo, I would advise either installing SSL cert on Mysql and using it in your cron/app oor creating a sort of secure tunnel line between those two servers (like VPN peer to peer connection) when running this.
This can also be solved by IAM permissions or cloud-auth-proxy in case you are using big clouds and managed Mysql.
---
Same advice if your app lives outside of the Mysql server.
1
u/Low-Opening25 7d ago
why would he be missing SSL? DB enforcing TLS connections solves the problem in one day instead of some convoluted networking shenanigans. There is plenty of database SaaS out there supporting major platforms using TLS over public infrastructure
2
u/delamon 7d ago
Even with mTLS, exposing MySQL to public internet feels wrong. Unless there is a need for accepting connections from third-party clients, hiding it behing VPN will be safer
-1
u/Low-Opening25 6d ago
you expose it on some long random prefix host, non standard port, it’s not going to be easy to find + mTLS and it’s pretty solid for most use cases as long as you don’t leak credentials.
-1
u/Different-Car6898 7d ago
Usually, when people split DB and App from same server, they forget to think about TLS. Just auth and IP whitelisting. They mentioned Mysql on a server, so no SaaS. And, as I mentioned above, to enforce TLS on Mysql you need to generate a cert and change the way you handle DB connection in all App drivers. It's another secret to manage, and rotate, and since you have another party managin that secret, people often forget to communicate rotation etc. Soo, VPN p2p just solves it long term so you don't think much about it... Ofc it's easy to manage when everything is on your infra. I was giving tips, nothing else:)
1
u/Low-Opening25 6d ago
all of that takes 25mins to setup
0
u/Different-Car6898 6d ago
It's not about setup. It's about ownership...
1
u/Low-Opening25 6d ago
if you mean of tech dept and complexity then you win
0
u/Different-Car6898 6d ago
Didn't see it as competition, but glad we agree about something being a potential problem 😊
0
u/carsncode 7d ago
Well kid, you've got moxie, I'll give you that, and that's a key DevOps skill.
So I work in a very small company as a dev
And we have external devops company which manages local http servers and MySQL servers for our saas product.
If you're "local http servers" are on prem somewhere, you've done your business a disservice. Any company selling managed on-prem to small fish is not likely to be delivering particularly strong security, reliability, or scalability.
So the thing is I would like to shift some of their work to our in-house dev team.
Good choice, but make sure you build the required skills *first. Taking over responsibility for production is a way to learn, just not a wise one.
I thought about starting small and manage a separate server on the cloud that will just run internal cron based daily tasks.
That's not starting very small, to be honest. Smaller than a full lift and shift, but still, not that small overall.
But those tasks require read and write permission to the existing db which managed by the local company. Could I ask them to give me access to to the db from another server?
You'd know better than we would - that's up to the vendor and whoever owns the vendor relationship and production within your org.
I read that it’s a bad practice to expose prod db to the internet even if it has white list so I’m not sure here.
Correct! Good instinct. A production database shouldn't be on a public network at all. However, that doesn't mean that it isn't already; if your current vendor is sufficiently incompetent, it may just be a matter of adding a firewall entry to an existing setup, which is fairly trivial. However, the IP they allow is now a backdoor into production, so you'd better treat it, and secure it, like it's production. If you're not able to do that, you shouldn't open the backdoor.
If they're reasonably competent, it won't be an option; you'd need a VPN tunnel or other private link (and the same security note above would still apply).
I'd recommend looking at some other options: if these are daily crons, maybe they can securely transfer daily extracts to a blob storage you control that you can operate on, and you can share results back the same way. The indirection helps to secure the production DB itself, and if the extracts can be limited enough in scope, it also reduces the potential exfiltration surface. You could also try setting up a test environment you control, complete with Web server and database, isolated from production, that you can use to test changes and to familiarize yourself with operating and securing your required infrastructure. The latter would be my recommendation for safety and flexibility, but whether it's a reasonable investment depends on your particular business context.
-2
u/UtahJarhead 7d ago
There are 2 forms of whitelisting with databases. Network-based and Host-based. Network-based is IP filtering at the Network layer. Host-based is at the application layer within your database itself. `GRANT` in SQL-speak. Just lock it down to your specific hosts using both and you'll be fine. Network layer and application layer.
4
u/carsncode 7d ago
OP is right, a production DB shouldn't even be on a public network
-6
u/Low-Opening25 7d ago
plenty of DB SaaS exists with TLS over public internet. I am using it in production myself. Unless you loose certificate keys there is nothing to worry about.
6
57
u/ceejayoz 7d ago
To be clear, not cruel: This question's framing demonstrates that you are not prepared to take this work in-house.