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.