When Percona first published the blog MongoDB Security: Why Pay for Enterprise when Open Source Has You Covered? , I constantly referenced it. Comparing MongoDB Enterprise to Percona Server for MongoDB has become such a common topic for discussion with Percona’s current and future customers that the information contained in that blog is ingrained in my memory. However, MongoDB and Percona have both come a long way since that blog was written. Several of the recommendations are still true three years later, but some things have evolved on both the MongoDB and Percona side. The purpose of this post is to expand upon and refresh those comparisons made three years ago.
What Hasn’t Changed for MongoDB?
One thing that hasn’t changed in three years is that security is still a top priority for all organizations with regards to their database environments. In the past year alone, there have been several data leaks due to misconfigured MongoDB databases. It is important to note that these highly-publicized leaks are due to configuration issues or unsupported, out-of-date software. There is no need to fear some inherently exploitable issues with up-to-date, well-maintained, properly implemented deployments of MongoDB. In Part One of this post (this part), I will explain the security options that exist in the open source software side of MongoDB that will allow you to deploy a secure Enterprise-grade MongoDB deployment without worrying about license fees. This is important because it allows organizations the flexibility to deploy consistent models across their entire infrastructure. Too often we see customers running different versions of software in dev/test/qa due to license restrictions. With open source software, this is not a concern.
What Has Changed for MongoDB?
One thing that has changed in the past three years since that blog post was written is the explosion of growth in the Database as a Service (DBaaS) sector of database management. DBaaS is a more specific form of Platform as a Service (PaaS). MongoDB, Inc. has gone all-in on the DBaaS space, which aligns well with its continued mission to empower developers by overcoming the burden that is database management. In 2016, MongoDB Atlas went GA as MongoDB’s DBaaS offering. In 2018, MongoDB acquired a competitor in the space – MLab. The most significant change has been its switch to a new license, SSPL, which directly impacts companies offering “as a service” solutions of MongoDB. According to MongoDB’s CEO, MongoDB’s long-term strategy involves enterprise licensed software subscriptions, of which DBaaS components will be heavily integrated. So, if vendor lock-in and utilizing truly open source technology are a priority for your company, what are your options? This is an area where I will expand on Percona’s original security-centric blog post and explain what options and paths exist for users who do not want to double-down on MongoDB’s enterprise licensed toolkit.
So, the aspects that are important to running an Enterprise-grade version of MongoDB are:
- Monitoring, Diagnostics, Analytics, and Alerting
- Backups, Deployment, and Maintenance Automation
The first one to tackle is Security. Broken down further, for a database this means:
- 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. Schema 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).
- Log Redaction. Filtering what information is written to log files
MongoDB has built-in users. It misses things, however, like password complexity, age-based rotation, centralization, and identification of user roles versus service functions. This has been submitted as a feature request but is backlogged with no planned fix version. These user authentication controls are essential to passing PCI. PCI requires that people don’t use old passwords or 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). The reason that this logic has not been added at the database level is that, for the most part, another answer exists that integrates easily with MongoDB. LDAP is an open-source project of its own. Many connectors allow the use of Windows Active Directory (AD) systems to talk with LDAP.
The community version of MongoDB does not have this functionality.
A final note about authentication is Kerberos authentication. Percona Server for MongoDB has not implemented this functionality yet. It is only available in MongoDB Enterprise. Percona has not seen great interest in this feature from its customers or users of its MongoDB software.
Role-based Authorization 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 actions someone might be able to do – only exposing exactly what you want users to be able to do. This is a core MongoDB feature that is everywhere and in every build regardless of vendor.
One important differentiation in authorization toolkit between MongoDB Enterprise and Percona Server for MongoDB is LDAP authorization. This feature maps LDAP group distinguished names to MongoDB group roles and allows for easy role configuration among groups of users. This functionality is currently not Generally Available in Percona Server for MongoDB, but it is actively under development and scheduled for a 4.2 release. Because roles are a built-in feature for MongoDB, this limitation only results in additional manual steps and/or custom scripting. It is not a limitation in functionality once users are added.
Encryption at the database layer has become increasingly popular and mandatory at large organizations due to recent data compromises and breaches. Although most high-profile breaches are a result of improperly implemented or extremely out-of-date deployments, additional security measures like encryption at-rest and in-flight are always preferred. Encryption is often a requirement for any database operating under PCI or HIPAA standards.
The first aspect of encryption is in-flight or over-the-wire encryption. This ensures that network traffic is only readable by the intended client. Luckily, this is another core feature of the MongoDB code and is present in every build regardless of vendor. Percona recommends standardizing on OpenSSL as it is likely to have compatibility across open source databases and open source operating system platforms.
The second aspect of encryption is at-rest encryption. This ensures that once stored, data can only be read by the intended client. This option is available for the WiredTiger storage engine. MongoDB’s implementation requires a MongoDB Enterprise License. Luckily, Percona has you covered with an open source implementation of WiredTiger encryption in Percona Server for MongoDB. Percona’s implementation has Hashicorp Vault integration for key management and also encrypts rollback files which could contain sensitive data.
MongoDB’s concept of Schema Validation ensures that standards for storing data are defined and rigidly enforced if necessary. All versions of MongoDB have methods for enforcing format standards for data stored in the database. DBAs can check for field names based on certain criteria based on regex strings to search for SSN or CC numbers. MongoDB’s native JSON language allows for easy scripting of customized options regardless of MongoDB version as this is a core part of the MongoDB database. By enforcing rigid schemas, organizations can ensure that developers do not insert sensitive data into documents that do not belong.
The concept of auditing user activity is not foreign to anyone responsible for security. It is a critical aspect of compliance for all organizations. This is another area where Percona can offer an open source alternative to MongoDB’s Enterprise license. On the MongoDB side, this is an Enterprise-only feature that requires a license. On the Percona side, this is included as part of Percona Server for MongoDB. They are very similar in functionality and allow users to filter output to particular users, databases, collections, or sources. This allows granularity into what is audited and allows the review of logs in the event of a security incident.
Another important consideration for security with MongoDB is log redaction. Often it is necessary to remove messages from a log event before logging. This will prevent the logs from containing potentially sensitive information like PII to the diagnostic log. Metadata such as error or operation codes, line numbers, and source file names remain visible in the logs.
This is an Enterprise only feature on the MongoDB, Inc. side while Percona Server for MongoDB offers Log Redaction functionality in its open source version. It is important that while this feature increases security, it can make troubleshooting more difficult.
That wraps up Part One of this blog series. The purpose of this blog was to inform those interested in MongoDB solutions of their options with regards to selecting the appropriate MongoDB database software for their use-case. Security is an important reason why companies opt for the Enterprise version of MongoDB. However, Percona Server for MongoDB can offer most of this functionality with a non-licensed model. This means no more worrying about purchasing licenses for production, dev, test, qa, sandbox, etc. You can have consistent deployments across all environments by utilizing non-licensed, open source software all while ensuring that the security standards required by your organization are being enforced.
The chart below summarizes what we’ve covered:
In the next blog in this series, we will take a look at monitoring, diagnostics, analytics, and alerting for MongoDB and what is available in the open source community and compare that to what is available via licensing from MongoDB, Inc.
For more information, download our free white paper to learn why more and more enterprise companies are leaning in when it comes to adopting open source software (OSS). It examines the benefits of adopting open source into your database infrastructure, and how your business can benefit from having an open source product as part of your enterprise solutions.