Re: File security

At 12:18 07/23/98 -0400, 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.
>
>I know I can restrict the commands that will access the files CPYF, DFU
>etc but there are more and more ways to get at the DATA and if you miss
>one (such as FTP) then you really don't have any security.  
>
>Also certain people (Programmers) will need to use some of these but not
>on production files.

I've just been wrestling with this also. You can certainly use adopted 
authority to access the database, but look at the security APIs. It will get 
pretty complicated if you try to adopt the program owner's authority. I 
rejected this because it doesn't seem to work very well with the package 
software that we have, but it may work for you. Here's what I've come up with 
so far:

Only grant update access to the objects that the user will actually be 
updating. We allow read access to virtually everything else (company policy), 
so there are plenty of spreadsheets, Access databases and crystal reports. 
That's a good use for ODBC.

For interactive users, remove the command line, only let them run the programs 
that they need to run in order to do their jobs, and make them use the menus. 
They're all LMTCPB(*YES).

Use exit programs to prevent updating of ANYTHING in a production library by 
ODBC or FTP unless the exact command has been registered as a permissible 
command (not really as difficult as it sounds, but I still have some work to do 
on that part). The preferred method of updating the data is via server programs 
on the AS/400.

Since FTP enforces the LMTCPB setting (ODBC doesn't), and since some file 
transfers require an AS/400 update job to be invoked, provide a special version 
of the CALL command that allows LMTCPB users to run it, in a library that has 
no public access, and is available only to a very special user profile that can 
do nothing but run little FTP transfer jobs. Command line FTP scripts work well 
for this. The login and password can be put in there without risk, because the 
user can't do anything but run the little jobs that he's authorized to run and 
other users can't get at his stuff either.

Oh yea, Level 40 for QSECURITY, passwords must be changed every 60 days, tear 
down the postit notes that are pasted on the side of the monitor, and 
deactivate device and user profile after 3 invalid login attempts (I still need 
to get the user profile part implemented, but all things in good time). A 
little missionary work is probably helpful too, so that users understand that 
you are protecting their jobs, not making their lives more difficult. A few 
months back our old AS/400 died. We were paper and pencil again for just a 
shade over two days. It's amazing how valuable that system got in such a short 
time.



Pete Hall
peteh@inwave.com 
http://www.inwave.com/~peteh/

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