Security Auditing for MongoDB on Atlas

MongoDB is a 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). Atlas provides all of the features of its database counterpart, without the operation and heavy lifting normally required when building new applications. It 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-premise. Let’s explore the native audit capabilities of MongoDB and MongoDB Atlas.

Auditing capabilities in MongoDB

Auditing in MongoDB is only available in MongoDB Enterprise – not in the free version. You 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 configuration file:

auditLog:
  destination: syslog

The following operations are recorded to the audit trail:

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

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’ll 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.:

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

You can see many more examples at https://docs.mongodb.com/manual/tutorial/configure-audit-filters/

Auditing in MongoDB 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, then Enterprise Security and toggle the Database Auditing to On. Then click on Select Users and Roles and select the database’s 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 its own log files and Atlas retains these files for 30 days. To access them, you will need to automate the retrieval of these files and store 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:

https://cloud.mongodb.com/api/atlas/v1.0

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 to 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 "https://cloud.mongodb.com/api/atlas/v1.0/groups/{GROUP-ID}/audit-log"
\\
--data '{
  "auditAuthorizationSuccess": false,
  "auditFilter": "{ \\”atype\\”: { \\”$in\\”: [ \\"createUser\\", \\"updateUser\\", \\“dropUser\\” ] } }",
  "enabled": true
  }'

Now, if you want to forgo native auditing and get a truly simple solution, check out how our customers are using Imperva’s Sonar Platform for security and compliance of MongoDB and MongoDB Atlas. Contact us to learn more.