RE: Documenting / Managing iSeries security

We are using BPCS security.  But as anyone knows who doesn't keep their 
head buried in the sand, the days of relying on 5250 menu based security 
for data protection are long past. 
We're not ready for 'application only access'.  Very little data gets 
downloaded, but we do use a lot of queries.

You use group profiles to secure by application:  A/P, etc.
We use group profiles to secure by company.  Too much of the applications 
interface to do it here by application.  Although we are using a separate 
accounting package and that has it's own group profiles, etc.

Yes, trying to figure out what authorization lists to put their 
replacement in when someone leaves is a trick.  Often, instead of deleting 
someone, we'll just disable them.  (And, no, that doesn't mean we use Nick 
the Kneebreaker instead of Mack the Knife.)  We could then determine what 
authorization lists this person is a member of and add the new person 
likewise.

Trying to decide out of the hundreds of BPCS files to put in a particular 
group would be a real chore.  For example, what files will the group 
GRPALLAP have access to might involve a lot of trial and terror.  Although 
I am beginning to understand what you are saying.  Everything in CLIDIVF 
may be owned by SSA36 but GRPALLAP might have update access to AVM (the 
vendor master) and a selection of other files.  Then when the person doing 
that job gets replaced then some new person gets added to that group 
profile.  But they would also need the supplemental group of SSA to use 
the BPCS programs, etc.  And as much as I hate supplemental groups that 
ain't happening.  I suppose the programs for BPCS could be *PUBLIC *USE 
without the earth coming to an end.  Unless they do something stupid like 
one package we used to have.  That package had a program owned by QSECOFR 
that only did a CALL QUSCMDLN.



Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





CWilt@xxxxxxxxxxxx 
Sent by: security400-bounces@xxxxxxxxxxxx
05/27/2004 03:03 PM
Please respond to
Security Administration on the AS400 / iSeries  <security400@xxxxxxxxxxxx>


To
security400@xxxxxxxxxxxx
cc

Subject
RE: [Security400] Documenting / Managing iSeries security






Rob,

Ok I can see where you are coming from.  I assume you are using BPCS
security to prevent users from doing stuff they are not authorized to do.
Thus, group profiles might be of little use.  Unless the users that use
single libraries or multiple libraries are fixed.  What I mean is that a
user in a given role (AP for instance) deals with a given set of 
companies.
If that user were to leave then his/her replacement would deal with the 
same
set of companies.

For example, say your AP people work across all companies, you could have 
a
GRPALLCMPYS.  Users that only access one company would be in GRPxxxxxxx
where the xxxxxx is something appropriate.

Finally if you could identify subsets of users that need access to given
subsets of company (say order entry for three companies are handled by the
same set of users) you could have other groups for those sets.  This would
be beneficial even if the subset of users is only one user.

Granted, the group profiles aren't as useful in your case since you've got 
a
small set of authorization lists being used.  Still I think there'd be
benefits to having the group profiles on the authorization list as opposed
to individual users.  If nothing else, to add a new user you'd simply copy
an existing and the user would have appropriate authority with no extra 
work
needed.


Charles




> -----Original Message-----
> From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
> Sent: Thursday, May 27, 2004 2:29 PM
> To: Security Administration on the AS400 / iSeries
> Subject: RE: [Security400] Documenting / Managing iSeries security
> 
> 
> Here's where we are coming from:
> http://www.dekko.com/GroupDekko.nsf/Companies
> Each of these companies have their own data library, program 
> library and 
> query library.  For example:
> CLIDIVF, CLIDIVO, CLIDIVQ
> DETDIVF, DETDIVO, DETDIVQ
> MCIDIVF, MCIDIVO, MCIDIVQ
> and so on..
> Each library has their own authorization list.
> Some employees actually do work for more than one company.
> Need further explanation?  I don't want to flood you with 
> information when 
> that might be enough to explain it.
> 
> We actually have so many files that it is impossible for SSA 
> to own all of 
> them.  There is a limit to how many objects one user may own. 
>  Actually 
> that was the straw that got us securing each companies data 
> file library 
> better.
_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400) 
mailing list
To post a message email: Security400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.