By Rich Loeber
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 IBM i.
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:
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.
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. All 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.
Lastly, 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.
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 (ie: 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:
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 at kisco.com, I'll give it my best shot. All email messages will be answered.