As your System i shop's security officer, you've developed a security policy; analyzed the user base; classified the various points of information access and implemented your policy to protect the data assets on your system. You have a current user profile base that you're maintaining on a regular basis. When new applications come along, you review the security requirements and make sure that they can fit within your established policies. You probably even have a plan in place for offsite backup storage for your shop with a regular schedule of backups and tape rotations.
But, have you given thought to how your security policies are stored on your system and how they figure into your backup process? If not, you might be in for a rude awakening when you need to restore your system following a catastrophic system loss. Let's take a look at how the various pieces of your security implementation are stored on your System i processor. A future tip will then look at how your can make sure that your security setup can be restored successfully.
Your security configuration is stored in three different places on your System i server. You should be familiar with these storage locations and how they relate to your security implementation.
Some security information is stored with individual objects. These include things such as public authority settings, who owns the object, what the owner's authority to the object is, group authorities to the object, the name of any authorization list that applies to the object along with private authority information.
In addition to the security information stored with each individual object, there is also a wealth of security information stored with your user profiles. This information includes user profile attributes, the profile's UID (User Identification Number) and GID (Group Identification Number), private authority information to objects, object ownership information, group profile information, profile auditing information and information about registered functions for the profile.
Lastly, there is security information stored with existing authorization lists on your system. This includes a list of objects secured by the list along with other normal authority information to be considered for objects secured by the list.
When you save the objects on your system, only part of the security information is getting backed up to tape. In order to get a complete backup of your system, including all of the current security information, you must not only save the objects, you must also save the security information. This requires using the Save Security Data (SAVSECDTA) command. This command will backup the user profiles, authorization lists and any authority holders that you have in your security configuration. Only when both the objects and the associated security data for your system are saved will you get a full backup of your security implementation.
There are some restrictions on the use of the SAVSECDTA command, so if you introduce it into your save/restore plan now, make sure that you understand those restrictions and accommodate them. Of special concern is the PRECHK parameter and the possibility that it could abnormally terminate your backup operation. See the HELP text associated with the SAVSECDTA command for more information.
If you have specific questions about this topic, e-mail me at rich@kisco.com. All e-mail 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.
