Security Checklist
Last updated: 2020-03-25
This documents provides a list of security measures that you should implement to protect your MongoDB installation. The list is not meant to be exhaustive.
Pre-production Checklist/Considerations
➤ Enable Access Control and Enforce Authentication
Enable access control and specify the authentication mechanism. You can use MongoDB's SCRAM or x.509 authentication mechanism or integrate with your existing Kerberos/LDAP infrastructure. Authentication requires that all clients and servers provide valid credentials before they can connect to the system.
See also:
➤ Configure Role-Based Access Control
- Create a user administrator first, then create additional users. Create a unique MongoDB user for each person/application that accesses the system.
Follow the principle of least privilege. Create roles that define the exact access rights required by a set of users. Then create users and assign them only the roles they need to perform their operations. A user can be a person or a client application.
NoteA user can have privileges across different databases. If a user requires privileges on multiple databases, create a single user with roles that grant applicable database privileges instead of creating the user multiple times in different databases.
See also:
➤ Encrypt Communication (TLS/SSL)
Configure MongoDB to use TLS/SSL for all incoming and outgoing connections. Use TLS/SSL to encrypt communication between
mongodandmongoscomponents of a MongoDB deployment as well as between all applications and MongoDB.Starting in version 4.0, MongoDB uses the native TLS/SSL OS libraries:
PlatformTLS/SSL LibraryWindowsSecure Channel (Schannel)Linux/BSDOpenSSLmacOSSecure TransportNoteStarting in version 4.0, MongoDB disables support for TLS 1.0 encryption on systems where TLS 1.1+ is available. For more details, see Disable TLS 1.0.
See also: Configure
mongodandmongosfor TLS/SSL.
➤ Encrypt and Protect Data
- Starting with MongoDB Enterprise 3.2, you can encrypt data in the storage layer with the WiredTiger storage engine's native Encryption at Rest.
- If you are not using WiredTiger's encryption at rest, MongoDB data should be encrypted on each host using file-system, device, or physical encryption (e.g. dm-crypt). Protect MongoDB data using file-system permissions. MongoDB data includes data files, configuration files, auditing logs, and key files.
- Collect logs to a central log store. These logs contain DB authentication attempts including source IP address.
➤ Limit Network Exposure
- Ensure that MongoDB runs in a trusted network environment and configure firewall or security groups to control inbound and outbound traffic for your MongoDB instances.
- Disable direct SSH root access.
Allow only trusted clients to access the network interfaces and ports on which MongoDB instances are available.
NoteStarting with MongoDB 3.6, MongoDB binaries,
mongodandmongos, bind tolocalhostby default. From MongoDB versions 2.6 to 3.4, only the binaries from the official MongoDB RPM (Red Hat, CentOS, Fedora Linux, and derivatives) and DEB (Debian, Ubuntu, and derivatives) packages would bind tolocalhostby default. To learn more about this change, see Localhost Binding Compatibility Changes.See also:
- Network and Configuration Hardening
- the
net.bindIpconfiguration setting - the
security.clusterIpSourceWhitelistconfiguration setting - the authenticationRestrictions field to the
db.createUser()command to specify a per-user IP whitelist.
➤ Audit System Activity
Track access and changes to database configurations and data. MongoDB Enterprise includes a system auditing facility that can record system events (e.g. user operations, connection events) on a MongoDB instance. These audit records permit forensic analysis and allow administrators to verify proper controls. You can set up filters to record specific events, such as authentication events.
See also:
➤ Run MongoDB with a Dedicated User
Run MongoDB processes with a dedicated operating system user account. Ensure that the account has permissions to access data but no unnecessary permissions.
See also: Install MongoDB
➤ Run MongoDB with Secure Configuration Options
- MongoDB supports the execution of JavaScript code for certain
server-side operations:
mapReduce,$where,$accumulator, and$function. If you do not use these operations, disable server-side scripting by using the--noscriptingoption on the command line. Keep input validation enabled. MongoDB enables input validation by default through the
net.wireObjectChecksetting. This ensures that all documents stored by themongodinstance are valid BSON.See also: Network and Configuration Hardening
➤ Request a Security Technical Implementation Guide (where applicable)
- The Security Technical Implementation Guide (STIG) contains security guidelines for deployments within the United States Department of Defense. MongoDB Inc. provides its STIG, upon request, for situations where it is required. Please request a copy for more information.
➤ Consider Security Standards Compliance
- For applications requiring HIPAA or PCI-DSS compliance, please refer to the MongoDB Security Reference Architecture to learn more about how you can use the key security capabilities to build compliant application infrastructure.
Periodic/Ongoing Production Checks
- Periodically check for MongoDB Product CVE and upgrade your products .
- Consult the MongoDB end of life dates and upgrade your MongoDB installation. In general, try to stay on the latest version.
Ensure that your information security management system policies and procedures extend to your MongoDB installation, including performing the following:
- Periodically apply patches to your machine and review guidelines.
- Review policy/procedure changes, especially changes to your network rules to prevent inadvertent MongoDB exposure to the Internet.
- Review MongoDB database users and periodically rotate them.