- put the database in a virtual private cloud (VPC), an internal network

- setup a Virtual Private Network (VPN) also placed in the same VPC from which developers can connect to to access the internal network

- setup at least two MongoDB users, one `readWrite` user that can connect from the internal network and one administrative user that can only connect from localhost

- setup a key based SSH connection only accessible from the VPN to the MongoDB instance

- setup Security Groups (firewall) to lock all the unused ports and IP origins out

That way you'll need a VPN key, an SSH key and the MongoDB admin user's access to fully compromise the database.

Understandable and reasonable. there are ways to achieve this without exposing the DB but it take some more effort.

> 3. Don't know. Never even touched the firewall.

Firewalls are good, because they add an extra layer on security. Personally I believe, there should be firewall on most servers (firewall should be the default). But firewalls aren't magic and they are just one layer.

> I have a PW on my DB and that's it. Why do I need more than that?

Because this means you have 0 margins for error. Either you PW auth works flawlessly and without bugs, or you are screwed.

Also you expose one more endpoint that can potentially be a ddos target.

So do I. So I setup all my dbs with TLS mutual auth or equivalent. Even databases that don't support TLS natively (e.g., Redis 5 and below) get a TLS/SSH port-forward setup for them at the network boundary.

> I have a PW on my DB and that's it. Why do I need more than that?

If you're not using an MITM-proof connection (e.g., TLS or SSH), and you connect to your DB from a network that has me (maybe we're in the same coffee shop, maybe I'm working in your office, or maybe I just work at an ISP between you and your server), then I have your PW.