Auditing and Compliance Capabilities: What to Log, Protect, Retain, and Review

Learning objectives

1. Diagnostic logs, database audit logs, and domain audit events are different evidence streams

A diagnostic log helps operate the server and includes events such as authentication failures, startup configuration, connections, slow operations, and errors. MongoDB database auditing is a dedicated Enterprise/Atlas capability that records auditable security/database actions under an audit schema and filter. An application domain audit event records business facts such as “refund approved by operator 42.” None of these streams automatically substitutes for the others.

2. Free/local path: generate security signals and inspect Community diagnostic logs

Community Edition can still teach evidence handling without pretending it has Enterprise auditing. The lab creates an administrator, a read-only service, one failed login, and one unauthorized write. Then it extracts relevant diagnostic log lines. Exact message IDs/wording can change across releases, so filter by component/severity/keywords and inspect the structured JSON fields on your actual 8.3.8 build rather than hard-coding one message string as a contract.

docker rm -f atlasmart-ch22-l5 2>/dev/null || truedocker volume rm atlasmart-ch22-l5-db 2>/dev/null || truedocker run -d --name atlasmart-ch22-l5 \  -p 127.0.0.1:27180:27017 \  -v atlasmart-ch22-l5-db:/data/db \  mongodb/mongodb-community-server:8.3.8-ubuntu2204-slim \  --auth --bind_ip_all --port 27017until docker logs atlasmart-ch22-l5 2>&1 | grep -q "Waiting for connections"; do sleep 1; done# The first administrator is created from inside the server container so the# connection is genuinely local to mongod. Do not depend on Docker NAT for the# localhost exception.docker exec atlasmart-ch22-l5 mongosh --quiet --host 127.0.0.1 --port 27017 --eval '  const a=db.getSiblingDB("admin");  a.createUser({user:"atlasAdmin",pwd:"local-only-change-me",roles:[{role:"root",db:"admin"}],mechanisms:["SCRAM-SHA-256"]});  printjson(a.runCommand({connectionStatus:1}));'mongosh "mongodb://atlasAdmin:local-only-change-me@127.0.0.1:27180/admin?authSource=admin" --quiet --eval 'db.runCommand({ping:1})' mongosh "mongodb://atlasAdmin:local-only-change-me@127.0.0.1:27180/admin?authSource=admin" --quiet --eval '  const app=db.getSiblingDB("atlasmart");  app.createUser({user:"report-api",pwd:"report-local-only",roles:[{role:"read",db:"atlasmart"}],mechanisms:["SCRAM-SHA-256"]});  app.orders.insertOne({orderId:"AUD-22",status:"created"});'# Failed authentication.mongosh "mongodb://report-api:WRONG@127.0.0.1:27180/atlasmart?authSource=atlasmart" \  --quiet --eval 'db.runCommand({ping:1})' || true# Successful login, then an authorization failure because read cannot insert.mongosh "mongodb://report-api:report-local-only@127.0.0.1:27180/atlasmart?authSource=atlasmart" \  --quiet --eval 'printjson(db.orders.findOne({orderId:"AUD-22"})); db.orders.insertOne({orderId:"DENIED"})' || true# Inspect local evidence. Preserve full structured lines in a real investigation.docker logs atlasmart-ch22-l5 2>&1 | grep -Ei 'auth|unauthor|access|connection' | tail -n 40

3. Enterprise auditing: choose events deliberately and budget the cost

MongoDB Enterprise can emit audit events to console, syslog, JSON, or BSON destinations and filter auditable actions. CRUD auditing relies on authCheck authorization successes, so auditAuthorizationSuccess must be enabled for successful reads/writes—and MongoDB warns that doing so adds more performance overhead than logging authorization failures only. Starting in MongoDB 8.0, Enterprise audit output can also use the Open Cybersecurity Schema Framework (OCSF) schema.

