Security of resource definitions

CICS provides a number of facilities that help you keep your resource definitions secure from unauthorized use.

When you are considering the security of your resource definitions:
Limited access to resource definitions in the CSD
You should limit read/write access to resource definitions in the CSD to a small number of people. To do this:
  • Protect groups of resources by using the CEDA command LOCK
  • Protect the list of resource groups that is specified in the system initialization parameter GRPLIST by using the CEDA command LOCK
  • Use the CEDB transaction to create resource definitions, but not to INSTALL them
  • Use the CEDC transaction for read-only access to resource definitions.

For information about the CEDA LOCK and UNLOCK commands, see Resource management transaction CEDA commands.

Resource security checking

Resource security checking ensures that terminal operators can access only those resources for which they have been authorized. You can use resource security checking (RESSEC) for the TRANSACTION definition.

Multiple CSD files

You can have different CSD files for different CICS® systems. The users of one CICS do not have access to the CSD file for another CICS.

You could have a test CSD file in a system where the RDO transactions can be used, and a production CSD file in a system where the RDO transactions are not available. There would then be no chance of unauthorized users altering resource definitions needed for production work.

Read-only and update definitions for the same CSD file
Having two CSD files means duplicating resource definitions for resources that are shared by more than one system. An advantage of RDO is that you need only one definition for each resource. You can define one CSD file to be shared among several CICS systems with only one having write access. To do this, you define one CSD file differently to different systems by using the CSDACC system initialization parameter. For the system where the CSD file can be used but not updated, you specify: 
CSDACC=READONLY
and, for the system where you are planning to update the CSD, you specify: 
CSDACC=READWRITE

You need READONLY access to install definitions. This also allows you to use the DISPLAY and VIEW commands. You need READWRITE access to use the ADD, APPEND, ALTER, COPY, MOVE, and RENAME commands. For information on defining the CSD file, see Resource management utility DFHCSDUP commands.

Controlling access to a group or list—LOCK and UNLOCK

RDO also provides a means of controlling access to any group or list, so that users in the same system can have different types of access. This is done with the LOCK and UNLOCK commands.

The LOCK and UNLOCK commands enable you to control update access to a group or list so that only operators with the same operator identifier can make changes.

The lock is held on the CSD file and remains in effect across restarts of CICS. The lock is owned by the user, who is identified by a combination of the CICS generic applid (specified by the APPLID system initialization parameter), and the user's operator identifier (OPIDENT).

The OPIDENT is the one associated with the user when he or she signs on to the terminal used for RDO. For further information on OPIDENT, see The CICS segment.

Any user who is not signed on or who has a different OPIDENT is not allowed to perform any operation that would change the locked group. However, any user is allowed to do the following things to a locked group:
  • COPY
  • CHECK
  • DISPLAY
  • INSTALL
  • VIEW

The lock can be removed, using the UNLOCK command, only by a user on the same system and with the same operator identifier.

It would be wise to put a lock on your group of TYPETERMs and on your group of AUTINSTMODEL TERMINALs.

Controlling access to the RDO transactions
Recommended access for the CEDA, CEDB, and CEDC transactions is as follows:
  • CEDC can be given fairly wide access, because it allows only read-only commands.
  • CEDB should be restricted, because it allows modification of the CSD file as well as read-only commands.
  • CEDA should be further restricted to the few people allowed to modify both the active CICS system and the CSD file.
Installing resources
A user who is authorized to use CEDA can install any resources in the CICS system: beyond checking the user's authority to use the transaction itself, CICS does not do any command or resource security checking in the CEDA transaction.
This is not the case for transactions that use the CREATE command to install resources; here, CICS uses
  • command security to check that the user is authorized to use the CREATE command. For more information, see CICS command security.
  • resource security to check that the user is authorized to modify the resource in question. For more information, see Resource security.