Rule sets group one or more rules together; the rules determine whether a user can perform an action on an object.
UTL_MAIL
PL/SQL package and an access control list to create an email alert for security violations.A rule set is a collection of one or more rules.
You can associate the rule set with a realm authorization, factor assignment, command rule, or secure application role.
The rule set evaluates to true or false based on the evaluation of each rule it contains and the evaluation type (All True or Any True). A rule within a rule set is a PL/SQL expression that evaluates to true or false. You can create a rule and add the rule to multiple rule sets.
You can use rule sets to accomplish the following activities:
As a further restriction to realm authorization, to define the conditions under which realm authorization is active
To define when to allow a command rule
To enable a secure application role
To define when to assign the identity of a factor
When you create a rule set, Oracle Database Vault makes it available for selection when you configure the authorization for a realm, command rule, factor, or secure application role.
In a multitenant environment, you can create a rule set and its associated rules in the application root.
A common realm must use a common rule set when the associated realm or command rule is evaluated by Database Vault. The common rule set and its rules can only be created in the application root. After the common rule set is created, it exists in every container that is associated with the root where the common rule set is created. The common rule set can only include common rules.
To configure a common rule set and its rules, you must be commonly granted the DV_OWNER
or DV_ADMIN
role.
Related Topics
Oracle Database Vault provides a set of default rules sets that you can customize for your needs.
You can find a full list of rule sets by querying the DBA_DV_RULE_SET
data dictionary view. To find rules that are associated with a rule set, query the DBA_DV_RULE_SET_RULE
data dictionary view.
The default rule sets are as follows:
Allow Dumping Datafile Header: This rule set prevents the dumping of data blocks.
Allow Fine Grained Control for Alter System: This rule set enables you to control the ability of users to set initialization parameters using the ALTER SYSTEM
SQL statement.
Allow Fine Grained Control of System Parameters: Note: This rule set has been deprecated.
This rule set provides a very flexible, fine-grained control over initialization parameters that manage system security, dump or destination location, backup and restore settings, optimizer settings, PL/SQL debugging, and security parameters. It affects the following initialization parameters, based on the associated rules of this rule set:
Are System Security Parameters Allowed rule: Cannot set O7_DICTIONARY_ACCESSIBILITY
Are Dump or Dest Parameters Allowed rule: Cannot set the following parameters:
Parameter B-D | Parameters D-U |
---|---|
|
|
|
|
|
|
|
|
|
|
Are Backup Restore Parameters Allowed rule: Cannot set RECYCLEBIN
(but does not prevent disabling the recycle bin)
Are Database File Parameters Allowed rule: Cannot set CONTROL_FILES
Are Optimizer Parameters Allowed rule: Can set OPTIMIZER_SECURE_VIEW_MERGING = FALSE
(but TRUE
not allowed)
Are PL-SQL Parameters Allowed rule: Can set PLSQL_DEBUG = FALSE
(but TRUE
not allowed), cannot set UTL_FILE_DIR
. The UTL_FILE_DIR
initialization parameter is deprecated. It is still supported for backward compatibility. However, Oracle recommends that you instead use directory objects. See Oracle Database Reference for more information about UTL_FILE_DIR
.
Are Security Parameters Allowed rule: Cannot set the following:
Parameters A-A | Parameters O-S |
---|---|
|
|
|
|
|
|
See Oracle Database Reference for detailed information about initialization parameters.
Allow Sessions: Controls the ability to create a session in the database. This rule set enables you to add rules to control database logins using the CONNECT command rule. The CONNECT command rule is useful to control or limit SYSDBA
access to programs that require its use. This rule set is not populated.
Allow System Parameters: Note: This rule set has been deprecated.
Controls the ability to set system initialization parameters. Since Oracle Database 11g Release 2 (11.2), the Allow Fine Grained Control of System Parameters rule set has replaced this rule set, but it is still supported for backward compatibility. The Allow System Parameters rule set is not associated with any commands, but its rules are still available and can be used with any custom rule set. Oracle recommends that you use the Allow Fine Grained Control of System Parameters rule set.
Can Grant VPD Administration: Controls the ability to grant the GRANT EXECUTE
or REVOKE EXECUTE
privileges on the Oracle Virtual Private Database DBMS_RLS
package, with the GRANT
and REVOKE
statements.
Can Maintain Accounts/Profiles: Controls the roles that manage user accounts and profiles, through the CREATE USER
, DROP USER
, CREATE PROFILE
, ALTER PROFILE
, or DROP PROFILE
statements.
Can Maintain Own Account: Allows the accounts with the DV_ACCTMGR
role to manage user accounts and profiles with the ALTER USER
statement. Also allows individual accounts to change their own password using the ALTER USER
statement. See DV_ACCTMGR Database Vault Account Manager Role for more information about the DV_ACCTMGR
role.
Disabled: Convenience rule set to quickly disable security configurations like realms, command rules, factors, and secure application roles.
Enabled: Convenience rule set to quickly enable system features.
Not allow to set AUDIT_SYS_OPERATIONS to False: Prevents the AUDIT_SYS_OPERATIONS
initialization parameter from being set to FALSE
. If unified auditing is enabled, then the AUDIT_SYS_OPERATIONS
parameter has no effect.
Not allow to set OPTIMIZER_SECURE_VIEW_MERGING to True: Prevents the OPTIMIZER_SECURE_VIEW_MERGING
initialization parameter from being set to TRUE
.
Not allow to set OS_ROLES to True: Prevents the OS_ROLES
initialization parameter from being set to TRUE
.
Not allow to set PLSQL_DEBUG to True: Prevents the PLSQL_DEBUG
initialization parameter from being set to TRUE
.
Not allow to set REMOTE_OS_ROLES to True: Prevents the REMOTE_OS_ROLES
initialization parameter from being set to TRUE
.
Not allow to set SQL92_SECURITY to False: Prevents the SQL92_SECURITY
from being set to FALSE
.
Not allow to turn off AUDIT_TRAIL:
Prevents theAUDIT_TRAIL
initialization parameter from being turned off. If unified auditing is enabled, then the AUDIT_TRAIL
parameter has no effect.To create a rule set, you first create the rule set itself, and then you can edit the rule set to associate it with one or more rules.
See Also:
Auditing Oracle Database Vault for more information about audit records in the DVSYS.AUDIT_TRAIL$
table
Oracle Database Security Guide for information about creating unified audit policies for Database Vault
A rule defines the behavior that you want to control; a rule set is a named collection of rules.
You can create rules during the rule set creation process, or independently of it.
After you create the rule, you can associate a rule set with one or more additional rules.
If you create a new rule during the rule set creation process, the rule is automatically added to the current rule set. You also can add existing rules to the rule set. Alternatively, you can omit adding rules to the rule set and use it as a template for rule sets you may want to create in the future.
You can add as many rules that you want to a rule set, but for better design and performance, you should keep the rule sets simple. See Guidelines for Designing Rule Sets for additional advice.
The rule set evaluation depends on the evaluation of its rules using the Evaluation Options (All True or Any True). If a rule set is disabled, Oracle Database Vault evaluates the rule set to true without evaluating its rules.
Related Topics
Default rules are rules that have commonly used behavior, such as checking if an action evaluates to true or false.
You can find a full list of rules by querying the DBA_DV_RULE
data dictionary view.Table 6-1 lists the current default Oracle Database rules.
Table 6-1 Current Default Oracle Database Vault Rules
Rule | Description |
---|---|
Are Backup Restore Parameters Allowed |
Note: This default rule has been deprecated. Checks if the current SQL statement attempts to turn on the |
Are Database File Parameters Allowed |
Note: This default rule has been deprecated. Checks if the current SQL statement attempts to alter control file related configuration |
Are Dump Parameters Allowed |
Checks if the current SQL statement attempts to alter initialization parameters related to the destination of a dump |
Are Dest Parameters Allowed |
Checks if the current SQL statement attempts to alter initialization parameters related to the size limit of a dump |
Are Dump or Dest Parameters Allowed |
Note: This default rule has been deprecated. Checks if the current SQL statement attempts to alter initialization parameters related to the size limit or destination of dump |
Are Optimizer Parameters Allowed |
Note: This default rule has been deprecated. Checks if the current SQL statement attempts to alter the setting for the |
Are PL-SQL Parameters Allowed |
Note: This default rule has been deprecated. Checks if the current SQL statement attempts to alter the following initialization parameters:
|
Are Security Parameters Allowed |
Note: This default rule has been deprecated. Checks if there is an attempt to disable the following initialization parameters:
Note that if you have enabled unified auditing, then the This rule prevents any attempt to enable the following parameters:
|
Are System Security Parameters Allowed |
Note: This default rule has been deprecated. Prevents modification of the following parameters:
|
False |
Evaluates to |
Is Alter DVSYS Allowed |
Note: This default rule has been deprecated. Checks if the logged-in user can execute the |
Is Database Administrator |
Checks if a user has been granted the |
Is Drop User Allowed |
Checks if the logged in user can drop users |
Is Dump of Block Allowed |
Checks if the dumping of blocks is allowed |
Is First Day of Month |
Checks if the specified date is the first day of the month |
Is Label Administrator |
Checks if the user has been granted the |
Is Last Day of Month |
Checks if the specified date is the last day of the month |
Is _dynamic_rls_init Parameters Allowed |
Note: This default rule has been deprecated. Prevent modification of the |
Is Parameter Value False |
Checks if a specified parameter value has been set to |
Is Parameter Value None |
Checks if a specified parameter value has been set to |
Is Parameter Value Not False |
Checks if a specified parameter value has been set to |
Is Parameter Value Not None |
Checks if a specified parameter value has been set to |
Is Parameter Value Not Off |
Checks if a specified parameter value has been set to |
Is Parameter Value Not On |
Checks if a specified parameter value has been set to |
Is Parameter Value Not True |
Checks if a specified parameter value has been set to |
Is Parameter Value Off |
Checks if a specified parameter value has been set to |
Is Parameter Value On |
Checks if a specified parameter value has been set to |
Is Parameter Value True |
Checks if a specified parameter value has been set to |
Is SYS or SYSTEM User |
Checks if the user is |
Is Security Administrator |
Checks if a user has been granted the |
Is Security Owner |
Checks if a user has been granted the |
Is User Manager |
Checks if a user has been granted the |
Is _system_trig_enabled Parameters Allowed |
Note: This default rule has been deprecated. Checks if the user tries to modify the following system parameters, but in database recovery operations, this rule permits these parameters to be changed.
Note that if you have enabled unified auditing, then the |
Is o7_dictionary_accessibility Parameters Allowed |
Note: This default rule has been deprecated. Checks if current SQL statement attempts to alter the setting of the |
Login User Is Object User |
Checks if the logged in user is the same as the user about to be altered by the current SQL statement |
No Exempt Access Policy Role |
Checks if the user has been granted the |
Not Export Session |
Obsolete |
True |
Evaluates to |
After you have created one or more rules, you can use Enterprise Manager Cloud Control to add to a rule set.
Before you remove a rule from a rule set, you can locate the various references to it using Cloud Control.
After you remove the rule from the rule set, the rule still exists. If you want, you can associate it with other rule sets. If you want to delete the rule, then you can do so from the Rules page.
Before you remove a rule set, you should remove the rule set references to Oracle Database Vault components.
You can use Enterprise Manager Cloud Control to find reference to the rule set and then delete the rule set.
Understanding how rule sets work helps to create more effective rule sets.
Oracle Database Vault evaluates the rules within a rule set as a collection of expressions.
If you have set Evaluation Options to All True and if a rule evaluates to false, then the evaluation stops at that point, instead of attempting to evaluate the rest of the rules in the rule set. Similarly, if Evaluation Options is set to Any True and if a rule evaluates to true, the evaluation stops at that point. If a rule set is disabled, Oracle Database Vault evaluates it to true without evaluating its rules.
You can nest one or more rules within the rule set.
For example, suppose you want to create a nested rule, Is Corporate Network During Maintenance, that performs the following two tasks:
It limits table modifications only when the database session originates within the corporate network.
It restricts table modifications during the system maintenance window scheduled between 10:00 p.m. and 10:59 p.m.
The rule definition would be as follows:
DVF.F$NETWORK = 'Corporate' AND TO_CHAR(SYSDATE,'HH24') between '22' AND '23'
You can also create rules to apply to everyone except one user (for example, a privileged user).
To create a rule that excludes specific users, user the SYS_CONTEXT
function.
For example:
SYS_CONTEXT('USERENV','SESSION_USER') = 'SUPERADMIN_USER' OR additional_rule
If the current user is a privileged user, then the system evaluates the rule to true without evaluating additional_rule
. If the current user is not a privileged user, then the evaluation of the rule depends on the evaluation of additional_rule
.
This tutorial demonstrates how to use the UTL_MAIL
PL/SQL package and an access control list to create an email alert for security violations.
UTL_MAIL
PL/SQL package, which you must manually install, has procedures to manage email notifications.leo_dvowner
can use the CREATE PROCEDURE
statement to create the email security alert.UTL_MAIL
, you must configure an access control list (ACL) to enable fine-grained access to external network services.DBMS_MACADM
PL/SQL package.In tutorial, you create an email alert that is sent when a user attempts to alter a table outside a maintenance period.
To do this, you must create a rule to set the maintenance period hours, attach this rule to a rule set, and then create a command rule to allow the user to alter the table. You then associate the rule set with this command rule, which then sends the email alert when the user attempts to use the ALTER TABLE
SQL statement outside the maintenance period.
Note:
To complete this tutorial, you must use a database that has an SMTP server.
The UTL_MAIL
PL/SQL package, which you must manually install, has procedures to manage email notifications.
User leo_dvowner
can use the CREATE PROCEDURE
statement to create the email security alert.
Before you can use UTL_MAIL
, you must configure an access control list (ACL) to enable fine-grained access to external network services.
For detailed information about fine-grained access to external network services, see Oracle Database Security Guide.
To create the rule set and command rule, you can use DBMS_MACADM
PL/SQL package.
This tutorial demonstrates how to use Oracle Database Vault to control the authorization of two users.
patch_boss
and patch_user.
In this tutorial, you configure a rule set that defines two-person integrity (TPI).
This feature is also called dual key security, dual key connection, and two-man rule security. In this type of security, two users are required to authorize an action instead of one user.
The idea is that one user provides a safety check for the other user before that user can proceed with a task. Two-person integrity provides an additional layer of security for actions that potentially can be dangerous. This type of scenario is often used for tasks such as database patch updates, which is what this tutorial will demonstrate. One user, patch_user
must log into perform a database patch upgrade, but the only way that he can do this is if his manager, patch_boss
is already logged in. You will create a function, rules, a rule set, and a command rule to control patch_user
's ability to log in.
You must create two users for this tutorial, patch_boss
and patch_user.
patch_boss
acts in a supervisory role: If patch_boss
is not logged in, then the patch_user
user cannot log in.
patch_user
is the user who is assigned to perform the patch upgrade. However, for this tutorial, user patch_user
does not actually perform a patch upgrade. He only attempts to log in.
To create the users:
In a real-world scenario, you also would log in as the DV_OWNER
user and grant the DV_PATCH_ADMIN
role to user patch_user
(but not to patch_boss
). But because you are not really going to perform a database patch upgrade in this tutorial, you do not need to grant this role to user patch_user
.
The behavior of the Database Vault settings will be determined by the function.
check_boss_logged_in
, does just that: When user patch_user
tries to log into the database instance, it checks if user patch_boss
is already logged in by querying the V$SESSION
data dictionary view.Next, you must create two rules, a rule set to which you will add them, and a command rule.
check_boss_logged_in
function when user patch_user
tries to logs in to the database.Oracle provides guidelines for designing rule sets.
You can share rules among multiple rule sets. This lets you develop a library of reusable rule expressions. Oracle recommends that you design such rules to be discrete, single-purpose expressions.
You can design a rule set so that its evaluation is static, that is, it is evaluated only once during a user session. Alternatively, it can be evaluated each time the rule set is accessed. If the rule set is evaluated only once, then the evaluated value is reused throughout the user session each time the rule set is accessed. Using static evaluation is useful in cases where the rule set must be accessed multiple times but the conditions on which the rule set depend do not change during that session. An example would be a SELECT command rule associated with a rule set when the same SELECT
statement occurs multiple times and if the evaluated value is acceptable to use again, rather than evaluating the rule set each time the SELECT
occurs.
To control the static evaluation of the rule set, set the is_static
parameter of the CREATE_RULE_SET
or UPDATE_RULE_SET
procedures of the DBMS_MACADM
PL/SQL package. See DBMS_MACADM Rule Set Procedures for more information.
Use Oracle Database Vault factors in your rule expressions to provide reusability and trust in the values used by your rule expressions. Factors can provide contextual information to use in your rules expressions.
You can use custom event handlers to extend Oracle Database Vault security policies to integrate external systems for error handling or alerting. Using Oracle utility packages such as UTL_TCP
, UTL_HTTP
, UTL_MAIL
, UTL_SMTP
, or DBMS_AQ
can help you to achieve this type of integration.
Test rule sets thoroughly for various accounts and scenarios either on a test database or on a test realm or command rule for nonsensitive data before you apply them to realms and command rules that protect sensitive data. You can test rule expressions directly with the following SQL statement:
SQL> SELECT SYSDATE from DUAL where rule expression
You can nest rule expressions inside a single rule. This helps to achieve more complex situations where you would need a logical AND
for a subset of rules and a logical OR
with the rest of the rules. See the definition for the Is Corporate Network During Maintenance rule set under Tutorial: Creating an Email Alert for Security Violations for an example.
You cannot use invoker's rights procedures with rule expressions. Only use definer's rights procedures with rule expressions.
The number and complexity of rules can slow database performance.
Rule sets govern the performance for execution of certain operations. For example, if you have a very large number of rules in a rule set governing a SELECT
statement, performance could degrade significantly.
If you have rule sets that require many rules, performance improves if you move all the rules to logic defined in a single PL/SQL standalone or package function. However, if a rule is used by other rule sets, there is little performance effect on your system.
If possible, consider setting the rule set to use static evaluation, assuming this is compatible with the associated command rule's usage. See Guidelines for Designing Rule Sets for more information.
You can check system performance by running tools such as Oracle Enterprise Manager (including Oracle Enterprise Manager Cloud Control, which is installed by default with Oracle Database), Automatic Workload Repository (AWR), and TKPROF
.
See Also:
Oracle Database Performance Tuning Guide to learn how to monitor database performance
Oracle Database SQL Tuning Guide to monitor the performance of individual SQL and PL/SQL statements
Oracle Database Vault provides reports and data dictionary views that are useful for analyzing rule sets and the rules within them.
Table 6-2 lists the Oracle Database Vault reports. See Oracle Database Vault Reports for information about how to run these reports.
Table 6-2 Reports Related to Rule Sets
Report | Description |
---|---|
Lists rule sets that have no rules defined or enabled |
|
Lists secure application roles that have incomplete or disabled rule sets |
|
Lists rule sets that are incomplete or disabled |
Table 6-3 lists data dictionary views that provide information about existing rules and rule sets.
Table 6-3 Data Dictionary Views Used for Rules and Rule Sets
Data Dictionary View | Description |
---|---|
Lists the rules that have been defined |
|
Lists the rule sets that have been created |
|
Lists rules that are associated with existing rule sets |