Granting programmers additional authority to production as needed.

[nycsusan@hotmail.com]

"Regular" programmers (a.k.a. developers) typically don't need *ALLOBJ authority. Production support people do, in my opinion, at least while they are on call. Where I have worked, the senior members of the team, and/or the people on production support have the authority to update production objects. At the soonest reasonable opportunity, they are supposed to get management approval, file an incident report, and have others review their changes. If production is down, our first priority is to get it running again. If we expect people to carry a beeper and respond to problems 24 x 7, they should be given the authority to resolve the problem ASAP ... why have them carry a pager otherwise? I have no idea if limiting authority to production support would pass an audit or not ... it probably depends on what kind of audit you mean. You can audit joblogs, so you can monitor online activity.

[Guest.Visitor]

Granting programmers additional authority to production as needed.

Janet Many companies undergo an IT Security Audit. Having every developer/programmer with *ALLOBJ is a HUGE NO-NO. Or even a handful with *ALLOBJ. But there must be protocols to follow where SOMEONE can fix the problems in a timely manner with the proper system authority, and the appropriate logging of WHO and WHAT was done. There really isn'y any NEED for developers/programmers to have *ALLOBJ system wide. Nor for carte blanche on the production environment. The larger the group, the less need for EVERYONE to have it. Then again, there are some shops where EVERYONE has *ALLOBJ because there just simply is not a proper security process in place. Just my $0.02 Phil

[David Abramowitz]

Granting programmers additional authority to production as needed.

Phil White wrote: Many companies undergo an IT Security Audit You may be surprised how many companies do not! Dave

[Guest.Visitor]

Granting programmers additional authority to production as needed.

Dave, Sadly, you are right.

[Guest.Visitor]

Granting programmers additional authority to production as needed.

Is there a standard in the industry on locking down programmers access to production, and then granting them more authority when needed for production emergencies? Should programmers be allowed to grant themselves more authority via a menu or command? What are you doing to grant programmer's more authority to production libraries when needed? Our programmers have READ access to production libraries...data and programs objects. We have a utility that an authorized person can use to grant more authority to programmers when needed, but we require a phone call or problem notice, before it is granted. If we were to let the programmers take a menu option or command to grant this authority themselves, would this pass an IT audit, or an IT insurance audit?? We have been asked by Application Managers (f.y.i....almost all of our software applications are written in-house), for the programmers to be allowed a "menu option" or "command" to invoke our temporary *ALLOBJ utility, and grant the additional access themselves. Currently, at my company, the Security Administrator or Data Center Operations has to take the menu option for temporary *ALLOBJ, and fill in the screen stating the reason the programmer needs the additional authority, and then the programmer has to log off and back on to get the *ALLOBJ....they cannot grant this themselves through a menu or cmd. This process invokes auditing on the programmer's user profile, so audit reports can be produced. The Application Managers and Programmers are wanting to eliminate the phone call to the proper granter (Security Administrator or Data Center Operations), and "self-serve" this to themselves from a menu or command. Our concern are: IT audits and no controls. What are you doing? Does anyone know if this would pass an IT audit? I appreciate your opinion, and time to respond.

[madmitch76@hotmail.com]

Granting programmers additional authority to production as needed.

Yup - familiar problem! Our solution was to give the programmers *READ authority under normal circumstances. If they required emergency access then they would use a generic profile. However the generic profile would has an initial program that required two things - firstly a DSPF that requires the programmer to verify their individual user and password (which is then recorded) and then take an affirmtive action to a STRCPYSCN message (the output of whom is also recorded). Ken