Authority collection

Authority collection is a capability that is provided as part of the base operating system. At a high level, authority collection captures data that is associated with the run-time authority checking that is built into the IBM® i system. This data is logged to a repository provided by the system and interfaces are available to display and analyze the data. The intent of this support is to assist the security administrator and application provider in securing the objects in an application with the lowest level of authority that is required to allow the application to run successfully. By using the authority collection capability to remove or avoid excess authority, the overall security of the objects that are used by an application is improved.

Applications available for the IBM i server often have excessive authority that is granted to the objects within the application. Analysis of applications proves that this excessive authority setting is true today even with the current laws and regulations that require sensitive data to be adequately secured. Traditionally, the public authority (*PUBLIC) of objects within an application is set to an authority value that exceeds the authority that is required to run the application. For example, the public authority on a DB2® table object (*FILE) can be set to *CHANGE authority even though the application requires *USE authority to the data. This excessive authority setting opens a security exposure in the system as the data in this particular table object can be changed, outside of the application, by users of the system. Further analysis of the application security settings shows where the authority setting is even greater than *CHANGE authority. For some applications, the authority setting of *ALL is used which allows users of the system to change the object and data and even delete the entire object from the system. The authority collection support is designed to provide the security administrator and application provider a tool to help lock down the security of the application objects.

Interfaces are provided to allow a security administrator to collect and analyze data that is associated with the authority checking support of IBM i. These interfaces support the ability to start authority collection for a specific user of the system. When this user runs a job on the system (interactive, batch, communication, and so on) and accesses objects within the application, authority collection data is gathered and written to the authority collection repository for the user. The data that is collected during the application’s run-time authority checks is significant in both volume and detail. For this reason, you must consider the performance impact that authority collection has on the run-time performance of an application. While the authority collection can be run on a production partition, the recommendation initially is to run the authority collection on a test partition where the application’s run-time performance requirements are not the same as the production environment. In addition, changes made to the authority settings of the objects, based on the authority collection data, need to be fully tested before the authority changes are made in the production environment.

Authority checking support is built into the IBM i Operating System (OS) and Licensed Internal Code (LIC). Each authority check that is requested by the OS and LIC is logged to the authority collection data repository for the user. Access to any IBM i object (*FILE, *PGM, *CMD, and so on) requires the authority check to succeed before access to the object and data is allowed. For the authority check to succeed, the user, the user’s groups, public authority, and program adopted authority settings are considered when the system checks for authority. Each object type can have different internal implementations and thus have different authority checking requirements. This is an important detail in relation to authority collection. For a single IBM i OS interface (CL Command, API, Service) numerous authority checks can occur against the object(s). Consider a simple example of calling a CL program that runs a simple command such as DSPJOBD or CHGJOBD. The system needs to find the library that contains the object, find the object within the library, lock the job description to prevent deletion while the interface is running, access the object itself to read (or change) the object and then display or change the data associated with the interface. Each of these steps, including locking the object, might perform an authority check against the object to make sure that the user is authorized to use the interface and target object. In fact, it is common that multiple authority checks are made by the OS and LIC for an object within a single CL command or API interface. The reason for this is that the authority checking logic built into the OS and LIC is run for internal interfaces that are used by the OS to access the object as well as the authority checks built into the interface itself.

An entry is logged in the authority collection repository for each unique authority check against the objects involved. This is important to understand as the authority that is required to the object must be derived from the cumulative “required authority” value from all of the authority collection entries that are logged for the object. For more information, see Analyze the authority collection data.