How to implement security for CA OPS/MVS facilities?
Article ID: 28203
Updated On:
Products
Issue/Introduction
Introduction:
Some CA OPS/MVS facilities can and probably should be made available to many, if not all, users at your installation. Features like OPSVIEW and OPSLOG are good examples of such facilities. However, some CA OPS/MVS facilities need to be secured to prevent unauthorized users from changing the state of the automation or even the state of the system. Examples of such facilities are Global variables, RDF tables and the ADDRESS OPER host command environment.
The following question is often posed to our technical support representatives: "How do I restrict access to the RDF Table Editor or the Global variable options in OPSVIEW?" The answer to this question is not as straightforward as one would think. OPSVIEW is a set of ISPF dialogs that use base CA OPS/MVS facilities to accomplish an objective. So, even if it were possible (which it is not) to limit access to a specific option or panel in OPSVIEW, that would not provide any real security. Limiting access to the panel would not prevent someone from creating his or her own REXX program or ISPF dialog to perform similar functions, thereby circumventing the security on the OPSVIEW dialogs. To avoid such exposures, security interfaces are provided to allow installations to control the access to CA OPS/MVS facilities rather than to options in the OPSVIEW dialogs.
Instructions:
There are two possible ways for an installation to implement security in the product. The most common, simplest and highly recommended method of security validation is to write CA OPS/MVS AOF security rules. AOF security rules are written in OPS/REXX, which makes them easy to write, easy to maintain and easy to test. Furthermore, the OPSECURE function can be used from within AOF security rules to interface to any SAF-based security product (CA ACF2, CA Top Secret or RACF). Doing so allows you to write generic AOF security rules which in turn call the SAF-based security product to perform the validation checking. Your security administrators are responsible for setting up the generic CA OPS/MVS security resources and maintaining control over who has access to those resources. A less desirable alternative is to perform all the security checking in the AOF security rules and maintain lists of user IDs that are allowed to access the associated CA OPS/MVS facilities. These user ID lists should not be hard coded in the rules, but should be maintained in global variables referenced by the rules.
The second option for securing CA OPS/MVS facilities is to modify the assembler language installation authorization exit routine (see the source code for module OPUSEX). Although it is not as easy to test the installation authorization exit as it is to test REXX-based security rules, you can have the exit writer perform testing without impacting other users by setting the appropriate USERID value in the AUTHSTRING parameter (see the CA-OPS/MVS Parameter Reference for more detailed information).
You may choose to use both AOF security rules and the installation authorization exit. In that case, AOF security rules take precedence over the installation authorization exit. The installation authorization exit is not called if any enabled security rule processes the security event. You can check this for each security event by performing two actions: setting the BROWSESEC parameter to YES (to include SEC events in OPSLOG) and then checking the COUNT column for that security event in OPSLOG to see if any AOF security rules processed it. A value of zero in the COUNT column indicates that no AOF security rules processed the event.
Note that AOF rules are considered a secure environment and the use of CA OPS/MVS facilities within AOF rules is not subject to security checking. Therefore, it is very important to use your security product to limit update access to the AOF rule data sets and the high-level qualifier specified in the RULEPREFIX parameter.
It is strongly recommended that every installation use the CA OPS/MVS SECURITYRULESET parameter to limit all AOF security rules to a single AOF rule data set and also to use your SAF-based security product to tightly control update access to that data set. When this parameter is set to the name of a valid AOF ruleset, any attempt to enable an AOF security rule from any other rule data set will be rejected.
Additional Information:
CA OPS/MVS Implementing External Security
Environment
Component:
Feedback
