Whoa! That came out pretty strong :) I will reiterate your point "A DBA needs DBA access to the system.". Absolutely, a DBA needs access to the database for performing certain operations. a DBA does not need access the database as SYS explicitly.
"Oracle provides this via SYS and SYSTEM" No, it doesn't. It has the DBA role for that. SYSTEM, I can accept as a DBA user, but not SYS; it's not a user to be used as an access mechanism; it's purpose is to be a schema - a repository. Well, let's take a look at the past to gain some perspective. Remember the initial days of Oracle 9i? Suddenly you couldn't connect to SYS as a regular account, in stead you had to use AS SYSDBA clause. A lot of such strong words must have echoed around the world for Oracle Corp asking us to type the extra eight characters. But the rationale, I think, people have understood by now, is far more valuable than the extra effort. SYS is a special account, not a regular DBA account, pure and simple. SYS owns the special objects that is precious for the database to operate, it is not the requirement of the database that SYS must be used to do certain things such as full export or shutdown/startup. By mandating the AS SYSDBA clause, Oracle at least made us aware that the account should not be used for regular super user type maintenance such as creation of users and full exports. Take a page from our friendly neighborhood unix sys admins. Most systems require direct connect to root user on the console only; and the sys admins always use their own accounts to manage the system. This way they avoid the inadvertent mistake where an important file is overwritten or deleted. The use of home directories prevent such an accident. The same gos here - using named accounts in Oracle such as JDOE as a DBA with default tablespace other than SYSTEM will prevent that. What are the odds of such a thing happening? I don't know; but planning to have a user other than SYS sure beats the odds any day. A security advisory is exactly that, an _advisory_; it's not cast in stone. The needs of the organization dictate what is the good tradeoff between follwoing a good practice and obstructing progress. A cowboy mentality to approach any such issue might be a little detrimental, I think. Arup ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Wednesday, November 12, 2003 6:44 PM > > Smith, Ron L. <[EMAIL PROTECTED]> wrote: > > > > We are being asked by Auditing to stop using the SYS, and SYSTEM > > accounts. They would like for us to create an Oracle Role with the > > same > > permissions a SYS and SYSTEM, then grant the role to each of the > > DBA's. > > Don't ask me why. Nothing is being audited in 99% of the databases. > > They just say it in a paper some where so they said we shouldn't use > > it. > > This seems like it would cause lots of problems with exports, > > imports, > > installs, etc... Has anyone had to deal with this type of request? > > Any > > potential problems with making the change? > > > > Quite a few potential problems. This is typical security jackass > kneejerk reaction, pure and simple. A DBA needs DBA access > to the system. Oracle provides this via SYS and SYSTEM. Period. > The rest is just hazy, unprovable, half-cooked "security" bullshit > from people who read this and that everywhere and are by default > considered experts by even less competent damagement. > > Granting all rights of user SYS and SYSTEM to a role and then granting > that role to a DBA user reeks of sheer stupidity. If the issue is auditing, > then use auditing. That's what it's there for. If the issue is use of DBA > access, then get rid of the DBAs. (see how long that lasts...). > > This sort of thing reminds me of the time I used to work at a very secure site > back in the early 90s. Where we had to request a security officer to give us > the password for SYS and SYSTEM in order to do our job. The officer changed > the password before passing it on to us verbally. He then proceeded to watch us > type on the screen, then watched us log out and then changed the password > again on the spot. Very secure, very procedural, very formal. > > Except the officer was not a DBA, knew zilch about SQL and couldn't discern > if we were copying the entire main accounts table to a non-secure area if his life > depended on it. > > Great security! No wonder it got exposed a few years later in a well known > incident. > > The issue of course is that what these people needed was auditing, not security. > But try as we might, we could not make their "experts" understand the > diff... > > Cheers > Nuno Souto > [EMAIL PROTECTED] > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Nuno Pinto do Souto > 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.net -- Author: Arup Nanda 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).
