Zero-Trust Security with MongoDB Atlas

Learn the essential strategies and best practices for securing your MongoDB Atlas deployments, from role-based access control and federated authentication to network isolation and advanced data encryption.

Securing your cloud database isn't just a checkbox; it is the foundation of a reliable and trustworthy application. As a developer, you must ensure that only the right people and applications can access your data, and that your network and storage are locked down against unauthorized threats.

Managing Users' Permissions with Role-Based Access Control (RBAC)

Role-based access control (RBAC) is your first line of defense inside the database. It dictates exactly what an authenticated user or application is allowed to do. Instead of giving everyone blanket administrative rights, RBAC lets you assign specific roles tied to specific permissions.

MongoDB Atlas comes with several built-in, preconfigured roles. These include roles like read, readWrite, and dbAdmin.

You should use preconfigured roles for standard, everyday tasks. If an application only needs to read data from a specific database to populate a dashboard, assigning the read role is a quick and secure way to grant exactly that access without over-complicating your setup.

The MongoDB Atlas Database Access UI shows a list of database users and their assigned built-in and custom roles.

Assigning Roles to a User

Follow these steps to assign roles to a user:

1. In the left-hand menu, navigate to Security > Database and Network Access
2. Click Add New Database User or edit next to an existing user
3. Under Database User Privileges, select a built-in role from the dropdown or choose a custom role.
4. Click Add/Update User to save.

You can find a complete list of actions for each built-in role in the MongoDB documentation for database user roles

Creating Custom Roles for Granular Access

Sometimes, built-in roles don't fit perfectly. This is where custom roles come in. Custom roles allow you to define granular permissions down to the collection level.

Here is how to create a custom role:

1. In the left-hand menu, navigate to Security > Database and Network Access
2. Click Add New Custom Role.
3. Enter a descriptive name for your new role.
4. Add specific Actions (such as find, insert, or update) from the dropdown.
5. Specify the exact Resources (the target database and collection names) where those actions apply.
6. Click Add Custom Role to save.

After adding a custom role, you can use it when selecting roles in the user create and modify pop-up.

Using custom roles helps you enforce the principle of least privilege. This principle states that a user or workload should only have the absolute minimum access rights necessary to perform their job and nothing more.

By default, users created via the Database Users page have access to all clusters of the project. You can, however, limit a user's access to specific clusters using the option found at the bottom of the user creation and modification pop-up.

Simplifying Management of Users with Federated Authentication for Workforce and Workload

Federated Authentication in MongoDB Atlas centralizes and secures access by linking your database environment to your existing Identity Provider (IdP), such as Microsoft Entra ID, instead of managing separate local credentials.

With Federated authentication, users and applications authenticate through your organization's established security perimeter instead of using standalone database passwords. This approach streamlines administration, enhances security, and ensures compliance with your company's identity policies.

There is a difference between authenticating your workforce (human users such as developers and DBAs) and your workloads (applications and services).

• Human users (the workforce) will authenticate to the UI and can connect to the database via the mongo shell or Compass using your company's 2FA.
• Applications (the workload) securely connect to MongoDB databases using short-lived OAuth 2.0 tokens or cloud IAM roles.

Atlas offers a Federation Management console in the organization page, where you can set up and manage all aspects of federated authentication.

Steps to Configure Identity Federation

Whether you need to set up workforce or workload identity federation, you will:

• Set up Domain: Map your organization's domain in Atlas
• Set up Identity provider: Provide Atlas with the required parameters so that it can interact with it
• (optional) Role mapping: Specify what Atlas roles are to be used when a given user present itself as part of a group of your IdP

You do not have to migrate everything at once. Identity Federation can be enabled for specific applications or users while allowing others to continue using traditional SCRAM authentication.

To learn more, see:

• Configure Federated Authentication to access the Atlas UI
• Set up Workforce Identity Federation with OIDC to access the data
• Set up Workload Identity Federation with OIDC to access the data

Securing the Network

Authentication checks who is connecting, but network security checks where they are connecting from.

Atlas enforces TLS/SSL, meaning that all your connections are encrypted, but that is not enough to defend against someone trying to access your cluster from the internet via the public IP.

By default, you should use IP Access Lists (whitelists) to restrict access, which is available in:

Database and Network Access" > "IP Access List.

A major rule of thumb is to never whitelist all ip addresses with 0.0.0.0/0. This opens your database to the entire public internet, which is a major security risk.

For more robust network security, you should rely on Private Endpoints or Network Peering to establish a private connection between your cluster and your apps.

Private Endpoint

Private Endpoints provide a direct, private connection between your application and Atlas, bypassing the public internet.

Private endpoints link services like:

• AWS PrivateLink
• Azure Private Link
• Google Cloud Private Service

