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@gmail.com> 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
Received on Wed Aug 16 2006 - 18:52:56 CDT