Best Practices for MongoDB Security

When it comes to managing database systems, one crucial aspect is database security. The failure to lay a good foundation for security for any database system may result in a data breach whereby a third-party intruder will have unauthorized access to it. Consequently, events like this may lead to brand reputation damage, fines and penalties for non-compliance, compromised intellectual property, or even result in the business closing.

MongoDB – the most popular NoSQL database — provides a range of tools, controls, and measures formulated to provide a foundation for the three pillars of information security — confidentiality, integrity, and availability. Data security is most often compromised at the confidentiality level due to greater usability and access.

What Types of Data Should You Protect

Like other databases, MongoDB involves two types of data:

1. Data at rest — This is data stored in the file system disk.
2. Data in transit — This involves data moving through a network, for example, between the database and an application.

In order to protect your data within any database, your security measures must address:

• Data in the database files.
• Applications associated with the database.
• The computing and network infrastructure used to access the database.
• The physical database server and the underlying hardware.

MongoDB Security Checklist

Before setting up your MongoDB production deployment, there is a minimum standard of security to consider to ensure your deployment will be secure. Check out the following MongoDB security checklist to

1. Specify the authentication mechanism by enabling the access control. Before allowing access to the database, it is essential to verify user identity. MongoDB supports two mechanisms in this case: the first one is Salted Challenge Response Authentication Mechanism (SCRAM) which is the default authentication mechanism in MongoDB. It verifies supplied credentials (username and password) against the authentication database, and X.509 Certificate Authentication is used for both client authentication and internal authentication of replica set members and sharded clusters.

2. Establish role-based access control. Every application or person having access to the database should have a unique identity created by the user administrator. Define roles with exact access rights and assign them to users who need to perform the operations.

3. Communication between mongod, mongos, applications, and MongoDB should be encrypted. The encryption is achieved through TLS/SSL configuration.

4. Data protection. If using the WiredTiger storage engine for data at rest, you can encrypt the data using encryption at rest. If using a different storage engine, encrypt the data using the file-system, physical or device encryption, and add the file-system permissions. Further, you can encrypt fields within documents with the Client-Side Field-level encryption before passing data from the server.

5. Secure network of operation. MongoDB should run on a trusted network environment such that only trusted clients can have access to the network interface and ports. You can achieve this by disabling direct SSH root access and configuring the setup with security groups for inbound and outbound traffic to the MongoDB instances.

6. Audit system activities. Keeping track of user access activities to the database is very important. The audit allows administrators to exercise proper controls and permit proper forensic analysis. Some auditing facilities like the MongoDB Enterprise provide filters for specific events such as authentication events to reduce data that needs to be analyzed.

7. Enable secure configuration options when running MongoDB. It is advisable to limit the usage of JavaScript code supported by MongoDB such as mapReduce, $where, and  $function. You can completely disable these options using the –noscripting option. Validate input fields using modules such as mongoose. Additionally, you can use net.writeObjectCheck to ensure all documents stored by the mongod instance are valid BSON.

8. Run MongoDB with a dedicated user. It is not worthwhile to run MongoDB on an operating system that can be accessed by multiple users. To be on the safe side, MongoDB should be run by a dedicated system user account that has permissions to access data but not unnecessary permissions that may compromise data integrity.

Poor MongoDB Security Practices to Avoid

Recently, there has been an increase in database hacking incidents, especially MongoDB. This is not because MongoDB does not meet the standards to address security concerns but rather due to the failure of developers to follow security best practices. 

MongoDB is an open-source DBMS which means some developers might know the ins and outs more than others. This does not always mean your database is at risk of external intrusion unless you fall into any of the following mistakes:

1. Using the default ports. There is nothing wrong with using the default ports (27017 and 27018), but you might sometimes forget to set the security groups responsible for managing traffic into your system. Hackers will always try accessing the database with default ports first before trying something else. You can run MongoDB on a different port with the port option i.e $mongo –port 23456. However, the recommended way is to change the configuration in the /etc/mongod.conf file by editing the line below with your preferred port number:

   net:
   	port:27017

   MongoDB, by default, runs without authentication, which has often been an issue for new deployments that go into production. Failure to enable authentication means that anyone can access the database with ease. Always create a user with role-based access permissions to interact with the MongoDB database.

2. Improper user credentials storage. Some developers hard code the username and password credentials into the project, and when they make them public, anyone can have access to them hence making the database vulnerable. 

3. Failure to limit database access to known network devices. In this case, one should always limit database access to only know applications and load balancers through a whitelist. This limits the availability of the database to unknown networks that could pose a security threat.

4. Avoiding SSL usage. SSL authentication is very crucial in ensuring that only trusted connections make it to the database.

5. Failure to use LDAP for password rotations. LDAP ties users to a corporate directory such that when their role changes or they leave the company, the changes automatically apply to the database group. This ensures that their access to data will be limited to the role they have been reassigned to or completely limited if they leave the company.

Hardening Network infrastructure

Many times, security threats start at the network exposure level because this is the most easily accessible part to most hackers. Besides ensuring only trusted hosts have access to MongoDB, you can enhance security through network hardening. Network hardening involves two procedures in regards to MongoDB:

1. Firewalls. Firewalls are used to limit incoming traffic from untrusted hosts that would otherwise expose the MongoDB database to external intrusion. For Windows operating systems, netsh command line interface provides access to the Windows Firewall. On Linux systems, iptables interface provides access to the underlying netfilter firewall. The firewall will filter out untrusted hosts and ensure only traffic from trusted sources can reach mongod & mongos besides creating a connection with the trusted outputs.

2. Virtual Private Networks (VPNs). VPNs enable two networks to link over an encrypted and limited access trusted network. They do so by providing for certificate validation and a choice of encryption protocols that may require a rigorous level of authentication and all clients’ identification. VPNs provide a secure tunnel; hence connections created to the MongoDB instance using VPNs can prevent tampering and man-in-the-middle attacks.

Wrapping Up

As with all open-source databases, security should be a top priority for your MongoDB infrastructure. Deploying your MongoDB database with default settings is a clear path towards a security disaster. Therefore, it’s crucial to fully understand how security within MongoDB works and follow all best practices to ensure maximum security. Most importantly, auditing user activities, such as authentication, provides a window into identifying loopholes and planning for the future before disaster strikes. 

Tools like ClusterControl help you take the guesswork out of database security and ensure that your MongoDB deployments will always follow the respective security model. With ClusterControl, you can easily configure your databases, access controls, and encryption for data at rest and in transit. If you haven’t already, download ClusterControl today and start your free 30-day trial to see how ClusterControl can help you manage and improve the security of your MongoDB database.