In a recent article over at The Inquirer, Microsoft got roundly savaged for a database security leak. Apparently their third-party database operator didn’t correctly secure the backdoor to their “careers” database, leaving it open for anybody to ransack for personal information. When it was discovered (by a user), it was quickly acknowledged and remedied. So is MongoDB security any good? Short answer, of course it is.

In the back and forth, MongoDB’s database security got caught in the crossfire:

“All indications are that the database, a MongoDB instance, was not write-protected. You probably see where this is going. During the exposed timeframe an attacker could have modified the database, and thus the HTML code, of job listing pages being served through m.careersatmicrosoft.com.”*

While it’s true that MongoDB was the database system in question, and it’s true that the security was left open, it’s pretty unfair to imply that somehow this is a MongoDB problem – rather than the all-too-familiar “operator error.” MongoDB can be secured (as it currently is now in this particular instance), you just need to have someone experienced with the database system security to verify sure it is done correctly.

As MongoDB put it:

“Recently a blog post was published that claimed a user had not properly secured their instance of MongoDB and was therefore at risk. As the article explains, the potential issue is a result of how a user might configure their deployment without security enabled. There is no security issue with MongoDB – extensive security capabilities are included with MongoDB,” said Kelly Stirman, VP of Strategy at MongoDB.*

MongoDB is correct, but let’s face it: in the current real world, unfortunately, the idea of foolproof security is a unicorn. If somebody wants to get past your security badly enough, they’re most likely going to do it. Coding errors happen, patches are released, updates are recommended – the real crucible for any software is the cold, hard light of day. We expect this in the industry.

This doesn’t mean give up, however! It means be vigilant about understanding how to properly configure security settings, and making sure to monitor them consistently enough to know when malfeasance is afoot. If you’re a third-party operator running a database, you’d better know what the security settings are, and how to turn them on properly. The larger concern for anybody running software, database or otherwise, is making sure that the administrator or support is an expert on how to properly configure, maintain, and monitor it in a production environment, so as to minimize the impact of breaches. Filing fix-it tickets after the fact isn’t really a good plan (see the article in question).

MongoDB is as secure as any database option, as long as the security is correctly setup. MongoDB has a fairly comprehensive list of settings and procedures that explain how their security works.

Let’s go ahead and link to them:

Something in one of these sections most likely fixed Microsoft’s issue.

So somehow, Microsoft’s database security was left unexamined – a mistake that could be pretty fatal for a company that doesn’t have the resources that Microsoft does. If you rely on your database’s security (and performance) to run your business, you need a guarantee that the administrators can effectively solve problems and protect you from security gaffes (like not turning it on). This is where regular, expert oversight is a crucial part of any database plan. For MongoDB to work as expected, you need to have a support team that configures it correctly and monitors it regularly – and knows what to be monitoring.

This is where being a MongoDB expert comes in handy!

*Quotes taken from the original Inquirer article, here.