In today's data-driven world, keeping data secure and following rules is very important. For developers and organizations using MongoDB, it's crucial to track and ensure the integrity of user activity within the database. This is where auditing comes in. MongoDB auditing emerges as a champion, offering a meticulous record of user activity within your database. Let's dive deeper and discover how auditing empowers you to fortify your MongoDB environment!

Why Audit Your MongoDB Database?

Auditing provides a detailed record of user actions within your MongoDB database. This record includes inserts, updates, deletes, authentication attempts and more. Having an audit trail offers several benefits:

The main purposes of authentication are:

• Enhanced Security: Auditing helps identify suspicious activity. If a data breach occurs, audit logs can reveal the affected user, data accessed and time of access, allowing for swift mitigation.
• Compliance: Many regulations require organizations to track data access and modifications. Audit logs serve as evidence of compliance with these regulations.
• Troubleshooting: Audit logs can be invaluable for troubleshooting errors or unexpected behavior within your database. By examining the logs, you can pinpoint the user and action that caused the issue.

Note:

Auditing is an enterprise feature and is not available in the Community version of MongoDB. However, it is accessible in MongoDB Enterprise, MongoDB Atlas and Percona MongoDB.

Audit Log Features Evolution in MongoDB

The below table encapsulates the progression and development of auditing features across different MongoDB versions. It highlights the continuous improvements and additions to the auditing capabilities over time.

Implementing Auditing in MongoDB

Implementing auditing in MongoDB involves configuring the audit settings to track and log various database activities.

Note:

Auditing configuration can only be enabled at the config file level. If the MongoDB configuration already exists, a Mongod restart is required to enable auditing on the DB node.

Here's a step-by-step guide on how to implement auditing in MongoDB:

Configuration Parameters Related to Auditing

Before configuring auditing in MongoDB, it's important to be aware of the auditing configuration file parameters and command-line parameters. Below, we provide a detailed explanation:

 
auditLog:   
destination:    
format:    
path:    
filter: 
#runtimeConfiguration: true # Available from v5.0 
	

The below info table provides a clear and structured overview of the configuration parameters, their details and the possible values.

Procedure for Enterprise Version

• Start the mongod process with the above-mentioned auditLog parameters in the config file.

Note:

• For configuring the auditing the Authentication should be enabled.
• If destination: syslog,
  • For Centos: /var/log/messages is the file name
  • For Ubuntu: /var/log/syslog is the file name
• Use bsondump < file name > command to read the BSON audit log.
• If the console is set as the destination for audit logs, these logs will only be displayed in the terminal when the mongod process is running in the foreground. If the mongod process is running in the background, the audit logs will not be displayed anywhere, including the terminal, syslog, or other logging destinations.

• To collect CRUD operations, a few configuration changes are required:
  • Adding Filters: Without a filter, CRUD events will not be collected.
  • Enabling Authorization Success Logging: When using a filter for CRUD operations, you need to add setParameter: { auditAuthorizationSuccess: true }.
  • Ensuring Audit Message Logging: If the filter for CRUD is specified but auditAuthorizationSuccess: true is not included, none of the audit messages will be logged.

Note:

• Even though the destination file is not created, it will be created automatically after restarting the mongo. But if in any case the file is removed while Mongo is running, Then it won’t be created again.

Procedure for Atlas Cluster

Access required: ​​To configure audit logs, you must have Project Owner access to the project that you want to update or Organization Owner access to the organization that contains the project that you want to update.

Steps

• Log in to your Atlas project.
• In the Security section of the left navigation, click Advanced.
• Toggle the button next to Database Auditing to On.
• Confirm that you want to audit authentication failures.
• ​​Select the event actions that you want to audit in Select actions to audit.
• Click Save

Note:

• For customers using MongoDB Atlas who are not on the Enterprise or Platinum plans, there is an additional cost for enabling Database Auditing.
• Specifically, MongoDB Atlas adds a 10% increase to the hourly rate of all dedicated clusters if the project uses Database Auditing.

Understanding Audit Log Messages

 
{
    atype: ,  # Action type
    ts : { $date:  }, 
    uuid : { $binary: , $type:  },
    local: { ip: ,port:||isSystemUser:||unix: },
    remote:{ ip: ,port:||isSystemUser:||unix:  },
    users : [ { user: , db:  }, ... ],
    roles: [ { role: , db:  }, ... ],
    param: ,
    result: 
}
	

