Re: File security

John,

John Hall wrote:

> We are looking for a way to secure our files from ODBC, DFU, File
> Transfer  etc etc
>
> What I would like to do is restrict user access to the files to using
> programs only.  I would like to give the programs access to the files
> and not the user.  We have been a S36 shop and are converting over and
> as part of this conversion would like to secure all production files
> from unauthorized access.  The S36 setup is really poor security.

There are a couple of routes that you can go.  I like and
use the adopted authority method that restricts users direct
access to the data, but I have seen some implementations of
that scheme that left a bit to be
desired.  The basic steps to use adopted authority sum up to
be:

    1)Specifically exclude users from any data rights,
    2)Grant them *USE rights to selected programs
    3)Use adopted authority on the program to grant the
users authority to the data.

Here is a short list of pitfalls to avoid;

A) Don't have one profile own everything on your system.
Separate ownership by applications (or some other logical
business delineation).  This provides for more granularity
in your security design, and prevents
having one profile own too many objects.

B) Don't have the same profile own the data and the
'adopting' programs.  If you do then users will effectively
have '*ALL' authority to the entire application.  Better to
have one profile own the all data and all 'un-adopted'
program objects.  The grant  a second profile (the adoptor)
appropriate (*USE or *CHANGE) rights to the data.  Now when
users call the adopting program they have *USE, or at the
most *CHANGE rights to the data rather than *ALL.

C) Neither of these profiles should have passwords.  Their
only purpose is to own objects.

D) The profiles should not be group profiles for any system
user.  You don't want users to inherit *ALL authority to any
of these objects.

E)To restrict access to entire applications, secure at the
library level.  It's fast, it's easy to do (and undo if you
must), and it requires little long term maintenance.  I'm
convinced that overall AS/400 security could improve by a
phenominal percentage if System Administrators would just
lock library authority down.  *PUBLIC *CHANGE access to a
library seems awfully excessive, but you'd be surprised at
the number of shops I've run across that are configured this
way.

The above scheme works well if your users don't expect to
get directly at the data using some AS/400 or PC query tool.
If users do use query or other report writing tools, they
will need a front end built for them that provides them
access to the specific data that they expect to query.

Another option that can used instead of, or in conjunction
with, the ideas layed out above is to use exit point
programs to secure ODBC, FTP, RMTCMD, etc. Exit point
programs can control who is allowed to read, update, and
even delete files that are accessed from remote systems. 
There are exit points for Client Access servers (yes, there
is even one now for non-IBM ODBC drivers!) as well as for
DDM and TCP/IP connections.  You can certainly write your
own exit programs, but if you'd just like to buy a solution,
our company sells an exit point package that can handle this
for you.

jte


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---