35.1.1Audit Log

The Smile CDR audit log is responsible for creating a record of user access to the system, including:

• Accesses (both read and write) to the FHIR Endpoints
• Accesses (both read and write) to the Web Admin Console and JSON Admin API
• User authentication against security endpoints
• Configuration changes

The responsibility of the audit log is to bind these events to a specific user account. Note that user accounts marked as a Service Account will not generate audit log entries.

The audit log is a part of the Smile CDR Cluster Manager module, and runs on every node in a cluster. Configuration for the cluster manager is stored in the Node Configuration Properties File.

35.1.2Audit Log Configuration

The following properties may be used to control the Audit Log.

• audit_log.db.enabled – Controls whether the audit log will be written to the database. The default value is true. If set to false, no new entries will be written to the database (existing entries are not deleted simply by modifying this setting).
• audit_log.broker.enabled – Controls whether the audit log will be written to a message broker queue named smilecdr-audit. The default value is false. If set to true, all audit log entries will be written to the queue. If the Smile CDR Message Broker is Kafka, then the audit messages are written to a topic called smilecdr.audit.
• audit_log.request_headers_to_store – Controls which request headers Smile CDR will extract and store along with the audit event. If left empty, no headers will be stored.

35.1.3Disabling the Audit Log

The following snippet may be added to your configuration properties file to completely disable the audit log.

module.clustermgr.config.audit_log.db.enabled=false
module.clustermgr.config.audit_log.broker.enabled=false

35.1.4Broker Audit Log

Audit log messages written to the queue or topic have a format similar to the following example:

{
  "endpointModuleId" : "fhir_endpoint",
  "endpointNodeId" : "unit_test_node",
  "remoteAddress" : "127.0.0.1",
  "targetModules" : [ ],
  "targetResources" : [ {
    "persistenceModuleModuleId" : "persistence",
    "persistenceModuleNodeId" : "unit_test_node",
    "resourceId" : "Patient/1",
    "resourceVersion" : 1
  } ],
  "targetUsers" : [ ],
  "timestamp" : "2019-11-18T11:08:36.479-05:00",
  "typeCode" : "FHIR_VREAD",
  "typeDisplay" : "FHIR Resource Instance Read (Version-specific)",
  "typeSystem" : "https://smilecdr.com/ns/CodeSystem/CdrAuditEvents",
  "username" : "ADMIN",
  "userModuleId" : "local_security",
  "userNodeId" : "unit_test_node",
  "authenticatedUserType" : "USER"
}

35.1.5Audit Module

It is recommended to split the audit log away from your primary Cluster Manager database. This is possible by creating a module of type AUDIT_LOG_PERSISTENCE. Creating such a module will permit you to define a database separate from your Cluster Manager database. One reason for doing this is to reduce traffic on your primary Cluster Manager database, but there are potential security and retention reasons as well. Below is a diagram showing the relationship between the Cluster Manager and the Audit Log Persistence module, and how audit logs are propagated throughout the system.

The following example has a Cluster Manager module, along with two Audit Log Persistence modules. The Web Admin module is there to show that it is possible to have multiple Audit Log Persistence modules, and that the Web Admin module can query any of them.

Note that there are a few minor differences between this separate module's audit logs, and the Cluster Manager's audit logs.

• The Audit Log Persistence module does not contain database constraints on the client PID or user PID fields of the Audit Logs. These fields are later populated with cluster manager data upon viewing.
• The Audit Log Persistence module does not support sending messages to a broker. We plan to provide a new AUDIT_LOG_BROKER module type in the future to support this.

35.1.5.1Cluster Manager in conjunction with Audit Modules

If any Audit modules are defined, the cluster manager will stop writing audit logs to its own database, favouring instead writing to each available Audit module. This behaviour can be changed by enabling the audit_log.db.always_write_to_clustermgr property on the Cluster Manager. If this is enabled, the Cluster Manager will continue to write audit logs to its own database, in addition to any Audit modules that are defined.

35.1.5.2Viewing Audit Logs on alternate modules.

When viewing the Web Admin console's Audit Log page, you must now select an audit module to view.