Security and auditing

There are security considerations and audit journal entries for the configuration and management of Db2® Mirror.

Security considerations

Authority requirements for managing Db2 Mirror

To manage a Db2 Mirror environment, a user may need to be granted authority to services or objects to perform certain tasks. Some tasks may even require function usage or special authority. By default, *PUBLIC can only view Db2 Mirror settings.

See Db2 Mirror services for details about all services provided to configure and manage Db2 Mirror.

See Authorization for detailed authority requirements and default *PUBLIC authority of each Db2 Mirror service.

Access to Db2 Mirror objects can be modified using the Db2 Mirror Data Access function in the Db2 Mirror GUI. The GUI will configure the authorities on both nodes.

Figure 1. Db2 Mirror Data Access in the Db2 Mirror GUI

Replication Criteria List authority considerations

The Replication Criteria List (RCL) contains object replication rules that could be used to determine the existence of objects on the nodes. By default, *PUBLIC authority to the RCL physical file QSYS2/MIRROR_RCL is *EXCLUDE.

Access to the RCL file can be modified using the Grant Object Authority (GRTOBJAUT) and Revoke Object Authority (RVKOBJAUT) CL commands. Administrators who are responsible for configuring the replication of objects and managing the replication list rules will need access to the RCL file.

See Replication services for details about the authorization requirements for each service used to manage the RCL.

Object Tracking List authority considerations

By default, *PUBLIC authority to the Object Tracking List (OTL) physical file QRECOVERY/QADBRSYSTS is *EXCLUDE.

Access to the OTL file can be modified using the Db2 Mirror Data Access function in the Db2 Mirror GUI. System administrators who monitor the progress of resynchronization will need access to the OTL.

The OTL contains metadata about replicated objects and tracked actions. When a user is granted authority to the OTL, this metadata can be seen regardless of whether the user has object level authority to the replicated object. The OTL does not contain database file row images. It is recommended to limit the number of users who have been granted with select privilege to the OTL.

An additional security consideration exists for the OTL beyond authority to the file itself. In some situations, you may want to remove unprocessed entries from the OTL. When a user defers an entry from the OTL, Db2 Mirror is being directed to no longer attempt to process the resynchronization topic related to that entry. By deferring the entry, the related object will no longer be identical across the node pair. User deferral of OTL entries is not a common occurrence, but can be necessary in some recovery scenarios. For that reason, an additional authorization is needed by user in the form of being authorized to the QIBM_DB2_MIRROR function usage identifier.

It is recommended that QIBM_DB2_MIRROR function usage authority be granted to only those administrators who have both the knowledge and responsibility to manage this critical Db2 Mirror topic.

Submitted Job Tracker authority considerations

IBM® i services are used to manage the Submitted Job Tracker feature. See Work Management services for details about the authorization requirements for each service used to manage the Submitted Job Tracker.

Submitted Job Tracker maintains a number of physical files to store the list of job queues being tracked and store job parameter and job status information about each tracked job. By default, *PUBLIC authority is set to *EXLUDE for each of these physical files^¹:

The Job Queue List (JQL) physical file is QSYS/QAMRDJQL.
The physical files for the job tracking files are QSBMJOBTRK/QAMRDJTS and QSBMJOBTRK/QAMRDJTT.

Considerations for replication of security related system values

Certain security related system values are not allowed to be changed if an option in Start Service Tools (STRSST) has been used to prevent them from being changed. If you attempt to change a system value that has been locked using this function, the change will not be allowed. See Lock function of security-related system values for more information on which system values can be locked.

The lock down of system values is not a replicated feature, so the replication or resynchronization of these system values will fail if the system value is locked down on the target node.

For additional security considerations, see Security guidelines

Auditing

You can audit the configuration, management, and state of the Db2 Mirror environment.

Auditing Db2 Mirror actions

To audit Db2 Mirror actions, configure the IBM i security auditing level to include *SYSMGT. See Security auditing journal entries for a complete description of actions that are audited when *SYSMGT is specified.

Use the Change Security Auditing (CHGSECAUD) command to set the system values and create the QAUDJRN journal, if it does not already exist.

Auditing behavior during setup

Cloning actions initiated from a third node will generate M0 audit journal entries on the setup source node. If the setup source node is powered down at the time of the action, then the audit journal entry is written on the third node instead.

Auditing behavior during active replication

While replication is active, auditing occurs naturally for most operations on each node while the change is synchronously made on each node. One exception is IFS operations, which will only produce audit records on the node where the IASP is varied on.

Auditing behavior during resynchronization

The resynchronization of changes that were tracked while replication was suspended is processed on the target node in QDBMSRVR jobs running under the QSECOFR user profile. Audit journal entries or data journal entries that are written on the target node as a result of resynchronization will be recorded as user QSECOFR rather than the user who originally made the change on the source node.

Auditing Submitted Job Tracker actions

To audit Submitted Job Tracker actions, configure the IBM i security auditing level to include *OBJAUD. See Planning the auditing of object access for a complete description of auditing access to an object in the security audit journal when *OBJAUD is specified.

Use the Change Security Auditing (CHGSECAUD) command to set the system values and create the QAUDJRN journal, if it does not already exist.

By default, there is no object auditing enabled for the files used by Submitted Job Tracker. The following examples use the Change Object Auditing (CHGOBJAUD) CL command to change the object auditing values for each of the physical files used by Submitted Job Tracker:

To use object auditing to collect information about change accesses to the JQL, perform the following command:
```
CHGOBJAUD OBJ(QSYS/QAMRDJQL) OBJTYPE(*FILE) OBJAUD(*CHANGE)
```
To use object auditing to collect information about change and read accesses against the job tracking files, perform the following commands^¹:
```
CHGOBJAUD OBJ(QSBMJOBTRK/QAMRDJTS) OBJTYPE(*FILE) OBJAUD(*ALL)
CHGOBJAUD OBJ(QSBMJOBTRK/QAMRDJTT) OBJTYPE(*FILE) OBJAUD(*ALL)
```

The audit journal entries can be analyzed using the techniques described in Analyzing audit journal entries with query or a program

Db2 Mirror audit journal entries

The following audit journal entries are written to the QAUDJRN journal in the Db2 Mirror environment:

Viewing Db2 Mirror audit journal entries

The Db2 Mirror audit journal entries for both the primary and secondary nodes can be viewed and managed from the Db2 Mirror GUI. Hover over the security icon (lock) and click on Audit Records.

Figure 2. Launch Audit Records in Db2 Mirror GUI

The following figure shows the Audit Records view in the Db2 Mirror GUI.

Figure 3. Review Db2 Mirror specific audit records

The Db2 Mirror audit journal entries can also be examined using the following SQL table functions:

¹ For each database IASP, the QAMRDJTS and QAMRDJTT files exist in library QSJTnnnnn.