Store audit trail in database

Changes

• Store monitoring logs in the database instead of a separate text file.
• Change the wording from "monitoring" to "audit". This seems to be the more common term.
• Provide useful filters in the admin UI.
• Display audit events related to a subject. This could provide some useful context for users, e.g. when a subject makes a complaint or shows up in the data protection dashboard.
• Display audit events related to a study. This could provide some useful context for study approvers or PIs.
• Store some additional events that are helpful for the previously described use cases.
• Smaller changes
  • no longer include the app in the audit event
  • store username instead of user ID (to keep it useful even if the account was deleted)
  • store study id instead of name

Comparison to previous approaches

• A very similar idea was pitched in !1189 (closed). @goettel mentioned that this was discussed and rejected in the privacy jour fixe, but I was not part of that so I cannot talk about the exact reasons and whether they still apply (this was in february 2020).
  • A major concern back than was the privacy impact on users. I would argue that the data we store about users is much less sensitive than the data we have about subjects (e.g. MRI images). But these logs could be seen as a way of work place surveillance. This also means we may have to involve the works council (Betriebsrat).
• In !1733 (merged) and !1746 (merged) we discussed that monitoring logs are only available if configured explicitly: "Monitoring should be enabled when, and only when, there are workflows in place concerning how to deal with this data."
  • This was in part because users were not aware that monitoring logs even existed. In this version, it is much easier to discover this feature because we are putting it in front of users who actually need it. Server admins arguably were never the correct audience.
  • Deleting old logs is somewhat harder in this version.
  • This version is can currently not be disabled
• For studies, we had a "review changes" view for some time. It was added in !1861 (merged) and removed again in !2398 (merged) because it was very complex and not as useful as we had hoped.
• We allow to export all information stored in castellum about a subject to comply with GDPR 15.3. The monitoring logs were so far not covered by this. I am not sure why.
• In !679 (merged) we removed logging of subject updates when they did not concern special categories of data. I reverted that in b82a216e because these changes provide relevant context for data protection coordinators.

  • As data protection officer I may have to retrace dates of user activity (create, edit, delete) for certain data sets of subjects ("Besondere Kategorien personenbezogener Daten" see https://dsgvo-gesetz.de/bdsg/22-bdsg/) However, this should be done using four eye principle: Data protection officer has to ask sys admin on providing a log excerpt on a certain user or on data set changes on a certain subject.

Benefits

• We reuse existing data to cover new use cases
• We make the monitoring log / audit trail more useful by putting it in front of people who can actually need it
• These logs are a common pattern and users know how to use them
• We only log that a user has performed an action. We do not log the contents (e.g. values of attributes). So there is really not that much information in these logs. One notable exception is subject search, which therefore needs to be enabled separately (see !2486 (merged)).

Downsides

• By mixing different use cases in a single features, it is easy to include too much or too little information.
• By including this data in the UI, we increase the attack surface.
• The information included in these logs is not sufficient to fully cover the new use cases. For example, knowing who last edited a subject may provide useful context to data protection coordinators. But if the only legal basis for keeping a subject's data was a study participation, and all study domains for that study have been deleted, non of that information is included in the audit trail for the subject.