Lv.2 BeginnerMongoDB

2026.05.2525 min readLv.2 Beginner

SeriesMongoDB Atlas Complete Guide · Part 3View series hub

MongoDB Atlas Complete Guide Part 3 — Security, Networking, and Access Control

Atlas security is a shared responsibility between MongoDB and the customer. This guide covers the three-layer network model (IP Access List, VPC Peering, Private Endpoint), SCRAM/X.509/AWS IAM authentication, least-privilege RBAC, CMK Envelope Encryption and Queryable Encryption, Audit Log Push-based Export, and GDPR/PCI DSS/HIPAA compliance — from an operational perspective.

Series

• Part 1 | Concepts, architecture, and why Atlas matters
• Part 2 | Cluster Design Strategy
• Part 3 ← You are here | Security, Networking, and Access Control
• Part 4 | Performance Optimization — Indexing, Query Tuning, Auto-scaling
• Part 5 | Atlas in the AI Era — Vector Search, Stream Processing, RAG Pipelines

Table of Contents

1. The Big Picture — Shared Responsibility Model
2. Three-Layer Network Security — IP Access List, VPC Peering, Private Endpoint
3. Authentication — Who Is Connecting
4. Authorization — What They Can Do (RBAC)
5. Three Encryption Layers — At Rest, In Transit, In Use
6. Audit Logs — Who Did What
7. Compliance — GDPR, PCI DSS, HIPAA
8. Top 5 Security Pitfalls
9. Final Security Checklist

1. The Big Picture — Shared Responsibility Model

MongoDB Atlas security is built on the Shared Responsibility Model. Incidents happen when teams assume Atlas handles everything. Start by drawing a clear boundary.

No matter how capable Atlas is, the moment you add 0.0.0.0/0 to the IP Access List or wire up an admin-level DB user in your app, security collapses. This part walks through every item in the customer responsibility column.

2. Three-Layer Network Security

Atlas network access control supports three methods that can be layered. The right combination depends on your security requirements.

Higher security means higher configuration complexity. Consider both your security requirements and team capability when choosing.

2-1. IP Access List — The Baseline, With Pitfalls

Every Atlas cluster requires an IP Access List entry before any connection is accepted. Configuration is straightforward, but operational mistakes are common.

# Allow a specific IP
atlas accessLists create \
  --type ipAddress \
  --entry "203.0.113.42" \
  --comment "Prod App Server - Seoul DC"

# Allow a CIDR block (office network)
atlas accessLists create \
  --type cidrBlock \
  --entry "10.0.1.0/24" \
  --comment "Internal Office Network"

# Quick-add current IP (development only)
atlas accessLists create --currentIp

What you must never do:

# Allow every IP on the internet — happens more than you'd think
atlas accessLists create --entry "0.0.0.0/0"

Operational warning: The Atlas UI shows a warning for 0.0.0.0/0, but teams often click through it with "just temporarily." This setting is discovered in production far more often than expected. From 2025, Atlas Resource Policies let you ban wildcard IP entries at the organization level.

Example Resource Policy to block 0.0.0.0/0 org-wide:

// Atlas Admin API — deny 0.0.0.0/0 entries
{
  "policies": [{
    "body": "forbid(principal, action == atlas:CreateNetworkAccessEntry,
             resource) when { resource.ipAddress == \"0.0.0.0/0\" };"
  }]
}

2-2. VPC Peering — Private Network Connectivity

VPC Peering connects your app server's VPC and the Atlas VPC over a private network, bypassing the public internet entirely.

VPC Peering constraints (must know):

• No CIDR overlap: If your VPC CIDR overlaps with Atlas's, the connection fails. Set the Atlas project CIDR carefully at creation time — it cannot be changed later.
• Same cloud only: AWS ↔ AWS, GCP ↔ GCP, Azure ↔ Azure. Cross-cloud peering is not supported.
• M10+ Dedicated only (M0 and Flex are excluded)

# Create AWS VPC Peering (Atlas CLI)
atlas networking peering create aws \
  --accountId 123456789012 \
  --vpcId vpc-0abc123def456 \
  --routeTableCidrBlock "10.0.0.0/16" \
  --region ap-northeast-2

2-3. Private Endpoint — Maximum Security, Production Standard

Private Endpoint (AWS PrivateLink / Azure Private Endpoint / GCP Private Service Connect) is MongoDB Atlas's officially recommended network security approach.

The critical difference from VPC Peering is unidirectional (one-way) connectivity. Your VPC can connect to Atlas, but Atlas cannot initiate connections back to your VPC. This is what maintains a clean trust boundary.

Reverse connections (Atlas → customer VPC) are blocked at the infrastructure level. Traffic stays within the AWS/Azure/GCP backbone and never touches the public internet.

AWS PrivateLink setup steps:

