As a security officer, most of the time you are concerned with granting access rights to users. To do this, you need to know what the user's job responsibilities are and what they will be doing within the computing environment. Based on existing security policies for your shop, you then configure security for each user so that they can get at the computing resources they need to do their job easily, smoothly and securely.
Once you have a users set up and running, however, they tend to fall off our radars since we're then occupied with getting the next group of users set up and configured. In other words, there is a tendency to address areas where there are immediate demands at the expense of others.
Modifying access rights on System i
One important thing to keep track of, however, are situations where access rights need to be modified or rescinded. The most glaring situation is when someone leaves the company. You should have a clearly developed plan of action to implement when someone leaves. This plan should include:
- Deactivating their user profile
- Identifying any objects owned by their profile and reassigning them
- Removing access rights for objects not owned by them
- Deleting the user profile after all else is done
But just deactivating a profile is not sufficient. Batch jobs can still be run under an inactive user profile and those jobs will still have rights to the object set that was defined for that user. So you must take the additional action of removing those access rights. Rescinding access rights is just as important to a secure installation as granting those rights.
Unmonitored rights pose a security threat
Chances are your System i is currently sitting with loads of unnecessary access rights in place for people who are long gone. Each one of those access rights is a potential security exposure and should be dealt with. You should review the way the user was initially configured when their access rights were granted and then go through and reverse the process.
Making this work depends on you being in the loop when someone leaves the company. In a small shop, you normally learn this by word of mouth. But, in any size shop, a formal notification process needs to be put in place to guarantee that inactive profiles are dealt with promptly. This can be especially important if someone leaves on bad terms. A firm procedure has to be in place with your HR staff and it must be enforced.
The other situation for which you need to prepare is when someone has a change in job responsibilities. In this situation, you will not only need to grant new access rights for the user, but you will also have to backtrack and possibly remove some earlier rights that have already been granted. Again, careful coordination must be worked out with your HR folks. You are likely to hear about this through less formal channels since the user will need to get reconfigured in order to start their new responsibilities.
If you have any questions about this topic, send me a message. All email 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.
