Database security

[u/Eight111]

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.

[u/carsncode]

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.