Connect to your Atlas cluster. When configured, you will get a connection string that ensures that no traffic will flow on the wide web.

The traffic coming from your services that try to connect to Atlas will be routed by your VPC, like a proxy to the Atlas network.

You can also connect via private endpoint from your on-prem network by configuring a VPN or Direct Connect.

To configure it, you create an endpoint in your own cloud provider's Virtual Private Cloud (VPC) and link it to the Atlas service. This makes the Atlas cluster appear as if it lives directly inside your own private network. Each cloud provider has its own steps. A step-by-step guide for the GCP, Azure, and AWS can be found here

Network Peering

Network Peering establishes a secure private connection between your cloud environment and your Atlas cluster. It does so by merging the routing tables, as if the Atlas network and your cloud network were one.

This allows you to:

• Extend your private network to Atlas, treating the cluster as part of your internal network.
• Securely access Atlas without exposing it to the public internet.
• Encrypt all traffic between your network and Atlas.

While configuring Network peering, you will have to verify that Atlas CIDR blocks do not overlap with those of your VPC.

What to pick and when

Both solutions provide a superior security posture compared to the IP whitelist by ensuring the database remains invisible to the public web.

• Private Endpoints are the standard for cloud and hybrid-cloud setups because it allows your services on the cloud or on-premise to reach Atlas through a private network.
• Network Peering is the best choice for cloud-only architectures where you have full control over your IP ranges.

However, it requires that your VPC and Atlas IPs do not overlap (CIDR blocks), and it cannot natively route traffic from on-premise data centers.

Protecting the data

Beyond access and network controls, the data itself must be protected. Atlas provides several layers of encryption.

1. Queryable Encryption

Queryable Encryption is a cryptographic feature that encrypts sensitive fields (such as credit card numbers or SSNs) within your application before sending them to MongoDB Atlas.

• The data is stored on the database server as fully randomized values, and the database can still perform complex queries (such as equality, range, or prefix) without ever decrypting the information.
• Sensitive data remains encrypted throughout its entire lifecycle -in transit, at rest, in use, in logs, and in backups.
• Decryption only ever occurs on the client-side, since only your application has access to the encryption keys.
• This feature utilizes the MongoDB driver's automatic encryption, which performs encrypted read and write operations transparently. This means you don't have to add explicit, manual calls to encrypt or decrypt fields within your application logic.
• MongoDB also offers CSFLE, an alternative to Queryable Encryption. While it also encrypts data on the client-side, it is more limited as searches on encrypted fields only support simple equality matches.

2. Customer Key Management (CKM) for Data at Rest

• By default, Atlas encrypts your data with its own safe encryption key. If someone in the cloud were to get access to the disks that host your data, they would not be able to read it.
• CKM allows you to use your own cloud provider's Key Management Service (KMS) to control the master encryption keys. If you revoke the key, the database becomes immediately unreadable.

3. Auditing

• To maintain a truly secure environment, you need to know who did what and when.
• Database auditing records all administrative and data access events. It can be activated in clusters from the M10 tier up. In Atlas, you can configure auditing to capture specific granular actions.
• This is essential not only for identifying potential security breaches after they happen, but also for maintaining compliance with strict regulatory frameworks like HIPAA, GDPR, or SOC 2.
  

MongoDB Atlas offers layers of protection for your environments.

By implementing strict role-based access control, streamlining identities with federated authentication, locking down network boundaries with Private Endpoints, and employing robust encryption for your sensitive data, you drastically reduce your attack surface. Remember to audit your system to ensure you keep track of who accesses the data.

Best Practices for Securing MongoDB Atlas

Securing your MongoDB Atlas deployment involves implementing proper network controls, authentication, and encryption. The following practices help protect your database while ensuring authorized access.

1. Restrict Network Access: Configure IP Access Lists to allow connections only from trusted IP addresses such as application servers or office networks, preventing unauthorized access.

2. Use Federated Authentication: Federated authentication enables both employees and applications to securely authenticate using enterprise identity providers for centralized access management.

3. Enable Private Endpoints: Private Endpoints allow secure database connectivity through a private network. When enabled, Atlas provides separate connection strings for private network access and public IP access via the whitelist.

4. Query Encrypted Data: MongoDB Atlas supports encryption features such as Queryable Encryption and Client-Side Field Level Encryption (CSFLE). Queryable Encryption allows limited queries like equality and range searches, while CSFLE typically supports exact-match queries.

Key Takeaways

• Never use 0.0.0.0/0 for your IP access list; always restrict network access.
• Use Private Endpoints instead of Network Peering whenever possible.
• Apply the principle of least privilege, giving each user only the necessary roles.
• Leverage federated authentication to simplify access management and enforce MFA.
• Utilize Queryable Encryption or Client-Side Field Level Encryption (CSFLE) to protect highly sensitive fields.