# Step 1: Create Private Endpoint Service in Atlas
atlas privateEndpoints aws create \
  --region ap-northeast-2

# Copy the output endpointServiceName, then...

# Step 2: Create VPC Interface Endpoint via AWS CLI
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123def456 \
  --subnet-ids subnet-0aaa111 subnet-0bbb222 \
  --service-name com.amazonaws.vpce.ap-northeast-2.vpce-svc-xxxxx \
  --vpc-endpoint-type Interface

# Step 3: Register the Endpoint ID in Atlas
atlas privateEndpoints aws interfaces create \
  --endpointServiceId <SERVICE_ID> \
  --privateEndpointId vpce-0xxxxxxxxxxxxxxx

Multi-region cluster note: you must create a separate Private Endpoint in each region that has nodes. A Seoul + Singapore cluster requires endpoints in both regions.

VPC Peering vs Private Endpoint — final comparison:

3. Authentication — Who Is Connecting

Once the network perimeter is in place, the next layer is verifying who is actually connecting.

3-1. Database Users (SCRAM)

The most common authentication method. Uses SCRAM (Salted Challenge Response Authentication Mechanism) — a username and password protocol.

// Correct connection string (credentials separated into env vars)
const uri = `mongodb+srv://${process.env.DB_USER}:${process.env.DB_PASS}@cluster0.xxxxx.mongodb.net/`;

DB user creation best practices:

# Bad: one admin account shared across all apps
atlas dbusers create \
  --username admin \
  --role atlasAdmin    # Full admin rights (never use in app)

# Good: dedicated user per app with least privilege
atlas dbusers create \
  --username app-user-read \
  --role "readAnyDatabase"

atlas dbusers create \
  --username app-user-write \
  --role "readWriteAnyDatabase"

atlas dbusers create \
  --username app-user-specific \
  --scope "myDatabase"    # Scoped to one database

3-2. X.509 Certificate Authentication (M10+)

Authenticates with a client certificate instead of a password. Eliminates password-leak risk — preferred in high-security environments such as finance and healthcare.

# Create an X.509-authenticated DB user
atlas dbusers create \
  --username "CN=myApp,OU=Engineering,O=MyCompany" \
  --x509Type MANAGED

3-3. AWS IAM Authentication (recommended for AWS)

Supports IAM Role-based authentication on AWS EC2, Lambda, and EKS. No need to store any password in code, which significantly improves security posture.

# AWS IAM authentication example (Python)
import boto3
from pymongo import MongoClient

def get_aws_token():
    # Verify caller identity using STS (IAM Role-based)
    sts = boto3.client('sts')
    token = sts.get_caller_identity()
    return token

client = MongoClient(
    "mongodb+srv://cluster0.xxxxx.mongodb.net/",
    authMechanism="MONGODB-AWS"
    # Reads AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY from the environment
)

3-4. Atlas UI Access — MFA and SSO

Securing the Atlas console itself matters. If an Atlas admin account is compromised, the entire cluster is at risk.

• MFA (Multi-Factor Authentication): Enforce MFA on every Atlas UI account
• Federated Authentication (SSO): Integrate with enterprise IdPs such as Okta, Azure AD, or Google Workspace. When an employee is offboarded from the IdP, their Atlas access is revoked automatically

// Enforce MFA at the organization level (Atlas Admin API)
PATCH /orgs/{orgId}/settings
{
  "requireMFAForAccount": true
}

4. Authorization — What They Can Do (RBAC)

Authentication answers "who are you." Authorization answers "what can you do." Atlas provides two layers of RBAC.

4-1. Atlas Platform RBAC (Console and API Access)

Access to the Atlas console and API is segmented by Organization and Project roles.

Organization-level roles
  Organization Owner          Full management (billing, members, project creation)
  Organization Member         Can join projects; cannot change org settings
  Organization Billing Admin  Billing management only

Project-level roles (including 2025 additions)
  Project Owner                    Create/delete clusters, full security settings
  Project Data Access Admin        Read/write data; cannot delete clusters
  Project Database Access Admin    (2025 new) DB user management only
  Project Backup Manager           (2025 new) Backup management only
  Project Observability Viewer     (2025 new) Monitoring read-only
  Project Read Only                Read project settings only
  Project Cluster Manager          Cluster configuration (excludes security settings)

The 2025 additions — Project Database Access Admin, Project Backup Manager, and Project Observability Viewer — allow much finer-grained separation. DBAs get only DB access, backup teams get only backup, monitoring teams get only visibility.

4-2. Database RBAC (Data Access Control)

Combine Atlas built-in roles with custom roles you define.

Built-in roles:

Custom role example — read access to one collection only:

// Create a custom role via Atlas Admin API
POST /groups/{groupId}/customDBRoles/roles
{
  "roleName": "readOnlyOrders",
  "actions": [
    {
      "action": "FIND",
      "resources": [
        {
          "db": "ecommerce",
          "collection": "orders"
        }
      ]
    }
  ]
}

