Resource security

You can use resource security on the system to control the actions of authorized users after successful authentication.

System values and user profiles control who has access to your system and prevent unauthorized users from signing on. Resource security controls the actions that authorized system users can perform after they have signed on successfully. Resource security supports the main goals of security on your system to protect:

Confidentiality of information.
Accuracy of information to prevent unauthorized changes.
Availability of information to prevent accidental or deliberate damage.

The security officer protects the resources (objects) on the system by determining who has the authority to use them and how user can access these objects. The security officer can set object authorities for individual objects or for groups of objects (authorization lists). Files, programs, and libraries are the most common objects requiring protection, but system security allows you to set object authorities for any object on the system.

You can manage resource security simply and effectively, if you plan a straightforward approach in advance. A resource security scheme created without prior planning can become complicated and ineffective.

Resource security on the system allows you to define who can use objects and what operations they can perform on those objects. The ability to access an object is called authority. When you set up object authority, you need to be careful to give your users enough authority to do their work without giving them the authority to browse and change the system. Object authority gives permissions to the user for a specific object and can specify what the user is allowed to do with the object. You can limit an object resource through specific detailed user authorities, such as adding records or changing records. System resources can be used to give the user access to specific system-defined subsets of authorities: *ALL, *CHANGE, *USE, and *EXCLUDE.

Files, programs, libraries, and directories are the most common system objects that require resource security protection, but you can specify authority for each object on the system.

The system provides several tools to assist you in designing a straightforward resource security scheme:

Group profiles

You can group users with similar authority needs under a single group profile. Then the users in the group can all share the same authority to use objects unless you define specific authority for a user in the group.

Authorization lists

You can group objects with similar security requirements in an authorization list. Then you can grant authority to the list rather than to the individual objects. An authorization list contains a list of users and the authority that the users have to the objects that the authorization list secures. You can also use an authorization list to define public authority for the objects on the list. When you set the public authority for an object to *AUTL, the object gets its public authority from its authorization list. You cannot use an authorization list to secure a user profile or another authorization list. Also, you can specify only one authorization list for an object. For more information, see "Authorization list security" in the iSeries™ Security Reference.

Validation lists

Validation list objects provide a method for applications to securely store user authentication information.

User authority

You can define specific authority to access and use objects for individual user profiles. Using user authority may be helpful when you have a small number of users that have access requirements that do not conform to group requirements.

Object ownership

Every object on the system has an owner and the owner has *ALL authority to the object by default. Group profiles or individual user profiles can own objects. When an object has no owner or when object ownership might pose a security risk, the system assigns ownership of the object to an IBM-supplied user profile called the Default Owner (QDFTOWN) user profile. When a user creates an object, the user is the owner of the object unless the user specifies that the group profile to which the user belongs should be the owner of the object. However, you can change or remove the owner's authority to the object. Proper assignment of object ownership helps you manage applications and delegate responsibility for the security of your information. For more information, see "Object ownership" in the iSeries Security Reference.

Primary group authority

You can specify a primary group for an object and the authority the primary group has to the object. The system stores the name of the primary group profile and the primary group's authority for the object with the object. The use of primary group authority may simplify your authority management and improve authority checking performance in comparison to the use of group profiles. Only a user profile with a group identification number (gid) may be the primary group for an object and the same profile cannot be the owner of the object and its primary group. For more information, see "Group ownership of objects" in the iSeries Security Reference.

Library authority

Many objects on the system reside in libraries. To access an object in a library, you need authority both to the object itself and to the library in which it resides. You can put files and programs that have similar protection requirements into a library and restrict access to that library. This is often simpler than restricting access to each individual object. However, library security may not be adequate for protecting data with high security requirements. To protect highly sensitive or critical objects, you may want to secure the individual object or use an authorization list rather than rely on library security alone. For more information, see "Library security" in the iSeries Security Reference.

Directory authority

When you access an object in a directory, have authority to all the directories in the path that contains the object. You must also have the necessary authority to the object to perform the operation that you requested. You can use directory authority in the same way that you use library authority. You can group objects in a directory and secure the directory rather than the individual objects. For example, you might choose to limit access to directories and use public authority to the objects within the directory because limiting the number of specific authorities that you define for objects improves the performance of the authority checking process.

Object authority

If the access to a library or directory is not specific enough or when specific objects within a library or directory have different access requirements than the general library or directory, you can restrict authority on individual objects, such as files. Authority to an object falls into one of three categories:

Object Authority defines what operations a user or program can perform on the object as a whole.
Data authority defines what operations a user or program can perform on the contents of the object.
Field authority defines what operations a user or program can perform on data fields.

For more information on object authority types, see "Defining how information can be accessed" in the iSeries Security Reference.

Public authority

The public consists of anyone who has authorization to sign on to the system and public authority defines what kind of access is available for users who do not have any other authority to the object. You can define public authority for every object on the system, although the public authority you define for an object may be *EXCLUDE. The system uses public authority for an object when it cannot find any other more specific authority for the object. The use of public authority is an effective means of securing objects that are not confidential and provides good system performance.

Adopted authority

Adopted authority adds the authority of a program owner to the authority of the user who runs the program. Adopted authority is a useful tool when a user needs different authority for an object in different situations. Sometimes a user needs different authorities to an object or application based on different situations in which the user works with the object or application. For example, a user might be allowed to change the information in a customer file when the user runs application programs that provide that function. However, the same user is allowed only to view, not change, customer information when the user runs a decision support tool, such as SQL. You can resolve this type of situation by giving the user *USE authority to customer information to allow file queries and use adopted authority in the customer maintenance programs to allow the user to change the files when the user runs customer maintenance programs. Objects of type *PGM, *SRVPGM, *SQLPKG, and Java™ programs can adopt authority. For more information, see "Objects that adopt the owner's authority" in the iSeries Security Reference.

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. The primary use of authority holders is for System/36™ environment applications, which often delete program-described files and create them again. An authority holder stores the authority information for program-described database files that an application deletes and creates during processing. When a person or program deletes an object, they also delete the authority information for that object. The use of an authority holder ensures that the authority information is retained when a program deletes an object. When you delete an object, you also delete the authority information for that object. You most commonly use authority holders when you convert from the System/36 because System/36 applications often delete files and create them again. For more information, see "Authority holders" in the iSeries Security Reference.

Field authority

You can give field authority of Reference or Update to individual fields in a database file. The use of field authority allows you to protect the database file while allowing appropriate use of specific fields in that file. You manage field authority only through the SQL statements GRANT and REVOKE. For more information, see "Field authority" in the iSeries Security Reference.

Parent topic:

Concepts