Identify DB2 Resources

Implementation Considerations › Identify DB2 Resources

Identify DB2 Resources

DB2 resources can be broken down into two groups — controllable objects and system privileges. CA Top Secret Option for DB2 uses resource classes to protect these DB2 resources. In order to secure these resources you must:

Identify them to CA Top Secret by ADDing them to a predefined DB2 user or department ACID. For example:
```
TSS ADD(DB2DEPT) DB2TABLE(USRMIKE.RES)
```
PERMIT these resources to individual users. For example:
```
TSS PER(USER01) DB2TABLE(USRMIKE.RES) ACC(SELECT)
```

Evaluate Use of Default Protection (DEFPROT)

It is recommended that you assign the DEFPROT attribute to all DB2 resource classes. The DEFPROT attribute forces protection by default on all resources in a given resource class.

Issue the following command to add DEFPROT to a resource class:

TSS REPL(RDT) RESCLASS(DB2STOGP) ATTR(DEFPROT)

Member DB13RDT in the installation sample JCL library contains the commands for performing this administration.

Evaluate Use of RES Suboption

To protect DB2 resources in an online, multi‑user facility (such as CICS), you must specify the RES suboption of the FACILITY control option for the facility you log onto. For example, to protect DB2 resources accessed from the CICSPROD facility, you would issue the following command:

TSS MODIFY FAC(CICSPROD=RES)

Evaluate Use of Additional Access Restrictions

In addition to specifying an access level for each of the DB2 resource objects (DB2SYS is used to control system privileges and does not have access levels), you can specify any of the following access restrictions for all of the DB2 resources:

EXPIRE

Limits the duration of the ACID's access to a particular resource. For example, if USRE01 needed temporary access to the “USRMIKE.RES” table for two weeks, the following command would be issued:

    TSS PER(USER01) DB2TABLE(USRMIKE.RES) ACC(SELECT) FOR(14)

FACILITY

Allows the user access to the DB2 resources residing in a particular facility (i.e., DB2PROD, DB2TEST). For example, to allow USER01 access to the XYZ application plan only in the DB2PROD facility, the following command would be issued:

    TSS PER(USER01) DB2PLAN(XYZ) ACC(EXECUTE) FAC(DB2PROD)

In a DB2 environment, it is likely that multiple DB2 subsystems will have resources with the same name. In fact, system privileges have the same resource name in all DB2 subsystems.

TIME/DAY

Limit access to certain days of the week, certain times of the day, or both. For example, to PERMIT USER03 to access the DSNP DB2 subsystem only on Mondays, Wednesdays and Fridays between the hours of 9 and 5, the following command would be issued:

TSS PER(USER03) DB2(DSNR.DSNP) DAYS(MON,WED,FRI) TIME(09,17)

ACTION

Specifies how CA Top Secret Option for DB2 will react to a request to access a particular resource. ACTIONS are divided into six types. They include:

FAIL—Regardless of the mode the ACID is in, any attempts to access this resource are treated as though the ACID is in FAIL mode. Unauthorized access is failed. Ordinarily, if the user had been in WARN mode, he would have received messages upon attempting to access the resource but he would have succeeded in his attempt.
AUDIT—The ACID is audited when this resource is accessed.
NOTIFY—CA Top Secret Option for DB2 will notify the security console when the resource is accessed.
EXIT—If the PERMIT is granted, CA Top Secret will issue the EXIT call to invoke the Installation Exit
DENY—Used to deny access to resources that do not support access levels.
ADMIN—ACTION(ADMIN) allows an administrator to PERMIT access to resources that are outside of his normal scope of authority. If an ACCESS level is not specified, the administrator is PERMITted to authorize the default access level associated with that resource class in the RDT.

For example, to indicate that an AUDIT record should be maintained of every time USER03 accesses the PAY001 application plan, the following command would be issued:

TSS PER(USER03) DB2PLAN(PAY001) ACC(EXECUTE) ACTION(AUDIT)

For more information about these access restrictions, see the CA Top Secret Command Functions Guide.

Using System Privileges

DB2SYS resources are global in nature — they represent a special type of permission and do not relate to a specific object. There is only one instance of the resource or permission type in the system, therefore it is recommended that the DB2SYS resources or permissions be owned by a corporate entity (such as a department). For example, to assign SYSADM privilege to the security department, the following command would be executed:

TSS ADD(SECDEPT) DB2SYS(SYSADM)

System privileges have the same resource name in all DB2 subsystems. Use the facility access control to restrict a system privilege for a user to a specific DB2 subsystem. For example, to assign SYSADM privilege to user JONES01 for DSNT subsystem which is associated with the DB2TEST facility, the following command would be executed:

TSS PER(JONES01) DB2SYS(SYSADM) FAC(DB2TEST)

In general, native DB2 system privileges have the same meaning in CA Top Secret Option for DB2. There are two exceptions — DB2SYS(CREDBA) and DB2SYS(CREDBC). In native DB2, the CREATEDBA privilege grants the user the explicit privilege to create databases and an implicit privilege of DBADM authority over those databases. CREATEDBC acts in the same manner, however, it only grants an implicit privilege of DBCTRL authority over the databases created by the user.

In CA Top Secret Option for DB2, the DB2SYS privileges of CREDBA and CREDBC both grant the explicit privilege to create databases. However, there are no implicit privilege of DBADM or DBCTRL for the created databases. Unlike DB2, the creator is NOT treated as the owner in CA Top Secret Option for DB2.

Explicit/Implicit Privileges and Authorization Hierarchy

DB2 privileges are bestowed in DB2 explicitly by issuing a GRANT statement, or implicitly every time a DB2 object is created.

In CA Top Secret Option for DB2, however, only explicit privileges are recognized. The creator of an object does not automatically gain privileges over the object.

CA Top Secret Option for DB2 supports the DB2 hierarchy of authorities. The significant difference between hierarchical authorities and standard privileges is that you can permit access to one DB2 object via a permission granted to another DB2 object. For example, the ALTER privilege for the PAYROLL.SALARY table could be given explicitly via the following command:

TSS PERMIT(JONES) DB2TABLE(PAYROLL.SALARY) ACC(ALTER)

Or implicitly through any of the following:

TSS PER(JONES) DB2DBASE(PAYROLL) ACC(DBADM)

TSS PER(JONES) DB2SYS(SYSDBADM)
TSS PER(JONES) DB2SYS(SYSCTRL)
TSS PER(JONES) DB2SYS(SYSADM)

Special Authorization IDs

As part of the DB2 installation, four special authorization IDs are defined to DB2 — two for install SYSADM and two for install SYSOPR. You have to CREATE an ACID for each of these IDs if you wish to use their authorities. At the very least, you will need to CREATE an ACID for one of the install SYSADM IDs. No other CA Top Secret Option for DB2 PERMITs will need to be issued.

Install SYSADM and install SYSOPR are extremely powerful authorities and should, therefore, be granted only with the highest consideration. You should consider associating them with an SCA or the MSCA for use during installation and maintenance. You might also want to add special controls, such as AUDIT, to these ACIDs.

In DB2 version 10 and above, two additional special authorization IDs are defined during DB2 installation. These authids are the install SECADM authids. In native DB2, these authids have the authority to perform the GRANTS and REVOKES of native DB2 security and to control security definitions such as row permissions and column masks. However, with CA Top Secret Option for DB2 these authids are not associated with the SECADM authority. The SECADM authority is controlled with a system authority permission just as other system privileges and authorities are controlled. The entity in the authority permission is SECADM.

Using BINDAGENT

Unlike other DB2SYS privileges that have global scope, BINDAGENT privilege only grants access authority for a specific owner. For example, to authorize USRFRED as the bind agent for USRJIM's packages, the following command would be issued:

TSS PER(USERFRED) DB2SYS(BINDAGENT.USERJIM)

This command allows USERFRED to BIND application plans and packages for USERJIM without having acquired access privilege for DB2 objects in those plans or packages. At BINDTIME, USERJIM's ACID is still checked for the appropriate authorizations.

Protect Table Columns

For table updates and referential constraints, you can permit access to the entire table or to selected columns of a table. For example, to give USRFRED UPDATE access to the BONUS column of the PAYROLL.SALARY table, you would issue the following command:

TSS PER(USRFRED) DB2TABLE(PAYROLL.SALARY.BONUS) ACC(UPDATE)