We All Just Want To Feel Special
[Please note, this is the second of a two-part series. You can read the first article here.]
While everyone likes to feel special, we need to be more selective when it comes to data access. As we discussed last month, many users have privileges far beyond their business requirements and simply need to have their access reduced to more reasonable levels.
The first step is to build an inventory of user profiles with administrative privileges. You can do this using the “Print User Profile” (PRTUSRPRF) command, although the task of determining if any special authorities are being inherited from group profiles is largely a manual effort. As a better alternative, Powertech Compliance Monitor for IBM i provides an assessment report that interrogates both user and group profile definitions to easily identify powerful profiles regardless of whether authority is defined in the base profile or is inherited from a group. You can apply filters to suppress known profiles, such as QSECOFR, or any service profiles you might have created.
Once you’ve identified the administrative profiles, you should create a plan to remove unnecessary privileges. This often entails changes to a user’s base profile, or to the groups to which they belong. Unfortunately, IBM doesn’t publish a list of functions that require a particular special authority so the process of removing authorities can be a little problematic. One approach is to test with a few representative users who can help identify when tasks break because a certain privilege has been removed.
If issues are discovered, programs that adopt authority can be written to allow restricted functions to run without the invoking user needing additional authority on their own profile. Powertech Authority Broker for IBM i, a powerful privilege management solution, can also provide temporary elevation of privileges to perform tasks—along with notification and an easy-to-generate audit trail.
Watch this session to learn more about *ALLOBJ >
Take Command of the Command Line
The risk associated with excess privileges can be mitigated by removing a user’s command line capabilities. Control command usage via the user profile’s “Limit capabilities” setting; this restriction is based on each command’s “allow limited users” property. Thus, it’s important to control and monitor the CHGCMD command to ensure that this property is not altered on commands.
Unfortunately, a user’s “Limit capabilities” restriction is only guaranteed to be effective on 5250 sessions; other interfaces might not observe the setting. Network interfaces such as FTP still allow limited users to execute commands. The best way to control and audit users accessing commands and files through network interfaces is to implement an exit program solution such as Powertech Exit Point Manager for IBM i. To gain additional control of the command line environment, use Powertech Authority Broker for IBM i to provide only temporary access to a command line, and Powertech Command Security for IBM i to restrict how and when commands can be run by a user—including programmers and security officer-class profiles.
Everyone Must Respect Authority
Configure *PUBLIC access to support a “deny-by-default” model. Instead of the door being open to all users—as it is for most organizations—it should be closed; only those users on the IBM i list of authorized users should be allowed access. Establishing resource security can be a daunting task to the uninitiated, but it’s often a simpler task than many people fear. The most important thing to remember is that IBM i determines permissions in an entirely predictable way. I mention this, as a common response to an authority failure is to grant *ALLOBJ to users, or *ALL access to *PUBLIC. While these are “now it will work” instant fixes, neither determines the underlying reason for the failure. As an analogy, imagine having a problem with an office door lock. Would it be a reasonable to fix this by giving every user the master key to the building? Would it make sense to remove all of the locks and turn off the alarm system? No, of course not!
For users without the “skeleton key” privilege associated with *ALLOBJ, private authority access needs to be assigned. As with *PUBLIC, this can be done quickly via authority to the library, and then (optionally) to the objects within the library. A user who requests access to a file or a program must have access to both the library that the object resides in as well as the object itself. If the user doesn’t have access to the library, IBM i doesn’t even check authority to the object. This means a user can be denied access to an entire database simply by denying access to the library that contains it.
Lastly, don’t overlook what powerful users can do via access through the Integrated File System (IFS). Many systems retain the open authority that the “root” folder is shipped with—the equivalent of *PUBLIC(*ALL)—and should be secured immediately. Modify the QPWFSERVER authorization list so that *PUBLIC doesn’t have access to the native \QSYS.LIB structure, although any remaining *ALLOBJ users still have complete access. Deploy an exit program solution to supplement the native controls for controlling and auditing access within the IFS, including those remaining *ALLOBJ users.
IFS directory authority is different from IBM i native controls as it follows the Unix security scheme. The nested folder structure adds some complexity that doesn’t exist when we talk about libraries. The trick is to not over-secure the folders, and to make notes about changes so that they can be undone if necessary. Also, IBM folders (except root) are typically configured correctly and should not be altered without good reason.
Don’t Forget the Auditor!
While it’s important to ensure that users only have appropriate levels of privilege, there always are going to be users that need access to restricted areas. I recommend to clients that users that are “powerful” and that have access to a command line, should be audited. This can be accomplished using the CHGUSRAUD command to turn on comprehensive auditing of the users’ actions, including commands that they have executed.
Unfortunately, the extraction and reporting of a user’s audit data can be extremely time-consuming and frustrating. Using a commercial tool like Authority Broker for IBM i simplifies the process of maintaining order for powerful users as well as generating the audit trail of their actions required by auditors.
Don’t Let All Object Be Your Invitation To Data Loss
This two-part article has provided guidelines regarding the definition of a powerful user. It also has identified actions that you can take to limit the exposure associated with that power. After all, we don’t want absolute power corrupting absolutely, or accidentally!
If you missed the first part, read it here.
Take Control of *ALLOBJ Authority
Authority Broker for IBM i makes it easy to give you users only the authorities they need and only when they need them. To see for yourself, request a demo.
