Friday, April 5, 2013

Security, Privileges, Roles - Part 2

Dear Readers,

My name is Franz Devantier, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g) Security DBA.  I will be sharing with you the basic duties of an Oracle DBA, and also some of the undocumented, and not so well known tasks. 

I will make a deal with you:  If you refer me to a company that needs database support, from a few hours per week to full time, and I am able to sign a contract with them.
Then I will give you 10% of the monthly contract or deal price every month.  When the contract ends, and we re-sign the contract, I will again give you 10% of the monthly contract price.  This will go on until the company no longer employs or contracts me or my agents to look after their databases.
I can do this, because that 10% is my marketing budget.  When we re-sign the contract, in the future, it may depend on you giving the thumbs up again, and that is worth 10% of the monthly contract price, to be given to you as commission.
Contact: Franz

Security, Privileges, Roles, Profiles and Resource Limitations  -  Part 2
Who Can Grant or Revoke System Privileges?
There are two types of users who can grant or revoke system privileges to other users.  These users must be carefully managed so that the security is not compromised.
·         Uses who have been granted a specific system privilege with the ADMIN OPTION.  Rather don’t grant system privileges to users with the ADMIN OPTION, because it creates a security issue
·         Users who have been granted the system privilege; GRANT ANY PRIVILEGE, also a potential security issue

Schema Object Privileges
A schema object privilege is the privilege to perform a specific action on a specific schema object.  For example the privilege to delete rows from a table that belongs to another schema, is a good example.

However some schema objects such as clusters, indexes, triggers, and database links, do not have associated object privileges.  There use is controlled by system privileges.  For example to alter a cluster, the user must own the cluster, in which case the user can alter the cluster, or the user must have the ALTER ANY CLUSTER system privilege.
The following broad areas with regards to Schema object Privileges are important:
·         Granting and revoking schema object privileges
·         Who can grant schema object privileges
·         Using privileges with Synonyms
·         Table privileges
·         View Privileges
·         Sequences
·         Procedure privileges
·         Function and Package privileges
·         Type privileges

Granting and Revoking Schema Object Privileges
You can grant and revoke schema object privileges from users and roles.  You can use the SQL statements GRANT and REVOKE, or you can use Oracle enterprise manager Database Control.

Who Can Grant Schema Object Privileges?
By default a user has all object privileges for schema objects contained in his or her schema.  A user can grant all or any of the privileges on any of the objects in their own schema, to any other user or role.

The GRANT ANY OBJECT PRIVILEGE is a system privilege, and allows the user to grant or revoke any object privilege in any schema to any other user, with or without the GRANT OPTION.  If a user receives the GRANT OPTION with the privilege, then that user can grant that same privilege to any other user, which can become a security issue.
 Using Privileges with Synonyms
A synonym points to a schema object, and if you have object privileges on that object, then you can reference that object via the synonym.  If you don’t have privileges on that object then referencing the synonym will return the same error, as referencing the object itself.  You can grant the privileges to the synonym, and the privilege for the underlying object is granted.

If a synonym is dropped, then all the grants for the underlying schema object still remain in effect, even if the privileges were granted through the synonym that is dropped.

Franz Devantier,
Need a database health check, or a security audit?
devantierf@gmail.com

No comments:

Post a Comment