DB2 auditing creates evidence that security controls work: who attempted access, who changed privileges, which protected objects were read or changed, and which administrative authority was used. This guide covers audit trace classes, policy-managed auditing, RACF coordination, SMF records, IFCIDs, interpretation, and performance.
The Db2 audit trace collects information about Db2 security controls. It supports evidence for least privilege, incident response, and regulatory reviews. Db2 normally sends audit information to SMF, where it is recorded in SMF type 102 records; a START TRACE request can also use GTF as a destination when your operational process requires it.
Decide what question the audit must answer before starting a trace. “Who was denied?” needs a different signal than “who read an audited table?” or “which SYSADM activity succeeded?” Capturing everything forever creates cost and hides important events in noise. Start with data classification, named audit objectives, retention requirements, and a documented reviewer.
Audit classes are a convenient grouping of Instrumentation Facility Component Identifiers (IFCIDs). Class 1 captures inadequate-authorization attempts through IFCID 140 and is the default when CLASS is omitted for an audit trace. Class 2 captures explicit GRANT and REVOKE with IFCID 141. Classes 3 through 6 cover audited-object DDL, first change, first read, and bind information (IFCIDs 142 through 145).
Other important classes include class 7 for authorization ID changes, class 8 for utilities, class 9 for installation-defined records, class 10 for trusted contexts, and class 11 for successful access using IFCID 361. Exact fields and applicability are release-dependent; use the licensed IFCID flat file and current IBM documentation when writing parsers.
1234-- Illustrative console pattern; use your release command syntax -START TRACE(AUDIT) CLASS(1,2) DEST(SMF) -DISPLAY TRACE -STOP TRACE(AUDIT) TNO(nn)
Audit policies make auditing targeted and repeatable. A policy contains criteria and audit categories for authorization IDs, roles, object ownership, or administrative authority. SECADM can create, display, activate, and inactivate these policies. Policy management is safer than a collection of undocumented console commands because the intended control is cataloged and reviewable.
Activate a policy with START TRACE and the AUDTPLCY option. Db2 reads the policy definition at start time; changing SYSIBM.SYSAUDITPOLICIES does not alter a running trace. Stop and start the policy trace after changes. Do not combine AUDTPLCY with individual CLASS or IFCID options. For tamper-proof policies in data sharing, IBM recommends starting all of them together so their trace numbers stay aligned.
123-START TRACE(AUDIT) AUDTPLCY(PAYROLL_ACCESS,SYSADM_USE) -- Record the returned trace number and policy version in the change ticket -STOP TRACE(AUDIT) AUDTPLCY(PAYROLL_ACCESS)
RACF auditing and Db2 auditing overlap but are not duplicates. RACF explains authentication, resource-profile, certificate, and started-task decisions. Db2 explains SQL-level authority, package execution, table access, DDL, and utilities. Investigators usually need both timelines, joined by user IDs, timestamps, client information, and connection data.
Access auditing should focus on sensitive objects and high-risk identities. Administrative auditing should cover SYSADM, DBADM, SECADM, grants, privileged utilities, and security-policy changes. Successful access can be expensive: IFCID 361 started broadly records all successful access, while a policy category can narrow it to use of a named administrative authority. Choose the narrowest control that meets the requirement.
SMF type 102 is a delivery format, not an explanation by itself. Feed records to an approved SIEM, Db2 monitor, or controlled parser that understands the correct IFCID layout. Preserve raw records long enough to re-parse them after a tooling upgrade. Record the Db2 member, subsystem, trace number, policy name, timestamp, authid, role, client fields, object, SQL or utility context, decision, and outcome.
Interpret trends, not just single messages. Repeated IFCID 140 denials from one client may be a broken deployment or credential attack. A sudden increase in successful privileged access can be a planned maintenance window or an incident. Correlate results with change tickets and RACF logs before concluding intent.
Audit work costs CPU, SMF bandwidth, storage, and analysis effort. First-read and first-change controls are often less voluminous than tracing every read, while successful-access auditing can grow very quickly. Pilot on representative traffic, measure SMF volume and Db2 overhead, and enforce retention and redaction policies before enabling a broad production policy.
Never solve an audit-volume problem by silently turning auditing off. Narrow the scope, use a defined sampling or policy category if policy allows it, improve downstream capacity, and document the risk decision. Re-test after application releases because an ORM or REST gateway can multiply the number of SQL events dramatically.
Auditing is the library sign-in sheet. RACF checks whether you may enter the building; Db2 records what you tried to read, change, or borrow once you are inside. A good sign-in sheet is detailed enough to answer a question later, but not so huge that nobody can find the important entry.
1. Which IFCID records inadequate authorization?
2. Who administers audit policies?
3. What must happen after changing an active policy?