Effectively securing your system’s resources in terms of applications and business data takes a lot of effort. It also requires a well-devised strategy as well as comprehensive planning and implementation measures. As in many of life’s circumstances, good intentions will take you only part of the way. Upon successful completion of all planned activities, you’ll need to ensure that all vital security policies and precautions are continuously enforced as the daily business once again takes over the agenda.
If not, your next internal or external system security audit most certainly will provide you with a wake-up call, making my aforementioned statement brilliantly clear to you. Your auditors will listen with great interest as you explain the basic principles of the Application-Only resource security model that constitutes the backbone of your system security policy (for a list of Application-Only resources, see Find Out More, below). The fact that only the application programs possess adopted authority to access your data files, and that all user profiles have access to these programs only through group profile membership, might initially impress your auditors, depending on their knowledge of the IBM i security mechanisms.
After all, the presented security model is flexible and, to a great extent, exploits the advanced built-in security features of the IBM i. The excitement is bound to quickly fade, however, when the audit reveals that the payroll file, following a recent change that added two new fields, is now owned by a developer user profile, and the file’s public authority is defined as *CHANGE. The given example is, of course, quite obvious. But other more subtle failures to comply with the security scheme in place might be more difficult to discover, while in turn causing a similar serious impact on your system’s resource protection.
Even if the security exposure remains undiscovered at first, having to explain the failure to comply with your signed-off security policy to your security auditors might in its own right spell disaster. Needless to say, that part of implementing your security model would in fact include well-defined processes that handle moving application objects into production and apply the necessary object ownership, private authorities, authorization list, program authority adoption attributes, and whatever else is required. But experience tells me that regardless of the effort put into ensuring that nothing goes wrong, eventually something will.
To help me verify and manage object authority and security attribute settings on demand, and to avoid potentially unpleasant conversations with my security auditors, I’ve designed and created a couple of object authority CL commands. One command helps me compare the security-related attributes of two specific objects and reports found discrepancies; the other performs the same comparison for a list of objects. Here, I explain the two commands and how you can take advantage of them.
The CMPOBJAUT Command
Managing object authority requires control of a number of object attributes, such as object ownership, object private authorities, object primary group, and object authorization list, to mention the most common properties involved. In addition, database file objects support field-level authority, and program objects define how the program interacts with adopted authority. As for the latter, programs can both inherit adopted authority from previous call levels and adopt their own owner’s authority, depending on the program’s USEADPAUT and USRPRF attribute setting, respectively.
The WRKOBJAUT Command
The Work with Object Authority (WRKOBJAUT) command lets you indicate a range of objects defined by either a generic object name or the special value *ALL for objects located in the specified library for comparison against either a specific reference object or the corresponding object in a stated reference library. You have the option of further narrowing the selected object range by criteria such as object attribute, user-defined attribute, creator-user profile, owning-user profile, as well as object create, change, and last-used date ranges.
Articles on Apis 