No, and is one of the "problems or challenges" if you will with dataset encryption. An enterprise goes to the significan effort to do data at rest encryption, yet anyone that has legitimate READ access to the data can be sloppy, and re-create the exposure just by copying the data to another name. It would have been nice if there were some additional controls built-in that would enforce some sort of encryption "inheritance" requirements when using standard copy utilities that would disallow a copy from encrypted to unencrypted.
At my shop, and probably true at many others, the various application teams have READ access to much of the production data to be able to diagnose problems with their applications. Sadly this leads to laziness on their part, copying prod data to test, to do their application testing. The answer is to put up a wall, and not allow that. We've been trying to get to that point, but the PHB's of those area's dig their heels in. We don’t have a good answer yet. We are not yet doing dataset encryption as our IS department is looking at KMF infrastructure like EKMF or the like. The administration overhead of managing the plethora of keys is going increase exponentially, and I'm afraid that in the process, there will be a "key mishap", and whatever data was encrypted with that key will be lost forever. That the balance that needs to be struck between "one key covering everything", or "one key per dataset", or "one per application", etc. _____________________________________________________________________________________________________ Dave Jousma AVP | Manager, Systems Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Mark Jacobs Sent: Friday, June 28, 2019 7:39 AM To: [email protected] Subject: Dataset encryption question **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Outside of using dataset conditional access rules is there anyway to prevent someone from copying encrypted dataset HLQ1.data to HLQ2.data? They have access rights to both HLQ's and the encryption key. Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://protect2.fireeye.com/url?k=3440c8f7-681c3cf8-3440e26f-0cc47a33347c-879d4a15700b3947&u=https://api.protonmail.ch/pks/lookup?op=get&[email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
