January 16, 2018 | IBM i

Object Authority: Too Many Programmers, Too Much Authority

image

Object Authority: Too Many Programmers, Too Much Authority

In many shops, too many IBM i programmers have All Object (*ALLOBJ) authority. Worse, some shops also give their users *ALLOBJ authority, in order to provide access to applications without having to set up individual program security for each user. When IBM i applications were accessed solely via a green screen and users had menu driven access to the system, this wasn’t a problem. However, in today’s business environment, the IBM i is networked and exposed to the web, which puts your system at risk.

What auditors want

Since the auditors know that IBM i applications are notorious for having too much object authority granted to their users, excessive authority is one of the first things the auditors will look for. Due to compliance requiring separation of duties, the auditors also are checking to see if the user’s authorities match up with their job descriptions. There is no need for programmers to have*ALLOBJ access to production programs 24 X 7, yet many do and the auditors will find them.

 

Auditors always want to know who has special authorities and when they have accessed them. This can be difficult to document manually and it is extremely time consuming. Even worse, your manual efforts may not comply with regulations.

 

So how do you go about securing your system without affecting your user’s abilities to do their job? Solutions like iSecurity Authority on Demand can easily strip away excessive authorities. More importantly, they can grant increased authorities to individual users on a temporary basis, as necessary. Even better, iSecurity Authority on Demand retains a complete audit trail of what a user does when they invoke their temporary higher object authority.  This makes compliance easy to achieve.

Identify the Problem Areas

The first step in controlling excessive authorities is to identify who has excessive authorities. Then you need to analyze what authorities the user actually needs, in order to perform their day to day duties. Finally, you need to restrict their access to the lowest level needed on a daily basis and have a method to grant special authorities when needed with a complete audit trail.

 

In a previous post, we discussed the Authority Collection tool  built into the IBM i OS and how you can use it to determine what authority levels users need to perform their jobs. This tool will identify the lowest level of authorities your users need to access applications, but this is only the first step. There are instances when programmers need a higher level of authority to do their jobs. The trick is being able to easily monitor what they are doing and provide the auditors with all the details.

Providing a Better Method

Fortunately, there is an easy way to be able to provide users the authorities they need, when they need them, and to track everything they do. Using iSecurity Authority on Demand, companies can ensure that their programmers have access to the privileges they need, with a complete audit trail of what was done. This can be done automatically or it can be provided through the help desk.

 

One way to manage special authorities is to setup service accounts which require a pin code to access. Only those users who should have access to the service account know the pin, protecting your system.  Entering the pin code will allow the programmer to temporarily access the higher authorities they need, while the system tracks everything that they do, including capturing their screens. New pins can be generated on a regular basis, adding another layer of protection.

 

If you feel that having a service account with pin codes known by the users is dangerous, then you can require users to make a special request through your help desk. Providing a pin code on an as needed basis allows more control over higher object authority access. You’ll have a complete audit trail of who requested access and why, along with visibility of what they did. Regardless of which method works for you, you will have a complete audit trail of what was done by the user.

 

Another benefit of the iSecurity Authority on Demand approach is that you can use it when you have vendors who need temporary access to your system.  Often vendors need *QSECOFR or *SECADMIN rights to apply new applications or code changes. By using iSecurity Authority on Demand, you can easily capture all the activity they perform and have a complete audit trail for the auditors.

 

Without this solution, you can still manually generate the data the auditors want to see. However, it is a time consuming and error prone process. Using iSecurity Authority on Demand, you can easily generate a number of reports which are sure to meet the auditor’s needs. The best part is, you can help secure your system while still allowing users access to the privileges they need.