Securing a Classic data server

To secure your Classic data server, create security classes and profiles in your external security manager (ESM) and configure service-level parameters in the server.

About this task

Work with your Security Administrator to determine the appropriate levels of security for your site. For best results, secure as many operations as you can while maintaining site standards and performance. You can secure administrative connections to your Classic data server, remote operator commands, monitoring, table mapping, catalogs, and the replication process itself.

When you secure the configuration data sets and the VSAM files for subscriptions and replication mappings, use the following table to locate them. You specified high level qualifiers for these data sets in the customization parameters file when you performed the installation customization process.

Table 1. High level qualifiers and corresponding data sets.
High level qualifier (HLQ) Function

CDCPCFGD="&&CPHLQ..CACCFGD"

CDCPCFGX="&&CPHLQ..CACCFGX"

Configuration data sets

CDCCATNM="&CPHLQ..CATALOG"

CDCIDXNM="&CPHLQ..CATINDX"

 Catalog data sets

CDCPSUBS="&CPHLQ..SUB"

Subscription data sets

CDCPRMDS="&CPHLQ..RM"

Replication mapping data sets

Procedure

  1. Determine which users require access to your Classic data servers and the level of access that each user requires.

    Decide whether each user requires READ or CONTROL access to subscriptions, administrative functions, and remote console commands.

  2. Ensure that each user has a valid z/OS® user account.
  3. If you grant different levels of access to system resources for multiple users, follow these steps.
    1. Ask your System Administrator to define the profiles and classes that you require by using the System Authorization Facility (SAF).
      Follow the remaining steps for each applicable service:
      • Administration service (PAA)
      • Operator service (OPER)
      • Query processor service (QP)
    2. Ensure that VALIDATE=Y for the SAFEXIT parameter.

      VALIDATE=Y is the default setting, so omitting the keyword has the same effect as specifying VALIDATE=Y.

      If you use SAFEXIT with VALIDATE=N then the Classic data server only validates that each user has a valid user account and password. Users have full access to objects on the Classic data server except the catalog, where SQL privileges determine access.

    3. Optional: Override the default class and profile names in the xxxCLASS and xxxPROF parameters.
      Exception: You cannot specify class and profile overrides for the monitoring service or query processor service.
  4. Run data description language (DDL) on the server that contains the appropriate GRANT statements to secure access to catalog objects.
  5. Perform the following security tasks for the source server.
    1. For IMS:
      • Grant UPDATE access to the IMS RECON data sets.
      • If you use IMS DBRC command authorization, the Classic data server needs LIST.* authority for DBRC.
      • Ensure that the data server has READ authority for the IMS DBDLIB data sets that the data server references. Grant READ authority for all IMS log data sets that need to be accessed.
        • For a DB/DC or DBCTL subsystem these data sets include the primary and secondary online log data sets and the corresponding primary and secondary system log data sets.
        • For logs produced by DL/I batch jobs one of these types of logs will only be accessed if it contains data capture log records. When processing historical changes, the log can potentially contain data capture log records.
    2. Grant READ access for CLASS(FACILITY) RESOURCE(BPX.CONSOLE) to the job or started task for the Classic data server.
    3. Grant UPDATE access to the configuration data sets and the VSAM files for subscriptions and replication mappings.
    4. The user ID associated with the job or started task needs an OMVS segment for TCP/IP access.