Why you should use Privilege Analysis on an Oracle Database
In this article, I am going to be explaining a feature that is available to utilise on Oracle Database Enterprise Edition. This is a very useful feature that should help customers in their daily fight against data protection and intelligence property leaks from external as well as internal users.
In the news, we hear about data security flaws and data leaks from highly data-sensitive customers all the time, but in my opinion, every business that has Database Enterprise should be considering utilising this feature to restrict access, log access and build a secure Database that only allows certain individuals the correct level of access.
Too many times, I have seen ‘power users’ or ‘admin users’ set for users that do not require this level of access, but it is faster to add a user to a group rather than set up the correct access. By using PA and after some administration and set-up, customers can quickly identify what user has what access and can identify any irregular privileges not required. So let me start by explaining what Privilege Analysis is.
What is Privilege Analysis?
Privilege Analysis (PA) is a key security feature of the Oracle Database Enterprise Edition, which analyses role and privilege usage for specific database users and generic user accounts. Privilege Analysis reports on which privileges such as ‘SELECT ANY TABLE’ or ‘CREATE VIEW’ for example, were used or not used in a defined period of time. The features give a more informative view of privileges which were used and when, rather than a point-in-time view which only shows if a privilege is granted, not if it was used or unused. Understanding this difference will allow you to implement more secure database access by users and reduce the risk of a data attack from a granted user with full privileges.
What are the costs for Privilege Analysis?
NONE! Did you read that? An Oracle feature that gives real benefit that does not cost anything on Enterprise Edition!
Privilege Analysis was introduced as a feature of the licensable Enterprise option called Oracle Database Vault on version 12c 12.1.0.1. However, since the introduction of 19c, Privilege Analysis is now included on all subsequent versions of the Enterprise Database and is now a feature to use without separately licensing it. If, however, you use PA on a Standard Edition Database, then I am afraid you will be licensed incorrectly and will either need to stop using Privilege Analysis or upgrade your Database to Enterprise Edition and procure the appropriate Enterprise Edition license!
Understanding the concept of Least Privilege
The concept of Least Privilege is a security model or term that aims to limit the privileges of users' accounts (user, utility, application) to only what is required for their role/task. This way any user access is only for their role and will not include super user or sys admin privileges were not necessary. Powerful privileges should only be granted to the users that require this access and even then, these should be strictly monitored and limited to database administrative tasks and restricted from production data where possible. Least privilege methodology should be continually monitored so that any accounts that are super user are not accessed by unauthorised personnel and that all sensitive data is appropriately secured and monitored.
We already have a DBA who does this kind of thing…
Whilst you may have a database administrator or team of administrators doing this ad hoc, it’s not the same as using PA. If set up correctly, PA will not only monitor access by Joe Bloggs but will also log access by the very DBAs who may, unbeknownst to them, access sensitive information that they should not be viewing. It is a way of not only protecting the data but also your employees who may or may not fully understand data access policies and corporate data security. Static tools do exist but they in general only give a point in time view of access. For example, if a user had access to financial data that they used to their benefit today and then subsequently removed their access to this data, running the static view report after privilege removal will only show access granted from that point on — so the window or chance to capture that data access would be gone.
Privilege Analysis collects role and privilege user information over time and reports on what was used and what wasn’t. Additionally, with PA, you can set up alerts when unused privileges and roles are used, instead of just revoking them. This approach allows you to catch unusual activity and capture the access and by whom. When you allow for an appropriate amount of time to analyse, you can revoke unused privileges to clean up the access that has been granted unnecessarily and reduce a data breach. There is also a good tip here that by viewing the access over time, you can build up a picture of which objects specific roles access, and then can generate object grants rather than full access for a user — again a further level of security.
Using Privilege Analysis
Privilege Analysis is a feature of Database Enterprise and as such there is no setup of installation of the feature required. To start using this feature a user needs the CAPTURE_ADMIN role. This user should create a PA policy and enable the policy for a set period. Once this has elapsed, the user has to disable the policy and then can generate the report of used and unused privileges capturing user and role accesses.
How long should I have Privilege Analysis enabled?
My answer to this question is ‘How long is a piece of string?’ More specifically, I would suggest considering whatever length of time you need to fully assess your user’s access. This can be over a few days to a few months — it depends on how long you want the access to be assessed. Of course, I would not recommend running this on a long-term basis on a production environment, however, I would suggest running it on a test environment initially to assess the performance and show the accesses appropriately. Then I would move it to production for a limited window to show the effectiveness of the report.
What to take note of on the Privilege Analysis Report?
A couple of key things to consider in this report are:
1. Period of time to capture.
This should be enabled for a set period to allow for the majority of users to access, create a history of access and show who accesses what, using what privilege.
2. Create privileges.
Are these needed for the user/role — could more specific access be granted rather than full access?
3. Sensitive data.
Who has access to the production data records and who actually needs it? Should this be unlocked for a specific group of users and locked for everyone else? The report can identify which individuals have read/write/create table/create view access on specific objects.
4. Identify what users/roles access which views/tables.
Is it appropriate for their role — do they have access where it is not needed?
In Summary
Since Privilege Analysis is a free option with Oracle Database Enterprise, I would urge all Enterprise Edition customers to consider using this feature. It is not often that Oracle gives powerful functionality away at zero cost (though of course the cost is built into the cost of Database Enterprise Edition– remember, this was licensable on version 12c under the Database Vault option.
But because of the nature of data security and data breaches that are happening daily across the world, Oracle has released this feature to support their customers and empower them to better monitor their users and their user’s access to sensitive data.
You must remember that this feature will not stop wilful security hacks, but it is there to help monitor data access, and also protect your employees from making unintentional unauthorised access to sensitive data that may create legal or data breach concerns for your data security teams.
As Oracle license experts, we can help you with this or any Oracle license matter to reduce risk and cost in your Oracle license estate. Go to our website for more information or contact us confidentially.
About the author
Johnny Cree is an Oracle SAM Licencing Consultant here at Version 1.
