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. The library in which these members are secured is known as the security PDS. Only security personnel are 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 as 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 CC2DEXEC data set into the security PDS:

   $NMSEC

   Controls access to functions.

   $RMSXxxx

   Provides sample SAF security profiles for the following:

   • 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)
   • RACF

   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 any user-defined command replacement NCL procedures into the security PDS.
4. Restrict access to this security PDS to security personnel, and the region (read access only).
5. Point the NPTABLES DD to your security PDS.

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