DB2 Violation In Top Secret AUDIT File For Secondary Authid

Products

• Top Secret

Issue/Introduction

When using Top Secret for DB2 and a DB2 violation is written to the Top Secret AUDIT file because it has no permission to a DB2 table, the violation is against the secondary AUTHID. Without a DB2 TRACE, there is no way to determine the primary AUTHID involved.

Why is the violation occurring on the secondary AUTHID?

Resolution

Top Secret for DB2, similar to DB2, performs security based on the AUTHID the check occurs under, not the primary AUTHID. If a successful check or failure occurs against a secondary AUTHID, this will be the ACID the event is logged against.

In the Top Secret for DB2 documentation, there are numerous references to the disadvantages of using secondary AUTHIDs. One of the biggest disadvantages is the loss of individual accountability. The Top Secret DB2 Installation Guide section 'What Are Some of the Benefits?' documents the following:

With 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 Top Secret profiles to contain the permissions required from each of the secondary AUTHIDs in the shop.
Then these profiles can be attached to the users 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, the SET CURRENT SQLID could be removed from the SQL and the secondary AUTHID is no longer required. The resource check for this table would be satisfied on the check against the primary AUTHID.