I think Vern's question on " Do you have a development LPAR or machine, or is everything done on the production server?" is the key here Gad.
If you have multiple LPARS or servers, then limiting the need to debug/change in production should be relatively easy. If your development team do everything in production it's a lot harder.
Some form of change management would help in the first scenario, along with the suggestions that Rob made around the use of authorization lists for objects and programs that limit the majority of access to "application only". The use of logging software on accounts with some level of access to allow troubleshooting then gives you a fairly high degree of confidence that developers or support staff are only doing what they should be.
If you only have a single environment, then it's a little more difficult as its hard to both restrict access and let the team do their jobs but with use of separate profiles and authorization lists over "production" objects as opposed to "development" ones, along with logging of those profiles with access to allow promotion of code of troubleshooting can help give some level of comfort.
Not all change management solutions have a high cost either, and can really save time and effort in the long term.
Cheers,
Karl.
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Rob Berendt
Sent: Friday, October 2, 2020 9:43 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: File protection basics
In general our developers do not have *ALLOBJ on production.
I realize that full blown change management systems can be pricey for many shops. To the point that there's only a small subset of our systems as licensed endpoints. The others we have to manually distribute to.
We have an automated system which detects if someone changed any file (through journal scraping) outside of a program. It then automatically generates an entry in our Domino based workflow and it all goes through an audit workflow.
Most files are secured by one authorization list. Most programs are secured by another. We're working on tightening this up even further by adopting an "Application Access Only" model but other projects keep barging in.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.com
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Charles Wilt
Sent: Friday, October 2, 2020 12:33 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: File protection basics
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
While Vern has some good ideas, and I agree that no developer should
regularly be able to make changes in production.. sometimes developer's
need access to production.
In that case, there should be some sort of documented process to allow them
to gain elevated access...preferably one that then logs everything they do
for review.
You could roll your own, but there are third party apps to facilitate this.
https://www.helpsystems.com/products/identification-and-access-management-software-ibm-i
Charles
On Fri, Oct 2, 2020 at 9:02 AM Gad Miron <gadmiron@xxxxxxxxx> wrote:
And while we're grappling with the issue..
How do I strip Programers on our Prod machine of their (*ALLOBJ) Authority
and still let them debug and fix any/all PGMs/Files
TIA
Gad
Then I thought why not create a user profile with no special authorities
and see how it affects me when I use it.
</snip>
That's not a bad plan. Be sure to use that as your primary, until you run
into a road block you have to immediately address and just have to use your
existing profile.
It also might be a good idea to contact a power user you have a good
relationship with (buying a doughnut is a good idea on our side of the
pond) and trying that with them also.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.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
midrange.com
