Why a DB2 Violation Is Written To The AUDIT file On Behalf of the SECONDARY Authid?

Document ID : KB000050106
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

A DB2 violation is written to the AUDIT file, because it has no permission to a DB2 table.

However, the violation is written on behalf of the SECONDARY Authid.

Without a DB2 TRACE, there is no way to determine the primary AUTHID involved.

Solution:

CA Top Secret for DB2, similar to DB2, performs security based on the Authid the check occurs under and not the Primary Authid.

If a successful check or failure occurs against a Secondary Authid it, will be this id the event will be logged against.

In the CA Top Secret for DB2 documentation, there are numerous references to the disadvantages of using Secondary Authids.

One of the largest disadvantages is the loss of individual accountability.

The CA Top Secret DB2 Installation Guide section 'What Are Some of the Benefits?' documents the following:

With CA Top Secret Option for DB2 you do not need secondary authorization IDs. In fact, they can obscure the lines of individual accountability.

In the current design of the product there is nothing that can be done to alter this process.

Our recommendation would be to define TSS profiles to contain the permissions required from each of the Seconday Authids in the shop.
Then these profiles can be attached to the user who require the access and the Secondary Authids can be removed.

Below is an example of what the administration could look like this:

TSS ADD(deptxxx) DB2TABLE(TABLEXX)
TSS CRE(XXprof) NAME('profile for XX resources') TYPE(PROFILE) DEPT(deptxxx)
TSS PER(XXprof) DB2TABLE(TABLEXX_ABC_XYZ) ACCESS(SELECT)
TSS ADD(acidxx) PROF(XXprof)    

Once this setup is in place, then the SET CURRENT SQLID could be removed from the SQL and the Secondary Authid would no longer be required.
The resource check for this table would be satisfied on the check against the Primary Authid.