Privilege analysis dynamically analyzes the privileges and roles that users use and do not use.
READ ANY TABLE
system privilege.DBA
role and performs database tuning operations.Oracle Database Vault with Oracle Database Release 12c includes a feature called privilege analysis to help you increase the security of your applications and database operations.
CAPTURE_ADMIN
role.Because it is a dynamic analysis, it captures real privileges and roles that were actually used.
Because it is a dynamic analysis, it captures real privileges and roles that were actually used.
Privilege analysis captures privileges used by database users and applications at runtime. If your applications include definer’s rights and invoker’s rights procedures, then privilege analysis captures the privileges that are required to compile a procedure and execute it, even if the procedure was compiled before the privilege capture was created and enabled.
Running inside the Oracle Database kernel, privilege analysis helps reduce the attack surface of applications and increase operational security by identifying used and unused privileges. Privilege analysis can be used after you install Oracle Database Release 12c without any additional configuration steps.
Note:
If you want to configure privilege analysis by using Oracle Enterprise Manager Cloud Control, then ensure that you have the latest plug-in. For information about how to deploy a plug-in, see Enterprise Manager Cloud Control Administrator's Guide.
Privilege analysis can be used to capture the privileges that have been exercised on pre-compiled database objects.
Examples of these objects are PL/SQL packages, procedures, functions, views, triggers, and Java classes and data.
Because these privileges may not be exercised during run time when a stored procedure is called, these privileges are collected when you generate the results for any database-wide capture, along with run-time captured privileges. A privilege is treated as an unused privilege when it is not used in either pre-compiled database objects or run-time capture, and it is saved under the run-time capture name. If a privilege is used for pre-compiled database objects, then it is saved under the capture name ORA$DEPENDENCY
. If a privilege is captured during run time, then it is saved under the run-time capture name. If you want to know what the used privileges are for both pre-compiled database objects and run-time usage, then you must query both the ORA$DEPENDENCY
and run-time captures. For unused privileges, you only need to query with the run-time capture name.
To find a full list of the pre-compiled objects on which privilege analysis can be used, query the TYPE
column of the ALL_DEPENDENCIES
data dictionary view.
To use privilege analysis, you must be granted the CAPTURE_ADMIN
role.
You use the DBMS_PRIVILEGE_CAPTURE
PL/SQL package to manage privilege capture. You use the data dictionary views provided by privilege analysis to analyze your privilege use.
You can create different types of privilege analysis policies to achieve specific goals.
Role-based privilege use capture. You must provide a list of roles. If the roles in the list are enabled in the database session, then the used privileges for the session will be captured. You can capture privilege use for the following types of roles: Oracle default roles, user-created roles, Code Based Access Control (CBAC) roles, and secure application roles.
Context-based privilege use capture. You must specify a Boolean expression only with the SYS_CONTEXT
function. The used privileges will be captured if the condition evaluates to TRUE
.
Role- and context-based privilege use capture. You must provide both a list of roles that are enabled and a SYS_CONTEXT
Boolean expression for the condition. When any of these roles is enabled in a session and the given context condition is satisfied, then privilege analysis starts capturing the privilege use.
Database-wide privilege capture. If you do not specify any type in your privilege analysis policy, then the used privileges in the database will be captured, except those for the user SYS
. (This is also referred to as unconditional analysis, because it is turned on without any conditions.)
Note the following restrictions:
You can enable only one privilege analysis policy at a time. The only exception is that you can enable a database-wide privilege analysis policy at the same time as a non-database-wide privilege analysis policy, such as a role or context attribute-driven analysis policy.
You cannot analyze the privileges of the SYS
user.
Privilege analysis shows the grant paths to the privilege but it does not suggest which grant path to keep.
If the role, user, or object has been dropped, then the values that reflect the privilege captures for these in the privilege analysis data dictionary views are dropped as well.
Analyzing privilege use is beneficial in finding unnecessarily granted privileges.
The privileges of the account that accesses a database should only be limited to the privileges that are strictly required by the application.
But when an application is developed, especially by a third party, more privileges than necessary may be granted to the application connection pool accounts for convenience. In addition, some developers grant system and application object privileges to the PUBLIC
role.
For example, to select from application data and run application procedures, the system privileges SELECT ANY TABLE
and EXECUTE ANY PROCEDURE
are granted to an application account appsys
. The account appsys
now can access non-application data even if he or she does not intend to. In this situation, you can analyze the privilege usage by user appsys
, and then based on the results, revoke and grant privileges as necessary.
During the application development phase, some administrators may grant many powerful system privileges and roles to application developers.
The administrators may do this because at that stage they may not know what privileges the application developer needs.
Once the application is developed and working, the privileges that the application developer needs — and does not need — become more apparent. At that time, the security administrator can begin to revoke unnecessary privileges. However, the application developer may resist this idea on the basis that the application is currently working without problems. The administrator can use privilege analysis to examine each privilege that the application uses, to ensure that when he or she does revoke any privileges, the application will continue to work.
For example, app_owner
is an application database user through whom the application connects to a database. User app_owner
must query tables in the OE
, SH
, and PM
schemas. Instead of granting the SELECT
object privilege on each of the tables in these schemas, a security administrator grants the SELECT ANY TABLE
privilege to app_owner
. After a while, a new schema, HR
, is created and sensitive data are inserted into HR.EMPLOYEES
table. Because user app_owner
has the SELECT ANY TABLE
privilege, he can query this table to access its sensitive data, which is a security issue. Instead of granting system privileges (particularly the ANY
privileges), it is far better to grant object privileges for specific tables.
You can create and use privilege analysis policies in a multitenant environment.
If you are using a multitenant environment, then you can create privilege analysis policies in either the CDB root or in individual PDBs. The privilege analysis policy applies only to the container in which it is created, either to the privileges used within the CDB root or the application root, or to the privileges used within a PDB. It cannot be applied globally throughout the multitenant environment. You can grant the CAPTURE_ADMIN
role locally to a local user or a common user. You can grant the CAPTURE_ADMIN
role commonly to common users.
See Also:
Oracle Database Administrator’s Guide for more information about multitenant container databases (CDBs)
You can create and manage privilege analysis policies in either SQL*Plus or in Enterprise Manager Cloud Control.
DBMS_PRIVILEGE_CAPTURE
PL/SQL package to analyze privileges.DBMS_PRIVILEGE_CAPTURE
PL/SQL package.DBMS_PRIVILEGE_CAPTURE
PL/SQL package.DBMS_PRIVILEGE_CAPTURE
PL/SQL package.DBMS_PRIVILEGE_CAPTURE
PL/SQL package.DBMS_PRIVILEGE_CAPTURE
PL/SQL package.You can use Oracle Enterprise Manager Cloud Control or the DBMS_PRIVILEGE_CAPTURE
PL/SQL package to analyze privileges.
Before you can do so, you must be granted the CAPTURE_ADMIN
role. The DBMS_PRIVILEGE_CAPTURE
package enables you to create, enable, disable, and drop privilege analysis policies. It also generates reports that show the privilege usage, which you can view in DBA_*
views.
See Also:
Oracle Database PL/SQL Packages and Types Reference for detailed information about the DBMS_PRIVILEGE_CAPTURE
PL/SQL package
You must follow a general set of steps to analyze privileges.
You can create a privilege analysis policy in either Enterprise Manager Cloud Control or from SQL*Plus, using the DBMS_PRIVILEGE_CAPTURE
PL/SQL package.
SYS
schema.DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE
procedure creates a privilege analysis policy.When a policy is created, it resides in the Oracle data dictionary and the SYS
schema.
However, both SYS
and the user who created the policy can drop it. After you create the policy, you must manually enable it so that it can begin to analyze privilege use. If you want to configure privilege analysis by using Oracle Enterprise Manager Cloud Control, then ensure that you have the latest plug-in. For information about how to deploy a plug-in, see Enterprise Manager Cloud Control Administrator's Guide.
You can create a privilege analysis policy in Cloud Control.
The DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE
procedure creates a privilege analysis policy.
After you create the privilege analysis policy, you can find it listed in the DBA_PRIV_CAPTURES
data dictionary view.
Use the following syntax for the DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE
procedure:
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE( name VARCHAR2, description VARCHAR2 DEFAULT NULL, type NUMBER DEFAULT DBMS_PRIVILEGE_CAPTURE.G_DATABASE, roles ROLE_NAME_LIST DEFAULT ROLE_NAME_LIST(), condition VARCHAR2 DEFAULT NULL);
In this specification:
name
: Specifies the name of the privilege analysis policy to be created. Ensure that this name is unique and no more than 128 characters. You can include spaces in the name, but you must enclose the name in single quotation marks whenever you refer to it. To find the names of existing policies, query the NAME
column of the DBA_PRIV_CAPTURES
view.
description
: Describes the purpose of the privilege analysis policy, up to 1024 characters in mixed-case letters. Optional.
type
: Specifies the type of capture condition. If you omit the type
parameter, then the default is DBMS_PRIVILEGE_CAPTURE.G_DATABASE
. Optional.
Enter one of the following types:
DBMS_PRIVILEGE_CAPTURE.G_DATABASE
: Captures all privileges used in the entire database, except privileges from user SYS
.
DBMS_PRIVILEGE_CAPTURE.G_ROLE
: Captures privileges for the sessions that have the roles enabled. If you enter DBMS_PRIVILEGE_CAPTURE.G_ROLE
for the type
parameter, then you must also specify the roles
parameter. For multiple roles, separate each role name with a comma.
DBMS_PRIVILEGE_CAPTURE.G_CONTEXT
: Captures privileges for the sessions that have the condition specified by the condition
parameter evaluating to TRUE
. If you enter DBMS_PRIVILEGE_CAPTURE.G_CONTEXT
for the type
parameter, then you must also specify the condition
parameter.
DBMS_PRIVILEGE_CAPTURE.G_ROLE_AND_CONTEXT
: Captures privileges for the sessions that have the role enabled and the context condition evaluating to TRUE
. If you enter DBMS_PRIVILEGE_CAPTURE.G_ROLE_AND_CONTEXT
for the type
parameter, then you must also specify both the roles
and condition
parameters.
roles
: Specifies the roles whose used privileges will be analyzed. That is, if a privilege from one of the given roles is used, then the privilege will be analyzed. You must specify this argument if you specify DBMS_PRIVILEGE_CAPTURE.G_ROLE
or DBMS_PRIVILEGE_CAPTURE.G_ROLE_AND_CONTEXT
for the type
argument. Each role you enter must exist in the database. (You can find existing roles by querying the DBA_ROLES
data dictionary view.) For multiple roles, use varray type role_name_list
to enter the role names. You can specify up to 10 roles.
For example, to specify two roles:
roles => role_name_list('role1', 'role2'),
condition
: Specifies a Boolean expression up to 4000 characters. You must specify this argument if you specify DBMS_PRIVILEGE_CAPTURE.G_CONTEXT
or DBMS_PRIVILEGE_CAPTURE.G_ROLE_AND_CONTEXT
for the type
argument. Only SYS_CONTEXT
expressions with relational operators(==
, >
, >=
, <
, <=
, <>
, BETWEEN
, and IN
) are permitted in this Boolean expression.
The condition
expression syntax is as follows:
predicate::= SYS_CONTEXT(namespace, attribute) relop constant_value | SYS_CONTEXT(namespace, attribute) BETWEEN constant_value AND constant_value | SYS_CONTEXT(namespace, attribute) IN {constant_value (,constant_value)* } relop::= = | < | <= | > | >= | <> context_expression::= predicate | (context_expression) AND (context_expression) | (context_expression) OR (context_expression )
For example, to use a condition to specify the IP address 192.0.2.1
:
condition => 'SYS_CONTEXT(''USERENV'', ''IP_ADDRESS'')=''192.0.2.1''';
* You can add as many constant values as you need (for example, IN {
constant_value1
}
, or IN {
constant_value1
,
constant_value2
,
constant_value3
}
).
Remember that after you create the privilege analysis policy, you must enable it, as described in Enabling a Privilege Analysis Policy.
You can create a variety of privilege analysis policies.
DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE
can be used to analyze database-wide privileges.DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE
procedure can be used to analyze the privilege usage of multiple roles.DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE
procedure can be used to capture privileges for analysis.DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE
can be used to analyze user access when the user is running SQL*Plus.The DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE
can be used to analyze database-wide privileges.
Example 4-1 shows how to use the DBMS_PRIVILEGE_CAPTURE
package to create and enable a privilege analysis policy to record all privilege use in the database.
Example 4-1 Privilege Analysis of Database-Wide Privileges
BEGIN DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE( name => 'db_wide_capture_pol', description => 'Captures database-wide privileges', type => DBMS_PRIVILEGE_CAPTURE.G_DATABASE); END; / EXEC DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE ('db_wide_capture_pol');
The DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE
procedure can be used to analyze the privilege usage of multiple roles.
Example 4-2 shows how to analyze the privilege usage of two roles.
Example 4-2 Privilege Analysis of Privilege Usage of Two Roles
BEGIN DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE( name => 'dba_roles_capture_pol', description => 'Captures DBA and LBAC_DBA role use', type => DBMS_PRIVILEGE_CAPTURE.G_ROLE, roles => role_name_list('dba', 'lbac_dba')); END; / EXEC DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE ('dba_roles_capture_pol');
The DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE
procedure can be used to capture privileges for analysis.
Example 4-3 shows how to analyze privileges used to run SQL*Plus.
Example 4-3 Privilege Analysis of Privileges During SQL*Plus Use
BEGIN DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE( name => 'sqlplus_capture_pol', description => 'Captures privilege use during SQL*Plus use', type => DBMS_PRIVILEGE_CAPTURE.G_CONTEXT, condition => 'SYS_CONTEXT(''USERENV'', ''MODULE'')=''sqlplus'''); END; / EXEC DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE ('sqlplus_capture_pol');
The DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE
can be used to analyze user access when the user is running SQL*Plus.
Example 4-4 shows how to analyze the privileges used by session user PSMITH
when running SQL*Plus.
Example 4-4 Privilege Analysis of PSMITH Privileges During SQL*Plus Access
BEGIN DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE( name => 'psmith_sqlplus_analysis_pol', description => 'Analyzes PSMITH role priv use for SQL*Plus module', type => DBMS_PRIVILEGE_CAPTURE.G_CONTEXT, condition => 'SYS_CONTEXT(''USERENV'', ''MODULE'')=''sqlplus'' AND SYS_CONTEXT(''USERENV'', ''SESSION_USER'')=''PSMITH'''); END; / EXEC DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE ('psmith_sqlplus_analysis_pol');
You can enable a privilege analysis policy using either Enterprise Manager Cloud Control or from SQL*Plus, using the DBMS_PRIVILEGE_CAPTURE
PL/SQL package.
DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE
procedure enables a privilege policy and creates a capture run name for it.After you create a privilege analysis policy, you must enable it.
When you enable a privilege analysis policy, you can create a named capture run for the policy’s findings. The capture run defines a period of time from when the capture is enabled (begun) and when it is disabled (stopped). This way, you can create multiple runs and then compare them when you generate the privilege capture results. Tutorial: Using Capture Runs to Analyze ANY Privilege Use provides an example of how you can create and generate multiple capture runs.
The general process for managing multiple named capture runs is as follows:
Create the policy.
Enable the policy for the first run.
After a period time to collect user behavior data, disable this policy and its run.
Generate the results and then query the privilege analysis data dictionary views for information about this capture run.
If you omit the run_name
parameter from the DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT
procedure, then this procedure looks at all records as a whole and then analyzes them.
Re-enable the policy for the second run. You cannot create a new capture run if the policy has not been disabled first.
After you have collected the user data, disable the policy and the second run.
Generate the results.
Query the privilege analysis data dictionary views. The results from both capture runs are available in the views. If you only want to show the results of one of the capture runs, then you can regenerate the results and requery the privilege analysis views.
Once enabled, the privilege analysis policy will begin to record the privilege usage when the condition is satisfied. At any given time, only one privilege analysis policy in the database can be enabled. The only exception is that a privilege analysis policy of type DBMS_PRIVILEGE_CAPTURE.G_DATABASE
can be enabled at the same time with a privilege analysis of a different type.
When you drop a privilege analysis policy, its associated capture runs are dropped as well and are not reflected in the privilege analysis data dictionary views.
Restarting a database does not change the status of a privilege analysis. For example, if a privilege analysis policy is enabled before a database shutdown, then the policy is still enabled after the database shutdown and restart.
You can enable a privilege analysis policy using Cloud Control.
You can disable a privilege analysis policy using either Enterprise Manager Cloud Control or from SQL*Plus, using the DBMS_PRIVILEGE_CAPTURE
PL/SQL package.
DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE
procedure disables a privilege analysis policy.You must disable the privilege analysis policy before you can generate a privilege analysis report.
After you disable the policy, then the privileges are no longer recorded. Disabling a privilege analysis policy takes effect immediately for user sessions logged on both before and after the privilege analysis policy is disabled.
You can disable a privilege analysis policy using Cloud Control.
CAPTURE_ADMIN
role and the SELECT ANY DICTIONARY
privilege. Oracle Database 2 Day DBA explains how to log in.You can generate a privilege analysis policy report using either Enterprise Manager Cloud Control or from SQL*Plus, using the DBMS_PRIVILEGE_CAPTURE
PL/SQL package.
DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT
procedure generates a report showing the results of a privilege capture.After the privilege analysis policy has been disabled, you can generate a report.
In Enterprise Manager Cloud Control, you can view the reports from the Privilege Analysis page Actions menu, and from there, revoke and regrant roles and privileges as necessary. To view the report results in SQL*Plus, query the data dictionary views in Privilege Analysis Policy and Report Data Dictionary Views. If a privilege is used during the privilege analysis process and then revoked before you generate the report, then the privilege is still reported as a used privilege, but without the privilege grant path.
You can generate a privilege analysis report using Cloud Control.
A privilege analysis report provides information about both used and unused privileges.
You can drop a privilege analysis policy report using either Enterprise Manager Cloud Control or from SQL*Plus, using the DBMS_PRIVILEGE_CAPTURE
PL/SQL package.
DBMS_PRIVILEGE_CAPTURE.DROP_CAPTURE
procedure drops a privilege analysis policy.Before you can drop a privilege analysis policy, you must first disable it.
Dropping a privilege analysis policy also drops all the used and unused privilege records associated with this privilege analysis. If you created capture runs for the policy, they are dropped when you drop the policy.
You can drop a privilege analysis policy by using Cloud Control.
CAPTURE_ADMIN
role and the SELECT ANY DICTIONARY
privilege. Oracle Database 2 Day DBA explains how to log in.You can create new roles using privileges found in a privilege analysis report and then grant this role to users.
You can use the report summary to find the least number of privileges an application needs, and encapsulate these privileges into a role.
You can use Enterprise Manager Cloud Control to revoke and regrant roles and privileges to users.
You can generate a script that revokes or regrants privileges from and to users, based on the results of privilege analysis reports.
You can perform a bulk revoke of unused system and object privileges and roles by using scripts that you can download after you have generated the privilege analysis.
Later on, if you want to regrant these privileges back to the user, you can generate a regrant script. In order to generate the regrant script, you must have a corresponding revoke script.
Execute the revoke scripts in a development or test environment. Be aware that you cannot revoke privileges and roles from Oracle-supplied accounts and roles.
You can use Enterprise Manager Cloud Control to generate a script that revokes privileges from users.
This tutorial demonstrates how to create capture runs to analyze the use of the READ ANY TABLE
system privilege.
pa_admin
must create and enable the privilege analysis policy.app_user
uses the READ ANY TABLE
system privilege.app_user
.pa_admin
then can generate and view a privilege analysis report.ANY_priv_analysis_pol
privilege analysis policy.You must create two users, one user to create the policy and a second user whose privilege use will be analyzed.
The user pa_admin
must create and enable the privilege analysis policy.
User app_user
uses the READ ANY TABLE
system privilege.
You must disable the policy before you can generate a report that captures the actions of user app_user
.
With the privilege analysis policy disabled, user pa_admin
then can generate and view a privilege analysis report.
Next, you are ready to create a second capture run for the ANY_priv_analysis_pol
privilege analysis policy.
This tutorial demonstrates how to analyze the privilege use of a user who has the DBA
role and performs database tuning operations.
pa_admin
must create the and enable the privilege analysis policy.tjones
uses the DBA
role to perform database tuning operations.tjones
.pa_admin
can generate and view privilege analysis reports.You must create two users, one to create the privilege analysis policy and a second user whose privilege use will be analyzed.
User pa_admin
must create the and enable the privilege analysis policy.
User tjones
uses the DBA
role to perform database tuning operations.
You must disable the policy before you can generate a report that captures the actions of user tjones
.
With the privilege analysis policy disabled, user pa_admin
can generate and view privilege analysis reports.
Oracle Database provides data dictionary views that show information about analyzed privileges.
Table 4-1 lists these data dictionary views.
Table 4-1 Data Dictionary Views That Display Privilege Analysis Information
View | Description |
---|---|
|
Lists information about existing privilege analysis policies |
|
Lists the privileges and capture runs that have been used for reported privilege analysis policies |
|
Lists the privilege grants that have not been used |
|
Lists the privileges and capture runs that have not been used for reported privilege analysis policies |
|
Lists the object privileges and capture runs that have been used for reported privilege analysis policies. It does not include the object grant paths. |
|
Lists the object privileges and capture runs that have not been used for reported privilege analysis policies. It does not include the object privilege grant paths. |
|
Lists the object privileges and capture runs that have been used for reported privilege analysis policies. It includes the object privilege grant paths. |
|
Lists the object privileges and capture runs that have not been used for reported privilege analysis policies. It includes the object privilege grant paths. |
|
Lists the system privileges and capture runs that have been used for reported privilege analysis policies. It does not include the system privilege grant paths. |
|
Lists the system privileges and capture runs that have not been used for reported privilege analysis policies. It does not include the system privilege grant paths. |
|
Lists the system privileges and capture runs that have been used for reported privilege analysis policies. It includes the system privilege grant paths. |
|
Lists the system privileges and capture runs that have not been used for reported privilege analysis policies. It includes system privilege grant paths |
|
Lists all the privileges and capture runs for the |
|
Lists the user privileges and capture runs that have been used for reported privilege analysis policies. It does not include the user privilege grant paths. |
|
Lists the user privileges and capture runs that have not been used for reported privilege analysis policies. It does not include the user privilege grant paths. |
|
Lists the user privileges and capture runs that have been used for reported privilege analysis policies. It includes the user privilege grant paths. |
|
Lists the privileges and capture runs that have not been used for reported privilege analysis policies. It includes the user privilege grant paths. |
See Also:
Oracle Database Reference for a detailed description of these data dictionary views