Changes in This Release for Oracle Database Vault Administrator's Guide

An Oracle Database Vault policy groups and manages realms and command rules that have something in common in a single policy.

For example, the realms and command rules can have an application or schema in common.

The status of the realms and command rules in this policy can be updated at once, in a single command, instead of performing the update individually on each security object. Also new to this release is the DV_POLICY_OWNER role, which provides the grantee user the authority to perform basic administration tasks. This user can add authorized users to the realms that are included in the policy and change the policy state without being granted the powerful DV_OWNER role.

The following new functionality supports this feature:

• DBMS_MACADM PL/SQL procedures:

  • DBMS_MACADM.ADD_CMD_RULE_TO_POLICY

  • DBMS_MACADM.ADD_OWNER_TO_POLICY

  • DBMS_MACADM.ADD_REALM_TO_POLICY

  • DBMS_MACADM.CREATE_POLICY

  • DBMS_MACADM.DELETE_CMD_RULE_FROM_POLICY

  • DBMS_MACADM.DELETE_OWNER_FROM_POLICY

  • DBMS_MACADM.DELETE_REALM_FROM_POLICY

  • DBMS_MACADM.DROP_POLICY

  • DBMS_MACADM.RENAME_POLICY

  • DBMS_MACADM.UPDATE_POLICY_DESCRIPTION

  • DBMS_MACADM.UPDATE_POLICY_STATE

• Role:

  • DV_POLICY_OWNER

• Data dictionary views:

  • DVSYS.DBA_DV_POLICY

  • DVSYS.DBA_DV_POLICY_OBJECT

  • DVSYS.DBA_DV_POLICY_OWNER

  • DVSYS.POLICY_OWNER_COMMAND_RULE

  • DVSYS.POLICY_OWNER_POLICY

  • DVSYS.POLICY_OWNER_REALM

  • DVSYS.POLICY_OWNER_REALM_AUTH

  • DVSYS.POLICY_OWNER_REALM_OBJECT

  • DVSYS.POLICY_OWNER_RULE

  • DVSYS.POLICY_OWNER_RULE_SET

  • DVSYS.POLICY_OWNER_RULE_SET_RULE

Simulation mode protects Oracle Database Vault security objects so that SQL commands are not blocked, but violations to the security controls are logged.

Simulation mode can also be set for the new Oracle Database Vault policy, which then sets it on embedded objects. This status is between the full protection of being enabled and blocking the access of SQL statements and being disabled. When realms and command rules are set to the simulation mode, violations that occur to these security controls are only logged to the simulation log file. They are not enforced or deny access to the user. This enables you to more quickly certify applications with Oracle Database Vault and to move new realms and command rules to production. You can implement a mandatory realm on a test application database schema and then set it to simulation mode. After running the full test application regression test, you then can analyze the simulation mode log to determine which users and which trusted paths to authorize to the test application schema. You can also develop new command rules and migrate them to production in simulation mode for a period of time to determine the impact they would have when they are enabled.

The simulation mode log is available for viewing in the DBA_DV_SIMULATION_LOG data dictionary view. After you have finished testing the realm and command rule, you can clear the contents of the DBA_DV_SIMULATION_LOG view for the next time you need to test Database Vault configurations in a test environment.

The following functionality supports this features:

• New or changed DBMS_MACADM PL/SQL procedures:

  • DBMS_MACADM.CREATE_REALM (changed)

  • DBMS_MACADM.UPDATE_REALM (changed)

  • DBMS_MACADM.CREATE_COMMAND_RULE (changed)

  • DBMS_MACADM.UPDATE_COMMAND_RULE (changed)

  • DBMS_MACADM.DELETE_COMMAND_RULE (changed)

  • DBMS_MACADM.CREATE_CONNECT_COMMAND_RULE (new)

  • DBMS_MACADM.UPDATE_CONNECT_COMMAND_RULE (new)

  • DBMS_MACADM.DELETE_CONNECT_COMMAND_RULE (new)

  • DBMS_MACADM.CREATE_SESSION_EVENT_CMD_RULE (new)

  • DBMS_MACADM.UPDATE_SESSION_EVENT_CMD_RULE (new)

  • DBMS_MACADM.DELETE_SESSION_EVENT_CMD_RULE (new)

  • DBMS_MACADM.CREATE_SYSTEM_EVENT_CMD_RULE (new)

  • DBMS_MACADM.UPDATE_SYSTEM_EVENT_CMD_RULE (new)

  • DBMS_MACADM.DELETE_SYSTEM_EVENT_CMD_RULE (new)

