Configure Auditing on Self-Managed Deployments

Output to Syslog

To enable auditing and print audit events to the syslog (option is unavailable on Windows) in JSON format, specify syslog for the --auditDestination setting. For example:

mongod --dbpath data/db --auditDestination syslog

Include additional options as required for your configuration. For instance, if you wish remote clients to connect to your deployment or your deployment members are run on different hosts, specify the --bind_ip.

You may also specify these options in the configuration file:

storage:
   dbPath: data/db
auditLog:
   destination: syslog

Output to Console

To enable auditing and print the audit events to standard output (i.e. stdout), specify console for the --auditDestination setting. For example:

mongod --dbpath data/db --auditDestination console

Include additional options as required for your configuration. For instance, if you wish remote clients to connect to your deployment or your deployment members are run on different hosts, specify the --bind_ip.

You may also specify these options in the configuration file:

storage:
   dbPath: data/db
auditLog:
   destination: console

Output to JSON File

To enable auditing and print audit events to a file in JSON format, specify the following options:

For example, the following enables auditing and records audit events to a file with the relative path name of data/db/auditLog.json:

mongod --dbpath data/db --auditDestination file --auditFormat JSON --auditPath data/db/auditLog.json

Include additional options as required for your configuration. For instance, if you wish remote clients to connect to your deployment or your deployment members are run on different hosts, specify the --bind_ip.

The audit file may be rotated with the logRotate command, either alongside the server log or independently. Rotation specifics may be configured with the systemLog.logRotate configuration file option or the --logRotate command-line option.

You may also specify these options in the configuration file:

storage:
   dbPath: data/db
auditLog:
   destination: file
   format: JSON
   path: data/db/auditLog.json

Output to BSON File

To enable auditing and print audit events to a file in BSON binary format, specify the following options:

For example, the following enables auditing and records audit events to a BSON file with the relative path name of data/db/auditLog.bson:

mongod --dbpath data/db --auditDestination file --auditFormat BSON --auditPath data/db/auditLog.bson

Include additional options as required for your configuration. For instance, if you wish remote clients to connect to your deployment or your deployment members are run on different hosts, specify the --bind_ip.

The audit file is rotated at the same time as the server log file. Rotation specifics may be configured with the systemLog.logRotate configuration file option or the --logRotate command-line option.

You may also specify these options in the configuration file:

storage:
   dbPath: data/db
auditLog:
   destination: file
   format: BSON
   path: data/db/auditLog.bson

The following example converts the audit log into readable form using bsondump and outputs the result:

bsondump data/db/auditLog.bson

Output Messages in OCSF Format

Starting in MongoDB 8.0, MongoDB can write log messages in OCSF format. The OCSF schema provides logs in a standardized format compatible with log processors.

To use the OCSF schema for log messages, set the --auditSchema option to OCSF. For example:

mongod --dbpath data/db --auditDestination file --auditFormat JSON --auditPath data/db/auditLog.json --auditSchema OCSF

You can also specify the OCSF schema in the auditLog.schema configuration file option:

storage:
   dbPath: data/db
auditLog:
   destination: file
   format: JSON
   path: data/db/auditLog.json
   schema: OCSF

For more information on the OCSF schema, see OCSF Schema Audit Messages.

Separation of Concerns

Prior to MongoDB 5.0, anyone auditing a MongoDB mongod or mongos instance had to have write access to the host server's file system in order to update audit filters. Runtime Audit Filter Management improves security by separating audit access from administrative access.

Using Runtime Audit Filter Management instead of editing configuration files directly means:

• File system access is not required so an auditor does not need access to the mongod or mongos host server.

• There is no direct access to the mongod or mongos instance's configuration file.

• Runtime Audit Filter Management only exposes audit filters and the auditAuthorizationSuccess parameter.

Runtime Configurability

Starting in MongoDB 5.0, when Runtime Audit Filter Management is enabled, auditing can be reconfigured at runtime without restarting the mongod or mongos instance. A statically configured instance has to be restarted to update its audit settings.

Audit filter modifications made at runtime persist when an instance is shutdown and restarted.

Consistency

Within a cluster, if all participating mongod and mongos nodes are configured to use Runtime Audit Filter Management, then every node will use the same audit filters. In contrast, if each node has its own locally configured audit filters, there is no guarantee of audit filter consistency across nodes.

Enable Runtime Audit Filter Management

Starting in MongoDB 5.0, audit configurations for mongod and mongos nodes can be configured at runtime. A group of these nodes can take part in a distributed audit configuration.

To include a node in a distributed audit configuration, update the node's configuration file as follows and restart the server.

The server logs an error and fails to start if:

• runtimeConfiguration is true and

• either auditLog.filter or auditAuthorizationSuccess is set.

To modify audit filters and the auditAuthorizationSuccess parameter at runtime, see auditConfig.