MongoDB Atlas

Defense in Depth
Security on MongoDB Atlas

Five layers of security — network isolation, encryption, authentication, authorization, and auditing — protecting your data from the perimeter to the field level.

Five Layers of Protection

Atlas implements a defense-in-depth model. Each layer operates independently — compromising one never exposes the others.

Secure by Default

Unlike self-managed deployments where security is opt-in, Atlas ships with strong defaults from the moment you create a cluster. No open ports, no anonymous access, no unencrypted connections.

Authentication required — no anonymous access

TLS 1.2+ enforced — all connections encrypted in transit

Encryption at rest — AES-256 on all data

IP allowlist empty — zero access until you explicitly grant it

Network Security

The outermost layer. Control exactly who and what can reach your cluster — from IP allowlists to fully private connectivity that never touches the internet.

VPC Isolation

Dedicated clusters run in a fully isolated VPC/VNet within the Atlas infrastructure. Your data plane is logically separated from all other customers.

AWS VPC Azure VNet GCP VPC

Private Endpoints

Traffic between your application and Atlas stays on the cloud provider's backbone — never traversing the public internet.

AWS PrivateLink Azure Private Link GCP PSC

IP Access List & VPC Peering

Restrict access to trusted IP addresses or CIDR blocks. Alternatively, peer your VPC directly with Atlas for private routing without endpoint services.

CIDR Rules VPC Peering
Atlas Network Access Docs
network_config.tf
# Private Endpoint — AWS PrivateLink resource "mongodbatlas_privatelink_endpoint" "pe" { project_id = var.atlas_project_id provider_name = "AWS" region = "US_EAST_1" } # IP Access List resource "mongodbatlas_project_ip_access_list" "office" { project_id = var.atlas_project_id cidr_block = "203.0.113.0/24" comment = "Office network" } # VPC Peering resource "mongodbatlas_network_peering" "peer" { project_id = var.atlas_project_id container_id = mongodbatlas_cluster.main.container_id provider_name = "AWS" accepter_region_name = "us-east-1" aws_account_id = var.aws_account_id vpc_id = var.vpc_id route_table_cidr_block = "10.0.0.0/16" }
App VPC ⟶ PrivateLink ⟶ Atlas VPC ⟶ Cluster

Encryption at Every Layer

Data is encrypted in transit, at rest, and optionally at the field level — so sensitive fields remain unreadable even to database administrators and MongoDB personnel.

🔐

In Transit

TLS 1.2+ required for all client-to-cluster and intra-cluster communication. Uses OpenSSL FIPS module.

TLS 1.2+
💾

At Rest

AES-256 encrypts all data on disk transparently. Bring your own key (BYOK) via AWS KMS, Azure Key Vault, or GCP KMS.

AES-256 BYOK
🔑

CSFLE

Client-Side Field-Level Encryption encrypts specific fields before they leave the application — server never sees plaintext.

Client-Side
🔍

Queryable Encryption

Run equality and range queries on fully encrypted data. The server processes encrypted queries without ever decrypting.

Query on Encrypted

Queryable Encryption in Action

Queryable Encryption lets you query encrypted fields using equality and range operators. The database processes encrypted values and returns encrypted results — decryption happens only on the client. This protects data from compromised servers, snapshots, and backups.

No server-side exposure — data remains encrypted in memory, logs, and backups.

Automatic encryption — configure once, the driver handles all encryption/decryption transparently.

Range queries — run $gt, $lt, $gte on encrypted numeric and date fields.

queryable_encryption.py
from pymongo import MongoClient from pymongo.encryption import AutoEncryptionOpts # KMS provider config (AWS KMS example) kms = { "aws": { "accessKeyId": os.environ["AWS_KEY"], "secretAccessKey": os.environ["AWS_SECRET"] }} # Encrypted fields configuration encrypted_fields = { "fields": [ { "path": "ssn", "bsonType": "string", "queries": [{ "queryType": "equality" }] }, { "path": "billing.amount", "bsonType": "double", "queries": [{ "queryType": "range" }] } ] } # The driver handles all encryption transparently client = MongoClient( "mongodb+srv://cluster.mongodb.net", auto_encryption_opts=AutoEncryptionOpts( kms_providers=kms, encrypted_fields_map={ "mydb.patients": encrypted_fields } ) ) # Query on encrypted field — server never sees plaintext result = client.mydb.patients.find_one( { "ssn": "123-45-6789" } )

Authentication

Verify who is connecting. Atlas supports multiple authentication mechanisms — from username/password to certificate-based to federated identity.

SCRAM (Default)

Salted Challenge-Response Authentication Mechanism. NIST 800-63B compliant, default for all Atlas clusters.

X.509 Certificates

Authenticate using client certificates from your own PKI. Eliminates passwords entirely for service-to-service communication.

LDAP / Active Directory

Integrate with your corporate directory. Centralize user management and map LDAP groups to MongoDB roles.

AWS IAM Authentication

Use AWS IAM roles for passwordless authentication. Ideal for applications running on EC2, ECS, Lambda.

OIDC / Workforce Identity Federation

Authenticate via Okta, Azure AD, or any OIDC provider. Supports both workforce (human) and workload (service) identity.

Connection Examples

