CARLa Prevent access using OPERATIONS

You can prevent OPERATIONS user IDs from accessing your sensitive resources as follows:

Create an additional RACF group profile (for example, OPSATTR).
Connect all user IDs that have the OPERATIONS or GROUPOPERATIONS attribute to this OPSATTR group. A CARLa program to assist you with this task is shown next.
Permit the defined and populated group to the access control list of all sensitive resource profiles with an access level of “NONE”.

It is suggested to run this next CARLa program on a regular basis through your job scheduler (for example, Tivoli Workload Scheduler). That procedure ensures that this suggested OPERATIONS control is automatically enforced and maintained.

CARLa program sample:

The MERGELIST statement is used in this particular CARLa program. MERGELIST writes the output of multiple newlists into a single report.

Exercise:

Run this CARLa program to generate the appropriate “CONNECT” and/or “REMOVE” commands (think before executing them). As a double check, list a number of the user IDs
that is shown in the output. Does it have or lack the OPERATIONS attribute as you expect?

In real life, the next step is to identify the sensitive profiles and permit “NONE” access to the OPSATTR group. This permission prevents that during the access verification process the OPERATIONS attribute check is done. Instead this check for the OPERATIONS attribute is now bypassed.

As a starting point, you can use newlist type REPORT_SENSITIVE for this purpose. Newlist type REPORT_SENSITIVE contains the list of data set profiles that protect data sets that are considered system-sensitive. For more information about which data sets zSecure considers system-sensitive refer to chapter 13, section SENSDSN of the zSecure User Reference manual.

The following CARLa program generates the appropriate permit commands for group OPSATTR with access “NONE” to sensitive data set profiles.

Sample output:

For all data set profiles that protect at least one sensitive data set, a permit command is generated. Running these commands protects these sensitive data sets from being accessed by users that posses the OPERATIONS attribute.

Notes regarding the previously shown CARLa code used for producing the permit commands for the OPSATTR group.

The SIMULATE statements the program starts with, define that you consider LINKLIST and JES PROC libraries to be sensitive. If, on your system, you do not consider these data sets to be sensitive, you can remove these statements.
The EXCLUDE statement filters occurrences where a sensitive data set exists, but is not protected by any data set profile. Although this situation hopefully does not occur on real production systems, this statement prevents generating a permit command for a non-existing data set profile.

Besides the data sets that zSecure automatically considers sensitive, you might have system-defined data sets that are considered sensitive to your company. You can use a SIMULATE statement to add those data sets to the list of sensitive data sets for newlist REPORT_SENSITIVE.

The syntax for this SIMULATE statement is as follows: SIMULATE SENSITIVE ACC CLS NAME. Where:

ACC Access level that is considered an exposure. Must be READ or UPDATE.
CLS Class name. Must be DATASET, DSN, or D.
NAME Resource name, fully qualified data set name (without quotations).

Exercise:

Adjust the CARLa program so it considers data sets “CRMB.CPLIANCE.REPORTS” and “PMI.RACF.CNTL” as READ sensitive.

Note: this CARLa program takes only care of protecting sensitive data sets from being accessed by OPERATIONS users. If, on your system, other resource classes are active that honor the OPERATIONS attribute, you might require additional permissions to protect sensitive resources in these classes. To investigate which resource classes honor the OPERATIONS attribute, you can use the Class Descriptor Table (RACFCLAS) report.

Adding the appropriate OPSATTR permits for these general resource classes is not included in this lab guide.

View Suggested samples and answers

Continue with Using SMF to report access

IBM, the IBM logo and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml.