[TABLE]In today's security conscious environment, most System i shops have already locked down their systems. Object level security is locked down and users are classified as to what they can and cannot do when they are logged onto the system. But, securing files is only part of the problem. If a user can't look at a file, but they can look at processed output sitting in a print spool file, then your hard work of locking up the files is for naught.
There are several things you can do to control spool viewing. For starters, review your user profiles to see which users have the special authority of *SPLCTL or *JOBCTL. Both of these special authorities can give a user access to spool files. Only security officers and system operators should have these authorities. In a smaller shop, this might also extend to your programmers but not always. Generally speaking, most users should not be given these authorities unless they absolutely must manage their own print spool files and job controls. As a first step, these authorities should be limited as much as possible, especially the *SPLCTL authority because it is not subject to any restrictions and allows the user access to all spool files on your system.
Output spool files are special objects on your system and are not, per se, created with standard OS security controls. The way you can control security on spool files is through the way your output queues are set up and authorized. If you have output reports with sensitive information, you can control who can see them by the output queue where the report is stored. Output queues are created using the CRTOUTQ (Create Output Queue) com
To continue reading for free, register below or login
To read more you must become a member of Search400.com
mand and they can be changed using the CHGOUTQ (Change Output Queue) command. You can view the way and output queue is configured with the WRKOUTQD (Work with Output Queue Description) command.
The user profile that creates the report can always view it and control it. Sensitive reports should be created using a restrictive user profile to prevent widespread use of the spool file. To impose even stricter security, there are several parameters you can set when you create an output queue that will provide more control:
DSPDTA: Helps to protect the contents of spool files be defining who can display, copy, move or send a spool file in the output queue
AUTCHK: Defines what authority is needed to change or delete a spool file
OPRCTL: Defines whether a user profile with *JOBCTL authority can work with spool files in the output queue.
Using these three parameters, you can impose very restrictive access controls to spool files associated with an output queue. There is a good chart in the Security Reference guide that shows how the three parameters work together. If you have never given this concept much thought, you should conduct a thorough review of how your current output queues are set up to make sure that they conform to your company's security policies already in place.
If you have specific questions about this topic, email me at rich@kisco.com. All email messages will be answered.
---------------------------
About the author: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
