The essential guide to MongoDB security

MongoDB security is in the news again. A recent spate of stories reveals how hackers have been seizing MongoDB databases and ransoming the data for bitcoins. Tens of thousands of MongoDB installations have been compromised, according to Rapid7.

We all worry about security. If you run applications, networks, or databases, security is always a top-line issue. With more companies turning to open source software such as MongoDB to store important enterprise data, security becomes an even bigger question. Depending on your business, you might also have multiple government (such as the Health Insurance Portability and Accountability Act, or HIPAA) or business (Payment Card Industry Data Security Standard, or PCI DSS) network security regulatory standards with which you need to comply.

Is MongoDB database software secure? Does it meet these standards? The short answer: Yes it is, and yes it does! It’s simply a matter of knowing how to set up, configure, and work with your particular installation.

In this article, I’m going to address MongoDB security. MongoDB is safe to use -- if you know what to look for and how to configure it.

First of all, how do people go wrong with MongoDB security? There are several key areas that trip up users when it comes to MongoDB security:

• Using the default ports
• Not enabling authentication immediately (the biggest issue!)
• When using authentication, giving everyone broad access
• Not using LDAP to force password rotations
• Not forcing SSL usage on the database
• Not limiting database access to known network devices (application hosts, load balancers, and so on)
• Not limiting which network is listening (however this no longer affects any supported versions)

MongoDB has five core security areas:

• Authentication. LDAP Authentication centralizes items in your company directory.
• Authorization. Authorization defines what role-based access controls the database provides.
• Encryption. Encryption can be broken into At-Rest and In-Transit. Encryption is critical to securing MongoDB.
• Auditing. Auditing refers to the ability to see who did what in the database.
• Governance. Governance refers to document validation and checking for sensitive data (such as an account number, password, Social Security number, or birth date). This refers to both knowing where sensitive data is stored and preventing sensitive data from being introduced into the system.

LDAP authentication

MongoDB has built-in user roles and turns them off by default. However, it misses items like password complexity, age-based rotation, and centralization and identification of user roles versus service functions. These are essential to passing regulations such as PCI DSS compliance. For example, PCI DSS prohibits the use of old passwords and easy-to-break passwords and requires changes to user access whenever status changes (for example, when the user leaves a department or the company).

Thankfully, LDAP can be used to fill many of these gaps. Many connectors allow the use of Windows Active Directory (AD) systems to talk with LDAP.

Note: LDAP support is only available in MongoDB Enterprise. It’s not in the Community version. It is available in other open source versions of MongoDB such as Percona Server for MongoDB. 

MongoDB 3.2 stores users in LDAP, but not roles (these are currently stored on the individual machines). MongoDB 3.4 Enterprise should introduce the ability to store roles in LDAP for centralized access. (We’ll discuss roles later.)

Percona

Utilizing LDAP and AD, you can tie users in with your corporate directory. When they change roles or leave the company, they can be removed by human resources from your database group. Thus, you have an automated system in place to ensure only those you want to access the data manually can do so, without accidentally missing something.

LDAP in Mongo is actually easy. MongoDB has a special command to tell it to check the external LDAP database: $external.

Some other caveats for using LDAP:

• Create a user with .createUser as you normally would, but be sure to go with db/collection resource tags.
• In addition, LDAP authentication requires two more fields:
  • mechanism: “PLAIN”
  • digestPassword: false

Custom roles

Role-based access control (RBAC) is core to MongoDB. Built-in roles have been available in MongoDB since version 2.6. You can even craft your own, right down to the specific actions a particular user might be allowed to do. This allows you to define what a particular user can do or see with razor precision. This is a core MongoDB feature that it is available in nearly every vendor’s version of the open source software.

The five main built-in MongoDB roles you should be aware of:

• read:
  • Read-only access, typically given to most users
• readWrite:
  • readWrite access allows editing data
  • readWrite includes read
• dbOwner:
  • Includes readWrite, dbAdmin, userAdmin (for the database). userAdmin means adding or removing users, granting privileges to users, and creating roles. These privileges are assigned only to the specific database server.
• dbAdminAnyDatabase:
  • Creates dbAdmin on all databases, but doesn’t allow user administration (to create or remove users, for example). You can create indexes, call compactions, and more. This doesn’t provide sharding access.
