When planning the security policies for an IBM i installation, security officers can often overlook the special requirements that programmers will have. This tip will provide guidance on how to best provide security and programmer flexibility.
Problems with programmers
Whether the programmers for your System i are in-house staff or outside consultants, they will provide unique challenges to security. On one hand, they are almost always an expensive resource so the fewer hoops they have to jump through to get their work done, the more efficiently (and cost effectively) they can do it. On the other hand, giving them full access to your system is a huge security risk and one that you would not grant to anyone else in your organization.
Programmers will always take the position that they need full access to your system in order to work effectively. In some cases, that may even be true; especially in small to medium sized shops where there is only a single programmer or a small programming staff. When problems arise during normal production, someone needs to be able to jump in and fix it, regardless of the system or systems affected. So, full system access may be required.
But, for development projects and for programmers who are working on specific task assignments, full access is never going to be required. Library and object controls can be kept in place and the assignment of all object authority (*ALLOBJ) should be avoided at all costs. The fewer user profiles you have with *ALLOBJ authority, the better. Each user profile with this high level of access authority represents a significant security risk.
How to best deal with programmers
One good approach is to segregate your programmers on a separate system so that they can work in an unrestricted environment, but not work with live data. Many shops I've worked in or worked with have maintained a separate system just for programmers. With LPARs, many organizations just carve out a test partition for their programmers. New code can be created, compiled and tested in a test environment without exposure to live data. If you can afford this, it is a great compromise. You have to create a strong change control turnover policy so that new programs and data files get the right security configuration when making the transition from test to production, but that should be easy to control.
For programmers that support daily production, a lot of what they do will not require all object authority. For those situations where it is an absolute necessity, consider setting up a super user profile that can be activated by your security officer as needed. Then, when the situation is found where more than normal access rights are called for, your security officer can activate the super user profile for use by the programmer in question. As soon as the fire is out, the security officer can deactivate the super user profile and all will be secure.
As a last resort, if you can't pry all object authority away from a user profile, then you should at least be journaling activity for each programmer user profile that has this authority granted. While this will only provide after-the-fact reporting, at least you will have a record of events. To set this up, security journaling must be active. Then you can use the change user auditing (CHGUSRAUD) command to configure what you want to track for the user profile in question. For more information on how to set this up, refer to this tip on monitoring your System i super users. Even if you are able to remove all object authority for most of your programming staff, I'd recommend taking this approach for every user profile on your system that has full access to the system.
If you have any questions about this topic, you can reach me at firstname.lastname@example.org, I'll give it my best shot. All email messages will be answered.
ABOUT THE AUTHOR: Rich Loeber is president of Kisco
Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security
products for the IBM i market.
This was first published in August 2009