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.
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 iSeries server security level of 30 and above is the recommended choice for systems in a network that want to protect specific system objects.
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:
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.
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.
In contrast, an iSeries server 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.
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 Add Server Authentication Entry (ADDSVRAUTE) 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 Change DDM TCP/IP Attributes (CHGDDMTCPA) command at the AS. The default value of this attribute is that passwords are required.
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.
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.
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.