Re: BPCS Security Concepts

We modified all BPCS maintenance programs so that only Opt 5 shows on the screen
this is the default mode.  We then set up a ZCC table by user and program that
then allows particular user to have access to other options eg. 010205, will 
give
a user access to 1-create ,2 -Change, 5- Display.

Jon Le Roi wrote:

> I do not think this is unique to the cliet server version nor just to BPCS.
> MAPICS, Pansophic and BPCS all have a program that allows create, delete,
> update and display of the master records for things like customers, vendors
> and items. Every company I have worked for has written a unique version of
> these programs to limit it to view only; a simple process but silly that it
> is not provided as part of the package.
>
> Regards,
> Jon Le Roi
>
> At 08:36 AM 7/20/99 -0500, you wrote:
> >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
> +---



+---
| 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
+---