By Rich Loeber
When planning out the security policies for your trusted IBM i installation, security officers can often overlook the special requirements that programmers will have. This tip will try to provide some ideas of how to best deal with this situation.
The programming staff for your IBM i, whether they are in-house staff employees or outside consultants, provide unique challenges to security. On one hand, they are almost always an expensive resource so the fewer hoops they have to jump over to get their work done, the more efficiently (and cost effectively) they can get their work done. 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 the day with normal production, someone needs to be in the position to jump in and address the issue, regardless of the system or systems affected. In order to be able to do that effectively, 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.
So, how do you best deal with your 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 that I've worked in or worked with have maintained a separate system just for the use of programmers. In this day of the logical partitioning (LPAR), 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 do 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 your programmers who 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 then deactivate the super user profile and all will be well.
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 provide after-the-fact reporting, at least you will have a track 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, see my previous security tip titled Watching Your 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 rich @ kisco.com, I'll give it my best shot. All email messages will be answered.
RECENT POSTS
CATEGORIES
