Thursday, April 18, 2013

Security, Access control on tables - Part 1

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, Access control on tables, views, Synonyms or Rows  -  Part 1
Access Control on Tables, Views, Synonyms, or Rows
Authentication processes, validate the identities of the entities using your networks, databases, and applications.

Authorization processes provide limits to the access, actions, and limits of the entities that are linked to their identities and roles.

Restrictions can also be associated with the objects that users access.  By providing restrictions on the objects themselves, it provides a level of protection regardless of the entity that accesses the object, and by which route the entity accesses or the object.  Also if the entity attempts to alter the object, then the object is protected, regardless of the user, or the method of access.

You can protect objects by using object-level privileges, or providing access to the objects through views.  You can also design policies to restrict  access to specific tables, views, synonyms or rows.  The level of access that enables you to use application context, with fine-grained access control, is called Virtual Private Database (VPD).  Policies that are designed like this can be used to invoke or call functions that have been designed to specify dynamic predicates that establish the restrictions.  You can then take related policies and group them together, to be applied as a policy group to a specific application.

Once you have set up object level protection, using views and synonyms, and even VPD, then you will want to be notified when your configuration is threatened, or breached.  Auditing configurations, will enables you to receive notifications of specific activities, that you may want to be notified about.  Once you receive a notification, you can strengthen your security configuration, and see if this stands up to the requirements.  You can see it as an iterative process, as you get your security better and better.  Hopefully you will be dealing with attempted breaches of security, but there will be those breaches that you will have to address as well.  Even with a security breach, the extent of damage will be limited, with good security measures in place.

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

No comments:

Post a Comment