> 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).
