[Previous entry: "Information leakage and goole hacking"] [Next entry: "Howard Rogers on dropping the DBA, CONNECT and RESOURCE roles"]
An interesting discussion about revoking privileges from SYS or DBA
December 16th, 2004 by Pete
Post to del.icio.us
Post to Furl
I saw a thread on comp.databases.oracle.server last week entitled "OK to revoke privileges from SYS or DBA?".
This thread started by talking about whether it’s OK to revoke privileges from the SYS user and the DBA role. The thread got a little heated in places but the consensus at the end is to not use the SYS user except for things it has to be used for such as creating databases. The consensus is also to not drop the DBA role and to not alter it in anyway, the reasoning being that Oracle use the role in some of the installation script for default users and the features they use could break.
The consensus also seemed to be to not alter the CONNECT or RESOURCE roles and to not drop them for the same reasons as above.
Some suggest altering these roles and some suggest that dropping them is OK and Daniel sited the fact that some ultra secure sites in the USA have dropped DBA, CONNECT and RESOURCE and altered the installation scripts and work fine. This is hard to confirm. I can see the potential issue of Oracle using these roles themselves can make it hard to remove them without losing warranty so don't drop them.
Removing privileges from these roles could also be a support issue for the same reasons. The sound advice is to not grant DBA, CONNECT or RESOURCE to any users in your databases (apart from the default users created by Oracle - even then the default users should be kept to the absolute minimum anyway).
Create your own roles for user to connect to your applications with; do not grant privileges that can be used to create objects. Also for users that can create objects create a separate role and if possible revoke those CREATE PRIVILEGES after use so that the users only have them for the short time they are needed.
In the case of the DBA role, other than the SYS and SYSTEM users do not grant the DBA role to any other admin staff. Segregate the admin duties and create admin roles that have the privileges needed. Do not simply grant all privileges to another role. Use the least privilege principle.
