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

123 lines
8.4 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="Elements of distributed relational database security" />
<meta name="abstract" content="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." />
<meta name="description" content="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." />
<meta name="DC.subject" content="security, distributed database overview, application, requester, server, consistent system levels across network" />
<meta name="keywords" content="security, distributed database overview, application, requester, server, consistent system levels across network" />
<meta name="DC.Relation" scheme="URI" content="rbae5ddm1.htm" />
<meta name="DC.Relation" scheme="URI" content="rbae5elementappc.htm" />
<meta name="DC.Relation" scheme="URI" content="rbae5elementtcpip.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="rbae5secdb" />
<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 distributed relational database security</title>
</head>
<body id="rbae5secdb"><a name="rbae5secdb"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Elements of distributed relational database security</h1>
<div><p>A distributed relational database administrator needs to protect
the resources of the application servers in the network without unnecessarily
restricting access to data by <dfn class="term">application requesters (ARs)</dfn> in
the network.</p>
<p>An AR secures its objects and relational database to ensure only authorized
users have access to distributed relational database programs. This is done
using normal <span class="keyword">iSeries™ server</span> object
authorization to identify users and specify what each user (or group of users)
is allowed to do with an object. Alternatively, authority to tables, views,
and SQL packages can be granted or revoked using the SQL GRANT and REVOKE
statements. Providing levels of authority to SQL objects on the AR helps ensure
that only authorized users have access to an SQL application that accesses
data on another system.</p>
<p>The level of system security in effect on the <dfn class="term">application server
(AS)</dfn> determines whether a request from an AR is accepted and whether
the remote user is authorized to objects on the AS.</p>
<p>Some aspects of security planning for <span class="keyword">iSeries server</span> in
a distributed relational database network include: </p>
<ul><li>Object-related security to control user access to particular resources
such as confidential tables, programs, and packages</li>
<li>Location security that verifies the identity of other systems in the network</li>
<li>User-related security to verify the identity and rights of users on the
local system and remote systems</li>
<li>Physical security such as locked doors or secured buildings that surround
the systems, modems, communication lines and terminals that can be configured
in the line description and used in the route selection process</li>
</ul>
<p>Location, user-related, and object-related security are only possible if
the system security level is set at level 20 or above.</p>
<p>For Advanced Program-to-Program Communication (APPC) conversations, when
the system is using level 10 security, an <span class="keyword">iSeries server</span> connects
to the network as a nonsecure system. The server does not validate the identity
of a remote system during session establishment and does not require conversation
security on incoming program start requests. For level 10, security information
configured for the APPC remote location is ignored and is not used during
session or conversation establishment. If a user profile does not exist on
the server, one is created.</p>
<p>When the system is using security level 20 or above, an <span class="keyword">iSeries server</span> connects
to the network as a secure system. The iSeries system can then provide conversation-level
security functions and, in the case of APPC, session level security as well.</p>
<p>Having system security set at the same level across the systems in your
network makes the task of security administration easier. An AS controls whether
the session and conversation can be established by specifying what is expected
from the AR to establish a session. For example, if the security level on
the AR is set at 10 and the security level on the AS is above 10, the appropriate
information might not be sent and the session might not be established without
changing security elements on one of the systems.</p>
<div class="section"><h4 class="sectiontitle">Passwords for DRDA<sup>®</sup> access</h4><p>The most common method
of authorizing a remote user for database access is by flowing a user ID and
password at connection-time. One method an application programmer can use
to do this is to code the USER/USING clause on an embedded SQL CONNECT statement.
For example:</p>
<pre>EXEC SQL CONNECT TO :locn USER :userid USING :pw</pre>
<p>For Distributed
Relational Database Architecture™ (DRDA) access to remote relational databases,
once a conversation is established, you do not need to enter a password again.
If you end a connection with either a RELEASE, DISCONNECT, or CONNECT statements
when running with the remote unit of work (RUW) connection management method,
your conversation with the first application server (AS) might or might not
be dropped, depending on the kind of AS you are connected to and your application
requester (AR) job attributes (for the specific rules, see Control DDM conversations).
If the conversation to the first AS is not dropped, it remains unused while
you are connected to the second AS. If you connect again to the first AS and
the conversation is unused, the conversation becomes active again without
you needing to enter your user ID and password. On this second use of the
conversation, your password is also not validated again.</p>
</div>
</div>
<div>
<ul class="ullinks">
<li class="ulchildlink"><strong><a href="rbae5elementappc.htm">Elements of security in an APPC network</a></strong><br />
When Distributed
Relational Database Architecture (DRDA) is used, the data resources of each
server in the DRDA environment
should be protected.</li>
<li class="ulchildlink"><strong><a href="rbae5elementtcpip.htm">Elements of security in a TCP/IP network</a></strong><br />
DDM and DRDA over native TCP/IP does not use <span class="keyword">i5/OS™</span> communications
security services and concepts such as communications devices, modes, secure
location attributes, and conversation security levels which are associated
with Advanced Program-to-Program Communication (APPC). Therefore, security
setup for TCP/IP is quite different.</li>
</ul>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rbae5ddm1.htm" title="This topic describes how iSeries security relates to DDM, and how it can limit access to the data resources of a target server by source server programs and users.">Security</a></div>
</div>
</div>
</body>
</html>