As usual, some pc based person only thinks of the way their world works.
I have been though multiple audits at multiple companies where they accepted that: 1) System programmers had two logons. One "normal" and one "higher". The "normal" userid still had some privileged access, but nothing like the "higher" userid which had basically unlimited access. 2) Additional audit trails were created for the "higher" userid. Both that fact that they logged on and what they did. 3) The systems programmers split their libraries and work processes so that they only used the "higher" userid when really necessary.
The fact was that we had to negotiate what was considered "daily" work and what was considered "special" work. This took a bit of time and was refined over time. A lot of the decisions revolved around READ-ONLY vs UPDATE rights on many of the libraries.
Also, the security rules were different depending on which LPAR or Guest we were logged on to. Our normal userid could do everything on the systems programmer test LPAR. On the Development LPAR, it could do most everything. Our real limits were on the production LPARs.
That being said, I think you are going to have to also go down the same road where you split your work processes and libraries into normal daily stuff and "special" stuff. It will take you a while to get into the mindset, but in the end you will find that it worth it. It will take a lot of negotiating, but it
Since the first place where I was forced into this arrangement, I have implemented it at other locations. Yes, the systems programmers thought it was terrible at first, but once they got used to it, they realized that it sometimes saved their bacon. (Think "SHUTDOWN" under VM!) They had to learn to think: Which hat am I wearing right now? A limited systems programmer hat or the mainframe "god" hat.
If you get your workloads split correctly, you may not need to use a vaulted userid as often.
Tony Thigpen James Peddycord wrote on 11/22/2016 11:52 AM:
NTAC:3NS-20 Our company is undergoing a project to 'protect privileged access' by using a password vaulting product. We have been doing this for quite some time for applications teams who require higher levels of access to production datasets for problem resolution, installs, etc. The way it works is that a pool of logonids is created, along with an AD group that allows the appropriate applications folks to be able to 'check out' one of these pooled logonids for 24 hours via a web interface. The web interface uses the users lan password plus their secure key passcode and phrase to validate their identity. The project has now included Windows and Unix server admins, but instead of a pooled logonid these users have separate logonids with admin access and they 'check out' their own individual administrator logonid. Now the project has moved into the mainframe systems programmer space. So far we have used the 'privileges' on the logonid records as defined by our security product to limit this vaulting. Users with 'security' access must check out logonids from the vault. Users with the non-cncl privilege are next. During project discussions it has been brought up that the systems programmers, with their access to SYS1 datasets and operator commands, are privileged users by nature, and that eventually they are going to want to vault this access. We (the systems programmers) are strongly against this. It looks like at some point we will lose our battle and our access to the mainframe will be vaulted, meaning my entire team will need to check a logonid out of the password vault every morning before starting work. Our main argument now is that we do not want these logonids to be generic, pooled logonids, we want them to be basically the same as our own logonids so that we can see who did what by using the mainframe's built in logging (SMF data, ISPF stats, etc...). My questions are, are other companies using password vaulting or other multi-level authentication for mainframe systems programmer access? What else could we use in our argument against using generic, pooled logonids? Thanks in advance! Jim ---------------------------------------------------------------------- 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
