3 Getting Started with Oracle Database Vault

Before you can start using Oracle Database Vault, you must configure and enable it with the Oracle database.

3.1 About Configuring and Enabling Oracle Database Vault in Oracle Database

Oracle Database includes Database Vault when you choose to include a default database in the installation process, but you must configure and enable it before you can use it.

The configuration and enablement process enables Oracle Label Security if it is not already enabled. Oracle Label Security is required for Oracle Database Vault but it does not require a separate license unless you begin using Oracle Label Security separately and create Oracle Label Security policies.

If you create a custom database, then you can use DBCA to install and enable Database Vault for it. The registration process enables Oracle Label Security if it is not already enabled. This procedure applies to the CDB root, application root, and the current pluggable database (PDB), as well as to both single-instance and Oracle Real Application Clusters (Oracle RAC) installations. In a multitenant database, Database Vault must be configured with the CDB root before any of the PDBs can configure Database Vault.

As part of the configuration process, you created the Oracle Database Vault administrative accounts. The Oracle Database Vault configuration recommends four administrative database account names (two primary accounts and two backup accounts) with different passwords for each. These are accounts that hold the Database Vault roles DV_OWNER and DV_ACCTMGR, granted with the WITH ADMIN OPTION clause. Two of these accounts will be used to provision the roles to named users with administrative privileges. Maintaining two backup accounts, one with DV_OWNER and one with DV_ACCTMGR roles, will allow you to recover from the named user losing or somehow misplacing their credentials because SYS, or any other user, will not be able to reset these passwords for users with these roles.

Note:

If you upgraded from a release earlier than Oracle Database 12c, then you disabled Oracle Database Vault to perform the upgrade. After the upgrade process is complete, then you must configure and enable Oracle Database Vault again.

If you are migrating a non-Database Vault-enabled Oracle database from a release earlier than release 12c, then you must perform a manual installation of Database Vault.

3.2 Configuring and Enabling Oracle Database Vault

You can configure and enable Oracle Database Vault based on several scenarios.

3.2.1 About Configuring and Enabling Database Vault

You must configure and enable Oracle Database Vault in the CDB root before you can perform the same action in any of the associated PDBs.

The common users who have been assigned the DV_OWNER and DV_ACCTMGR roles in the CDB root can also have the same role in the PDBs. PDBs can have Database Vault configured and enabled using the same common users or use separate PDB local users. The DV_ACCTMGR role is granted commonly to the common user in the CDB root. You can grant DV_OWNER locally or commonly to the CDB root common user when you configure and enablement Database Vault with the CDB root. Granting DV_OWNER locally to the common user prevents the common DV_OWNER user from using this role in any PDB.

3.2.2 Configuring and Enabling Database Vault in the CDB Root

You can configure and enable Oracle Database Vault with common users who will use the Database Vault administrative roles from the CDB root.

