CA Datacom/DB security protects access to tables and the CA Datacom/DB Utility (DBUTLTY) functions. This security is typically administered through an external security product.
Security User IDs
CA Datacom/DB is called by user applications. As part of shipping a request to the MUF, the current user ID is passed. In the MUF, this user ID is signed on with a technique not requiring a password. This technique requires that the MUF be authorized. The MUF does not enable if external security is established for the Directory and the MUF is not authorized.
The MUF maintains the signed on users in an unlimited cache that contains both the signon and tables that have been accessed successfully in the past. As each request is made, it is validated by first checking the cache. If it is found, no further checks are needed. If it is not found, external security is called.
Because CA Datacom/DB saves authorizations in memory, it is not always in synchronization with the external security product. For most products (except notably RACF), when it is necessary for a change to be seen instantly, use the DBUTLTY SECURITY OPTION=RESET transaction or the console command SECURITY RESET to reset the security buffer. You can specify either an individual user be reset or all users be reset. If you specify a user on the reset, the MUF signs that individual user off and all of the cached permissions of that user are discarded. If you do not specify a user, the MUF signs all users off, and the entire cache is discarded, which in turn causes reestablishment of all security validations.
When updating RACF resources, The RACF environment is not automatically refreshed. However, there is a method that allows the RAC LIST to be refreshed without recycling the MUF. For more information, see Refreshing RACF Without Cycling Multi-User.
Note: The security user ID is part of the log record and is reported with the RXX report. The security user ID is also part of the READRXX fields.
Security and User Exits
CA Datacom/DB has three user exists and the MUF allows a subtask. These facilities allow code other than CA Datacom/DB to open data sets and perform work. When reviewing your security environment and setting up external security, review these programs (if any) and verify that you are not allowing access to secured data by user programs hidden in the MUF region.
SQL Security Supersedes
If the SQL Security Model is defined for a database, only privileges defined with GRANT and REVOKE statements are used to control access to the tables in that database. In this case, these security authorizations supersede any external authorizations.
Table Partitioning Considerations
If a DBUTLTY function does not include an explicit TABLE= keyword, table level security (at the DBUTLTY) can be granted either at the Full Parent table level or the Child table level. If the DBUTLTY function includes a specific TABLE= keyword, table level access is checked using the table name specified by the TABLE= keyword. For example, the EXTRACT function of DBUTLTY uses the table name specified in the TABLE= keyword. But a DBUTLTY BACKUP AREA function uses either the Childrens' names that are contained in the area, or it uses the Full Parents table names. If access is granted to either, the BACKUP is allowed.
|
Copyright © 2014 CA.
All rights reserved.
|
|