Saving and Restoring Resource Security

Resource security (defining user's access to objects) is a very important component of your system. Yet, you may not be saving all of the information you need to restore it correctly after a system failure or disaster. Even if you are saving all of the information, you may not be aware of the steps required to restore resource security. Here are the basics.

Public authority, object ownership and the link between objects and their authorization lists are saved through the Save Object (SAVOBJ) or Save Library (SAVLIB) command. Authorization lists and private authority are saved through the Save Security Data (SAVSECDTA) or Save System (SAVSYS) command.

The following steps are required to restore resource security for an application:

1. Restore user profiles and authorization lists with the Restore User Profile (RSTUSRPRF) command, specifying USRPRF(*ALL). (Restoring individual user profiles will not restore authorization lists.)

2. Restore the application libraries with the Restore Library (RSTLIB) or Restore Object (RSTOBJ) command.

3. Restore private authority to objects with the Restore Authority (RSTAUT) command.

Security and the Unattended Workstation

The AS/400 provides a built-in global solution for unattended security through the QINACTITV system value. But, when you only want to secure individual workstations this method cannot be used. The following technique will solve this problem by allowing an intractive program to control the time-out function.

Let's say that you assign a value of 45 seconds to WAITRCD. This means the display will remain visible for 45 seconds before control is returned to the program which sent the file.

To detect inactive workstations from your RPG/400 programs, do the following:

1. Code the INVITE keyword in the DDS for the display file.

2. Supply a value for the display file's WAITRCD parameter.

3. Specify the INFDS data structure in your RPG program with the *STATUS special keyword included.

4. If a workstation time-out occurs, the *STATUS field will contain a value of 1331. Code a test for this value in your program following your installation standards.

5. If a time-out is detected, you may want to have your program call an installation standard program that signs off the workstation, alerts the system operator or takes some other corrective action.

The following sample code (not a complete working program) illustrates the concept. Indicator 50 and a status of 1331 indicates a workstation time-out in which case a program is called to deal with the potential security problem.

 ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+.. A INVITE A R SCRN1 TEXT('MY SUBFILE RCD') ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+.. FPROMPT CF E WORKSTN F KINFDS INFDS F KNUM 1 IINFDS DS I *STATUS STATUS . . . C WRITESCRN1 C READ PROMPT 50LR * C *IN50 IFEQ *ON C STATUS ANDEQ1331 C MOVE *ON *INLR C CALL 'QCMDEXC' C PARM 'SIGNOFF' CMD 7 C PARM 7 LEN 155 C ENDIF ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+.. 

Password Management Made Easier

One of the most useful system values when it comes to password management is the Password Validation Program (QPWDVLDPGM). By specifying a program and its library in this parameter, you can allow a program to process the information entered in the Change Password (CHGPWD) command. This can be very useful in refining your security. I have written my own password validation program. It has two functions: it checks for certain words that you do not want used as passwords (e.g., user name), and it captures the password information at the time it is being changed. By capturing password information, a security administrator could inquire into passwords-something OS/400 doesn't normally allow you to do.

Once you assign a validation program to QPWDVLDPGM system value, every time the CHGPWD command is called (explicitly or automatically at password expiration time), the validation program is executed.

You should be aware of several considerations associated with this technique. Only passwords changed through the CHGPWD command will be processed, and passwords created by CRTUSRPRF or changed by CHGUSRPRF will not be processed. In addition, you must have special authority of *SECADM to update the QPWDVLDPGM system value.

Securing Individual Database Fields

The AS/400 database does not directly support field-level security for a file; that is, there's no direct way to protect an individual field from unauthorized access while leaving all others unprotected. At most, you can give users *READ authority (to read records), *ADD (to add records), *UPD (to update records) or *DLT (to delete records), but this is a blanket authority that covers the entire record-not a specific field.

What you want is a way for all users to read the nonsensitive part of a record, such as employee number, name and the department number. However, you don't want everyone to be able to read the rest of the fields, such as hourly pay rate and deductions.

There is a way to allow access to only certain fields in a physical file while protecting others: create a logical file that contains a subset of the fields. The physical file might look like this:

 ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... A R EMREC A EMEMPL 5P 0 TEXT('Employee number') A EMNAME 30A TEXT('Employee name') A EMDEPT 4P 0 TEXT('Department number') A EMHPAY 5P 2 TEXT('Hourly pay rate') A K EMEMPL ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 

The logical file created for selected field access would look like this:

 ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... A R EMREC PFILE(EMPMST) A EMEMPL A EMNAME A EMDEPT A K EMEMPL ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 

The logical file only "sees" the employee number, name and department number, and virtually ignores the rest of the confidential information.

Consider which users would be given access to the limited information. Give them all *OBJOPR authority to the logical file. This gives the users the authority to open the logical file and use the data authorities of the physical file on which the logical is based.

Then give the users the desired data rights to the physical file. If you want them capable of reading the data, give them *READ authority to the physical file. Don't give them *OBJOPR authority to the physical file, though. If they don't have *OBJOPR authority, they cannot open the physical file itself and the confidential fields remain protected.

You can use the same technique to allow some users to change certain fields but not others. Again, create a logical file with *OBJOPR authority to the users, and give *CHANGE authority (but not *OBJOPR) to the physical file.

Limiting Sign-on Attempts

In order to prevent unauthorized access to your AS/400, you need to limit the number of unsuccessful sign-on attempts to your system. This is done through two system values: maximum sign-on attempts allowed (QMAXSIGN), and action to take for failed sign-on attempts (QMAXSGNACN). QMAXSIGN sets the number of unsuccessful attempts allowed before taking some kind of action. I would suggest a maximum of three. If a user takes more than three attempts to sign on, someone needs to intervene.

QMAXSGNACN takes the action once QMAXSIGN has been met. The default value is a 1, meaning that the workstation is varied off. To reestablish contact with the AS/400, use the Vary Configuration (VRYCFG) command. A value of 2 will disable the user profile. A user with *SECADM and *ALLOBJ special authorities will then need to set the status of the user profile to *ENABLED.

A value of 3 will vary off the workstation and disable the profile.

Automatic Password Expiration

To ensure the continued secured usage of a user profile and keep users from obtaining other users' passwords, be sure to use PWDEXPITV value in the user profile. This will assure that passwords are being changed frequently. It can be set to a value of *SYSVAL, which incorporates the number of days from the system value QPWDEXPITV as an expiration time. Or you can put a number of days in that field from 1-366. *NOMAX is also a valid value, but you should be careful about how you use it. Once the number of days since the last password change has expired, the user is forced to change his password.