In last month's tip, I wrote about how to create a security policy for your System i. This month, I'll take a broad overview look at how to best implement the policy on your System i.
Part of your security policy will be implemented globally through the setup of your System i system values. Much has already been written about this and is generally available from this website and others. I do not want to duplicate that.
What is unique to each application, however, is the object level security setup that protects your basic data and programming elements. This is what I want to explore here by reviewing a few key practices that, over time, will simplify your security administration task.
The first of these key practices is implementing your object level security based on group profiles. Security can be implemented by individual profiles or by groups. Each user profile on your system can be assigned to a single group along with up to fourteen supplemental groups. A group profile is nothing more than an additional profile that is defined to your system but is set up so that it cannot be used for logon purposes. Its only purpose is to control object access. Once a group profile has been created, you can then add individual profiles to the group by placing the group profile in the GRPPRF (group profile) field or in the SUPGRPPRF (supplemental group). With group profiles implemented, you no longer have to create object access rules for each profile, just for the group profile. By reference, the rules for the group will then apply to each individual user profile that is included in the group.
Check your security policy document to identify the specific groups that you are going to need and get them set up on your system. Then, code the individual users into each group. When people leave the company, you will not have the issue of having to modify your security setup. Plus, adding a new user profile will be greatly simplified by not having to maintain an extensive set of individual object accesses. When you are all set up, you can generate listings for each group using the DSPUSRPRF (display user profile) command with the *GRPMBR option.
The other key practice that I want to discuss today with your security implementation is the use of Authorization Lists for object security. An individual object can be controlled by entering profile information directly associated with the object or by reference to an Authorization List. When you store your profile access rules directly with the object, then you cannot make updates to these rules when your object is in use. Using Authorization Lists, however, removes this obstacle and saves you from a lot of late night sessions.
Also, with an Authorization List, you can create a single security configuration that can then be applied to multiple objects on your system. At the individual object level, just reference the Authorization List and the rules created in the list will apply to the object. From your security policy, you will find general rules that apply within an application. These can easily be assigned to an Authorization List.
But, you ask, what about exceptions? Every security policy is going to have exceptions and you can deal with them as they arise. I try to discourage them by asking that a clear business case be made for each exception. The response, "well, it would just be a lot easier" is no longer acceptable. Those kind of exceptions these days can easily lead to banner headlines that will be embarrassing to you and to your company.
If you have any questions about anything included in this tip, you can email me. Messages will be answered as quickly as possible.
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 iSeries market.
