Securing MongoDB Part 4: Environmental Control & Database Management

Welcome back to the final installment of our 4-part blog series presenting the best practices and controls available in MongoDB to help you create a secure, compliant database platform.

In this concluding post, we’ll be discussing environmental control and database management.

As a quick recap, in part 1, we took a look at the general requirements for data security and regulatory compliance, and then in part 2, reviewed MongoDB access controls enforcing authentication and authorization. In part 3, we discussed auditing and encryption.

If you want to get a head-start and learn about all of these topics in one installment, just go ahead and download the MongoDB Security Architecture guide.

Environment & Processes

Building on the database security controls discussed in the previous posts, to further reduce the risk of exploitation, run MongoDB in a trusted environment, implement a secure development lifecycle, and enforce deployment best practices.

A “Defense in Depth” approach is recommended to complement secure MongoDB deployments, addressing a number of different methods for managing risk and reducing 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 the MongoDB database.

Secure environments use the following strategies to control access, with more detail available in the Network Exposure and Security section of the documentation.

• Network Filter. By using filters such as firewalls and router ACL rules, connections to MongoDB from unknown systems can be blocked.

Firewalls should limit both incoming and outgoing traffic to/from a specific port to trusted and untrusted systems. For best results and to minimize overall exposure, ensure that only traffic from trusted sources can reach mongod and mongos instances and that the mongod and mongos instances can only connect to trusted outputs. In addition, unneeded system services should be deactivated.

• Binding IP Addresses. The bind_ip setting for mongod and mongos instances limits the network interfaces on which MongoDB programs will listen for incoming connections.
• Running in VPNs. Limit MongoDB programs to non-public local networks and virtual private networks. Virtual Private Networks (VPNs) make it possible to link two networks over an encrypted and limited-access trusted network. Typically MongoDB users configure SSL rather than IPSEC protocols for performance advantages.
• Dedicated OS User Account. A user account dedicated to MongoDB should be created and used to run MongoDB executables. MongoDB should not run as the “root” user.
• File System Permissions. The servers running MongoDB should employ filesystem permissions that prevent users from accessing the data files created by MongoDB. MongoDB configuration files and the cluster keyfile should be protected to disallow access by unauthorized users.
• 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.

MongoDB also allows the administrator to configure the MongoDB server to prevent the execution of Javascript scripts. This will prevent MapReduce jobs from running, but the aggregation pipeline can be used as an alternative in many use cases.

• Physical Access Controls. In addition to the logical controls discussed above, controlling physical access to servers, storage and backup media provides critical environmental protection.

MongoDB Atlas Security

As discussed earlier in this blog series, MongoDB Atlas is a database as a service for MongoDB, providing all of the features of the database, without the operational heavy lifting required for any application.

Data security has always been a top consideration for any organization evaluating public cloud platforms for application deployment. MongoDB Atlas has been engineered to deliver robust security controls for any instance you deploy:

• IP Whitelisting. Clients are prevented from accessing the database unless their IP address has been added to the IP whitelist for your MongoDB Atlas group.
• Access Control. Authentication is enforced for all MongoDB Atlas clients via the SCRAM-SHA-1 mechanism. User and administrator roles can be defined to ensure a separation of duties between different entities accessing the database and the MongoDB Atlas service.
• End-to-End Encryption. MongoDB Atlas uses TLS/SSL to encrypt the connections to your databases. Data at rest can be protected using encrypted data volumes.

Review the MongoDB Atlas documentation for more information on configuring the in-built security controls.

Database Monitoring

Proactive monitoring of all components within an IT environment is always a best practice. System performance and availability depend on the timely detection and resolution of potential issues before they present problems to users.

From a database security perspective, monitoring is critical to identifying potential exploits in real time, thereby reducing the impact of any breach. For example, sudden peaks in the CPU and memory loads of host systems and high operations counters in the database can indicate a Denial of Service attack. MongoDB ships with a variety of tools including mongostat and mongotop that can be used to monitor your database.

The most comprehensive monitoring solution is provided by MongoDB Ops Manager, which is the simplest way to run MongoDB. Ops Manager makes it easy for operations teams to monitor, secure, back up, and scale MongoDB. Ops Manager is available with MongoDB Enterprise Advanced. MongoDB Cloud Manager is a hosted management platform for MongoDB providing many of the same capabilities as Ops Manager.

^{**Figure 1**: Ops Manager Offers Charts, Custom Dashboards & Automated Alerting}

Featuring charts, custom dashboards, and automated alerting, Ops and Cloud Manager track 100+ key database and systems health metrics including operations counters, memory and CPU utilization, replication status, open connections, queues and any node status. Cloud Manager can also alert you if any host is internet-exposed.

The metrics are securely reported to Ops Manager where they are processed, aggregated, alerted and visualized in a browser, letting administrators easily determine the health of MongoDB in real time. Views can be based on explicit permissions, so project team visibility can be restricted to their own applications, while systems administrators can monitor all MongoDB deployments across the organization.

Ops Manager allows administrators to set custom alerts when key metrics are out of range. Alerts can be configured for a range of parameters affecting individual hosts, replica sets, agents, and backup. Alerts can be sent via SMS and email or integrated into existing incident management systems such as PagerDuty and HipChat to proactively warn of potential issues before they escalate to costly outages.

Disaster Recovery: Backups & Point-in-Time Recovery

Ops Manager backups are maintained continuously, just a few seconds behind the operational system. If MongoDB experiences a failure, the most recent backup is only moments behind, minimizing exposure to data loss. Ops Manager and Cloud Manager are the only MongoDB backup solutions that offers point-in-time recovery of replica sets and cluster-wide snapshots of sharded clusters. You can restore to precisely the moment you need, quickly and safely.

Training & Consulting Services

Investing in skills can ensure a more secure environment. MongoDB University offers courses for both developers and DBAs:

• Free, web-based classes, delivered over 7 weeks, supported by lectures, homework and forums to interact with instructors and other students. Over 350,000 students have enrolled in these classes since they were first released.
• 2-day public training events held at MongoDB facilities
• Private training customized to an organization’s specific requirements - including best practices in secure development and deployment - delivered at your site.

In addition, MongoDB Global Consulting Services offers Health Checks and Production Readiness assessments, working with your team to evaluate and apply deployment best practices.

Keep up to Date

Always ensure you are running the latest production-certified release of both MongoDB and the drivers, and have applied the latest set of patches. While MongoDB Enterprise Advanced customers get access to emergency patches, fixes for security vulnerabilities are available to all MongoDB users as soon as they are released.

Wrapping Up

Its no surprise that with databases storing an organization’s most important information assets, securing them is top of mind for the business.

---

You can get started by reading the MongoDB Security Architecture guide. If you want to try them for yourself, [download MongoDB Enterprise](https://www.mongodb.com/download-center?#enterprise), free of charge for evaluation and development. MongoDB security architecture guide

---

About the Author - Mat Keep

Mat is a director within 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.