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."
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.