Database security for BPCS CD & *ALLOBJ response & CEA icons

Hi,

Thanks for the reinforcement Clare - Yes, definitely there is NO
requirement to have *ALLOBJ on the SSA group profile even on old releases -
it is IT suicide to give that kind of authority away to so many users on
your system. You may as well put a sign up that says 'Welcome - Open Season
on our Database' (not to mention various other things you may want to keep
users out of on your system - remember that with Client Access and the
Operations Navigator GUI SQL interfaces a lot of other ways into the system
are now possible).

SSA DO NOT SUGGEST, REQUIRE NOR RECOMMEND THAT YOU PUT *ALLOBJ ON THE SSA
GROUP USER PROFILE.

You do not need to log on as the user profile SSA to restore anything on
your box - QSECOFR or any other *ALLOBJ profile works just fine for that
sort of task. When an object restores to the system it will be owned by the
original owner (SSA) as long as that user profile exists on the system. You
just need to have enough authority to be able to restore objects on the
system to make that work. If the user profile owning an object in a SAVF or
on a save tape does not exist on the system at the time of restore, then
the object becomes owned by QDFTOWN and gets PUBLIC *EXCLUDE authority in
which case someone with *ALLOBJ has to go out and change the owner of the
object. This was a problem on BPCS CD installations when the first tapes
went out about 7 or 8 years ago now because some of the objects were not
owned by SSA and were unfortunately saved to tape for delivery that way.
Issuing a command to grant SSA authority to the objects, and to change the
owner to SSA resolved that problem.

Programmers can individually be given more authority so that they can
create/copy objects etc. as needed in the development libraries but may
need to have a user profile setting of OWNER *GRPPRF and have an SSA group
on their profile so that any objects they create are properly owned by user
SSA. SSA doesn't need the *ALLOBJ authority in this case either.

But the BEST way to secure your data is to acquire the SSA BMRs that get
rid of the need for having the SSA Group Profile on your BPCS user profiles
and which keeps users out of anything owned by SSA except for *USE
authority to the programs. It is far more secure for your database, since
as a member of the SSA Group if SSA owns the database and the programs,
your BPCS users will have access to that data both in and out of BPCS (even
if they have no command line access) via things like Microsoft Access and
ODBC connections from a PC which don't require any command line authority
at all - just authority to the data that you are retrieving.

--------------------
To answer an early question : for  people on BPCS CD the BMRs to secure
BPCS files using User Profile *OWNER object compile commands are: 66713
(secures command line and ATTN key) and 62812 (redelivers the KRSO objects
with User Profile *OWNER). The latter ships with a README to explain how to
set up the increased database security.

For 6002-6100 this is BMR 51582 for the basic User Profile *OWNER. And an
additional BMR of 66713 is needed on 6002 for command line and ATTN key and
BMR 57230 for 6100 and 80 command line/ATTN key and BMR 62640 for the same
in 6004.

Any customer with Fat Client programs should be on BMR level 39659 to
acquire a copy of SQLTP2 with User Profile *OWNER to avoid authority issues
with that program, which does direct SQLs to the database for PC data
uploads. This BMR is good for all releases of BPCS that use Fat Client
(ALAUNCH).

---------------------
Regarding Danny's question about the CEA client icons - Yes there is a way
to secure this. The support center can provide you a list of objects to add
into the BPCS security files which you can then use in SYS600D to set up
your users to be authorized (or not) to those objects. For some reason they
were left out of priming data on the earlier releases. I believe this may
also be a FAQ on the OnePoint support website.

Thanks,
Genyphyr Novak
Senior Systems Software Engineer
SSA Global R&D





message: 2
date: Thu, 24 Feb 2005 09:35:53 -0000
from: "Clare Holtham" <Clare.Holtham@xxxxxxxxxxxxxx>
subject: Re: [BPCS-L] Fix that SSA *Allobj Security Exposure!

But Tay,

It works as shipped. In other words, the SSA Group Profile (which is not
shipped as *Allobj, or never was) owns all the BPCS objects, and all the
BPCS users are members of that group. *Allobj is a red herring and is not
required. In Europe we (when I was with SSA) have always created a
secondary
profile called SSALOAD which DOES have *Allobj, AND is a member of the SSA
group profile (which only needs *USER), and has owner *GRPPRF. This profile
can be used for installing BPCS, for installing PTFS, for creating new BPCS
environments, etc etc. It is because some consultants have used the SSA
group profile to do these jobs that it has been left on customer boxes with
*ALLOBJ.

cheers,

Clare

Clare Holtham
Director, Small Blue Ltd - Archiving for BPCS
Web: www.smallblue.co.uk
IBM Certified iSeries Systems Professional
Email: Clare.Holtham@xxxxxxxxxxxxxxx

----- Original Message -----
From: <tay@xxxxxxxxxxxxx>
To: "SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx>
Sent: Thursday, February 24, 2005 9:13 AM
Subject: Re: [BPCS-L] Fix that SSA *Allobj Security Exposure!


>
> I am using 4.5CD version BPCS, my idea are same as what SSA
suggest(Profile
> *ALLOBJ). Otherwise, you need to individual(or group) define BPCS files
> authority use right and also need to study the individual user run
programs
> related files and individual grant the authority right accordingly.
Imagine
> that if you have over hundred of users and each user have to run
> different(or same) programs(such as ORD500,ORD600, PUR500, INV500 and
etc)
> and something the user was quit and replace new user.
> It will make you crazy !!
>
> >From :Tay
>


message: 3
date: Thu, 24 Feb 2005 12:54:06 -0500
from: "Danny Monselise" <dannym@xxxxxxxxxxxxxxxx>
subject: [BPCS-L] CEA Client Server Ver 6.04

Is there a way to restrict users from some of the Icons of the Client?
Dan