Auditing & Data History

Auditing

To comply with data protection regulation, we need to make sure that SORMAS provides an audit log trail which can be easily ingested by dedicated log processing systems and allows investigation by officials.

Use cases:

• User opens case in UI -> call to backend method CaseFacade.getCaseDataByUuid needs to be logged
• User edits/deletes case in UI -> call to backend method CaseFacade.save/deleteCase needs to be logged
• User does export -> call to CaseFacade.getExportList needs to be logged
• User opens case directory -> call to CaseFacade.getIndexList needs to be logged

High-Level Explanation

The audit trail gets populated by automatically logging every invocation of a facade/EJB method. By this, we can trace every interaction with the system (i.e., via Vaadin UI or REST). We output the collected logs to a user configurable log sink such that the logs can be easily ingested for further processing.

The most important module that is covered is the SORMAS backend.

Related epic: https://github.com/hzi-braunschweig/SORMAS-Project/issues/7904

Data History

Use case: A user observes incorrect data in a few cases. To understand how exactly this came to be it should be possible to extract the change history of the cases, including what exactly changed, at what point in time and by which user the change was made.

Goals:

1. Provide the information when and by whom a change was made
2. Provide what was changed / what the data looked like before and after the change

SORMAS uses Postgres temporal tables to provide a history of all data changes. These automatically create a copy of the previous status in a history table each time a database entry is changed and provide it with a validity period. This also makes it possible to query the status of the data at any time in the past with simple SQL queries.