To provide security for a shared data table when
cross-memory
services are used, ensure that:
- The file-owning region (FOR) that is acting as the shared data table server
cannot be impersonated. See SDT server authorization security check for details of how you
ensure this.
- An application-owning region (AOR) cannot gain access to data that it
is not meant to access. You can prevent this by checking at CONNECT time that
the AOR is allowed access to the FOR and, if file security is in force, that
the AOR is allowed access to the requested file.
These security checks are performed through the system authorization
facility (SAF), to invoke RACF® or an equivalent security manager.
Note: A region is still able to use data tables locally even if
it does not have authority to act as a shared data table server.
The CICS® shared data tables (SDT) facility reproduces the main characteristics
of function-shipping security that operate at the region level, but note the
following differences:
- SDT does not provide any mechanism for the FOR to perform security checks
at the transaction level (there is no equivalent of ATTACHSEC(IDENTIFY) or
ATTACHSEC(VERIFY)). Therefore, if you consider that the transaction-level
checks performed by the AOR are inadequate for some files, ensure that those
files are not associated with data tables in the FOR.
- SDT does not support any equivalent of preset security on SESSIONS, because
no sessions are used.
- SDT does not pass any installation parameter list (INSTLN) information
to the security user exits.
Security for CICS shared data tables is covered in the following topics: