MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » May 2014

RE: i5 Security info and training



fixed

"You know what really helps? A good change management package. One that
knows, and can be configured to set up things like: programs that need to
adopt authority, programs and data that have special authorization lists and
stuff set up on them."

I don't know about Implementer, but with Aldon, one defines on the
development machine the default ownership of objects. On the target
machine(s), the only thing necessary for the customer to do is log on as
QSECOFR and run one command. That gives the user profile ALDONCMS all the
authority necessary to execute the deployment jobs.

Paul Nelson
Cell 708-670-6978
Office 409-267-4027
nelsonp@xxxxxxxxxxxxx


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
rob@xxxxxxxxx
Sent: Thursday, May 01, 2014 1:25 PM
To: Midrange Systems Technical Discussion
Subject: RE: i5 Security info and training

Only one of our developers has a second account that has a high level of
security. And he pretty much reserves it only for helping us run Mimix.
I kept hearing this whining "but what about that emergency middle of the
night call that needs it?". Situation is, it hasn't happened in over 10
years. Sure, there have been late calls, but none, zippo, that just had
to have qsecofr type access.

Honestly, it used to frustrate me to no end that vendors required qsecofr
to install their product. I guess it just works.
OTOH, keep your guard up. We had a vendor that had a program with qsecofr
adopted authority. One line: CALL QCMD. Apparently it was their back
door to talk users through some stuff remotely without having to file a
100 page exception report with the customers security officer on why they
needed qsecofr.
We no longer do business with them.

I sincerely believe that many vendors really tried to get their installs
working as other than QSECOFR, but after this failure, and that failure,
just gave up.
Some of their installs I wonder how they ever get through them.
Hopefully in this age of virtualization they will try their installs on
clean lpars. And not the same old lpar where their owning profile already
existed or whatever.

If your developers keep needing qsecofr access they're doing it wrong.
That's like having first aid equipment down at the bottom of the ski slope
not "just in case" but "we're going to use it at the end of every run".

I realize it get's trickier when you have interfaces between disparate
vendor applications. Heck we got through this and we used to have ERP by
one vendor and accounting by another.

You know what really helps? A good change management package. One that
knows, and can be configured to set up things like: programs that need to
adopt authority, programs and data that have special authorization lists
and stuff set up on them.


Rob Berendt





Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact