336 lines
22 KiB
HTML
336 lines
22 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE html
|
|||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|||
|
|
<html lang="en-us" xml:lang="en-us">
|
|||
|
|
<head>
|
|||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|||
|
|
<meta name="security" content="public" />
|
|||
|
|
<meta name="Robots" content="index,follow" />
|
|||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
|||
|
|
<meta name="DC.Type" content="concept" />
|
|||
|
|
<meta name="DC.Title" content="Plan library security" />
|
|||
|
|
<meta name="abstract" content="This topic describes how to plan security for the libraries on your system." />
|
|||
|
|
<meta name="description" content="This topic describes how to plan security for the libraries on your system." />
|
|||
|
|
<meta name="DC.Relation" scheme="URI" content="rzamvplanrscsec.htm" />
|
|||
|
|
<meta name="DC.Relation" scheme="URI" content="rzamvdeterminelibowner.htm" />
|
|||
|
|
<meta name="DC.Relation" scheme="URI" content="rzamvlibdescworksheet.htm" />
|
|||
|
|
<meta name="DC.Relation" scheme="URI" content="rzamvnamingworksheet.htm" />
|
|||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2006" />
|
|||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2006" />
|
|||
|
|
<meta name="DC.Format" content="XHTML" />
|
|||
|
|
<meta name="DC.Identifier" content="planlibsec" />
|
|||
|
|
<meta name="DC.Language" content="en-us" />
|
|||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
|||
|
|
<!-- US Government Users Restricted Rights -->
|
|||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
|||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
|||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
|||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
|||
|
|
<title>Plan library security</title>
|
|||
|
|
</head>
|
|||
|
|
<body id="planlibsec"><a name="planlibsec"><!-- --></a>
|
|||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|||
|
|
<h1 class="topictitle1">Plan library security</h1>
|
|||
|
|
<div><p>This topic describes how to plan security for the libraries on
|
|||
|
|
your system.</p>
|
|||
|
|
<p>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. </p>
|
|||
|
|
<p><span class="uicontrol">Planning Libraries</span></p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<div class="p">Library security is effective only if these rules are followed:<ul><li>Libraries contain objects with similar security requirements.</li>
|
|||
|
|
<li>Users are not allowed to add new objects to restricted libraries. 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.</li>
|
|||
|
|
<li>Library lists are controlled.</li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
<p><span class="uicontrol">Describing Library Security</span></p>
|
|||
|
|
<div class="p">As an application designer, you need to provide information about a library
|
|||
|
|
for the security administrator. The security administrator uses this information
|
|||
|
|
to decide how to secure the library and its objects. Typical information needed
|
|||
|
|
is:<ul><li>Any application functions which add objects to the library.</li>
|
|||
|
|
<li>Whether any objects in the library are deleted during application processing. </li>
|
|||
|
|
<li>What profile owns the library and its objects.</li>
|
|||
|
|
<li>Whether the library should be included on library lists.</li>
|
|||
|
|
</ul>
|
|||
|
|
See the following sample format for providing this information:<p><kbd class="userinput">Library name: ITEMLIB<br />
|
|||
|
|
<br />
|
|||
|
|
Public authority to the library: *EXCLUDE <br />
|
|||
|
|
<br />
|
|||
|
|
Public authority to objects in the library: *CHANGE <br />
|
|||
|
|
<br />
|
|||
|
|
Public authority for new objects (CRTAUT): *CHANGE <br />
|
|||
|
|
<br />
|
|||
|
|
Library owner: OWNIC Include on library lists? No. Library is added to library list by <br />
|
|||
|
|
initial application program or initial query program. <br />
|
|||
|
|
<br />
|
|||
|
|
List any functions that require *ADD authority to the library: No objects are added to <br />
|
|||
|
|
the library during normal application processing. <br />
|
|||
|
|
<br />
|
|||
|
|
List any objects requiring *OBJMGT or *OBJEXIST authority and what functions need that <br />
|
|||
|
|
authority: All work files, whose names begin with the characters ICWRK, are cleared at <br />
|
|||
|
|
month-end. This requires *OBJMGT authority.</kbd></p>
|
|||
|
|
</div>
|
|||
|
|
<p><span class="uicontrol">Use library security to complement menu security</span></p>
|
|||
|
|
<p>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. </p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<p><span class="uicontrol">Planning security for application libraries:</span> 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.</p>
|
|||
|
|
<div class="p">Review the information that you gathered about your the applications and
|
|||
|
|
libraries:<ul><li>Application Description form</li>
|
|||
|
|
<li>Library Description form</li>
|
|||
|
|
<li>User Group Description form for any groups that need the library</li>
|
|||
|
|
<li>Your diagram of applications, libraries, and user groups</li>
|
|||
|
|
</ul>
|
|||
|
|
Think about which groups need the information in a library, why they
|
|||
|
|
need it, and what they need to do with it. Determine the contents of the application
|
|||
|
|
libraries, as they contain the important application files. They may also
|
|||
|
|
contain other objects, most of which are programming tools to make the application
|
|||
|
|
work properly, such as:<ul><li>Work files</li>
|
|||
|
|
<li>Data areas and messages queues</li>
|
|||
|
|
<li>Programs</li>
|
|||
|
|
<li>Message files</li>
|
|||
|
|
<li>Commands</li>
|
|||
|
|
<li>Output queues</li>
|
|||
|
|
</ul>
|
|||
|
|
Most of the objects, other than files and output queues, do not represent
|
|||
|
|
a security exposure. They usually contain small amounts of application data,
|
|||
|
|
often in a format that is not easily intelligible outside the programs. You
|
|||
|
|
can list names and descriptions of all the objects in a library by using the <span class="cmdname">Display
|
|||
|
|
Library</span> command. For example, to list contents of the CONTRACTS
|
|||
|
|
library: <samp class="codeph">DSPLIB LIB(CONTRACTS) OUTPUT(*PRINT)</samp> Next you need
|
|||
|
|
to decide what public authority you want to have for application libraries
|
|||
|
|
and program libraries.</div>
|
|||
|
|
<p><span class="uicontrol">Deciding public authority to application libraries</span>:
|
|||
|
|
For purposes of resource security, the public means anyone you authorize to
|
|||
|
|
sign on to your system. Public authority allows a user access to an object
|
|||
|
|
if you have not any other more specific access. 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. Usually, public authority to library objects
|
|||
|
|
and library create authority for new objects should be the same.</p>
|
|||
|
|
<p>The Create Authority (QCRTAUT) system value determines the system-wide
|
|||
|
|
public authority for new objects. IBM<sup>®</sup> 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).</p>
|
|||
|
|
<div class="p">Use public authority as much as possible, for both simplicity and good
|
|||
|
|
performance. To determine what public authority to a library should be, ask
|
|||
|
|
these questions:<ul><li>Should everyone in the company have access to most of the information
|
|||
|
|
in this library?</li>
|
|||
|
|
<li>What kind of access should people have to the majority of the information
|
|||
|
|
in this library?</li>
|
|||
|
|
</ul>
|
|||
|
|
Concentrate on decisions for the majority of the people and the majority
|
|||
|
|
of the information. Later, you will learn how to deal with the exceptions.
|
|||
|
|
Planning resource security is often a circular process. You may discover that
|
|||
|
|
you need to make changes to public authority after considering the requirements
|
|||
|
|
for specific objects. Try several combinations of public and private authority
|
|||
|
|
to both objects and libraries before you choose one that meets your security
|
|||
|
|
and performance needs.</div>
|
|||
|
|
<div class="p">Ensuring adequate authority: *CHANGE authority to objects and *USE authority
|
|||
|
|
to a library are adequate for most application functions. However, you need
|
|||
|
|
to ask your programmer or application provider some questions to determine
|
|||
|
|
if certain application functions require more authority:<ul><li>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.</li>
|
|||
|
|
<li>Are any files or other objects in the library created during processing?
|
|||
|
|
Creating an object requires *CHANGE authority to the library.</li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<div class="p">You can use *USE authority to both the library and the programs in the
|
|||
|
|
library to run programs sufficiently, but program libraries may have other
|
|||
|
|
objects that require additional authority. Ask your programmer a few questions:<ul><li>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.</li>
|
|||
|
|
<li>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.</li>
|
|||
|
|
<li>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.</li>
|
|||
|
|
</ul>
|
|||
|
|
Fill in all of the resource security information on both parts of the
|
|||
|
|
Library Description form except the library owner and the authorization list
|
|||
|
|
column. You then can determine ownership of libraries and objects.<div class="note"><span class="notetitle">Note:</span> A
|
|||
|
|
knowledgeable programmer who has access to a library may be able to retain
|
|||
|
|
access to objects in the library even after you have revoked authority to
|
|||
|
|
the library. If a library contains objects with high security requirements,
|
|||
|
|
restrict the objects and the library for complete protection.</div>
|
|||
|
|
</div>
|
|||
|
|
<p><span class="uicontrol">Determining ownership of libraries and objects:</span> 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.</p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<div class="p"><span class="uicontrol">Recommendations:</span> The recommendations below apply
|
|||
|
|
in many, but not all, situations. After reviewing the recommendations, discuss
|
|||
|
|
your ideas for object ownership with your programmer or application provider.
|
|||
|
|
If you purchase applications, you may not be able to control what profile
|
|||
|
|
owns libraries and objects. The application may be designed to prevent changes
|
|||
|
|
of ownership.<ul><li>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.</li>
|
|||
|
|
<li>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.</li>
|
|||
|
|
<li>If you plan to delegate responsibility for control of applications to
|
|||
|
|
managers in various departments, those managers could be the owners of all
|
|||
|
|
the application objects. However, the manager of an application might change
|
|||
|
|
responsibilities. If that is the case, then you would transfer ownership of
|
|||
|
|
all the application objects to a new manager.</li>
|
|||
|
|
<li>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.</li>
|
|||
|
|
</ul>
|
|||
|
|
Decide what profiles should own your applications. Enter the owner profile
|
|||
|
|
information on each Library Description form. You can now decide ownership
|
|||
|
|
and access for your user libraries.</div>
|
|||
|
|
<p><span class="uicontrol">Deciding ownership and access for user libraries:</span> If
|
|||
|
|
your system has the IBM Query for iSeries™ 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. </p>
|
|||
|
|
<p>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. </p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<p><span class="uicontrol">Grouping objects</span></p>
|
|||
|
|
<p> 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.</p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<div class="p">Recommendations:<ul><li>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.</li>
|
|||
|
|
<li>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.</li>
|
|||
|
|
</ul>
|
|||
|
|
You will also need to add the naming convention for authorization lists
|
|||
|
|
to your Naming conventions form. Once you have prepared an AuthorizationlList
|
|||
|
|
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.</div>
|
|||
|
|
<p><span class="uicontrol">Library Security</span></p>
|
|||
|
|
<p>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.</p>
|
|||
|
|
<div class="p">Using library security is one technique for protecting information while
|
|||
|
|
maintaining a simple security scheme. For example, to secure confidential
|
|||
|
|
information for a set of applications, you could do the following:<ul><li>Use a library to store all confidential files for a particular group of
|
|||
|
|
applications.</li>
|
|||
|
|
<li>Ensure that public authority is sufficient for all objects (in the library)
|
|||
|
|
that are used by applications (*USE or *CHANGE).</li>
|
|||
|
|
<li>Restrict public authority to the library itself (*EXCLUDE).</li>
|
|||
|
|
<li>Give selected groups or individuals authority to the library, using *USE
|
|||
|
|
or *ADD if the applications require it.</li>
|
|||
|
|
</ul>
|
|||
|
|
Although library security is a simple, effective method for protecting
|
|||
|
|
information, it may not be adequate for data with high security requirements.
|
|||
|
|
Highly sensitive objects should be secured individually or with an authorization
|
|||
|
|
list, rather than relying on library security.</div>
|
|||
|
|
<p><span class="uicontrol">Library Security and Library Lists</span></p>
|
|||
|
|
<div class="p">When a library is added to a user’s library list, the authority the user
|
|||
|
|
has to the library is stored with the library list information. The user’s
|
|||
|
|
authority to the library remains for the entire job, even if the user’s authority
|
|||
|
|
to the library is revoked while the job is active. When access is requested
|
|||
|
|
to an object and *LIBL is specified for the object, the library list information
|
|||
|
|
is used to check authority for the library. If a qualified name is specified,
|
|||
|
|
the authority for the library is specifically checked, even if the library
|
|||
|
|
is included in the user’s library list. <div class="note"><span class="notetitle">Note:</span> If a user is running under adopted
|
|||
|
|
authority when a library is added to the library list, the user remains authorized
|
|||
|
|
to the library even when the user is no longer running under adopted authority.
|
|||
|
|
This represents a potential security exposure. Any entries added to a user’s
|
|||
|
|
library list by a program running under adopted authority should be removed
|
|||
|
|
before the adopted authority program ends.</div>
|
|||
|
|
In addition, applications
|
|||
|
|
that use library lists rather than qualified library names have a potential
|
|||
|
|
security exposure. A user who is authorized to the commands to work with library
|
|||
|
|
lists could potentially run a different version of a program.</div>
|
|||
|
|
</div>
|
|||
|
|
<div>
|
|||
|
|
<ul class="ullinks">
|
|||
|
|
<li class="ulchildlink"><strong><a href="rzamvdeterminelibowner.htm">Determine library owner</a></strong><br />
|
|||
|
|
When you plan your application installation, you must first decide the user profiles and installation values for each application.</li>
|
|||
|
|
<li class="ulchildlink"><strong><a href="rzamvlibdescworksheet.htm">Library description worksheet</a></strong><br />
|
|||
|
|
After you have described your naming conventions, you should describe the libraries on your system. Libraries identify and organize objects on your system.</li>
|
|||
|
|
<li class="ulchildlink"><strong><a href="rzamvnamingworksheet.htm">Naming conventions worksheet</a></strong><br />
|
|||
|
|
When you know how the system names objects, you can plan and monitor security, solve problems, and plan backup and recovery.</li>
|
|||
|
|
</ul>
|
|||
|
|
|
|||
|
|
<div class="familylinks">
|
|||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzamvplanrscsec.htm" title="This topic describes each of the components of resource security and how they all work together to protect information on your system. It also explains how to use CL commands and displays to set up resource security on your system.">Plan resource security</a></div>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
</body>
|
|||
|
|
</html>
|