Re: Trigger programme without a trigger.

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

CRPence wrote:
>    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.
>   
I'll disagree once more just to reiterate my point, and then move on.

It is no more likely to accidentally get around high-security access 
profile than it is to accidentally remove a trigger.  Both require 
subverting security policies which *should* be incapable of being 
subverted.  Otherwise, they're really not security policies.  That 
either one could happen is an abject failure of the system.

Remember, I'm talking about a specific architecture in which the 
database can only be accessed through a specific user profile.  
Subverting that requires an security breach as egregious as that which 
would allow removing a trigger.  A properly deployed security system 
prevents both.  Improperly deployed security prevents neither.

So, in the end, the data protection aspect of trigger vs. I/O module is 
moot: both work exactly the same, and both depend on a properly deployed 
security policy.  And thus the choice between the two should come down 
to an application-driven business decision.

This is simple stuff.  Rather than designing systems based on 
theoretical security lapses, you should instead deploy your systems 
correctly.  If you disagree, then fine.  I can leave it at that.  But 
it's a fallacious argument to say that triggers protect data any better 
than HSA profiles.

Joe