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:

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

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

You can see many more examples at 

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:

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 "{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.

The post Security Auditing for MongoDB on Atlas appeared first on Blog.

*** This is a Security Bloggers Network syndicated blog from Blog authored by Ron Bennatan. Read the original post at: