Arup Nanda [EMAIL PROTECTED] wrote:
I'm not sure that's what the OP wanted. He wanted to know if stopping
use of
SYS and SYSTEM on a regular basis will be acceptable, not disable
them. It
sure is.
Besides, how does one disable the account? Lock it? SYSTEM can be
locked but
SYS can't be; hence the whole concept of disabling does not make
sense.
I hear what you're saying, but define acceptable. And how do you stop
someone from using a given userid other than disabling it? How do you
disable is of course dependent on what the software maker provides you.
In the case of SYS, probably change passwords is the only way.
In the case of SYSTEM I think it can be disabled, although I'm not
sure of the impact of that on tools that may need it. I'd rather use the
password method, that way all I need do to enable it is change
the password again.
I feel the auditors merely wanted the OP to stop using SYS and SYSTEM
on a
regular basis in operations that require a DBA access - such as full
exports
and selecting from disctionary tables. IMHO this is a very valid
advisory
and not difficult to follow.
Stopping someone from using a given set of accounts achieves preciously
nothing in terms of security (or auditing) IF the functionality of those accounts
is then replicated to other accounts.
Fact is a DBA needs to be able to exp/imp (debatable, but let's ignore that).
And manage rights. And manage space. And manage allocations,
And monitor the system. And a myriad of other tasks immaterial to the
point I'm trying to make.
Those are conveniently provided for by Oracle on a default install using
the SYSTEM account. This is what it is for, this is the work of a DBA,
this is WHY that account has been given those access rights. SYS is
debatable and Oracle may now want to discourage people from using
it. Fair enough. But SYSTEM is the DBA account par excellence,
the same that root is also a sysadmin account.
Now you may take away the accounts, but you MUST provide the
functionality (or a subset) SOMEHOW, or else the DBA (or the sysadmin)
can NOT do his/her work.
If you provide the function through another account, then EFFECTIVELY,
all you have achievced is change the name of the account that does that
function. Security wise, you are back exactly where you started!
And all you have achieved is create a whole lot of risks for the next
person that comes along and installs some software.
The auditors should be defining a set of functions that must be audited
and to what level, and the DBA (and Oracle!) should look at how to
implement those. If they are executed by logonid A, B or MXYZPTLK
is essentially just spurious information (other than of course knowing
WHO has the password for that ID!). Does Oracle provide a facility
to properly audit all this? IMHO, far from it. But it's getting better.
I don't want to know that SYSTEM or SOUTON with a subset
of its rights stuffed up my database or exported my main accounts
and clients tables. What I want to know is WHY, WHEN, HOW and
by WHOM. So that I can reconstruct the events, and hopefully prevent
the problem from ever happening again.
Changing the login names DBAs use doesn't cut it for this, other than
look good in auditor's reports. If there is one thing that the military are
good at (!) is in defining precisely what security and auditing consists
of.
Have a look at a secure military installation and you'll find it's not about
stopping people from using this or that, it's about KNOWING who
did what, how and when.
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).
