Comparing DB2 and CA ACF2 Option for DB2 Features › Processing Security Information

Processing Security Information

DB2 controls access to resources by explicitly or implicitly granting privileges to an ID. GRANT and REVOKE statements explicitly give and remove privileges. Ownership of a resource implicitly grants certain privileges that cannot be revoked. Privileges that are explicitly or implicitly granted to an ID are recorded in the DB2 catalog. Each row in the catalog tables represents one privilege that has been granted to an authorization ID. When you try to perform a function, DB2 checks the catalog tables to determine if you are permitted to perform the action.

For example, suppose you issue the ALTER TABLESPACE request. DB2 uses your authorization ID to check the catalog tables for one of the following:

• Ownership of the table space
• DBADM authority on the database
• System DBADM authority
• SYSADM or SYSCTRL authority

DB2 checks your authorization ID against the values in the GRANTEE column of the catalog security tables. This ID can be your primary authorization ID or one of your secondary authorization IDs. This secondary ID is associated with your primary ID through the sign‑on or attach connection exit at connection time or by the SET CURRENT SQLID statement. DB2 checks the appropriate catalog table for each ID until one has the required privilege assigned to it. The more secondary IDs that are assigned to the primary ID, the more slowly DB2 processes.

For some privileges, the process to determine which users are granted the privilege is more complicated. For example, with the UPDATE privilege, DB2 must check two tables if UPDATE is restricted to a column level: one for the table privileges and one for the column privileges.

During processing, you can choose what you want to trace. Through options of the audit trace records, you can choose:

• Categories of events to trace
• Particular authorization IDs or plan names to audit
• Ways to start and stop the trace
• Destinations for audit trace records.

DB2 uses SMF type 102 records to record audit trace information. DB2 can record original, primary, and all secondary IDs in its SMF records. The IDs that are reported depend on the product that you buy or write.

Authorization checking for resources when a plan is bound can take place at two different times: at bind time and at execution time. Authorization checking to use a plan takes place when the user executes the plan. Authorization checking to use dynamic SQL takes place at execution time.

Corresponding CA ACF2 Option for DB2 Feature

CA ACF2 Option for DB2 does not update or reference the DB2 catalog tables. CA ACF2 Option for DB2 stores its rules and DB2 records in the Infostorage database. CA ACF2 Option for DB2 uses these to perform validation on the resource. It ignores all GRANT and REVOKE statements.

At the startup of a DB2 subsystem, CA ACF2 Option for DB2 determines which DB2 OPTS infostorage record is active and stores its mode values. When a user attempts to perform an action on a resource, CA ACF2 Option for DB2 performs its resource validation.

CA ACF2 Option for DB2 checks one or more rule sets for the same privileges for which DB2 checks its catalog tables. CA ACF2 Option for DB2 also considers the mode values specified by the DB2 OPTS record for each resource. CA ACF2 Option for DB2 locates all of the rule sets that apply to the access attempt until it finds one that grants access. These include any rule set that covers the specific resource or ones that grant administrative authorities such as SYSADM or DBADM.

First, CA ACF2 Option for DB2 checks the rule set that applies to the specific resource. An CA ACF2 Option for DB2 rule applies to a specific resource only when the conditions described by the rule match the following conditions of the user’s actual access request.

• Name of the actual resource
• Type of the actual resource
• DB2 subsystem of the user or group SYSID if DB2 subsystem has been assigned a Group SYSID and the group SYSID matches the SYSID of the rule.
• Environment of the request, including the:
  • UID of the user
  • Time of day and day of week of the request
  • Date of the request
• Type of access requested.

CA ACF2 Option for DB2 checks the rule set to determine whether the access request matches the following parameters:

• $KEY (the name of the resource)
• $TYPE (the type of resource)
• $SYSID (the DB2 subsystem or group SYSID as defined in the OPTS record)

When CA ACF2 Option for DB2 finds a match, it uses the $LIDOWNER or $UIDOWNER control statement to determine whether the user owns the resource. If the user owns the resource, CA ACF2 Option for DB2 automatically permits access to the resource, no other checking is performed. If the user does not own the resource, CA ACF2 Option for DB2 continues to search the rule set for a rule entry that matches the user’s environment. The rule entry can contain the following parameters that describe the environment:

• UID
• SHIFT
• UNTIL, FOR, or ACTIVE
• SERVICE
• COLUMN (if appropriate).

If CA ACF2 Option for DB2 finds a matching rule entry, it determines from the access permission whether the request is allowed. If no rule entry matches or the access permission prevents access, CA ACF2 Option for DB2 uses the mode value of the DB2 OPTS record for that resource to determine whether access is allowed. If the mode for the resource is set to LOG or QUIET, access is granted. If the mode is set to ABORT, CA ACF2 Option for DB2 checks the user’s logonid to determine whether it is privileged (that is, has the SECURITY or NON‑CNCL attribute) and whether a scope record is defined for the SECURITY privilege. If one of these attributes is specified and the user is scoped for the resource (when SECURITY is specified), the access is allowed but logged.