Recommended pattern — per-app least privilege:

App Server A (order processing)
  DB User: app-orders-rw
  Permissions: ecommerce.orders (readWrite), ecommerce.products (read)

App Server B (reporting)
  DB User: app-report-ro
  Permissions: ecommerce.* (read only)

Batch Server (settlement)
  DB User: batch-settlement
  Permissions: finance.settlements (readWrite), ecommerce.orders (read)

5. Three Encryption Layers — At Rest, In Transit, In Use

Atlas encryption splits into three layers: At Rest (stored), In Transit (moving), and In Use (being processed). Understanding what each layer protects is essential to applying them correctly.

5-1. At Rest — Encrypting Stored Data

Default encryption (automatic, no cost): Atlas encrypts all cluster storage by default using the cloud provider's AES-256 keys. No configuration required.

CMK (Customer-Managed Keys): For enterprise environments where default encryption is insufficient, customers manage their own KMS keys. Supported with AWS KMS, Azure Key Vault, and GCP Cloud KMS.

Revoking the CMK immediately makes the Atlas cluster inaccessible — this is the "kill switch" for a security incident. Accidentally deleting the CMK causes permanent data loss, so key management requires extreme care.

2025 new: Azure Key Vault Secretless authentication: Previously, integrating Azure Key Vault required a static client secret. From 2025, Secretless authentication uses short-lived OAuth 2.0 tokens, eliminating the burden of secret rotation.

# Azure Key Vault Secretless setup (no static secret)
atlas encryption azureKeyVault enable \
  --clientID "" \
  --secret "" \
  --subscriptionID "xxxx" \
  --resourceGroupName "my-rg" \
  --keyVaultName "my-keyvault" \
  --keyIdentifier "https://my-keyvault.vault.azure.net/keys/mykey"

Automatic 90-day MongoDB Master Key rotation: When CMK is enabled, Atlas automatically rotates the MongoDB Master Key at least every 90 days, scheduled during your configured Maintenance Window.

5-2. In Transit — Encrypting Data in Motion

Atlas enforces TLS by default. Connections without TLS are rejected. From 2025, TLS 1.3 is being rolled out fleet-wide.

# Enforce minimum TLS version via Resource Policy
# Blocks TLS 1.0 and 1.1
atlas clusters update myCluster \
  --minimumEnabledTlsProtocol "TLS1_2"

5-3. In Use — Encrypting Data While Processing (Queryable Encryption)

The strongest encryption layer available. Data is encrypted on the client before reaching the server — Atlas holds only ciphertext. Neither MongoDB employees nor the cloud provider can access plaintext.

// Queryable Encryption setup example (Node.js)
const { ClientEncryption } = require('mongodb-client-encryption');

const encryptedClient = new MongoClient(uri, {
  autoEncryption: {
    keyVaultNamespace: "encryption.__keyVault",
    kmsProviders: {
      aws: {
        accessKeyId: process.env.AWS_ACCESS_KEY_ID,
        secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY
      }
    },
    encryptedFieldsMap: {
      "mydb.users": {
        fields: [
          {
            path: "ssn",
            bsonType: "string",
            queries: { queryType: "equality" }
          },
          {
            path: "creditCard",
            bsonType: "string",
            queries: { queryType: "equality" }
          }
        ]
      }
    }
  }
});

// Querying by ssn — the server processes only ciphertext
const user = await db.collection("users").findOne({ ssn: "900101-1234567" });

CSFLE vs Queryable Encryption:

6. Audit Logs — Who Did What

Tracking what happened is a core part of security. Database Auditing is available on M10+ clusters.

6-1. Enabling Audit Logging

# Enable auditing via Atlas CLI
atlas auditing update \
  --auditFilter '{"atype": {"$in": ["authenticate", "authCheck", "createCollection", "dropCollection", "createIndex", "dropIndex", "createUser", "dropUser", "updateUser"]}}' \
  --auditAuthorizationSuccess false

Setting --auditAuthorizationSuccess false excludes successful authorizations from logs, preventing log volume from becoming unmanageable.

6-2. Critical Events to Audit

{
  "atype": {
    "$in": [
      "authenticate",       // Login attempts (success and failure)
      "authCheck",          // Permission checks
      "createCollection",   // Collection creation
      "dropCollection",     // Collection deletion (always track)
      "dropDatabase",       // Database deletion (always track)
      "createIndex",        // Index creation
      "createUser",         // User creation
      "dropUser",           // User deletion
      "updateUser",         // Permission changes
      "logout"              // Logout
    ]
  }
}

6-3. Exporting Logs to External Systems (Push-based Log Export)

The 2025 update introduced Push-based Log Export. Atlas automatically pushes logs to external systems, making SIEM integration much easier.

