What I prefer to do in this case (and have successfully implemented) is to move the members of USERA to another group profile. USERA continues to own the application. The application programs are modified to adopt authority. This method allows users to continue to work as they do today -- as long as they go through the application interfaces. However, if the user attempts to use a network interface like FTP or ODBC or a sockets application or a Web application or even access the application objects from the command line, they will only be able to access the application objects with the authority *PUBLIC is set to. Therefore, if you set *PUBLIC to *EXCLUDE, they will be totally prevented from accessing the objects outside of the application. However, if you don't mind if they read the application data, you can set *PUBLIC to *USE and then users could download the data, but not update it outside the application. This is a permit example of how you implement object security and why it works so well -- no matter how the data is being accessed.
To implement -- change the programs to adopt authority (set the program's user profile parameter to *OWNER), set the application objects to the appropriate *PUBLIC authority setting, then remove selected users from USERA group and make sure everything is working properly. You can then start removing more and more users or, you can remove the rest all at once.
================================== 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
This was first published in August 2004