• root:
  • This is a superuser, but with limits
  • It can do most things, but not all:
    • Unable to change system collection
    • Some commands are still not available to this role, depending on the version. For example, the MongoDB 3.2 root role doesn’t allow you to change the oplog or profiler size, and the MongoDB 3.4 root role doesn’t allow you to read the current views.

Wildcarding databases and collections

Wildcarding means granting permissions to large groups of databases or collections (or all of them) on a server. With a null value, you can specify all databases or collections and avoid the dbAdminAnyDatabase role. This allows specific users to have all the privileges, including administration functions.

This is dangerous.

When you use wildcards, you grant a lot of special privileges, and you should be aware that you are opening up possible avenues of attack:

• readWriteAnyDatabase is extremely wide and exposes user names and roles to a potential attack via the application user
• Using wildcards means you won’t limit specific applications to specific databases
• Wildcarding prevents you from using multitenancy with multiple databases
• New databases aren’t automatically granted access

Creating a custom role

The power of MongoDB roles comes from creating custom roles. In a custom role, you can specify that any action on any resource can be specified for a specific user. With this level of granularity, you can deeply control who can do what in your MongoDB environment.

When it comes to specifying a custom role, there are four distinct types of resources:

• db. Specifies a database. You can use a string for a name, or “” for “any” (no wildcarding).
• collection. Specifies a collection of documents. You can use a string for a name or “” for “any” (no wildcarding).
• cluster. Specifies a sharded cluster or other metadata resources. It is a Boolean value of true/false.
• anyResource. Specifies access to anything, anywhere. It is a Boolean value of true/false.

Any role can inherit the properties of another role. There is an array called “roles,” and you can drop a new role in the array. It will inherit the properties of the specified role.

Use createRole to add a role to the array.

You can add new or existing databases to a user or a role. For example, you could add read and write access to a database by appending the database to a role.

Use the grantPrivilegesToRole command to add new resources to an existing role.

Below is an example of creating a new Super user role. The purpose of this role, again, is to have one user that is in no way restricted in the MongoDB environment (for emergency situations).

db = db.geSiblingDB(“admin”);
db.createRole({     
     role: “superRoot”,     
     privileges:[{          
          resource: {anyResource:true},          
          actions: [‘anyAction’]     
     }]     
     roles:[]
});
db.createUser({     
     user: “comanyDBA”,     
     pwd: “EWqeeFpUt9*8zq”,     
     roles: [“superRoot”]
})

These commands create a new role on the database geSiblingDB called superRoot and assign that role any resource and any action. Then we create a new user on the same database called companyDBA (with a password) and assign it the new superRoot role.

Using SSL for all things

SSL helps ensure the security of your data over unsecured networks. If you employ a database that interacts with the internet, you should use SSL.

There are two very good reasons to use SSL to secure MongoDB: privacy and authentication. Without SSL, your data can be accessed, copied, and used for illegal or harmful ends. With authentication, you have a secondary level of safety. SSL's private key infrastructure (PKI) guarantees that only users with the correct CA certificate can access MongoDB.

MongoDB has had SSL support for a long time, but has dramatically improved SSL support in the last few versions. Previously, if you wanted to use SSL, you had to download it and compile it manually with the MongoDB Community version. As of MongoDB 3.0, SSL is compiled with the software by default. 

Legacy versions of MongoDB also lacked valid host checking; host validation was merely a flag that you could check in the configuration file that satisfied an SSL request from a connection.

The latest versions of SSL in MongoDB include the following key features:

• Checks for valid hosts (optional)
• Ability to point to a specific setup .key file to use
• Custom Certificate Authority (CA) for self-signed certs or alternative signers
• allowSSL, preferSSL, requireSSL modes, which allow you to select a granularity for your SSL use (from less secure to more secure)

SSL: Using a custom CA

The newer versions of SSL in MongoDB allow you to use a custom CA. While this gives you flexibility in specifying how you want to work with SSL, it comes with caveats. If you're simply trying to secure the connection, you might be tempted to opt for sslAllowInvalidCertficates. However, this is generally a bad idea for a few reasons:

• Allows any connection from expired to revoked certificates
• You are not ensuring restrictions to a specific hostname
• You’re not nearly as secure as you think you are

To fix this, simply set net.ssl.CAFile, and MongoDB will use both the key and CA file (you must do this on the client).

Using SSL, however, has a known drawback: performance. You will definitely lose some performance when using SSL.

