Re: CREATE DATABASE LINK privilege discussion

Why dont you set up valid node checking on the production server and refuse connections from the dev servers. that way they can create as many links as they want but they wont be allowed in!

The issue also "implies" that he has the password for an account in PROD, most sites I work for do not allow dev access to prod. If the connection is used a connected user or concurrent user then it also imples shared passwords.

You may be better attacking the issue from the point of view of whihc account they access in prod. If its a dev account then question qhy its necessary; if its not then question why access is allowed to dev to remove data from prod; why is it not obfuscated. Also test the level of privs on the account used. use my
http://www.petefinnigan.com/find_all_privs.sql script and question every priv.

Question also why there is a "dynamic" nature to this; i.e. why does he need to keep creating links. Maybe its better to create a single link and control the password (dont use connected user or concurrent user as they imply sharing of passwords and hence "other access is possible", its better to use a specific password for a private link and you create it and control it. then allow only access via this link to an account that just does exactly whats needed only when its approved and then block the access to the link when its not needed - lots of possible ideas, revoke create session, ddl trigger, valid node checking... that way you cintrol access not them and if you dont stop them doing their job but control it you cannot be wroing.

maybe also even create a PL api that controls the access to the link so only allowing very specific actions

Also test what public links or private from the connected account exist in prod. A good hack is to connect to prod and find a better link in prod and then connect back to the same database or another with better privs!

hth

cheers

Pete

Taylor, Chris David wrote:
> I am curious how many of you grant your developers the 'CREATE DATABASE LINK' privilege in 10g or higher?
> We have a production read-only account that is setup to provide support for troubleshooting production support issues and one of my developers (out of approximately 20 devs) created a database link from a development database to production for his application.
>
> Now, this is fast becoming an issue and he keeps complaining that he needs that privilege and that he should be able to create as many database links as he wants - wherever he wants (for those environments he has access to including the production support ID).
>
> We (as an organization) have been sloppy in the past in granting 'CREATE DATABASE LINK' but thankfully we have developers who normally understand that you shouldn't use it to create links to a production support id for app dev.
>
> So how do you handle it? Is there a good document on what privs app devs should 'typically' have? A good industry standards doc or some such?
>
> Thanks,
>
> 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.
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

-- 

Pete Finnigan
CEO and Founder
PeteFinnigan.com Limited

Specialists in database security.

Makers of PFCLScan the database security auditing tool.
Makers of PFCLObfuscate the tool to protect IPR in your PL/SQL

If you need help to audit or secure an Oracle database, please ask for
details of our training courses and consulting services

Phone: +44 (0)1904 791188
Fax  : +44 (0)1904 791188
Mob  : +44 (0)7759 277220
email: pete_at_petefinnigan.com
site : http://www.petefinnigan.com

Registered Office: 9 Beech Grove, Acomb, York, YO26 5LD, United Kingdom
Company No       : 4664901
VAT No.          : 940668114

Please note that this email communication is intended only for the
addressee and may contain confidential or privileged information. The
contents of this email may be circulated internally within your
organisation only and may not be communicated to third parties without
the prior written permission of PeteFinnigan.com Limited.  This email is
not intended nor should it be taken to create any legal relations,
contractual or otherwise.

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