Preparing for Your First MongoDB Deployment: Backup and Security

In the first article of this two part series, we discussed how many of the concepts, operations and processes for deploying Relational Databases can be directly applied to MongoDB, along with hardware selection and best practices for deployment and monitoring.

In this article we focus on protecting your deployment with backup tools and security policies.

MongoDB Backup and Restore

There are three common approaches to backing up a MongoDB database:

• Cloud backups with MongoDB Management Service (MMS)
• Taking file system snapshots
• Using the mongodump tool packaged with MongoDB

Backups with MongoDB Management Service (MMS)

In addition to monitoring discussed in the previous article, MMS provides a fully managed, cloud-based backup solution that is hosted in reliable, redundant and secure datacenters.

The MMS Backup agent is locally installed to the MongoDB cluster and performs an initial synchronization, before then streaming encrypted and compressed data from the MongoDB oplog (used in MongoDB replica sets) to MMS.  Snapshots are created every 6 hours.

MMS Backup is the only solution that supports point-in-time recovery for replica sets and cluster-wide snapshots of sharded clusters. Oplog data for the last 24 hours is stored and can be applied to create a custom snapshot of a replica set. For sharded clusters, the balancer is paused every 6 hours and a no-op token is inserted across all shards, mongos’ and config servers. The oplog can be applied to all replica sets in the cluster until the point in which the token was inserted, providing a consistent snapshot across the cluster.

To restore data, snapshots are sent via SCP directly to your server, or a custom URL can be generated to download them. MMS requires two-factor authentication for all restores.

For more details on the backups with MMS service, checkout the documentation page on MongoDB website.

File System Backups

File system backups, such as that provided by Linux LVM, quickly and efficiently create a consistent snapshot of the file system that can be copied for backup and restore purposes. For more information on how to use file system snapshots to create a backup of MongoDB, refer to the Backup and Restore with File System Snapshots documentation.

mongodump

mongodump is a tool bundled with MongoDB that performs a live backup of the data in MongoDB. mongodump may be used to dump an entire database, collection, or result of a query. mongodump can produce a dump of the data that reflects a single moment in time by dumping the oplog and then replaying it during mongorestore, a tool that imports content from BSON database dumps produced by mongodump. mongodump can also work against an inactive set of database files.

More information on creating backups can be found on the Backup and Restoration Strategies MongoDB Documentation page.

Security

As with all software, administrators of MongoDB must consider security and risk exposures for a MongoDB deployment. There are no magic solutions for risk mitigation, and maintaining a secure MongoDB deployment is an ongoing process.

Defense in Depth

A Defense in Depth approach is recommended for securing MongoDB deployments, and it addresses a number of different methods for managing risk and reducing risk exposure.

The intention of a Defense In Depth approach is to layer your environment to ensure there are no exploitable single points of failure that could allow an intruder or untrusted party to access the data stored in a MongoDB database. The most effective way to reduce the risk of exploitation is to run MongoDB in a trusted environment, to limit access, to follow a system of least privileges, to follow a secure development lifecycle, and to follow deployment best practices.

Any database handling sensitive information needs to offer holistic approaches to security, encompassing:

• User rights management to restrict access to sensitive data, implemented through authentication and authorization controls;
• Logging operations against the database in an audit trail;
• Data protection via encryption of data in-motion over the network and at rest in persistent storage;
• Environmental and process controls.

MongoDB 2.4 introduced a number of capabilities to address the requirements above, and MongoDB 2.6 continues to build upon those capabilities. A developer preview release of MongoDB Enterprise 2.6 is available now.

Authentication

The authentication of entities accessing MongoDB can be managed from within the database itself or via integration with external security mechanisms including Kerberos services with MongoDB Enterprise 2.4 or LDAP, Windows Active Directory and x.509 certification authorities when using MongoDB 2.6.

Authorization

MongoDB allows administrators to define the permissions an application or user has, and what data they can see when querying the database. MongoDB has a number of built-in roles, and with MongoDB 2.6, the ability to configure granular user-defined roles. For example, some users may have the right to view a record, but never to update or delete it.

MongoDB 2.6 offers field level security to manage fine grained security authorization controls to sensitive data, with the ability to define declarative security policies which are implemented at run time. By managing control at the field level, a single document describing an asset can contain data with multiple security levels, avoiding the complexity of separating information with different security levels across multiple databases.

Auditing

MongoDB 2.6 adds support for logging of administrative actions taken against the database by maintaining an audit log. For ease of use, audit logs distributed across a MongoDB cluster can be merged into a single log, enabling the association of events from a single operation that affected multiple nodes.

Encryption

MongoDB provides capabilities to encrypt data in motion over the network and at rest in permanent storage.

Support for SSL allows clients to connect to MongoDB over an encrypted channel. MongoDB supports FIPS 140-2 encryption if run in FIPS Mode with a FIPS validated Cryptographic module.

There are multiple ways to encrypting data at rest with MongoDB.  One approach is to encrypt field-level data within the application layer, using the requisite encryption type that is appropriate for the application.

Another option is to use third-party libraries such as NcryptFS and LUKS that provide disk-level encryption for Linux as part of the operating system kernel, providing advanced key management that ensures only authorized processes can access this data. For Windows platforms, technologies such as IBM Guardium Data Encryption, BitLocker Drive Encryption and TrueCrypt can also be used.

The following is a checklist of the key steps to creating a secure deployment

Query Injection

As a client program assembles a query in MongoDB, it builds a BSON object, not a string. Thus traditional SQL injection attacks should not pose a risk to the system for queries submitted as BSON objects.

However, several MongoDB operations permit the evaluation of arbitrary Javascript expressions and care should be taken to avoid malicious expressions. Fortunately most queries can be expressed in BSON and for cases where Javascript is required, it is possible to mix Javascript and BSON so that user-specified values are evaluated as values and not as code.

Conclusion

MongoDB users rely on the best practices discussed in both this and the first article to maintain the highly available, secure and scalable operations demanded by businesses today.

These and other best practices are discussed in detail in the MongoDB Operations Guide (opens a PDF document).

About the Author

Mat Keep (@matkeep) is part of the MongoDB product marketing team, responsible for building the vision, positioning and content for MongoDB’s products and services, including the analysis of market trends and customer requirements. Prior to MongoDB, Mat was director of product management at Oracle Corp. with responsibility for the MySQL database in web, telecoms, cloud and big data workloads. This followed a series of sales, business development and analyst / programmer positions with both technology vendors and end-user companies.