Disk encryption

Data is either “in transit” or “at rest.” You can encrypt either or both in MongoDB. We’ve discussed data encryption in transit (SSL). Now let’s look at data at rest.

At-rest data is data stored on disk. Data-at-rest encryption typically refers to data saved to an encrypted storage location. This is to prevent theft by physical means and create backups that are stored in a fashion not easily read by any third party. There are practical limits to this. The biggest is trusting your system administrators -- and assuming a hacker hasn’t obtained administrative access to the system.

This is not an issue unique to MongoDB. Preventive measures used in other systems work here as well. They might include encryption tools like LUKS and cryptfs or even more secure methods such as signing encryption keys with LDAP, smart cards, and RSA-type tokens.

When performing this level of encryption, you need to consider factors like automounting and decrypting of drives. But this is not new to your system administrators. They can manage this requirement in the same way they manage it in other parts of the network. The added benefit is a single procedure for storage encryption, not one per whatever technology a particular function uses.

Data-at-rest encryption can be solved with any or all of the following:

• Encrypt the entire volume
• Encrypt only the database files
• Encrypt in the application

The first item can be solved with disk encryption on the file system. It is easy to set up using LUKS and dm-crypt. Only the first and second options are required for PCI DSS compliance and other certification requirements.

Auditing

Central to any good security design is being able to track which user did what action in the database (similar to how you should control your actual servers). Auditing allows you to filter the output of a particular user, database, collection, or source location. This generates a log to review for any security incidents. More important, it shows any security auditor that you’ve taken the correct steps to protect your database from an intrusion and to understand the depth of any intrusion should one occur.

Auditing allows you to fully track the actions of an intruder in your environment.

Note: Auditing is available only in MongoDB Enterprise. It’s not in the Community version. It is available in some other open source versions of MongoDB such as Percona Server for MongoDB. 

You might also ensure that schema changes occur only when properly vetted by your DBA staff, as the developer code could fail if someone changes the format of what you’re storing in the database. This brings an additional layer of control to MongoDB’s dynamic production schema (allowing itself to store anything even if it should not).

Governance

Governance is about the insertion and updating of data. It is also useful for checking if a field name like “bday,” “birthday,” “ssn,” or “social,” is defined. Put simply, governance is the ability to enforce complex standards on the MongoDB system by using Document Validation.

Document Validation allows you to define which document areas are valid for a specific collection. You can set parameters to search keys and values and verify that they meet predefined standards. For example, you can check whether a key exists and if it is the correct key type.

The main Document Validation commands are:

• collMod. Defines the key to validate.
• validator. Define the parameters of the validation.
• validationLevel. Sets the strictness of the validator (how often it acts and how severe the action, depending on validationAction).
• validationAction. Sets the action when something fails validation.

We are not limited to defined keys and key values. You could also use regular expression strings. Using a regular expression, you could run a check for strings like a credit card number: ^d{4}-d{4}-d{4}-d{4}$. With regular expressions, you could also check for a user ID, a birth date, a Social Security number, and more. 

These examples are ways your DBAs and security architects can help prevent developers from exposing the company to added risk.

Reducing your network attack surface

Reducing your network attack surface means attempting to control all of the possible vulnerabilities in your network’s hardware and software that are accessible to unauthenticated users.

MongoDB’s documentation suggests that you put a mongos instance on each application host. This suggestion is certainly valid for reducing latency in your database environment (by limiting network jumps). But while this is good for performance, it is very bad for security.

Every mongos instance must be able to talk to:

• Every primary
• Every secondary
• Every configuration server

As you can imagine, this is a security nightmare. With every mongos instance, you have x many more connections spanning your network. That’s x many more connections an attacker might exploit.

Instead, it’s better to have a group of MongoDB servers near the applications that you let talk to other systems. Set up a load balancer (or something similar) for the application and only allow the applications to talk to the MongoDB servers. This will provide a reasonable DMZ-type setup that prevents opening too many connections across the network.

Percona

Default settings sink databases

Open source databases generally, and MongoDB specifically, have all the security options you need to guarantee that your data is protected (without having to buy an enterprise edition).

Know how security works in your open source database. Leaving it on the default settings is a sure path to disaster. By understanding and addressing the points above, you can fulfill all of your security needs (including regulatory security compliance) and protect your company using reasonable and well-known methods.

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.