MongoDB Authorization: A Practical Guide

What Is MongoDB Authorization?

MongoDB is a document-oriented NoSQL database that can store large amounts of data. Unlike traditional relational database management systems (RDBMS), MongoDB uses collections and documents instead of tables and rows.

MongoDB authorization is a MongoDB security process that lets administrators define which authenticated users should have access to which resources, and what operations they should be allowed to perform on the resources. MongoDB provides extensive authorization features including role-based access control (RBAC), LDAP authorization, and dynamic field level security.

In this article:

• MongoDB Authorization Features
  • Role-Based Access Control (RBAC)
  • LDAP Authorization
  • Field-Level Security Using Read-Only Views
  • Log Redaction
• Enabling MongoDB Authorization Using RBAC
• Best Practices for MongoDB Authorization
  • Grant Minimal Access to Entities
  • Group Common Access Privileges into Roles
  • Control Which Actions an Entity Can Perform
  • Control Access to Sensitive Data
• MongoDB Security with Satori

MongoDB Authorization Features

MongoDB has multiple features that allow organizations to control user access to database information.

Role-Based Access Control (RBAC)

In an RBAC authorization system, permissions are assigned to roles and roles are assigned to users. MongoDB provides predefined roles that support regular user and administrator database privileges. These include dbAdmin, dbOwner, clusterAdmin, and readWrite.

Administrators can further customize roles to assign fine-grained permissions to users based on data access and processing requirements.

The auditing capabilities of MongoDB Enterprise Advanced allow organizations to define specific administrative actions for each role and log all actions. Organizations can then implement end-to-end operational management and maintain visibility into compliance and reporting operations.

LDAP Authorization

MongoDB supports authentication using the Lightweight Directory Access Protocol (LDAP). In addition, it lets you use LDAP to authorize users. MongoDB Enterprise Advanced lets you reuse existing user permissions stored in the LDAP server, mapping them to MongoDB roles, without having to re-create users in MongoDB.

When an LDAP server is configured for authorization, MongoDB allows user authentication via a number of methods, including LDAP, Active Directory, Kerberos, or X.509 without the need to store local user documents in the $external database.

The $external database is used when users store their credentials outside of MongoDB. When a user is successfully authenticated, MongoDB queries the LDAP server to get all groups to which the user belongs. The group is then converted to an equivalent MongoDB role.

Field-Level Security Using Read-Only Views

Developers and database administrators (DBAs) have several ways to implement field-level security.

DBAs can define unmaterialized views that expose only a subset of the data in the underlying MongoDB collection. For example, a view can exclude sensitive data fields, such as personal identifiable information (PII), from sales data and health records. This greatly reduces the risk of data breaches.

DBAs can also define aggregate views based on multiple collections or multiple existing views. The permissions granted to the view are separate from those granted to the underlying views or collections.

This makes it easy for organizations to meet compliance standards in regulated industries. By restricting access to sensitive data, data can be partitioned to reflect different access rights, without creating separate silos.

Additionally, views can show calculated fields without exposing underlying customer data or affecting the structure or content of the original source collection.

Log Redaction

MongoDB Enterprise Advanced can be configured with log redaction, to prevent potentially sensitive information such as personal identifiers from being written to the diagnostic log.

Enabling MongoDB Authorization Using RBAC

When you use RBAC to manage MongoDB access, users are assigned one or more roles that determine access to database resources and operations. This works as follows:

• Users can only access the system if an administrator assigns them a role.
• A role can contain one or more existing roles. In this case, the role inherits all permissions of the containing role.
• MongoDB does not enable access control by default. DBAs can enable authorization using the –auth or security.authorization setting. When you enable authentication, this also automatically enables client authorization.

The MongoDB RBAC system uses the following authorization elements:

• Roles—grants permission to perform specified actions on a resource.
• Privileges—consists of allowed actions on a given resource.
• Resource—a database, collection, set of collections, or database cluster.
• Action—specifies the actions allowed for the resource.

MongoDB provides built-in roles, which you can use as-is or customize to your needs.

Best Practices for MongoDB Authorization

Here are a few ways you can control access to MongoDB and improve data protection.

Grant Minimal Access to Entities

Provide users and service accounts the minimal database access they need to perform their functions. For example, if your application requires access to a logical database, you should restrict operations to that database and prevent access to other logical databases.

Group Common Access Privileges into Roles

Group entities into functional roles such as Developer, DBA, and Application Server. Role permissions are centrally managed and users can be added to or removed from roles as needed.

Control Which Actions an Entity Can Perform

When granting access to a database, consider the specific tasks or commands that each entity must have permission to perform.

Control Access to Sensitive Data

Avoid data silos by limiting the permissions of individual fields based on security permissions.

MongoDB Security with Satori

Satori’s data security platform enables a move from persistent permissions to JIT and need-to-know access to data.