133 lines
9.3 KiB
HTML
133 lines
9.3 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="rbal1secure.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="rbal1elements.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="rbal1elementsusetcp.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="../rzahj/rzahjovr.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="rbal1ddmcnv.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="../rzahg/rzahgicsecurity.htm" />
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
|
|
<meta name="DC.Format" content="XHTML" />
|
|
<meta name="DC.Identifier" content="rbal1secdb" />
|
|
<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="rbal1secdb"><a name="rbal1secdb"><!-- --></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 the <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 statement
|
|
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="rbal1elements.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="rbal1elementsusetcp.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="rbal1secure.htm" title="The iSeries server has security elements built into the operating system to limit access to the data resources of an application server. Security options range from simple physical security to full password security coupled with authorization to commands and data objects.">Security</a></div>
|
|
</div>
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
|
<div><a href="../rzahg/rzahgicsecurity.htm">Security</a></div>
|
|
</div>
|
|
<div class="relref"><strong>Related reference</strong><br />
|
|
<div><a href="../rzahj/rzahjovr.htm">APPC, APPN, and HPR</a></div>
|
|
<div><a href="rbal1ddmcnv.htm" title="The term connection in this topic collection refers to the concept of an SQL connection. An SQL connection lasts from the time an explicit or implicit SQL CONNECT is done until the logical SQL connection is terminated by such means as an SQL DISCONNECT, or a RELEASE followed by a COMMIT.">Control DDM conversations</a></div>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html> |