MongoDB Security Part 1 - Design and Configuration

Update: Watch our webinar on Securing Your MongoDB Deployment for further information on this topic.

By Andreas Nilsson, Lead Security Engineer at MongoDB

With increased regulatory compliance, heightened concerns around privacy and growing risk from hackers and organized crime, the need to secure access to data has never been more urgent.

MongoDB Enterprise Advanced is the certified and supported production release of MongoDB, with advanced security features, including Kerberos and LDAP authentication, encryption of data at-rest, FIPS-compliance, and maintenance of audit logs. These capabilities extend MongoDB’s already comprehensive security framework, which includes Role-Based Access Control, PKI certificates, Field-Level Redaction, and SSL/TLS data transport encryption. You can get access to all of the features of MongoDB Enterprise free of charge for evaluation and development environments by heading to our download center. In a short series of blog posts I will attempt to explain the philosophy and design of the security model of MongoDB. The first post covers the basics of securing a MongoDB server and application and gives an overview of the options available. The second post lists the best practices for hardening your MongoDB deployment. For details of the MongoDB security architecture and a complete list of features, please refer to the MongoDB Security Architecture Whitepaper.

Security Model

Before going into details let’s start with the basics. A database security model needs to offer a basic set of features:

• control of read and write access to data
• protection of the integrity and confidentiality of the data stored.
• control of modifications to the database system configuration.
• privilege levels for different user types, administrators, applications etc.
• auditing of sensitive operations.
• stable and secure operation in a potentially hostile environment.

These security requirements can be achieved in different ways. A disconnected database server in a locked room would constitute a secure deployment regardless of how the database was being protected. However, it would not be very useful. A database is often placed unprotected on a “secured”, internal network. This is an idealized scenario since no network is entirely secure, architecture changes over time, and a considerable number of successful breaches are from internal sources. A defense-in-depth approach is therefore recommended when implementing your application’s infrastructure. While MongoDB’s security features help to improve your overall security posture, security is only as strong as the weakest link in the chain.

A conceptual view of the MongoDB security architecture is represented in the image below. The security model is divided into the four pillars of authentication, authorization, auditing and encryption.

Secure Your Deployment

In the discussion below we will assume a simple web application which reads from and writes to a replicated database. Each of the steps below is described in detail in the MongoDB Security Checklist. The focus is primarily on enabling access control and encryption.

Infrastructure Prerequisites

Design the application to work in a multilayer fashion, and place the database server(s) on a dedicated network segment, isolated from the DMZ where the web application resides. Configure firewall rules to limit network access to the database server. Lock down MongoDB user and file permissions. The database files should be protected from unauthorized access and the mongod/mongos daemons should be running with minimum privileges, specifically not as root.

Enable Access Control

The first step in securing your MongoDB database is to enable access control. As new apps and services are in development, it is typical that access control is not enforced. But once these applications are ready for test and QA, then it is important to specifically enable it, thus requiring all clients and servers provide valid credentials before they can connect to the database. This ensures that you are not deploying unproteced instances when you launch your app into production. Refer to the documentation for a tutorial stepping through how to configure authentication. The following is the recommended series of steps to enable access control.

Design

Determine which type of authentication methods to use for client authentication. The options are challenge-response based username/password (SCRAM-SHA-1), x.509, LDAP and Kerberos. Determine which type of authentication method to use for server-server cluster authentication. The options are username/password, keyfiles with SCRAM-SHA-1 and x.509. Please note that x.509 requires the use of SSL/TLS. List the different user types that will exist in the system; administrators, support staff, different type of application users etc. For each of the user types, align with the privileges offered by MongoDB’s h built-in roles, or create customized user-defined roles tailored for your specific deployment.

Deployment

Configure a keyfile or x.509 certificates for the cluster nodes. Start the mongod servers with the –auth flag set and appropriate cluster authentication options as determined in 3. Start mongos servers with appropriate cluster authentication options. Create the desired users with correct permissions. Please note that after creating the first user access control is enabled. Therefore, at a minimum the first user should have the userAdminAnyDatabase or root roles in order to be able to create other users.

Enable Network Encryption

