Re: User Security Question

Comments embedded.
On Nov 2, 12:32 pm, HectorTYC <rufus_mi..._at_btinternet.com> wrote:
> Database version: 9.2.0.6.0
> OS = Solaris 8
>
> I currently work for an organisation that continually shoots itself in
> the foot with the large amount of unauthorised changes it makes to the
> production database of the main business application. These changes
> are being made by a motley bunch of devlopers, support analysts ...
> pretty much anyone who feels like it really.

Is this a 'home-grown' application or one supplied by an outside vendor? If the latter are the vendor representatives also making these changes?

>
> To make matters worse they are doing this using the main schema
> account (please excuse me if I mangle terminology, I'm not a DBA) used
> by the application itself, thus leaving no audit trail of who has made
> these changes.

Unfortunately it's necessary to use the owner account to modify objects (in the absence of DBA or SYSDBA access), but I understand your problem. There are possible workarounds, however, such as DDL triggers which could populate a table with the 'identifying' information for the session, such as IP address, program used, etc. You should look at:

http://www.psoug.org/reference/ddl_trigger.html

for examples of such triggers.

> All show as being the application that has made the
> change, rather than some nut with Toad and a cavalier attitude as is
> more often the case. Worse; tracing (?) is not turned on so that info
> is even more limited than it could be.

SYS_CONTEXT() can be your friend, as it can return IP Address, Host, and other useful information about the connected session.

>
> I am aware of how bad this is m'kay (on any number of levels) but
> until I can persuade/force the organisation to plough resource into
> what is quite a large undertaking, simply changing the password is an
> appealing but not viable option.
>

That shouldn't be necessary; a robust DDL trigger just might be all you need to track down who is doing what and when. Then it's up to you to log how much trouble this change created.

> As an interim measure I am resigning myself to attempting to force
> people not to use this account using policy and a mixture of begging
> and loud tutting, however I'd be interested to see if anyone out there
> has any clever suggestions as to how I could stop people using the
> application user account without making changes to the account or
> incurring any DB downtime. I did wonder if it was possible to allow
> connections by this user from only a list of trusted sources but our
> DBA thinks this isn't possible.

It isn't, really. Look into the DDL trigger option and see if that will meet your needs.

David Fitzjarrell Received on Fri Nov 02 2007 - 14:14:49 CDT