Limiting All-Object Authority

Hey, Wayne O.:

Is there a way to minimize the access to a file that contains salaries, for the user profiles that have *ALLOBJ authority? Can we give them access to the object but not to the content (data)? Is our only option to audit these user profiles and the files containing the salaries?

--Marc-André

People frequently ask me how to block access to an object for users with *ALLOBJ special authority. When the system determines a user's authority to an object, the first check made is whether the user has *ALLOBJ authority. If the answer is yes, the system allows the user access. So the answer is that there is no way to block a user who has *ALLOBJ authority. When I teach about special authority, I describe *ALLOBJ as equivalent to *GOD. There is no way to limit the access of God, so you want to be very careful what users you allow *ALLOBJ special authority.

Are you sure that the user needs *ALLOBJ authority? Restricting access to files and adopting authority in specific applications is a much better solution.

You can't hide individual fields like salary from the users who have *ALLOBJ authority. The only way to hide the content of specific fields is to encrypt either the complete file or the individual field. I recommend simply encrypting the salary field. The data could be stored in encrypted form and would only need to be decrypted in the programs that operate on the salary data. I suspect there are many programs that access the personnel data file but don't need access to the salary. These programs would not need to be modified. I am not aware of any software that performs this function.

You can audit the actions of individual users. However the OS/400 audit journal data simply records that an audited user opened the audited file. The audit record does not provide information on what fields were changed or retrieved. These are the steps to auditing a specific file for access by *ALLOBJ users:

1. Use the Change User Audit (CHGUSRAUD) command to activate auditing for profiles with *ALLOBJ special authority.

CHGOBJAUT   USRPRF(all-object-user)   OBJAUT(*ALL)

2. Use the Change User Audit (CHGUSRAUD) command to turn on auditing for the files that contain sensitive data. The OBJAUD option of *USRPRF will audit access for users identified in step 1.

CHGOBJAUD OBJ(PAYROLL) OBJTYPE(*FILE)   OBJAUD(*USRPRF) 

3. Activate object auditing by setting the system value QAUDCTL to *OBJAUD.

CHGSYSVAL SYSVAL(QAUDCTL) VALUE(*OBJAUD)

The system will write an audit record whenever a user accesses the payroll file, but the audit record will not tell which records in the file, nor which fields, were referenced or changed.

OS/400 journaling will show the records that were accessed. The journal will collect information for all users, not just specific users. However, you can process the audit data and select transactions for specific user profiles.

The other alternative I can think of is to define a trigger program for the files that contain sensitive data. The trigger program is called each time the file is accessed and can audit the actions of selected users. However, this option can have a marked increase in CPU use if the file with the trigger is accessed frequently. I do not recommend this option unless you have an overwhelming business need to audit the access.

--Wayne O. Evans

For more information on audit journals and *ALLOBJ users, see "Auditing Users with All-Object Authority."

Security articles authored by Wayne O. Evans can be found on his Web site, www.woevans.com. Click here to contact Wayne O. Evans by e-mail.