Appendix A: Managing Security With Adoption
This appendix describes a method for managing security on your iSeries or AS/400 that is both effective and easy to maintain. The method uses adopted authority to control access to your production objects.
Many AS/400 systems have little or no authority restrictions implemented. This is, of course, easy to maintain, but it leaves the system open to the corruption of production objects, both by accidental and intentional means.
Where authority restrictions are used, the approach most often considered is to restrict access at the object level. That is, an attempt is made to identify key objects, and then to grant the appropriate object authorities to certain users and groups.
The operating system lets you specify which users have which rights to which objects. But keeping object authorities up to date can quickly become very complex. As the numbers of objects and users grow, two types of authority errors become more and more likely:
1. A user is mistakenly given more authority to an object than they should have, resulting in a security exposure.
2. A user is given less authority to an object than they need to get their job done, resulting in application failure.
Part of the difficulty in accurately maintaining authorities at the object level is that it is unnatural to think in terms of authorizing users to objects. It is more natural to think in terms of authorizing users to tasks or functions. When your security scheme is based on authorizing users to access objects, you must make a mental translation:
“User JSMITH should be allowed to run A/P reports, so lets see...What files does JSMITH need access to?”
Because you are forced to think indirectly, this method of implementing security often leads to mistakes.
There is another big weakness to managing authorities at the object level: the object rights that are granted are not limited by context.
For example, if JSMITH needs to run an application that might remove a member from file APTRAN, JSMITH needs to have *ALL authority to APTRAN. Otherwise the application will fail when it attempts to remove the member.
But with *ALL authority to APTRAN, JSMITH could execute the DLTF APTRAN command, either accidentally or on purpose, clobbering the entire file. The only way to prevent this would be to insure that JSMITH could never enter commands at a command line.
Most security experts agree that using adopted authority is a better strategy than trying to directly manage authorities at the object level. With the adopted authority approach:
· Users are excluded from directly accessing production objects.
· Users temporarily adopt the authority needed to access the appropriate objects when they are performing an authorized function.
Using this approach, the security administrator can manage users’ access to functions instead of objects.
In the past, implementing the adopted authority approach to system security has been easier to say than do, because the AS/400 lacked tools to allow administrators to easily manage which functions users were authorized to perform. What administrators need is a facility for defining application functions and their attributes, including:
· The function name and description.
· The action or actions associated with the function.
· The users authorized to perform the function.
· The extra authority, if any, that users should adopt for the brief time that the function is being executed.
It’s no accident that ALC menus and menu options let administrators define functions with all of the above attributes—including authority adoption.
To implement security on your system, using the adopted authority approach and the A la Carte Menu and Security System, simply follow these steps:
1. Insure that the QSECURITY system value for your system is set to 30 or greater.
2. Identify all production libraries.
3. Create a user profile, such as PRODOWNER, that will own all production objects. The profile should not be a member of any group.
4. Use the Change Object Owner (CHGOBJOWN) command to insure that all objects in all production libraries are owned by PRODOWNER. Set your change management tool to enforce this standard.
5. Use the Revoke Object Authority (RVKOBJAUT) command to revoke all private authorities from all production objects.
6. Use the Change Object Authority (CHGOBJAUT) command to set the *PUBLIC authority for all production objects to either *EXCLUDE (prevents any command line access) or *USE (allows read access). Set your change management tool to enforce this standard.
7. Create ALC menus as needed to group application functions. Control user access to menus by displaying the menu and then pressing F23.
8. Create one ALC menu option for each application function. Specify PRODOWNER for the “Authority to use” parameter. Control user access to menu options by positioning the cursor to the menu option and then pressing F23.