In order to protect the network traffic, SSL/TLS should be enabled between clients and the server and in between servers. MongoDB supports TLS 1.0, 1.1 and 1.2, all SSL versions are disabled. Enabling TLS is well described in the security documentation. MongoDB supports the use of any server certificate as long as the corresponding root CA certificate is provided with the configuration parameter –sslCAFile. If no CA certificate is specified, no certificate validation is performed and the certificate is only used for encryption purposes. Although supported, use of self-signed certificates is not recommended, since there is no basis for trust, and hence no certificate validation can be performed. By default mutual certificate validation is performed on the client-server connection. The server certificate is validated against the CA certificate file provided on the client side, and the client certificates are validated against the CA certificate provided on the server side. However no authentication is performed. In order to allow clients to connect without a certificate, the server can be started with the command line flag –sslAllowConnectionsWithoutCertificates.

X.509 Authentication

If SSL/TLS is enabled clients, can use the authentication mechanism MONGODB-X509 to authenticate using x.509 certificates.

It is also possible to use x.509 authentication between the servers in a cluster. From a security perspective this is a great improvement to using a keyfile with a static password.

Enable Storage Encryption

In addition to network encryption, the latest MongoDB 3.2 release adds native support for encrypting data at-rest using the new Encrypted storage engine, which is available as part of MongoDB Enterprise Advanced. By natively encrypting database files on disk, administrators eliminate both the management and performance overhead of external encryption mechanisms. This new storage engine provides an additional level of defense, allowing only those staff with the appropriate database credentials access to encrypted data. The encryption process is entirely transparent to the application, and MongoDB supports a variety of encryption schema, with AES-256 (256 bit encryption) in CBC mode being the default. AES-256 in GCM mode is also supported. The encryption schema can be configured for FIPS 140-2 compliance. You can learn more about configuring at-rest encryption and key rotation from the documentation.

Disable Unused Exposed Interfaces

Disable sensitive interfaces and functionality that is not needed. MongoDB supports the execution of JavaScript code for certain server-side operations: mapReduce, group, eval, and $where. If you do not use these operations, disable server-side scripting by setting –noscripting to true. Use only the MongoDB wire protocol on production deployments. The following interfaces are disabled by default: –httpinterface, –jsonp, and –rest. Leave these disabled, unless required for backwards compatibility. The bind_ip setting for mongod and mongos instances limits the network interfaces on which MongoDB programs will listen for incoming connections. Configure the server only to bind on desired interfaces.

Auditing

The MongoDB Enterprise Advanced auditing framework logs all access and actions executed against the database. The auditing framework captures administrative actions (DDL) such as schema operations as well as authentication and authorization activities, along with read and write (DML) operations to the database. Administrators can construct and filter audit trails for any operation against MongoDB, whether DML, DCL or DDL without having to rely on third party tools. For example, it is possible to log and audit the identities of users who retrieved specific documents, and any changes made to the database during their session. By default, MongoDB auditing logs all administrative actions, but can also be configured with filters to capture only specific events. The audit log can be written to multiple destinations in a variety of formats including to the console and syslog (in JSON format), and to a file (JSON or BSON), which can then be loaded to MongoDB and analyzed to find relevant events.

MongoDB Maintains an Audit Trail of Administrative Actions Against the Database

Each MongoDB server logs events to its local destination. The DBA can then merge these into a single log, enabling a cluster-wide view of operations that affected multiple nodes. MongoDB Enterprise Advanced also supports role-based auditing. It is possible to log and report activities by specific role, such as userAdmin or dbAdmin – coupled with any inherited roles each user has – rather than having to extract activity for each individual administrator. The MongoDB auditing documentation includes information on how to configure auditing and all of the operations that can be captured.

Summary

Securing the database layer of an application is a necessary step to protect the data from unauthorized access. MongoDB offers a flexible and competent security model but as with all security solutions, care should be take to enable and configure the system correctly. In part 2, we will provide best practices on hardening your MongoDB deployment MongoDB Enterprise Advanced provides access to enterprise grade capabilities. It includes all the ease-of-use, broad driver support, and scalability features of MongoDB, while addressing the more demanding security and certification requirements of corporate and government information security environments. To try it out, download an evaluation version of MongoDB Enterprise.

---

¹LDAP & Kerberos authentication are available as part of MongoDB Enterprise Advanced