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: <ORACLE-L_at_fatcity.com>
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." <rlsmith_at_kmg.com>
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> 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:pete_at_petefinnigan.com
> > 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: oracle_list_at_peterfinnigan.demon.co.uk
> >
> > 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: ListGuru_at_fatcity.com (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: rlsmith_at_kmg.com
> >
> > 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: ListGuru_at_fatcity.com (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: orarup_at_hotmail.com
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: ListGuru_at_fatcity.com (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).
Received on Wed Nov 12 2003 - 17:34:24 CST
