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.

- 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.

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.

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

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.

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/