• New data dictionary view and table:

  • DBA_DV_SIMULATION_LOG data dictionary view

  • DVSYS.SIMULATION_LOG$ table

Privilege analysis policies now capture more privilege use than in previous releases, find unused privilege grants, and create named capture runs.

• Additional privilege captures: You now can create privilege analysis policies that capture compilation privileges that are used for definer’s rights and invoker’s rights program units, that capture privileges that were used for Code Based Access Control (CBAC) role use, and that capture secure application role use.

• Unused privilege grants: The privilege capture reports now indicate which privilege grants were not used by users or roles.

• Capture runs: A capture run defines the period of time that a privilege capture takes place. You define the capture run when you enable the policy. You can create multiple capture runs for use with one policy and then use these capture runs in comparison reports.

In a multitenant environment, you now can create common realms and common command rules within the application PDB context.

The benefit of creating common realms and command rules (that is, in the application root) is that you can manage them from a central location in a multitenant environment, rather than in individual pluggable databases (PDBs). Realms for the application root common objects must be configured in the application PDB or root. Local realms and local command rules can still be implemented on individual PDBs over and above any common realms and common command rules.

Common realms can only be created on common objects in the application root. You cannot create common realms in the CDB root. However, you can create common command rules in either the application root or the CDB root. A common command rule in the application root applies to its associated PDBs. Common command rules that are in the CDB root will apply to all PDBs in the CDB environment. When you create a common object in the application root, you must synchronize it so that it is visible in the individual PDBs, but if you create a common object in the CDB root, it is synchronized automatically. To synchronize an object in the application root, you use the ALTER PLUGGABLE DATABASE APPLICATION statement with the SYNC clause.

The following functionality supports this feature:

• New or changed DBMS_MACADM PL/SQL procedures:

  • All realm-related DBMS_MACADM PL/SQL procedures

  • All command rule-related DBMS_MACADM PL/SQL procedures

  • DBMS_MACADM.ADD_CMD_RULE_TO_POLICY (new)

  • DBMS_MACADM.DELETE_CMD_RULE_FROM_POLICY (new)

• New or changed data dictionary views:

  • DBA_DV_COMMAND_RULE

  • DVSYS.DBA_DV_POLICY_OBJECT (new)

  • DBA_DV_REALM

  • DVSYS.DV$REALM

  • DBA_DV_REALM_AUTH

  • DBA_DV_REALM_OBJECT

  • DBA_DV_RULE_SET

  • DBA_DV_RULE_SET_RULE

Command rules now provide more ALTER SESSION and ALTER SYSTEM functionality, and CONNECT command rule enhancements.

In previous releases, you could create command rules for the ALTER SESSION and ALTER SYSTEM statements, but the functionality that you could include was limited. Starting with this release, Oracle Database Vault provides the ability to include event settings that are commonly used by ALTER SESSION and ALTER SYSTEM. The options for these special command rules enable you to use many of the features of the ALTER SESSION and ALTER SYSTEM statements, such as the ability to use the SET clause for parameter settings.

In addition, Oracle has made the management of the CONNECT command rule easier to maintain. In previous releases, you could create a CONNECT command rule, but if, for example, you had to create four different command rules for four different users, then you had to create a complex rule with OR and AND keywords to account for the multiple users in one command rule. With this release, you can create a CONNECT command rule for each user.

The changed and new DBMS_MACADM PL/SQL procedures to manage the ALTER SESSION, ALTER SYSTEM, and CONNECT command rules are as follows:

