After you create a rule set, Database Vault makes it available for selection for realms, factors, command rules, and secure application roles. You can also use predefined rule sets. For example, use rule sets to:
- Define the conditions under which a realm authorization is active (as a further restriction to realm authorization)
- Define when to execute a command rule
- Enable a secure application role
- Define when to assign the identity of a factor
Oracle-Defined Rule Sets
It is recommended that you use, but not modify, the default rule sets.
- Allow System Parameters: Controls the ability to set system initialization parameters
- 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
- 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.
- 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. It also allows individual accounts to change their own password using the ALTER USER statement.
Two other delivered rule sets are very simple yet very useful. They provide a quick way to achieve an always-true or always-false rule set result.
- The always-true rule set is called Enabled. Its single rule has the expression “1 = 1,” which is always true.
- The always-false rule set is called Disabled. Its single rule has the expression “1 = 0,” which is always false.
These rule sets can be used to react quickly in an emergency security situation where something has to be protected or opened immediately.
Creating and Maintaining Rules
You can create and maintain rules in Cloud Control or via the command line. To create a rule, you can enter the name of the rule and the expression that should be evaluated. This expression can be any expression that appears in a WHERE clause. It evaluates to either TRUE or FALSE. Rules can be nested within a rule set by including multiple expressions involving AND or OR logic in the Rule Expression. For example:
TO_CHAR(SYSDATE,'HH24') between '22' AND '23' AND SYS_CONTEXT('USERENV', 'SESSION_USER'='SUPERADMIN_USER'
Note: An effective way to test an expression is to put it in the WHERE clause of the following SELECT statement:
SELECT 1 FROM DUAL WHERE [expression]
If the value 1 is returned, the expression is TRUE. If no value is returned, the expression is FALSE. If you receive an error, the expression has an error in it.
Rule Set Tasks
You can perform the rule set tasks listed in the slide in Cloud Control or via the command line.
1. When you create a rule set, you specify a name, (optionally) a description, the status of “enabled” or “disabled,” and evaluation options.
- For Evaluation Options, a value of All True means that all the rules listed in the rule set must be true in order for the rule set to evaluate to TRUE.
- A value of Any True means that as long as any one of the rules evaluates to TRUE, the entire rule set is considered to be TRUE.
2. A rule set consists of one or more rules. In the process of creating or editing a rule set, you can add new or existing rules to it.
3. The following pages have more details about the additional bullet points.
Auditing Rule Sets
Database Vault Audit Views in a Non-Unified Audit Environment
In a non-unified auditing environment, Database Vault writes the audit trail to the DVSYS.AUDIT_TRAIL$ table. The DVSYS.DV$ENFORCEMENT_AUDIT data dictionary view captures DVSYS.AUDIT_TRAIL$ audit trail records for violations of realms, rules, rule sets, factors, and other Oracle Database Vault policy enforced objects.
Database Vault Audit Views in a Unified Audit Environment
If you have enabled unified auditing, this setting does not capture audit records. Instead, you must create and enable audit policies to capture this information. The SYS.DV$ENFORCEMENT_AUDIT data dictionary view provides information about enforcement-related audits from the UNIFIED_AUDIT_TRAIL view.
SQL> CREATE AUDIT POLICY audpol1 ACTIONS COMPONENT = dv realm violation on "HR Schema"; SQL> audit policy audpol1; SQL> select DV_ACTION_NAME,DV_RETURN_CODE, DV_ACTION_OBJECT_NAME, DV_RULE_SET_NAME from unified_audit_trail where DV_RETURN_CODE<>0; DV_ACTION_NAME DV_RETURN_CODE DV_ACTION_OBJECT_NAME DV_RULE_SET_NAME ---------------------- --------------- ---------------------- ---------------------- Realm Violation Audit 47401 HR Schema Non Work Hours
Specific columns are defined for the rule sets in the audit trail: the RULE_SET_NAME and RULE_NAME columns in DVSYS.DV$ENFORCEMENT_AUDIT or the DV_RULE_SET_NAME column in SYS.DV$ENFORCEMENT_AUDIT. Consider Audit on Failure, for example: If a rule set evaluates to FALSE, an audit record is written, which includes the rule set that failed along with the specific name of the rule that caused the failure.
Setting a Custom Event Handler
You can set a procedure to be called when a rule set is evaluated. It can be set to either execute on failure or execute every time the rule set is evaluated (on success or failure).
Custom event-handler options:
- Handler Disabled: Does not run any custom event method.
- Execute On Failure: Runs the custom event method when the rule set evaluates to false or one of the associated rules contains an invalid PL/SQL expression.
- Execute On Success: Runs the custom event method when the rule set evaluates to true.
Custom event-handler logic: Enter a PL/SQL expression up to 255 characters in mixed-case capitalization. An expression may include any package procedure or stand-alone procedure. You can create your own expression or use the PL/SQL interfaces, which are part of the Database Vault Rule Set APIs.<
Using Rule Sets with Realms
A rule set can be used to provide an extra check on whether a user can access realm-protected objects. When you add an authorization to a realm, you can specify an authorization rule set. This rule set must be satisfied in order to allow access to the realm-protected objects.
Use case 1: The HR user is a realm participant and can access protected objects. However, the addition of a rule means that it must also resolve to a true condition for access to be granted. For example, the “Work Week” rule requires that the current day on the database server be a weekday.
Use case 2: Consider a situation in which several users need to run large and complex queries against the tables in the SH schema. So as not to overload the system during office hours, it is decided thatthese queries should run during nonwork hours The usersthatrun these queries decided that these queries should run during nonwork hours. The users that run these queries have all been granted the NIGHT_REPORTS database role, which gives them the access they need to the database objects involved in their queries. You need to create a rule set that ensures that any users with the NIGHT_REPORTS role are only allowed to run SELECT statements on the SH schema tables and views if the time is not between the hours of 6:00 AM and 5:00 PM.
Rule Set Reports
Reports that analyze rule sets include:
- The Rule Set Configuration Issues report displays the Database Vault rule set information where no rules are defined or enabled for a rule set.
- The Secure Application Configuration Issues report lists secure application roles that have incomplete or disabled rule sets.
- The Command Rule Configuration Issues report lists rule sets that are incomplete or disabled.
Rule Set Views
The following views in the DVSYS schema contain information about rule sets and rules:
- DBA_DV_RULE_SET: One row per rule set
- DBA DV RULE: One row per rule
- DBA_DV_RULE_SET_RULE: Associates a rule to a rule set
These views are useful for seeing, either programmatically or as an ad hoc query, information about the existing rule sets in the database. All the information viewable in Cloud Control is also available here. DBA_DV_RULE_SET is the parent table and contains information that is specific to the rule set definition, but nothing about the rules contained in it. DBA_DV_RULE contains information about each of the rules. DBA_DV_RULE_SET_RULE is the intersection table; it associate a rule set.For convenience, this view contains all the information that is in the DBA_DV_RULE view,therefore, there is no need to join it to the DBA_DV_RULE view.
You can run meaningful queries on these views by joining the rule set names, as shown in the example in the slide.
SELECT rs.rule_set_name, rs.enabled, rsr.rule_name, rsr.rule_expr, rsr.rule_order FROM dvsys.dba_dv_rule_set rs, dvsys.dba_dv_rule_set_rule rsr WHERE rs rule set name = rsr rule set name;
RULE_SET_NAME ENABLED RULE_NAME RULE_EXPR -------------------------- ------- --------------- ----------------------------- Can Maintain Own Account Y Is User Manager DVSYS.DBMS_MACUTL.USER_HAS_... Disabled Y False 1=0 Enabled Y True 1=1
Rule Set API
The rule set API enables you to do anything that Cloud Control can do with rule sets, including some things that cannot be done. Here are the procedures that you can call to manipulate rule sets and rules:
– CREATE_RULE_SET (rule_set_name, description, enabled, eval_options, audit_options, fail_options, fail_message, fail_code, handler_options, handler, is_static). The is_static parameter determines how often a rule set is evaluated when it is accessed and is not settable in the Cloud Control. If TRUE, the rule set is evaluated once during the session; if FALSE, it is evaluated every time.
– UPDATE_RULE_SET (rule_set_name,description, enabled, eval_options, audit_options, fail_options, fail_message, fail_code, handler_options, handler, is_static). The is_static parameter determines how often a rule set is evaluated when it is accessed and is not settable in the Cloud Control. If TRUE, the rule set is evaluated once during the session; if FALSE, it is evaluated every time.
– RENAME_RULE_SET (rule_set_name, new_name) – DELETE_RULE_SET (rule_set_name).
– CREATE_RULE (rule_name, rule_expr)
– UPDATE_RULE (rule_name, rule_expr)
– RENAME_RULE (rule_name, new_name)
– DELETE_RULE (rule_name)
– ADD_RULE_TO_RULE_SET (rule_set_name, rule_name)
– DELETE_RULE_FROM_RULE_SET (rule_set_name, rule_name)