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, you must 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.