Why auditing?
-
auditing registers access to confidential or vital enterprise data
-
in some countries there is a legal obligation to "log" all access
to data of a personal nature (e.g. medical data)
-
auditing allows administrative follow-up (e.g. all actions taken for
a given customer number)
-
auditing may be useful for database administration to find out
how tables are accessed
Scope of auditing
-
SQL/AF audits all accesses to designated DB2/VM tables that contain
sensitive or confidential data.
-
SQL/AF audits all DB2/VM clients, that is, all VM/ESA, VSE/ESA and CICS users,
as well as users accessing the DB2/VM database via IBM's DRDA protocol.
-
SQL/AF monitors all table access, both dynamic (QMF, ISQL etc.) and static
(compiled).
-
Depending on the audit rules defined for the table, both read (SQL SELECT)
and write ( SQL DELETE, INSERT, UPDATE) access is audited.
-
By default, auditing is performed at the table level and
audit logging occurs whenever an SQL statement refers to the table.
-
Alternatively, named table-columns can be defined as audit triggers.
Audit logging then occurs whenever an SQL statement refers to these
table-columns.