Resending this message. The first post was undelivered since listguru thought it was a vacation message. This one has the word _V_acatio_N.
----- Original Message ----- To: <[EMAIL PROTECTED]> Sent: Wednesday, November 12, 2003 5:58 PM > Ron, > > I think you answered your own question - technically the auditors are > correct; however your _specific_ situation (short-handed staff) may warrant > this not be done. Perhaps you can use it justify to your management why you > are willing to accept the risk, it's really a simple question of economics. > > However, in your response you have mentioned that you never use SYS, only > when the regular DBA of the database is out and a different DBA, new to the > database is called to fill in. If the fill-in is planned, e.g. the regular > DBA goes on _V_acatio_N, you can create a named account for the new DBA. > > If the absence is unplanned, or the name of the new DBA is not known, I > suggest you create an account called NEWDBA with SYSDBA and DBA privileges, > but lock the account. Have a policy in your organization that the account > NEWDBA is created in all the databases and locked. In emergency, use SYS as > SYSDBA to unlock the account and use it. It is not for security, just to > prevent accidental creation of objects in the SYSTEM tablespace. Imagine > NEWDBA as a different kind of SYS. There is no extra work involved and > sooner or later you will see that most DBA, especially new ones to the > organization fall in line and it becomes a kind of standard. You can lock > NEWDBA account, not the SYS account. > > How many times do you need the SYS account access? Database creation is one > time and a non-regular DBA will not need that. Full export is one, but can > be easily done using the NEWDBA user. How many times do you use the full > import? In emergencies? In that case, use the NEWDBA. Frankly, there are > very few occasions where using SYS accounts is needed. It's mostly laziness > on our part that prompts us to use SYS, simply because we know there will > not be any type of access restriction. > > I guess the important thing auditors are looking for is your acceptance of > the risk and documenting it for used in situations beyond your control - > such as emergencies and the regular DBA is not available. As long you > document that under those extenuating circumstances one is allowed to use > SYS, simply because it is necessary considering the workload, that might be > acceptable to management. Mere rejection of auditors' recommendation without > the justification probably will not help either party. > > Hope this helps. > > Arup > > ----- Original Message ----- > From: "Smith, Ron L." <[EMAIL PROTECTED]> > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Wednesday, November 12, 2003 5:24 PM > Subject: RE: Stop using SYS, SYSTEM? > > > > Where we work, there is one DBA responsible for each database. Each DBA > > is responsible for dozens of databases, servers, and applications. The > > only time another DBA is in one of my databases is when I am out of the > > office and can't get to a phone line or network connection. We never > > use SYS but it was included in the audit so I included it in the > > question. > > > > We still have to use SYS and SYSTEM for database creates, full exports, > > imports, etc... The only thing I can see creating a dummy SYSTEM > > account would do is to add one more userid and dozens of new passwords > > to the database and more work for an already short handed staff. > > > > Ron Smith > > > > -----Original Message----- > > Sent: Wednesday, November 12, 2003 3:59 PM > > To: Multiple recipients of list ORACLE-L > > > > > > Hi Ron, > > > > I just starte to write an answer to agree with your auditor based on > > accountability and i saw Arup's answer come through so I have deleted my > > answer and just say i concur whole heartedly with Arup. I also conduct > > oracle security audits and i suggest to clients not to use SYS or SYSTEM > > for day to day work. > > > > kind regards > > > > Pete > > -- > > Pete Finnigan > > email:[EMAIL PROTECTED] > > Web site: http://www.petefinnigan.com - Oracle security audit > > specialists Book:Oracle security step-by-step Guide - see > > http://store.sans.org for details. > > > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > > Author: Pete Finnigan > > 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: Smith, Ron L. > > 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).
