You may just possibly be the only other DBA besides me who does NOT want root access!
I know just enough to be dangerous. I have more than enough work to do without taking over the SA's job as well. theoretical point 2: yes, you should trust your DBAs and SAs. But if you, for whatever reason, have to have a temporary person in, someone you don't know, who leaves and is not reachable/accountable, then it behooves you to put some sort of controls in place. perhaps just logging each session so that what is done can be seen, without making it so onerous that people try to circumvent the rules. We have a hosting company here for our staging and production servers. I have an account on both servers. They have not, as yet, changed the database passwords (we're in the process of going live and they haven't set up a read-only account for me). I *could* go in and fix the problems. That would be the fast way, and the users certainly would appreciate it. I follow the rules. Submit change requests, with scripts attached. It's safer all around. --- "Fink, Dan" <[EMAIL PROTECTED]> wrote: > Jared, > I realize the following is not really an answer, but it may provide > a little food for thought. > > Practical: > 1. Log miner or other log reading tool could be used to track > changes made through the transaction layer. Some operations can be > done with > nologging, but not all and the undo is logged regardless. Yes, it > would be > complicated and messy. > 2. If you don't trust the SAs and DBAs for the systems, they need to > be replaced. You are absolutely correct that if a person has the > knowledge > and motive, almost anything is possible. This is shown time and time > again > by corporate embezzlement. > 3. As a DBA, I never want to know root's password. If I need SA > type > commands, either use sudo on unix (not sure if there is an equivalent > on > NT/2K) or provide exact information to the SA. I work on maintaining > a good > relationship with the SAs so we each respect each other's 'turf' and > don't > try to do things we are not qualified to do. > 4. Changing passwords frequently, especially system generated ones, > leads to people writing them down or otherwise storing them somewhere > they > can be accessed. I wonder how many of us have 1 password (with minor > variations) for the overwhelming majority of our systems/logins. > 5. Don't make security so onerous and inconvenient that people are > constantly looking for ways around it just so that they can do their > job. > This encourages the creation of security holes and a general > disregard for > the processes and procedures. > 6. If you create a server no admins have access to, how would it be > set up and maintained? > > Theoretical > The only truly secure system is the one that is never turned on. > Once power is applied and the system is started, it can be > compromised. An > SA can su - oracle and login as sysdba, a DBA can spoof a user, a > developer > could insert malicious code. > I think that the issue is to create and abide by standards and > processes, hire trustworthy personnel and treat them right. > As has been shown recently here in the US, there are significant > business risks from unethical, greedy people. How are these > prevented? > > Dan Fink > > -----Original Message----- > Sent: Tuesday, November 26, 2002 4:05 PM > To: Multiple recipients of list ORACLE-L > > > 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). > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: Fink, Dan > 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).
