Securing the Save/Restore Function

By Rich Loeber

On today's open IBM i system, the save/restore function can be used to transfer critical files and programs between systems. With this comes the specter of data and program theft, so it is important to make sure that this avenue of data transfer is secure.

Most IBM i installations run a scheduled save of their system to transfer files, programs and other objects to tape or other media for safe keeping. Saving the system on a scheduled basis is just good practice since the catastrophic loss of a single disk unit on your system can mean that you loose everything on your system. Since introduction, IBM has hounded its customers (and rightly so) to do a regular save on your system. Once objects have been saved, you can also use IBM i/OS functions to restore objects from the saved media. This can be part of either a full system restore or to recover objects that get damaged or corrupted in any number of ways.

The problem, from a security viewpoint, is that once data and programs have been saved to offline media, they can then be transported to another system and restored. Mission critical information must be guarded to prevent theft from occurring. Physical security on the media is critical for this, but I want to talk more about securing the save/restore function on your system.

Today, with an open TCP/IP world in which we work, you can save a critical file to a save file and then FTP or SNDNETF it to any system in the world. IBM i software developers regularly use the FTP save file to transfer program updates onto customer systems. With the ease of data transfer that this provides, restricting the use of the save/restore functions on your system is more critical than ever.

The first line of defense for this is found in the user profile. Before someone can use the Save/Restore commands in the IBM i/OS, they must have *SAVSYS special authority in their user profile. If you have not done so, I recommend that you review your user profile base to find out which user profiles have *SAVSYS configured and make sure that they have a real business reason for it. Certainly, your operator(s) will need this authority, as will anyone who runs the scheduled backup or restore functions. But, I would be hard pressed to think of any other users in a regular environment (including programmers) who really need to have this ability. I know some programmers are going to howl at this, but they will have to be able to make their business case before you give them these keys to the kingdom, so to speak. You can always look at granting them this authority on an as needed basis, revoking it once the task to be done has been completed. Some shops even keep a special user profile around for this use. When needed, they activate it temporarily and the deactivate it with full documentation kept on how it was used.

The next place to look for restricting Save/Restore use on your system is the IBM i/OS authority setup for the the RSTxxx and SAVxxx commands. The RSTxxx commands are shipped from IBM with public *EXCLUDE, but the SAVxxx commands have a public setting of *USE. You might want to consider setting up an authorization list for these commands and then listing the users that you want to be able to use them in the list. Once the list is built, associate it to the commands and then change the SAVxxx commands to be public *EXCLUDE. (You can also do this with direct authority, but having the authorization list will make IBM i/OS upgrades easier to implement.)

There are several system values that you should take a look at too. The QALWOBJRST value lets you restrict certain objects at restore time. These include system-state programs, programs that adopt authority and objects with validation errors. QVFYOBJRST controls restoring signed objects. QFRCCVNRST wil force object recreation on certain objects at restore time. Lastly, you can specify *SAVRST in the QAUDLVL command to audit save restore operations on your system.

If you have any questions about anything in this tip, just ask me and I'll give you my best shot. My email address is rich at kisco.com. All email will be answered.