We are currently in the process of reviewing our entire system's security. One of the conundrums we've come across is how to prevent user profiles from gaining "unofficial" access to data (i.e. through a system tool such as DFU or DBU) while still maintaining "official" access (i.e. production end-user applications) to the data they need to update.
The way our security is set up, the user profiles belong to groups, and those groups have *CHANGE access to the libraries and the data within them (through private auth or AUTLs). So, from OS/400's perspective, it does not distinguish between the two types of access, and thus permits both.
Is there a way that we can set up our system that would allow us to distinguish between these two types of access, and thus secure them differently?
OS/400 does not provide "situational" security or access controls. My favorite, and I believe most robust way, to fix this problem is to change the application programs adopt authority. Since the application profile will own the programs and the database files, users will be able to perform all functions but only when they go through the application. Then you set the *PUBLIC authority of the files to *USE or, in your case, give the group profile *USE to the authorization list. This allows users to download the information into Excel spreadsheets or to use Crystal Reports but they cannot update or change the data. Or, if you prefer that they have no access through these interfaces, you can grant the group *EXCLUDE to the authorization list. They will still be able to run the application because they have authority through adopted authority but they will have no access outside of the 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
When error messages arise concerning attempts to use a permanent system object without authority, find the source of the issue by looking for an AF ... Continue Reading