OPS/MVS

 View Only
  • 1.  Securing CA-OPS Opsview

    Posted Aug 27, 2015 11:00 AM

    I am working on implementing security for CA-OPS (v12.1) resources (RACF). I would like to secure the various menu options within the OPSVIEW application in the following way:

     

    1. OPSLOG - No restriction.

    2. All other options from the main panel limited access based on user ID.

     

    I have EXTSECURITY option turned OFF and I am using a security rule to process security events.

     

    What I have found is that it appears many of the menu options do not generate a security events AT ALL, at least not until you are already deep into the menu. Thus, there is no way for me to restrict access to individual menu options without restricting access to the entire menu system, i.e. restricting access to CA-OPS in general. It would seem to be an all or nothing proposition. I was even able to navigate into the editor menu without a security check occurring and was able to open a rule for edit with no security check. What is confusing me is that the OPSVIEW resource has the following variable available to it SEC.AUSYOTSR which is the menu option associated with the security event. In the book they give an example of "3.2". So I should be able to secure things if someone typed 3.2 which would take you into the Print Queue Manager for JES3. Based on this example then, every time someone issues a menu choice a security check should be made but it is not happening.

     

    So my question is this: Is this the way it is supposed to work? If not are there PTF's that fix it? How do others go about securing CA-OPS from most but not all?



  • 2.  Re: Securing CA-OPS Opsview
    Best Answer

    Posted Aug 28, 2015 10:19 AM

    The OPSVIEW facility within a SEC rule is to only control the access into OPSVIEW (upon the user invoking the OPSV command to access OPS). It is not to secure the 'menu' options entered once user is in OPSVIEW. The variable SEC.AUSYOTSR is referring to the OPTION that the user 'may' of passed to the OPSV command processor upon entering OPSVIEW...something like TSO OPSV 2.6 SUBSYS(OPSS).....so the variable sec.ausyotsr would of been set to 2.6 (user getting into OPSVIEW and directly into RDF editor). Security within OPSVIEW will have to be done at the facility level (the underlying functionality from the menu option) as you are seeing. Setting the BROWSESEC parm (if you dont have it set) will assist you in this effort as it logs the facility driven by each OPSVIEW menu option.