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.
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?
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))
Dataset DFP Profile Record (SET PROFILE(DATASET) DIV(DFP))
DFP / PAY LAST CHANGED BY USER009 ON 04/30/18-12:39
DFP / BANK LAST CHANGED BY USER009 ON 04/30/18-12:39
CSFKEYS resource rule for the key label
ENCRYPT.KEY UID(***USER001) ALLOW WHEN(CRITERIA(SMS(DSENCRYPTION)))