We encrypt all our host data without worrying about z/OS by using SKLM on our DS8K SAN.
I'm told this means all data that the host can access is encrypted at rest and is transparent to the host. On Mon, Apr 1, 2019, 3:56 AM Steve Beaver <st...@stevebeaver.com> wrote: > I think someone is going way overboard > > Sent from my iPhone > > Sorry for the finger checks > > > On Mar 31, 2019, at 09:50, Phil Smith III <li...@akphs.com> wrote: > > > > Matthew Donald wrote: > > > >> I'm looking into pervasive encryption and I have a question about batch > > > >> temp files that I have been unable by googling. > > > >> > > > >> In order to have SMS encrypt a dataset, the dataset must be in extended > > > >> format, which I believe is specified in the dataclass. My question is: > do > > > >> batch temporary datasets support extended format? Can they be encrypted > > > >> using pervasiv encryption? > > > > > > > > Not clear to me what the problem is that you're trying to solve by > encrypting temporary data sets. Remember what protection the whole-file > encrypt provides: > > > > 1) Data is encrypted between the array and the CEC (the support was > added for the financial industry, which does worry about such things, > especially with remote DASD). > > > > 2) DFSMS admins can manipulate encrypted data sets without requiring the > ability to decrypt them. Presumably this doesn't apply, since an admin > won't be doing anything admin-ish with temporary data sets (moving, > copying, etc.). > > > > > > > > Beyond those, all it's really adding is a second SAF resource on those > data sets (well, really on the key, but since you can't even open the data > set without that resource permission, same diff). So if the data sets are > already locked down properly, all you're really doing is protecting the > data on the wire between the array and the CPU. If that's a requirement, > great; otherwise, you're not achieving anything.* > > > > > > > > ...phsiii > > > > > > > > * Unless, of course, your auditors don't understand and are asking for > this, in which case what you're achieving is getting the auditors to shut > up! > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
