I'd suggest that you build a new profile with authorities that are more "executive-appropriate." It protects him, protects IT and protects the business.
Steve Pitcher
iTech Solutions
Office: (203) 744-7854 Ext. 176
Mobile: (902) 301-0810
http://www.itechsol.com<
https://west.exch026.serverdata.net/owa/redir.aspx?C=JBgOIlc4Bi12Yk9kXxfyMfoRkA8OdpmbMNZqwQYygIUA02R-cmHUCA..&URL=http%3a%2f%2fwww.itechsol.com%2f>
http://www.iInTheCloud.com<
https://west.exch026.serverdata.net/owa/redir.aspx?C=QqlLNfAiLvPEecQsQ7mjdj0emj6eoUlob7-8WybvF00A02R-cmHUCA..&URL=http%3a%2f%2fwww.iInTheCloud.com>
________________________________
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of Patrik Schindler <poc@xxxxxxxxxx>
Sent: Tuesday, January 14, 2020 1:34:55 PM
To: Midrange Systems Technical Discussion
Subject: Re: Security question
Hello Bill,
Am 14.01.2020 um 17:05 schrieb Howie, Bill <BHowie@xxxxxxxxxxxxxxxx>:
The issue in my mind is that even if we set up a "silo" for him (basically, I think, just his own library) and don't change any of the other things, like limiting his capabilities, then we won't really be able to restrict him at all. Conversely, if we do limit his capabilities on his user profile, then he wouldn't be able to do certain things even within his own library.
Q: Why does he need to have a playground in his library in the first place?
This is a really uncommon scenario, since per default on IBM I as well as on UNIX, if you have a local user, he's got broad access to applications and configuration files (readonly, though). This is normal and for many applications, it's needed (if a program can't read it's config file, it cannot work as intended).
On i, files are usually created with *CHANGE for *PUBLIC per default.
Possible solutions:
• Do a security review on critical database files or just on library level, depending on granularity of desired access. Create group profile(s) for controlling access, add users to groups as required and change authorization to *CHANGE for the group profile on the *LIB or objects contained within. Then, change public permissions to *EXCLUDE. This is a harsh step with possible corner cases to overlook and have a certain amount of user complaints. Also, there could be sensitive data in "public" libraries such as QUSRSYS or QGPL, depending on former admin choices.
• Create a separate LPAR type *OPSYS, install a new instance of the OS, patches, basic configuration and whatnot. Transfer objects from his library onto the new install and delete the profile on the other server afterwards. Labour intensive but very secure. And there's license cost.
• Use an old machine for him exclusively, if there's something like that sitting in the basement. Possibly reinstall to clean everything up. Costs power and AC capacity.
• Tell him, it's not achievable without massive investment in time/money. Someone paying the expenses should decide what to do.
:wq! PoC
PGP-Key: DDD3 4ABF 6413 38DE -
https://www.pocnet.net/poc-key.asc
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
