Re: Trigger programme without a trigger.

David Gibbs wrote:

As I did with Chuck, I'll respond once more to you because after that it's just dead horse flogging. But I'm not sure if we're saying the same thing on some parts. Your primary argument seems to be that you can prevent accidents, but that you need outside access to your database. Specifically, it looks like you condone ODBC updates and want to use triggers to enforce your business rules. I have a serious problem with that, but that's at least a design decision, not a security one.

Then the person clearly doesn't have enough experience to be granted the authority.

But see, *nobody* should have the authority to update the production database (at least that's one school of thought). The only profile that can update the database is the one that the database programs adopt. And thus, unless that policy is subverted, nobody can accidentally update the database.

That's the problem with trying to prevent stupidity. You can't.

Of course you can't ... but you can prevent ACCIDENTS.

Yes you can. Secure your objects, only allow authorized access.

In a heterogeneous environment, this doesn't fly. The idea that only one user on one system can update a database is a thing of the past.

Says who? In my opinion, it's heterogenous environments that are demanding this level of control. An update should go through a stored procedure, not via direct access to the database. Heck, I don't even like external queries because they require outside knowledge of my schema and thus tightly bind the server to the client.

If you encapsualte your access in stored procedures, you can implement the security just as I've outlined.

The only thing that requires circumvention of the HSA profile is unfettered direct access to tables, which as I said I believe to be a really bad design. In most of the technologies I've seen, direct ODBC updates are a thing of the past. Everything is message based and clients know nothing about things like table and column names.

Sure it can ... put a flag in your trigger program that turns off the logic ... yes, the trigger fires, but the logic is bypassed. Obviously the flag source needs to be secured so the logic can't ACCIDENTALLY be turned off.

And this security can be accidentally removed just as easily. In fact, this seems even more dangerous because you don't know whether or not your trigger is working. Once again, it's not more secure. But I agree that you can get around the performance issues this way.

Unless of course, you have a way to remove the trigger programatically. Of course, the program that removes the trigger could be run "accidentally", thereby leaving you completely unprotected.

Accidents only happen in uncontrolled systems. Uncontrolled systems are a PITA. I've worked in enough to know this first hand.

And you can only update an HSA controlled database in an uncontrolled system. I guess I miss your point: if I've secured my database and my security is deployed properly, how do I accidentally update my database?

Joe