Securing Resources › Common Resources to Protect › Ownership vs. Authorization

Ownership vs. Authorization

Securing resources is a two step process. Once the resource type, or class, is defined in the Resource Descriptor Table (RDT), then the resources themselves must be:

• Owned by an individual ACID (we recommend using a DEPT ACID)
• Permitted to additional ACIDs (if necessary)

Resource classes are identified through the RDT. To secure a specific resource within that class, that resource must also be owned by a particular ACID. That is, CA Top Secret can protect data sets (in MVS) and minidisks (in VM) because the data set and minidisk resource classes are included in the RDT. To protect the ACCTNG.UPD data set or the ABC123 minidisk, that data set or minidisk must be owned. For example, the ACCTNG.UPD data set may be owned by the Accounting Department whose ACID is ACCDEPT. The ABC123 minidisk may be owned by John Smith, whose ACID is USER01.

Note: Data sets and minidisks, as resource classes, are protected by default in IMPL Mode and in FAIL Mode (which is the mode in which CA Top Secret is delivered). If you are operating in any other mode, you can use the DEFPROT attribute to invoke default protection. DEFPROT, which can also be used for other resource classes, is discussed in greater detail in the “Securing Resources” chapter.

Ownership of a resource automatically implies full access to that resource. For other ACIDs to have access to that resource, they must be authorized to do so. CA Top Secret allows a great deal of specificity in defining exactly what authorization restrictions you want placed on the use of a resource by a particular user or profile group.

You can restrict access according to the following:

• Time of day (for example, between 9 a.m. and 5 p.m.)
• Day of week (for example, weekdays only)
• A particular period of time (for example, until December 31st)
• Facility (for example an ACID may only access a particular resource through TSO)
• Path (meaning it must be accessed through a particular program which, in turn must be loaded from a particular library).
• A particular access level (such as UPDATE or READ).

  Note: Access level restrictions are not applicable to all resource classes.

Note: For more information about securing resources, see the “Securing Resources” chapter.

Certain types of resources, such as TSO commands and CA Roscoe monitors, cannot be owned. Access to these resources can be restricted using the Limited Command Facility (LCF). LCF and unownable resources are discussed in greater detail in the “Securing Resources” chapter.