Hello,
We are in the process of migrating from a different vendor's DB2 utilities to the CA v18 utilities. In doing this, we've notice that product authorization is treated a little differently.
For our current vendor's utilities, we give users EXECUTE to a particular utility or tool's plan. Once they have that authority, they can use the utility or tool on any DB2 object that they have correct rights for. They did not need any special access for the vendor product tables. For example, for LOAD, they need EXECUTE to the load plan and LOAD authority to the table being loaded. For Unload, they need access to the UNLOAD utility and SELECT on the table being unloaded. For the query tool, they need EXECUTE to the tool and then DB2 rights to whatever they are querying, updating, etc.
With the CA utilities and tools, we are finding that giving people access t the PLANs does not always cover everything they need even if they have the right rights to the table, utility, etc. that they are working right. For example, for RC/EXTRACT and RC?Migrator, not only do people need EXECUTE to those plans, they also need SELECT, INSERT, UPDATE, DELETE to certain CA product tables. If they don't have these rights, they receive an error.
Although this is doable I see it as risky because this means that some of our more savy users could update the CA product tables directly and this could result in invalid data, incomplete updates or deletes, etc. I say this because they are bypassing the panels which do the validation checking and are also bypassing the CA programs which ensure that all of the required changes are made and things are kept in sync.
We've had a number of products and I can't remember ever seeing one where not only did you have t give people EXECUTE to the plan, but you also needed to give them rights to some of the underlying product tables. If more granular authorization was needed (ie allow a person to view but not update something, that was controlled from within the product itself.
To address this and eliminate the need to do GRANTS at the CA product table, we were thinking about changing the binds from DYNAMICRULES(RUN) to DYNAMICRULES(BIND) but since the packages and plans are bound with OWNER set to a group that has SYSADM rights, we're concerned that this will bypass an individual user's authorization at the object level and instead allow the use the OWNER/SYSADM authorization.
Does anyone have suggestions on how we can eliminate the need to give individuals direct access (ie INSERT, UPDATE, DELETE, SELECT) to the underlying CA product tables? Does this seem like a reasonable request?
Look forward to hearing other people's opinions.
Thanks,
Donna Domovic