Planning library security
Many factors affect how you choose to group your application information into libraries and manage libraries. This topic addresses some of the security issues associated with library design.
To access an object, you need authority to the object itself and to the library containing the object. You can restrict access to an object by restricting the object itself, the library containing the object, or both.
Planning libraries
A library is like a directory used to locate the objects in the library. *USE authority to a library allows you to use the directory to find objects in the library. The authority for the object itself determines how you can use the object. *USE authority to a library is sufficient to perform most operations on the objects in the library.
Using public authority for objects and restricting access to libraries can be a simple, effective security technique. Putting programs in a separate library from other application objects can also simplify security planning. This is particularly true if files are shared by more than one application. You can use authority to the libraries containing application programs to control who can perform application functions.
- Libraries contain objects with similar security requirements.
- Users are not allowed to add new objects to restricted libraries and changes to programs in the libraries are controlled. That is, application libraries should have public authority of *USE or *EXCLUDE unless users need to create objects directly into the library.
- Library lists are controlled.
Describing library security
- Any application functions which add objects to the library.
- Whether any objects in the library are deleted during application processing.
- What profile owns the library and its objects.
- Whether the library should be included on library lists.
Public authority to the library: *EXCLUDE
Public authority to objects in the library: *CHANGE
Public authority for new objects (CRTAUT): *CHANGE
Library owner: OWNIC Include on library lists? No. Library is added to library list by
initial application program or initial query program.
List any functions that require *ADD authority to the library: No objects are added to
the library during normal application processing.
List any objects requiring *OBJMGT or *OBJEXIST authority and what functions need that
authority: All work files whose names begin with the characters ICWRK are cleared at
month-end. This requires *OBJMGT authority.
Use library security to complement menu security
To access an object in a library, you must have authority both to the object and to the library. Most operations require either *EXECUTE authority or *USE authority to the library. Depending on your situation, you may be able to use library authority as a simple means for securing objects. For example, assume that for the Order-Entry menu example, everyone who has authority to the Order Entry menu can use all of the programs in the ORDERPGM library.
Rather than securing individual programs, you can set the public authority to the ORDERPGM library to *EXCLUDE. You can then grant *USE authority to the library to specific user profiles, which will allow them to use the programs in the library. This assumes that public authority to the programs is *USE or greater. Library authority can be a simple, efficient method for administering object authority. However, you must ensure that you are familiar with the contents of the libraries that you are securing so that you do not provide unintended access to objects.
Planning security for application libraries: After you have determined your objectives for your resource security, you can begin planning security for application libraries. Choose one of your application libraries to work with as you follow the process described here. If your system stores files and programs in separate libraries, choose a library that contains files. When you finish the topic, repeat these steps for your remaining application libraries.
- Application Description form
- Library Description form
- User Group Description form for any groups that need the library
- Your diagram of applications, libraries, and user groups
- Work files
- Data areas and messages queues
- Programs
- Message files
- Commands
- Output queues
DSPLIB LIB(CONTRACTS) OUTPUT(*PRINT)
Next you need
to decide what public authority you want to have for application libraries
and program libraries.Deciding public authority to application libraries: For purposes of resource security, the public means anyone you authorize to sign on to your system. Public authority allows a user with no other authority, access to an object. In addition to deciding public authority for objects already in the library, you can specify the public authority for any new objects added to the library later. To do this, you use the Create Authority (CRTAUT) parameter. Typically, public authority to library objects and library create authority for new objects should be the same.
The Create Authority (QCRTAUT) system value determines the system-wide public authority for new objects. IBM ships the QCRTAUT system value with *CHANGE. Avoid changing QCRTAUT, because many system functions use it. If you specify *SYSVAL for the CRTAUT of an application library, it uses the QCRTAUT system value (*CHANGE).
- Should everyone in the company have access to most of the information in this library?
- What kind of access should people have to the majority of the information in this library?
- Are any files or other objects in the library deleted during processing? Are any files cleared? Are members added to any files? Deleting an object, clearing a file, or adding a file member requires *ALL authority to the object.
- Are any files or other objects in the library created during processing? Creating an object requires *CHANGE authority to the library.
Deciding public authority to program libraries: Often, application programs are kept in a separate library from files and other objects. You are not required to use separate libraries for applications, but many programmers use this technique when they design applications. If your application has separate program libraries, you need to decide the public authority to those libraries.
- Does the application use data areas or message queues to communicate between programs? Are they in the program library? *CHANGE authority to the object is required for handling data areas and message queues.
- Are any objects in the program library, such as data areas, deleted during processing? *ALL authority to an object is required to delete the object.
- Are any objects in the program library, such as data areas, created during processing? *CHANGE authority to the library is required to create any new objects in the library.
Determining ownership of libraries and objects: After you plan security for application libraries, you can decide ownership of libraries and objects. Each object is assigned an owner when it is created. The owner of the object automatically has all authority to the object, which includes authorizing others to use the object, changing the object, and deleting it. The security officer can perform these functions for any object on the system.
The system uses the profile of the object owner to track who has authority to the object. The system completes this function internally. This may not affect the user profile directly. However, if you do not plan object ownership properly, some user profiles can become very large.
When the system saves an object, the system also saves the name of the owning profile with it. The system uses this information if it restores the object. If the owning profile for a restored object is not on the system, the system transfers ownership to an IBM-supplied profile called QDFTOWN.
- Avoid using an IBM-supplied profile, such as QSECOFR or QPGMR, as an application owner. These profiles own many objects in IBM-supplied libraries and are already very large.
- Normally, a group profile should not own an application. Every member in the group has the same authority as the group profile, unless you specifically assign lower authority. In effect, you would be giving every member of the group complete authority to the application.
- If you plan to delegate responsibility for control of applications to managers in various departments, those managers can be the owners of all the application objects. However, the manager of an application might change responsibilities, and you would then transfer ownership of all the application objects to a new manager.
- Many people use the technique of creating a special owner profile for each application with the password set to *NONE. The owning profile is used by the system to manage authorities for the application. The security officer, or someone with that authority performs the actual management of the application or it is delegated to managers with *ALL authority to particular applications.
Deciding ownership and access for user libraries: If your system has the IBM Query for i licensed program or another decision support program, your users need a library for storing the query programs they create. Normally, this library is the current library in the user profile. If a user belongs to a group, you use a field in the user profile to specify whether the user or the group owns any objects created by the user.
If the user owns the objects, you can specify what authority the group members have to use the objects. You can also specify whether the group’s authority is primary group authority or private authority. Primary group authority may provide better system performance. The Group authority to objects created field is not used if the owner of objects created is the group. Group members automatically have *ALL authority to any objects created.
Decide who should own and have access to user libraries. Enter your choices in the Owner of objects created and Group authority over objects fields on the Individual User Profile form. Now you are ready to begin grouping objects.
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.
- Use authorization lists for objects that require security protection and 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.
Library security
Most objects on the system reside in libraries. To access an object, you need authority both to the object itself and the library in which the object resides. For most operations, including deleting an object, *USE authority to the object library is sufficient, in addition to the authority required for the object. Creating a new object requires *ADD authority to the object library. Appendix D shows what authority is required by CL commands for objects and the object libraries.
- Use a library to store all confidential files for a particular group of applications.
- Ensure that public authority is sufficient for all objects in the library that are used by applications (*USE or *CHANGE).
- Restrict public authority to the library itself (*EXCLUDE).
- Give selected groups or individuals authority to the library, using *USE or *ADD if the applications require it.
Library security and library lists