GDPR: Trace read access of DB tables - Forum - OpenEdge RDBMS - Progress Community

GDPR: Trace read access of DB tables

 Forum

GDPR: Trace read access of DB tables

This question is answered

Problem: How can one log and trace out that XYZ user has accessed N records from a DB table. In this particular scenario the DB will be accessed thru Progress Editor (multi user session). Progress OE version 11.5.1 Enterprise RDBMS

Note: This is related to GDPR that comes into effect in EU from 25-May-2018.

Verified Answer
  • Auditing does not support FIND events.

    You can create user defined audit events but those are only as good as the code that fires them (and they won't do you any good if the code is bypassed by an ad-hoc query).

    You could define FIND triggers but:

    1) If the data is frequently accessed you will be imposing a very significant performance penalty.  Users are likely to hunt you down and give you "feedback".  (This is why auditing does not support FIND.  The performance impact would be *huge*.)

    2) There are many ways that FIND triggers might not catch everything.  For instance, triggers can be disabled in code.  And whatever audit trail they might create could possibly be tampered with.

    --
    Tom Bascom
    tom@wss.com

  • I concur that Auditing finds is not a particular good idea. However, there's also Application events in the auditing mechanism which allows you to log when for example somebody open the Employee Details screen/page of Y instead of logging the read of the records. This way you can at least see that person X accessed the employee details of Y, which should be enough in most use cases (imho).

All Replies
  • I think that it is good way to use OpenEdge Auditing for this purpose. But I do not remember if the FIND event is being tracked there.
    Another option is to create and use a Trigger on the FIND event.
     
  • According to documentation (documentation.progress.com/.../index.html, you can report creates, updates and deletes for a record.

  • Auditing does not support FIND events.

    You can create user defined audit events but those are only as good as the code that fires them (and they won't do you any good if the code is bypassed by an ad-hoc query).

    You could define FIND triggers but:

    1) If the data is frequently accessed you will be imposing a very significant performance penalty.  Users are likely to hunt you down and give you "feedback".  (This is why auditing does not support FIND.  The performance impact would be *huge*.)

    2) There are many ways that FIND triggers might not catch everything.  For instance, triggers can be disabled in code.  And whatever audit trail they might create could possibly be tampered with.

    --
    Tom Bascom
    tom@wss.com

  • I concur that Auditing finds is not a particular good idea. However, there's also Application events in the auditing mechanism which allows you to log when for example somebody open the Employee Details screen/page of Y instead of logging the read of the records. This way you can at least see that person X accessed the employee details of Y, which should be enough in most use cases (imho).

  • This GDPR and Auditing is getting a monster.

    KPMG requests that especially every change of a database admin (user with Admin rights on the server too) should be registered somewhere.

  • I agree with and both. Logging read events is a sensitive topic and we should be really careful as it can have great impact on the system's performance. So log only what you really need to i.e. sensitive data in context of GDPR law. We should refrain ourselves from generalising this solution for all table accesses.

    - If you are looking to log all changes (i.e. CUD but not read) then check Change Data Capture which is available in OpenEdge version 11.7 onwards.

    Thanks for you replies guys.

  • I doubt that GDPR requires recording all reads. When Sarbanes-Oxley came into effect in the US, there were people who claimed that it required recording reads but it does not.