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

Additional Privileges for the DV_ACCTMGR Role

In this release, users who have been granted the DV_ACCTMGR role can manage users who have been granted the DV_MONITOR,DV_SECANALYST, and DV_AUDIT_CLEANUP roles. This functionality enables you to easily change the password for user accounts such as the DBSNMP user, which often expires, and which have roles such as DV_MONITOR.

See the following sections for more information about these roles:

• "DV_MONITOR Database Vault Monitoring Role"

• "DV_SECANALYST Database Vault Security Analyst Role"

• "DV_AUDIT_CLEANUP Audit Trail Cleanup Role"

Support for the Oracle Label Security Function OLS_LABEL_DOMINATES in Rules

When creating rules, you now can include the public standalone function OLS_LABEL_DOMINATES, which is also new to this release.

See the following sections for more information:

• "CREATE_RULE Procedure" for an example of creating a rule that uses the OLS_LABEL_DOMINATES function

• Oracle Label Security Administrator's Guide for more information about the OLS_LABEL_DOMINATES function

Improvements for the Profile Used to Store Privileges for Privilege Analysis

Starting with this release, the captured privileges for pre-compiled database objects such as PL/SQL packages are stored in the ORA$DEPENDENCY profile. This profile cannot be deleted.

See "How Privilege Analysis Works with Pre-Compiled Database Objects" for more information about how privilege analysis works with precompiled database objects.

Changes to Registering Oracle Database Vault

In previous releases of Oracle Database Vault, you registered (that is, enabled) Database Vault with a database by using Oracle Database Configuration Assistant (DBCA). You now can register Database Vault from the command line, by using the DVSYS.CONFIGURE_DV and DBMS_MACADM.ENABLE_DV procedures.

See the following sections for more information:

• "Registering Oracle Database Vault with an Oracle Database"

• "DVSYS.CONFIGURE_DV General System Maintenance Procedure"

• "ENABLE_DV Procedure"

Changes to Enabling or Disabling Oracle Database Vault

This release introduces two new DBMS_MACADM procedures that you can use when you enable or disable Oracle Database Vault: DBMS_MACADM.ENABLE_DV and DBMS_MACADM.DISABLE_DV.

See the following sections for more information:

• Appendix B, "Disabling and Enabling Oracle Database Vault"

• "DISABLE_DV Procedure"

• "ENABLE_DV Procedure"

Simplified Oracle Database Vault Administration

Starting with this release, you can access Database Vault Administrator (DVA) from Oracle Enterprise Manager. DVA is no longer an independent application. The advantage of this design is that it makes it easier for you to create, view, and modify Oracle Database Vault settings from a centralized location when you are working with Oracle Database.

Another enhancement is that all of the configuration-related DBMS_MACADM PL/SQL package procedures and functions have been incorporated into the Enterprise Manager interface. For example, you now can delete rules from a rule set using the interface.

See "Logging into Oracle Database Vault" for more information.

Default Protection for Database Vault Schemas

Because the Database Vault metadata (for example, policy and factors) as well as the administrative packages reside in the DVSYS and DVF schemas, these schemas are critical to the integrity of Oracle Database Vault. Starting from this release, direct login to these accounts will be blocked by default. You can disable or re-enable this default protection by using two new DBMS_MACADM procedures: DBMS_MACADM.DISABLE_DV_DICTIONARY_ACCTS and DBMS_MACADM.ENABLE_DV_DICTIONARY_ACCTS. You must have the DV_OWNER role to execute these procedures.

Performing Privilege Analysis for System and Object Privileges

You now can easily identify excessive system and object privilege grants or roles and privileges that are not being used, even with large numbers of user accounts in complex Oracle Database installations. A privilege analysis finds privilege usage according to a specified condition. For example, the privilege analysis can record privileges that are used to run a given application module and privileges that are used by a given logon user. The results of the privilege analysis are stored in data dictionary views.

See Chapter 4, "Performing Privilege Analysis to Find Privilege Use," for more information.

New Oracle Database Vault Realms

