Configure audit logging

Introduction

Casewhere audit logging provides essential information about data changes made within the system, which can be crucial for diagnosing potential or actual security issues. This feature is designed to address key questions in a user-friendly manner:

• Who made the change?
• What was changed?
• When the changes were made?
• Who can access the log data?

Logging is performed at the field level, allowing you not only to configure audit logs for specific data classes but also to track changes in the values of selected fields.

Configuration

Enable audit log in data class

In the Data Class editor, navigate to the tab Audit Log, and configure the following:

• Read Access Rule: to decide who can access the log data. See more here for instructions on how to configure access rules.
• Correlation Id: to identify related log entries.
• Attributes: select fields to enable the audit log. You can control who can access the log data by specifying the access rule.
  • Log data can be enriched with additional information to make it easier to interpret. For instance, logging the Application ID and Application Title when an application is deleted allows users to identify what was removed, as it can otherwise be difficult to determine. This can be done by enabling the On Delete option for the relevant attributes.

When the audit log setting is enabled for a data class, all changes to its data objects will be logged. By default, Casewhere uses the activity name for the log event, but this can be customized. To do so, in the Workflow Definition, go to the Advanced Settings tab and enter a custom Audit Event Name.

View audit log in worker site

Create a page with a custom widget Log. The widget needs a case id to query data, so the setting Required Case Context must be enabled.

The widget template is as follows:

• Html

<div class="row flex-grow">  
    <div class="col-12">   
        <cw-audit-log data-config="auditLogConfig"></cw-audit-log>
    </div>
</div>

• Javascript: in the scope of customWidgetController, append the following code:

$scope.auditLogConfig = {  caseId: $scope.widgetModel.queryParameters.CaseId,  pageSize: 10};

Select a case from Application List to open the log viewer using Open Page action. Following parameters are required for the log viewer to work:

• Id: {{dataObject.Id}}
• CaseId: {{dataObject.CaseId}}

The logging page will appear as shown below:

How to protect the sensitive attributes from viewing by user

In real-world scenarios, sensitive data like credit card numbers or CPR numbers should not be visible to users. Casewhere includes a feature to protect this data from being displayed on the audit log page.

For example, if there is a sensitive attribute called CPRNumber in the Teacher data class that needs protection, you can safeguard it as follows:

1. Open the Teacher data class in the configuration. Enable the Encrypted property of the CPRNumber attribute.

2. Then, choose the MaskFormat for it. The mask format is the property to configure how we want to display the value of the encrypted attribute on the audit log page. In this example, we choose the First 4 option. With this option, if the value is 123456789, it will be displayed as 1234*****.

1. Next, navigate to the Audit Log tab. Ensure we have already checked the Enabled option of the CPRNumber property. Then we have to define an access rule for the encrypted attribute to determine when this attribute should be protected. In the image below, we define an access rule to ensure only the user who has the manager role can view the whole value of the attribute on the audit log page.

@user.Contains("Role", "Manager")

You can learn more about the Casewhere rule here.

1. Open the audit log viewer page, observe the audit log contains the CPRNumber value. With the user does not have the Manager role, the value of the encrypted attribute has been protected properly.