In addition to being used for level checking, the DTSYSTEM class identifies the following:
Note: Security event logging to the console is normally suppressed on DTSYSTEM resource calls made during Multi-User startup.
Each of the non-level DTSYSTEM resource names begin with a high-level node of CXX name that identifies a system. A system includes all the databases and tables defined in the CA Datacom/DB Directory (CXX) represented by the CXX name. The CXX name is established for a CXX when the CXX is initialized.
The DTSYSTEM resource class is the key to turning on external security for CA Datacom products. To activate external security, the Security Administrator must deny all users access to the DTSYSTEM resource which identifies the system to secure. To deactivate external security, the Security Administrator must allow all users access to the DTSYSTEM resource identifying the unsecured system. The CXX name identifies the system.
At the startup of the MUF, when the LEVEL PASS and FAIL resource names are properly set up, the external security product is called with a series of resource names in the DTSYSTEM resource class. These resource names have a high-level node of the cxxname followed by a low-level node or nodes representing a product or feature. The following list shows what these resource names represent and what it means if the user who submitted the MUF is denied access to these resource names.
Note: Each of the following products or features, when externally secured, produces a DB00220I message to indicate that it is externally secured.
CA Dataquery is externally secured
CA Datacom Datadictionary is externally secured.
XCF is externally secured.
Note: The check for XCF security is only done for those operating system environments that support XCF.
View security allowed.
cxxname.SV.DEFAULT
Default view security may be specified on the Multi-User startup options.
The DTSYSTEM resource class also allows the Security Administrator to define the security mode for any new Multi-User system not yet defined. If the default permission is allowed for undefined systems, new systems are not secured. When the default permission is denied and LEVEL03 or higher is properly set (such as in CA ACF2), new systems are protected and permissions must be in place for all CA Datacom/DB activities before the CA Datacom/DB Directory initialization. If LEVEL03 or higher has been properly set, "default deny" allows the Database Administrator to choose the level of external security for undefined MUF.
If you have defined LEVEL03 or higher resource name pairs, coded path definitions in the Multi-User startup option SECURITY, and if the path-class access is denied, access to this particular path-class is secured.
If any level is selected, cxxname.DD and cxxname.DQ are also checked. If access is denied for cxxname.DQ, CA Dataquery is externally secured.
If LEVEL03 or higher external security is in place (through DTSYSTEM resources) and the operating system environment is such that XCF could run against this MUF, an additional security check is done using the DTSYSTEM resource class and a resource name of cxxname.XCF. If permission is denied to the user who submitted the Multi-User, XCF external security is in place.
Beginning with 14.0, the XCF_FROM specifications have become more dynamic and flexible. Therefore, if XCF is externally secured, each remote job which uses XCF to connect to MUF has its security checked at open or connection time.
This check is made against the DTSYSTEM resource class using a resource name of cxxname.XCFFROM.from-system.groupname (corresponding to the system from which the job is connecting and the XCF group it is using to connect). This check is done using the user who submitted Multi-User. If the check is denied, the open fails with a return code 87 (003) and no connection is established by the job.
SECURITY Multi-User Startup Option
Path security allows you to identify security rules for different command paths.
SECURITY (Path Security Syntax)
┌─ , ───────┐ ►►─ SECURITY ─▼─ DBaabbb ─┴───────────────────────────────────────────────────►◄
(Required) This is the format of a path security class-and-path option parameter, where DB is a constant.
The aa in the format represents valid class codes. These class codes correspond to the table classes defined in the external security system. Those table classes must be defined before implementing path security in CA Datacom/DB.
The valid entries and the table classes to which each corresponds are:
Corresponds to DCTABLE
Corresponds to DFTABLE
Corresponds to DGTABLE
Corresponds to DHTABLE
Corresponds to DPTABLE
Corresponds to DQTABLE
Corresponds to DRTABLE
Corresponds to DSTABLE
Corresponds to DTTABLE
Corresponds to DXTABLE
Specifies no path security for the indicated path (bbb)
The bbb in the format represents one of the valid path codes you can secure with path security. By specifying multiple class-and-path options, you can, if needed, specify in any order all ten different path codes on multiple lines as long as all paths specified are unique. But each separate path code can only be used once per SECURITY Multi-User startup option. When you specify multiple class-and-path options, you must use a comma to separate each occurrence, as indicated in the syntax diagram and shown in the following example.
The valid path code entries and what they signify are:
CICS SQL requests path
CICS SQL for CA Dataquery requests path
CICS non-SQL requests path
CICS non-SQL for CA Dataquery requests path
Non-CICS non-SQL for CA Dataquery requests path
CA Datacom Server or Ingres Enterprise Access to CA Datacom SQL requests path
CA Datacom Server or Ingres Enterprise Access to CA Datacom non-SQL requests path
Non-CICS, non-CA Datacom Server, and non-Ingres Enterprise Access to CA Datacom SQL requests path
SQL non-CICS for CA Dataquery requests path
All other non-SQL paths
Example
The following is an example showing the use of six path code options in one SECURITY Multi-User startup option. Path codes can be listed in any order, that is, the order shown in this example is only one of many possible orders.
SECURITY DBaaSSR,DBaaRAT,DBaaSCI,DBaaRSR,DBaaSQL,DBaaRCI
Note: There is no restriction on how many times a class code can be used per SECURITY Multi-User startup option. You could, for example, use the same class code for the different path code occurrences.
An example of a Multi-User startup option with six possible path-and-class options is:
SECURITY DBDTRAT,DBDCSCI,DBDRSSR,DBDFRCI,DBDSSQL,DBDXRSR
If a path-and-class is specified in the Multi-User startup option, a security check is issued for the DTSYSTEM class with a resource name cxxname.path-and-class. The path-and-class name must exactly match the seven letters coded in the Multi-User startup option. If access is denied, this path is secured using the class specified. If access is granted, an error is returned and the Multi-User is not enabled.
Any paths not coded in the Multi-User startup option have all possibilities checked for the path, that is, the ten classes and NO using DTSYSTEM resource class and names of cxxname.path-and-class. If access is denied to more than one of the options for this path, an error is returned and the Multi-User does not enable. If access is allowed for all options, no security is in place for this path.
|
Copyright © 2014 CA.
All rights reserved.
|
|