• DBMS_MACADM.CREATE_COMMAND_RULE (changed)

• DBMS_MACADM.UPDATE_COMMAND_RULE (changed)

• DBMS_MACADM.CREATE_CONNECT_COMMAND_RULE (new)

• DBMS_MACADM.UPDATE_CONNECT_COMMAND_RULE (new)

• DBMS_MACADM.DELETE_CONNECT_CONNECT_RULE (new)

• DBMS_MACADM.CREATE_SESSION_EVENT_CMD_RULE (new)

• DBMS_MACADM.UPDATE_SESSION_EVENT_CMD_RULE (new)

• DBMS_MACADM.DELETE_SESSION_EVENT_CMD_RULE (new)

• DBMS_MACADM.CREATE_SYSTEM_EVENT_CMD_RULE (new)

• DBMS_MACADM.UPDATE_SYSTEM_EVENT_CMD_RULE (new)

• DBMS_MACADM.DELETE_SYSTEM_EVENT_CMD_RULE (new)

Starting with this release, the Authentication_Method default factor can be used for external and global user authentication.

This enhancement provides for global and external authentication when the Kerberos and Secure Sockets Layer (SSL) strong authentication features are used.

Starting with this release, the default value for the SQL92_SECURITY parameter has changed from FALSE to TRUE.

You now can use Oracle Flashback Technology features and Information Lifecycle Management (ILM) features in an Oracle Database Vault-enabled database.

The Oracle Flashback Technology enhancement enables you to use Database Vault realms and command rules to control access to database objects while you are using the Oracle Flashback features. You can protect the PURGE TABLE, PURGE INDEX, FLASHBACK TABLE, PURGE TABLESPACE, PURGE RECYCLEBIN, PURGE DBA_RECYCLEBIN, CREATE FLASHBACK ARCHIVE, ALTER FLASHBACK ARCHIVE, DROP FLASHBACK ARCHIVE SQL statements with Database Vault command rules.

The ILM enhancement enables you to use Database Vault realms and command rules with the Automatic Data Optimization (ADO) features, including granting to users the authorization to enable an ADO administrative user to perform ILM operations on Database Vault-protected objects. This enhancement enables ILM to meet regulatory compliance requirements for data retention and protection, and to store large amounts of data at the lowest cost, using storage tiering. To manage authorizations for users to perform ILM operations, two new procedures are introduced with this release: DBMS_MACADM.AUTHORIZE_MAINTENANCE_USER and DBMS_MACADM.UNAUTHORIZE_MAINTENANCE_USER. To find information about ILM authorization grants, a new data dictionary view, DBA_DV_MAINTENANCE_AUTH, is provided.

Oracle Data Guard logical standby databases can perform rolling upgrades for Oracle Database Vault-enabled systems using transient logical standby and the DBMS_ROLLING package.

See Integrating Oracle Database Vault with Oracle Data Guard for more information.

Several default rules and rule sets are no longer included in a fresh installation of Oracle Database Vault.

The following rules are no longer included in a fresh installation of an Oracle Database 12c release 2 (12.2) database:

• Is _system_trig_enabled Parameters Allowed

• Is o7_dictionary_accessibility Parameters Allowed

• Is _dynamic_rls_init Parameters Allowed

• Is Alter DVSYS Allowed

• Are System Security Parameters Allowed

• Are Dump or Dest Parameters Allowed

• Are Backup Restore Parameters Allowed

• Are Database File Parameters Allowed

• Are Optimizer Parameters Allowed

• Are PL-SQL Parameters Allowed

• Are Security Parameters Allowed

The following default rule sets are not included in fresh installations of Oracle Database 12c release 2 (12.2):

• Allow System Parameters

• Allow Fine Grained Control of System Parameters

These rules and rule sets are replaced by new rules and rule sets that are more secure.

The UTL_FILE_DIR parameter has been deprecated for this release.

This parameter is still supported for backward compatibility. However, Oracle recommends that you use directory objects instead.