Skip to main content

Best Practices for MongoDB Security Patches

Written by Mary Gorman

At MongoDB, security is our top priority. Our security team continuously monitors for potential vulnerabilities that could impact the integrity and safety of your environments. To address these vulnerabilities, MongoDB periodically releases security patches. We strongly recommend that customers adopt these patches as soon as possible, as discussed in this recent MongoDB Blog post.

This article describes important security practices that provide multiple, overlapping layers of security controls. This is known as “defense in depth” and it is an industry-standard security practice. Defense in depth practices are always important for ongoing security, but become even more critical to have in place during the period before you are able to deploy a patch to protect against a vulnerability.

MongoDB recommends that all customers adopt defense in depth practices to strengthen the ongoing security of their environments. The guidance in this article should be followed differently, however, depending on how customers are deploying MongoDB.

Enterprise Advanced / self-managed customers - Defense in depth practices are important to protecting your data. If you are running a self-managed MongoDB deployment and cannot adopt a patch as recommended, take these specific steps:

  • Customers should confirm whether their deployment is reachable from untrusted networks and restrict access to trusted application paths, bastion hosts, or approved administrative sources only.

  • Review operational and application accounts for unnecessary privileges, shared credentials, or passwords that may need to be changed before patching is completed.

  • Confirm that authentication credentials/secrets (e.g., passwords) are unique to each account or environment, and rotated within the last 90 days. Passwords or passphrases should be at least 15 characters.

  • In practice, customers should prioritize unique passphrases, password manager use, and immediate rotation of any database user whose password is not secret, reused, or shared.

For more information, see MongoDB’s Security Checklist for Self-Managed Deployments.

Atlas customers periodically have patches rolled out to them automatically (learn about Maintenance Windows and Protected Hours, and when they apply), so customers are running the latest software including security patches. However, the following defense in depth best practices are still highly recommended for ongoing security, and are consistent with MongoDB’s Shared Responsibility Model.

  • Review whether their cluster accepts connections from broad or untrusted networks and tighten access if needed using Atlas network controls – this can be done from your Network Access page. See Configure IP Access List Entries.

  • Customers should also review any database users with broad privileges, shared credentials, or older passwords and update them as appropriate. See Configure Database Users and Configure Custom Database Roles.

  • Confirm that authentication credentials/secrets (e.g., passwords) are unique to each account or environment, and rotated within the last 90 days. Passwords or passphrases should be at least 15 characters.

  • In practice, customers should prioritize unique passphrases, password manager use, and immediate rotation of any database user whose password is not secret, reused, or shared.

Did this answer your question?