× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Laurence has not told use what version/release, nor TR level, but IBM has
introduced several new methods of blocking *ALLOBJ users from seeing data.
I'm guessing specifically for this reason. But, it takes someone with the
knowhow, and full authority on the system to set it up. If it were me, I'd
have a third party set it up, document the daylights out of it, and have
them go away.

--
Jim Oberholtzer
Agile Technology Architects

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Charles Wilt
Sent: Friday, June 26, 2020 11:20 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Recommendation for IBMi privileges for an outsourcer to support
an IBMi environment

Agree with this...

But having said that, now-a-days, you really need to understand who's doing
what. Doesn't matter if they are internal or external.

Rob's suggestions are good, I'd consider one of the authority broker
products, lots of tracking built in.

Lastly, I seem to recall there's a way to deny access to objects even to
someone with *ALLOBJ authority. I believe that it requires that the user
have *ALLOBJ access via a group profile and that their actual profile be
explicitly denied access to individual objects.

Charles

On Fri, Jun 26, 2020 at 4:41 AM <CarlN@xxxxxxxxx> wrote:

I believe the what you are being told is true. They will need QSECOFR
to manage the system.

That being said, when selecting a "partner", yes you are selecting a
partner, choose wisely, because you are giving them the keys to the
kingdom.
You must trust them completely. If you don't, then you are choosing
the wrong partner.
Possibly have them sign an nondisclosure agreement.





Thanks,



From: "Laurence Chiu" <lchiu7@xxxxxxxxx>
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxxxxxxxx>
Date: 06/25/2020 10:24 PM
Subject: Recommendation for IBMi privileges for an outsourcer to
support an IBMi environment
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx>



We are about to embark on an outsourcing agreement with a supplier to
support our IBMi environment.

We would prefer that they don't have the ability to look at our
production data. The following security profiles were recommended

*IOSYSCFG, *JOBCTL, *SAVSYS, *SERVICE and *SPLCTL.

However they say they also need QSECOFR to be able install software,
apply PTF's etc. There is a view (untested) that somebody with this
privilege could run any application on the IBMi environment and view
sensitive data.
Even if we had menus in front with internal application security, they
could just dump the data. We don't think they would do that but our
security folks don't like to have security holes like this.

For those organizations who are using outsourcers to manage their
environments, are there some best practices (even good practices) that
you could recommend that would ameliorate that risk? I think to
install the OS you would need QSECOFR but what other reasons would you
need it?

Thanks
--
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@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com



--
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@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
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@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.