The patch allows logging every access to patron personal data by staff members. This enables tracking of abnormal usage patterns in order to discover and mitigate possible data breaches, and the data collected could also be useful for investigators if such an event where to occur. An entry is written to the actions_log table when any page the patron-info sidebar is displayed on is viewed.
Created attachment 131589 [details] [review] Bug 30279: Log viewing of personal data in staff client Add possiblilty to log when personal data is viewed by staff in the web interface. To test: 1) Enable the system preference "PatronViewLog" 2) Visit any page where the patron-info sidebar is displayed 3) Verify that an log entry has been created for module "MEMBERS" and action "VIEW" in the action_logs table 4) Disable the system preference and perform step 2) again 5) Verify that no new log entries for the above module and action has been created Sponsored-by: Gothenburg University Library
Created attachment 131590 [details] [review] Bug 30279: Log viewing of personal data in staff client Add possiblilty to log when personal data is viewed by staff in the web interface. To test: 1) Enable the system preference "PatronViewLog" 2) Visit any page where the patron-info sidebar is displayed 3) Verify that an log entry has been created for module "MEMBERS" and action "VIEW" in the action_logs table 4) Disable the system preference and perform step 2) again 5) Verify that no new log entries for the above module and action has been created Sponsored-by: Gothenburg University Library
A couple things to note here: 1. On viewlog.tt PatronViewLog should probably have it's own checkbox under 'Modules' so you can search the logs for that specifically. 2. The act of checking out an item puts several entry's into the logs. If I land on the patrons detail page (1 log), move to the Check out page ( 2nd log ), check something out ( 3rd log ), and so on. That seems like a lot of logging. 3. QA tool is complaining about missing filters: FAIL koha-tmpl/intranet-tmpl/prog/en/includes/circ-menu.inc FAIL filters missing_filter at line 6 ([% ViewLog.log_patron_view(patron.borrowernumber) %])
(In reply to Lucas Gass from comment #3) > A couple things to note here: > > 1. On viewlog.tt PatronViewLog should probably have it's own checkbox under > 'Modules' so you can search the logs for that specifically. > > 2. The act of checking out an item puts several entry's into the logs. If I > land on the patrons detail page (1 log), move to the Check out page ( 2nd > log ), check something out ( 3rd log ), and so on. That seems like a lot of > logging. > > 3. QA tool is complaining about missing filters: > > FAIL koha-tmpl/intranet-tmpl/prog/en/includes/circ-menu.inc > FAIL filters > missing_filter at line 6 ([% > ViewLog.log_patron_view(patron.borrowernumber) %]) 1 and 2 are just my thoughts, but I will set this to FQA because of 3, the missing filter.
(In reply to Lucas Gass from comment #4) > (In reply to Lucas Gass from comment #3) > > A couple things to note here: > > > > 1. On viewlog.tt PatronViewLog should probably have it's own checkbox under > > 'Modules' so you can search the logs for that specifically. > > > > 2. The act of checking out an item puts several entry's into the logs. If I > > land on the patrons detail page (1 log), move to the Check out page ( 2nd > > log ), check something out ( 3rd log ), and so on. That seems like a lot of > > logging. > > > > 3. QA tool is complaining about missing filters: > > > > FAIL koha-tmpl/intranet-tmpl/prog/en/includes/circ-menu.inc > > FAIL filters > > missing_filter at line 6 ([% > > ViewLog.log_patron_view(patron.borrowernumber) %]) > > 1 and 2 are just my thoughts, but I will set this to FQA because of 3, the > missing filter. As a response to point 2: I took part in the initial design and background to this feature that looked for an efficient way to log every page rendering in Koha that exposed patron information - this is achieved in a simple yet powerful way by this Gothenburg implementation. The idea is that you should be able to tell when patron information has been exposed within the staff client.
Created attachment 131653 [details] [review] Bug 30279: Add view action to system log page and fix QA tool issue
Thank you for the feedback/review. The filter issue should (hopefully) now be fixed. The method called in the template does not return anything and a filter makes no sense, but it should be resolved by using the CALL directive which does not expect a return value. Also added the new action on the page for browsing action-logs. Regarding excessive logging it's simply part of the spec of this feature as Ola pointed out. As logging of patron views is disabled by default and has to be enabled I assume those who enable it are aware that a new log entry will be created each time the patron info is shown.
Hi David, I get this error message trying to apply the patch on a devbox : Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 30279: Log viewing of personal data in staff client Using index info to reconstruct a base tree... M installer/data/mysql/mandatory/sysprefs.sql M koha-tmpl/intranet-tmpl/prog/en/includes/circ-menu.inc M koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/logs.pref Falling back to patching base and 3-way merge... Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/logs.pref CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/logs.pref Auto-merging koha-tmpl/intranet-tmpl/prog/en/includes/circ-menu.inc Auto-merging installer/data/mysql/mandatory/sysprefs.sql error: Failed to merge in the changes. Patch failed at 0001 Bug 30279: Log viewing of personal data in staff client hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-30279-Log-viewing-of-personal-data-in-staff-cl-iw9yB4.patch I'll be happy to test it when it's fixed ! Séverine
Created attachment 132604 [details] [review] Bug 30279: Log viewing of personal data in staff client Add possiblilty to log when personal data is viewed by staff in the web interface. To test: 1) Enable the system preference "PatronViewLog" 2) Visit any page where the patron-info sidebar is displayed 3) Verify that an log entry has been created for module "MEMBERS" and action "VIEW" in the action_logs table 4) Disable the system preference and perform step 2) again 5) Verify that no new log entries for the above module and action has been created Sponsored-by: Gothenburg University Library
Created attachment 132605 [details] [review] Bug 30279: Add view action to system log page and fix QA tool issue
Thanks. Rebased against master so conflicts should now be resolved.
Nice useful feature ! I noticed that the name of the module is 'Patrons' and not 'MEMBERS' as written in test plan. 2 logs are created when I search a patron using the main search box, whatever the tab I use (check out or search patron). It doesn't happen when you use the search form. I wonder if it should create log if HidePersonalPatronDetailOnCirculation is enabled : in that case, none of the personal datas are display out of the 'moremember.pl' page. Maybe this point is out of purpose, but we've got many other ways to access user's personal datas for example in the different search results or the hold pop-up. Shouldn't this be logged too ?
> Maybe this point is out of purpose, but we've got many other ways to access > user's personal datas for example in the different search results or the > hold pop-up. Shouldn't this be logged too ? Also when using the reports module.
There will be various ways of accessing personal information if you are skilled in Koha but the idea is to log obvious upfront abuse by staff. There will, when this patch is in place, be possible to communicate in the organisation that the system logs abuse of the Koha system.
Patron data can also be accessed via the REST-api, via the svc-api and via ILS-DI and via SIP2, and reports and plugins. A reasonable goal might be that all access to borrower information by a staff user with only edit_patron permissions should be logged. Maybe it is sufficient to add logging to the REST-api and svc-api in addition to this patch?