Distributed Security Guidelines

Several techniques can enhance the security of distributed DB2 implementations . The following guidelines will assist the developer in securing distributed DB2 data.

Come-From Checking

At times, ensuring that a specific userid has the appropriate authorization to access distributed data is not sufficient. Using the CDB tables, you can use DB2 to institute what is known as come-from checking . When come-from checking is established, the requesting location and requesting userid are checked in combination.

Suppose that userid DBAPCSM exists at several locations : CHICAGO , JACKSONVILLE , and PITTSBURGH . By populating the SYSIBM.USERNAMES table appropriately, you can implement come-from checking to effectively disable specific combinations of userid and location.

By inserting the appropriate rows into SYSIBM.LUNAMES and SYSIBM.USERNAMES , you can implement come-from checking to enable a specific user to access data from any location or to enable any user to access data from a specific location. By default, come-from checking is not implemented. Analysis and specific action must be taken to use come-from checking.

Come-from checking is particularly useful when multiple authids may be logging in from multiple locations. Additional control is available with come-from checking.

Authid Translation

Another possibility in a distributed environment is to translate authids automatically for distributed requests . One authid can be translated to another completely different authid.

Authids can be translated by the requesting location, the server location, both locations, or neither location.

Inbound authid translation happens when authids are translated by the server. This term is used because the authid is not changed until it is received by the server (as an inbound request). By contrast, outbound authid translation is performed by the requester, prior to the request being sent.

Consistent Authids

You can use authid translation to implement consistent authids for each user on the network, regardless of location. Consider, for example, a situation in which authids are assigned so that they are unique across the network. Perhaps the location is embedded in the name . So, maybe DBA P CSM exists in Pittsburgh; DBA J CSM , in Jacksonville; and DBA C CSM , in Chicago.

Authid translation can be used to convert any of these valid authids to a single, consistent authid such as DBACSM . Doing so greatly reduces the administrative burden of implemented distributed security.

Network Specific Authids

Sometimes assigning all requests from a single location the same consistent authid is useful. If you impose outbound authid translation, all outbound requests can be translated to one specific authid, thereby reducing complexity (of course, at the expense of security).

Password Encryption

If outbound authid translation is implemented, DB2 requires that a valid password is sent along with each authid. If you choose this option, be sure to encrypt the passwords in the SYSUSERNAMES CDB table using one of the following methods :

• Specify Y in the ENCRYPTPSWDS column of the SYSLUNAMES table (for that LU ).

• Code an EDITPROC on SYSUSERNAMES to encrypt the password.

Miscellaneous Security Guidelines

Utilize the following security guidelines as you develop distributed DB2 applications.

PUBLIC AT ALL LOCATIONS

If a particular table is to be made accessible by anyone on the network ”regardless of authid or location ”security can be granted specifying PUBLIC AT ALL LOCATIONS . Of course, it is applicable to only the INSERT , UPDATE , DELETE , and SELECT table privileges.