Lennie Dymoke-Bradshaw wrote: >My first reason for PE for data sets is that encryption >protects the data when it is accessed outside of its normal >environment (i.e. not via the data's normal RACF >environment).
Some other examples, in no particular order: anything IPL'ed on the system (or that could be) that isn't z/OS with its security manager fully operating (e.g. ZZSA, standalone dump, Linux raw track access mode, Linux zdsfs, z/VM, the Customized Offerings Driver), some of the stuff Innovation Data Processing can do for backups, or a misconfigured program properties table (NOPASS). RACF is excellent, but you cannot assume it'll always be fully on guard. And it's not just "outside the normal environment." For example, it's possible (and common) to mount remote NFS directories, with z/OS acting as the NFS client. RACF might still be enforcing certain security controls from its local z/OS point of view, but if the data are in the clear then the NFS server at the other end is a weak link. Anybody who gets access to the NFS server's drives/directories gets to read everything if it's unencrypted. Roughly speaking this is "loosely attached DASD," and z/OS supports that. Of course the whole point of NFS is often to share data in certain, hopefully controlled ways across systems (including z/OS to z/OS), and the network connections can be/should be encrypted if there's a hop from the machine boundary. But what happens when someone decides to mount an NFS directory, do their authorized processing using that form of disk storage (to "escape" a chargeback?), such as backing up something there...and then somebody else reads the data from the NFS server, or from its backup? That'd be bad. z/OS now supports cloud object storage via IBM Cloud Tape Connector for z/OS and/or IBM DS8000 Transparent Cloud Tiering with z/OS DFSMShsm. It's a good idea to encrypt there, too. The cloud object storage can be physically located anywhere: within your data center(s), outside, or some of both. There are "break glass" RACF storage administrator credentials available in many shops, but even those emergency credentials shouldn't be able to access most data. Auditors shouldn't have access to most data either, although RACF has had some improvements fairly recently to cater better to auditors, to allow them to perform their important jobs but not to exceed them. z/OS Data Set Encryption helps make sure the auditors stay within their lanes, too. We should be a little careful (once again) to distinguish between z/OS Data Set Encryption and Pervasive Encryption. They are related but distinct. In this thread we're mostly discussing z/OS Data Set Encryption. Yes, please, get z/OS Data Set Encryption turned on for everything it supports, and keep expanding it. (z/OS 2.4 will introduce z/OS Data Set Encryption support for yet more types, such as PDSEs.) Pervasive Encryption is broader, and yes, you should make progress in the broader journey, too. For example, Coupling Facility (CF) structure data encryption is another capability within Pervasive Encryption strategy/architecture. J.O.Skip Robinson wrote: >For almost no cost, you can steer your company away >from potentially disastrous litigation. Why would >any management refuse that offer? Relatedly, for almost no cost you can steer *yourself* (and other administrators and operators) away from (many or most) potentially disastrous data breach investigations and culpability. Do you even want the ability to be able to read somebody else's data, such as your customers'? Why would any IT professional want the personal risk of even being accused? -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE -------------------------------------------------------------------------------------------------------- E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
