An intermittent problem may occur when accessing a table with DB2 when access is made thru the Guardium Encryption Product. A newly defined CSFKEYS resource with the SYMCPACFWRAP(YES) option was created to allow that access. After loading a table using the key, everything functions correctly. Later on, after some undetermined time/event, the user is unable to access the recently loaded table. The access is still lost even after an IPL. The only way to regain access is for the DBA to reload the table.
This specific issue may surface with the following configuration; GUARDIUM Encryption for DB2, SYMCPACFWRAP(YES) (for protected keys not clear keys). Use the following procedure to make it to work as expected.
1. Own the CSFKEYS resource:
TSS ADD(dept) CSFKEYS(protected.certificate.label)
2. Permit the DB2 task to have its required access:
TSS PER(db2_stc_acid) CSFKEYS(protected.certificate.label) ACCESS(READ) ASYMUSE(SECXPORT,HANDSHAKE)
SYMXPORT(BYANY) SYMCPACFWRAP(YES)
Note: This allows the DBA to load the DB2 table and encrypt it with the protected key, set a cached bit in ICSF that says the key is protected, and allows users to access the data if they are permitted.
3. Permit other users access to the WRAPPED Key. In order to allow access to the data after the ICSF Cache has been cleared (IPL, Recycle of ICSF or a refresh of the CKDS could cause the cache to be cleared.)
TSS PER(profile or ALL) CSFKEYS(protected.certificate.label) ACCESS(NONE) ASYMUSE(NOSECXPORT,NOHANDSHAKE)
SYMXPORT(BYNONE) SYMCPACFWRAP(YES)
This additional rule (not required in the RACF environment) allows the RACROUTE EXTRACT call issued against the first user to request access to the DB2 Table to extract the SYMCPACFWRAP(YES) attribute. This sets the bit in the ICSF Cache and all subsequent calls to access the DB2 Table do not issue the RACROUTE EXTRACT because ICSF has the bit cached.
For more information about CSFKEYS, see:
CSFKEYS Resource Class—Secure ICSF CSFKEYS