Description

Sample Log Message

• If any user successfully authenticated:

 
Nov 16 21:46:44 mydbopslabs205 mongod: { "atype" : "authenticate", "ts" : { "$date" : "2022-11-16T21:46:44.321+00:00" }, "local" : { "ip" : "127.0.0.1", "port" : 27017 }, "remote" : { "ip" : "127.0.0.1", "port" : 39062 }, "users" : [ { "user" : "Madhu", "db" : "admin" } ], "roles" : [ { "role" : "root", "db" : "admin" } ], "param" : { "user" : "Madhu", "db" : "admin", "mechanism" : "SCRAM-SHA-256" }, "result" : 0 }
	

• If any user failed to authenticate:

 
Nov 16 21:40:54 mydbopslabs205 mongod: { "atype" : "authenticate", "ts" : { "$date" : "2022-11-16T21:40:54.384+00:00" }, "local" : { "ip" : "127.0.0.1", "port" : 27017 }, "remote" : { "ip" : "127.0.0.1", "port" : 39044 }, "users" : [], "roles" : [], "param" : { "user" : "M", "db" : "admin", "mechanism" : "SCRAM-SHA-1" }, "result" : 18 }
	

• Internal Operations in MongoDB:

 
Nov 16 22:22:23 mydbopslabs205 mongod: { "atype" : "authCheck", "ts" : { "$date" : "2022-11-16T22:22:23.964+00:00" }, "local" : { "ip" : "127.0.0.1", "port" : 27017 }, "remote" : {}, "users" : [], "roles" : [], "param" : { "command" : "find", "ns" : "config.transactions", "args" : { "find" : "transactions", "filter" : { "lastWriteDate" : { "$lt" : { "$date" : "2022-11-16T21:52:23.964+00:00" } } }, "projection" : { "_id" : 1 }, "sort" : { "_id" : 1 }, "readConcern" : {}, "$db" : "config" } }, "result" : 0 }
	

Overview of MongoDB Audit Guarantee

This flowchart ensures a clear understanding of the audit guarantee process in MongoDB, showing how audit events are handled to maintain database integrity and compliance.

Advanced Auditing Features (MongoDB Enterprise)

• MongoDB Enterprise includes robust auditing capabilities for various operations. Once enabled, the audit facility automatically logs all auditable actions as outlined in Audit Event Actions, Details and Results.
• To tailor the audit logs to your needs, you can specify event filters. These filters can be configured either at startup or if preferred, MongoDB can be set up to allow filter specification during runtime.

Syntax:

 
filter: { :  }
	

Sample Filters

• Log All the CURD Operation

 
auditLog:
  filter:{
          atype: "authCheck",
          "param.command":{
          $in: [ "find", "insert", "delete", "update", "findandmodify"]}
          },
setParameter:
  auditAuthorizationSuccess: true
	

Note:

In the filter commands we can use the find(), insertOne(), insertMany(), remove(), updateOne(), updateMany(), findAndModify(). We are not allowed to use the aggregate commands in the filter

Note:

• Filter the operations based on the Action Type

 
filter: '{atype: {$in: [
         "authenticate", "authCheck",
         "renameCollection", "dropCollection", "dropDatabase",
         "createUser", "dropUser", "dropAllUsersFromDatabase", "updateuser",
         "grantRolesToUser", "revokeRolesFromUser", "createRole", "updateRole",
         "dropRole", "dropAllRolesFromDatabase", "grantRolesToRole", "revokeRolesFromRole",
         "grantPrivilegesToRole", "revokePrivilegesFromRole",
         "replSetReconfig",
         "enableSharding", "shardCollection", "addShard", "removeShard",
         "shutdown",
         "applicationMessage"
      ]}}'
	

• Filter the operations if any drop has occurred (collection or database, Users or roles etc)

 
filter: '{ "atype" : /^drop.*/ }'
	

• Filtering the operation from a particular DB using the regular expression

 
filter: '{ atype: "authCheck", "param.command": { $in: [ 
"find", "insert", "delete", "update", "findandmodify" ] }, 
"param.ns": /^test\\./ } }'
	

Runtime Configuration

To configure the auditing filters in run time (which is available from v5.0), we should start the mongod process along with the auditLog.runtimeConfiguration config parameter.

 
Note: If runtimeConfiguration is enabled, then the configuration file cannot be used to specify audit filters or auditAuthorizationSuccess parameters. 

In case if we add those parameters, We will encounter the below errors, 

{"t":{"$date":"2024-05-28T18:12:14.029+00:00"},"s":"D1", "c":"ASSERT",   "id":23074,   "ctx":"main","msg":"User assertion","attr":{"error":"BadValue: auditLog.filter must not be configured when runtime audit configuration is enabled","file":"src/mongo/db/modules/enterprise/src/audit/audit_manager.cpp","line":272}}

{"t":{"$date":"2024-05-28T18:08:28.076Z"},"s":"I",  "c":"CONTROL",  "id":5760901, "ctx":"main","msg":"Applied --setParameter options","attr":{"serverParameters":{"auditAuthorizationSuccess":{"default":false,"value":true}}}}
	

Syntax

 
db.adminCommand(
   {
     setAuditConfig: 1,
     filter: ,
     auditAuthorizationSuccess: 
   })
	

Note: The runtime filter configuration command can only be executed on the primary node of the mongod cluster.

Validate the Audit Configuration (v5.0+)

From v5.0, We have been able to read the configuration details of the auditing by using the below commands.

 
> db.adminCommand({getAuditConfig: 1})
MongoDB Enterprise mongo-sync:PRIMARY> db.adminCommand({getAuditConfig: 1})
{
"generation" : ObjectId("000000000000000000000000"),
"filter" : {
"atype" : "authCheck",
"param.command" : {
"$in" : [
"find",
"insert",
"delete",
"update",
"findAndModify"
]
}
},
"auditAuthorizationSuccess" : true,
"ok" : 1,
"$clusterTime" : {
"clusterTime" : Timestamp(1716920208, 1),
"signature" : {
"hash" : BinData(0,"ssWx0b9FYNxbRxXAZtBTFVcKfI4="),
"keyId" : NumberLong("7374108369310711815")
}
},
"operationTime" : Timestamp(1716920208, 1)
}
	

Runtime Filter Configuration FAQs

We conducted a thorough validation of the feature and reviewed multiple references from various platforms. During this process, we encountered the following queries from users and technical experts:

• What happens to the runtime filter configuration if the mongod services are restarted?

Even if mongod is restarted or stopped and restarted with the same configuration file, the already applied runtime filter will remain unchanged. The filter will only be removed or altered if a new filter is added or if the auditLog feature is disabled.

• Is the runtime filter configuration replicated to secondary nodes in a replica set?

Yes, if both secondary and primary members are configured to support runtime filter changes and mongod services are running, the filter configuration will replicate across the replica set.

• How can we add separate filters for each node in auditing if the filter is replicated?

If filter replication is not desired across all nodes, you can configure different filters for each node using the configuration file filter options. This approach allows you to customize filters independently for primary and secondary nodes.

Best Practices for Managing Audit Logs:

Audit Log Rotation

• As your database grows, managing large audit logs becomes a concern.
• Implementing a log rotation strategy is essential to prevent your logs from consuming excessive storage space.
• Various tools are available for analysing and visualising audit logs, making it easier to identify trends and potential security risks.

Querying the JSON Audit Logs

Use the jq command for querying the audit logs which is in the JSON format.

 
# Querying Based on the “atype” equality: 
> jq '.|select(."atype"=="createCollection")'  /tmp/auditLog.json
# Querying the nested fields
> jq '.|select([["local","ip"],"127.0.0.1"])'  /tmp/auditLog.json
	

For more details refer to the Jq document as per the requirement.

By implementing auditing in your MongoDB environment, you gain a valuable layer of security and demonstrate compliance with relevant regulations. Audit logs provide a clear picture of user activity within your database, allowing you to identify and address any suspicious behavior. So, take charge of your data security and enable auditing in your MongoDB database today!

Enhance Your MongoDB Security with Mydbops. We offer expert MongoB Managed, Consulting and Remote DBA Services. Contact Mydbops today for personalised MongoDB consultation.

{{cta}}