I don't think our staffing level would permit that. 1 DBA, 2 SA's and 1 contractor SA. On Tue, 2004-03-16 at 17:47, MacGregor, Ian A. wrote: > There is also the idea of two-man control. No one is allowed > sole access to the machine room. No one knows the entire root/admin > or dba password. I know of many places which implement two-man > control for physical security, but none that have carried it to the > computer security level. It would be so burdensome. > > > Ian MacGregor > Stanford Linear Accelerator Center > ian@xxxxxxxxxxxxxxxxx > > ______________________________________________________________________ > From: Jared.Still@xxxxxxxxxxx [mailto:Jared.Still@xxxxxxxxxxx] > Sent: Tuesday, March 16, 2004 5:08 PM > To: oracle-l@xxxxxxxxxxxxx > Subject: Re: Database security > > > Thanks you Paul for the detailed info, and all others that replied. > > You have pretty much confirmed what I thought to be true. > > * you can't stop a determined SA > * I don't want to be the SA > * encryption is the only way to prevent access to data by the DBAs > and SAs. This of course introduces key management. > > This supplies me with some solid material as we do gap analysis > on our database security. > > Jared > > > > > Paul Drake > <discgolfdba@xxxxxxxxx> > Sent by: > oracle-l-bounce@xxxxxxxxxxxxx > > 03/16/2004 04:59 PM > Please respond to > oracle-l > > > > To: > oracle-l@xxxxxxxxxxxxx > cc: > Subject: > Re: Database security > > > --- Jared.Still@xxxxxxxxxxx wrote: > > 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 > > Jared, > > I wish we would have talked this over last week while > enjoying a tasty beverage. > > DBA and SYSDBA are different animals. > > The quick answer is, you can't do it. > > You can prevent the (MCSE) Domain Admin from > connecting to an Oracle database instance on a win32 > box, when it really isn't a windows box anymore. that > takes alot of work and testing. If he can gain access > to the server room, you can't stop him. > > The verbose answer is, you can make it a large PITA > for him to get into it, but the a user having local > administrator can re-grant the local ORA_DBA or > ORA_%ORACLE_SID%_DBA group to the administrators local > group or their account, or could construct a new > password file and connect as sysdba. > > You can setup the filesystem permissions such that the > local administrators cannot access the oracle files > (at client sites I allow them read access for backup > purposes, via a local OPER group). > > You can audit permissions changes to filesystems. > > But you cannot prevent a member of the local > administrators group from clearing the log files, e.g. > security event log. > > You can, however, run a syslog client to send such > messages to a *nix box, that a local administrator of > the win32 box (or Domain Admin) could not access. If > you have a security administrator, I'm sure that you'd > muck something up in PERL to send them alerts for such > things in an automated fashion, hopefully not thru the > local MS Exchange server that the evil MS SysAdmin > could also compromise (or already manages). > > Now, if the SysAdmin grants a local group to his > account (or local group) or takes ownership of files - > it will show up in the log files on the *nix box. > > It depends upon what you are trying to accomplish. > If you simply want to be able to track that a user has > gained access as sysdba, the event logs already > include such information, just get that information > off of the box in real-time fashion. That may be > sufficient for your purposes. > > If you seriously want to prevent the Admin from > accessing the database files, you're going to have to > prevent him from accessing any of the backup sets > (including those at rest, on tapes at the offsite > location, etc). That is pretty much impossible without > encrypting the data. > > I have done alot of work on making Oracle on Windows > as secure as possible. Some of it as an exercise, some > for real. I had a w2k box that only had one port > listed in a netstat command output, that was the > listener's. > The box was not real useful outside of the listener > and the instance (which is good). > > Have you considered, removing the box from the domain, > so that it is in its own workgroup, (thinking clean > re-install) and not granting any accounts out to any > others? > > After Nimda hit our network (years ago), all the > oracle servers that were win32 left the domain, and > had netbios ripped out (as well as the server service, > etc.). > > If the SysAdmin has no accounts to log onto the box, > then he's not really the SysAdmin anymore. You would > be. caution. > > That is the responsibility that I assumed (took) here > years ago. Its alot of work. Careful what you wish > for. I get to apply the hotfixes, change the virus > software, verify that the backupsets were transported > to the staging servers, read the logs. > > It meant that the developers no longer had access to > /udump. That is a large price to pay for OS and > filesystem security. > > The developers do get access (via ssh) to the new 9.2 > dev db running on RHEL 3.0 ES. All ports on that are > closed off below 1024 except for ssh (this is a box on > the internal LAN, and yes, I still run a firewall on > the box). > > There is no rpm for sendmail on the server. > There is no rpm for bind on the server. > > I did open everything above 1024 tcp so that dedicated > server processes could be obtained and I would not > want to ask anyone to read a trace file created via a > shared server. If it turns out that we're only using > ports below 4000, I'll tighten up the range that > iptables is accepting incoming connections for tcp. > > time for beef and beer. > > Paul > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - More reliable, more storage, less spam > http://mail.yahoo.com > ---------------------------------------------------------------- > 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 -----------------------------------------------------------------