|
Your situation is one that many iSeries shops face -- how do users have
sufficient authority to perform their jobs while coming through a
green-screen menu yet prevent them from downloading files you do not want
them to download. First, realize that this issue exists in more forms than
just iSeries Access for Windows (AKA Client Access). All Windows clients
come with an embedded FTP client, ODBC clients can be downloaded from the
Internet, etc.
The way to secure your sensitive files is to use object level security. If
you think of the Payroll application, only a handful of users should have
access to that data. Place *PUBLIC(*EXCLUDE) on the payroll application's
library(s), grant the users or payroll group authority to the library and
you have locked out users that have no business need to access the payroll
application.
Some people use exit programs to accomplish what you have described. Some
of the exit program solutions allow you to swap or change the user the
process is running under. The thought is that you swap to a profile that
has "less" or more restrictive access to the system libraries. I don't care
for that approach. First, that requires you to add a private authority to
all system libraries (and directories) for this "swapped to" user. Second,
it reduces audit ability because all file downloads and any other activity
that takes place through the network connection are now run as this "swapped
to" user. Therefore, all audit journal entries will be logged as the
"swapped to" user and not the actual user making the request. If you are
going to use an exit program solution, I prefer one that allows you to
control access via the object -- in other words, the software examines the
request and determines whether it contains an object (e.g., a library) that
you have prohibited from being used on this type of request (e.g., a
download.)
However, my recommendation is to use object level security if at all
possible. That may require altering the characteristics of the application,
to have it adopt authority so that you can remove the users' or groups'
explicit authority to the object. This is possible -- even with JDEdwards.
Call their help desk and ask for their instructions on securing their
application. ==================================
MORE INFORMATION ON THIS TOPIC
==================================
The Best Web Links: tips, tutorials and more.
Search400's targeted search engine: Get relevant information on security.
Ask your systems management questions--or help out your peers by answering them--in our live discussion forums.
Check out this Search400.com Featured Topic: Top ten security tips
|