Mike:
I think you were suggesting option #3 - stored procedures.
I'm planning on using the DB2 Recovery Expert to keep track of who makes
changes, but that will only catch "rogue" Insert/Update/Deletes after they
are made. Your suggestion of using triggers would accomplish the same
thing.
What I want to be able to do is to prevent users from running unauthorized
applications to Insert/Update/Delete on the database. If they can find the
Stored Procedures, and they have Execute privilege on them, I'm pretty
sure they will be able to run them whether they use the authorized or
unauthorized application.
(I define an unauthorized application as one created by someone who is not
part of the app/dev team, who has decided to just write their own.)
Tony
==============================
Anthony Schmidt
President
The Computery Ltd.
One East Main Street
Bay Shore, NY 11706
631-665-8100 Voice
631-969-5988 Fax
http://www.computeryltd.com
----- Forwarded by Anthony Schmidt/BayShore/SGU_LN on 04/28/2005 03:35 PM
-----
"McNeer Mike " <db2udbdba-ezmlmshield-x17679185.[Email address protected]
04/28/2005 03:13 PM
To
"LazyDBA Discussion" <[Email address protected]
cc
Subject
RE: Securing the database from "rogue" developers using tools like MS
Access
Not knowing all of the details..The limited security option is the best
way to go. If you are wanting to track or audit the users updates, use
triggers on the tables that populate or defaults to track userid. You
should be able to add a field such as change_user and have it default to
the userID
MM
-----Original Message-----
From: Anthony Schmidt
[mailto:db2udbdba-ezmlmshield-x83592943.[Email address protected]
Sent: Thursday, April 28, 2005 1:47 PM
To: LazyDBA Discussion
Subject: Securing the database from "rogue" developers using tools like
MS Access
I posted a question regarding this about a month ago and there seemed to
be three solutions to this.
One was using application security - but this doesn't support tracking
updates by user name
Two was using a broker application to track application usage - but this
requires the purchase of a third party program
Three was to provide only Select privileges to the users, but use stored
procedures to provide Insert/Update/Delete capablities.
I'd like to use the option #3, but it occurred to me that users can
still
run the stored procedures with "rogue" applications they may write. Is
there any way to prevent that?
Tony
==============================
Anthony Schmidt
President
The Computery Ltd.
One East Main Street
Bay Shore, NY 11706
631-665-8100 Voice
631-969-5988 Fax
http://www.computeryltd.com
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
---------------------------------------------------------------------
PLEASE CLICK REPLY-ALL TO SEND A REPLY TO EVERYONE
website: http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
---------------------------------------------------------------------
PLEASE CLICK REPLY-ALL TO SEND A REPLY TO EVERYONE
website: http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
DB2 & UDB email list listserv db2-l LazyDBA home page