connection_strings.sh
# SCRAM (username/password) mongosh "mongodb+srv://cluster.mongodb.net/mydb" \ --username admin --authenticationDatabase admin # X.509 Certificate mongosh "mongodb+srv://cluster.mongodb.net/mydb" \ --tls --tlsCertificateKeyFile client.pem \ --authenticationMechanism MONGODB-X509 # AWS IAM (passwordless) mongosh "mongodb+srv://cluster.mongodb.net/mydb" \ --authenticationMechanism MONGODB-AWS # OIDC (Workforce Identity) mongosh "mongodb+srv://cluster.mongodb.net/mydb" \ --authenticationMechanism MONGODB-OIDC

Atlas Control Plane

Access to the Atlas UI and API is separately protected by Multi-Factor Authentication (MFA) and Identity Federation (SSO) via SAML or OpenID Connect with providers like Okta and Azure AD.

Authorization & RBAC

Control what each identity can do. Built-in and custom roles implement the principle of least privilege — from organization-wide to field-level granularity.

Built-in RolesreadOnly, readWrite, dbAdmin, clusterMonitor, and more — covering common access patterns.

Custom Roles — define fine-grained privileges per collection or even per field. Combine actions like find, insert, update on specific namespaces.

Field-Level Redaction — use $redact in aggregation pipelines to strip sensitive fields based on the caller's role or clearance level.

Atlas Organization & Project Roles — separate administrative roles for billing, project management, and cluster operations. No single user needs full access.

Secrets Management — integrate with HashiCorp Vault to dynamically issue short-lived database credentials, eliminating long-lived secrets.

custom_role.js
// Custom role: read orders, write only to reviews db.adminCommand({ createRole: "appServiceRole", privileges: [ { resource: { db: "store", collection: "orders" }, actions: ["find"] }, { resource: { db: "store", collection: "reviews" }, actions: ["find", "insert", "update"] } ], roles: [] }) // Field-level redaction in aggregation db.patients.aggregate([ { $redact: { $cond: { if: { $in: ["MEDICAL", "$tags"] }, then: "$$PRUNE", else: "$$DESCEND" } }} ])

Privileged User Access

MongoDB personnel do not have default access to customer clusters. The rare exception requires MFA, management approval, is time-limited, and every action is logged and reviewed.

Auditing & Monitoring

The innermost layer: accountability. Every administrative and database action can be captured, filtered, and forwarded to your SIEM for forensic analysis and compliance evidence.

Database Auditing

Capture all DML/DDL and administrative actions with granular filters. Track actions by user, role, LDAP group, IP address, or operation type. Available on M10+ dedicated clusters.

authCheck CRUD Events DDL Events

Organization & Project Activity Feed

Chronological, filterable log of all administrative actions — user access changes, cluster modifications, network configuration updates, billing events.

UI + API Filterable

SIEM Integration

Export audit logs via the Atlas API for integration with Splunk, Imperva, IBM Guardium, or any SIEM platform. Build alerts, dashboards, and compliance reports.

Splunk Guardium Custom SIEM
audit_filter.json
// Audit filter: capture auth failures + sensitive ops { "$or": [ // All authentication failures { "atype": "authenticate", "param.mechanism": { "$exists": true }, "result": { "$ne": 0 } }, // DDL operations (create, drop, rename) { "atype": { "$in": [ "createCollection", "dropCollection", "dropDatabase", "renameCollection", "createIndex", "dropIndex" ] } }, // Writes to sensitive collections { "atype": "authCheck", "param.ns": { "$regex": "^mydb\\.patients" }, "param.command": { "$in": ["update", "delete", "insert"] } } ] }
ACTION → AUDIT LOG → SIEM → ALERT

Compliance & Certifications

Atlas is audited and certified against the industry's most demanding security and privacy frameworks. These certifications mean fewer controls your team has to build and validate.

🛡️

SOC 2 Type II

Security, availability, and confidentiality controls independently audited annually.

📋

ISO 27001

Information security management system certified by accredited third party.

🏥

HIPAA

BAA available. Atlas supports HIPAA-compliant architectures for healthcare data.

💳

PCI DSS

Level 1 Service Provider compliant for payment card data workloads.

🇪🇺

GDPR

Data processing agreements, EU data residency, and right-to-erasure support.

☁️

CSA STAR

Cloud Security Alliance STAR registry listing with detailed security posture.

🏛️

FedRAMP

Available through MongoDB Atlas for Government (via authorized partners).

🇦🇺

IRAP

Assessed for Australian government workloads under the IRAP framework.

📄

Governance & Risk Management

MongoDB conducts regular cloud provider audits, maintains a structured vulnerability management program using CVSS risk scoring, performs annual penetration tests, and is a MITRE CVE Numbering Authority for identifying and reporting threats.

MongoDB Trust Center

Shared Responsibility Model

Atlas handles infrastructure security so you can focus on application-level controls. Here's where the line is drawn.

Atlas Manages

Physical infrastructure and data center security

OS patching, MongoDB version upgrades, and hotfixes

Always-on encryption at rest (AES-256) and in transit (TLS 1.2+)

Automated backups, snapshots, and point-in-time recovery

Replica set failover and self-healing for high availability

Compliance certifications (SOC 2, ISO 27001, HIPAA, PCI DSS)

VPC/VNet isolation of cluster infrastructure

Vulnerability management, pen testing, and BCDR planning (ISO 22301)

👤

You Manage

Configure IP Access List and network peering / private endpoints

Create database users with appropriate roles (least privilege)

Enable and configure database auditing filters

Set up CSFLE / Queryable Encryption for sensitive fields

Manage BYOK encryption keys in your KMS

Enforce MFA and identity federation for Atlas UI/API access

Application-level input validation and security

Regular review of access permissions and audit logs