Part of planning for a distributed relational database involves
the decisions you must make about securing distributed data.
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 servers connected
by Advanced Program-to-Program Communication (APPC) can do the following things:
- If both servers are iSeries™ servers,
communicate passwords in encrypted form.
- Verify that when one server receives a request to communicate with another
server in the network, the requesting server is actually "who it says it is"
and that it is authorized to communicate with the receiving server.
All servers can do the following things:
- Pass a user's identification and password from the local server to the
remote server 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 iSeries server includes
security audit functions that allow you to track unauthorized attempts to
access data, as well as to track other events pertinent to security.
The server also provides a function that can prevent all distributed database
access from remote servers.
- 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 server identification of remote-data-accessing users at both
local and remote servers.
- Coordinate auditing functions between sites.