MongoDB is one of the most popular open-source databases. Unfortunately, this also means ubiquity of misconfigured and unsecured MongoDB deployments out in the wild. Just in recent years, we’ve seen several hacks involving thousands of MongoDB databases left exposed online without any protection, making them ripe for the hacker’s picking. It doesn’t have to be this way, though.

To keep your business secure, it is important not only to keep the hackers from getting in but also to keep your data from getting out. Even if a malicious actor gains access to the server, for example via an SSH session, it is vital to keep the data from being exfiltrated to an unauthorized location, such as IP addresses not under your organization’s control. In considering a solution to protect against data exfiltration, it is critical to note that one policy does not fit all.

This is a guest blog post from Shuo Yang in his blog series “Transitioning to Programming the Cloud”, as a part of our blog posts focusing on Identity, Security and Access. We talked about how AWS CIP, STS and IAM can serve as the foundation of application authorization in our last post, i.e., how the application gets the temporary credential representing a specific role (i.e.