Protection strategies in a distributed relational database

Network security in an IBM® i distributed relational database must be planned to protect critical data on any server 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 which system security level to put in place for each system in the network. A system security level of 10 provides no security for servers other than physical security at the system site. A system security level of 20 provides some protection to servers because network security checking is done to ensure that 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. A system security level of 30 and above is the suggested 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 clients on the network and the servers. Some questions that need to be resolved might include:

• Should a default user profile exist on a server?

  Maintaining many user profiles throughout a network can be difficult. However, creating a default user profile in a communications subsystem entry opens the server to incoming communications requests if the server 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 clients 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 a server 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, a system that rarely acts as a server to other systems in the network and that 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 clients to specify that a user ID should be used for all users to connect with. The server authentication 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 server. The default value of this attribute is that passwords are required.

• How should access to database objects be handled?

  Authority to objects can be granted through private authority, group authority, public authority, adopted authority, and authentication lists. While a user profile (or default profile) has to exist on the server for the communications request to be accepted, how the user is authorized to objects can affect performance.

  Whenever possible, use group authority or authentication 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 a server, because you can map user IDs.