If the user is not privileged, CA ACF2 Option for DB2 continues to check other rule sets that might apply such as those that control administrative authorities (for example, SYSADM or DBADM). After each rule set validation, CA ACF2 Option for DB2 checks the corresponding mode value of the OPTS record for the access recommendation. If no rule sets permit access and the OPTS mode value specifies ABORT for each of the resources that DB2 checks, access is ultimately denied.

For example, suppose you issue an ALTER TABLESPACE request. CA ACF2 Option for DB2 locates the rule sets that grant the following by matching the environments:

• Table space ownership (CA ACF2 Option for DB2 matches the $KEY of the table space rule set to the table space name and uses the $LIDOWNER or $UIDOWNER control statement to establish ownership.)
• DBADM authority (CA ACF2 Option for DB2 matches the $KEY of the database rule set to the database name and finds the matching rule entry that states SERVICE(DBADM). It uses the access permission to determine whether you have DBADM authority.)
• System DBADM authority (CA ACF2 Option for DB2 finds the $KEY of SYSDBADM and uses the matching rule entry and its access permissions to determine whether you have system DBADM authority.
• SYSCTRL authority (CA ACF2 Option for DB2 finds the $KEY of SYSCTRL and uses the matching rule entry and its access permission to determine whether you have SYSCTRL authority.)
• SYSADM authority (CA ACF2 Option for DB2 finds the $KEY of SYSADM and uses the matching rule entry and its access permission to determine whether you have SYSADM authority.)

The following are the steps that CA ACF2 Option for DB2 takes:

1. CA ACF2 Option for DB2 checks the table space rule set to determine from the $LIDOWNER or $UIDOWNER control statement if you own the table space. If so, you can alter the table space.
2. If you do not own the table space, it uses the TSPMODE field in the DB2 OPTS record to determine whether access is granted. If the TSPMODE field specifies LOG or QUIET, you can issue the ALTER TABLESPACE request.
3. If the TSPMODE field specifies ABORT, CA ACF2 Option for DB2 determines whether you can alter the table space by checking your logonid for the SECURITY or NON‑CNCL privilege. If one of these privileges is specified and you are scoped for the table space (when SECURITY is specified), CA ACF2 Option for DB2 permits you to alter the table space but logs the access.
4. If you are not a privileged user, CA ACF2 Option for DB2 locates the next rule set that applies, which, in this case, is the database rule set to determine whether you have DBADM authority. If CA ACF2 Option for DB2 finds a rule entry that matches your environment, it checks the access permission. If the access permission grants you access (specifies ALLOW or LOG), you can alter the table space.
5. If a matching database rule cannot be located or prevents access, CA ACF2 Option for DB2 uses the DBSMODE field of the OPTS record to determine whether you can alter the table space. If LOG or QUIET is specified, you can issue the ALTER TABLESPACE request.
6. If ABORT is specified for DBSMODE, CA ACF2 Option for DB2 uses the SYSDBADM rule set to determine whether you have system DBADM authority. If the access permission on the matching rule entry permits access, you can alter the table space.
7. If the SYSDBADM rule set does not exist or grant access, CA ACF2 Option for DB2 uses the SYSMODE field of the OPTS record to determine whether the ALTER can be done. If LOG or QUIET is specified, you can issue the ALTER TABLESPACE request.
8. If ABORT is specified for SYSMODE, CA ACF2 Option for DB2 uses the SYSCTRL rule set to determine whether you have SYSCTRL authority. If the access permission on the matching rule entry permits access, you can alter the table space.
9. If the SYSCTRL rule set does not exist or grant access, CA ACF2 Option for DB2 uses the SYSMODE field of the OPTS record to determine whether the ALTER can be done. If LOG or QUIET is specified, you can issue the ALTER TABLESPACE request.
10. If ABORT is specified for SYSMODE, CA ACF2 Option for DB2 uses the SYSADM rule set to determine whether you have SYSADM authority. If the access permission on the matching rule entry permits access, you can alter the table space.
11. If the SYSADM rule set does not exist or grant access, CA ACF2 Option for DB2 checks the SYSMODE field of the DB2 OPTS record to determine whether you can alter the table space. If LOG or QUIET is specified in this field, you can perform the function.
12. If ABORT is specified for SYSMODE, access is prevented. This series of events means that the SYSMODE field is the final judge of whether access to a resource is permitted when all other rule sets deny access and the user is not privileged. This is because SYSADM is the last authority for which CA ACF2 Option for DB2 checks.

If your site uses secondary authorization IDs, CA ACF2 Option for DB2 completes the process described above for each ID that a user is authorized to use. If the user does not issue the SET CURRENT SQLID request, CA ACF2 Option for DB2 starts with the user’s primary ID. If that ID does not have access to the DB2 object, CA ACF2 Option for DB2 uses a secondary ID in this process. If the secondary ID does not give the user access, the remaining secondary IDs are checked until CA ACF2 Option for DB2 finds one that grants access or cannot find an ID.

CA ACF2 Option for DB2 uses a type 230 SMF record, or whatever is defined in the CA ACF2 Field Definition Record (ACFFDR). It reports violations, traces, and loggings recorded against the original, primary, and secondary authorization IDs.