ibm-information-center/dist/eclipse/plugins/i5OS.ic.ddm_5.4.0.1/rbae5elementappc.htm

132 lines
9.2 KiB
HTML
Raw Permalink Normal View History

2024-04-02 14:02:31 +00:00
<?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="Elements of security in an APPC network" />
<meta name="abstract" content="When Distributed Relational Database Architecture (DRDA) is used, the data resources of each server in the DRDA environment should be protected." />
<meta name="description" content="When Distributed Relational Database Architecture (DRDA) is used, the data resources of each server in the DRDA environment should be protected." />
<meta name="DC.subject" content="password, encrypted" />
<meta name="keywords" content="password, encrypted" />
<meta name="DC.Relation" scheme="URI" content="rbae5secdb.htm" />
<meta name="DC.Relation" scheme="URI" content="rbae5configlist.htm" />
<meta name="DC.Relation" scheme="URI" content="rbae5conversationlevel.htm" />
<meta name="DC.Relation" scheme="URI" content="rbae5tssec.htm" />
<meta name="DC.Relation" scheme="URI" content="rbae5tssec.htm" />
<meta name="DC.Relation" scheme="URI" content="rbae5exitpgm.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 1999, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1999, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="rbae5elements" />
<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>Elements of security in an APPC network</title>
</head>
<body id="rbae5elements"><a name="rbae5elements"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Elements of security in an APPC network</h1>
<div><p>When Distributed
Relational Database Architecture™ (DRDA<sup>®</sup>) is used, the data resources of each
server in the DRDA environment
should be protected.</p>
<p>To protect data resources of each server in the DRDA environment, you can use three groups
of security elements that are controlled by the following parameters: </p>
<ul><li>For system-related security or session, the <em>LOCPWD parameter</em> is
used on each <span class="keyword">iSeries™</span> server
to indicate the system validation password to be exchanged between the source
and target systems when an Advanced Program-to-Program Communication (APPC)
session is first established between them. Both systems must exchange the
same password before the session is started. (On <span class="keyword">System/36™</span>,
this password is called the location password.) In an APPC network, the LOCPWD
parameter on the <span class="cmdname">Create Device Description (APPC) (CRTDEVAPPC)</span> command
specifies this password. Devices are created automatically using APPN, and
the location password on the remote location list specifies a password that
is used by the two locations to verify identities. Use the <span class="cmdname">Create
Configuration List (CRTCFGL)</span> command to create a remote location
list of type (*APPNRMT).</li>
<li>For user-related or location security, the <em>SECURELOC parameter</em> is
used on each <span class="keyword">iSeries</span> server
to indicate whether it (as a target server) accepts incoming access requests
that have their security already verified by the source server or whether
it requires a user ID and encrypted password. In an APPC network, the SECURELOC
parameter on the <span class="cmdname">Create Device Description (APPC) (CRTDEVAPPC)</span> command
specifies whether the local server allows the remote server to verify security.
Devices are created automatically using APPN, and the secure-location on an
APPN remote Configuration List is used to determine if the local server allows
the remote server to verify user security information. The SECURELOC value
can be specified differently for each remote location. <p>The SECURELOC parameter
is used with the following security elements: </p>
<ul><li>The user ID sent by the source server, if allowed by this parameter</li>
<li>The user ID and encrypted password, if allowed by this parameter</li>
<li>The target server user profiles, including default user profiles</li>
</ul>
<p>For more information, see the DDM source system security in an APPC
network topic.</p>
</li>
<li>For object-related security, the <em>DDMACC parameter</em> is used on the <span class="cmdname">Change
Network Attributes (CHGNETA)</span> command to indicate whether the files
on the <span class="keyword">iSeries</span> server can be
accessed at all by another server and, if so, at which level of security the
incoming requests are to be checked. More information about this object-related
parameter is provided in the topic DDM Network Attribute (DDMACC Parameter).
<p> </p>
<ul><li>If *REJECT is specified on the DDMACC parameter, all DRDA requests
received by the target <span class="keyword">iSeries</span> server
are rejected.</li>
<li>If *OBJAUT is specified on the DDMACC parameter, normal object-level security
is used on the target server.</li>
<li>If the name of an optional, user-supplied user exit program (or access
control program) is specified on the DDMACC parameter, an additional level
of security is used. The user exit program can be used to control whether
a given user of a specific source server can use a specific command to access
(in some manner) a specific file on the target server. (See the topic DDM
server access control exit program for additional security for details.)</li>
<li>When a file is created on the target server using DRDA, the library name specified contains
the file. If no library name is specified on the DRDA request, the current library (*CURLIB)
is used. The file authority defaults to allow only the user who created the
file or the target server's security officer to access the file.</li>
</ul>
</li>
</ul>
<p>Most of the security controls for limiting remote file access are handled
by the target server. Except for the user ID provided by the source server,
all of these elements are specified and used on the target server. The source
server, however, also limits access to target server files by controlling
access to the DRDA file
on the source server and by sending the user ID, when needed, to the target
server.</p>
</div>
<div>
<ul class="ullinks">
<li class="ulchildlink"><strong><a href="rbae5configlist.htm">APPN configuration lists</a></strong><br />
In an APPC network, location passwords are specified for those pairs of locations that are going to have end-to-end sessions between them.</li>
<li class="ulchildlink"><strong><a href="rbae5conversationlevel.htm">Conversation level security</a></strong><br />
Systems Network Architecture (SNA) logical unit (LU) 6.2 architecture identifies three conversation security designations that various types of systems in an SNA network can use to provide consistent conversation security across a network of unlike systems.</li>
<li class="ulchildlink"><strong><a href="rbae5tssec.htm">DRDA application server security in an APPC network</a></strong><br />
When the target server is an <span class="keyword">iSeries</span> server,
several elements are used together to determine whether a request to access
a remote file is allowed or not.</li>
</ul>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rbae5secdb.htm" title="A distributed relational database administrator needs to protect the resources of the application servers in the network without unnecessarily restricting access to data by application requesters (ARs) in the network.">Elements of distributed relational database security</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="rbae5tssec.htm" title="When the target server is an iSeries server, several elements are used together to determine whether a request to access a remote file is allowed or not.">DRDA application server security in an APPC network</a></div>
</div>
<div class="relref"><strong>Related reference</strong><br />
<div><a href="rbae5exitpgm.htm" title="Customers who use menu-level security, which is accomplished by restricting the user's access to functions on the server, are likely to have a large number of public files. Public files are those files to which the public has some or all authority. A user exit program allows you to restrict each DDM user's access to public files and to private files.">DDM server access control exit program for additional security</a></div>
</div>
</div>
</body>
</html>