Re: CREATE DATABASE LINK privilege discussion

> 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.

That's how we work here too. As Guillermo explained, our production systems live in seperate DMZ networks isolated by firewalls. So we have a internet facing DMZ, an application server DMZ and a database DMZ (and quite a lot other networks). The dev/test/pre-production systems don't have direct access to the production DMZs. Only the specific application servers and admin machines have access to the production systems. We also audit database and application server connections and send the logs via syslog to our centralised syslog system. Connections are encrypted and we use Kerberos to authenticate NFS mounts and users. We also use the data masking pack to protect sensitive data when we refresh the dev/test/pre-production systems with production data. And of course, our dev team doesn't have access to production!

It sure is a more complex network to work with and understsand. Good communcation is the key here. When a new employee is hired he or she needs to learn how to navigate these restrictions and thus requires a higher level of network skills. To help people understand all this, we've prepared a presentation which explains how things work and we take an hour or so with each new employee to help them integrate all of this. People usually appreciate this presentation. It also means that we often need to implement production changes with the dev team and the admins working close together.

Of course, as Guillermo says, we can always improve on this design from a security stand point. We could run our systems with SELinux in enforcing mode, we could filter IP addresses in our listener, use the database firewall and run an IDS/IPS for example. But hey, there's so much we could achieve if we didn't have new projects all the time right? ;)

Also, as Bill said, good CYA is important. Make sure you have policies written down and approved by management. You can't achieve anything if you don't have top management written approval (well, you could, but it's usually harder).

Finally, if you're looking to help your security team understand Oracle security, you can start with the Center for Internet Security Oracle Benchmarks [1] and David C. Knox's books [2]. Don't forget the official Oracle documentation security guidelines too [3]. And many more of course, but that's a start.

HTH, David

[1] http://benchmarks.cisecurity.org/en-us/?route=downloads.browse.category.benchmarks.servers.database.oracle
[2] http://community.oraclepressbooks.com/profile.php?aid=76
[3] http://download.oracle.com/docs/cd/E11882_01/network.112/e16543/guidelines.htm#CHDCEBFA

--
David Robillard
http://www.linkedin.com/in/davidrobillard
http://itdavid.blogspot.com/



> 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_at_gmail.com [mailto:alanbort_at_gmail.com] On Behalf Of Guillermo

> Alan Bort

> Sent: Sunday, October 30, 2011 2:44 PM

> To: david.robillard_at_gmail.com

> 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_at_gmail.com>

> 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

>

> --

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

>

>

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