Alternatives for controlling FM/Db2 auditing

FM/Db2 auditing is an optional facility. FM/Db2 works if auditing is not implemented. You should consider:

  • Whether user access to Db2® data and other resources using File Manager Db2® component requires auditing.
  • The information that File Manager audit log records can provide.
  • The information that File Manager audit log records cannot provide, and possible alternatives to obtaining that information.
  • If you do decide to use File Manager auditing, how you will handle any issues associated with large audit log data sets, or additional SMF records.
  • How you will use the information provided by File Manager audit log records.

If your site requires a record of a user's read access to Db2® data, an external security product such as RACF® can be configured to log access by some or all users, and may be a better alternative. Db2® also provides an audit facility which may be an alternative to File Manager auditing.

File Manager audit of read access to Db2® data does not write audit log records for every row processed, rather the name of the Db2® object and how many rows were processed are written to the audit log. File Manager audit of changes to Db2® data typically writes two log records, a before and after image of the row that was changed. If you intend to log update changes to Db2® tables that are subject to heavy update activity, consider the performance impact of writing many audit log records as well the size of any audit log data sets that might be produced.

You have two choices with respect to auditing of FM/Db2 audit activities. These are:

  1. Use FMN2POPT controlled auditing.

    The following points summarize the facilities available with FMN2POPT controlled auditing:

    • Different audit settings can be specified for each Db2® system that FM/Db2 might access
    • Auditing occurs for key FM/Db2 functions only (edit and copy). Other FM/Db2 functions are not subject to audit (for example print, import, export, and issuing Db2® commands).
    • The audit settings for any Db2® system apply equally to all FM/Db2 users connected to that Db2® system.
    • The audit settings for any Db2® system apply equally to all Db2® objects within that Db2® system.
    • The "Create audit trail" option is visible to the user for those FM/Db2 functions where auditing might occur.
    • You can specify auditing to the user's audit log data set, to the user's audit log data set with automatic (mandatory) printing of the audit log at the completion of the session, or to SMF.
  2. Use SAF-rule controlled auditing. This relies on various SAF FACILITY and XFACILIT resource rules, which you define with an external security product, such as RACF® (or equivalent product).

    The following points summarize the facilities available with SAF-rule controlled auditing:

    • Different audit settings can be specified for each Db2® system that FM/Db2 might access.
    • Auditing can be (optionally) specified for all FM/Db2 functions, however audit records are not written for the SQL statements used by FM/Db2 to build templates, or for other internal purposes.
    • Different auditing requirements can be specified for different TSO user IDs.
    • Different auditing requirements can be specified for access to different Db2® objects, or to different types of SQL statements, or when issuing Db2® commands.
    • You can provide FM/Db2 users with a "Create audit trail" option for some FM/Db2 functions. This is also SAF-rule controlled. The presence of the "Create audit trail" option does not guarantee that the user can switch off auditing, since this depends on the level of access the user has to the appropriate SAF resource names. When a user has access to the "Create audit trail" option, they can always turn on auditing, even if the relevant SAF resource rules do not require auditing.
    • You can specify auditing to the user's audit log data set, to the user's audit log data set with automatic (mandatory) printing of the audit log at the completion of the session, or to SMF. Dual logging (to the user's audit log data set and to SMF) can also be specified.

Some other points to consider are:

  • Auditing to the user's audit log data set can result in large numbers of audit log data sets, and this may have disk space implications. You may need to consider implementing automatic purging or archiving of audit log data sets.
  • Auditing to SMF (only) requires additional set-up, but provides a more reliable and secure environment for capturing audit information than audit logging to the user's audit log data set.
  • With SAF-rule controlled auditing in effect to SMF only, a File Manager/Db2 user can determine that SAF-rule controlled auditing is in effect, but there is no indication to the user which activities are actually being audited.
  • With SAF-rule controlled auditing in effect, failure to write records to the SMF audit log - when this is required - will result in the termination of the current FM/Db2 function.

If you implement SAF-rule controlled auditing you need to decide how File Manager auditing will be enabled. This is described in more detail in Customizing the audit facility for FM/Db2. There are two alternatives. One requires an enabling SAF rule and the presence of a member in SYS1.PARMLIB, the other requires an enabling SAF rule but has no requirement for a member in SYS1.PARMLIB. The use of a member in SYS1.PARMLIB provides additional facilities compared with the alternative that does not require the use of SYS1.PARMLIB. The additional facilities are documented in File Manager options specified in PARMLIB members.

When you have determined the appropriate type of auditing for your installation, follow the instructions in Customizing the audit facility for FM/Db2.