• Oracle Default Schema Protection realm. This realm protects roles and schemas that relate to Oracle Database options such as Oracle OLAP, Oracle Spatial, and Oracle Text.

• Oracle System Privilege and Role Management realm. This realm protects sensitive roles that are used for exporting and importing data to and from a database. It also contains user authorizations for users who must be able to grant system privileges.

• Oracle Default Component Protection realm. This realm protects the SYSTEM and OUTLN schemas.

Changed Oracle Database Vault Realms

• Oracle Database Vault realm. This realm protects configuration and role information in the DVSYS, DVF, and LBACSYS schemas. Starting with this release, the SYS.AQ%DATAPUMP% tables and view have been removed from this realm. These objects no longer need realm protection because Oracle Streams Advanced Queuing and Oracle Data Pump authorizations are now handled differently.

  See the following sections for more information:

  • "Privileges for Using Oracle Streams with Oracle Database Vault"

  • "Using Oracle Data Pump with Oracle Database Vault"

• Database Vault Account Management realm. This realm is designed for administrators who are responsible for creating and managing database accounts and database profiles. Starting with this release, the account manager (role DV_ACCTMGR) can grant the CREATE SESSION privilege to users.

Mandatory Realm Protection

In previous releases of Oracle Database Vault, object owners or users who had object privileges for objects within a realm still had access to these objects, even if these users were not realm participants or realm owners. In this release, you optionally can restrict these users' access to the objects by using a mandatory realm. In a mandatory realm, only realm participants and realm owners can access realm-protected objects.

Mandatory realms enable you to have more flexibility when you create Database Vault policies and they help you to achieve more security. Additional advantages of mandatory realms are that in some cases they prevent roles from being altered to achieve access based on role authorization, and they are useful during patch upgrades. Roles that are protected by a mandatory realm cannot be modified. Therefore, no privileges can be granted to or revoked from a role once it is protected by a mandatory realm.

See "Using Mandatory Realms to Restrict User Access to Objects within a Realm" for more information.

Additional Audit Information for Realms

In previous releases, the audit trail recorded only the last realm evaluated for any realm enforcement policies. Starting with this release, the ACTION_OBJECT_ID and ACTION_OBJECT_NAME fields of the new DVSYS.DV$CONFIGURATION_AUDIT and DVSYS.DV$ENFORCEMENT_AUDIT data dictionary views will capture all realm IDs and realm names that have the audit option set to audit on failure or audit on success or failure.

See the following sections for more information:

• "DVSYS.DV$CONFIGURATION_AUDIT View"

• "DVSYS.DV$ENFORCEMENT_AUDIT View"

Additional DBMS_MACADM PL/SQL Authorization Procedures

In this release, the following procedures have been added to the DBMS_MACADM PL/SQL package, to give you greater control over more specific user authorizations:

• DBMS_MACADM.AUTHORIZE_DDL grants users authorization to execute data definition language (DDL) statements on the specified schema. To revoke this authorization, you can use the DBMS_MACADM.UNAUTHORIZE_DDL procedure.

• DBMS_MACADM.AUTHORIZE_PROXY_USER grants users authorization to proxy other user account. To revoke this authorization, you can use the DBMS_MACADM.UNAUTHORIZE_PROXY_USER procedure.

See the following sections for more information:

• "AUTHORIZE_DDL"

• "UNAUTHORIZE_DDL Procedure"

• "AUTHORIZE_PROXY_USER"

• "UNAUTHORIZE_PROXY_USER Procedure"

Changes to Oracle Data Pump and Oracle Scheduler in Oracle Database Vault

In this release, the following default rule sets for Oracle Data Pump and Oracle Scheduler have been removed:

• Allow Oracle Data Pump Operation

• Allow Scheduler Job

The following data dictionary views have been added, which record information about the Oracle Data Pump and Oracle Scheduler authorizations in Database Vault:

• DVSYS.DBA_DV_DATAPUMP_AUTH

• DVSYS.DBA_DV_JOB_AUTH

