The OTRAN resource name is shared by all CA IDMS, IMS, and CICS facilities. Therefore, protecting a task via OTRAN for a CICS region also results in tasks of the same name being protected in all CA IDMS, IMS, and CICS regions which are also under the control of CA Top Secret.
Note: A task protected via OTRAN does not go through LCF checking unless EXTCLS='LCFONLY' is specified.
To add ownership of a task to an ACID, enter:
TSS ADD(acid) OTRAN(task)
To allow users access to the task, enter:
TSS PERMIT(acid) OTRAN(task)
The #SRTT allows you to indicate that certain tasks should bypass security checking. This is particularly useful for customized signon programs or menus. The following sample entry demonstrates how to bypass security for the SGN2 task:
#SECRTT TYPE=OCCUR RESTYPE=TASK, SECBY=OFF, RESNAME=SGN2, EXTCLS='LCF' EXTNAME=(RESNAME)
If you choose not to protect tasks using OTRAN, they can be protected via LCF. Tasks protected through LCF must be defined by facility. Tasks can be defined either inclusively (TRANS) or exclusively (XTRANS), but not both. Essentially, each user can have an inclusive list, which specifies a list of tasks the user is allowed, or an exclusive list which the user is not allowed to use.
It is recommended that tasks be divided by function or subset and defined as a group within profiles. This way tasks are defined only once per group, instead of once per user.
CA Top Secret provides protection for all resources that are coded in the #SRTT. CA IDMS fails all resource checks for undefined resources.
Since CA IDMS does not tolerate security violations during abend processing, care must be taken when protecting certain resources. For example, if you activate external security for SPGM and SLOD and the program resources beginning with IDMS and RHDC are unowned, the CA IDMS clean-up tasks CLOD QUED abend in any mode. If these programs are owned and the CA IDMS started task ACID has not been permitted to use them, CA Top Secret issues warning messages while in WARN mode, but the transactions will still ABEND.
For resources to be protected they must be owned. The standard set of CA Top Secret control features for owned resources is also available for CA IDMS resources including:
It is important to remember that an ownable resource (not a task) can be added to the Audit Record so that all activity involving it can be tracked. In short, resource ownership allows more comprehensive, flexible, and systematic security than a task-based implementation.
Since the two approaches are not mutually exclusive, some combination of the two approaches might suit your particular environment and security needs best.
Program protection is activated by coding an #SRTT entry for the SPGM resource class.
A sample #SRTT entry appears below.
#SECRTT TYPE=ENTRY RESTYPE=SPGM SECBY=EXTERNAL EXTCLS='PROGRAM' EXTNAME=(resname)
Access to the program must be granted using the PERMIT function of the TSS command.
Access can be limited to only specific regions through the FACILITY parameter as part of the program permission. Time of day, day of week, and access expiration controls are also available.
How to establish ownership of the program and permit access to it are covered in the User Guide.
There are two methods to provide protection:
Note: Database protection is required for both types of protection. You must code an #SRTT macro to issue security checks when using either Subschema or Run Unit protection. The macro shown below must be used for both methods.
#SECRTT TYPE=ENTRY RESTYPE=DB
SECBY=EXTERNAL EXTCLS='DATABASE' EXTNAME=(RESNAME)
Traditional subschema protection uses the following statements, which do not provide Run Unit protection, in addition to the ENTRY statements listed previously.
#SECRTT TYPE=ENTRY RESTYPE=NRU SECBY=EXTERNAL EXTCLS='SUBSCHEMA' EXTNAME=(SSNAME)
Note: Using traditional Subschema protection, the CA IDMS external security interface regards all subschema resources as protected by default, whether or not DEFPROT is an attribute of SUBSCHEMA. Thus, any attempt to use a subschema resource in an application will fail if the resource is not owned.
Traditional Run Unit protection uses the following statements, which do not provide Subschema protection, in addition to the ENTRY statements listed previously.
#SECRTT TYPE=ENTRY RESTYPE=NRU SECBY=EXTERNAL EXTCLS='IDMS' EXTNAME=(RESTYPE,RESNAME,SSNAME,DBNAME)
If you choose to create a resource class for run units, you may want to create a general resource class for the CA IDMS resources. For example:
TSS ADD(RDT) RESCLASS(IDMS)
RESCODE(NN)
ATTR(MAXLEN(36))
DEFACC(READ)
ACLIST(ALL,NONE,READ,UPDATE,CREATE)
Then, the run unit resource can be owned by issuing:
TSS ADD(USERMS) IDMS(NRU.)
Permitted with:
TSS PERMIT(USERMW) IDMS(NRU.pgmname.ssname)
or
TSS PERMIT(USERMW) IDMS(NRU.pgmname.ssname.dbname)
Access to the subschema must be granted using the PERMIT function of the TSS command. Access can be limited to only specific regions through the FACILITY keyword as part of the subschema permission. Time of day, day of week, and access expiration controls are also available.
The syntax for subschema security is shown below. The ADD function establishes ownership of the subschema.
TSS ADD(USER'3) SUBSCHEM(TSTPAY)
The PERMIT function grants access to the subschema.
TSS PERMIT(USER14) SUBSCHEM(TSTPAY)
The following example shows the keywords that can be used to further limit the use of a subschema via the PERMIT function:
TSS PERMIT(USER14) SUBSCHEM(TSTPAY)
FAC(IDMSTEST)
TIME(13,17)
DAYS(TUESDAY,THURSDAY)
FOR(14)
ACTION(AUDIT)
Area security is provided for both logical and physical databases.
Area security requires the coding of the appropriate #SRTT macros, as shown in the following examples. The first example codes the required database security, while the second example codes area security.
#SECRTT TYPE=ENTRY RESTYPE=DB SECBY=EXTERNAL EXTCLS='DATABASE' EXTNAME=(RESNAME) #SECRTT TYPE=ENTRY RESTYPE=AREA SECBY=EXTERNAL EXTCLS='AREA' EXTNAME=(RESNAME)
Access by utility load or print/punch for DBA operations is also checked. Internal checking is designated with DBAREAD and DBAWRITE access. External checking is performed with READ access combined with DBADMIN authority.
Access to the area must be granted using the PERMIT function of the TSS command.
Areas have access levels associated with them; the access level is derived from the function code on the DML call. The PRIVPGM (Privileged Program) keyword is also applicable for area limiting. Specifying PRIVPGM limits access to the area to a particular CA IDMS program or group of programs. Use of the area can be limited to specific regions through the FACILITY keyword, as part of the area definition. Time of day, day of week, access expiration, and action controls are also available.
Note: The area resource has been predefined in the RDT record with the LONG attribute, which supports name lengths of up to 44 characters when used with the PERMIT command function.
The syntax for area security is shown below. The ADD function establishes ownership of the area.
TSS ADD(USER'2) AREA(TSTPDA)
The PERMIT function allows update access to the area.
TSS PERMIT(USER13) AREA(TSTPDA)
ACCESS(UPDATE)
The following example shows the keywords that can be used to further limit the area via the PERMIT command:
FAC(IDMSPROD) PRIVPGM(TSTPAA45)
TIME('9,18) DAYS(MONDAY,WEDNESDAY,FRIDAY)
UNTIL(11/24/'1) ACTION(NOTIFY)
The available access levels for areas and their relationship to CA IDMS DML calls are defined in the following table:
|
CA Top Secret Access Level |
CA IDMS Call Function |
|
READ |
RETRIEVE |
|
UPDATE |
All other |
|
NONE |
N/A |
|
ALL |
N/A |
NONE and ALL are CA Top Secret-only access levels, implying no access and total access, respectively.
The default access level is READ.
The following example shows the keywords that can be used to further limit the area via the PERMIT command:
FAC(IDMSPROD) PRIVPGM(TSTPAA45)
TIME('9,18) DAYS(MONDAY,WEDNESDAY,FRIDAY)
UNTIL(11/24/'1) ACTION(NOTIFY)
Terminals are owned resources; therefore, auditing and distributed administration can easily be performed. Ownership of a terminal protects the resource across all defined facilities; however, access can be limited to only specific facilities through the FACILITY keyword as part of the terminal definition. Time of day, day of week, access expiration, and action controls are also available.
The terminal name defined depends on your environment:
Note: Terminal protection applies across all facilities with like terminal names. CA IDMS PTERM definition also limits VTAM terminals for facilities such as TSO. Check the implication of terminal security as related to TSO, CICS, or any other online facilities under CA Top Secret control. To determine how to establish ownership of the terminal and permit access to it, see the User Guide.
|
Copyright © 2013 CA Technologies.
All rights reserved.
|
|