MongoDB is document oriented NoSQL database that provides, high performance, high availability, and easy scalability. To many, it is the leader in the NoSQL space.

MongoDB Atlas was launched in June of 2016 and provides MongoDB as a database-as-a-service (DBaaS). MongoDB Atlas provides all of the features of its database counterpart, without the operation and heavy lifting normally required when building new applications. MongoDB Atlas is available on-demand through a pay-as-you-go model and billed on an hourly basis.

One of the main concerns when moving workloads to a cloud provider such as Atlas is providing the same level of security and audit that you have on-prem. Luckily, MongoDB Atlas provides you with these capabilities. In this blog I’ll review the audit capabilities within MonngoDB and Atlas and how to use them.

Auditing in MongoDB

Auditing in MongoDB is only available in MongoDB Enterprise – not in the free version. Auditing in MongoDB can write audit events to the console, to syslog, to a JSON file, or to a BSON file. You configure the audit option using the –auditDestination qualifier. For example, to send audit events as JSON events to syslog use:

mongod --dbpath data/db --auditDestination syslog

Or, add it to your mongod.conf configuation file:

   destination: syslog

The following operations are recorded to the audit trail:

    • Schema operations (equivalent to DDL)
    • Replica set and sharded cluster operations
    • Authentication and authorization operations
  • CRUD operations

Each audit record has a structure of:

  atype: <Action Type>,
  ts : { "$date": <timestamp> },
  local: { ip: <String>, port: <int> },
  remote: { ip: <String>, port: <int> },
  users : [ { user: <String>, db: <String> }, ... ],
  roles: [ { role: <String>, db: <String> }, ... ],
  param: <event detailes>,
  result: <error code>

Action types include authenticate, authCheck, createCollection, createDatabase, createIndex, renameCollection, dropCollection, dropDatabase, dropIndex, createUser, dropUser, updateUser, dropAllUsersFromDatabase, grantRolesToUser, revokeRolesFromUser, createRole, dropRole, updateRole, dropAllRolesFromDatabase, shutdown, removeShard and more.

You need to tell the system which events you want to audit using the –auditFilter option. These are filters that allow you to specify the condition by which audit records are created. For example, if you want to audit all createUser, updateUser and dropUser commands use:

--auditFilter '{ atype: { $in: [ "createUser", "updateUser", “dropUser” ] } }'

You can specify this in the command line or in your config file, e.g.:

   destination: syslog

   filter: '{ atype: { $in: [ "createUser", "updateUser", “dropUser” ] } }'

You can see many more examples at

Auditing in Atlas

MongoDB Atlas supports auditing for all M10 and larger clusters – i.e. it is not available in M2, M5 or M0 (free tier).

There are two types of auditing that you can enable in Atlas – auditing of database operations and auditing of Atlas-level operations. The database tier auditing is as described above. Atlas auditing allows you to also audit activities done to the Atlas configuration itself.

To enable Atlas auditing you need to click on Security and then Enterprise Security and toggle the Database Auditing to On. Then click on Select Users and Roles and  select the databases users, Atlas roles and/or LDAP groups for which you want auditing to be enabled. Finally, select which operations to audit using Select Actions to Audit.

Atlas auditing always goes to log files. Each mongod and mongos instance generates it’s own log files and Atlas retains these files for 30 days to you will need to automate the retrieval of these files and storing them in some security data lake. You can download files manually using the Atlas UI but more commonly you will call a REST API to retrieve the logs. The REST API takes the form of:

Where you specify which log file you want using:

GET /groups/{GROUP-ID}/clusters/{HOSTNAME}/logs/{LOG-NAME}

And specify the timeframe for which you want the logs using the optional startDate and endDate parameters. Note that for full automation you will need ot know what files are there, do some kind of pagination to bring new files vs old files, etc.

In order to specify the audit filters use the same REST API endpoint as above with:

PATCH /groups/{GROUP-ID}/auditLog

Where GROUP-ID is the unique identifier for the project and the data document can include the same auditFilter as used for base MongoDB, e.g.:

curl -u "username:apiKey" --digest \
 --header "Accept: application/json" \
 --header "Content-Type: application/json" \
 --request PATCH "{GROUP-ID}/audit-log" \
 --data '{
   "auditAuthorizationSuccess": false,
   "auditFilter": "{ \”atype\”: { \”$in\”: [ \"createUser\", \"updateUser\", \“dropUser\” ] } }",
   "enabled": true

Finally, if you just want this auditing capability given to you ready-made and as a service take a look at jSonar’s Database Security 2.0 service at