The following DBMS_MACADM PL/SQL package procedures have been added so that you can authorize or unauthorize users to perform Oracle Data Pump transportable tablespace operations in an Oracle Database Vault environment:

• "AUTHORIZE_TTS_USER Procedure"

• "UNAUTHORIZE_TTS_USER Procedure"

See the following sections for more information:

• "Using Oracle Data Pump with Oracle Database Vault"

• "DVSYS.DBA_DV_DATAPUMP_AUTH View"

• "Using Oracle Scheduler with Oracle Database Vault"

• "DVSYS.DBA_DV_JOB_AUTH View"

Integration in a Multitenant Environment

Oracle Database 12c Release 1 (12.1) now enables you to consolidate multiple databases, called pluggable databases (PDBs), into one large Oracle database called a multitenant container database (CDB). This enables you to better manage many applications that are built on one or more Oracle databases. Databases that are protected by Oracle Database Vault can accommodate CDBs.

See the following for more information:

• "How Oracle Database Vault Works in a Multitenant Environment"

• Oracle Database Administrator's Guide for details about managing a multitenant environment

Ability to Control the Use of the ORADEBUG Utility

You can enable or disable the use of the ORADEBUG utility in an Oracle Database Vault environment. This enhancement enables you to prevent the misuse of critical ORADEBUG features such as manipulating and dumping internal structures, enabling or disabling SQL tracing for other users, and suspending intensive processes in a Database Vault-enabled database.

See "Using the ORADEBUG Utility with Oracle Database Vault" for more information.

Inclusion of Database Vault Records in the Unified Audit Trail

This release introduces the unified audit trail, in which the various Oracle Database audit trails (such as the standard audit trail, fine grained audit trail, and so on, in addition to the Database Vault and Oracle Label Security audit trails) are consolidated into one audit trail. In a new installation, unified auditing is enabled. If you are upgrading from an earlier release, then you can choose between a unified or non-unified auditing environment. If you choose to use unified auditing, then Oracle Database Vault audit records are stored in a table in the Oracle Database AUDSYS schema, not the Database Vault AUDIT_TRAIL$ table in the SYS schema.

By having the various audit trails in one location, you have one centralized view of all auditing that has occurred from different areas of the database. The unified audit records are presented in a consistent, uniform format. This makes it easier for you to run analysis reports, for example.

See Oracle Database Security Guide for more information about how to capture unified audit records for Oracle Database Vault.

Auditing of the Oracle Database Vault Administrator's Actions

Starting with this release, Oracle Database Vault can audit all actions performed by the Database Vault administrator. All configuration changes made to Database Vault components, such as realms or factors, are now written to the audit trail. This auditing captures the creation, modification, and deletion of most Database Vault enforcements as well as Database Vault authorization for components such as Oracle Data Pump and Oracle Scheduler. However, it does not audit by default the grants and revocations of Database Vault-protected roles, such as DV_OWNER and DV_ADMIN. This type of audit relies on the audit configuration of the relevant Oracle Database Vault realms.

See Appendix A, "Auditing Oracle Database Vault," for information about auditing.

New Data Dictionary Views to Capture Audit Data

The following unified auditing-specific data dictionary views are new for this release:

• DVSYS.DV$CONFIGURATION_AUDIT provides information about Database Vault configuration changes made by the Database Vault administrator. See "DVSYS.DV$CONFIGURATION_AUDIT View" for more information.

• DVSYS.DV$ENFORCEMENT_AUDIT provides information about user activities that affect Database Vault enforcement policies. See "DVSYS.DV$ENFORCEMENT_AUDIT View" for more information.

New Role for Cleaning the Oracle Database Vault Audit Trail

For better separation of duty, this release introduces the DV_AUDIT_CLEANUP role, which can be granted to any user who is responsible for cleaning the Database Vault audit trail. This role does not apply to unified auditing environments.

See the following sections for more information about using this role:

• "DV_AUDIT_CLEANUP Audit Trail Cleanup Role"

• "Archiving and Purging the Oracle Database Vault Audit Trail"