Security is a huge topic of immense importance. Ironically, it’s all too common to sacrifice security for the sake of convenience.
This is often the case when it comes to network access security: we are quick to open up network access “just for now”, but fail to close things down later. This increases the exposure surface into the protected resource (A MongoDB Atlas cluster for example) indefinitely. But it doesn’t have to be that way.
TL;DR: Use expiring network access permissions for IPs instead of permanent ones.
How to Make it Better
For a while now, Atlas had a simple measure that helps clean up temporary access grants. Instead of the network access permission lasting until you explicitly delete it, you can set it to expire automatically and get removed.
Flip the toggle at the bottom left to enforce a time limit on the access grant. Pick a time frame: 6 hours, one day, or a week - the shorter the better. Atlas will automatically clean up the entry and close the IP access after that duration elapsed.
Some might ask “But what if I want to keep it open longer?”
Here’s my cheat-sheet:
| IP Address Space | Access Type | Auto-Expire? |
|---|---|---|
| A. Private (10. …, 192.198. …) | Production Application | No |
| B. Private (10. …, 192.198. …) | Interactive | Yes! |
| C. Public IP / Block | Interactive | Yes! |
| D. Public IP / Block | Production Application | Yes! |
This cheat sheet is of the paranoid opinion “Don’t allow public IP access to Atlas.” But paranoia good for security.
Here are some supporting thoughts. They all share the following core belief:
Sacrifice convenience to gain security
With that in mind, lets talk about interactive vs. application access.
Interactive Users
An interactive user is a human running MongoDB Compass, or the shell , or program during development.
This is the danger zone. “I just need to do my job now“ motivates allowing such traffic. But tomorrow is not now anymore… better expire it. If you are the grantor (you have an Atlas role allowing you to add the network), then you can just as well grant yourself permissions again after expiration. Sacrifice convenience.
If the interactive user does not have access-control privileges, the nuisance of provisioning access is higher. But then the question arises: why is access to Atlas done over the public IP?
- No peering? Ask to set it up.
- No private-link? Ask to set it up.
- Atlas in different zone? Ask to set up peering.
- Private IP block? Expire anyway.
Why expire an interactive IP anyway? Well, because it provides another surface for would-be attackers. Interactive users have potential OS exposure to compromise via channels such as email, malware, random downloads and just plain old neglect.
For Applications
An application is a program or process running unattended.
Seek to route traffic via either peering or a private link. This would turn the traffic into non-public traffic, and therefore fall under use case #1.
Auto-Expire in Other Ways
The alternatives to auto-expiring automatically existed for a while. Shun the “I’m personally responsible so it’s ok for me to have permanent access” argument.
If the DBaaS or DB doesn’t auto expire, a good sys-admin or DevOps practice would automate tearing down old entries. Still valid: Atlas management API allow for creating and removing network access, so it’s a viable option.
Manual “expiration” entails manual auditing, and manual removal of such entries. This is both error prone and less reliable in general. But if that is all your organization is willing to do for security - so be it. Chalk that one up for “acceptable within parameters”.
Permanent Access
As you surmise by now, the approach in this post strongly shuns permanence, especially for public IP space.
What about permanence within private space? Those should also be expired! But in this case, automatic expiration is a bit trickier. A production application loosing connectivity is a risk not many would take. There can be arrangements that either audit and expire connections with no observed traffic, or which renew/ re-provision access on a cadence as long as some sign of life is detected. But such automation is a chance for error with higher risk to availability of the production application. So letting practicality win here: revert to manual auditing of such entries. Yes: they are internal traffic, but still another open vector.
Bottom line: Your data is priceless, consequences are high - keep it as safe as possible. Sacrifice convenience to gain security.