RE: BPCS Security Concepts

Martha:

As I read yesterday, and tested successfully today on Full Client/Server,
you may limit accesses within a program by using SYS603 - Security Group
Maintenance.  Please read the post from yesterday, it was very insightful.

Cheers.

> -----Original Message-----
> From: uucp@Uucp1.mcs.net [mailto:uucp@Uucp1.mcs.net]On Behalf Of Martha
> Bayer
> Sent: Tuesday, July 20, 1999 6:37 AM
> To: 'BPCS-L@midrange.com'
> Subject: RE: BPCS Security Concepts
>
>
> Based on the responses so far, I think the problems I have with update vs.
> inquiry security must be unique due to the fact that we are client/server.
> We are able to limit access by program with no problem.  So we don't allow
> people access to month-end programs, and we can limit their access to
> programs that are inquiry only, like INV300 and CST300 without
> any problem.
> Our problem happens on things like the vendor master, customer  master, or
> item master.  We can't give people access to just display the information.
> There is a file command in the menu bar at the top of the window
> that allows
> them to choose between create, copy, revise, delete, and display
> functions.
> We cannot limit which function they choose.
>
>
> Martha Bayer
> Badger Mining Corporation
> 920-361-2388
> mbayer@badgerminingcorp.com
>
>
>       -----Original Message-----
>       From:   MacWheel99@aol.com [SMTP:MacWheel99@aol.com]
>       Sent:   Monday, July 19, 1999 3:21 PM
>       To:     BPCS-L@midrange.com
>       Subject:        Re: BPCS Security Concepts
>
>       > Subj:  RE: BPCS Security - More information
>       >  From:        mbayer@badgerminingcorp.com (Martha Bayer)
>
>       >  We're on 6.0.02 CS AS/400.  We were told by SSA consultants that
> update vs.
>       >  inquiry security may be available in version 7.0.  I wonder how
> many others
>       >  think this is an important feature?  Has any one found a way
> around it?
>
>       Update vs. Inquiry security is available in version 405 CD - did it
> go away
>       in V6 or am I not understanding something?
>
>       My understanding of this is that INQUIRY is where people can view
> data via
>       INV300 SFC350 CST300 etc. while update means people can run jobs
> that update
>       the BPCS data base such as ORD500 JIT600 etc.
>
>       One headache with 405 CD security is the group security is an all or
> nothing
>       everyone same rules, so to offer different IBM rules to some user
> sub-groups,
>       we have to risk a performance hit by having secondary user groups.
>
>       Another headache is that we have users who have had to be granted
> command
>       line authority, and been shown how to do some support tunctions for
> narrow
>       reasons, then used their know-how & access in ways I consider quite
>       dangerous, like DFU vs. BPCS file contents.
>
>       > Subj:  Re: BPCS Security - More information
>       >  From:        mkamara@krupsusa.com
>       >
>       >   We're on 6.0.04 MM,  AS/400 720 V4R3 and new to BPCS.  We are a
>       >  wholesale/distribution company in the US.  I have set up basic
> security
>       >  given access to the modules based on departments.  I will like to
> have a
>       >  tighter control without affecting performance where some users
> will update
>       >  capabilities and others have inquiry only.
>
>       Check BPCS Documentation - there is an outline of how the security
> works.
>
>       Whatever consultant helped you get setup might have additional
>       reccommendations on this topic.  Take a look at how work station
> defaults are
>       changed & if you want end users doing that.  Who should be making
> changes to
>       BPCS User Menus?  Does every module have a manager who decides who
> all should
>       have what kind of access to which areas?  Usually the department
> head says
>       anyone can inquire into our stuff but only people in our department
> ought to
>       be changing the contents & here is a list of users in our
> department.  Some
>       data is more sensitive than others, such as profit margins.  Do you
> want or
>       need people to be able to manipulate / view the contents of other
> people's
>       reports?
>
>       Check BPCS_L archives for remarks I made on BPCS Security several
> months ago.
>
>       The things that were the major conceptual stumbling blocks for my
> project
>       team personnel regarding comprehending security issues.
>
>       1. The SFC600 Module List works on basis of OPPOSITES.
>
>       Some people we have coded NO to all modules, then down below listed
> just the
>       programs we want them to be able to run, such as some inquiries &
> pop-up
>       menus.
>
>       These people are coded N in the list of modules, so that the
> programs listed
>       below are what are YES for them.
>
>       Some people we want them to be able to do just about anything in a
> particular
>       module, such as SFC & JIT, but we say NO to end-of-month stuff like
> SFC905 &
>       JIT900.
>
>       Those folks are coded Y for the overall modules - so that the stuff
> down
>       below on that module are the NO exceptions we do not want them to
> get into
>       for whatever reason.
>
>       2. Anyone can make a mistake & take a wrong menu option & get into
> trouble -
>       for example we had some people taking some end-of-month options &
> trying to
>       exit & in their frustration, causing unwanted updates.
>
>       As the block of opposites grows, and as people's security needs to
> be
>       changed, we want to keep the picture easy to read, so we organize
> the stuff
>       generally A to Z left to right & 1 to 10 top to bottom.
>
>       3. A query can have any name, but to run it from BPCS Menu, it needs
> to be
>       named logically within the BPCS naming conventions, avoid risk of
> conflict
>       with future PTF, and fit within the security rules.  Our
> modifications &
>       queries use the 3 letter prefix of ORD INV etc. but by the 6th
> character have
>       shifted alphabetical.  We have some power users who create queries,
> create
>       the CL to run them, and put the CL on BPCS User Menus.  This
> capability
>       requires command line authority, right SYS stuff for the menus, IBM
>       Programmer Authority to compile the CL, and support to cross library
> lists
>       when copying a query between 2 different environments.
>
>       4. We can muck with additional rules on how BPCS Security functions,
> and
>       change IBM commands, but let's not add to the complexity of Security
> if we do
>       not want to make this a full time job.
>
>       On IBM Security - you might want to make the first place people go =
> the BPCS
>       Menu for their environment, then the second place where they go,
> when they F3
>       out of BPCS to be *SIGNOFF, so only people who know how with either
> command
>       line authority, or other stuff, can get into OS/400 menus.
>
>       We are in constant struggle of WHY DOES THIS PERSON NEED COMMAND
> LINE
>       AUTHORITY?  The main reason is they were taught how to do something
> by
>       someone who did not think computer security was especially
> important, and are
>       now more comfortable navigating via that method than the vanilla
> menus.
>
>       We have created CL for BPCS User Menu to do many of the things that
> people
>       said were the reasons why they needed access to IBM Menus.
>
>       I hope this helps
>
>       Al Macintyre
>       +---
>       | This is the BPCS Users Mailing List!
>       | To submit a new message, send your mail to BPCS-L@midrange.com.
>       | To subscribe to this list send email to BPCS-L-SUB@midrange.com.
>       | To unsubscribe from this list send email to
> BPCS-L-UNSUB@midrange.com.
>       | Questions should be directed to the list owner: dasmussen@aol.com
>       +---
> +---
> | This is the BPCS Users Mailing List!
> | To submit a new message, send your mail to BPCS-L@midrange.com.
> | To subscribe to this list send email to BPCS-L-SUB@midrange.com.
> | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: dasmussen@aol.com
> +---
>

+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---