- An intermittent problem may occur when acccessing to a table with DB2 when access is made thru the Guardium Encryption Product.
- A new defined CSFKEYS resources with the SYMCPACFWRAP(YES) option was created to allow that access.
- After they load a table using the key all functions correctly.
- Later on after some undetermined time/event the User is unable to access the recently loaded table.
- Once they have lost access to the table that was loaded the event continues after an IPL!
The only way to regain access is for the DBA to reload the table!
- Use the following procedure to make it to work as expected.
- This specific issue may surface with the following configuration; GUARDIUM Encryption for DB2, SYMCPACFWRAP(YES) (for protected keys not clear keys).
This results to write 2 security rules for the CSFKEYS resource.
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)
Note: This allows the DBA to load the DB2 table and encrypt it with the protected key, sets 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 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)
- 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(YESS) 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.
- It you want to have more information about CSFKEYS resource class go to links: