Using RACF To Control Access To DB2 Objects

5 Pages

Ever since the release of DB2 Version 5 and OS/390 Version 2, Release 4, you have had a choice of how you protect your DB2 resources: native DB2 controls or RACF. An effective DB2 security implementation using RACF requires close coordination between your DBA team and your security implementation (RACF) team. This article describes the security mechanisms available with RACF.


Since its release in 1983, DB2 has provided an extensive set of security controls for the data it manages. For each of the DB2 constructs—such as database, table, view, or storage group—a specific set of privileges exist. For example, to manage data in a table, you could SELECT, INSERT, UPDATE, or DELETE a record. You control who can perform these operations using the SQL GRANT and REVOKE statements. In Figure 1, the SELECT privilege on the tables EMPDATA.POSITION and EMPDATA.SALARY is granted to MNELSON, ALOBO, and RLOVE.

A user’s authority can be removed using the REVOKE statement. Figure 2 shows that user MNELSON’s SELECT on the EMPDATA.SALARY table has been removed.

DB2’s access controls are quite granular. For example, users may be granted INSERT on a table, which permits them to add new rows, but not change existing rows (UPDATE), remove rows (DELETE), or read rows (SELECT).

DB2 takes great care to ensure that the integrity of its security information is maintained. That means if a table is dropped, then all the access rules for the table are dropped. From a database consistency viewpoint, this makes perfect sense. However, from a security management perspective, this makes life more complex. If you have any access rules defined on the table, you must manually save their content and then re-create them using the GRANT statement. Notice that you cannot define the access lists before the table exists. Fortunately, DB2 does not grant access to any resource by default, other than to the object owner.

DB2 does not have a mechanism to assign the same access controls to multiple DB2 objects without replicating the access rules. If the SALARY and POSITION tables had the exact same user access requirements, we would still have to create two separate access lists, one for each table.

DB2 allows the owner of a privilege to pass that privilege on to others if they are so authorized by the WITH GRANT option on the GRANT statement. However, if the original owner of the privilege loses his privilege, then anyone who has been granted the privilege by the original owner loses the privilege as well; this is known as a cascading revoke. Once again, from a database purity viewpoint, revoking these privileges makes sense. From a security viewpoint, it just makes life a bit more difficult.


5 Pages