Implementing Resource-Level Security › Securing Data Set Members

Securing Data Set Members

On z/VM systems, read:

• Minidisk for PDS
• SOLVE GCS for RUNSYSIN
• vmid 292 F-disk for TESTEXEC
• vmid 293 G-disk for dsnpref.pvpref.CC2DEXEC

The members that control a region must be secured to ensure adequate security for the region. The library in which these members should be secured is called the security PDS. Only security personnel should be allowed access to the security PDS.

The security PDS is not created during the installation of your product, and must be created manually before you proceed to implement security. To establish a valid security PDS that secures all members controlling access to Automation Services functions, complete the following steps:

1. Create a security PDS, and ensure that it is the first library in the COMMANDS concatenation of libraries.

   Note: The COMMANDS concatenation of libraries is in your RUNSYSIN member. The default first library is TESTEXEC.

2. Copy the following members from the CC2EXEC data set into the security PDS:
   • $NMSEC

     Controls access to functions.

   • ALLOCATE, FSTOP, OPSYS, ROUTE, SHUTDOWN, SUBMIT, SYSCMD, and UNLOAD

     Controls access by message monitor users to commands. These members are command replacement NCL procedures.

3. Copy the following members from the CC2DEXEC data set into the security PDS:
   • $RMSXxxx

     Provides sample SAF security profiles for CA ACF2 (if you are using it to control access to the region), NPF members (if you are using NPF to control access to the region), or RACF.

4. Copy any user-defined command replacement NCL procedures into the security PDS.
5. Restrict access to this security PDS to security personnel, and the region (read access only).
6. Ensure that the NPTABLES DD points to your security PDS.

   Note: The NPTABLES DD in your RUNSYSIN member points to dsnpref.pvpref.CC2DEXEC by default.