Re: Privileges by session
Date: Mon, 11 Jan 2010 12:39:36 +0000
Message-ID: <5e317f311001110439x3d6fe931kc612ddf42dc1764c_at_mail.gmail.com>
Hi,
Something of a rock and a hard place going on here!
I would echo the advice below to use Oracle wallet. On a recent system I have worked on I created an account to hold all of the db objects and another account that we called the "runtime" user with the required grants. Then this runtime account was added to a wallet and that is what is used by the application code to access the database and the connection is always "/_at_<TNS_ALIAS>". OK so people who can access the app server can still get to the db, but only as the runtime user that cannot drop/create/alter objects.
Of course the lattitude to re-engineer what you have got is probably limited.
Regards
Pete
On Mon, Jan 11, 2010 at 8:21 AM, Pete Finnigan <pete_at_petefinnigan.com>wrote:
> Hi William,
>
> There are lots of issues here. The first is that as jared points out you
> must fix the hard coded password problem.
>
> There are plenty of solutions to this that might include:
> 1) have the password added by the SA's - not ideal as its still hard coded
> 2) use Oracle wallets and mkstore to avoid the need to pass in the password
> 3) use free software like opr.sourceforge.net to do similar
>
> definetly do not share passwords for the application between dev and prod.
>
> Use a firewall or valid node checking to ensure the app password is only
> used by the app. audit app use of system privileges and potentially
> connections from non-stanard IP's
>
> The next issue is there is no such thing as a read-only user. Any user
> is in the public group and in 11gR1 this includes 27,000 otehr
> privileges some of which can be used to escalate your privileges. This
> means its not read-only.
>
> Your ideas for restricting the read only accounts based on
> module/machine/IP etc are OK on a simple level. All these fields can
> easily be spoofed - search my blog for number of examples / links to
> papers on this.
>
> Lock the developer account and only open it when its requested - i.e.
> priority one bug that requires live data to resolve.
>
> Audit all system privileges on these read only accounts. Audit access to
> all objects in application schemas by these users.
>
> Use valid node checking to limoit their access from one terminal each.
>
> Use profiles to stop session duplication, careful use of resources etc.
>
> Secure application roles are a good approach as well as a trigger (bear
> in mind what I said about spoofing)
>
> cheers
>
> Pete
>
>
> Blanchard, William wrote:
> > Greetings,
> >
> > I have convinced management to allow me to grant read-only access to the
> > developers. The problem is that they know the application passwords and
> > have been using those passwords to circumvent my controls. Is there a
> > way via a trigger, role, etc to change individual sessions privileges so
> > they have read only (select) permissions? The easiest way would be to
> > change the permissions on the applications but that's not an option.
> >
> > Thank you,
> >
> > WGB
> >
> >
> > -
> >
> > This email and any information, files, or materials transmitted with it
> > are confidential and are solely for the use of the intended recipient.
> > If you have received this email in error, please delete it and notify
> > the sender.
> >
> >
> >
>
> --
>
> Pete Finnigan
> Director
> PeteFinnigan.com Limited
>
> Specialists in database security.
>
> If you need help to audit or secure an Oracle database, please ask for
> details of our courses and consulting services
>
> Phone: +44 (0)1904 791188
> Fax : +44 (0)1904 791188
> Mob : +44 (0)7742 114223
> 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. : 940 6681 14
>
> 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
>
>
>
-- Regards Pete -- http://www.freelists.org/webpage/oracle-lReceived on Mon Jan 11 2010 - 06:39:36 CST