z/OS DB2 Security Configuration

Kevin Arnold

z/OS DB2 Security Configuration
We have a single, large production DB2 subsystem on z/OS. We also have about 16 non-production subsystems. Our environment is perhaps somewhat different than most in that simply reading unauthorized information has potential for significant impact to our company.

Our DBA's have been SYSADM for the last 15 years. They are responsible for the application data portion, of course. They did not have any problem with losing SYSADM as long as they have DBADM over their databases and appropriate (for our environment) other authorities such as SYSOPR. The Tech Manager, whose group is responsible for the DB2 software and overall system performance, is giving me all kinds of grief. He believes the DBA's should not have access to TRACE, RECOVER INDOUBT, or CANCEL THREAD because of the potential impact to the overall system performance, which is the primary means why they have SYSOPR. I am the security manager - I can't tell someone what their job is but I do feel responsible for giving people the authority they need to do their job. From my perspective, he needs to either convince the DBA's to give up these functions or develop a means of communication with them when these events happen.

Question 1 - are TRACE, RECOVER INDOUBT, and CANCEL THREAD authorities typically found in a DBA group?

The Tech Manager has given me other serious problems as well. We agreed that his people (responsible for one third-party application database, along with the DB2 software) did not have to have access to the DBA databases. So I setup a configuration where they basically have SYSCTRL and DBADM over their databases (DSNDB* and 3rd party), but not SYSADM nor INSTALL SYSADM. They could get a firecall ID with INSTALL SYSADM from the security department when needed which would be audited. Well, he went ballistic (even though it was his idea). He claims that whenever "maintenance" is done to one of our 17 DB2 subsystems, he must use INSTALL SYSADM and he can't wait for a firecall. He gave an example of going to "new function mode" in version 8, which is coming soon. He also says he would use SYSADM authority to do his normal Monday through Friday 8-5 job in maintaining the systems and simply having the subset specified here is not sufficient. I understand that INSTALL SYSADM is needed to gen a new system or to do a full recovery, but that doesn't happen very often here.

Question 2 - Is "INSTALL SYSADM" specifically needed to do DB2 "maintenance" from a software support perspective? E.g., going to new function mode

Question 3 - Ditto a regular SYSADM, compared to DBADM over DB2 databases and SYSCTRL?

I'll be the first to back down if my requests are not reasonable, but I'd like to know if I'm getting a snow job or not from the Tech's. Thanks in advance!


CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System intends this e-mail message, and any attachments, to be used only by the person(s) or entity to which it is addressed. This message may contain confidential and/or legally privileged information. If the reader is not the intended recipient of this message or an employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are prohibited from printing, copying, storing, disseminating or distributing this communication. If you received this communication in error, please delete it from your computer and notify the sender by reply e-mail.

Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm