Auditing access to Db2

Security auditing allows you to inspect and examine the adequacy and effectiveness of the policies and procedures that you put in place to secure your data.

Db2 provides the ability for you to monitor if your security plan is adequately designed based on your security objectives and determine if your implementation techniques and procedures are effectively carried out to protect your data access and consistency. It enables you to address the following fundamental questions about your data security.

• What sensitive data requires authorized access?
• Who is privileged to access the data?
• Who has actually accessed the data?
• What attempts are made to gain unauthorized access?

The Db2 catalog contains critical authorization and authentication information. This information provides the primary audit trail for the Db2 subsystem. You can retrieve the information from the catalog tables by issuing SQL queries.

Most of the catalog tables describe the Db2 objects, such as tables, views, table spaces, packages, and plans. Other tables, particularly those with the AUTH character string in their names, hold records of every granted privilege and authority. Each catalog record of a grant contains the following information:

• Name of the object
• Type of privilege
• IDs that receive the privilege
• IDs that grant the privilege
• Time of the grant

The Db2 audit trace can help you monitor and track all the accesses to your protected data. The audit trace records provide another important trail for the Db2 subsystem. You can use the the audit trace to record the following access information:

• Changes in authorization IDs
• Changes to the structure of data, such as dropping a table
• Changes to data values, such as updating or inserting records
• Access attempts by unauthorized IDs
• Results of GRANT statements and REVOKE statements
• Mapping of Kerberos security tickets to IDs
• Other activities that are of interest to auditors