CA ACF2 protects your z/OS operating system from access by unauthorized individuals. It does this by requiring each user to identify themselves using a logonid and password when they first access the system. Logonids are records stored in the Logonid database. The logonid that a user enters is the key to the logonid record. CA ACF2 checks the logonid record to determine whether:
To access a DB2 subsystem, you must be defined to the CA ACF2 Logonid database. Even though you do not sign directly on to a DB2 subsystem, CA ACF2 Option for DB2 associates you with your DB2 session through your CA ACF2 logonid. This logonid becomes your DB2 primary authorization ID unless a DB2 exit changes it. In most cases, you already have a logonid defined because you use it to sign on to TSO, CICS, or IMS. To add, modify, or delete logonids, use standard CA ACF2 processing under the LID setting of the ACF command. See the CA ACF2 Administrator Guide to learn about administering logonids.
When you connect to DB2, DB2 issues a System Authorization Facility (SAF) call. A DB2 exit can then associate you with multiple secondary authorization IDs. CA ACF2 Option for DB2 verifies all of these IDs, whenever required.
Once connected to DB2, you can access a resource only if a rule permits access or your logonid is privileged. You can give logonids special privileges to perform certain administrative security functions. These privileged logonids can access data that is not their own and for which rules are not written.
All violations and statistics are recorded against logonids to ensure individual accountability. Access to DB2 resources, however, is validated against the user identification string (UID). The UID enables you to give access to resources according to groups of users defined by your organization. This string is explained further in the next section, “What is a UID?”
Under native DB2 security, DB2 security administrators can use secondary IDs to simplify DB2 security administration. Secondary IDs enable more than one user to exercise ownership privileges over a group of objects. With secondary IDs, users can easily obtain additional privileges in a DB2 subsystem without these privileges being granted specifically to them. This eliminates the need to revoke privileges from users who are terminated or transferred, which in turn eliminates the cascade effect. With secondary IDs, security administrators maintain only who has access to the secondary IDs and do not have to worry about revoking privileges from the wrong people.
You can use the architecture of secondary IDs for other purposes than to obtain the privileges of a group authorization ID for resource access. For example, you can design applications that use unqualified table names so that users can access different versions of the table by changing the current SQL ID. However, if you do use secondary IDs strictly to grant access to group authorization IDs and to avoid the cascade effect, you might be able to use the UID in CA ACF2 Option for DB2 rules rather than use secondary authorization IDs (see below). You might want to do this because secondary IDs can blur the lines of individual accountability, which is central to CA ACF2 philosophy. CA ACF2 Option for DB2 uses logonids at connection time to uniquely identify users. A unique logonid prevents one user from posing as another and makes it possible for CA ACF2 Option for DB2 to trace activity to a specific individual.
While the logonid identifies individuals at connection time and in reports, CA ACF2 Option for DB2 uses the user identification string (UID) to determine who can access a resource. For CA ACF2 Option for DB2, the UID accomplishes the same results as a secondary authorization ID when it is used to group IDs for resource access. The UID enables a user to access resources based on the user’s UID values assigned to him. The section entitled “What is a UID?” explains the UID further. The UID in CA ACF2 Option for DB2 eliminates the cascade effect and thus one of the reasons to use secondary IDs.
If your site has already defined secondary authorization IDs and wants to continue using them, CA ACF2 Option for DB2 supports the use of these IDs. See the CA ACF2 Option for DB2 Getting Started for information about using these IDs with CA ACF2 Option for DB2.
CA ACF2 uses logonids to validate which users can sign on to a system. Once signed on, users can access only the resources that rules permit them to access. However, special logonid privileges enable users to perform certain administrative security functions without specific rules. If CA ACF2 identifies you as a special user, such as an account manager (that is, the ACCOUNT field is specified in your logonid), you can add certain privilege fields to a user’s logonid. To make someone an account manager, you must be a security administrator (designated by the SECURITY field in your logonid record).
Of all the privilege fields available to CA ACF2 users, only the NON‑CNCL, SECURITY, and AUDIT privileges apply to users of DB2 and CA ACF2 Option for DB2 security information. Users with these privileges are able to process CA ACF2 Option for DB2 security information as follows:
Access to all DB2 resources. CA ACF2 Option for DB2 will log access, but cannot cancel this user.
Access to all DB2 resources and CA ACF2 control information. This user can insert, change, list, and delete any CA ACF2 Option for DB2 rule and record in his scope. Because of this, he can access all tables, plans, and any other DB2 resources in his scope.
List all CA ACF2 Option for DB2 rules and records. This user has no special privileges to access tables, views, or other DB2 resources. However, he can list all CA ACF2 Option for DB2 rules to determine who is granted access.
You can restrict the authority of the SECURITY and AUDIT privileges through scoping. Scoping places limits on the rules and records that the privileged user can access. You define these limits in scope records, which are stored in the Infostorage database. When a privileged user tries to access a resource or change a record, CA ACF2 Option for DB2 uses the scope records to determine whether the resource is in his scope. You can use standard CA ACF2 processing under the SCOPE setting of the ACF command to administer scope records. See “Controlling Privileged Users,” for more information about administering scope records in CA ACF2 Option for DB2.
Other privileges that affect the security databases (for example, ACCOUNT) are not explained here because they do not affect CA ACF2 Option for DB2 security information. See the CA ACF2 Administrator Guide for complete explanations of these privileges.
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|