Pervasive dataset encryption granularity and configuration

Products

• ACF2
• ACF2 - DB2 Option
• ACF2 - z/OS
• ACF2 - MISC

Issue/Introduction

Are there situations where someone could have access to an encrypted dataset and be able to copy or move it but not read/write to it.  Kind of related to how STGADMIN works where storage admin can move a dataset from volume to volume without having explicit access to the dataset to read/write it. 

For a particular HLQ sites probably only want one key yet the level of granularity in an ACF2 rule for that HLQ might have many rules lines for different second level qualifiers and users.  How does that fit together?  

Environment

Release : 16.0

Component : CA ACF2 for z/OS

Resolution

Question – Are there situations where someone could have access to an encrypted dataset and be able to copy or move it but not read/write to it.  Kind of related to how STGADMIN works where storage admin can move a dataset from volume to volume without having explicit access to the dataset to read/write it. 

Answer
Yes, z/OS data set encryption there is a separation of duties between data owners and data administrators so some users can have access to the dataset to move/copy but not be able to view the contents of the encrypted dataset. For details see IBM Redbooks 'Getting Started with z/OS Data Set Encryption' sections:

3.2.6 Copying, backing up, migrating, and replicating encrypted data sets
3.3.2 Separating duties of data owners and administrators

Question – For a particular HLQ you probably only want one key yet the level of granularity in an ACF2 rule for that HLQ might have many rules lines for different second level qualifiers and users.  How does that fit together?

Answer
The ACF2 compiled Dataset Profile records allow a site the flexibility to determine the dataset qualifiers granularity of datasets to be encrypted. The dataset access rules with many rule lines determine what type of access users have to the dataset, if the specific dataset is encrypted(based on the dataset profile record) the user would need to have access to the CSFKEYS resource for the key label that the dataset was encrypted with. In the following example datasets that start with qualifiers PROD.PAYROLL use the DFP Profile Record PAY which specifies key label PAYROLL.ENCRYPT.KEY and in order to unencrypt PROD.PAYROLL datasets users would need access to the CSFKEYS resource PAYROLL.ENCRYPT.KEY:

Complied Dataset Profile Record (SET PROFILE(DATASET) DIVISION(PROFILE))

$KEY(PROD)

 PAYROLL.- DFP(PAY)

 BANKING.- DFP(BANK)

Dataset DFP Profile Record (SET PROFILE(DATASET) DIV(DFP))
  DFP / PAY LAST CHANGED BY USER009 ON 04/30/18-12:39          
             DATAKEY(PAYROLL.ENCRYPT.KEY) RESOWNER()
  DFP / BANK LAST CHANGED BY USER009 ON 04/30/18-12:39         
            DATAKEY(BANKING.ENCRYPT.KEY) RESOWNER()

CSFKEYS resource rule for the key label

$KEY(PAYROLL) TYPE(SAF)                                              
  ENCRYPT.KEY UID(***USER001) ALLOW WHEN(CRITERIA(SMS(DSENCRYPTION)))