storage:  dbPath: /var/lib/mongodbsecurity:  authorization: enabledauditLog:  destination: file  format: JSON  path: /var/log/mongodb/audit.json  schema: OCSF  filter: '{ "category_uid": 4 }'setParameter:  auditAuthorizationSuccess: false

If the compliance requirement truly needs successful CRUD authorization events, widen the filter and enable authorization-success auditing only after load testing. A broad “audit everything” policy can materially increase resource usage and log volume. Audit configuration itself is security-sensitive and should be change-controlled and monitored.

4. Atlas auditing has a managed boundary and a tier boundary

Atlas database auditing is available on M10 and larger clusters and is not available on Free or Flex. Atlas lets project administrators choose users/roles/actions or provide a custom JSON audit filter. Changing audit configuration can cause rolling updates/elections, and enabling authorization successes can significantly increase cost/overhead. Therefore an Atlas production plan should record cluster tier, selected events, retention/export path, review ownership, and the operational effect of changing the filter.

5. Protect the evidence: collection is not enough

Security logs can contain usernames, source addresses, namespace names, command metadata, and—depending on verbosity/configuration—potentially sensitive client data. Audit evidence is valuable only if attackers and ordinary administrators cannot quietly rewrite or delete it. Forward important records to an independent, access-controlled store; define retention and deletion authority; monitor ingestion gaps; synchronize timestamps without manually skewing the lab clock; and test that investigators can retrieve the required interval.

• Minimize sensitive content: do not log secrets, tokens, full connection strings, or unnecessary document bodies. Enterprise/Atlas log redaction features have edition boundaries; application logs need their own redaction.
• Protect integrity: restrict write/delete rights on the evidence destination and consider immutable/WORM controls where regulation requires them.
• Define retention: keep evidence long enough for business/regulatory detection windows, but not indefinitely without purpose.
• Review: alert on failed logins, privilege/user changes, repeated authorization failures, unexpected admin sources, audit-configuration changes, certificate rotations, and backup/restore administration.
• Reconcile: compare database/platform/application evidence during exercises; a missing stream is itself a signal.

6. A control matrix prevents edition confusion

7. Verification, cleanup, and production judgment

• A failed password and a denied write produce observable Community diagnostic evidence.
• The lesson never describes Community diagnostic logs as Enterprise auditing.
• Enterprise audit configuration is labeled optional/non-Community and includes a narrow filter.
• Atlas auditing is labeled M10+ and unavailable Free/Flex.
• Evidence protection includes integrity, access, redaction, retention, review, and ingestion-gap monitoring.

Auditing is not a checkbox that makes a deployment compliant. Start from an investigation/control objective, capture only the evidence needed to meet it, preserve integrity and availability of the records, assign reviewers, test retrieval, and measure overhead. Remember that MongoDB audit events from an aborted transaction can exist even though there is no audit event that simply says the transaction aborted; investigators must correlate database state and transaction/application evidence. Chapter 23 continues the security model by moving from identity and transport protection to encryption at rest and in-use/client-side encryption boundaries.

docker rm -f atlasmart-ch22-l5 2>/dev/null || truedocker volume rm atlasmart-ch22-l5-db 2>/dev/null || true

Authoritative references

Version-sensitive behavior in this lesson was checked against current MongoDB documentation at generation time. Re-check these sources before applying the procedures to a later server or managed-service release.

• MongoDB Security
• Security Checklist for Self-Managed Deployments
• Localhost Exception in Self-Managed Deployments
• Role-Based Access Control in Self-Managed Deployments
• SCRAM Authentication
• createUser Command
• Built-In Roles
• Privilege Actions
• User-Defined Roles
• Configure MongoDB Instances for TLS
• Connection String TLS Options
• Self-Managed Internal/Membership Authentication
• Rotate Keys for Self-Managed Replica Sets
• rotateCertificates Command
• IP Binding in Self-Managed Deployments
• Auditing
• Configure Audit Filters
• System Event Audit Messages
• Atlas Database Auditing
• MongoDB 8.3 Release Notes
• mongosh Release Notes
• PyMongo Release Notes