PDF version of article published in OTech magazine Winter 2014 Edition. Original Magazine at http://www.otechmag.com/2014/otech-magazine-winter-2014/

1. Article Published in OTech Magazine Winter 2014 Edition
Original Magazine at http://www.otechmag.com/2014/otech-magazine-winter-2014/
Enforcing Principle of Least Privilege
- Biju Thomas
One of the top features of Oracle Database 12c that attracted me is the ability to enforce principle of least privilege with
ease. Ever since database vendors started taking security seriously, the principle of least privilege theory is in play. To
identify the privileges required by an application or user in Oracle database versions prior 12c was a tedious trial and
error process. Many applications I have come across run with DBA or DBA like privileges, this is because no privilege
analysis done at application design and development time. For application design and development team the focus is
always on getting the development work completed and delivering the project. Security, especially least privilege, is not
a focus item where team wants to spend time. It is easy to grant system privileges (especially DBA or ANY privileges like
INSERT ANY TABLE) to get the application working.
Oracle Database 12c brings the Privilege Analysis feature to clearly identify the privileges required by an application for
its functioning and tells the DBA which privileges can be revoked, to enforce the principle of least privilege and make the
database and application more secure. Privilege analysis feature is available only in Enterprise Edition and it requires
Database Vault license, which is an extra cost option. The good thing is that Database Vault need not be enabled to use
Privilege Analysis - one less thing to worry.
In a nutshell, privilege analysis works as below:
- Define a capture - to identify what need to be analyzed
- Enable the capture, to start capturing
- Run the application or utility whose privilege need to be analyzed
- Disable the capture
- Generate results from capture for review
- Implement the results, from the findings
Figure 1: Privilege Analysis
I will explain the steps using SQL command line as well as using Enterprise Manager Cloud Control 12c. To do the
privilege analysis you need the CAPTURE_ADMIN role, this role is granted to DBA role, so if you have DBA privileges on
the 12c database, you can perform the analysis.
Demo Environment
For demonstration purposes I am going to use the OE schema that comes with Oracle Database 12c examples - it has 14
tables and several other objects. We want to analyze the privileges of OE_ADM user who currently has the following
privileges.

2. - SELECT ANY TABLE
- INSERT ANY TABLE
- UPDATE ANY TABLE
- DELETE ANY TABLE
- ALTER ANY TRIGGER
- CREATE PROCEDURE
- CREATE TABLE
- CREATE SYNONYM
- CREATE ANY INDEX
- ALL privs on ORDERS and ORDER_ITEMS tables
- CONNECT and DBA Roles
SQL> select object_type, count(*) from dba_objects
where owner = 'OE' group by object_type;
OBJECT_TYPE COUNT(*)
----------------------- ----------
SEQUENCE 1
LOB 15
TYPE BODY 3
TRIGGER 4
TABLE 14
INDEX 48
SYNONYM 6
VIEW 13
FUNCTION 1
TYPE 37
OE_ADM user connects using SQL*Developer to run the scripts and reports. Our objective is to remove the ANY
privileges from OE_ADM user and grant appropriate privileges based on the tasks performed during the analysis period.
New package DBMS_PRIVILEGE_CAPTURE has the subprograms to manage the privilege analysis. The
CAPTURE_ADMIN role has execute privilege on this package.
Define and Start Capture
The very first step in privilege analysis is to create a capture, to define what actions need to be monitored. Four types of
analysis can be defined in the capture:
- Database (G_DATABASE - 1): If no condition is defined, analyzes used privilege on all objects within the whole
database. No condition or roles parameter specified for this type of capture.
- Role (G_ROLE - 2): Analyses privileges exercised through a role. Specify the roles to analyze using the ROLES
parameter.
- Context (G_CONTEXT - 3): Use this to analyze privileges that are used through an application module or specific
context. Specify a CONDITION to analyze
- Role and Context (G_ROLE_AND_CONTEXT - 4): Combination of role and context.

