When you initially approach the subject of security on the iSeries, or any machine for that matter, sometimes the task can seem monumental. You have to concern yourself with every object on the system and decide who can have access and what level of access they can have. For most iSeries shops, the number of objects on your system is astronomical. Having to make decisions on that grand a scale is enough to scare most IT professionals away from the task. The sad part is, many do ignore security, simply because it appears to be so difficult. The result of that approach can be costly when security is compromised.
The key to implementing an effective security design is to keep it as simple as possible. The designers of OS/400 security had this in mind when they created the security layer on your system, so it is entirely possible to achieve.
The first step in designing your security plan is to assess your needs. Where are there potential security exposures that could cripple the operation of your company? Most of the objects on your system are not business critical, so you should focus in on those that are. Decide what are the critical applications on your system and the key assets for those applications. Critical resources might be those that should be kept confidential (payroll comes to mind) or that are crucial company assets (such as your customer master or contact file).
Next, inventory the user libraries on your system and identify how they are used in your system. You can accomplish a lot by making a careful choice on the security setting for each library. You can enforce a global setting for all objects in that library by securing the library the way you want. As objects are created in that library, the default setting for the AUT parameter will adopt the setting in place for the library. If you are implementing security from scratch, you can process global GRTOBJAUT commands to set the authorities on existing objects. Having a clear idea of how each library is used in your system goes a long way towards keeping things simple from a security administration viewpoint.
As much as possible, don't deal with objects at the object level. Use library security settings to control global access to objects in a library. Of necessity, there will be specific objects that you will want to control differently within a library. Keep these to a minimum wherever possible and maintain a listing for your own reference of objects that are exceptions within each library.
When you have groups of objects that have similar access requirements, use authorization lists rather than maintaining each individual object authority. This will simplify your task by giving you a single authorization list to maintain rather than keeping up with the settings for each individual object.
The last global consideration in your plan to keep things simple is implementation of the *PUBLIC authority for objects. If you want to lock an object (or library) up tight, make sure it has a public authority of *EXCLUDE. You can also use the public authority to set basic access controls so for most objects, thereby avoiding having to maintain settings for specific users or groups.
Security can seem a daunting task, but it doesn't have to be that way. Get your plan together, inventory your system and lock it up in a way that your confidential and critical data assets are protected without giving yourself a huge maintenance job at the same time.
Rich Loeber is president of Kisco Information Systems Inc., in Saranac Lake, NY. The company is a provider of various security products for the AS/400 market.
