RE: CREATE DATABASE LINK privilege discussion

  • From: "Taylor, Chris David" <ChrisDavid.Taylor@xxxxxxxxxxxxxxx>
  • To: 'Guillermo Alan Bort' <cicciuxdba@xxxxxxxxx>, "'david.robillard@xxxxxxxxx'" <david.robillard@xxxxxxxxx>
  • Date: Mon, 31 Oct 2011 07:28:02 -0500

Interesting approach.  I've actually never worked in a US corp where the dev 
servers couldn't talk to the prod servers.  Even in very large financial 
organization.  Is that "normal"?  I can totally understand the 
advantages/disadvantages though.

Chris Taylor
Sr. Oracle DBA
Ingram Barge Company
Nashville, TN 37205

"Quality is never an accident; it is always the result of intelligent effort."
-- John Ruskin (English Writer 1819-1900)

CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and 
may also be privileged. If you are not the named recipient, please notify the 
sender immediately and delete the contents of this message without disclosing 
the contents to anyone, using them for any purpose, or storing or copying the 
information on any medium.

From: alanbort@xxxxxxxxx [mailto:alanbort@xxxxxxxxx] On Behalf Of Guillermo 
Alan Bort
Sent: Sunday, October 30, 2011 2:44 PM
To: david.robillard@xxxxxxxxx
Cc: Taylor, Chris David; Michael Dinh; oracle-l mailing list
Subject: Re: CREATE DATABASE LINK privilege discussion

I think the problem runs deeper than the "create database link" privilege. You 
physically shouldn't be able to access prod from dev. They should be in 
separate networks (different data centers if possible) and firewalls should 
prevent any access to the production database servers that does not come on the 
listener port from the application servers or on ssh and listener ports from 
the DBA's machine (a VPN group, perhaps?). This may present ever you with a bit 
of a headache, but security comes first.

Also, putting some fear of THE EVIL PIRATE NINJA HACKERS into your managers' 
minds would help you somewhat to achieve tighter security in your database 
environments. So just casually mention that you've been reading up on security 
and that there are a few modifications you'd like to make to the current 
security policies (hardening) and casually leave a newspaper clipping about the 
latest Anonymous hack or whatever. As David so eloquently put it: your problem 
is political, then fight politically.

Also, having the password for that use change every say, 15 days, with about a 
full day to unlock it should it ever become locked and a 10-wrong password 
attempts limit in the profile would probably prove too much of a haggle for the 
developers... then again, it could cause you some political trouble and without 
a clearly defined security policy you could be "ordered" to remove this 
security measures from this particular user by a manager.

Ultimately, it's the managers' decision, you can alert them of what's 
happening, and keep it well documented (e-mail history, etc) and when they call 
you in the middle of the night because "production is very slow" you can reply 
with "I told you so, now, will you let me do what needs to be done?"

Also, being a DBA is much more than knowing how to manage a database... It's 
been my experience that EVERYBODY blames the database... noboy really asks for 
hard evidence when a developer says "the database is slow" or when a system 
admin says "the OS is fine, must be a database bug". But when you say "the 
interconnect is failing and here I have the logs that show it" they are always 
"hmm, I'm not sure, perhaps you can open a case with Oracle"... so you need to 
know how to handle people and how to manage managers... which is kind of 
ironic, and some would say manipulative... but who ever said life is fair?

Hth
Alan.-

On Sun, Oct 30, 2011 at 4:13 PM, David Robillard 
<david.robillard@xxxxxxxxx<mailto:david.robillard@xxxxxxxxx>> wrote:
Hello Chris,

> I'm in full agreement.  I'm fighting a losing battle it 'seems' with dev's 
> manager too - which is weird.
> It is exceedingly strange that 1 Dev complaining about not having access to 
> Production data is reflecting negatively on my image/reputation.
> Suddenly I becoming that "guy who is hard to work with" because I'm insistent 
> that this shouldn't be done.
You unfortunately have a political problem, not a technical one :S

This situation looks like you'll need to get your social skills
working. That one dev complaining is probably the manager's friend
and/or has a bigger audience then you. So IMHO should talk to this one
dev in particular and try to understand exactly why he says he needs
this link. Once you understand this, you can try to find another
solution which would not have the db links and still allow him to
work. Then I would go talk with the manager directly telling him that
you a) did talk with this dev guy, b) why you don't think that
granting a dev to create a database link from the dev to the prod
systems is a good idea (get some references from books, best
practices, etc) and c) the solution which would allow the devs to work
without dev to prod db links.

If you have a different manager then the dev one, get him involved as
well. If you're friend with the manager's manager, try to get him on
your side. If upper management is on your side, then you should win.
If you have an I.T. security division, talk to them. They can even
find out the Oracle database links best practices for you and explain
it to the devs and the managers (it's their job, so why not let them
do your work ;) If your production system has some sensitive
information, then explain to the security guys that the devs might be
able to create db links to the production sensitive info. That should
work wonders!

> And for the very reasons you mentioned.  I even snapped a screenshot from 
> Grid Control of the activity his session alone was generating.
That's perfect, it's exactly the kind of hard evidence you need to
show both the devs, the manager and the security guys. If the manager
has any common sense, he'll see the negative impact on production
machines.

> Frustrating.

Yeah, big time! Keep you cool, it's the only way to win this one.

And good luck!

David

> Chris Taylor
> Sr. Oracle DBA
> Ingram Barge Company
> Nashville, TN 37205
--
//www.freelists.org/webpage/oracle-l



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

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 10-2011