Securing MongoDB Part 4: Environmental Control and Database Management
Securing MongoDB Part 4: Environmental Control and 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.
Join the DZone community and get the full member experience.Join For Free
Built by the engineers behind Netezza and the technology behind Amazon Redshift, AnzoGraph™ is a native, Massively Parallel Processing (MPP) distributed Graph OLAP (GOLAP) database that executes queries more than 100x faster than other vendors.
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.
- Physical Access Controls. In addition to the logical controls discussed above, controlling physical access to servers, storage, and backup media provides critical environmental protection.
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 offer 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.
It's no surprise that with databases storing an organization’s most important information assets, securing them is top of mind for the business.
Published at DZone with permission of Mat Keep , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.