Administrator > Security

Role-Based Access

Controlling authority using roles saves time, requires less effort and meets auditing challenges.

Are you finding that providing users’ access to resources such as files, libraries, directories and so forth is becoming unwieldy? Are you attempting to allow access for individual users? Do you want to sink into the floor when the auditor requests a report of users’ access? If the answer to any of these is yes, implementing roles and role-based access can be the answer to help reduce the time and effort spent on managing users and their access.

Roles

The premise of roles is users are given capabilities and access to applications or system resources based on their job functions or roles. For example, organizations may have some or all of the following roles: operator, system administrator, security officer, programmer, programming manager, quality assurance tester, system analyst, etc. Depending on the size of your organization, several individuals may have the same role. Or, in very small shops, you may have one person who performs several roles.

Roles can also be defined within an application. For example, in an accounting application, you have an accounts receivable (AR) clerk, AR supervisor, accounts payable (AP) clerk and AP manager roles. Each role—whether defined for an operating system or application—has a specific set of tasks it’s expected to perform. Therefore, access to system resources or application functions are permitted or denied based on the role in which the user has been defined.

To implement role-based access, first define what roles are required and who should fill them. There’s no right or wrong as to how many roles should be defined, but identify too few and you’ll end up giving users more authority or access than they need to perform their job functions; too many roles and their management gets unwieldy.

The next step is to list the tasks the roles already perform or should perform. Here are some examples:

• Operator—Perform backups, submit routine batch jobs, run nightly processing jobs, restore libraries upon request, monitor for system messages, start and stop writers, work with printed output
• System administrator—Performance tuning, perform system upgrades, install and configure third-party applications, manage the job scheduler, TCP/IP configuration, WebSphere* configuration, LPAR configuration and management
• Programmer—Write and update application code, test code, debug production issues, fix programming defects
• Security officer—Create and manage user profiles, manage and monitor system security configuration to ensure compliance with the organization’s security policy, monitor past security-relevant events

Once roles are defined, the next step is to determine what capabilities and access is required to perform the tasks. On IBM i, this typically involves determining required special authorities. Additionally, you’ll want to list what programs or System i Navigator tasks are required to perform the tasks. Note especially the resources that the role would normally be excluded from or prevented from accessing. This way you know to accommodate this when you start implementation.

For IBM i, roles are implemented most easily through group profiles. Create a group for each role and assign the special authorities required to perform the role’s tasks. Additionally, grant the group (role) any private authorities required to application objects such as menus, files, authorization lists, commands, etc.

Tips

When creating the group profile on IBM i, create the profile without a password (set the password parameter to *NONE), so it can’t be used for signon. Group profiles are supposed to represent a role, not an individual.

To eliminate your group profiles from appearing on reports auditors may request, set:

• limited capabilities to *YES so that the group doesn’t appear on a report listing the profiles with limited capabilities set to *NO
• password expiration interval to *SYSVAL
• initial menu to *SIGNOFF

If the name of the group profile doesn’t make it obvious what role it’s representing, add the explanation to the Text field.

Considerations

When determining what special authorities are required for each role, be careful to understand the task that needs to be performed. For example, programmers will often insist they need *SAVSYS or, worse, *ALLOBJ special authority. But if you dig for more details, they usually want a special authority because they’re assuming the function they’re running requires it. My point with this example is to encourage you not to let the users demand the solution to their capability and access requirements. They should provide you with a detailed explanation of the tasks they must perform. Then, it’s the security officer’s responsibility to determine the best—and most secure—way to allow users to accomplish their tasks.

Implementing roles via group profiles also provides an easy reporting and reviewing mechanism. Many laws and regulations, as well as internal and external auditors, require that user access be reviewed on a regular basis. If you can’t easily produce reports listing user access, the review process becomes very confusing for all involved and, quite frankly, is often ineffective in reaching the objective (that is, to remove access from users who no longer require it). By implementing roles, the appropriate manager reviews the capabilities and access associated with the role and then reviews the users in the role to determine 1) whether the role still requires the current access and capabilities and 2) if each user should remain assigned to the role. Without roles, users and their individual access rights and capabilities must be individually reviewed, which can be very tedious and time-consuming.

Another reason for implementing roles via group profiles is to keep a record of the access rights and capabilities of each role. I encourage you to provide access and capabilities only through roles (groups). This will ensure that if the user leaves the company, there’s a clear and accurate reflection of what the person replacing the individual needs—simply place the new person in the former employee’s role (group).

When helping clients implement role-based access, the question often arises—if there’s only one user in the role, do you still create the group profile? In my opinion, yes. That’s because if you discipline yourself to only grant access to the group (role), the group will always have the authorities required to perform the role’s functions. This is helpful when the one person in the role either is dismissed from the company or is on vacation, on leave or is otherwise away from the office for an extended period. All you have to do to allow someone to take over the role is to add the person to the group. If you haven’t implemented the capabilities and access at the group profile, then you have to try to determine what authority the individual profile has been granted (or revoked) and replicate that for the person just placed into the role. If the role has been implemented via a group profile, all you have to do is make the user a member of the group profile.

Annual Review

I recommend everyone review the capabilities and authorities assigned each role as well as the users assigned to the roles at least annually. To review the members of the role, simply run the Display User Profile (DSPUSRPRF) command requesting the list of group members:

DSPUSRPRF USRPRF(group_name) TYPE(*GRPMBR)

To review the capabilities (special authorities) given to the role, display the group profile representing the role:

DSPUSRPRF USRPRF(group_name)

To determine what authorities the role has been granted, run the same command, requesting the list of objects authorized:

DSPUSRPRF USRPRF(PROGRAMMER) TYPE(*OBJAUT)

Reviewing these items at least once a year will help catch the users who’ve changed positions within the organization and, therefore, have changed role. They probably have already been assigned to their new role, but it’s often difficult to determine if a user needs to be removed from a role. This review also lets you confirm that the role hasn’t been given excess authorities or capabilities.

Always Right

Whether you’re trying to reduce the time it takes to prepare for an audit, want to make the review of user access simpler and less time-consuming or you’re trying to simplify user management, role-based access is for you.