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.

MySQL brands itself as the world’s most popular open source database. As popular as MySQL database is among developers and SQL enthusiasts, it is equally popular amongst hackers. Misconfigured server access, overprivileged roles, and weak authentication schemes are the most common security issues in MySQL database. While access control features provided by MySQL are adequate enough at the SQL level, it is error-prone to manage access at the operational level.