Re: Back and a Question

In my experience you sometimes have to provide the rope and the appropriate people will hang themselves. In my current position I parse the listener logs to determine access and over a period of time I have been able to show that some of the developers abuse production access.

Then you may have to inform your manager that as long as access like this is available to the developers that you cannot be held responsible if issues come up. You can reassure him/her that you will be very diligent but cannot guarantee that someone doesn't perform an unrecoverable action without some down time.

Most of the time when you put the responsibility at the management level they will panic. Now I have a logon trigger that prevents this access or traces the session if it doesn't come from the application server. Not the best security bu sufficient enough to inform the developers that you know what they are executing. Once they know they are being watched they are much better about going into production.

Just my .02 ;-)

Mike

Niall Litchfield wrote:
On 8/15/06, Jared Still <jkstill@xxxxxxxxx> wrote:
There are no rules that state "developers cannot have access to production data"

we impose (actually I am trying to :( ) impose the rule that developers cannot have access to production *systems*. Sure they might need to see the data, or a subset thereof, to replicate an issue - though with appropriately written and instrumented software you should just need the logs :) - that doesn't translate into hacking around on production.
 

-- http://www.freelists.org/webpage/oracle-l

Other related posts: