Using Reports › Understanding the ACFRPTRV Report › Why Do You Need this Information? › Violation Records › Logging Records

Logging Records

ACFRPTRV automatically reports all SMF loggings for accesses to a resource if you specify LOG on the rule entry or in the DB2 record. With LOG, you can ensure that CA ACF2 Option for DB2 rules grant access in the way that you want. You can also use it to migrate rule sets from QUIET to ABORT mode. It lets you identify and track users who receive violation or logging records for access to resources that they need. As security administrator, you can adjust the rule entries to ensure they receive the proper access authority without disturbing their work flow.

You can use LOG in a rule entry with the SHIFT parameter to audit access to resources during specific time frames. For example, if you suspect that accesses are made outside of normal work hours (for example, 9:00 a.m. to 5:00 p.m.), you can log these accesses. To do this, create a shift record that excludes these hours (that is, one that contains 00:00–8:59 and 5:01–23:59). Associate this shift record with the resource through the SHIFT parameter of the rule entry. Specify LOG on the rule entry. When CA ACF2 Option for DB2 interprets the rule set, the rule entry with the SHIFT parameter is sorted and interpreted before a rule entry without SHIFT. Therefore, all accesses to the resource outside of normal hours (that is, during the shift record’s hours) are permitted but logged. A rule entry that grants permission to the resource without the SHIFT parameter would be interpreted next. In this case, the rule entry would apply to all accesses during normal hours (or outside the hours specified by the shift record).

Note: CA ACF2 Option for DB2 generates violation and logging records whenever an authorization check is made that violates a rule or is logged by the rule. To the ACFRPTRV report, this means:

• CA ACF2 Option for DB2 might create multiple loggings. For example, a utility such as LOAD can repeat accesses during a single execution. So, CA ACF2 will create a logging for each access attempt during the execution. Similarly, a STARTDB, STOPDB, or DISPLAYDB command issued with a masking character (the asterisk) can cause multiple loggings. An asterisk means that DB2 is to issue the command against each database that the user is authorized to access. To determine what databases the user is authorized to access, CA ACF2 Option for DB2 checks the rule sets for every database. If LOG is specified in the rule, CA ACF2 Option for DB2 creates a logging for that database. Each time DB2 issues the command against a database, CA ACF2 Option for DB2 interprets that database’s rule set. However, in cases where LOG is not specified and the resource is in ABORT mode, no violation records are created. No violation records are created because CA ACF2 Option for DB2 acts like DB2 in this regard and skips the databases the user is not authorized to access.
• CA ACF2 Option for DB2 creates SMF loggings for access to an object referred to by an application plan when the plan is bound, not when the resource is accessed (unless the VALIDATE(RUN) option is used). For example, if you update a table using SQL statements in a plan bound with the VALIDATE(BIND) option and the rule entry specifies LOG, CA ACF2 Option for DB2 creates SMF records for the authorization checks of the SQL statements when the plan is bound, not when the plan actually updates the table.

  Now, suppose you specify VALIDATE(RUN) and the rule entry specifies ALLOW. Also suppose that some of the privileges required for the table update are not available at bind time but are granted to the plan owner by execution time. CA ACF2 Option for DB2 validates the owner’s authority at bind time and again at execution. Since the update would not have been authorized at bind time, CA ACF2 Option for DB2 generates an SMF logging for each of these security checks at bind time but not at execution time because the owner has the needed authorities by the time the user executes the plan.

  Now, use the same VALIDATE(RUN) scenario but change the rule entry to specify LOG. In this case, CA ACF2 Option for DB2 generates SMF loggings when the plan is bound and when the user executes the plan. The same is true if the privileges are not available at bind time or at execution time.

• CA ACF2 Option for DB2 might create multiple SMF records if a user has an overriding administrative authority such as SYSADM or DBADM, and the rule set for this authority specifies LOG. This creates one SMF record for the violation on the resource and one for the access allowed (but logged) by the administrative authority. You should interpret these SMF records together. They each have the same date and time stamp. CA ACF2 Option for DB2 generates multiple records to show why the access was granted (that is, SYSADM, DBADM, and so on) and what resource the user tried to access. To get this information, you must specify the LOG and VIO report parameters and not sort the records. See the sample JCL supplied in the CAI.CACPJCL data set.
• CA ACF2 Option for DB2 creates a view after performing an access check for each privilege on the creator’s ID. However, if a rule specifies LOG or if the user has SECURITY or scoped SECURITY privileges on the table, CA ACF2 Option for DB2 logs the access check against the table when the view is created.
• When performing a bind plan with VALIDATE(BIND) and specifying an owner different than the binder’s ID, you can get a violation record for the owner if the owner does not have the BIND privilege and the SYSDBADM, SYSCTRL, or SYSADM privileges. The violation is for TYPE(PLN) and SERVICE(BIND). However, if the binder has SYSDBADM, SYSCTRL, or SYSADM, the plan is successfully found. If it does not have SYSDBADM, SYSCTRL, or SYSADM, a violation is logged for the SYSCTRL privilege for the binder.