Maintaining encrypted data sets
Encrypted data sets can be retained for the entire life of the data. This chapter briefly explains how to determine which data sets are encrypted. It also provides step-by-step procedures for rotating the keys that are associated with data set encryption.
This chapter includes the following topics:
7.1 Identifying encrypted data sets
Data sets become encrypted when key labels are provided at data set allocation. Those key labels might be provided by the following sources:
•DATASET class resources
•SMS DATACLAS
•TSO ALLOCATE
•JCL
Although you might identify the source for the key label, that process does not always ensure that the data sets that are associated with the source are encrypted. For example, you can set a key label in a DATASET class resource that encrypts new data sets, but the old data sets remain unencrypted. Therefore, you need more tools to determine which data sets are encrypted.
7.1.1 Using IBM zSecure
You can use IBM zSecure to identify all encrypted data set names, along with their associated key labels. For more information about zSecure, see 2.3.6, “IBM Security zSecure Suite” on page 22.
7.2 Rekeying encrypted data sets
Your security policy might dictate the rotation of keys in your environment. On z/OS, ICSF supports the rotation of master keys and operational keys.
7.2.1 Rotating the AES master key
IBM recommends that master keys be rotated periodically. However, the frequency of master key rotation is at the organization’s discretion. Master key rotation is nondisruptive and does not affect the data that is encrypted by keys in the Key Data Sets.
Master key rotation involves reenciphering secure, operational keys that are in the Key Data Sets. Reencipherment occurs in the secure boundary of the Crypto Express adapter.
Master key rotation involves decrypting secure, operational key values that are in the Key Data Sets from under the current master key to encryption under the new master key. This reencipherment occurs in the secure boundary of the Crypto Express adapter. After reencipherment, the new master key is set to become the current master key.
The process for master key rotation is automated and can be run on a single system or synchronized across a sysplex.
Rotating the AES master key includes the following steps:
1. Allocate a new CKDS.
2. Load the new AES master key.
3. Start the coordinated CKDS Change MK operation.
4. Verify the new AES master key.
These steps are described next.
Step 1: Allocating a new CKDS
To allocate a new key data set for the CKDS that can store variable-length records, we used the JCL that is shown in Example 7-1. This JCL was based on the sample job from SYS1.SAMPLIB(CSFCKD3).
Example 7-1 JCL to allocate a new CKDS data set
//DEFINE EXEC PGM=IDCAMS,REGION=4M
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE CLUSTER (NAME(PLEX75.SHARED3.SCSFCKDS) -
VOLUMES(BH5CAT) -
RECORDS(100 50) -
RECORDSIZE(372,2048) -
KEYS(72 0) -
FREESPACE(10,10) -
SHAREOPTIONS(2,3)) -
DATA (NAME(PLEX75.SHARED3.SCSFCKDS.DATA) -
BUFFERSPACE(100000) -
ERASE) -
INDEX (NAME(PLEX75.SHARED3.SCSFCKDS.INDEX))
/*
You can optionally allocate a backup data set for the reenciphered keys, as shown in Example 7-2.
Example 7-2 JCL to allocate a backup CKDS data set
//DEFINE EXEC PGM=IDCAMS,REGION=4M
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE CLUSTER (NAME(PLEX75.SHARED3.COPY.SCSFCKDS) -
VOLUMES(BH5CAT) -
RECORDS(100 50) -
RECORDSIZE(372,2048) -
KEYS(72 0) -
FREESPACE(10,10) -
SHAREOPTIONS(2,3)) -
DATA (NAME(PLEX75.SHARED3.COPY.SCSFCKDS.DATA) -
BUFFERSPACE(100000) -
ERASE) -
INDEX (NAME(PLEX75.SHARED3.COPY.SCSFCKDS.INDEX))
/*
Step 2: Loading the new AES master key
Loading the master key for key rotation uses the same steps that are required to load a new master key register before CKDS initialization.
For more information about the steps to load the AES master key, see 4.3.5, “Loading the AES master key” on page 75.
Step 3 Starting the Coordinated Change MK operation
The Coordinated Change Master Key operation can be started from the TKE workstation (for TKE 8.0 and later) or by using z/OS ICSF.
The following steps show how to start a coordinated CKDS master key change by using ICSF:
Figure 7-1 ICSF - KDS Management
2. In the ICSF - Key Data Set Management panel, select Option 1-CKDS Management (see Figure 7-2). Press Enter.
Figure 7-2 ICSF- Key Data Set Management Option 1
3. In the ICSF - CKDS Management panel, select Option 5-Perform a coordinated CKDS change master key (see Figure 7-3). Press Enter.
Figure 7-3 ICSF - CKDS Management Option 5
4. Review the Coordinated KDS change master key panel (see Figure 7-4). Press Enter.
Figure 7-4 Coordinated KDS change master key panel
5. Perform the following changes on the ICSF - Coordinated KDS change master key (see Figure 7-5):
a. Enter Y for fields Rename Active to Archive and New to Active [Y/N} and Create a backup of the reenciphered KDS [Y/N].
b. Update the New KDS, Archived KDS, Backup KDS names.
In our example:
• The New KDS (allocated and empty) was named PLEX75.SHARED3.SCSFCKDS
• The Archive KDS (not allocated) was named PLEX75.SHARED3.OLD.SCSFCKDS
• The Backup KDS (allocated but empty) was named PLEX75.SHARED3.COPY.SCSFCKDS
c. Press Enter.
Figure 7-5 Archive KDS
Figure 7-6 Confirm KDS change
7. Check the status message on the ICSF - Coordinated KDS change master key panel (see Figure 7-7).
Figure 7-7 Coordinated KDS change: Change successful
8. Check for the MVS Console messages. SYSLOG includes the messages that are shown in Example 7-3.
Example 7-3 SYSLOG messages
CSFM618I CKDS DATA SET PLEX75.SHARED3.SCSFCKDS.INDEX RENAMED TO
PLEX75.SHARED.SCSFCKDS.INDEX
IEF196I CSFM618I CKDS DATA SET PLEX75.SHARED3.SCSFCKDS.INDEX RENAMED
TO
IEF196I PLEX75.SHARED.SCSFCKDS.INDEX
CSFM622I COORDINATED CHANGE-MK PROGRESS: DATA SET RENAMING COMPLETE.
IEF196I CSFM622I COORDINATED CHANGE-MK PROGRESS: DATA SET RENAMING
IEF196I COMPLETE.
IEF196I IEF237I 9788 ALLOCATED TO SYS00005
CSFM653I CKDS LOADED 9 RECORDS WITH AVERAGE SIZE 253
IEF196I CSFM653I CKDS LOADED 9 RECORDS WITH AVERAGE SIZE 253
IEF196I IGD104I PLEX75.SHARED.SCSFCKDS RETAINED,
IEF196I DDNAME=SYS00005
CSFM622I COORDINATED CHANGE-MK PROGRESS: NEW IN-STORAGE KDS LOADED ON
REMOTE SYSTEMS.
IEF196I CSFM622I COORDINATED CHANGE-MK PROGRESS: NEW IN-STORAGE KDS
IEF196I LOADED ON REMOTE SYSTEMS.
CSFM622I COORDINATED CHANGE-MK PROGRESS: OPERATION TERMINATION IS
TEMPORARILY INHIBITED.
IEF196I CSFM622I COORDINATED CHANGE-MK PROGRESS: OPERATION TERMINATION
IEF196I IS TEMPORARILY INHIBITED.
CSFM622I COORDINATED CHANGE-MK PROGRESS: A NEW CKDS HASH TABLE WAS
CONSTRUCTED.
IEF196I CSFM622I COORDINATED CHANGE-MK PROGRESS: A NEW CKDS HASH TABLE
IEF196I WAS CONSTRUCTED.
IXC121I CFRM ENCRYPT CHANGE-MK PROGRESS: CHANGE MASTER KEY PROCESSING COMPLETED.
IEF196I CSFM622I COORDINATED CHANGE-MK PROGRESS: CHANGE MASTER KEY
IEF196I PROCESSING COMPLETED.
CSFM622I COORDINATED CHANGE-MK PROGRESS: ALL FINAL CKDS DSN REFERENCES
UPDATED.
IEF196I CSFM622I COORDINATED CHANGE-MK PROGRESS: ALL FINAL CKDS DSN
IEF196I REFERENCES UPDATED.
CSFM622I COORDINATED CHANGE-MK PROGRESS: SWITCHED THE ACTIVE CKDS
HASH TABLE TO NEW.
IEF196I CSFM622I COORDINATED CHANGE-MK PROGRESS: SWITCHED THE ACTIVE
IEF196I CKDS HASH TABLE TO NEW.
CSFM622I COORDINATED CHANGE-MK PROGRESS: OPERATION TERMINATION IS NOW
REENABLED.
IEF196I CSFM622I COORDINATED CHANGE-MK PROGRESS: OPERATION TERMINATION
IEF196I IS NOW REENABLED.
CSFM622I COORDINATED CHANGE-MK PROGRESS: COMPLETING CORE WORK.
IEF196I CSFM622I COORDINATED CHANGE-MK PROGRESS: COMPLETING CORE WORK.
IXC121I CFRM ENCRYPT CHANGE-MK PROGRESS: REENCIPHERING KEYS IN CFRM
CDS.
CSFM622I COORDINATED CHANGE-MK PROGRESS: A NEW CKDS HASH TABLE WAS
CONSTRUCTED.
IEF196I CSFM622I COORDINATED CHANGE-MK PROGRESS: A NEW CKDS HASH TABLE
IEF196I WAS CONSTRUCTED.
IXC121I CFRM ENCRYPT CHANGE-MK PROGRESS: ADMINISTRATIVE DATA KEYS
IXC121I CFRM ENCRYPT CHANGE-MK PROGRESS: CHANGE MASTER KEY PROCESSING
STARTED.
IXC121I CFRM ENCRYPT CHANGE-MK PROGRESS: ACTIVE POLICY DATA HAS BEEN
UPDATED.
IXC121I CFRM ENCRYPT CHANGE-MK PROGRESS: CF STRUCTURE UPDATES PENDING.
CSFM622I COORDINATED CHANGE-MK PROGRESS: CHANGE MASTER KEY PROCESSING
COMPLETED.
IEF196I CSFM622I COORDINATED CHANGE-MK PROGRESS: CHANGE MASTER KEY
IEF196I PROCESSING COMPLETED.
CSFM622I COORDINATED CHANGE-MK PROGRESS: ALL FINAL CKDS DSN REFERENCES
UPDATED.
IEF196I CSFM622I COORDINATED CHANGE-MK PROGRESS: ALL FINAL CKDS DSN
IEF196I REFERENCES UPDATED.
CSFM622I COORDINATED CHANGE-MK PROGRESS: SWITCHED THE ACTIVE CKDS
HASH TABLE TO NEW.
IEF196I CSFM622I COORDINATED CHANGE-MK PROGRESS: SWITCHED THE ACTIVE
IEF196I CKDS HASH TABLE TO NEW.
CSFM617I COORDINATED CHANGE-MK ACTION COMPLETED SUCCESSFULLY.
CSFU006I CHANGE-MK FEEDBACK: RC=00000000 RS=00000000 SUPRC=00000000
SUPRS=00000000 FLAGS=40000000.
IEF196I CSFU006I CHANGE-MK FEEDBACK: RC=00000000 RS=00000000
IEF196I SUPRC=00000000 SUPRS=00000000 FLAGS=40000000.
IXC121I CFRM ENCRYPT CHANGE-MK PROGRESS: CF STRUCTURE UPDATES PENDING.
IXC121I CFRM ENCRYPT CHANGE-MK PROGRESS: CF STRUCTURE UPDATES
COMPLETED.
|
Note: All of the IXC messages are sent by Sysplex Services for Data Sharing (XES) in this scenario because we enabled CF structure encryption in our environment. XES detected a change in the AES master key so that it drove a CF structure change in the CFRM couple data set.
|
9. Press F3 to return to the CKDS Management panel. Press F3 to return to the KDS Management panel.
Step 4: Verifying the AES master key is active
To verify that the master keys are active, complete the following steps:
Figure 7-8 ICSF panel select Option 1
2. The ICSF Coprocessor Management panel is shown in Figure 7-9. Enter s next to the crypto feature to view its status. Press Enter.
Figure 7-9 ICSF Coprocessor Management for the crypto features
3. View the Coprocessor Hardware Status panel (see Figure 7-10). Review the following Master keys information:
– New Master Key register is EMPTY.
– Current Master Key register is VALID with a new Verification Pattern.
– Old Master Key register is VALID with the Verification Pattern from the previous Master Key.
Figure 7-10 Coprocessor hardware status
7.2.2 Rotating data set encryption keys
Deciding to rotate your data set encryption keys is determined by your security policy or compliance mandates. It also is done for a compromised key.
Two common approaches to rotating data set encryption keys are listed in Table 7-1. Each approach features pros and cons.
Table 7-1 Data set encryption key rotation approaches
|
Approach
|
Description
|
Considerations
|
|
Aging Out
|
Current data is encrypted with current key.
After a specific period, a new key is generated and assigned.
New data is encrypted with the new key.
|
•Non-disruptive
•Not sufficient when a key is compromised
•Affects new data only
•Existing data is not reencrypted
•Old keys must remain in the CKDS
•More keys to manage
•Key versioning is recommended
|
|
Re-Encrypt All Data
|
A new key is generated and assigned.
Existing data is reencrypted with the new key.
New data is encrypted with the new key.
|
•Disruptive in most cases1
•Recommended when a key is compromised
•Affects all data (new and old)
•Must identify all data encrypted with the old key
•Archiving the old key is recommended rather than deleting the old key
•Crypto-periods can be established to restrict key usage
•Key versioning is recommended
|
1 For Db2 data sets, you can start an online reorganization to make the re-encryption process nondisruptive.
The first three steps for aging out and re-encrypting all data are the same for both approaches. The later steps apply to re-encrypting all data only.
Step 1: Generating an operational key
To rotate a data set encryption key, you must generate a key and associated key label.
As described in 3.5.7, “Creating a key label naming convention” on page 45, you must consider your key label naming convention in determining the key label for the new key. Consider the following questions:
•Is there an existing naming convention?
•Is there a new sequence number?
•What is the next sequence number?
•Will the key label be protected under an existing data set profile?
After you determine your key label name, you can choose one of several methods to generate a key label, as described in 5.3, “Generating a secure 256-bit AES DATA key” on page 105.
Step 2: Locating all key label sources
You must identify the DATASET class resources, SMS DATACLAS resource, TSO ALLOCATE CLISTs, and JCL that include the key label.
DATASET class
The DATASET class is the primary method that is used to supply a key label for data set encryption. You can create an ICETOOL to identify which DATASET class resources include a DATAKEY segment. Sample JCL to create such a report is shown in Example 7-4.
In Example 7-4, ISFPP.ITSO.RACF is the RACF database name in our environment. Also, the INCLUDE statement can be modified to filter the results.
Example 7-4 Report for DATASET class profiles
//* ---------------------------------------------------------------
//* DISPLAYS A REPORT OF ALL DATASET CLASS PROFILES WITH A
//* DATAKEY LABEL IN THE DFP SEGMENT.
//* ---------------------------------------------------------------
//* UNLOAD THE RACF DB IN QUESTION TO A FLAT DATASET.
//* ---------------------------------------------------------------
//IRRDBU00 EXEC PGM=IRRDBU00,PARM='NOLOCK'
//SYSPRINT DD SYSOUT=*
//INDD1 DD DISP=SHR,DSN=ISFPP.ITSO.RACF
//OUTDD DD DSN=&&RACFLAT,DISP=(NEW,PASS,DELETE),
// SPACE=(CYL,(1,1,0)),
// DCB=(LRECL=4096,RECFM=VB)
//SYSUDUMP DD SYSOUT=*
//* ---------------------------------------------------------------
//* USE THE OUTPUT FOR THE ICE REPORT
//* ---------------------------------------------------------------
//ICETOOL EXEC PGM=ICETOOL,PARM='MSGPRT=ALL'
//COUNTMSG DD SYSOUT=*
//TOOLMSG DD SYSOUT=*
//PRINT DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//DBUDATA DD DSN=&&RACFLAT,DISP=(OLD,DELETE,DELETE)
//TEMP0001 DD UNIT=SYSALLDA,SPACE=(CYL,(10,5))
//TOOLIN DD *
SORT FROM(DBUDATA) TO(TEMP0001) USING(DFP$)
DISPLAY FROM(TEMP0001) LIST(PRINT) -
PAGE -
TITLE('DATA SET PROFILES WITH A DFP DATAKEY') -
DATE(YMD/) -
TIME(12:) -
BLANK -
ON(10,44,CH) HEADER('DATA SET NAME') -
ON(55,06,CH) HEADER('VOLUME') -
ON(62,08,CH) HEADER('RESOWNER') -
ON(71,64,CH) HEADER('DATAKEY')
//DFP$CNTL DD *
SORT FIELDS=COPY
OPTION VLSHRT
INCLUDE COND=(05,04,CH,EQ,C'0410',AND,
71,08,CH,NE,C' ')
/*
Example 7-5 shows the output from the JCL in Example 7-4 on page 139 with the following INCLUDE statement:
INCLUDE COND=(05,04,CH,EQ,C'0410',AND,
71,08,CH,NE,C' ')
The output lists the DATASET profiles that include a DFP segment.
Example 7-5 DFP segment with key labels
DATA SET NAME VOLUME RESOWNER DATAKEY
---------------------------- ------ -------- ----------------------------------------------
DB12D.DSNDBC.DSN8D11A.** DATASET.PE06.ICSF.ENCRYPT.DB12D
DB12D.DSNDBC.DSN8*.* DATASET.PE06.ICSF.ENCRYPT.DB12D
DB12D.DSNDBC.LIBD.* DATASET.PE06.ICSF.ENCRYPT.DB12D
DB12D.DSNDBC.LIBDB.** DATASET.PE06.ICSF.ENCRYPT.DB12D
DB12D.DSNDBD.DSN8D11A.** DATASET.PE06.ICSF.ENCRYPT.DB12D
DB12D.DSNDBD.DSN8*.* DATASET.PE06.ICSF.ENCRYPT.DB12D
DB12D.DSNDBD.LIBD.* DATASET.PE06.ICSF.ENCRYPT.DB12D
DB12D.DSNDBD.LIBDB.* DATASET.PE06.ICSF.ENCRYPT.DB12D
DB12D.DSNDBD.LIB DATASET.PE06.ICSF.ENCRYPT.DB12D
PE01.ENCRYB2.* PE01 DATASET.PE01.NOT
PE01.ICSF.ENCRYPT.ME.* DATASET.PE01.ICSF.ENCRYPT.ME.ENCRKEY.00000001
PE01.ENCRYB2.DATASET CONSM2 PE01 DATASET.PE01.TEST
PE03.PE03.ENC.* PE03 DATASET.PE03.AC01
PE03.SECURE.** PE03 PE03.SECURE.KEY
PE06.ICSF.ENCRYPT.ME.* DATASET.PE06.ICSF.ENCRYPT.ME.ENCRKEY.00000005
PE06.ICSF.ENCRYPT.ME06.* DATASET.PE06.ICSF.ENCRYPT.ME06.ENCRKEY.00000006
PE06.ICSF.ENCRYPT.ME07.* DATASET.PE06.ICSF.ENCRYPT.ME07.ENCRKEY.00000007
PE08.SC60.ENCRYPT.* DATASET.ENCRYPTKEY.001
Example 7-6 shows the output from the JCL in Example 7-4 on page 139 with the following INCLUDE statement:
INCLUDE COND=(05,04,CH,EQ,C'0410',AND,
71,17,CH,EQ,C'DATASET.PE01.TEST')
The output lists the DATASET profiles that include a key label DATASET.PE01.TEST.
Example 7-6 Data sets with a specific key label
DATA SET NAME VOLUME RESOWNER DATAKEY
----------------------------- ------ -------- -----------------------------------------------
PE01.ENCRYB2.* PE01 DATASET.PE01.NOT
PE01.ICSF.ENCRYPT.ME.* DATASET.PE01.ICSF.ENCRYPT.ME.ENCRKEY.00000001
PE01.ENCRYB2.DATASET CONSM2 PE01 DATASET.PE01.TEST
Step 3: Updating the key label sources with the new key label
Now that the new key is generated and the key label sources are identified, you can update the key label sources with the new key label. From that point forward, all newly allocated data sets are encrypted with the new key. Any data sets remain encrypted by the original key.
|
Note: Because the old data sets remain encrypted by the old key, the old key must remain in the CKDS.
|
Step 4: Identifying data sets encrypted with the old key label
When you must reencrypt all data that is associated with a particular key, you must identify which data sets are associated with the original key label.
You must consider every location where the data is stored, such as data that is:
•Active on DASD
•Migrated to tape
•Replicated to DR
You can use IBM zSecure to identify encrypted data sets that are associated with a particular key label. For more information about zSecure, see 2.3.6, “IBM Security zSecure Suite” on page 22.
When the data sets are located, you can verify the key label that is associated with the data set by issuing the LISTCAT ENTRIES(<data set name>) ALL command on the data sets.
Step 5: Allocating new data sets to replace the old data sets
Key labels are associated with data sets at data set allocation. Therefore, every data set must include an associated data set that was allocated with the new key.
Step 6: Copying the contents of the old data sets to the new data sets
After the new data sets are created, the data set contents can be copied from the old data set to the new data set.
|
Note: To perform the copy operation, the user who is performing the copy must have READ access to the old key label and the new key label.
|
Standard utilities can be used to perform the copy operation, including the following standard utilities:
•ISPF 3.3 Copy data set
•IDCAMS REPRO
•IEBGENER
|
Note: Db2 and IMS provide nondisruptive migration to encryption with their Database Online Reorganization function. For high availability, Db2 and IMS provide nondisruptive migration to encryption with Database Online Reorganization function.
|
After the copy operation completes, you have the old data set encrypted with the old key and the new data set encrypted with the new key.
Step 7: Deleting the old data sets
You can choose to delete the old data sets and rename the new data sets to the old so that applications do not need to change.
Alternatively, you can choose to keep or rename the old data sets. In this case, you might want to consider setting the old key label cryptoperiod to end on the day the data was copied into the new data set. This process prevents applications from using the old data set. For more information about cryptoperiods, see 9.5, “Setting key expiration dates” on page 188.
Step 8: Archiving the old key
We do not recommend deleting old data set keys. If the key is deleted, the associated encrypted data sets cannot be opened. For example, if you missed a few data sets during the identification process and the key was deleted, those data sets cannot be decrypted. If you have a backup of the CKDS and the corresponding master key at the time of the backup, you can attempt to recover the old key.
Rather than deleting the old data set encryption key, you can archive the key. The archived key remains in the active CKDS and is disabled for active use by default. When you want to use an archived key, you can recall it by using ICSF or you can define the CSF.KDS.KEY.ARCHIVE.USE resource in the XFACILIT class to allow all archived keys to be used.
For more information about key archiving, see 9.4, “Archiving data set encryption keys” on page 186.
An alternative to key archiving is setting a key expiration date. When a key expires, it can no longer be used in cryptographic operations. The expiration date must be changed to allow use of the key.
For more information, see 9.5, “Setting key expiration dates” on page 188.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.