You will find a lot written about advanced topics in security for your IBM i, but if you don't have basic object level security in place, all the advanced topics in the world may be a complete waste of time. This tip will explore the basics of how to best secure native objects, including your data files, on your AS/400.
Before you attempt to secure your system at the object level, you have to check a system setting. Using the display system value (DSPSYSVAL) command, check the following system value on your system:
QSECURITY
If it is set to a level lower than 30, then you cannot implement object level security on your system. In this case, the first thing you need to do is increase the security level setting for your system. If this is your situation, I recommend moving to a minimum level of 40. If you are at level 30, you should also consider a move to level 40 as it will help with an extra level of protection for the integrity of your system.
Removing *ALLOBJ authority and setting an access policy
When you have finished this task, there are two more tasks that you need to check before moving on to the meat of object security. If a lot of users on your system have special authority on their user profile set to include the all object (*ALLOBJ) authority, then these need to also be changed. On a secure system, only a limited number of profiles should have all object authority to your system. Typically, this is limited to the system security profile (QSECOFR) and any other security officers that are defined to your system. Such profiles should have a documented business reason for having this special privilege assigned. You can identify the profiles that are set this way by running the display user profile (DSPUSRPRF) command for *BASIC information to an *OUTFILE. Scan the database file created for the *ALLOBJ string; this will show you how many profiles have this setting and which profiles they are.
Before you implement access rules on your system, you will need to determine an access policy. This policy will define how you grant or restrict access. The policy should be defined along application lines and have the support and approval of your organization's management.
Object level security and libraries
Now that we have these basics out of the way, it is time to implement security at the object level. If you are really doing this for the first time, you have a choice of implementing security with private authorities on each object or by using an authorization list. I recommend the latter. When you have to make changes to security settings on the fly, having your security set in authorization lists lets you make changes at any time. If your security access is stored with each object, then the object has to be available (i.e. not in use) to make changes to it.
Security is specified at the object level and at the library level. You also define public authority for general access controls and then you can grant specific greater access at the individual user profile or group profile level. Public authority is best enforced at the library level, but it can vary also at the object level. If, for example, you do not want just anyone accessing objects in a library, set the public authority for the library to exclude (*EXCLUDE). As a first step, I recommend that you identify all user libraries on your system and get the public and private authorities set up for them. Implementing security at the library level will take you a long way to having your system properly locked down.
Once your libraries have been configured for access rules, you can then go on to secure individual objects in the libraries. You can customize access rules using system default settings as follows:
- *EXCLUDE - the object cannot be used by anyone
- *USE - the object can be read by anyone but cannot be changed
- *CHANGE - the object can be read and updated by anyone, but not managed
- *ALL - the object can be read, updated and managed by anyone
- *AUTL - the object access definition of the authorization list is used
If you have very customized requirements, you can also carry this down to a more granular level by using specific settings available on the system.
This tip just scratches the surface. If you have any questions about this topic, you can reach me at (rich@kisco.com), I'll give it my best shot. 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.
