Security considerations for a distributed relational database

These decisions include:

• What systems should be made accessible to users in other locations and which users in other locations should have access to those systems.
• How tightly controlled access to those systems should be. For example, should a user password be required when a conversation is started by a remote user?
• Is it required that passwords flow over the wire in encrypted form?
• Is it required that a user profile under which a client job runs be mapped to a different user identification or password based on the name of the relational database to which you are connecting?
• What data should be made accessible to users in other locations and which users in other locations should have access to that data.
• What actions those users should be allowed to take on the data.
• Whether authorization to data should be centrally controlled or locally controlled.
• If special precautions should be taken because multiple systems are being linked. For example, should name translation be used?

When making the previous decisions, consider the following items when choosing locations:

• Physical protection. For example, a location might offer a room with restricted access.
• Level of system security. The level of system security often differs between locations. The security level of the distributed database is no greater than the lowest level of security used in the network.

  All systems connected by Advanced Program-to-Program Communication (APPC) can do the following things:

  • If both systems are System i® products, communicate passwords in encrypted form.
  • When one system receives a request to communicate with another system in the network, verify that the requesting system is actually "who it says it is" and that it is authorized to communicate with the receiving system.

  All systems can do the following things:

  • Pass a user's identification and password from the local system to the remote system for verification before any remote data access is allowed.
  • Grant and revoke privileges to access and manipulate SQL objects such as tables and views.

  The IBM® i operating system includes security audit functions that you can use to track unauthorized attempts to access data, as well as to track other events pertinent to security. The system also provides a function that can prevent all distributed database access from remote systems.

  • Security-related costs. When considering the cost of security, consider both the cost of buying security-related products and the price of your information staff's time to perform the following activities:
    • Maintain identification of remote-data-accessing users at both local and remote systems.
    • Coordinate auditing functions between sites.