Re: Read Audit Trail

Eftimios Pantzopoulos wrote:

The company I'm working for has asked me whether it's possible
to track all accesses to a file which contains an (encrypted)
credit card number.

From my research I've discovered that there is a READ trigger
on the iSeries DB2 but it is highly recommended that it not be
used, which I can understand.

I've also come across a reference to a DB2 audit function, but
unfortunately, only for the LUW version of DB2

http://publib.boulder.ibm.com/infocenter/db2luw/v8/?topic=/com.ibm.db2.udb.doc/admin/t0011540.htm

I went searching for the function in iSeries DB2 and couldn't
find it. Can anyone tell me if it exists, where any good
documentation for it is, or if not, any alternatives to
tracking access to important data. Perhaps there are better
techniques using normal iSeries authority?

The term /accesses to a file/ might need further clarification to receive a reasonable response; especially given /"read" audit trail/ from the subject, which seems to imply much more. However I offer...

Journaling [aka logging] of the file which explicitly includes [rather than defaulting to omit] open & close log entries, will log for review, the identity of every open request of the file. STRJRNPF to start the logging against the file, and DSPJRN to review the results.

Auditing as I recall can similarly log all /read/ access, actually opens for read access; probably auditing for *ALL accesses is required, since open for update is likely recorded as /change/ access... I really can not recall. CHGOBJAUD to activate the level of auditing against the file after establishing that object auditing is active via the QAUDCTL system value [set to include *OBJAUD special value].

There is also a database file /open/ exit program which could be used to identify all open requests [across effectively all database file member opens on the system]. AFaIK there is still no exit\trigger type of feature specific to the open of a file.mbr except as logged via the journal for a database file [for all data members]. Object auditing is probably better.?

If detail for _which record_ is accessed by a program, only a read trigger will enable generally, irrespective of access method. That is, outside of some function which is deemed /the only/ possible access to the data. In the case such a functional gateway exists to the data, as the presumed sole arbiter to the data, then intuitively that function can record all access details. Sometimes a SQL FUNCTION might provide such a method, for example when any request to read is actually for the decrypted value; such a function would be able to record each case of access to the decrypted value, if logging were acceptable to only that type of access.

As for the DB2 LUW reference... many features of LUW [like of other databases] may be redundant or otherwise unnecessary or just complicate the /integrated/ nature of the DB2 for i5/OS. If for example the LUW auditing was effectively the same as object auditing, having to create a LUW-like auditing which is already handled in an integrated manner across all /objects/ on the i, there is little benefit to IBM or to the customers of DB2 for i to expense the feature and add the overhead of such a feature to the database. Unless such auditing is part of the SQL standards, not just part of other DB2s, without some overriding value to having a feature beyond what the integrated OS\database already provides, such a feature will unlikely find its way into the database. I did not read about the LUW feature, so I do not mean to imply anything about if or why it might or might not find its way into DB2 for i.

Regards, Chuck