"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@xxxxxxxxxxx Sent: 16 March 2004 22:36
To: Jared.Still@xxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------
---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------
