×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
As an Amazon Associate we earn from qualifying purchases.