7. Compliance — GDPR, PCI DSS, HIPAA

Atlas holds a range of global compliance certifications that substantially reduce the regulatory burden on your team.

Atlas certifications and compliance posture:

Certification scope (regions, tiers) changes over time. Verify the current state at the MongoDB Trust Center. PCI DSS and FedRAMP coverage in particular may vary by cloud region and cluster tier.

GDPR — Key Checkpoints

Data sovereignty
  Store EU user data only in EU regions (eu-west-1, eu-central-1)
  Prohibit cross-region replication of EU data in multi-region clusters
  Use Global Cluster Zone settings to isolate data geographically

Personal data encryption
  Apply Queryable Encryption to PII fields (name, email, address)
  Revoking the CMK immediately blocks access — usable as a right-to-erasure mechanism

Audit logging
  Record all personal data access events
  Retain logs for a minimum of 12 months

PCI DSS — Key Checkpoints

Network isolation
  Completely ban 0.0.0.0/0 in IP Access List (enforce via Resource Policy)
  Private Endpoint required
  Isolate the card data environment in a separate Atlas Project

Encryption
  Enable CMK-based Encryption at Rest
  Enforce TLS 1.2 or higher (Resource Policy)
  Apply Queryable Encryption to card number fields

Access control
  RBAC with least-privilege principle (PoLP)
  Enforce MFA
  Log all access events and retain for 12 months

8. Top 5 Security Pitfalls

These are the Atlas security incidents that actually happen in production.

Pitfall 1: Leaving 0.0.0.0/0 After Temporary Testing

A developer adds 0.0.0.0/0 to test a local connection and never removes it. It ends up in a production project.

Fix: Ban 0.0.0.0/0 entries at the organization level using Resource Policy.

Pitfall 2: Using atlasAdmin Credentials in the App

atlasAdmin credentials found in app server environment variables. If those credentials leak, the entire cluster is at risk.

Fix: Create dedicated DB users per app and grant readWrite only on the required databases and collections.

Pitfall 3: Hardcoding Passwords in Connection Strings

// Never do this — credentials hardcoded in code
const uri = "mongodb+srv://admin:MyPassword123!@cluster0.xxxxx.mongodb.net/";

The moment this code reaches GitHub, it is potentially exposed. Accidental public commits happen far more than teams expect.

Fix: Use environment variables, AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault.

// Correct — credentials in environment variables
const uri = `mongodb+srv://${process.env.MONGO_USER}:${process.env.MONGO_PASS}@cluster0.xxxxx.mongodb.net/`;

// Or use AWS Secrets Manager
const secret = await secretsManager.getSecretValue({ SecretId: 'prod/mongodb/credentials' }).promise();
const { username, password } = JSON.parse(secret.SecretString);

Pitfall 4: Audit Logging Disabled

"We have no idea what happened" after a database drop or bulk data exfiltration, because there are no logs.

Fix: Enable Audit Log on every M10+ production cluster immediately. At minimum, capture dropCollection, dropDatabase, createUser, and authenticate events.

Pitfall 5: CMK Created in a Single Region Only

A single-region AWS KMS key goes down with its region. The Atlas cluster becomes completely inaccessible.

Fix: Use AWS KMS Multi-Region Keys. Replicating the key across regions means one region outage does not take down your cluster.

9. Final Security Checklist

Network security

• Confirm no 0.0.0.0/0 entry in IP Access List
• Remove stale entries (offboarded employee IPs, temporary IPs)
• Private Endpoint configured on production clusters
• Resource Policy enforcing wildcard IP ban at org level

Authentication & authorization

• MFA enforced on all Atlas UI accounts
• Dedicated DB user per app (no shared accounts)
• Confirm atlasAdmin is not used by any app server
• No credentials hardcoded in code or config files
• RBAC scoped to least privilege (PoLP)

Encryption

• High-security environments (finance, healthcare): CMK enabled (AWS KMS / Azure KV / GCP KMS)
• Azure KV users: migrate to Secretless authentication (recommended from 2025)
• Sensitive fields (SSN, card numbers): Queryable Encryption applied
• Minimum TLS 1.2 enforced via Resource Policy
• CMK deployments: AWS Multi-Region Key or AKV multi-region configuration

Audit & monitoring

• Audit Log enabled on all M10+ production clusters
• dropDatabase, dropCollection, createUser events included
• Log export to external system configured (Datadog / Splunk / S3)
• Atlas Alerts configured for abnormal authentication failures
• Monthly review of Access List to remove unnecessary entries

Part 3 Summary

References

• MongoDB Atlas security documentation
• MongoDB Atlas network access documentation
• MongoDB Atlas private endpoints documentation
• MongoDB Atlas database users and roles
• MongoDB Atlas encryption at rest documentation
• MongoDB Atlas auditing documentation
• MongoDB Trust Center