Re: DB2/400 logging of read only access

Mike

A word of caution, my understanding is that read triggers drastically
impact performance. With a read trigger things like blocked reads, etc.
are not available. The recommendation I've heard is to at least double
memory and CPU resources to handle the triggers. This may not be so big
if the file *REALLY* is not accessed often. I think the recommendation to
do object auditing generally makes more sense.

Michael Quigley
Computer Services
The Way International
www.TheWay.org

midrange-l-bounces@xxxxxxxxxxxx wrote on 08/21/2008 08:07:11 AM:

date: Wed, 20 Aug 2008 22:01:02 -0400
from: Mike Cunningham <mcunning@xxxxxxx>
subject: RE: DB2/400 logging of read only access

True on HIPPA rules but the only way to do that would be at an
application level and if someone were to access all the same records
using DFU and construct up the patients record with cut and paste
operations you would not get that access recorded.

Since we are not covered by HIPPA I was actually thinking of
enhancing the protection of some data elements like SSN and credit
card numbers which I encrypt but would still like to be able to tell
who read any file that has any of this type of data. I was thinking
of moving this data to a file with only this data and journaling
everything that accesses it so even if someone were to gain access
(odbc, jdbc, dfu, etc, etc, etc) I know the db is recording
everything. A trigger might work fine for this since the file is not
accessed often and the overhead of the trigger processing would not
be that great. I could also do some scans against the journals
looking for activity I do not expect (ignore anything logged from
one of our applications that are allowed to use the data) and send
myself an alert