ibm-information-center/dist/eclipse/plugins/i5OS.ic.ddp_5.4.0.1/rbal1rdbpro.htm

111 lines
7.6 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="Protection strategies in a distributed relational database" />
<meta name="abstract" content="Network security in an iSeries distributed relational database must be planned to protect critical data on any application server (AS) from unauthorized access. But because of the distributed nature of the relational database, security planning must ensure that availability of data in the network is not unnecessarily restricted." />
<meta name="description" content="Network security in an iSeries distributed relational database must be planned to protect critical data on any application server (AS) from unauthorized access. But because of the distributed nature of the relational database, security planning must ensure that availability of data in the network is not unnecessarily restricted." />
<meta name="DC.subject" content="subsystem, communications" />
<meta name="keywords" content="subsystem, communications" />
<meta name="DC.Relation" scheme="URI" content="rbal1secure.htm" />
<meta name="DC.Relation" scheme="URI" content="../cl/addsvraute.htm" />
<meta name="DC.Relation" scheme="URI" content="../cl/chgddmtcpa.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="rbal1rdbpro" />
<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>Protection strategies in a distributed relational database</title>
</head>
<body id="rbal1rdbpro"><a name="rbal1rdbpro"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Protection strategies in a distributed relational database</h1>
<div><p>Network security in an <span class="keyword">iSeries™</span> distributed
relational database must be planned to protect critical data on any application
server (AS) from unauthorized access. But because of the distributed nature
of the relational database, security planning must ensure that availability
of data in the network is not unnecessarily restricted.</p>
<p>One of the decisions that a distributed relational database administrator
needs to make is the system security level in place for each system in the
network. A system security level of 10 provides no security for application
servers other than physical security at the system site. A system security
level of 20 provides some protection to application servers because network
security checking is done to ensure the local and remote system are correctly
identified. However, this level does not provide the object authorization
necessary to protect critical database elements from unauthorized access.
An <span class="keyword">iSeries server</span> security level
of 30 and above is the recommended choice for systems in a network that want
to protect specific system objects.</p>
<p>The distributed relational database administrator must also consider how
communications are established between application requesters (ARs) on the
network and the application servers. Some questions that need to be resolved
might include: </p>
<ul><li>Should a default user profile exist on an AS? <p>Maintaining many user
profiles throughout a network can be difficult. However, creating a default
user profile in a communications subsystem entry opens the AS to incoming
communications requests if the AS is not a secure location. In some cases
this might be an acceptable situation, in other cases a default user profile
might reduce the system protection capabilities too far to satisfy security
requirements.</p>
<p>For example, systems that serve many ARs need a high level
of security. If their databases were lost or damaged, the entire network could
be affected. Because it is possible to create user profiles or group profiles
on an AS that identifies all potential users needing access, it is unnecessary
for the database administrator to consider creating a default user profile
for the communications subsystem or subsystems managing distributed relational
database work.</p>
<p>In contrast, an <span class="keyword">iSeries server</span> that
rarely acts as an AS to other systems in the network and does not contain
sensitive or critical data might use a default user profile for the communications
subsystem managing distributed relational database work. This might prove
particularly effective if the same application is used by all the other systems
in the network to process work on this database.</p>
<p>Strictly speaking,
the concept of a default user applies only to the use of APPC. However, a
similar technique can be used with systems that are using TCP/IP. A single
user ID can be established under which the server jobs can run. The <span class="cmdname">Add
Server Authentication Entry (ADDSVRAUTE)</span> command can be used on
all ARs to specify that user ID should be used for all users to connect with.
The server authorization entries can have a password specified on them, or
they can specify *NONE for the password, depending on the setting
of the PWDRQD parameter on the <span class="cmdname">Change DDM TCP/IP Attributes (CHGDDMTCPA)</span> command
at the AS. The default value of this attribute is that passwords are required.</p>
</li>
<li>How should access to database objects be handled? <p>Authority to objects
can be granted through private authority, group authority, public authority,
adopted authority, and authorization lists. While a user profile (or default
profile) has to exist on the AS for the communications request to be accepted,
how the user is authorized to objects can affect performance.</p>
<p>Whenever
possible, use group authority or authorization lists to grant access to a
distributed relational database object. It takes less time and system resources
to check these than to review all private authorities.</p>
<p>For TCP/IP connections,
you do not need a private user ID for each user that can connect to an AS,
because you can map user IDs.</p>
</li>
</ul>
</div>
<div>
<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="relref"><strong>Related reference</strong><br />
<div><a href="../cl/addsvraute.htm">Add Server Authentication Entry (ADDSVRAUTE) command</a></div>
<div><a href="../cl/chgddmtcpa.htm">Change DDM TCP/IP Attributes (CHGDDMTCPA) command</a></div>
</div>
</div>
</body>
</html>