Securing Database Resources › About Database Resources › Database Security and Database Names

Database Security and Database Names

Segment Names and Database Names

The database name specified on a BIND RUN-UNIT statement or a CONNECT statement can be either a segment name or a database name defined in the database name table. If you secure all databases, a security check will be routed to the enforcing system on BIND RUN-UNIT statements and on database definition and access statements issued following a CONNECT.

Note: To issue the CONNECT statement itself under the central version, the user must have signon authority for the system with which the dictionary named in the statement is associated and authority to invoke the task or application from which the CONNECT is issued.

However, if you plan to leave some databases unsecured, you must consider how CA IDMS processes a database name before you build database security in the SRTT.

Role of the Database Name Table

If an application requests a bind to a database or a connection to a dictionary, CA IDMS searches the database name table for the name specified on the BIND or CONNECT. If it finds a match, CA IDMS determines the areas and files to be accessed based on the segments that are included in the database name. If it does not find a match in the database name table, CA IDMS searches for a matching segment name in the DMCL. If no match is found, an error results.

Securing Access to Individual Segments

To understand how access to segments is secured, consider this sample database name table:

If the entry for DB is security 'OFF', you would obtain these results using occurrence overrides:

• If you secure 'SYSTEM', access to the SYSTEM segment is secured. Access to CATSYS and SYSMSG through dbname SYSTEM is secured, but access to these segments directly or through dbname DIRLDICT is not secured.
• If you secure 'SYSTEM' and 'DIRLDICT', access to the SYSTEM segment is secured. Access to CATSYS, SYSMSG, and DIRLNWK through dbnames is secured, but direct access to these segments is not secured.
• If you secure 'SYSTEM', 'DIRLDICT', 'CATSYS', and 'SYSMSG', access to all segments but DIRLNWK is secured.

Therefore, to achieve complete database security using occurrence overrides, you must secure all segments to be protected and all dbnames that include one or more of those segments.

Securing the Database Name Table

To maintain database security that is based on occurrence overrides, you must secure database name tables that are included in DMCLs. If a database name table is not secure, a knowledgeable user could create or modify the definition of a database name that is not secured to include otherwise secure segments.

Note: For more information, see Securing Database Name Tables.