CA ACF2 Option for DB2 provides many benefits to DB2 users. Among them, it provides a single security architecture, enhances the DB2 concept of ownership, makes security administration easier and separate from the database administration function, and limits use of the administrative authorities.
CA ACF2 uses a single security architecture across z/OS and its subsystems to identify users and resources and to control and monitor events that should be audited. A unique CA ACF2 logonid identifies you when you access a resource in z/OS, CICS, IMS, or DB2. CA ACF2 uses the user identification string (UID) to authorize access to all resources whether they exist in z/OS, CICS, IMS, or DB2. This UID identifies which user or groups of users can access a resource. CA ACF2 Option for DB2 reduces high maintenance and security authorization costs because each user needs only one ID, regardless of what systems or applications he uses. However, CA ACF2 Option for DB2 supports secondary authorization IDs, just as DB2 does.
With CA ACF2 Option for DB2, you assign ownership of an object in an CA ACF2 Option for DB2 rule. Unlike DB2 security, ownership is not influenced by what privileges or IDs you are associated with when you create an object or whether you create it with dynamic or static SQL. For more information about ownership, see the “Comparing DB2 and CA ACF2 Option for DB2 Features” chapter.
You can also change ownership of an object without dropping the object. The privileges that you assign to an ID and the object itself are not lost as they are when using native DB2 security. All you have to do is change the CA ACF2 Option for DB2 rule that assigns ownership, reprocess (that is, compile) it, and store it again in the Infostorage database.
Because you no longer control privileges with GRANT and REVOKE statements, the cascade effect of the REVOKE statement is eliminated. The cascade effect causes other users to lose their privileges when the granting user’s privileges are revoked. With CA ACF2 Option for DB2, you can easily revoke privileges of terminated or transferred users without worrying about affecting other users’ privileges.
The UID identifies which groups of users can access your resources. If you use secondary IDs to grant access to a group of IDs to avoid the cascade effect, you might be able to use the UID to eliminate the overhead of maintaining and checking secondary authorization IDs. You can share rules across DB2 subsystems and eliminate the need for duplicate rules. This simplifies the rule writing and maintenance process because you maintain them on only one system. You can use ISPF panels to create and administer CA ACF2 Option for DB2 rules and records.
DB2 makes it difficult to separate security and database administration functions partly because objects must exist before you can grant them privileges. This can create an administrative burden for security administrators because they must respond immediately to requests from DBAs to secure resources. In CA ACF2 Option for DB2, rules control access to resources and are separate from those resources. So you can create rules for a resource before the resource exists.
Some sites let DBAs assign security privileges. Often, auditors view this as a “separation of function” problem. CA ACF2 Option for DB2 enables you to separate the security and database administration functions to suit your site’s needs.
Because the DB2 authority called SYSADM (System Administrator) has complete control over most DB2 resources, it would be wise to carefully limit and monitor its use. Unlike DB2, CA ACF2 Option for DB2 provides a facility that limits certain privileged users to whatever resources you prefer. This facility is called scoping. Using scoping and logging, you can tightly control use of the SECURITY and AUDIT logonid privileges when they are used on DB2 resources.
CA ACF2 Option for DB2 supports all categories of DB2 privileges and authorities. It controls the use of privileges and authorities through CA ACF2 Option for DB2 rules. It provides a similar level of granularity as these DB2 security privileges, but you also have complete control over who is granted these privileges.
The %CHANGE and %RCHANGE control statements in the CA ACF2 Option for DB2 rule set replace the WITH GRANT OPTION, a DB2 option that enables you to pass privileges to other users. %CHANGE and %RCHANGE let you designate who can change rules and grant privileges, without worrying about the cascade effect.
You can limit access to specific DB2 resources by time of day, day of week, date, or number of days. You can create SMF records for all accesses to a resource or for all accesses by a user, as you prefer. In this way, all violation records for the entire operating system are recorded in one place. Reporting facilities can tell you who can access a particular resource, what resources a particular user can access, the type of resource access (logging, violation, or trace), and who is updating DB2 infostorage records and CA ACF2 Option for DB2 rules.
|
You can phase in security by: |
|
|---|---|
|
Rule set |
Using the $MODE control statement in CA ACF2 Option for DB2 rules. |
|
Resource |
Altering the mode in the OPTS infostorage record. |
|
Subsystem |
Selectively activating each subsystem’s OPTS infostorage record. |
With the DB2 prevalidation and postvalidation exits, you can change CA ACF2 Option for DB2 processing to suit your site’s needs and environment.
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|