| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Database security
"Hvem vogter på ledvogterens datter, mens at ledvogteren vogter led?",
as said by the Dane Osvald Helmuth many years ago.
In translation: "Who is keeping the gatekeeper's daughter while the gatekeeper is keeping gates?"
In 7.1 they began to leave this veeeery small tracefile everytime someone had connect as internal. But that's easy to remove by said person anyway. It did make the auditors happy, though.
Something has to give here: Either the SA is only A (and the DBA becomes the real king on the system) - or you have to trust someone, somewhere.
Mogens
Niall Litchfield wrote:
> Hi Jared
>
> In the end I don't think that there are any 'technical' solutions to stopping SA staff from gaining complete control over a database. On any OS. I think it has to be policies and procedures. Isn't there also a rather simpler drawback to the approach you mentioned, just move the password file and use orapwd to recreate a new one with the password of your choice. :( The fundamental thing about technology security ISTM is that you don't rely on the technology for security, it gives a false sense of assurance. Obvioulsy this isn't a recommendation to leave the system insecure :(
>
> Niall Litchfield
> Oracle DBA
> Audit Commission
> +44 117 975 7805
>
>
>>-----Original Message-----
>>From: Jared.Still_at_radisys.com
>>Sent: 16 March 2004 22:36
>>To: Jared.Still_at_radisys.com; oracle-l_at_freelists.org
>>Subject: Database security
>>
>>
>>List,
>>
>>Here in the midst of Sarbanes Oxley, I've been pondering methods
>>that might be used to prevent a system administrator from connecting
>>to any databases running on that box.
>
>>I know that it is possible to setup Oracle on Windows so that without
>>a password, you cannot logon to the database as sysdba.
>>
>>eg. sqlplus "/ as sysdba" will require a password.
>>
>>The caveat to this is that the SA can simply:
>>
>>* stop the Oracle service
>>* change the init.ora parm remote_login_passwordfile to 'none'
>>* start up the database
>>* create a dba account
>>* shutdown the database
>>* re-enable the password file
>>* restart the database
>>
>>That won't get you SYSDBA, but it will get you DBA, which is probably
>>enough
>>for any nefarious activities.
>>
>>On *nix it is a bit different of course. Anyone with root
>>can simply su
>>to oracle.
>>
>>I have been perusing Pete Finnigan's "Oracle Security
>>Step-by-Step" but
>>have
>>not yet found information pertaining to this particular
>>topic, other than
>>revoking
>>privs from the DBA account. That action is not applicable
>>here, as the
>>team of
>>DBA's consists of me by myself.
>>
>>And TIA Mladen, but I already know how it works on unix, and
>>that MS is
>>the
>>dark side of the force, but is unfortunately what I have to
>>live with.
>>
>>Jared
>>
>>
>
>
>
>
> **********************************************************************
> This email contains information intended for
> the addressee only. It may be confidential
> and may be the subject of legal and/or
> professional privilege. Any dissemination,
> distribution, copyright or use of this
> communication without prior permission of
> the sender is strictly prohibited.
> **********************************************************************
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Thu Mar 18 2004 - 00:38:38 CST
 |
 |