Re: Morbid curiosity about a V7R2 feature.

Actually this support is real-time - it's connected with function usage (WRKFCNUSG), which is what we know as Application Administration in Navigator, just a lot more.

It is definitely proactive.

One need only look at the 7.2 documentation and see this in the Security "What's New" -

"A new DB2® for IBM® i function usage identifier can be used to deploy separation of duties. The function identifier, QIBM_DB_SECADM, provides a user with the ability to grant authority, revoke authority, change ownership, or change primary group, but without giving access to the object or, in the case of a database table, to the data that is in the table or allowing other operations on the table."

HTH
Vern

On 5/12/2014 6:40 PM, James H. H. Lampert wrote:

On 5/12/14 4:16 PM, Mike Cunningham wrote:

Routine audits of the system audit logs looking for an security admin
who gave themselves access to a file they don't need to access

Hmm. By which time said admin would have probably had plenty of time to get his or her hands into the cookie jar. Sounds "REactive, rather than PROactive," and not much of an improvement over those same audits catching the rogue admin actually ACCESSING the data.

Seems to me that a proper implementation would be like the usual drill of two keys needed to access a safe deposit box: to grant a new user access to the restricted object, one ought to need BOTH a user WITH access to the object, and a user able to GRANT access to it, to sign off on the authority.

Of course, up through V7R1, they would by definition be the same user.

--
JHHL