Db2 and product security

SECURITY data set and security processing

Product security is enforced through the SECURITY data set. Each user is registered in this data set automatically when a User Profile is created.

Users can modify their User Profiles through User Options or product administrators can modify them in User Profile administration. When a change is made to a User Profile from the administration panels, the records in the PROFILE and SECURITY data sets are updated. When a change is made from the User Options panels, only the record in the PROFILE data set is updated. Administrators can prevent users from modifying many of the profile values by locking the values. Users can view the values in locked fields but cannot modify them. Only users with profile administration authority can change locked values.

When a user begins a product session, the profile records from the SECURITY and PROFILE data sets are merged. If a value is locked, the setting from the SECURITY record is used. If a value is not locked, the setting from the PROFILE data set is used.

See System and SQL Performance products for DB2 customization tasks for a complete description of User Profiles.

Db2 security

You can restrict authority to start Db2 traces (Apptune and SQL Performance) and issue Db2 commands with product security alone or with Db2 security checking.

Use the DOMPLEX option Security via DB2 authorization table to specify the type of security enforcement that the product uses. Specifying N uses only product security (the default), and specifying Y uses both Db2 security and product security:

• Using only product security

  Authority to issue Db2 commands is controlled exclusively through the product when you specify N for Security via DB2 authorization table. This option prevents validation of authorization in Db2. For example, if a User Profile indicates that Db2 commands can be issued, the product allows the user to issue Db2 commands whether or not the user has SYSOPR or other authority in Db2.

  You can use the DOMEXIT2 user exit to override individual security options in the User Profile.

  For more information about DOMEXIT2, see the System-and-SQL-Performance-for-Db2-administration.

  For an explanation of DOMPLEX options, see Verifying-or-changing-DOMPLEX-parameters.

• Using both Db2 and product security

  If you specify Y for Security via DB2 authorization table, security is enforced for both Db2 and for the product. For Db2 operations, the product validates authority in the User Profile first. Db2 authority is validated only if the product allows the operation. For example, if the User Profile indicates that the user is allowed to issue commands, the product validates the user's Db2 authority. If the user does not have command authorization in Db2, the user cannot issue commands.

  On the other hand, because Db2 authorization is checked only if the operation is authorized by the product, it is possible for the product to restrict a user from issuing commands, even when Db2 command authority has been granted to the user. When Y is specified for the Security via DB2 authorization table option, the product can prevent a user from performing a function that Db2 would allow because that function is not authorized by the product. When user access to a specific function is denied because of insufficient security, the product issues error messages.

  The product establishes a user’s Db2 authority when the user first logs on to the product. If the target Db2 subsystem is not active when the user logs on, security checking is deferred until Db2 is started and the user makes the first request for a Db2 service.

• DB2 authorization requirements

  All product users need Db2 authority. The user assigned to the DBC started task needs RACF authority to the log files and DB2 authority to start traces and execute Explains.

  If you implement a product so that it controls security (by specifying N for the Security via DB2 authorization table option), the product’s User Profile enforces all authorizations when the product is installed. The product’s User Profile also enforces authorization to perform functions not related to Db2. For information about defining a User Profile, see Checking-the-default-User-Profile.

  For detailed information about creating User Profiles, see System-and-SQL-Performance-for-Db2-administration.

  If you use product security and Db2 security (by specifying Y for the Security via DB2 authorization table option), you must grant the user authorization to the appropriate functions on each Db2 subsystem. You must issue the proper Db2 authority to the user to issue Db2 commands (DISPLAYAUTH for DISPLAY commands and SYSOPRAUTH, SYSADMAUTH, or TRACEAUTH to start and stop traces, for example).

  You must perform these GRANTs before the user begins a product session with a DBC. The user ID that is granted authority in Db2 can be the user ID or, in the TSO environment, a secondary authorization ID within the user’s security group.

  You can use the DOMEXIT4 user exit to override these default user ID selections. This exit is invoked once at the start of each user’s product session. For more information about DOMEXIT4, see the System-and-SQL-Performance-for-Db2-administration.

  The product does not detect the GRANTs and REVOKEs that are issued in a Db2 subsystem until Db2 updates the SYSIBM.SYSUSERAUTH catalog table. If the update is in a Db2 buffer, it might not be written immediately on low-activity Db2 subsystems. If you are using a low-activity Db2 subsystem, you can expedite this update to the catalog table by restarting the Db2 subsystem or by executing the QUIESCE utility against the DSNDB06.SYSUSER table space. If the product is executing when a GRANT or REVOKE command is issued, the Data Collector does not recognize the change until you restart the Data Collector or issue a REFRESH command from the Data Collector Command Interface panel or the console.