The Oracle Database Vault security controls protect application data from unauthorized access, and comply with privacy and regulatory requirements.

You can deploy controls to block privileged account access to application data and control sensitive operations inside the database using trusted path authorization. Through the analysis of privileges and roles, you can increase the security of existing applications by using least privilege best practices. Oracle Database Vault secures existing database environments transparently, eliminating costly and time consuming application changes.

To provide increased security for consolidation, you can use Oracle Database Vault with Oracle Multitenant.

Oracle Database Vault can prevent privileged user access inside a pluggable database (PDB) and between the PDB and the common privileged user at the container database. Each PDB has its own Database Vault metadata, such as realms, rule sets, command rules, default policies (such as default realms), and so on. In addition, the objects within the DVSYS and DVF schemas are automatically available to any child PDBs. Both schemas are common user schemas.

You can configure common realms in the application root only, but you can create common rule sets and command rules in either the application root or the CDB root. A common command rule in the application root applies to its associated PDBs, and common command rules in the CDB root apply to all PDBs in the CDB environment. The ability to create common realms and command rules enables you to create policies that use a shared set of realms, rule sets, or command rules throughout the CDB environments, rather than having to create these same components for every PDB in the multitenant environment. The common protection applies for all PDBs associated with the application root that have Oracle Database Vault enabled.

You can create individual local policies for each PDB. When you use Database Vault to protect an object, Database Vault subjects common privileges for common objects to the same enforcement rules as local system privileges.

When you configure a PDB that has Database Vault enabled, the DVSYS schema is a common user schema that is stored in the root. This means that all the objects within the DVSYS schema (tables, data dictionary views, user accounts, PL/SQL packages, default policies, and so on) are subject to the common privileges available for this schema. In other words, you can create realms, factors, and so on in the root to protect the schema in the root. Ensure that you configure Database Vault in the root first, before you configure it in the associated PDBs.

When you enable Oracle Database Vault in the CDB root, you can choose either regular mode or strict mode. The settings propagate throughout the CDB based on the setting you choose. For example, suppose a CDB contains both Database Vault-enabled PDBs and PDBs in which Database Vault is not enabled. If you enable Database Vault using regular mode, then both types of PDBs continue to function normally. If you enable Database Vault using strict mode, then the Database Vault-disabled PDBs operate in restricted mode.

Figure 23-1 illustrates how the database in regular mode allows different access for common and local database administrators depending if Database Vault is enabled. In this scenario, neither the common user nor the local users have access to the realms in PDB1 and PDB2. Both the common user and the PDB3 local user have access to the Custom App application in PDB3, where Database Vault is not enabled.

Figure 23-1 Oracle Database Vault in a Multitenant Environment with Regular Mode

Description of "Figure 23-1 Oracle Database Vault in a Multitenant Environment with Regular Mode"

The DBA_DV_STATUS, CDB_DV_STATUS, DBA_OLS_STATUS, and CDB_OLS_STATUS data dictionary views verify if Oracle Database is configured and enabled.

In a multitenant environment, you register Oracle Database Vault with common users who will use the Database Vault-enforced roles in the CDB root.

1. In a multitenant environment, log into the root of the database instance as a user who has privileges to create users and grant the CREATE SESSION and SET CONTAINER privileges.

   For example:

   sqlplus c##dba_debra
   Enter password: password
   

2. Select user accounts (or create new users) that will be used for the Database Vault Owner (DV_OWNER role) and Database Vault Account Manager (DV_ACCTMGR role) accounts.

   Oracle strongly recommends that you maintain two accounts for each role. One account, the primary named user account, will be used on a day-to-day basis and the other account will be used as a backup account in case the password of the primary account is lost and must be reset.

   Prepend the names of these accounts with c## or C##. For example:

   GRANT CREATE SESSION, SET CONTAINER TO c##sec_admin_owen IDENTIFIED BY password CONTAINER = ALL;
   GRANT CREATE SESSION, SET CONTAINER TO c##dbv_owner_root_backup IDENTIFIED BY password CONTAINER = ALL;
   GRANT CREATE SESSION, SET CONTAINER TO c##accts_admin_ace IDENTIFIED BY password CONTAINER = ALL;
   GRANT CREATE SESSION, SET CONTAINER TO c##dbv_acctmgr_root_backup IDENTIFIED BY password CONTAINER = ALL;
   

   In this specification:

   • Create the primary accounts (c##sec_admin_owen and c##accts_admin_ace) if these do not already exist for the new roles, DV_ADMIN and DV_ACCTMGR.
   • Replace password with a password that is secure.
3. Connect to the root as user SYS with the SYSDBA administrative privilege

   CONNECT SYS AS SYSDBA
   Enter password: password
   

4. Configure the two backup Database Vault user accounts.
   For example:

   BEGIN
    CONFIGURE_DV (
      dvowner_uname         => 'c##dbv_owner_root_backup',
      dvacctmgr_uname       => 'c##dbv_acctmgr_root_backup',
      force_local_dvowner   => FALSE);
    END;
   /
   

   In this example, setting force_local_dvowner to FALSE enables the common users to have DV_OWNER privileges for the PDBs that are associated with this CDB root. Setting it to TRUE restricts the common DV_OWNER user to have the DV_OWNER role privileges for the CDB root only. If you grant DV_OWNER locally to the CDB root common user, then that user cannot grant the DV_OWNER role commonly to any other user.
5. Run the utlrp.sql script to recompile invalidated objects in the root.

   @?/rdbms/admin/utlrp.sql
   

   If the script provides instructions, follow them, and then run the script again. If the script terminates abnormally without giving any instructions, then run it again.

6. Connect to the root as the primary Database Vault Owner user that you just configured.

   For example:

   CONNECT c##dbv_owner_root_backup
   Enter password: password
   

7. Enable Oracle Database Vault using one of the following commands:

   • To enable Oracle Database Vault to use regular mode:

     EXEC DBMS_MACADM.ENABLE_DV;

   • If every associated PDB will need to have Database Vault enabled in this database, then use the following command. (You will need to enable each of these PDBs after you complete this procedure.) PDBs that do not have Database Vault enabled will be in restricted mode after the database is restarted and until Database Vault is enabled in the PDB:

     EXEC DBMS_MACADM.ENABLE_DV (strict_mode => 'y');

8. Connect with the SYSDBA administrative privilege.

   CONNECT / AS SYSDBA
   

9. Restart the database.

   SHUTDOWN IMMEDIATE
   STARTUP
   

10. Verify that Oracle Database Vault and Oracle Label Security are installed and enabled.

    SELECT * FROM DBA_DV_STATUS;
    SELECT * FROM DBA_OLS_STATUS;
    SELECT * FROM CDB_DV_STATUS;
    SELECT * FROM CDB_OLS_STATUS;

11. Connect as the backup DV_OWNER user and then grant the DV_OWNER role to the primary DV_OWNER user that you created earlier.

    For example:

    CONNECT c##dbv_owner_root_backup
    Enter password: password
    
    GRANT DV_OWNER TO c##sec_admin_owen WITH ADMIN OPTION;
    

12. Connect as the backup DV_ACCTMGR user and then grant the DV_ACCTMGR role to the backup DV_ACCTMGR user.

    For example:

    CONNECT c##dbv_acctmgr_root_backup
    Enter password: password
    
    GRANT DV_ACCTMGR TO c##accts_admin_ace WITH ADMIN OPTION;

13. Store the two backup account passwords in a safe location such as a privileged account management (PAM) system in case they are needed in the future.

In a multitenant environment, you must register Oracle Database Vault in the root first, then in the PDBs afterward.

1. If you have not already done so, then identify or create named common user accounts to be used as the Database Vault accounts along with associated backup accounts.
2. Ensure that you have registered Oracle Database Vault in the CDB root and that the DV_OWNER role was granted commonly to the common user.
3. Connect to the PDB as an administrator who is local to the PDB.
   For example:

   CONNECT dba_debra@pdb_name
   Enter password: password
   

   To find the available PDBs, query the DBA_PDBS data dictionary view. To check the current PDB, run the show con_name command.

4. Grant the CREATE SESSION and SET CONTAINER privileges to the users for this PDB.
   For example:

   GRANT CREATE SESSION, SET CONTAINER TO c##sec_admin_owen CONTAINER = CURRENT;
   GRANT CREATE SESSION, SET CONTAINER TO c##accts_admin_ace CONTAINER = CURRENT;
   

5. Connect as user SYS with the SYSDBA administrative privilege

   CONNECT SYS@pdb_name AS SYSDBA
   Enter password: password
   

6. While still in the PDB, configure the two backup Database Vault user accounts.

   BEGIN
    CONFIGURE_DV (
      dvowner_uname         => 'c##dbv_owner_root_backup',
      dvacctmgr_uname       => 'c##dbv_acctmgr_root_backup');
    END;
   /
   

   In this example, the force_local_dvowner parameter is omitted because it is unnecessary. All common users who are configured within a PDB are restricted to the scope of the PDB.

7. Run the utlrp.sql script to recompile invalidated objects in this PDB.

   @?/rdbms/admin/utlrp.sql
   

   If the script provides instructions, follow them, and then run the script again. If the script terminates abnormally without giving any instructions, then run it again.

8. Connect to the PDB as the backup Database Vault Owner user that you just configured.
   For example:

   CONNECT c##dbv_owner_root_backup@pdb_name
   Enter password: password
   

9. Enable Oracle Database Vault in this PDB.

   EXEC DBMS_MACADM.ENABLE_DV;
   

10. Connect to the CDB with the SYSDBA administrative privilege.

    CONNECT / AS SYSDBA
    

11. Close and reopen the PDB.
    For example:

    ALTER PLUGGABLE DATABASE pdb_name CLOSE IMMEDIATE;
    
    ALTER PLUGGABLE DATABASE pdb_name OPEN;
    

12. Verify that the PDB is configured and enabled for Database Vault.

    CONNECT SYS@pdb_name AS SYSDBA
    Enter password: password
    
    SELECT * FROM DBA_DV_STATUS;

13. Connect as the backup DV_OWNER user and then grant the DV_OWNER role to the primary DV_OWNER user that you created earlier.

    For example:

    CONNECT c##dbv_owner_root_backup
    Enter password: password
    
    GRANT DV_OWNER TO c##sec_admin_owen WITH ADMIN OPTION;
    

14. Connect as the backup DV_ACCTMGR user and then grant the DV_ACCTMGR role to the primary DV_ACCTMGR user.

    For example:

    CONNECT c##dbv_acctmgr_root_backup
    Enter password: password
    
    GRANT DV_ACCTMGR TO c##accts_admin_ace WITH ADMIN OPTION;

15. Store the two backup account passwords in a safe location such as a privileged account management (PAM) system in case they are needed in the future.

From SQL*Plus, in a multitenant environment, you can plug in a database that already has Database Vault enabled.

1. Log into the PDB as the local primary Database Vault owner.
   For example:

   sqlplus dbv_owner@pdb_name
   Enter password: password
   

   For example:

   To find the available PDBs, execute the show pdbs command. To check the current PDB, run the show con_name command.

2. Grant the common Database Vault DV_OWNER users the CREATE SESSION and SET CONTAINER privileges, and the appropriate Database Vault roles.
   The following accounts will be the primary and the backup accounts:

   GRANT CREATE SESSION, SET CONTAINER, DV_OWNER TO c##dbv_owner_root WITH ADMIN OPTION;
   GRANT CREATE SESSION, SET CONTAINER, DV_OWNER TO c##dbv_owner_root_backup WITH ADMIN OPTION;
   

3. Connect as a user who has been granted the DV_ACCTMGR role.
4. Create the DV_ACCTMGR common accounts.

   GRANT CREATE SESSION, SET CONTAINER, DV_ACCTMGR TO c##dbv_acctmgr_root WITH ADMIN OPTION;
   GRANT CREATE SESSION, SET CONTAINER, DV_ACCTMGR TO c##dbv_acctmgr_root_backup WITH ADMIN OPTION;

In a multitenant environment, you can create common and local command rules in either the CDB root or the application root.

Common command rules can be associated only with common realms, rule sets, and rules. Local command rules can be associated only with local realm, rule sets, and rules.

To apply these command rules to the entire multitenant environment, you must execute the command rule procedures from the CDB root or application root as a common user who has been granted the DVADM or DVOWNER role. A common command rule that is created in the CDB root will be applied to all PDBs in that CDB environment. A common command rule that is created in the application root will only be applied to the PDBs that are associated with this application root. To propagate the command rule to the PDBs that are associated with the CDB root or application root, you must synchronize the PDB. For example, to synchronize an application root called saas_sales_app to its application PDBs:

ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC;

To synchronize a common command rule in the CDB root to a PDB:

ALTER PLUGGABLE DATABASE APPLICATION APP$CDB$SYSTEM SYNC;

You can check a user’s roles by querying the USER_ROLE_PRIVS data dictionary view. To find information about command rules, query the DBA_DV_COMMAND_RULE data dictionary view.

You can convert a standalone Oracle Database Release 12c or later database to a PDB, and then plug this PDB into a CDB.

1. Connect to the root as a user who has been granted the DV_OWNER role.

   For example:

   sqlplus c##sec_admin
   Enter password: password
   

2. Grant the DV_PATCH_ADMIN role to user SYS with CONTAINER = CURRENT.

   GRANT DV_PATCH_ADMIN TO SYS CONTAINER = CURRENT;
   

3. In the root, connect as user SYS with the SYSOPER system privilege.

   For example:

   CONNECT SYS AS SYSOPER -- Or, CONNECT SYS@hrpdb AS SYSOPER
   Enter password: password
   

4. Restart the database in read-only mode.

   For example:

   SHUTDOWN IMMEDIATE
   STARTUP MOUNT
   ALTER DATABASE OPEN READ ONLY
   

5. Connect to the Database Vault-enabled database as a user who has the DV_OWNER role.

   For example:

   CONNECT sec_admin@dv_db
   

6. Grant the DV_PATCH_ADMIN role to user SYS on this database.

   GRANT DV_PATCH_ADMIN TO SYS;
   

7. Optionally, run the DBMS_PDB.CHECK_PLUG_COMPATIBILITY function to determine whether the unplugged PDB is compatible with the CDB.

   When you run the function, set the following parameters:

   • pdb_descr_file: Set this parameter to the full path to the XML file that will contain a description of the PDB.

   • store_report: Set this parameter to indicate whether you want to generate a report if the PDB is not compatible with the CDB. Set it to TRUE to generate a report or FALSE to not generate a report. A generated report is stored in the PDB_PLUG_IN_VIOLATIONS temporary table and is generated only if the PDB is not compatible with the CDB.

   For example, to determine whether a PDB described by the /disk1/usr/dv_db_pdb.xml file is compatible with the current CDB, run the following PL/SQL block:

   SET SERVEROUTPUT ON
   DECLARE
     compatible CONSTANT VARCHAR2(3) := 
       CASE DBMS_PDB.CHECK_PLUG_COMPATIBILITY(
              pdb_descr_file => '/disk1/usr/dv_db_pdb.xml',
              store_report   => TRUE)
       WHEN TRUE THEN 'YES'
       ELSE 'NO'
   END;
   BEGIN
     DBMS_OUTPUT.PUT_LINE(compatible);
   END;
   /
   

   If the output is YES, then the PDB is compatible, and you can continue with the next step.

   If the output is NO, then the PDB is not compatible. You can check the PDB_PLUG_IN_VIOLATIONS temporary table to see why it is not compatible.

8. Create an XML file that describes the PDB.

   For example:

   BEGIN
     DBMS_PDB.DESCRIBE(
       pdb_descr_file => '/disk1/oracle/dv_db.xml');
   END;
   /
   

9. Run the CREATE PLUGGABLE DATABASE statement, and specify the XML file in the USING clause. Specify other clauses when they are required.

   For example:

   CREATE PLUGGABLE DATABASE dv_db_pdb AS CLONE USING 'dv_db.xml' NOCOPY;
   

10. Connect to the PDB that you just created as user SYS with the SYSDBA administrative privilege.

    CONNECT SYS@dv_db_pdb AS SYSDBA
    

11. Execute the noncdb_to_pdb.sql script.

    @$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql
    

12. Open this PDB in a read/write restricted mode.

    ALTER PLUGGABLE DATABASE dv_db_pdb OPEN READ WRITE RESTRICTED;
    

13. Run the following procedure to synchronize the PDB:

    EXECUTE DBMS_PDB.SYNC_PDB;
    

14. Connect to the root as a user who has been granted the DV_OWNER role.

    sqlplus c##sec_admin
    Enter password: password
    

15. Revoke the DV_PATCH_ADMIN role from user SYS with CONTAINER = CURRENT.

    REVOKE DV_PATCH_ADMIN FROM SYS CONTAINER = CURRENT;
    

16. Connect to the legacy Database Vault-enabled database as user SYS with the SYSOPER system privilege.

    CONNECT SYS@dv_db_pdb AS SYSOPER
    

17. Restart this database.

    For example:

    SHUTDOWN IMMMEDIATE
    STARUP
    

18. Revoke the DV_PATCH_ADMIN role from user SYS.

    REVOKE DV_PATCH_ADMIN FROM SYS;