3. The CREATE_CAPTURE subprogram is used to define the capture. For our demo, we want to use the Role and Context,
because we want to know what privilege from the DBA role is being used as well as what other privileges granted to
OE_ADM are used when the application used is “SQL Developer”.
Figure 2 shows the OEM screen to create a capture policy. With few clicks you can easily create the policy. Based on the
context additional input is captured.
Figure 2: OEM Screen to Create a Privilege Analysis Policy
The SQL to define the policy as shown in Figure 2 is:
BEGIN
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE(
name => 'Analyze_OE_ADM' ,
description => 'Review Privileges used by OE_ADM through SQL Developer' ,
type => DBMS_PRIVILEGE_CAPTURE.G_ROLE_AND_CONTEXT ,
roles => ROLE_NAME_LIST('DBA','CONNECT') ,
condition => 'SYS_CONTEXT(''USERENV'', ''MODULE'') = ''SQL Developer'' AND
SYS_CONTEXT(''USERENV'', ''SESSION_USER'') = ''OE_ADM''');
END;
/
Once the policy is defined, it shows up in the OEM Privilege Analysis main screen, from where you can enable, disable,
generate report and drop the policy. See figure 3.

4. Figure 3: Privilege Analysis screen of OEM
You can click on the start button to start capture, or use the below SQL to start the capture.
EXECUTE DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE (name => 'Analyze_OE_ADM');
Now run the application and for a period of time, so that Oracle can capture all the privileges used.
Stop Capture and Generate Reports
Ok, now that OE_ADM user has performed their tasks using SQL Developer, let us stop the capture and review the
privileges used.
EXECUTE DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE (name => 'Analyze_OE_ADM');
Using OEM you can click on the Stop Capture button as shown in Figure 3. Now click the Generate Report button. Using
SQL you can accomplish this by
EXECUTE DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT (name => 'Analyze_OE_ADM');
OEM shows the number of unused privileges in the summary screen as shown in figure 4.
Once you run the Generate Results procedure, all the DBA_USED_ views as well as DBA_UNUSED_ views are populated.
You may query these views to generate revoke scripts or to prepare reports. The DBA_USED_ views show the privileges
used by the user for the policy. The DBA_UNUSED_ views show the privileges that are assigned to the user, but are not
used. The _PATH views show the privilege path (how the privileged was given to the user, through which role).
Capture Privilege - DBA Views Populated with Generate Results Procedure
DBA_USED_OBJPRIVS
DBA_USED_OBJPRIVS_PATH
DBA_USED_PRIVS
DBA_USED_PUBPRIVS
DBA_USED_SYSPRIVS

5. DBA_USED_SYSPRIVS_PATH
DBA_USED_USERPRIVS
DBA_USED_USERPRIVS_PATH
DBA_UNUSED_COL_TABS
DBA_UNUSED_OBJPRIVS
DBA_UNUSED_OBJPRIVS_PATH
DBA_UNUSED_PRIVS
DBA_UNUSED_SYSPRIVS
DBA_UNUSED_SYSPRIVS_PATH
DBA_UNUSED_USERPRIVS
DBA_UNUSED_USERPRIVS_PATH
OEM makes it easier on you to see the reports and even generate a revoke script. Figure 5 shows the drop down menu
under Actions.
Figure 5: OEM Options under Actions
The Reports menu shows a summary, as well as used and unused privilege listing that you can export to an excel file. To
be able to use the Revoke Scripts option, OEM needs to complete a setup as shown in figure 6.
Figure 6: OEM Setup for Revoke Scripts Generation
The revoke script revokes all unused roles and privileges from the role granted to the user, in this case this is not
desired, because we do not want to mess with the DBA role.
Here the Create Role menu comes for help. Figure 7 shows the OEM screen to create the role; you have option to
customize the role creation as well.

6. Figure 7: Create Role screen of OEM
This creates a new role for you with only the used privileges - how sweet is that!
Read OTech Magazine at http://www.otechmag.com/2014/otech-magazine-winter-2014/