Planning object authority

This information is helpful when planning object authority.

Your challenge as security administrator is to protect your organization’s information assets without frustrating the users on your system. You need to make sure that users have enough authority to do their jobs without giving them the authority to browse throughout the system and to make unauthorized changes.

The IBM i operating system provides integrated object security. Users must use the interfaces that the system provides to access objects. For example, if you want to access a database file, you must use commands or programs that are intended for accessing database files. You cannot use a command that is intended for accessing a message queue or a job log.

Whenever you use a system interface to access an object, the system verifies that you have the authority to the object that is required by that interface. Object authority is a powerful and flexible tool for protecting the assets on your system. Your challenge as a security administrator is to set up an effective object security scheme that you can manage and maintain.

Object authority enforcement

Whenever you try to access an object, the operating system checks your authority to that object. However, if the security level on your system (QSECURITY system value) is set to 10 or 20, every user automatically has authority to access every object because every user profile has *ALLOBJ special authority.

Object authority tip: If you are not sure whether you are using object security, check the QSECURITY system value. If QSECURITY is 10 or 20, you are not using object security. You must plan and prepare before you change to security level 30 or higher. Otherwise, your users may not be able to access the information that they need.

Object authority to system commands and programs

When to restrict authority to IBM-supplied objects:

When you have more than one national language on your system, your system has more than one system (QSYS) library. Your system has a QSYSxxxx library for each national language on your system. If you are using object authority to control access to system commands, remember to secure the command in the QSYS library and in every QSYSxxx library on your system.
The System/38™ library sometimes provides a command with function that is equivalent to the commands that you want to restrict. Be sure you restrict the equivalent command in the QSYS38 library.
If you have the System/36™ environment, you may need to restrict additional programs. For example, the QY2FTML program provides System/36 file transfer.

Grouping objects

After you have determined ownership of libraries and objects, you can begin grouping objects on the system. To simplify managing authorities, use an authorization list to group objects with the same requirements. You can then give the public, group profiles, and user profiles authority to the authorization list rather than to the individual objects on the list. The system treats every object that you secure by an authorization list the same, but you can give different users different authorities to the entire list.

An authorization list makes it easier to reestablish authorities when you restore objects. If you secure objects with an authorization list, the restore process automatically links the objects to the list. You can give a group or user the authority to manage an authorization list (*AUTLMGT). Authorization list management allows the user to add and remove other users from the list and to change the authorities for those users.

Recommendations:

Use authorization lists for objects that require security protection and that have similar security requirements. Using authorization lists encourages you to think about categories of authority rather than individual authorities. Authorization lists also make it easier to restore objects and to audit the authorities on your system.
Avoid complicated schemes that combine authorization lists, group authority, and individual authority. Choose the method that best suits the requirement, rather than using all of the methods at the same time.

You will also need to add the naming convention for authorization lists to your Naming Conventions form. Once you have prepared an Authorization List form, go back and add that information to your Library Description form. Your programmer or application provider might have already created authorization lists. Be sure to check with them.

You can define resource security for individual objects on the system. You can also define security for groups of objects using either library security or an authorization list.

Defining how information can be accessed: You can define what operations can be preformed on objects, data, and fields.
Defining what information can be accessed: You can define resource security for individual objects on the system. You can also define security for groups of objects using either library security or an authorization list.
Authority for new objects in a library: You can specify the authority for new objects in a library.
Authority for new objects in a directory: You can specify the authority for new objects in a directory.
Objects that adopt the owner's authority: You can assign adopted authority to a user program to allow the user to change a customer file.
Programs that ignore adopted authority: You can specify the Use adopted authority (USEADPAUT) parameter to control whether a program uses the adopted authority.
Authority holders: An authority holder is a tool for keeping the authorities for a program-described database file that does not currently exist on the system.
Working with authority: This topic describes commonly used methods for setting up, maintaining, and displaying authority information about your system.