jared, no answers... but I did read to the end. Thank YOU, you've given me a lot to think about and to talk to our hosting company about.
What really scares me is that I have no way of auditing the hosting company.... who have total access to production. Rachel --- [EMAIL PROTECTED] wrote: > Dear list, > > Let me toss a hypothetical situation at you. > > Say some auditors looked at some of your primary systems, > and concluded that they had no assurance that someone with > admin access to the server had not changed financial information > to benefit themselves, or to falsify financial records for the > gain of the company. > > Not that they might have any proof that something like that > had been done, but rather, just not proof that it had *not* > been done. > > I've been pondering this for a bit, and it seems to me that if > someone had good knowledge of both the OS and the > database (Oracle), as well as having admin rights on the > server, there are few things you can do to prevent such a person > from changing data in the database, and completely > covering his or her tracks. > > The platforms in question are Unix, Windows NT and > Windows 2000. I've limited it to those as most database > systems use one of those, and besides, that's all I know. :) > > Consider what steps you might take to audit unauthorized > transactions performed by an admin. > > Oracle Auditing could be used, but someone with admin > access to the server and database could easily alter the > records created by system auditing. > > You could create an audit table, using a trigger to audit > sensitive tables. A materialized view on a remote database > could be created on sensitive tables to remotely log all > actions. > > In the case of the audit table, that could easily be disabled, > and then re-enabled after the nefarious DML had completed. > > The materialized views might be more difficult to circumvent. > > If the remote end is using a dblink to the server employing a > password that is *different* than that of it's own account at the > remote server, it should be impossible for someone to completely > cover the traces of transactions created to falsify data. > > The MV Logs could be dropped, but without access to the MV's > at the remote server, the MV's would have to be left in place. > > These could be used as a reference to look for unauthorized > transactions > in the primary server. If this same admin has access to the remote > server where the MV's are, then this can also be circumvented. > > There is also the logs created as when logging in as internal > or sysdba. ( $ORACLE_HOME/rdms/audit/*.aud ) > > These can simply be deleted. Some system could be used to save > these to a remote server, but it would have to run *very* frequently > to > be effective. > > Oracle password files could also be used. While this can prevent > someone from logging in as SYS or SYSTEM while in place, all it > takes is a change to init.ora, and a database bounce to fix that. > > Make your bogus data changes, change the init.ora back and > bounce the database again. > > A somewhat clever person could set this up to automatically > take place the next time the DB is bounced. > > The conclusion I have come to is that the only effective method > that could be used to create an audit trail for such a scenario is > to create Materialized Views on sensitive tables, and create them > on a server that admins are guaranteed to not have access to. > > Of course, I may be missing something. I'm not always one to > catch all the details right off. Input, comments, suggestions, far > out ideas are all welcome. > > If you've read this far, thanks! > > Jared > > > > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > San Diego, California -- Mailing list and web hosting services > --------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus � Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
