Protecting databases

You can protect your VSAM and OSAM full-function databases, as well as your Fast Path DEDBs by using segment-level sensitivity, field-level sensitivity, or RACF®.

Segment- and field-level sensitivity: Through centralized control over the content of database definitions, program specification blocks, and the libraries in which they reside, an effective scheme of protection attributes can be assigned to data. Note, however, that for database protection through PSBs to be totally effective, you should also protect the PSB library and the application program library (to safeguard the code that accesses the databases).

Segment-level sensitivity

If you are not using field-level sensitivity, the smallest unit of data that can be protected is the segment. The basic actions that can be authorized are:

None: No access to segment type.
Read: Segment type can only be retrieved.

One or more of the following additional actions combined with read can be authorized:

Add: New occurrences of segment type can be inserted.
Update: An existing occurrence of a segment type can be replaced.
Delete: An existing occurrence of a segment type can be deleted.

The way the PCB and the parameter values for the PROCOPT keyword are specified controls the authorization. Although access authorization is declared at the program level, enforcement of the authorization can be made to appear at the transaction code or individual hierarchic level of a database. If only one transaction code is associated with a particular program, then the access authorization is effective at the transaction level. By using SENSEG statements in the PSB and key sensitivity as a processing option for higher-level segments, masking can be effective at the individual hierarchic level.

Field-level sensitivity

Field-level sensitivity can provide another kind of database security. Database descriptions (DBDs) and PSBs can be coded to permit access to a required subset of fields within a segment. Field-level sensitivity can also be used to control the replace function at the field level to help ensure database integrity.

Related reading:

For more information on security at the database level, see IMS Version 15.2 Database Administration.
For information about generating DBDs and PSBs, see Application Control Blocks Maintenance utility and Program Specification Block (PSB) generation utility in IMS Version 15.2 System Utilities.

Protecting databases with RACF

You use the RACF user ID of the DLISAS or control region started procedure, depending on the environment you are executing. If you start IMS with JCL, the RACF user ID can be on the job card along with its password.

VSAM full-function database: In an online environment, if a RACF user ID is associated with the DLISAS started procedure, that ID is used for access checking. If a RACF user ID is not associated with the DLISAS started procedure, the control region RACF user ID is utilized. (In the batch environment, the user ID of the batch job is employed.) Access authority of CONTROL is required. The database must be defined as ICFCATALOG. Use of the older VSAM catalog type is restricted.
OSAM full-function database: In an online environment, the RACF user ID of DLISAS is used; in the batch environment, the user ID of the batch job is used.
Fast Path DEDBs: In an online environment, the control region RACF user ID is used. (No batch environment exists.)
Additional protection: You can also implement database security with the DATABASE, FIELD, and SEGMENT classes in RACF.
Related reading: For more information on these resource classes, see Preparing a RACF security plan.