207 lines
14 KiB
HTML
207 lines
14 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="Resource security" />
|
||
|
|
<meta name="abstract" content="You can use resource security on the system to control the actions of authorized users after successful authentication." />
|
||
|
|
<meta name="description" content="You can use resource security on the system to control the actions of authorized users after successful authentication." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzamvconcepts.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzamvplanrscsec.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzamvsetrscsec.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="resourcesec" />
|
||
|
|
<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>Resource security</title>
|
||
|
|
</head>
|
||
|
|
<body id="resourcesec"><a name="resourcesec"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Resource security</h1>
|
||
|
|
<div><p>You can use resource security on the system to control the actions
|
||
|
|
of authorized users after successful authentication.</p>
|
||
|
|
<div class="p">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:<ul><li>Confidentiality of information.</li>
|
||
|
|
<li>Accuracy of information to prevent unauthorized changes.</li>
|
||
|
|
<li>Availability of information to prevent accidental or deliberate damage.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>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.</p>
|
||
|
|
<p>The system provides several tools to assist you in designing a straightforward
|
||
|
|
resource security scheme:</p>
|
||
|
|
<div class="p"><dl><dt class="dlterm">Group profiles</dt>
|
||
|
|
<dd>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.</dd>
|
||
|
|
<dt class="dlterm">Authorization lists</dt>
|
||
|
|
<dd>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. <span>For
|
||
|
|
more information, see <span class="q">"Authorization list security"</span> in the <cite>iSeries™ Security
|
||
|
|
Reference</cite>.</span></dd>
|
||
|
|
<dt class="dlterm">Validation lists</dt>
|
||
|
|
<dd>Validation list objects provide a method for applications to securely
|
||
|
|
store user authentication information.</dd>
|
||
|
|
<dt class="dlterm">User authority</dt>
|
||
|
|
<dd>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.</dd>
|
||
|
|
<dt class="dlterm">Object ownership</dt>
|
||
|
|
<dd>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. <span>For more
|
||
|
|
information, see <span class="q">"Object ownership"</span> in the <cite>iSeries Security Reference</cite>.</span></dd>
|
||
|
|
<dt class="dlterm">Primary group authority</dt>
|
||
|
|
<dd>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 (<var class="varname">gid</var>)
|
||
|
|
may be the primary group for an object and the same profile cannot be the
|
||
|
|
owner of the object and its primary group. <span>For more information,
|
||
|
|
see <span class="q">"Group ownership of objects"</span> in the <cite>iSeries Security Reference</cite>.</span></dd>
|
||
|
|
<dt class="dlterm">Library authority</dt>
|
||
|
|
<dd>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. <span>For more information, see <span class="q">"Library security"</span> in
|
||
|
|
the <cite>iSeries Security
|
||
|
|
Reference</cite>.</span></dd>
|
||
|
|
<dt class="dlterm">Directory authority</dt>
|
||
|
|
<dd>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.</dd>
|
||
|
|
<dt class="dlterm">Object authority</dt>
|
||
|
|
<dd>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: <ol><li>Object Authority defines what operations a user or program can perform
|
||
|
|
on the object as a whole.</li>
|
||
|
|
<li>Data authority defines what operations a user or program can perform on
|
||
|
|
the contents of the object.</li>
|
||
|
|
<li>Field authority defines what operations a user or program can perform
|
||
|
|
on data fields.</li>
|
||
|
|
</ol>
|
||
|
|
<span>For more information on object authority types, see <span class="q">"Defining
|
||
|
|
how information can be accessed"</span> in the <cite>iSeries Security Reference</cite>.</span></dd>
|
||
|
|
<dt class="dlterm">Public authority</dt>
|
||
|
|
<dd>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.</dd>
|
||
|
|
<dt class="dlterm">Adopted authority</dt>
|
||
|
|
<dd>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. <span>For more information, see <span class="q">"Objects that
|
||
|
|
adopt the owner's authority"</span> in the <cite>iSeries Security Reference</cite>.</span></dd>
|
||
|
|
<dt class="dlterm">Authority holders</dt>
|
||
|
|
<dd>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. <span>For more information,
|
||
|
|
see <span class="q">"Authority holders"</span> in the <cite>iSeries Security Reference</cite>.</span> </dd>
|
||
|
|
<dt class="dlterm">Field authority</dt>
|
||
|
|
<dd>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. <span>For
|
||
|
|
more information, see <span class="q">"Field authority"</span> in the <cite>iSeries Security
|
||
|
|
Reference</cite>.</span></dd>
|
||
|
|
</dl>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzamvconcepts.htm" title="To effectively create a security policy and plan security measures for your system, you need to understand the following security concepts, some of which are general concepts and some of which are specific to the hardware type.">Concepts</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><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><a href="rzamvsetrscsec.htm" title="This information helps you establish resource security for workstations and printers by setting ownership and public authority to objects, as well as specific authority to applications.">Implement resource security</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|