Before you begin, Oracle recommends that you ensure that all database-related objects are valid. You can use the UTL_RECOMP PL/SQL package to check the validity of objects. See Oracle Database PL/SQL Packages and Types Reference.
  1. Log into the CDB root of the database instance as a user who has privileges to create users and grant the CREATE SESSION and SET CONTAINER privileges.
  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. If you do not have a backup for your account, then you cannot reset passwords. In addition, you must grant the DV_OWNER role, WITH ADMIN OPTION, to be able to reset the password of the primary account. Store these passwords in a safe location, such as a privileged account management (PAM) system, in case they are needed in the future.

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

    GRANT CREATE SESSION, SET CONTAINER TO c##dvowner 
      IDENTIFIED BY password CONTAINER = ALL;
    GRANT CREATE SESSION, SET CONTAINER TO c##dvowner_backup 
      IDENTIFIED BY password CONTAINER = ALL;
    GRANT CREATE SESSION, SET CONTAINER TO c##dvacctmgr 
      IDENTIFIED BY password CONTAINER = ALL;
    GRANT CREATE SESSION, SET CONTAINER TO c##dvacctmgr_backup 
      IDENTIFIED BY password CONTAINER = ALL;

    This specification grants two system privileges, creates the accounts if they do not exist, assigns a password, and does this so all the users have access to the CDB and all PDB databases.

    • Create the primary accounts (c##dvowner and c##dvacctmgr) if these do not already exist for the new roles, DV_ADMIN and DV_ACCTMGR.
    • Replace password with a password that meets the password complexity requirements of the user's profile.
  3. Connect to the CDB root as user SYS with the SYSDBA administrative privilege
  4. Configure the two backup Database Vault user accounts.
    For example:
    BEGIN
     CONFIGURE_DV (
       dvowner_uname         => 'c##dvowner_backup',
       dvacctmgr_uname       => 'c##dvacctmgr_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##dvowner_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 SYSOPER administrative privilege.
  9. Restart the database.
    For a single-instance database:
    SHUTDOWN IMMEDIATE
    STARTUP

    If you are in an Oracle Real Application Clusters (Oracle RAC) environment, then you can perform an Oracle RAC rolling enablement.

  10. Connect with the SYSDBA administrative privilege.
  11. Verify that Oracle Database Vault and Oracle Label Security are installed and enabled.
    SELECT * FROM CDB_DV_STATUS;
    SELECT * FROM CDB_OLS_STATUS;
  12. Connect as the backup DV_OWNER user and then grant the DV_OWNER role, including the WITH ADMIN OPTION clause, to the primary DV_OWNER user that you created earlier.

    For example:

    CONNECT c##dvowner_backup
    Enter password: password
    
    GRANT DV_OWNER TO c##dvowner WITH ADMIN OPTION CONTAINER = ALL;
  13. Connect as the backup DV_ACCTMGR user and then grant the DV_ACCTMGR role, including the WITH ADMIN OPTION clause, to the backup DV_ACCTMGR user.

    For example:

    CONNECT c##dvacctmgr_backup
    Enter password: password
    
    GRANT DV_ACCTMGR TO c##dvacctmgr WITH ADMIN OPTION CONTAINER=ALL;
  14. 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.

3.2.3 Configuring and Enabling Database Vault Common Users to Manage Specific PDBs

You must configure and enable Oracle Database Vault in the CDB root first, then in the PDBs afterward.

If you try to configure and enable in a PDB first, then an ORA-47503: Database Vault is not enabled on CDB$ROOT error appears.
  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 configured and enabled 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.
  4. If necessary, open the database.
    ALTER DATABASE OPEN;
  5. Grant the CREATE SESSION and SET CONTAINER privileges to the users for this PDB.
    For example:
    GRANT CREATE SESSION, SET CONTAINER TO c##dvowner CONTAINER = CURRENT;
    GRANT CREATE SESSION, SET CONTAINER TO c##dvacctmgr CONTAINER = CURRENT;
  6. Connect as user SYS with the SYSDBA administrative privilege
  7. While still in the PDB, configure the two backup Database Vault user accounts.
    BEGIN
     CONFIGURE_DV (
       dvowner_uname         => 'c##dvowner_backup',
       dvacctmgr_uname       => 'c##dvacctmgr_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.

  8. 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.

  9. Connect to the PDB as the backup Database Vault Owner user that you just configured.
    For example:
    CONNECT c##dvowner_backup@pdb_name
    Enter password: password
    
  10. Enable Oracle Database Vault in this PDB.
    EXEC DBMS_MACADM.ENABLE_DV;
  11. Connect to the CDB with the SYSDBA administrative privilege.
  12. Close and reopen the PDB.
    For example:
    ALTER PLUGGABLE DATABASE pdb_name CLOSE IMMEDIATE;
    ALTER PLUGGABLE DATABASE pdb_name OPEN;
    
  13. Verify that the PDB is configured and enabled for Database Vault and Oracle Label Security.
    CONNECT SYS@pdb_name AS SYSDBA
    Enter password: password
    
    SELECT * FROM DBA_DV_STATUS;
    SELECT * FROM DBA_OLS_STATUS;
  14. Connect as the backup DV_OWNER user and then grant the DV_OWNER role, including the WITH ADMIN OPTION clause, to the primary DV_OWNER user that you created earlier.

    For example:

    CONNECT c##dvowner_backup@pdb_name
    Enter password: password
    
    GRANT DV_OWNER TO c##dvowner WITH ADMIN OPTION;
    
  15. Connect as the backup DV_ACCTMGR user and then grant the DV_ACCTMGR role, including the WITH ADMIN OPTION clause, to the primary DV_ACCTMGR user.

    For example:

    CONNECT c##dvacctmgr_backup@pdb_name
    Enter password: password
    
    GRANT DV_ACCTMGR TO c##dvacctmgr WITH ADMIN OPTION;
  16. 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.

3.2.4 Configuring and Enabling Database Vault Local Users to Manage Specific PDBs

You must configure and enable Oracle Database Vault in the root first, and then in the PDBs afterward.

If you try to configure and enabale in a PDB first, then an ORA-47503: Database Vault is not enabled on CDB$ROOT error appears.
  1. Log in to the PDB as a user who has privileges to create users and to grant the CREATE SESSION and SET CONTAINER privileges.
  2. If necessary, open the database.
    ALTER DATABASE OPEN;
  3. If you are not using existing local user named accounts for the new Database Vault roles, create new named local user accounts.
    In both cases, you must create backup accounts to hold the Database Vault roles in case the named user loses or forgets their password.
    GRANT CREATE SESSION, SET CONTAINER TO dvowner 
      IDENTIFIED BY password;
    GRANT CREATE SESSION, SET CONTAINER TO dvowner_backup 
      IDENTIFIED BY password;
    GRANT CREATE SESSION, SET CONTAINER TO dvacctmgr 
      IDENTIFIED BY password;
    GRANT CREATE SESSION, SET CONTAINER TO dvacctmgr_backup 
      IDENTIFIED BY password;
    

    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. If you do not have a backup for your account, then you cannot reset passwords. In addition, you must grant the DV_OWNER role, WITH ADMIN OPTION, to be able to reset the password of the primary account. Store these passwords in a safe location, such as a privileged account management (PAM) system, in case they are needed in the future.

  4. Ensure that you have configured and enabled Oracle Database Vault in the CDB root.
    Temporarily connect to the root and then query the DBA_DV_STATUS view.
    CONNECT SYS / AS SYSDBA
    Enter password: password
    
    SELECT * FROM DBA_DV_STATUS;
    
  5. Connect to the PDB as user SYS with the SYSDBA administrative privilege.
  6. While still in the PDB, configure the two backup Database Vault user accounts.
    BEGIN
     CONFIGURE_DV (
       dvowner_uname     => 'dvowner_backup',
       dvacctmgr_uname   => 'dvacctmgr_backup');
     END;
    /
    

    In this example, the force_local_dvowner parameter is omitted because it is unnecessary. Database Vault roles are granted locally when configured in a 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, run it again.

  8. Connect to the PDB as the backup Database Vault Owner user that you just configured.
    For example:
    CONNECT dvowner_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.
    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 and Oracle Label Security.
    CONNECT SYS@pdb_name AS SYSDBA
    Enter password: password
    
    SELECT * FROM DBA_DV_STATUS;
    SELECT * FROM DBA_OLS_STATUS;
  13. Connect as the backup DV_OWNER user and then grant the DV_OWNER role, including the WITH ADMIN OPTION clause, to the primary DV_OWNER user that you created earlier.

    For example:

    CONNECT dvowner_backup@pdb_name
    Enter password: password
    
    GRANT DV_OWNER TO dvowner WITH ADMIN OPTION;
    
  14. Connect as the backup DV_ACCTMGR user and then grant the DV_ACCTMGR role, including the WITH ADMIN OPTION clause, to the backup DV_ACCTMGR user.

    For example:

    CONNECT dvacctmgr_backup@pdb_name
    Enter password: password
    
    GRANT DV_ACCTMGR TO dvacctmgr 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.

3.2.5 Configuring and Enabling Oracle Database Vault in an Oracle Real Application Clusters Environment

You can configure Oracle Database Vault for an Oracle Real Application Clusters (Oracle RAC) environment, including each Oracle RAC node.

To configure Oracle Database vault for an Oracle RAC environment, you must configure and enable Oracle Database Vault on one node, then restart each of the instance nodes to enable it everywhere. The following procedure assumes that you have a separate Oracle home for each node. If you are familiar with rolling patch installation on Oracle RAC, then you will perform similar steps to enable Oracle Database Vault on all Oracle RAC nodes.
  1. Configure and enable Oracle Database Vault in the CDB root.
  2. Log into the PDB as user SYS with the SYSDBA administrative privilege.
  3. If necessary, open the database.
    ALTER DATABASE OPEN;
  4. Run the following ALTER SYSTEM statements on either of the Oracle RAC nodes:
    ALTER SYSTEM SET OS_ROLES=FALSE SCOPE=SPFILE; 
    ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE='EXCLUSIVE' SCOPE=SPFILE;
    ALTER SYSTEM SET SQL92_SECURITY=TRUE SCOPE=SPFILE; 
  5. Close and then reopen the PDB.
    ALTER PLUGGABLE DATABASE pdb_name CLOSE IMMEDIATE;
    ALTER PLUGGABLE DATABASE pdb_name OPEN;

3.2.6 Creating a Profile to Protect the DV_OWNER and DV_ACCTMGR Users

A profile provides additional protection for users who have been granted the DV_OWNER and DV_ACCTMGR roles.

Database users who have been granted the DV_OWNER or DV_ACCTMGR roles are considered critical, privileged, accounts. Typically, these accounts should be considered service accounts and exempt from password lockout requirements. Oracle recommends that you create a custom profile that prevents the account from being locked. In addition, you should audit failed login attempts for these Database Vault-related accounts.
  1. Log into the database instance as a user who has the CREATE PROFILE system privilege.
    • For common DV_OWNER and DV_ACCTMGR users: Log in to the root of the database instance.
    • For local DV_OWNER and DV_ACCTMGR users: Log in to the PDB in which you created the users.
  2. Create a profile similar to the following:
    • For common DV_OWNER and DV_ACCTMGR users: In the root, create the profile similar to the following:
      CREATE PROFILE c##dv_profile limit
      FAILED_LOGIN_ATTEMPTS UNLIMITED
      PASSWORD_VERIFY_FUNCTION ORA12C_VERIFY_FUNCTION
      PASSWORD_LOCK_TIME UNLIMITED
      CONTAINER=ALL;
    • For local DV_OWNER and DV_ACCTMGR users: In the PDB, create the profile similar to the following:
      CREATE PROFILE dv_profile limit
      FAILED_LOGIN_ATTEMPTS UNLIMITED
      PASSWORD_VERIFY_FUNCTION ORA12C_VERIFY_FUNCTION
      PASSWORD_LOCK_TIME UNLIMITED
      CONTAINER=CURRENT;
  3. Update the DV_OWNER and DV_ACCTMGR user accounts to use this profile.
    • For common DV_OWNER and DV_ACCTMGR users:
      ALTER USER c##dvowner PROFILE c##dv_profile CONTAINER = ALL;
      ALTER USER c##dvowner_backup PROFILE c##dv_profile CONTAINER = ALL;
      ALTER USER c##dvacctmgr PROFILE c##dv_profile CONTAINER = ALL;
      ALTER USER c##dvacctmgr_backup PROFILE c##dv_profile CONTAINER = ALL;
    • For local DV_OWNER and DV_ACCTMGR users:
      ALTER USER dvowner PROFILE dv_profile CONTAINER = CURRENT;
      ALTER USER dvowner_backup PROFILE dv_profile CONTAINER = CURRENT;
      ALTER USER dvacctmgr PROFILE dv_profile CONTAINER = CURRENT;
      ALTER USER dvacctmgr_backup PROFILE dv_profile CONTAINER = CURRENT;
  4. Connect as a user who has been granted the AUDIT_ADMIN role.
  5. Create and enable a unified audit policy to track failed logins by any user who has been granted the DV_OWNER or DV_ACCTMGR role.
    • For common DV_OWNER and DV_ACCTMGR users: In the root, create a policy similar to the following:
      CREATE AUDIT POLICY c##dv_logins ACTIONS LOGON;
      AUDIT POLICY c##dv_logins BY USERS WITH GRANTED ROLES DV_OWNER, DV_ACCTMGR 
      WHENEVER NOT SUCCESSFUL;
    • For local DV_OWNER and DV_ACCTMGR users: In the PDB, create a policy similar to the following:
      CREATE AUDIT POLICY dv_logins ACTIONS LOGON;
      AUDIT POLICY dv_logins BY USERS WITH GRANTED ROLES DV_OWNER, DV_ACCTMGR 
      WHENEVER NOT SUCCESSFUL;

3.2.7 Manually Installing Oracle Database Vault

Under certain conditions, you must manually install Oracle Database Vault.

For example, you may have to manually install Oracle Database Vault if a release 19c Oracle database without Database Vault is upgraded to release 23ai, then converted to a PDB to be plugged into a 23ai Database Vault-enabled database. In addition,you must manually install Oracle Database Vault (and Oracle Label Security) in a PDB if this PDB does not have these products when the PDB has been plugged into a CDB where Database Vault and Label Security are installed.
  1. As user who has been granted the SYSDBA administrative privilege, log in to the PDB in which you want to install Oracle Database Vault.

    Alternatively, log in to the CDB root as a user with DV_OWNER or DV_ADMIN role, and then check that all of the PDBs are open and if Oracle Database Vault is in all of the associated PDBs. You can check if the PDB is open by connecting to it and then querying the OPEN_MODE column from the V$DATABASE view. To find if there is an Oracle Database Vault installation on the CDB, as a user with the SYSDBA administrative privielge, run this query:

    SELECT * FROM DBA_DV_STATUS;
    
  2. If necessary, check if Oracle Database Vault and Oracle Label Security are already installed on this PDB.
    If the DVSYS and DVF accounts (for Database Vault) and the LBACSYS account (for Label Security) exist, then Database Vault and Label Security exist on the PDB.
    SELECT USERNAME FROM DBA_USERS WHERE USERNAME IN ('DVSYS', 'DVF', 'LBACSYS');

    If properly installed, the result of this should show the major database version and a status of VALID for both Oracle Label Security and Oracle Database Vault:

    SELECT COMP_NAME, VERSION, STATUS FROM DBA_REGISTRY WHERE COMP_ID IN ('DV','OLS');
  3. If neither Database Vault nor Label Security have been installed, then install Oracle Label Security by executing the catols.sql script.
    @$ORACLE_HOME/rdbms/admin/catols.sql

    Oracle Label Security must be installed before you can install Oracle Database Vault.

  4. Install Oracle Database Vault by executing the catmac.sql script.
    @$ORACLE_HOME/rdbms/admin/catmac.sql
  5. At the Enter value for 1 prompt, enter SYSTEM as the tablespace to install DVSYS.
  6. At the Enter value for 2 prompt, enter the temporary tablespace for the PDB.
After the installation is complete, you can configure and enable Oracle Database Vault in the PDB. After Database Vault is configured and enabled in the CDB root and the database has been restarted, then you can configure and enable Database Vault in the PDB. Database Vault must be configured and enabled in CDB root before it can be configured and enabled in the PDB. After Database Vault is configured and enabled in the CDB root and the database has been restarted, then you can open the PDB and configure and enable Database Vault.

3.3 Verifying That Database Vault Is Configured and Enabled

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

In addition to Oracle Database Vault administrators, the Oracle Database SYS user and users who have been granted the DBA role can query these views.
  • For Database Vault:

    • If you want to find the Database Vault status for the root only or an individual PDB, then query DBA_DV_STATUS. For example:

      SELECT * FROM DBA_DV_STATUS;

      Output similar to the following appears:

      NAME                 STATUS
      -------------------- -----------
      DV_APP_PROTECTION    NOT CONFIGURED
      DV_CONFIGURE_STATUS  TRUE
      DV_ENABLE_STATUS     TRUE

      DV_APP_PROTECTION refers to operations control, which automatically restricts common users from accessing PDB local data in Oracle Database multitenant environments.

    • If you want to find the Database Vault status of all PDBs in the multitenant environment, then as a common user with administrative privileges, query CDB_DV_STATUS, which provides the addition of a container ID (CON_ID) field.

  • For Oracle Label Security, query the DBA_OLS_STATUS data dictionary view.

3.4 Logging in to Oracle Database Vault from Oracle Enterprise Cloud Control

Oracle Enterprise Manager Cloud Control (Cloud Control) provides pages for managing Oracle Database Vault.

Only Oracle Enterprise Manager Cloud Control is supported, not Oracle EM Express. The Oracle Database Vault pages can be used to administer and monitor Database Vault-protected databases from a centralized console. This console enables you to automate alerts, view Database Vault reports, and propagate Database Vault policies to other Database Vault-protected databases.
Before you try to log in, ensure that you have configured the Cloud Control target databases that you plan to use with Database Vault by following the Oracle Enterprise Manager online help. Oracle Database Vault must also be configured and enabled with the Oracle database.
  1. Log in to Oracle Enterprise Manager Cloud Control with the credentials that were provided by your Cloud Control administrator.
  2. In the Cloud Control home page, from the Targets menu, select Databases.
  3. In the Databases page, select the link for the Oracle Database Vault-protected database to which you want to connect.

    The Database home page appears.

  4. From the Security menu, select Database Vault.

    The Database Login page appears.

  5. Enter the following information:
    • Username: Enter the name of a user who has been granted the appropriate Oracle Database Vault role:

      • Creating and propagating Database Vault policies: DV_OWNER or DV_ADMIN role, SELECT ANY DICTIONARY privilege

      • Viewing Database Vault alerts and reports: DV_OWNER, DV_ADMIN, or DV_SECANALYST role, SELECT ANY DICTIONARY privilege

    • Password: Enter your password.

    • Role: Select NORMAL from the list.

    • Save as: Select this check box if you want these credentials to be automatically filled in for you the next time that this page appears. The credentials are stored in Enterprise Manager in a secure manner. Access to these credentials depends on the user who is currently logged in.

    The Database Vault home page appears.


    Description of em_dv_home_page.png follows
    Description of the illustration em_dv_home_page.png

3.5 Quick Start Tutorial: Securing a Schema from DBA Access

This tutorial shows how to create a realm around the HR schema.

3.5.1 About This Tutorial

In this tutorial, you create a realm around the EMPLOYEES table in the HR sample database schema by using the Oracle Database Vault PL/SQL packages.

You will also learn how to create a unified audit policy to record realm violations and review them.

In the HR schema, the EMPLOYEES table has information such as salaries that should be hidden from most employees in the company, including those with administrative access. To accomplish this, you add the HR schema to the secured objects of the protection zone, which in Oracle Database Vault is called a realm, inside the database. Then you grant limited authorizations to this realm. Afterward, you test the realm to make sure it has been properly secured.

3.5.2 Step 1: Log On as SYSTEM to Access the HR Schema

You must enable the HR schema for this tutorial.

Before you begin this tutorial, ensure that the HR sample schema is installed.
  1. Log in to a PDB as a user who has been granted the DBA role, and then access the HR schema.
  2. Query the HR.EMPLOYEES table as follows.
    SELECT FIRST_NAME, LAST_NAME, SALARY FROM HR.EMPLOYEES WHERE ROWNUM < 10;
    

    Output similar to the following appears:

    FIRST_NAME           LAST_NAME                     SALARY
    -------------------- ------------------------- ----------
    Steven               King                           24000
    Neena                Kochhar                        17000
    Lex                  De Haan                        17000
    Alexander            Hunold                          9000
    Bruce                Ernst                           6000
    David                Austin                          4800
    Valli                Pataballa                       4800
    Diana                Lorentz                         4200
    Nancy                Greenberg                      12008
    
    9 rows selected.
    
  3. If the HR schema is locked and expired, log in to the database instance as the DV_ACCTMGR user and unlock and unexpire the account. For example:
    ALTER USER HR ACCOUNT UNLOCK IDENTIFIED BY password

    Replace password with a password that meets the password complexity requirements of the user's profile.

    A user with the DBA role has access to the salary information in the EMPLOYEES table of the HR schema. Logging in as SYSTEM works because SYSTEM has the DBA role, which has the SELECT ANY TABLE system privilege.

  4. Do not exit SQL*Plus.

3.5.3 Step 2: Create a Realm

Realms can protect one or more schemas, individual schema objects, and database roles.

After you create a realm, you can create security restrictions that apply to the schemas and their schema objects within the realm. You will need to create a realm for the EMPLOYEES table in the HR schema.
  1. Connect to a PDB as a user who has been granted the DV_OWNER role.
  2. Create the HR Apps realm around the HR.EMPLOYEES table.
    1. Create the HR Apps realm itself.
      BEGIN
       DBMS_MACADM.CREATE_REALM(
        realm_name    => 'HR Apps', 
        description   => 'Realm to protect the HR schema', 
        enabled       => DBMS_MACUTL.G_YES, 
        audit_options => DBMS_MACUTL.G_REALM_AUDIT_OFF,
        realm_type    => DBMS_MACADM.REGULAR_REALM);
      END; 
      /
    2. Add the HR.EMPLOYEES table to this realm.
      BEGIN
       DBMS_MACADM.ADD_OBJECT_TO_REALM(
        realm_name   => 'HR Apps', 
        object_owner => 'HR', 
        object_name  => 'EMPLOYEES', 
        object_type  => 'TABLE'); 
      END;
      /

At this stage, you have created the realm but you have not assigned any authorizations to it. Because this is a traditional realm (realm_type => DBMS_MACADM.REGULAR_REALM), any user with direct grants to READ or SELECT from HR.EMPLOYEES will still be able to view this table, but users who rely on system privileges, such as READ ANY TABLE or SELECT ANY TABLE, will not. You will take care of that later on in this tutorial.

3.5.4 Step 3: Create a Unified Audit Policy for Realm Violations

You can create unified audit policies for Oracle Database Vault realms, rule sets, and factors.

Unified Audit policies can be designed to create audit records whenever access to realms, rule sets, or factors are not successful, when access is successful, or when access is either successful or not successful. See Oracle Database Security Guide for more information about creating unified audit policies for Oracle Database Vault.

After you create a realm, you can create unified audit policies to capture violations of the realm.

  1. Connect to a PDB as a user who has been granted the DBA role, AUDIT SYSTEM system privilege, or AUDIT_ADMIN role.
    It may be easier to create a user with this privilege for the tutorial.
    1. As a user with the DV_ACCTMGR role, create a temporary user to act as audit administrator.
      GRANT CREATE SESSION TO cmack IDENTIFIED BY password;
    2. As a user with the SYSDBA administrative privilege, grant this new user the AUDIT_ADMIN role.
      GRANT AUDIT_ADMIN TO cmack;
    3. As a user with the DV_OWNER role, grant the new user authorization to use their AUDIT_ADMIN role.
      EXEC DBMS_MACADM.AUTHORIZE_AUDIT_ADMIN('CMACK');
  2. As the AUDIT_ADMIN user, cmack, create a unified audit policy to audit all actions that are violations of the HR Apps realm.
    1. Create the unified audit policy.
      CREATE AUDIT POLICY aud_hrapps_dv
      ACTIONS COMPONENT=DV REALM VIOLATION ON "HR Apps";
    2. Enable the unified audit policy.
      AUDIT POLICY aud_hrapps_dv;
At this stage, you have created the unified audit policy but you have not committed any realm violations yet. You will take care of that later in this tutorial.

3.5.5 Step 4: Create the SEBASTIAN User Account

At this stage, only the HR schema and database users, or roles, with direct object grants can manipulate the database objects the realm will protect. Users relying on system privileges cannot.

So, the next step is to authorize database accounts or database roles so that they have access to the schemas or objects protected by the realm. In this tutorial, the only object we have protected is the HR.EMPLOYEES table. User cmack has been granted the AUDIT_ADMIN role, and through the DBMS_MACADM.AUTHORIZE_AUDIT_ADMIN authorization that you performed earlier, authorized to use the AUDIT_ADMIN role to manage unified audit policies and view unified audit records. You will create the sebastian user account.
  1. In SQL*Plus, connect to the PDB as the Database Vault Account Manager, who has the DV_ACCTMGR role, and create the local user sebastian.

    For example:

    GRANT CREATE SESSION TO sebastian IDENTIFIED BY password;

    Replace password with a password that meets the password complexity requirements of the user's profile.

  2. Connect as SYS with the SYSDBA privilege, and then grant SEBASTIAN the following additional privilege.
    GRANT READ ANY TABLE TO sebastian;
  3. Do not exit SQL*Plus.

3.5.6 Step 5: Have User SEBASTIAN Test the Realm

At this stage, user sebastian can test the realm by trying to query the HR.EMPLOYEES table.

  1. Connect as user sebastian.
  2. Query the HR.EMPLOYEES table.
    SELECT COUNT(*) FROM HR.EMPLOYEES;

    The following output should appear:

    ERROR at line 1:
    ORA-01031: insufficient privileges
Even though user sebastian has the READ ANY TABLE system privilege, he cannot query the HR.EMPLOYEES table, because the HR Apps realm takes precedence over the READ ANY TABLE system privilege.

3.5.7 Step 6: Create an Authorization for the Realm

Next, user SEBASTIAN must be granted authorization to the HR Apps realm, so that they can access the HR.EMPLOYEES table.

  1. Connect to the PDB as a user who has been granted the DV_OWNER role.
  2. Create an authorization for the HR Apps realm.

    This authorization allows SEBASTIAN to use the READ ANY TABLE system privilege on the HR.EMPLOYEES table that is protected by this realm.

    BEGIN
     DBMS_MACADM.ADD_AUTH_TO_REALM(
      realm_name  => 'HR Apps', 
      grantee     => 'SEBASTIAN'); 
    END;
    /

3.5.8 Step 7: Test the Realm

To test the realm, you must try to access the EMPLOYEES table as a user other than HR.

(This tutorial does not cover the ability to prevent HR from accessing its own objects.)

The SYSTEM account normally has access to all objects in the HR schema because it has the SELECT ANY TABLE privilege, but now that you have safeguarded the EMPLOYEES table with Oracle Database Vault, this is no longer the case.

  1. In SQL*Plus, connect to the PDB as SYSTEM.
  2. Try querying any of the rows in the EMPLOYEES table again.
    For example:
    SELECT FIRST_NAME, LAST_NAME, SALARY FROM HR.EMPLOYEES WHERE ROWNUM <10;
    

    The following output should appear:

    Error at line 1:
    ORA-01031: insufficient privileges
    

    SYSTEM no longer has access to the EMPLOYEES table. (In fact, even user SYS does not have any access to this table.) However, user SEBASTIAN does have access to this information because sebastian is an authorized participant in the HR Apps realm.

  3. Connect as user sebastian.
    Perform the following query:
    SELECT FIRST_NAME, LAST_NAME, SALARY FROM HR.EMPLOYEES WHERE ROWNUM <10;

    Output similar to the following appears:

    FIRST_NAME           LAST_NAME                     SALARY
    -------------------- ------------------------- ----------
    Steven               King                           24000
    Neena                Kochhar                        17000
    Lex                  De Haan                        17000
    Alexander            Hunold                          9000
    Bruce                Ernst                           6000
    David                Austin                          4800
    Valli                Pataballa                       4800
    Diana                Lorentz                         4200
    Nancy                Greenberg                      12008
    
    9 rows selected.

3.5.9 Step 8: View Audit Records from Realm Violations

You should conduct a periodic review of violations on the unified audit policies that you have created.

You should create these unified audit policies to track violations to realms, rule sets, and factors. Ideally, you would incorporate this information with a security solution, such as Oracle Data Safe, and send notifications out immediately for all violations.
  1. Connect to the PDB as the user cmack.
    At minimum, a user must have the AUDIT_VIEWER role to view unified audit policy records. User cmack has been granted the AUDIT_ADMIN role, and through the DBMS_MACADM.AUTHORIZE_AUDIT_ADMIN authorization that you performed earlier, authorized to use the AUDIT_ADMIN role to manage unified audit policies and view unified audit records.
  2. As user cmack, query the UNIFIED_AUDIT_TRAIL view, which stores the unified audit records.
    column dbusername format a20
    column action_name format a20
    column object_name format a20
    column object_schema format a20
    column dv_action_object_name format a25
    
    SELECT DBUSERNAME, ACTION_NAME, OBJECT_SCHEMA, OBJECT_NAME, DV_ACTION_OBJECT_NAME, DV_RETURN_CODE 
    FROM UNIFIED_AUDIT_TRAIL
    WHERE AUDIT_TYPE = 'Database Vault'
    AND DV_ACTION_NAME = 'Realm Violation Audit'
    ORDER BY EVENT_TIMESTAMP;

    Output similar to the following appears:

    DBUSERNAME           ACTION_NAME          OBJECT_SCHEMA        OBJECT_NAME          DV_ACTION_OBJECT_NAME     DV_RETURN_CODE
    -------------------- -------------------- -------------------- -------------------- ------------------------- --------------
    SEBASTIAN            SELECT               HR                   EMPLOYEES            HR Apps                             1031
    SYSTEM               SELECT               HR                   EMPLOYEES            HR Apps                             1031

3.5.10 Step 9: Remove the Components for This Tutorial

You can remove the components that you created for this tutorial if you no longer need them.

  1. As the user cmack, disable and drop the aud_hrapps_dv unified audit policy.
    NOAUDIT POLICY aud_hrapps_dv;
    DROP AUDIT POLICY aud_hrapps_dv;
  2. As a user who has the DV_ACCTMGR role, drop users cmack and sebastian.
    DROP USER cmack;
    DROP USER sebastian;
  3. Delete the HR Apps realm.
    1. Connect to the PDB as a user who has been granted the DV_OWNER role.
    2. Run the following statement to drop the HR Apps realm and its authorizations:
      EXEC DBMS_MACADM.DELETE_REALM_CASCADE('HR Apps');
  4. If necessary, lock and expire the HR account.
    1. Connect as a user who has the DV_ACCTMGR role (for example, user dvacctmgr).
    2. Run the following ALTER USER statement:
      ALTER USER HR ACCOUNT LOCK PASSWORD EXPIRE;