Does ensuring MongoDB security justify the cost of the Enterpriseversion? In my opinion, the answer is no.
MongoDBInc blasted anemail with astudyshowingthat the average cost of a data breach can be $5.9M. You can find the key finding in IBM’s 2015 report here:
NH Learning Solutions
Key findings:
Data breaches cost the most in the US and Germany and the lowest in Brazil and India. The average per capita cost of a data breach is $217 in the US and $211 in Germany. The lowest cost is in Brazil ($78) and India ($56). The average total organizational cost in the US is $6.5 million and in Germany $4.9 million . The lowest organizational cost is in Brazil ($1.8 million) and India ($1.5 million).
So it might be even worse than you thought! The study presented a clear per-record cost, which helps companies determine the real cost to them. Thisbrings us to the recently-published MongoDB Security Architecture white paper . While being a great document, it raises somequestions that should be addressed. We should dissectexactly what paying for an enterprise build gets you that is not already available in the open source community version.
The key security features in above white paper are:
Authentication .LDAP Authentication centralizes things with your company directory (for PCI) Authorization . What role-based access controls the database provides Encryption .Broken into “At-Rest” and “In-Transit” as part of regular PCI requirements Governance .Document validation and even checking for sensitive data such as an SSN or birth data Auditing .The ability to see who did what in the database (also required for PCI).That list lets us break down each into why they are important, and is it something that should be free in the MongoDB ecosystem.
AuthenticationMongoDB has built-in users (off by default). It misses things, however, like password complexity , age-based rotation , centralization , and identification of user roles versus service functions. These are essential to passing PCI. PCI requires that people don’t use old passwords, easy-to-break passwords, and that user access gets revoked when there is a change in status (such as leaving a department or the company). Thankfully LDAP is an open-source projectof its own. Many connectors allow the use of windowsActive Directory (AD) systems to talk with LDAP.
Using LDAP and AD, you can tie users in with your corporate directory. When they change roles or leave the company, they can be removed by HR from your database group. Practically, this means there are automated systems in place to ensure only those you want to access the data manually can do so, without accidently missing something. It is important to note that the MongoDB Community Edition does not have LDAP support. For this you need MongoDB Inc’s Enterprise build. You can also use Percona Server for MongoDB . Percona’s build is open source and free, and we offer a support contract so that if you require support or help it is available.
AuthorizationRole-based Authorization or (RBAC) is core to MongoDB Community , MongoDB Enterprise and Percona Server for MongoDB . In Mongo 2.6+ you can use built-in roles, or even craft your own down to what actionssomeone might be able to do only exposing exactly what you want users to be able to do with razor precision. This is such a core MongoDB feature that it is everywhere and in every build regardless of vendor.
EncryptionAs I mentioned before, this is broken into two areas of discussion: At-Rest and In-Transit
At-Rest.:This is defined as on-disk, and typically refers to data saved to an encrypted storage location. This is to prevent theft by physical means and create backups that are stored in a fashion not easily read by any third party. There are practical limits to this. The biggest are trusting your sys-admins and assuming that a hacker has not been able to get access to the system to pretend they are one of your admins. This is not an issue unique to MongoDB or Percona. Such systems used more globally work here as well. They might include things like LUKS/cryptfs, or might go into even more secure methods such as signing encryption keys with LDAP, Smart Cards, and RSA type tokens.
When doing this level of encryption, you need to consider things like automounting and decrypting of drives. However, the general point is this is not something new to your system administrators, and they can manage this requirement in the same way they manage it in other parts of the system. The added benefit is a single procedure for storage encryption, not one per whatever technology a particular function uses.
In-Transit.:To keep this simple, we are just talking about using SSL on all connections (it can be as simple as that in the end). Depending on your internal requirements, and Percona Server for MongoDB all additionally support custom Signing Authorities (CA),x509 clients and member certificates. The x509 system is very useful when you want to make sure only authorized machines are allowed to talk to your system because they can even attempt to send a user/password to the system.
GovernancePut simply; this is the ability to enforce complex standards on the system by using Document Validation . This is an important feature that is available to MongoDB Community , MongoDB Enterprise and Percona Server for MongoDB . Governance is about the insertion and updating of data. It is also useful for checking ifa field name like bday, birthday, ssn, social, ect is defined. We are not limited to those: you could also do string regex’s on things like user_id to check for a $regex such as “^d{3}-d{2}-d{4}$” (which would be a Social Security Number), or a checking for a credit card number. These examples are ways your DBAs and security architects can help prevent developers from exposing the company to added risk.
You can also ensure schema changes only occur when properly vetted by your DBA staff, as the developer code could fail if they change the format of what you’re storing in the database. This brings an additional layer of control to MongoDB’s dynamic production schema (allowing it