This module provides full traceability of changes made to the platform, making it possible to:
- Improve regulatory compliance in contexts where an audit system is mandatory
- Trace the people behind a publication or change
- Perform diagnostics and understand a status
This module installs an audit system that records all changes made to the platform and its content. It enables actions to be traced back to the origin of a modification and its author. An option allows you to save the data before and after modifications, and when displayed a ‘diff’ is produced to highlight the changes made.
The data is stored in a table on the SQL server and presented via a dedicated portlet, with numerous search filters.
In terms of performance, there is a small impact due to the fact that data is saved in the database after each action. The added load is proportional to the number of changes/publications made by users. Activating the audit of admin activity is also a load factor, as the DWP's internal activity is also logged.
This module does not audit data access; only changes are recorded. This limits the performance impact of the module: the only system load added is the ‘insert’ instruction used to trace data in the database.
Recorded actions :
- login
- delegation
- create
- update
- clone
- merge
- delete
- deep_delete
- purge
- bin
Monitored resources :
- Publications
- Memberships
- Groups
- Workspaces
- Space creation requests
- Categories
- ACL
Export:
A button can be used to export data from the filtered table in the form of a CSV file that can be opened with Excel or compatible software.
Automatic purge batch processing
Depending on activity, the database table can fill up quickly. A purge batch process is built into the module to avoid saturation. The longer the history and the more active the users, the more the database will fill up.
Integrity check:
A hash is stored with each line in the database: this is used to check whether the line has been altered after saving. When displayed in the portlet, the hash of each record is compared with a new hash calculated to see if the data has been modified. If this is the case, an icon associated with a red colour highlights this.
It will surely be noticed that someone with admin and DBA rights will be able to modify the audit data in order to manipulate it, rendering all traceability null and void. This must be dealt with using the principles of separation of responsibilities: the DBA must not be the DWP admin and the DWP admin must not be the DBA.
RGPD compliance:
This module collects the member's identity and IP addresses, which are considered to be personal data: the implementation of the module must therefore be documented as part of RGPD compliance.
It is possible to deactivate the recording of IP addresses in order to limit the amount of data collected, and the purge mechanism makes it possible to define the retention period.
- Workflow transitions
- Properties
Recorded data :
- Date and time
- Member initiating the action
- Affected element
- Workspace
- User IP address (direct and forwarded)
- Value before change
- Value after change
Auditing isn't just about monitoring, it's also about protecting the people in charge of administration.
Customers love the diagnostic capabilities offered by this module: it's possible to trace the cause of an event and diagnose its origin.
At the same time, traceability also provides protection for administrators, who can prove that they are not behind actions for which they could be held responsible.
