Encrypting user data sets

You can encrypt CICS® user data sets for which z/OS® data set encryption is supported.

Before you begin

Check the data set types for which z/OS data set encryption is supported. See Planning for data set encryption.

Ensure that you have set up the key labels to use. See Managing Cryptographic Keys Using the Key Generator Utility Program in z/OS Cryptographic Services ICSF Administrator's Guide.

Ensure that the RACF® tasks to provide authority to create encrypted data sets and to provide access to the key labels are complete, including the following tasks:
  • Grant read access to STGADMIN.SMS.ALLOW.DATASET.ENCRYPT CL(FACILITY) to allow users to create encrypted data sets.
  • Grant read access to the key labels. When a user attempts to access an encrypted data set, RACF checks that the user has authority to use the key label before any encryption occurs by checking access to the relevant profiles in the CSFKEYS and CSFSERV classes. For more information about these classes, see Data Set Encryption in z/OS DFSMS Using Data Sets .

Ensure that you have set up the key labels to use. See Managing Cryptographic Keys Using the Key Generator Utility Program in z/OS Cryptographic Services ICSF Administrator's Guide.

About this task

For user data sets defined to CICS, encryption support includes key-sequenced data sets (KSDS), entry-sequenced data sets (ESDS), relative record data sets (RRDS), and variable relative record data sets (VRRDS), accessed through base VSAM and VSAM Record Level Sharing (RLS). Encryption is also supported for the backing VSAM key-sequenced data sets that are used for shared data tables or coupling facility data tables.

Procedure

  1. Either create an encryption key and associated key label, or use an existing key label.
  2. Allocate a new instance of the data set, specifying extended format and the data set key label.
    1. Specify extended format in one of the following ways:
      • Through the SMS data class, using the DSNTYPE=EXT parameter and R (required) or P (preferred) subparameters. Specify R to ensure that the data set is allocated in extended format.
      • Use the DSNTYPE parameter on the JCL DD statement, with values of EXTREQ (required) or EXTPREF (preferred). Specify EXTREQ to ensure that the data set is allocated in extended format. The DSNTYPE specified on a JCL DD statement overrides any DSNTYPE set for the data class.

      When you specify extended format, ensure that you only specify the extended addressing attribute if you also require that option for your data set.

    2. Specify the data set key label in one of the following ways:
      • On a RACF data set profile by using the DATAKEY keyword.
      • Through JCL by using the DSKEYLBL keyword.
      • On dynamic allocation through the DALDKYL text unit.
      • Through TSO allocate by using DSKEYLBL.
      • On an IDCAMS DEFINE through the KEYLABEL parameter of DEFINE CLUSTER.
      • On the SMS data class by specifying the Data Set Key Label field on the DEFINE/ALTER panel.
      When a data set key label is specified through more than one interface, the order of precedence is as follows:
      1. The RACF data set profile
      2. JCL, dynamic allocation, TSO allocate, or IDCAMS DEFINE
      3. SMS data class

      Consider the granularity of different key labels that you want to use across the groups of data sets that you plan to encrypt, so that you balance convenience of managing the key labels against maximizing the protection of your data. This also helps to determine the appropriate mechanism to use to specify the key label.

  3. Copy across data from the existing data set into the new, encrypted, data set.
    Use an appropriate DFSMS function such as REPRO, or the EXPORT and IMPORT functions. A typical sequence is as follows:
    1. Create the new data set.
    2. Copy the data across from the old data set.
    3. Delete the old data set.
    4. Rename the new data set back to the old name.