W dniu 12.04.2024 o 22:57, Tony Harminc pisze:
On Fri, 12 Apr 2024 at 12:22, Jousma, David <
[email protected]> wrote:

[...]
I personally am still having a hard time wrapping my head around the “real
benefit” of dataset encryption.   Everyone who has READ or more access to
the dataset, must also be permitted to the Key.   Those same people are
still able to copy/print/steal that data.    So who does that leave?
  Those that are not permitted to the dataset, and those who administer the
storage.    Those that don’t have access to the dataset aren’t going to get
the data, encrypted or not.   Those who administer the storage usually have
access to move/manage the installations data.    These are the people who
dataset encryption is protecting against.   That is a very small population
to go to this effort on.

I think this is analogous to "Why do airline pilots have to go through
security at the airport? After all, we trust them with our lives when
they're flying the plane."  And of course the answer is that the security
check is applied to everyone because it catches people who *look* like
airline pilots and are carrying a bomb. Or are real pilots under duress
because someone's got their child, etc. etc. etc.

Yes, storage administrators are a small population, but their credentials
can be compromised as much as anyone else's, and then you're not dealing
with rogue storage admins but with criminal (or goverment or whatever)
actors. And storage admins (or their credentials) may well make a better
target than those of application users because the admins have much broader
access to data.

To complement, storage admins are NOT the only group affected.
RACF is not working outside of z/OS system image, which could mean the following:
- volumes are accessible from other LPAR/system/RACF realm.
- DASD array was connected to another CPC. What CPC? In my server room? The CPC connected via DWDM, etc.

IMHO the worst assumption is "we have rules which are strictly followed". Starting from "RACF db cannot be read by anyone".

--
Radoslaw Skorupka
Lodz, Poland

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to