RPGIV @ Work

A unique site for RPG and System i Lovers

Welcome!

Hi, this site will provide all what you need in System i and RPG developments.

My Name is Chamara Withanachchi, System i Expert and RPG Developer. And in the field for last 11 years.

I hope you will find lot of valuable information from this site

Appropriate Authorities for Operators Print E-mail
User Rating: / 0
PoorBest 
Written by Chamara Withanachchi   

When the SOX auditors first started to roll through organizations, much focus was placed on the programmer role—especially authorities and capabilities granted to programmers on production systems. Now that programmer authorities are, in most organizations, granted according to their job responsibilities, I’m hoping auditors turn their attention to the operator role. Why? Because I believe many operators are being granted more capabilities and authorities than what’s required to perform their job functions and that this causes unnecessary risk. Let’s examine the authorities the operator role requires.

Special Authorities

An operator’s tasks vary depending on an organization’s size. The smaller the organization, the more varied the tasks and the more special authorities the operator may require. Typical operator tasks include managing jobs, answering messages, saving and restoring objects, starting and stopping writers, and more. Appendix D in the IBM i Security Guide shows tables of the corresponding commands that accomplish these tasks. Part of the table’s information is the special authority required to perform the task. You’ll find most operator-related tasks require *JOBCTL or *SAVSYS special authority. Notably absent from this list is *ALLOBJ and *SPLCTL special authorities. Even in a small organization, I don’t believe the operator role requires either of these special authorities. Yet, that’s what I see many organizations grant their operators. Yes, sometimes IBM i requires *ALLOBJ to perform what some consider to be operator tasks, for example when specifying “Allow object differences” with the *ALL option on the Restore Object (RSTOBJ) command. But rather than assign *ALLOBJ to the operator, I prefer to write a utility that provides the capability to specify this option. By utility, I mean a CL program configured to adopt authority (that is, its user profile parameter is set to *OWNER) and is owned by a profile that has *ALLOBJ. The only task the CL program performs is to prompt the RSTOBJ command. This utility is then placed as an option on a menu that contains other utilities or tasks operators need to perform.

I also believe that *SPLCTL shouldn’t be given to operators. *SPLCTL is the *ALLOBJ of spooled files. Once you give someone *SPLCTL, you can’t keep spooled files private. If a spooled file contains any sensitive information (e.g., checks or payroll receipts), anyone with *SPLCTL can see it. Operators need to be able to start and stop writers, but the combination of having *JOBCTL and properly configured outqs provide this capability without *SPLCTL.

 

Authority to Application Data

Many operators also have too much authority to application objects. I believe the purpose of *SAVSYS special authority is terribly misunderstood. Having *SAVSYS special authority lets operators save or restore any object on the system—regardless of whether they’re authorized to the object. In fact, they can be explicitly excluded from the object and still be able to save it. Many organizations have been granting a private authority to their operators (typically *ALL authority) because they’re under the impression that it’s required for them to perform a save of the system. These private authorities are unnecessary and provide the capability to perform tasks far beyond the scope of most operators. *ALL or even *CHANGE authority provides the capability to modify application data, view the contents of database files, and delete or clear the entire file. These abilities are not typically desirable for the operator role.

Another reason I’ve seen private authorities granted to operators is to run nightly jobs. I prefer to either remove the manual aspect and schedule these tasks in a job scheduler or, once again, use a CL program that adopts to perform the task. In this case, the program is owned by the profile owning the application. When the program runs, the operator has sufficient authority to run the task via the adopted authority of the program, not a private authority granted to application files.

Authorities to User Profiles

Another area of over-authorization I see is where operators have been granted authority to user profiles or even owning the user profiles. This is typically granted because either the operators are also performing helpdesk functions, such as resetting users’ profiles or passwords, or the operators are submitting jobs to run under profiles other than their own.

For helpdesk functions, I prefer adopted authority to having operators be authorized or own the profiles. In this case, the utility CL program prompts for selected parameters of the Change User Profile (CHGUSRPRF) command to let operators reset passwords and profile status. You may even want to add logic to prevent them from changing some profiles such as QSECOFR and other profiles with *ALLOBJ special authority so they can’t change the password of an all-powerful profile.

If operators have been given authority to a profile for job submission, I offer two alternatives: Have an administrator add the task to a job scheduler and let the task run automatically, or write a CL program that runs the Submit Job (SBMJOB) command and have that program be owned by and adopt a profile that has authority to the profile under which the job will run.

Policy and Education

Finally, operators need to be educated on how to appropriately handle confidential and private data. For example, your organization’s security policy may require media containing confidential or private data to be locked up at all times. Or perhaps when disposing of media containing private data, special degaussing must occur. Or maybe special procedures are required when restoring data from old media that contains unencrypted credit-card information or unsecured files holding private information. Restoring old files with unencrypted or improperly secured data may put your organization at risk of noncompliant with one of several laws or regulations. Or worse, it may put the data at risk of inappropriate disclosure or theft. Organizations need policies in place and operators should know the procedures that support the policies.

Just Enough

Operators play a vital role in all organizations. While it may be tempting to just give them all access to everything on the system, it’s an unnecessary risk to the confidentiality, integrity and availability of your data. I encourage you to examine the tasks your operators perform and give them only the required capabilities.

 

<Previous   Next>