Db2 can control
access to data within a Db2 subsystem. Db2 also
works with outside security systems, such as RACF®, that control access to the Db2 subsystem.
Before you begin
Your system security
administrator should have provided a Db2 for z/OS® security
environment as outlined in the information about managing Db2 security, including user IDs and resource profiles for batch connections. If you are using RACF, ensure that the system security administrator also defined your Db2 resources to RACF.
The following IDs should have been specified
on installation panel DSNTIPP1:
- Two system administrator (installation SYSADM) authorization IDs
- Two system operator (installation SYSOPR) authorization IDs
- Two security administrator (installation
SECADM) authorization IDs or roles
- One authorization ID (installation IBMUSER) if RACF is not available for batch access and USER=
is not specified in the JOB statement
Procedure
To establish subsystem security:
- Ensure that the specified installation SYSADM IDs are defined
in your TSO and RACF systems
before attempting to access Db2. You can also
define installation SYSOPR IDs, SECADM IDs, and the installation IBMUSER
ID.
- To enable primary and secondary user IDs to issue Db2 commands
from the z/OS console or TSO
SDSF, define RACF classes to
authorize Db2 commands.
Use the following RACF commands:
SETR CLASSACT(DSNADM)
RDEFINE DSNADM DSN1.SYSOPR UACC(NONE)
SETR RACLIST(DSNADM) REFRESH
PERMIT DSN1.SYSOPR CLASS(DSNADM) ID(userid) ACCESS(READ)
SETR RACLIST(DSNADM) REFRESH
You can grant SYSOPR authority to all primary and secondary
user IDs that issue Db2 commands
from the z/OS console or TSO
SDSF, but only after Db2 can process
SQL.
-
To separate security tasks from system administration tasks,
use the SEPARATE SECURITY field on the DSNTIPP1 panel. Before setting
the SEPARATE SECURITY field to YES, set at least one SECADM system
parameter to an authorization ID, or create the necessary trusted
contexts and roles. If you specify YES for SEPARATE SECURITY, system
administrator authority cannot be used to perform security tasks,
and the SECADM authority is required to manage trusted contexts and
roles. If both SECADM system parameters are set to roles and those
roles have not been created, no one will have the authority to manage
trusted contexts and roles.
-
Run job DSNTIJRA to complete the following tasks:
- Define the administrative task scheduler started task module to RACF program control
- Define the administrative task scheduler as a trusted context
in RACF
If you are using a Db2 data
sharing environment, customize and run DSNTIJRA for each member of
the group.