A recent and growing trend in DevOps is the growing trend of using NoSQL databases as a way to decrease server load by moving the load bearing downstream to the client side. While this may be cost effective, it has presented a fundamental flaw time and time again in the security side of things. The most prominent example of this is MongoDB, where news broke in the tech world that more than 40’000 instances were left unsecured(http://www.information-age.com/major-security-alert-40000-mongodb-databases-left-unsecured-internet-123459001/). Not only was this damning for a company that was due to IPO (its stock price was left relatively unscathed), but it left many DevOps scratching their heads as to how this was possible.

Since this time it has become apparent that the issue of security was not due to MongoDB having huge security problems, but in the user not knowing how to secure a NoSQL database properly. For this issue, I’ve compiled a short list of ways to secure a NoSQL database, assuring that most of the time it is user error more than a fundamental flaw in NoSQL.

NoSQL databases by design are meant to be secure. They present the hacker with a large degree of difficulty to leverage administrative level access of huge swathes of the database. For a hacker to successfully obtain administrative permissions, they would soon find that with the clustering of database instances, they would be unable to compromise large datasets by nature of NoSQL database structure.

Apache Hadoop now can track changes made in the database with timestamps, which was implemented in version 2.6. What was also the most prominent example of new security measures being added for NoSQL databases was at-rest encryption by way of introducing encryption zones within clusters, to prevent data from being moved around. In this way, the hacker would be taking out small pieces of data instead of a full set, akin to counting through skittles to get multiples of the same flavour.

The most obvious way to secure a NoSQL database is to use an authentication system to enforce access to the system from outside sources. MongoDB uses LDAP to combat this, and once it is set up it adds an extra layer of protection between sources. Hadoop by design is quite trusting, so enforcing rules can become a bit trickier. Using a Kerberos server as an intermediary with your repository is one way to go about it, but Hadoop is notoriously difficult to break that trust for securing data.

Whatever the case, even if a NoSQL database does experience a security threat, it’s important to recognise that no database is completely secure. The advantage of using a NoSQL database is not only in the security side, but if a hack does occur that the hacker will have their work cut out for them to obtain large swathes of meaningful data. With that comes a steep price for breaching, as the work wouldn’t be worth the risk.