IBM i Security Tips

Recovering Your IBM i Security Configuration

By Rich Loeber

I once worked, many years ago, with a company that had a disaster recovery plan in place and actually tested it once or twice. The plan called for us to arrive at the recovery center and then, almost immediately, turn security on the recovery box OFF to make things easier during the recovery. There was no corresponding step later in the recovery to reactivate security, so for the duration of any disaster, the backup system was exposed to security violations. Now, to give them some credit, this was in the days before networks and the Internet, so their exposure was probably pretty limited. In today's world, however, when you have to switch over to a disaster recovery site, you will need to have your security plan in place and built into the recovery process.

To understand how best to do this, you first have to understand what the different security objects and settings are on your system along with how and where they are saved.

System values make up a large component of your security policy implementation. The system values are all stored in the QSYS library. They are saved when you run a SAVSYS, the "Entire system" or "System data only" options on the SAVE menu or when you save your entire system using the "Run Backup" (RUNBCKUP) command. When you get to your recovery site and restore your OS from one of these, your system values will get restored in the process. Keep in mind that these settings will be restored the way they existed when your SAVSYS was created.

User profiles, including group profiles, are also stored in the QSYS library and are saved when you save the OS. Since these can change more frequently than the OS, you can also save them using the "Save Security Data" (SAVSECDTA) command. When you restore your OS, you will get the profiles as they existed when that backup was taken. If you have saved the the profiles separately, make sure that you restore them again as soon as the OS has been restored so that you get the most current set of passwords available.

Job Descriptions can also have an important affect on how jobs run and how security is enforced on your system. IBM generally recommends that you create your job descriptions in the QGPL library where they keep theirs, but a job description can be created and stored in any library on your system, especially if you are running any third party software. When you backup a library using the "Save Library" (SAVLIB) or "Save Object" (SAVOBJ) command, the job descriptions will travel along and will be restored when those libraries are restored.

Finally we get to your resource security setup. This, by its very nature, is a bit more complicated than the above items, but certainly manageable. The good news is that a lot of the resource security information is stored directly with the object. This includes its public authority setting, its object audit setting, the profile of the object's owner, the primary group and the link, if any, to an authorization list. So, when you save the objects in your library, you will also be saving these security items. The two resource security pieces that are not included are the authorization list itself and the private authority configuration.

All authorization lists are stored in the QSYS library. They are saved when you save your OS and they are also saved when you run the SAVSECDTA command. As with the user profiles already mentioned, these can change more dynamically than the OS, so having a separate SAVSECDTA is a good idea. After you restore your OS, make sure to include a restore of your security data to get the most recent versions of your authorization lists.

Private authorities are also stored in the QSYS library and are included as a part of the user profile data. So, when you save the most recent profile information, you are also saving the most recent private authorities. When you recover your profiles, you are also recovering the private authorities. But .... there is a catch. After your system has been recovered, including the most recent profiles and ALL application libraries, you will also have to run the "Restore Authority" (RSTAUT) command for *ALL users. This will restore the private authorities to objects and to authorization lists. This is a step that can be overlooked with dire consequences as far as your security implementation is concerned.

There is more information about all of this in IBM's Security Manual for the OS. I recommend you review the manual for more details.

If you have any questions about anything included in this tip, you can reach me at rich at kisco dot com, All email messages will be answered as quickly as possible.