Your SlideShare is downloading. ×
Enforcing principle of least privilege
Enforcing principle of least privilege
Enforcing principle of least privilege
Enforcing principle of least privilege
Enforcing principle of least privilege
Enforcing principle of least privilege
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Enforcing principle of least privilege

182

Published on

PDF version of article published in OTech magazine Winter 2014 Edition. …

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

Published in: Technology, Art & Photos
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
182
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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/

×