In CA Top Secret Option for DB2, users are identified by their ACIDs. Each user must have an ACID and, in most cases, a password. In addition to individual user ACIDs, there are also ACIDs representing departments, divisions, and zones. The administrator for each of these divisions is called a control ACID and these ACIDs are known by the following names: DCA (for departments), VCA (for divisions), ZCA (for zones), SCA (for the entire installation) and MSCA (the master security control ACID). The LSCA is the only control ACID with a variable scope. He or she can administer zones, ZCAs or other LSCAs.
Profile ACIDs are used in a manner similar to DB2 secondary authorization ids. User attributes or resource authorizations that apply to several users can be added to one Profile. Once that Profile is added to a User, he or she acquires the authorizations or attributes granted to the Profile.
For more information about creating ACIDs, you can see your CA Top Secret Command Functions Guide. In deciding on ACID construction, you should consider how you will delegate resources as well as who will have access to those resources. In CA Top Secret Option for DB2, ownership of a resource (which implies ALL access to that resource) is not automatically granted to the creator. Instead, ownership for administration is designated via the TSS ADD command when the resource is identified to CA Top Secret. We highly recommend that you ADD resources to a department or division rather than ADDing that resource to a specific individual. Individual users can then be granted access on an as needed basis. For example, assuming you've already created a DB2DEPT ACID, to secure all tables beginning with the PAY* prefix, you would first issue the following command:
TSS ADD(DB2DEPT) DB2TABLE(PAY*)
To PERMIT individual ACIDs (both in and out of the DB2DEPT department) you would issue the following command:
TSS PER(useracid) DB2TABLE(PAY*) ACC(SELECT)
Secondary authorization IDs are IDs that users can associate with to gain additional privileges to DB2 resources. Users can exercise the privileges of a secondary ID by associating with it through an exit. Some of the reasons IBM created secondary IDs are to overcome the cascade effect and improve the ownership of DB2 objects. The cascade effect occurs when DB2 revokes a privilege from an ID that granted the privilege to other IDs. DB2 also revokes the privilege from the other IDs. The loss of privileges creates an administrative burden for the security administrator, because he must ensure that users have the appropriate privileges to do their jobs. Secondary IDs can create a cushion against this type of effect because they typically are not granted the WITH GRANT OPTION and cannot grant privileges to another ID.
Secondary IDs also address the problem of managing ownership of DB2 objects. When a user is terminated or transferred, the security administrator must revoke his privileges and grant them to another user. This can create administrative overhead and result in the cascade effect. With secondary authorization IDs, the security administrator can grant these privileges to a secondary ID instead. The user then can associate with the secondary ID and exercise the privileges it has. Through the exits, the security administrators must update only a list of who can associate with each secondary ID when a user is transferred or terminated.
If you use secondary IDs for the above purposes, recognize that they can be difficult to maintain, can increase the complexity of managing DB2 security, and can create significant performance overhead. When DB2 checks a user's authorization, it checks every ID associated with that user until it finds one that is authorized. If users have multiple secondary IDs, this process can be time‑consuming. If you use secondary IDs to ease administration or to avoid the cascade effect, you should consider using profile ACIDs in CA Top Secret Option for DB2 to accomplish the same results. Profile ACIDs let similar groups of users access resources in the same manner. For example, if all clerks in the Personnel department need access to the SALARY DB2 table, you could issue the following commands:
TSS CREATE(PERCLRK) NAME('DB2 Pers. Profile') TYPE(PROFILE)
PASSWORD(NOPW) DEPT(PERSDEPT)
TSS PER(PERCLRK) DB2TABLE(SALARY.) ACC(SELECT)
Likewise, if all clerks in the Accounts Receivable department required access to the ACCOUNTS DB2 table, the following commands would be issued:
TSS CREATE (ARCLRK) NAME('Accts. Rec. Profile') TYPE(PROFILE)
PASSWORD(NOPW) DEPT(ARDEPT)
TSS PER(ARCLRK) DB2TABLE(ACCOUNTS.) ACC(SELECT)
If clerks in either department needed to access additional resources, the administrator would only need to update the Profiles. He would not have to update each individual clerks' ACID.
Some sites, however, use secondary IDs for purposes other than resource ownership. For example, users running applications that refer to an unqualified table name can use different versions of the table by changing their current SQL ID to a different secondary ID. If your site uses secondary authorization IDs in such a case, you can continue to use them with CA Top Secret Option for DB2 via the IBMGROUP resource class.
Note: Instead of using SET CURRENT SQLID as a means of qualifying tables for different systems, if each system has its own set of plans or packages, you can use the OWNER or QUALIFIER parameters of the DB2 BIND command for the same purpose. This will eliminate the need to use secondary IDs for table qualification.
In CA Top Secret, the IBMGROUP resource class is analogous to a RACF group name. In order to use IBMGROUP you must:
TSS CREATE(PAYROLL) NAME('Payroll 2nd id') TYPE(USER)
PASSWORD(NOPW,0) DEPT(DB2DEPT)
TSS ADDTO(DB2DEPT) IBMGROUP(PAYROLL)
TSS PERMIT(PAYROLL) DB2TABLE(PAYROLL.EMPLOYEE) ACCESS(SELECT)
TSS PER(USERFRED) IBMGROUP(PAYROLL)
Under CA Top Secret Option for DB2, however, we recommend using standard profile ACIDs rather than the IBMGROUP resource class or DB2 secondary authorization ids.
CA Top Secret returns to DB2 the names of all resources permitted to the user under the IBMGROUP resource class. This includes a search for the user record, all attached profiles to the user, and the ALL Record.
All additional access restrictions, such as time of day, day of week, ACTION keywords are honored on each TSS PERMIT command function. However, if USERA has been permitted IBMGROUP(PAYROLL) on MONDAY to FRIDAY from 9 a.m to 5 p.m., and the authorization exit in DB2 is driven on TUESDAY at 6 p.m., CA Top Secret does not return the IBMGROUP(PAYROLL) in the list of resource names to which USERA has been permitted.
In summary, you can replace secondary IDs with PROFILE ACIDs when:
When a user requests access to a particular DB2 resource, CA Top Secret Option for DB2 takes in the following considerations to determine if that user is authorized to that resource:
The first permission is the most explicit.
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|