Re: Trigger programme without a trigger.

Yes, a bit. And only a bit of a red herring, because it is all about the difference in the range from presumed-innocuous to an intent of maliciousness, in the actions being performed. If someone is charged with correcting the data in the file, they are probably not a developer because they are appropriately disallowed from the production system. As such an implementor may just use DFU or SQL to make the correction [possibly /ignoring/ scripted recovery actions; if even the developer was involved to ensure proper recovery], in their attempt at convenience and expedience, rather than with any malicious intent.

That is my point in suggesting that the whole concept is based on the *assumption* that the rules can and will be able to be enforced. It is the requirements to both establish and then ensuring the established procedures are followed, beyond just security, that limit the general ability to control the access to the file unilaterally. Requirements are functional for their intent, only when understood and followed.

And so it is very true, that the same concern exists as an issue with the database trigger, e.g. some result is not to the satisfaction of the implementor, so when they find the trigger they CHGPFTRG to disable it while they do their magic to correct the data. However in the case of either CHGPFTRG or RMVPFTRG, the implementor should at least *know* they are bypassing the business rules. That as compared to accidentally [not "accidentally"] bypassing the business rules, which is much more likely to occur with I/O access control established outside the database. The trigger is visible, whereas an application as expected arbiter to the I/O is not so plainly obvious. The trigger can be found and subverted, but even overlooked, it is still enforced. However the application as arbiter may be easily overlooked as a result of either human error or negligence, and overlooked, it will not be enforced.

Regards, Chuck

Joe Pluta wrote:

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