To delegate privileges on objects that you own or authorities that you possess, DB2 enables you to grant a privilege to another user using the WITH GRANT OPTION clause. IDs that are granted a privilege with this clause can pass the privilege to other IDs. These privileged IDs are also able to give the WITH GRANT OPTION to other IDs. Because the privilege is delegated to another ID, this option can make it difficult for you to keep track of who has what authority over which resource. When a privilege is revoked from a particular user, the cascade effect causes that privilege to be revoked from all users who were granted the privilege by that user. This includes users who received it through the WITH GRANT OPTION (unless the privilege was received from another ID). The effect of a REVOKE command can be confusing and difficult to assess.
Suppose you give the UPDATE privilege (WITH GRANT OPTION) to the PAYMGR ID for the PERSONEL.EMPLPAY table:
GRANT UPDATE ON TABLE PERSONEL.EMPLPAY TO PAYMGR WITH GRANT OPTION
The PAYMGR ID then gives the UPDATE privilege for the PERSONEL.EMPLPAY table to the PAYCLK ID:
GRANT UPDATE ON TABLE PERSONEL.EMPLPAY TO PAYCLK
If you revoke the UPDATE privilege from PAYMGR because he has left the company, DB2 also revokes this privilege from the PAYCLK ID even though users of PAYCLK might still need this privilege (unless PAYCLK also received it from another source).
REVOKE UPDATE ON TABLE PERSONEL.EMPLPAY FROM PAYMGR
The BINDAGENT privilege gives you another method to delegate authority to bind plans or packages. When a user receives the BINDAGENT privilege from another user, the user can specify the grantor’s ID as owner of the plan or package that he is binding. The user with the BINDAGENT privilege, however, does not have any other authority over the plan.
The BINDAGENT privilege is intended to separate function, not to add security. A bind agent with the EXECUTE privilege might be able to gain all the authority of the grantor of BINDAGENT.
Through scoping and the %CHANGE and %RCHANGE control statements, you can easily delegate who can grant access to DB2 resources. Scoping lets you define which users with special logonid privileges (such as SECURITY or AUDIT) can alter or view CA ACF2 Option for DB2 rules. The %CHANGE and %RCHANGE control statements let you define in the rule set who can change rules. Users indicated by %CHANGE can add, change, or delete any rule entry or control statement in the rule set, including %CHANGE to let other users change the rule set. Users indicated by %RCHANGE can add, change, and delete rule entries, but cannot add, change, or delete any control statements in the rule set. When %CHANGE and %RCHANGE are used with scoping, these control statements add to the authority that scoping restricts from a user.
For example, the following rule enables PAYMGR to update the PERSONEL.EMPLPAY table and to change the rule, thereby giving others access. It also enables PAYCLK to select the PERSONEL.EMPLPAY table.
$KEY(PERSONEL.EMPLPAY) TYPE(TBL) $SYSID(****) %CHANGE ***PAYMGR UID(***PAYMGR) SERVICE(UPDATE) ALLOW UID(***PAYCLK) SERVICE(SELECT) ALLOW
Important! As with any security product, good controls are necessary. Since views can be used to access a table’s data and a view’s name might not reflect which table it is based on, you should control who can update a view and who can change view rules. This ensures that an administrator granting access to a view does not inadvertently grant access to a table that is inappropriate. For this reason, you might consider not scoping security administrators or using the %CHANGE or %RCHANGE control statements in view rule sets.
If you want to revoke the UPDATE privilege from PAYMGR, you can eliminate this rule entry from the rule set. By also removing PAYMGR from the %CHANGE control statement, you eliminate the possibility of PAYMGR giving UPDATE or any other privilege to anyone. Notice that PAYCLK still can retrieve data from the table.
$KEY(PERSONEL.EMPLPAY) TYPE(TBL) $SYSID(****) UID(***PAYCLK) SERVICE(SELECT) ALLOW
Therefore, to change (or revoke) the authority or privilege that the rule permits, just change, compile, and store the rule set.
Here is another example. Suppose SECOFF is a security administrator who is scoped to all databases that begin with PAY. SECOFF can access only a database rule set that has a $KEY that begins with PAY to grant access to another user. For example, SECOFF could change the following rule set:
$KEY(PAY.EMPLOYEE) TYPE(DBS) $SYSID(****) UID(***PAYMGR) SERVICE(UPDATE) ALLOW
See Controlling Privileged Users for more information and examples about scoping.
To use the BINDAGENT privilege in CA ACF2 Option for DB2, you must specify BINDAGENT and the logonid on whose behalf the plan or package is bound in the $KEY control statement. For example, to enable PAYCLK01 to bind a plan or package for PAYMGR (the owner), create the following rule set:
$KEY(BINDAGENT.PAYMGR) TYPE(SYS) $SYSID(****) UID(***PAYCLK01) ALLOW
This rule set lets PAYCLK01 bind any plan or package on behalf of PAYMGR, the owner of the plan or package.
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|