Here is what IBM says about planning security for programmers...
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzarl/rzarlpgmrsec.htm
Programmers pose a problem for the security officer. Their knowledge makes it possible for them to bypass security procedures that are not carefully designed.
Programmers can bypass security to access data they need for testing. They can also circumvent the normal procedures that allocate system resources in order to achieve better performance for their own jobs. Security is often seen by them as a hindrance to doing the tasks required by their job, such as testing applications. However, giving programmers too much authority on the system breaks the security principle of separating duties. It also allows a programmer to install unauthorized programs.
Follow these guidelines when setting up an environment for application programmers:
• Do not grant all special authorities to programmers. If you must give programmers special authorities, give them only the special authority that is required to perform the jobs or tasks that are assigned to the programmer.
• Do not use the QPGMR user profile as a group profile for programmers.
• Use test libraries and prevent access to production libraries.
• Create programmer libraries and use a program that adopts authority to copy selected production data to programmer libraries for testing.
• If interactive performance is an issue, consider changing the commands for creating programs to run only in batch:
CHGCMD CMD(CRTxxxPGM) ALLOW(*BATCH *BPGM)
• Perform security auditing of application function before moving applications or program changes from test to production libraries.
• Use the group profile technique when an application is being developed. Have all application programs owned by a group profile. Make programmers who work on the application members of the group and define the programmer user profiles to have the group own any new objects that are created (OWNER(*GRPPRF)). When a programmer moves from one project to another, you can change the group information in the programmer’s profile. See Group ownership of objects for more information.
• Develop a plan for assigning ownership of applications when they are moved into production. To control changes to a production application, all application objects, including programs, should be owned by the user profile that is designated for the application.
Application objects should not be owned by a programmer because the programmer can have uncontrolled access to them in a production environment. The profile that owns the application might be the profile of the individual responsible for the application, or it might be a profile specifically created as the application owner.
Assuming you have at least two systems (production & development), be thankful you are restricted on the production system; they are there for your protection also.
Authority Broker from PowerTech covers your backside when you are on the production system by creating an audit trail of your actions. This trail can save your bacon when someone says "You changed something! That's why it isn't working now! IT'S ALL YOUR FAULT‼" or the auditor requires you to detail the actions you took on the production system.
With Authority Broker, you swap to a profile with the authorities you need, do what needs to be done and get off the system. All audit information is handled by Authority Broker.
Gary Monnier
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan
Sent: Tuesday, August 04, 2015 9:59 AM
To: Midrange Systems Technical Discussion
Subject: Re: Anyone written a functional duplicate of EDTLIBL?
Would seem reasonable to just ask to have the Edit command publicly
authorized similar to the others.? There is unlikely to be anything
valid offered to support their decision to have disallowed the one
while allowing the others.?
One word answer: Auditors.
To be fair, I've not been here long enough to know the history of how things came to be. I've known of other shops that have "negotiated" with auditors, explaining the need to have access to certain things, but I'm not sure whether they've done any of that here. We also do not have access to CRTLIB / CPYLIB here. To me, this just screams that the auditors have no effing idea what they're doing.
- Dan
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxx> To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx<mailto:MIDRANGE-L-request@xxxxxxxxxxxx> Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
