[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: RACF protecting Job Classes
From:       Ed Gould <edgould1948 () COMCAST ! NET>
Date:       2008-09-30 5:24:04
Message-ID: 1C33794E-9381-49E0-A8FC-5B03F61213FD () comcast ! net
[Download RAW message or body]

On Sep 29, 2008, at 8:43 PM, Ted MacNEIL wrote:

>> I'm totally with you on the benefits of having Job naming
>> standards (and enforcing them with RACF), however, I don't see how
>> this relates to, or needs to be related to, the proetction of JES
>> Job classes, other than the fact you "could" use a combination of
>> Job name and JES Class for authorisation purposes?
>
> I agree.
> The only classes that should be protected are the 'specialty' classes.
> IE: Production, FIRECALL, etc.
>
> While job naming standards help, the controls should be implemented
> based on USERID.
>
> EG: A production job-scheduler can only submit production jobs.
> A special (not RACF SPECIAL) user can only SUBMIT FIRECALL jobs.
> And, that should be controlled by an auditted process.

  Yes I know that but that was *NOT* allowed security(RACF) stopped
that dead in the tracks. It was interesting system that was in place.
We had every back door covered (that we could come up with. What was
fun was the shenanigans  we had to do to get a production job
submitting another production job in another city (VIA NJE). I won't
talk about it too much but it took me a few days of being locked in a
room with another sysprog and the RACF person to figure out how to
enable this to be done cleanly (without embedded passwords which were
*NOT* allowed). The methodology was sneaky (and I cannot disclose
it ) and it worked without a fuss and to my knowledge (I still talk
with the people) after 20 years it is still working and no coding
changes. I even have comments in the code asking the person to call
me if any changes are made.
>
> USERIDs make more sense than jobnames.

Yes of course you are correct up to a point. The problem comes in
when you have several hundred jobs (maybe more I lost track after a
while) but as a secondary check there was a check to make sure it had
a valid production userid *and* that the jobname was valid. We were
deadly serious about the jobnames, for various reasons one was
operator awareness and the second was that various performance groups
were maintained for specific jobnames. Yes I know it wasn't perfect
but it made everyones job easier and it also alerted the operator if
a job ran in the wrong city. Since we had jobs floating around the
network there was a city indicator in the jobname and if a job ran in
an incorrect city bells went off. The jobflow was documented
extremely well (via simple diagram) and so operators had some idea
what was going on. They were also back up schedulers (kept track of
jobs) it also had an ego effect as they were part of the production
process. If a job ran out of sequence they knew about it first and
they made the calls.


>
> While jobnames make operational procedures easier.
> They may (or may not) make security easier.
> -
> Too busy driving to stop for gas!
[prev in list] [next in list] [prev in thread] [next in thread]