123 lines
8.4 KiB
HTML
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>
|