Re: Set up a profile Question

>> We are  going to be audited and   I am assigned to clean up.   Our
>> operators  and programmers user profiles have special authority *ALLOBJ.
>> I noticed that IBM commands in QSYS authority have been changed.
>>
>>      1) Is it common for shops to changed IBM command authority?  I
>> noticed why operators can't run some commands because of this.
>>
>> 2) When setting up a operator or programmer profile does anyone  use
>> QSYSOPR as a group profile for Operators  or QPGMR  as a group profile for
>> Programmers?
>>
>> When I listed all  command authority  QSYSOPR & QPGMR  user profiles have
>> private authority to some IBM commands.
>>
>> Thanks,
>> Wanda



OOOH!  You've been letting your programmers play in the live files!   (:

We modify authority to IBM commands rarely... but we do it.  But we don't
change the as-shipped commands in QSYS; we have an alternate library that
appears higher in the system portion of the library list.  We duplicate
commands we want to change into our library, and make any changes on our
copy.  Since we're first in the library list, our version(s) get used.  Be
sure to restrict authority to this alternate system library to
look-but-don't-touch so miscreants can't slip a little something of their
own into the library.

IBM ships the systems with what it thinks is a good setup (and it is,
usually).  We tend to give our operators more control over things than IBM
thinks we should; our operators have authority (in some areas) closer to
programmer authority.

Neither programmers nor operators should have *ALLOBJ authority.  Operators
have *SAVRST (?) authority to let them save and restore things.

We use QPGMR as a group profile for programmers.  We let all of our
operators sign on as QSYSOPR.

Regarding private authority to IBM commands:  Check the IBM manuals for the
as-shipped defaults.  Compare your commands to the as-shipped and see what
was changed.

Once you know what's different from IBM's recommendations, then you can
evaluate what you need to run your business.  Auditors generally complain
about too much authority in the wrong hands.  But if you can make a
convincing case they'll accept your explanations.

One problem you may run into:  buy-in.  With all of the programmers and the
operators free to do whatever they please, cracking down on security will
be an uphill battle.  You MUST have buy-in from the top down:  President of
the company, and whatever executives are in the chain of command down to
you in Data Processing.

Arguments will include:  "Don't you trust us?"  "We won't be able to work."
"Everything will take longer."  "We won't be able to find bugs."  Each is
just a reaction to the turning of the screws.  Don't listen to them!  (:

It's not a matter of trust; it's a matter of the 'oops' factor.
Programmers will need a fully capable test environment (if you don't
already have one).

And you'll need a change management system to control the promotion of
programs and other objects to the live environment.  It might be a
fancy-shmancy commercial product, or a couple of home-built commands to
move the source and object to the live environment.  It's the -control-
that counts!

As we've been told at our office, don't look at an audit as something to
fear.  Look at it as an opportunity to show just how good you are, as the
auditors try to poke holes in your security.

--Paul E Musselman
PaulMmn@ix.netcom.com



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---