Re: Trigger programme without a trigger.

CRPence wrote:

However it takes only that one person using either a special profile or a special tool that gives the developer or implementor all-access to /fix something/, or an accidental equivalent granting of rights to a user due to error(s) in security implementation, for the expected access method to be bypassed on the production system; such a bypass need not even be malicious.

This is a bit of a red herring, because if you can bypass authority then you can bypass triggers: all it takes is an "accidental" RMVPFTRG. If your environment is such that people have access to high security profiles, then there's no way to protect your data. Your accidental granting of rights is equivalent to accidentally granting QSECOFR rights; no amount of security can prevent you from a security failure that egregious.

Basing your architecture on the fact that you can't enforce your own security rules seems to me to be a bad way to do things.

FWiW I also prefer that the owner of the database to be a peon user, so that any program adopting the authority of that owning user, for the purpose of accessing the database, does not also obtain access to anything beyond what the active user for the job is already authorized.

Agreed. The owner of the database ought have no authority except to the data. That's what they do, and that's all they do.
Joe



Editorial note:

Now, if you absolutely must,
you can grant read <ed: "access" inferred vs "writes"> writes
so people can do external queries. That's up to you. But there is
simply no reason to have unfettered update writes to your database.
If you've created a perfectly good database access mediator such as
the I/O module mentioned, then by all means lock the database down -
you will have shut the door on a lot of gremlins.

Actually I somehow managed to type "writes" twice instead of "rights".

Joe