Re: Privileges by session

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