User profiles are assigned a group on our iSeries, and the group has object authority to the data files. What data they can actually see and update is controlled by the application (JDE shop), limited by menu travel and other security parameters built into the system. My issue is with Client Access. The users have CA to do downloads of report information they have created (we translate it into a downloadable file). But while in CA, they can actually download any file that the group has authority to. If someone knows the library/filename of a payroll file they can download it. How can I secure our sensitive data while the users are in CA? Is there anyway I can revoke their authority while using CA? Is there a way I can only permit them to access one library where we could store downloadable files only?
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
Dig Deeper on iSeries system and application security
Related Q&A from Carol Woodbury
Before changing password levels and upgrading operating systems on the AS/400, ensure the clients connecting to the NetServer do not need the old ... Continue Reading
Look in the audit journal (QAUDJRN) on the AS/400 for an authority failure message with the name of the library as the object name. Use the ... Continue Reading
On AS/400, the journal type AF subtype K, shows that a user profile lacks the special authority required by the function attempting to run. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.