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

Products

• Cleanup
• Datacom
• DATACOM - AD
• CIS
• COMMON SERVICES FOR Z/OS
• 90S SERVICES
• DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS
• COMMON PRODUCT SERVICES COMPONENT
• Common Services
• CA ECOMETER SERVER COMPONENT FOC
• Easytrieve Report Generator for Common Services
• INFOCAI MAINTENANCE
• IPC
• UNICENTER JCLCHECK COMMON COMPONENT
• Mainframe VM Product Manager
• CHORUS SOFTWARE MANAGER
• CA ON DEMAND PORTAL
• CA Service Desk Manager - Unified Self Service
• PAM CLIENT FOR LINUX ON MAINFRAME
• MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME
• GRAPHICAL MANAGEMENT INTERFACE
• WEB ADMINISTRATOR FOR TOP SECRET
• Xpertware
• Top Secret
• Top Secret - LDAP
• Top Secret - VSE

Issue/Introduction

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.

Environment

Release: TOPSDB00200-1.3-Top Secret-Security-Option for DB2 UDB
Component: