Securing MongoDB Part 2: Database Access Control

Welcome back to our 4-part blog series presenting the best practices and controls available in MongoDB to help you create a secure, compliant database platform.

In this installment, we’ll be discussing database access control – covering both authentication and authorization.

In part 1, we took a look at the general requirements for data security and regulatory compliance. Looking ahead, in part 3 we’ll cover auditing and encryption. And in part 4, we’ll wrap up with environmental control and management.

If you want to get a head-start and learn about all of these topics in one installment, just go ahead and download the MongoDB Security Architecture guide.

Enable Access Control and Enforce Authentication

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 exposed instances when you launch your app into production. Refer to the documentation for a tutorial stepping through how to configure authentication.

Ensure that MongoDB runs in a trusted network environment and limit the interfaces on which MongoDB instances listen for incoming connections. Allow only trusted clients to access the network interfaces and ports on which MongoDB instances are available. See the Security Hardening section of the documentation to learn more about reducing the risk of exposure.

MongoDB Authentication

The authentication of entities accessing MongoDB can be managed from within the database itself, or via integration with an external mechanism (i.e. LDAP, x.509 PKI certificates, or a Kerberos service). MongoDB Enterprise Advanced, the certified and supported production release of MongoDB is required when using LDAP or Kerberos.

In Database Authentication

MongoDB authenticates entities on a per-database level using the SCRAM-SHA-1 IETF standard. Users are authenticated via the authentication command, while database nodes can be authenticated to the MongoDB cluster via keyfiles. Review the authentication documentation to learn more.

MongoDB Atlas Authentication

MongoDB Atlas is a database as a service for MongoDB, providing all of the features of the database, without the operational heavy lifting required for any application. MongoDB Atlas has been engineered to deliver robust access controls.

Authentication is enforced for all

MongoDB Atlas clients via the SCRAM-SHA-1 mechanism. User and administrator roles can be defined to ensure a separation of duties between different entities accessing the database and the MongoDB Atlas service. Clients are prevented from accessing the database unless their IP address has been added to the IP whitelist for your MongoDB Atlas group.

Review the MongoDB Atlas documentation for more information on configuring the in-built security controls.

LDAP Authentication

LDAP is widely used by many organizations to standardize and simplify the way large numbers of users are managed across internal systems and applications. In many cases, LDAP is also used as the centralized authority for user access control to ensure that internal security policies are compliant with corporate and regulatory guidelines.

With LDAP integration, MongoDB can authenticate users directly against corporate LDAP infrastructure to enforce centralised access policies. Note that MongoDB currently supports LDAP authentication, and not authorization. See the following section of this post to learn more about the authorization controls available in MongoDB.

Administrators can configure MongoDB to authenticate users via Linux PAM or by proxying authentication requests to a specified LDAP service. A tutorial on configuring LDAP authentication is available in documentation.

Kerberos Authentication

With MongoDB Enterprise Advanced, authentication using a Kerberos service is supported. Kerberos is an industry standard authentication protocol for large client/server systems, allowing both the client and server to verify each others' identity. With Kerberos support, MongoDB can take advantage of existing authentication infrastructure and processes, including Microsoft Windows Active Directory.

As with LDAP and x.509 certificates, before users can authenticate to MongoDB using Kerberos, they must first be created and granted privileges within MongoDB. The process for doing this, along with a full configuration checklist is described in the MongoDB and Kerberos tutorial.

x.509 Certificate Authentication

With support for x.509 certificates MongoDB can be integrated with existing information security infrastructure and certificate authorities, supporting both user and inter-node authentication. Users can be authenticated to MongoDB using client certificates rather than self-maintained passwords.

Inter-cluster authentication and communication between MongoDB nodes can be secured with x.509 member certificates rather than keyfiles, ensuring stricter membership controls with less administrative overhead, i.e. by eliminating the shared password used by keyfiles. x.509 certificates can be used by nodes to verify their membership of MongoDB replica sets and sharded clusters. A single Certificate Authority (CA) should issue all the x.509 certificates for the members of a sharded cluster or a replica set.

