Re: [Security400] Authority annoyances, continued...

["John Earl" <johnearl@xxxxxxxxxxxxxxxxxx>]

Buck,

> Has anybody here done any of these things?  Perhaps that's an answer
better
> kept private...

Yes - a couple of these.

> Securing the files *EXCLUDE and using adopted authority to allow
> green-screen programs access.  This functionally eliminates non
green-screen
> access, which may be too tight.

We use this approach on our packages.  If someone needs direct access
to data from, say, ODBC, that access would be specifically engineered.
Contrast this to the default of "everyone get's access until we get a
problem that makes us want to lock something up" approach that most
/400 shops default to.

> Triggers.  Some user profiles might be able to read, but not allowed
to
> update.  Some users might be allowed to update but not all fields!

We do not use this - but I like the theory.

> More logical files.  Use a subset of columns and allow users
read/write
> access to the fields they are authorized to.

I've used this in the past - but this can be tough on performance, and
even tougher to manage.   I like this option least of all.


> Exit programs.  There are packages that will help here.
Yup - we have a package.  This is one of the ways that we engineer
selected access to data while using the *EXCLUDE approach you outlined
above.  it's easy to make exit programs deny all access.  It is a more
difficult thing to build exit programs that reliably allow access to
selected people in selected circumstances.  That's what I think we do
well.

> Custom written I/O modules.  Allow only these modules access.  Let
the
> green-screen programs call them and publish the interface so other
> programmers have access.  Can double up as triggers if you define
the
> parameter list right.

This is much like triggers.  I like this approach - it has interesting
promise for future applications.

> Data warehouse.  Have a process (trigger?) copy production data into
the
> "public" data warehouse.  If PC users need to change data, the
changes go in
> a transaction file and get a custom process to update production
from there.

I assume that this would be combined with either a *EXCLUDE approach
or an Exit Program approach, or both.  I suppose this would work, but
once you have implemented the other approaches, I'm not sure if it is
worth the extra cost.


JMHO,

jte

--
John Earl - VP & CTO
The Powertech Group
253-872-7788
johnearl@powertechgroup.com
www.powertechgroup.com