Instructions for configuration are described in the MongoDB and x.509 certificates tutorial.

MongoDB and Microsoft Active Directory

MongoDB Enterprise Advanced provides support for authentication using Microsoft Active Directory with both Kerberos and LDAP. The Active Directory domain controller authenticates the MongoDB users and servers running in a Windows network.

MongoDB Authorization

MongoDB allows administrators to define the specific permissions an application or user has, and what data they can see when querying the database.

User Defined Roles

MongoDB provides over ten built-in roles supporting different user and administrator privileges. These can be customised through User Defined Roles, enabling administrators to assign fine-grained privileges to users or applications. Authorization privileges can be based on the specific functionality a user needs in their role, or to reflect their organizational structure. MongoDB provides the ability to specify user privileges with both database and collection-level granularity.

^{**Figure 1**: MongoDB User Defined Roles Permit Separations of Duty}

Privileges are assigned to roles, and roles are in turn assigned to users. For example:

• Classes of users and applications can be assigned privileges to insert data, but not to update or delete data from the database
• DBAs may be assigned privileges that enable them to create collections and indexes on the database, while developers are restricted to CRUD operations
• Certain administrator roles may have cluster-wide privileges to build replica sets and configure sharding, while others are restricted to creating new users or inspecting logs
• Processes for monitoring MongoDB clusters can be restricted to run just those commands that retrieve server status, without having full administrative access to perform database operations
• Within a multi-tenant environment, “landlord” developers and administrators can be assigned permissions across physical databases, while “tenant” developers and administrators can be granted a more limited set of actions across logical databases or individual collections. This functionality enables a clear separation of duties and control, both between and within organizations.

To ensure ease of account provisioning and maintenance, roles can be delegated across teams, ensuring the enforcement of consistent policies across specific functions within the organization.

Review the Authorization section of the documentation to learn more about roles in MongoDB.

When combined with the auditing capabilities available with MongoDB Enterprise Advanced, customers can define specific administrative actions per role, and then log all of those actions. As a result, the organization is able to enforce end-to-end operational control and maintain insight of actions for compliance and reporting.

MongoDB Field Level Redaction

MongoDB’s field level redaction allows building access control to individual fields of document, working in conjunction with client-side code. Implemented via the redaction stage of MongoDB’s Aggregation Pipeline, developers are provided with a method to restrict the content of a returned document on a per-field level. Permissions can be based on both the content of the document and on specific user privileges, based on security labels. Access control policies can be described using the MongoDB query language, making it simple for developers to implement the required controls.

Since data is redacted before it is returned to the application, exposure of sensitive information is reduced. Field level redaction is applicable to a wide range of sensitive data including personally identifiable information such as names, social security numbers, birthdates and bank account numbers. By co-locating data with different sensitivity levels within a single document, schema and query designs are simplified.

^{**Figure 2**: MongoDB Field Level Redaction Restricts Access to Sensitive Data}

The redaction logic must be passed by the application to the database on each request. It therefore relies on trusted middleware running in the application to ensure the redaction pipeline stage is appended to any query that requires the redaction logic.

Getting Started with MongoDB Security

With comprehensive controls for user rights management, auditing and encryption, coupled with management controls, MongoDB can meet the best practice and requirements discussed in this blog series. 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 security framework, which includes Role-Based Access Control, PKI certificates, Field-Level Redaction, and SSL/TLS data transport encryption.

In the third part of this blog post series, we will dive into MongoDB auditing and encryption.

---

You can learn about all of these capabilities now by reading the MongoDB Security Architecture guide. If you want to try them for yourself, [download MongoDB Enterprise](https://www.mongodb.com/download-center?#enterprise), free of charge for evaluation and development. MongoDB security architecture

---

About the Author - Mat Keep

Mat is a director within the MongoDB product marketing team, responsible for building the vision, positioning and content for MongoDB’s products and services, including the analysis of market trends and customer requirements. Prior to MongoDB, Mat was director of product management at Oracle Corp. with responsibility for the MySQL database in web, telecoms, cloud and big data workloads. This followed a series of sales, business development and analyst / programmer positions with both technology vendors and end-user companies.