11 Integrating Oracle Database Vault with Other Oracle Products

You can integrate Oracle Database Vault with other Oracle products, such as Oracle Enterprise User Security.

11.1 Integrating Oracle Database Vault with Enterprise User Security

You can integrate Oracle Database Vault with Oracle Enterprise User Security.

11.1.1 About Integrating Oracle Database Vault with Enterprise User Security

Enterprise User Security centrally manages database users and authorizations in one place.

It is combined with Oracle Identity Management and is available in Oracle Database Enterprise Edition.

In general, to integrate Oracle Database Vault with Oracle Enterprise User Security, you configure the appropriate realms to protect the data that you want to protect in the database.

After you define the Oracle Database Vault realms as needed, you can create a rule set for the Enterprise users to allow or disallow their access.

11.1.2 Configuring an Enterprise User Authorization

To configure an Enterprise User authorization, you must create an Oracle Database Vault rule set to control the user access.

  1. Connect to the PDB or the application root as a user who has been granted the DV_OWNER or DV_ADMIN role.
  2. Run the DBMS_MACADM.CREATE_RULE procedure to create the rule that allows or disallows user access.
    BEGIN
     DBMS_MACADM.CREATE_RULE(
      rule_name => 'Control User Access',
      rule_expr =>'SYS_CONTEXT(''USERENV'',''AUTHENTICATED_IDENTITY'') = ''USER_DOMAIN_NAME''',
      scope => DBMS_MACUTL.G_SCOPE_LOCAL);
    END;
    /
    

    In this specification:

    • rule_name specifies a rule name. Enter any valid name that is appropriate for your needs.
    • rule_expr must use the rule expression given in this example. Replace 'user_domain_name' with the domain. For example:
      'SYS_CONTEXT(''USERENV'',''AUTHENTICATED_IDENTITY'') = ''myserver.us.example.com'''
    • scope must be DBMS_MACUTL.G_SCOPE_LOCAL.
  3. Run the DBMS_MACADM.CREATE_RULE_SET procedure to create a rule set to be used for the rule.
    For example:
    BEGIN
     DBMS_MACADM.CREATE_RULE_SET(
      rule_set_name => 'EM User Authorization',
      description => 'Allows or disallows user access to EM',
      enabled => DBMS_MACUTL.G_YES,
      eval_options => DBMS_MACUTL.G_RULESET_EVAL_ANY,
      audit_options => DBMS_MACUTL.G_RULESET_AUDIT_OFF,
      fail_options => DBMS_MACUTL.G_RULESET_FAIL_SILENT,
      fail_message => null,
      fail_code => null,
      handler_options => DBMS_MACUTL.G_RULESET_HANDLER_OFF,
      handler => ' ',
      is_static => TRUE);
    END;
    /
  4. Run the DBMS_MACADM.ADD_RULE_TO_RULE_SET procedure to add the rule to the rule set.
    For example:
    BEGIN
     DBMS_MACADM.ADD_RULE_TO_RULE_SET(
      rule_set_name => 'EM User Authorization', 
      rule_name     => 'Control User Access',
      rule_order    => 1);
    END;
    /
  5. Run the DBMS_MACADM.ADD_AUTH_TO_REALM procedure to add the rule set to the realm authorization for the data that you want to protect.
    For example, for a realm called HR Realm:
    BEGIN
     DBMS_MACADM.ADD_AUTH_TO_REALM(
      realm_name    => 'HR Realm', 
      grantee       => 'PFITCH', 
      rule_set_name => 'EM User Authorization',
      auth_options  => DBMS_MACUTL.G_REALM_AUTH_OWNER,
      auth_scope    => DBMS_MACUTL.G_SCOPE_LOCAL);
    END;
    /

11.1.3 Configuring Oracle Database Vault Accounts as Enterprise User Accounts

You can configure existing Oracle Database Vault user accounts as enterprise user accounts in a PDB.

  1. Log in to the PDB as a user who has been granted the CREATE ROLE system privilege.

    For example:

    sqlplus sec_admin@pdb_name
    Enter password: password
    

    To find the available PDBs, query the PDB_NAME column of the DBA_PDBS data dictionary view. To check the current container, run the show con_name command.

  2. Create a global role for the DV_OWNER role and a global role for the DV_ACCTMGR role.

    For example:

    CREATE ROLE g_dv_owner IDENTIFIED GLOBALLY;
    CREATE ROLE g_dv_acctmgr IDENTIFIED GLOBALLY;
    
  3. Connect as a user who has been granted the DV_OWNER role.

    For example:

    CONNECT sec_admin_owen@pdb_name
    Enter password: password
    
  4. Grant the DV_OWNER role to the global DV_OWNER role.
    GRANT DV_OWNER TO g_dv_owner;
    
  5. Connect as a user who has been granted the DV_ACCTMGR role.

    For example:

    CONNECT dbv_acctmgr@pdb_name
    Enter password: password
    
  6. Grant the DV_ACCTMGR role to the global DV_ACCTMGR role.
    GRANT DV_ACCTMGR TO g_dv_acctmgr;
    
  7. Connect as user SYS with the SYSDBA administrative privilege.
    CONNECT SYS@pdb_name AS SYSDBA 
    Enter password: password
    
  8. Temporarily grant the DV_ACCTMGR user who will import the Database Vault users into OID the CREATE TABLE privilege and the SELECT_CATALOG_ROLE role.
    GRANT CREATE TABLE, SELECT_CATALOG_ROLE TO dbv_acctmgr;
    
  9. From the command line, run the User Migration Utility (UMU) to import the Database Vault accounts into Oracle Internet Directory (OID).

    The following example imports the Database Vault accounts sec_admin_owen and accts_admin_ace into OID. The DV_ACCTMGR user is specified for the DBADMIN setting.

    $ORACLE_HOME/rdbms/bin/umu PHASE=ONE
    DBADMIN=dbv_acctmgr:password
    ENTADMIN=cn=jane_ent_admin,dc=example,dc=com:password
    USERS= LIST
    DBLOCATION=example.com:7777:orcl
    DIRLOCATION=example.com:636
    USERSLIST=sec_admin_owen:accts_admin_ace
    MAPSCHEMA=PRIVATE
    CONTEXT=CONTEXT="c=Users, c=us"
    KREALM=EXAMPLE.COM
    
    $ORACLE_HOME/rdbms/bin/umu PHASE=TWO
    DBADMIN=dbv_acctmgr:password
    ENTADMIN=cn=jane_ent_admin,dc=example,dc=com:password
    DBLOCATION=example.com:7777:orcl
    DIRLOCATION=example.com:636
    

    By default, errors are written to the $ORACLE_HOME/network/log/umu.log file.

    Enterprise User Security (EUS) User Migration Utility (UMU) is deprecated in Oracle Database 21c. Use EUS Manager (EUSM) features instead.
  10. From the Oracle Internet Directory Self Service Console (http://hostname:port/oiddas/), grant the global DV_OWNER and DV_ACCTMGR roles (for example, g_dv_owner and g_dv_acctmgr) to the enterprise user Database Vault accounts.

    See the example of creating enterprise users in Oracle Database Enterprise User Security Administrator's Guide for a demonstration of creating an enterprise role from a global role and then granting this role to a user.

  11. From SQL*Plus, as user SYS with the SYSDBA administrative privilege, revoke the CREATE TABLE and SELECT_CATALOG_ROLE role from the DV_ACCTMGR user.
    REVOKE CREATE TABLE, SELECT_CATALOG_ROLE FROM dbv_acctmgr;

11.2 Integrating Oracle Database Vault with Transparent Data Encryption

Transparent Data Encryption complements Oracle Database Vault in that it provides data protection when the data leaves the secure perimeter of the database.

With Transparent Data Encryption, a database administrator or database security administrator can simply encrypt columns with sensitive content in application tables, or encrypt entire application tablespaces, without any modification to the application.

If a user passes the authentication and authorization checks, Transparent Data Encryption automatically encrypts and decrypts information for the user. This way, you can implement encryption without having to change your applications.

Once you have granted the Transparent Data Encryption user the appropriate privileges, then Transparent Data Encryption can be managed as usual and be used complimentary to Database Vault.

Figure 11-1 shows how Oracle Database Vault realms handle encrypted data.

Figure 11-1 Encrypted Data and Oracle Database Vault

Description of Figure 11-1 follows
Description of "Figure 11-1 Encrypted Data and Oracle Database Vault"

11.3 Attaching Factors to an Oracle Virtual Private Database

You can attach factors to an Oracle Virtual Private Database.

  1. Define a Virtual Private Database policy predicate that is a PL/SQL function or expression.
  2. For each function or expression, use the DVF.F$ PL/SQL function that is created for each factor.

11.4 Integrating Oracle Database Vault with Oracle Label Security

You can integrate Oracle Database Vault with Oracle Label Security, and check the integration with reports and data dictionary views.

11.4.1 How Oracle Database Vault Is Integrated with Oracle Label Security

An Oracle Database Vault-Oracle Label Security integration enables you to assign an OLS label to a Database Vault factor identity.

In Oracle Label Security, you can restrict access to rows in database tables or PL/SQL programs. For example, Mary may be able to see data protected by the HIGHLY SENSITIVE label, an Oracle Label Security label on the EMPLOYEE table that includes records that should have access limited to certain managers. Another label can be PUBLIC, which allows more open access to this data.

In Oracle Database Vault, you can create a factor called Network, for the network on which the database session originates, with the following identities:

  • Intranet: Used for when an employee is working on site within the intranet for your company.

  • Remote: Used for when the employee is working at home from a VPN connection.

You then assign a maximum session label to both. For example:

  • Assign the Intranet identity to the HIGHLY SENSITIVE Oracle Label Security label.

  • Assign the Remote identity to the PUBLIC label.

This means that when Mary is working at home using their VPN connection, she have access only to the limited table data protected under the PUBLIC identity. But when she is in the office, she has access to the HIGHLY SENSITIVE data, because she is using the Intranet identity.

In a traditional auditing environment, you can audit the integration with Oracle Label Security by using the Label Security Integration Audit Report. Oracle Database Vault writes the audit trail to the DVSYS.AUDIT_TRAIL$ table. If unified auditing is enabled, then you can create audit policies to capture this information. Be aware that as of Oracle Database release 21c, traditional auditing is deprecated.

11.4.2 Requirements for Using Oracle Database Vault with Oracle Label Security

You must fulfill specific requirements in place before you use Oracle Database Vault with Oracle Label Security.

  • Oracle Label Security is licensed separately. Ensure that you have purchased a license to use it.

  • Before you install Oracle Database Vault, you must have already installed Oracle Label Security.

  • The installation process for Oracle Label Security creates the LBACSYS user account. As a user who has been granted the DV_ACCTMGR role, unlock this account and grant it a new password. For example:

    sqlplus accts_admin_ace@pdb_name
    Enter password: password
    
    ALTER USER LBACSYS ACCOUNT UNLOCK IDENTIFIED BY password;
  • If you plan to use the LBACSYS user account in Oracle Enterprise Manager, then log in to Enterprise Manager as user SYS with the SYSDBA administrative privilege, and grant this user the SELECT ANY DICTIONARY and SELECT_CATALOG_ROLE system privileges.

  • Ensure that you have the appropriate Oracle Label Security policies defined.

  • If you plan to integrate an Oracle Label Security policy with a Database Vault policy, then ensure that the policy name for Oracle Label Security is less than 24 characters. You can check the names of Oracle Label Security policies by querying the POLICY_NAME column of the ALL_SA_POLICIES data dictionary view.

11.4.3 Using Oracle Database Vault Factors with Oracle Label Security Policies

To enhance security, you can integrate Oracle Database Vault factors with Oracle Label Security policies.

11.4.3.1 About Using Oracle Database Vault Factors with Oracle Label Security Policies

And Oracle Database Vault-Oracle Label Security integration enables you to control the maximum security clearance for a database session.

Oracle Database Vault controls the maximum security clearance for a database session by merging the maximum allowable data for each label in a database session by merging the labels of Oracle Database Vault factors that are associated to an Oracle Label Security policy.

In brief, a label acts as an identifier for the access privileges of a database table row. A policy is a name associated with the labels, rules, and authorizations that govern access to table rows.

11.4.3.2 Configuring Factors to Work with an Oracle Label Security Policy

You can define factors that contribute to the maximum allowable data label of an Oracle Label Security policy.

  1. Connect to the PDB or the application root as a user who has been granted the DV_OWNER or DV_ADMIN role.
  2. Make the user LBACSYS account an owner of the realm that contains the schema to which a label security policy has been applied.

    This enables the LBACSYS account to have access to all the protected data in the realm, so that it can properly classify the data.

    For example, to make LBACSYS the owner of a realm called HR Realm:
    BEGIN
     DBMS_MACADM.ADD_AUTH_TO_REALM(
      realm_name   => 'HR Realm', 
      grantee      => 'LBACSYS', 
      auth_options => DBMS_MACUTL.G_REALM_AUTH_OWNER);
    END;
    /
  3. Authorize the schema owner (on which the label security policy has been applied) as either a realm participant or a realm owner.
    For example:
    BEGIN
     DBMS_MACADM.ADD_AUTH_TO_REALM(
      realm_name   => 'HR Realm', 
      grantee      => 'HR', 
      auth_options => DBMS_MACUTL.G_REALM_AUTH_OWNER);
    END;
    /
  4. Configure a label security policy for the realm.
    Optionally set the label-merging algorithm for cases when Oracle Label Security has merged two labels. In most cases, you may want to configure the label security policy to use LII (Minimum Level/Intersection/Intersection). This setting is the most commonly used method that Oracle Label Security administrators use when they want to merge two labels. This setting provides optimum flexibility when your applications must determine the resulting label that is required when combining two data sets that have different labels. It is also necessary for situations in which you must perform queries using joins on rows with different data labels.
    • To create a new label security policy, run the DBMS_MACADM.CREATE_MAC_POLICY procedure. For example:
      BEGIN
       DBMS_MACADM.CREATE_MAC_POLICY(
        policy_name  => 'Access Locations',
        algorithm    => 'LII');
      END;
      /
    • To modify an existing label security policy, run the DBMS_MACADM.UPDATE_MAC_POLICY procedure.
  5. Run the DBMS_MACADM.ADD_POLICY_FACTOR factor to associate a factor with the label security policy.
    For example:
    BEGIN
     DBMS_MACADM.ADD_POLICY_FACTOR(
      policy_name  => 'Access Locations', 
      factor_name  => 'Sector2_DB'); 
    END;
    /
  6. Run the DBMS_MACADM.CREATE_IDENTITY procedure to create a factor identity.
    For example:
    BEGIN
     DBMS_MACADM.CREATE_IDENTITY(
      factor_name  => 'Sector2_DB', 
      value        => 'intranet', 
      trust_level  => 5); 
    END;
    /
  7. Label the factor identities using the labels for the policy.
    For example:
    BEGIN
     DBMS_MACADM.CREATE_POLICY_LABEL(
      identity_factor_name   => 'Sector2_DB', 
      identity_factor_value  => 'intranet',
      policy_name            => 'Access Locations',
      label                  => 'sensitive'); 
    END;
    /

Note:

If you do not associate an Oracle Label Security policy with factors, then Oracle Database Vault maintains the default Oracle Label Security behavior for the policy.

11.4.4 Tutorial: Integrating Oracle Database Vault with Oracle Label Security

An Oracle Database Vault-Oracle Label Security integration can grant different levels of access to two administrative users who have the same privileges.

11.4.4.1 About This Tutorial

You can use Oracle Database Vault factors with Oracle Label Security and Oracle Virtual Private Database (VPD) to restrict sensitive data access.

You can restrict this data so that it is only exposed to a database session when the correct combination of factors exists, defined by the security administrator, for any given database session.

11.4.4.2 Step 1: Create Users for This Tutorial

You must create two administrative users for this tutorial.

  1. Log in to a PDB as a user who has been granted the DV_ACCTMGR role.

    For example:

    sqlplus accts_admin_ace@pdb_name
    Enter password: password

    To find the available PDBs, query the PDB_NAME column of the DBA_PDBS data dictionary view. To check the current container, run the show con_name command.

  2. Create the following local users:
    GRANT CREATE SESSION TO mdale IDENTIFIED BY password CONTAINER = CURRENT;
    GRANT CREATE SESSION TO jsmith IDENTIFIED BY password CONTAINER = CURRENT;
    

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

  3. Connect as a user who can grant system privileges and who has been granted the owner authorization for the Oracle System Privilege and Role Management realm, and then grant administrative privileges to users mdale and jsmith.
    CONNECT dba_psmith@pdb_name
    Enter password: password
    
    GRANT DBA TO mdale, jsmith;
    

    At this stage, users mdale and jsmith have identical administrative privileges.

11.4.4.3 Step 2: Create the Oracle Label Security Policy

Next, you can create the Oracle Label Security policy and grant users the appropriate privileges for it.

  1. In SQL*Plus, connect to the PDB as the Oracle Label Security administrator, LBACSYS.
    CONNECT LBACSYS@pdb_name
    Enter password: password
    

    If user LBACSYS is locked and expired, connect as the Database Vault Account Manager, unlock and unexpire the LBACSYS account, and then log back in as LBACSYS.

    For example:

    CONNECT accts_admin_ace@pdb_name
    Enter password: password
    
    ALTER USER LBACSYS ACCOUNT UNLOCK IDENTIFIED BY password;
    
    CONNECT LBACSYS
    Enter password: password
  2. Create a new Oracle Label Security policy:
    EXEC SA_SYSDBA.CREATE_POLICY('PRIVACY','PRIVACY_COLUMN','NO_CONTROL');
  3. Create the following levels for the PRIVACY policy:
    EXEC SA_COMPONENTS.CREATE_LEVEL('PRIVACY',2000,'S','SENSITIVE');
    EXEC SA_COMPONENTS.CREATE_LEVEL('PRIVACY',1000,'C','CONFIDENTIAL');
    
  4. Create the PII compartment.
    EXEC SA_COMPONENTS.CREATE_COMPARTMENT('PRIVACY',100,'PII','PERS_INFO');
    
  5. Grant users mdale and jsmith the following labels:
    EXEC SA_USER_ADMIN.SET_USER_LABELS('PRIVACY','mdale','S:PII');
    EXEC SA_USER_ADMIN.SET_USER_LABELS('PRIVACY','jsmith','C'); 
    

    User mdale is granted the more sensitive label, Sensitive, which includes the PII compartment. User jsmith gets the Confidential label, which is less sensitive.

11.4.4.4 Step 3: Create Oracle Database Vault Rules to Control the OLS Authorization

After you create the Oracle Label Security policy, you can create Database Vault rules to work with it.

  1. Connect to the PDB as the Database Vault Owner.

    For example:

    CONNECT sec_admin_owen@pdb_name
    Enter password: password
    
  2. Create the following rule set:
    EXEC DBMS_MACADM.CREATE_RULE_SET('PII Rule Set', 'Protect PII data from privileged users','Y',1,0,2,NULL,NULL,0,NULL);
    
  3. Create a rule for the PII Rule Set.
    EXEC DBMS_MACADM.CREATE_RULE('Check OLS Factor',  'dominates(sa_utl.numeric_label(''PRIVACY''),  char_to_label(''PRIVACY'',''S:PII'')) = ''1''');
    

    Ensure that you use single quotes, as shown in this example, and not double quotes.

  4. Add the Check OLS Factor rule to the PII Rule Set.
    EXEC DBMS_MACADM.ADD_RULE_TO_RULE_SET('PII Rule Set', 'Check OLS Factor');
11.4.4.5 Step 4: Update the ALTER SYSTEM Command Rule to Use the Rule Set

Before the rule set can be used, you must update the ALTER SYSTEM command rule, which is a default command rule.

  1. As the Database Vault Owner, check the current value of the ALTER SYSTEM command rule, which is one of the default command rules when you install Oracle Database Vault.
    SELECT * FROM DBA_DV_COMMAND_RULE WHERE COMMAND = 'ALTER SYSTEM';
    
  2. Make a note of these settings so that you can revert them to their original values later on.

    In a default installation, the ALTER SYSTEM command rule uses the Allow Fine Grained Control of System Parameters rule set, and is enabled.

  3. Update the ALTER SYSTEM command rule to be associated with the PII Rule Set.
    EXEC DBMS_MACADM.UPDATE_COMMAND_RULE('ALTER SYSTEM', 'PII Rule Set', '%', '%', 'Y');
    

    This command adds the PII Rule Set to the ALTER SYSTEM command rule, applies it to all object owners and object names, and enables the command rule.

11.4.4.6 Step 5: Test the Authorizations

With all the components in place, you are ready to test the authorization.

  1. In SQL*Plus, log in to the PDB as user mdale.
    CONNECT mdale@pdb_name
    Enter password: password
    
  2. Check the current setting for the AUDIT_TRAIL initialization parameter.
    SHOW PARAMETER AUDIT_TRAIL
    
    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- ----------------------
    audit_trail                          string      DB
    

    Make a note of this setting, so that you can revert it to its original setting later on.

  3. As user mdale, use the ALTER SYSTEM statement to modify the CPU_COUNT parameter.
    ALTER SYSTEM SET CPU_COUNT = 4;
    System altered.
    

    Because user mdale was assigned the Sensitive label with the PII compartment, he can use the ALTER SYSTEM statement to modify the CPU_COUNT system parameter.

  4. Set the CPU_COUNT parameter back to its original value.

    For example:

    ALTER SYSTEM SET CPU_COUNT = 2;
    
  5. Log in as user jsmith and then issue the same ALTER SYSTEM statement:
    CONNECT jsmith@pdb_name
    Enter password: password
    
    ALTER SYSTEM SET CPU_COUNT = 14;
    

    The following output should appear:

    ERROR at line 1:
    ORA-01031: insufficient privileges
    

    Because user jsmith was assigned only the Confidential label, he cannot perform the ALTER SYSTEM statement.

11.4.4.7 Step 6: Remove the Components for This Tutorial

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

  1. Connect to the PDB as the Oracle Label Security administrator and remove the label policy and its components.
    CONNECT LBACSYS@pdb_name
    Enter password: password
    
    EXEC SA_SYSDBA.DROP_POLICY('PRIVACY', TRUE);
  2. Connect as the Oracle Database Vault Owner and issue the following commands in the order shown, to set the ALTER SYSTEM command rule back to its previous setting and remove the rule set.

    For example:

    CONNECT sec_admin_owen@pdb_name
    Enter password: password
    
    EXEC DBMS_MACADM.UPDATE_COMMAND_RULE('ALTER SYSTEM', 'Allow System Parameters','%', '%', 'Y');
    EXEC DBMS_MACADM.DELETE_RULE_FROM_RULE_SET('PII Rule Set', 'Check OLS Factor');
    EXEC DBMS_MACADM.DELETE_RULE('Check OLS Factor');
    EXEC DBMS_MACADM.DELETE_RULE_SET('PII Rule Set');
    COMMIT;
    
  3. Connect as the Database Vault Account Manager and remove users mdale and jsmith.
    CONNECT accts_admin_ace@pdb_name
    Enter password: password
    
    DROP USER mdale;
    DROP USER jsmith;

11.4.5 Related Reports and Data Dictionary Views

Oracle Database Vault provides reports and data dictionary views that list information about the Oracle Database Vault-Oracle Label Security integration.

Table 11-1 lists the Oracle Database Vault reports.

Table 11-1 Reports Related to Database Vault and Oracle Label Security Integration

Report Description

Factor Configuration Issues Report

Lists factors in which the Oracle Label Security policy does not exist.

Identity Configuration Issues Report

Lists invalid label identities (the Oracle Label Security label for this identity has been removed and no longer exists).

Security Policy Exemption Report

Lists accounts and roles that have the EXEMPT ACCESS POLICY system privilege granted to them. Accounts that have this privilege can bypass all Virtual Private Database policy filters and any Oracle Label Security policies that use Oracle Virtual Private Database indirectly.

Table 11-2 lists data dictionary views that provide information about existing Oracle Label Security policies used with Oracle Database Vault.

Table 11-2 Data Dictionary Views Used for Oracle Label Security

Data Dictionary View Description

DBA_DV_MAC_POLICY

Lists the Oracle Label Security policies defined

DBA_DV_MAC_POLICY

Lists the factors that are associated with Oracle Label Security policies

DBA_DV_POLICY_LABEL

Lists the Oracle Label Security label for each factor identifier in the DBA_DV_IDENTITY view for each policy

11.5 Integrating Oracle Database Vault with Oracle Data Guard

Oracle Database Vault can protect your Oracle Data Guard environments, providing additional security for your high availability and disaster recovery architecture.

11.5.1 Step 1: Configure the Primary Database

An Oracle Database Vault-Oracle Data Guard integration requires first, the primary database configuration, then the standby database configuration.

  1. For Linux and UNIX systems, ensure there is an /etc/oratab entry for the database on the node in which you are installing Oracle Database Vault.

  2. If you are using Data Guard Broker, then from the command prompt, disable the configuration as follows:

    dgmgrl sys
    Enter password: password
    
    DGMGRL> disable configuration;
    
  3. Configure and enable Oracle Database Vault on the primary server.

    By default, Oracle Database Vault is installed as part of Oracle Database. You can check the registration status by querying the DBA_DV_STATUS data dictionary view.

  4. Log in to the PDB as user SYS with the SYSDBA administrative privilege.

  5. Run the following ALTER SYSTEM statements:

    ALTER SYSTEM SET AUDIT_SYS_OPERATIONS=TRUE SCOPE=SPFILE; 
    ALTER SYSTEM SET OS_ROLES=FALSE SCOPE=SPFILE; 
    ALTER SYSTEM SET RECYCLEBIN='OFF' SCOPE=SPFILE; 
    ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE='EXCLUSIVE' SCOPE=SPFILE;
    ALTER SYSTEM SET SQL92_SECURITY=TRUE SCOPE=SPFILE;
    ALTER SYSTEM SET REMOTE_OS_ROLES=FALSE SCOPE=SPFILE;
    
  6. Run the ALTER SYSTEM statement on each database instance to set the parameters as shown in Step 5.

  7. As user SYS with the SYSDBA administrative privilege, close and then reopen each PDB.

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

11.5.2 Step 2: Configure the Standby Database

You can perform the standby database configuration within the database to be used for the standby database.

  1. Log into the database instance as user SYS with the SYSDBA administrative privilege.
    sqlplus sys@pdb_name as sysdba
    Enter password: password
    

    To find the available PDBs, query the PDB_NAME column of the DBA_PDBS data dictionary view. To check the current container, run the show con_name command.

  2. Mount a standby database instance.
    ALTER DATABASE MOUNT STANDBY DATABASE;
    
  3. Run the following ALTER SYSTEM statements:
    ALTER SYSTEM SET AUDIT_SYS_OPERATIONS=TRUE SCOPE=SPFILE; 
    ALTER SYSTEM SET OS_ROLES=FALSE SCOPE=SPFILE; 
    ALTER SYSTEM SET RECYCLEBIN='OFF' SCOPE=SPFILE; 
    ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE='EXCLUSIVE' SCOPE=SPFILE;
    ALTER SYSTEM SET SQL92_SECURITY=TRUE SCOPE=SPFILE;
    ALTER SYSTEM SET REMOTE_OS_ROLES=FALSE SCOPE=SPFILE;
  4. Close and then reopen the PDB.

    For example:

    ALTER PLUGGABLE DATABASE pdb_name CLOSE IMMEDIATE;
    ALTER PLUGGABLE DATABASE pdb_name OPEN;
  5. Mount the next standby instance.
  6. Restart the managed recovery as follows:
    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE; 
    
  7. If you are using Data Guard Broker, then from the command line, re-enable the configuration.
    dgmgrl sys
    Enter password: password
    
    DGMGRL> enable configuration; 
    

    This command applies the changes to the physical standby database made by the Oracle Database Vault installation on the primary database.

  8. Repeat the physical standby installation process on each physical standby database. For example, if there are three physical standby databases, then run these procedures or each standby database.

11.5.3 How Auditing Works After an Oracle Database Vault-Oracle Active Data Guard Integration

After you have integrated Oracle Database Vault with Oracle Active Data Guard, how auditing is configured affects how audit records are generated.

If you want to use the Active Data Guard physical standby database for read-only queries, then you must use pure unified auditing, not mixed mode. If mixed mode is used, then any query in the Active Data Guard physical standby that generates Oracle Database Vault audit records will be blocked. Oracle Database Vault cannot write to the traditional Database Vault audit table (DVSYS.AUDIT_TRAILS$). Unified auditing will ensure that the Database Vault audit data is written into the operating system log files in an Oracle Active Data Guard physical standby database. You can move the data in these log files to the unified audit trail. Remember that to audit Database Vault activities, you must create unified audit policies, because the Database Vault traditional audit settings do not apply to unified auditing.

11.5.4 Disabling Oracle Database Vault in an Oracle Data Guard Environment

If you want to disable Oracle Database Vault in an Oracle Data Guard environment, you must perform the procedures first on the primary database, and then on the standby database.

Perform the disablement of Oracle Database Vault on the primary and standby databases in the following order:

  1. Disable Oracle Database Vault on the primary database.
  2. Disable Oracle Database Vault on the secondary database.
  3. Restart the primary database.
  4. Restart each standby database.

11.6 Registering Oracle Internet Directory Using Oracle Database Configuration Asssitant

You can use Oracle Internet Directory in an Oracle Database Vault-enabled database.

However, if you want to register Oracle Internet Directory (OID) using Oracle Database Configuration Assistant (DBCA), then you must first disable Oracle Database Vault.

11.7 Integrating Oracle Database Vault with Oracle APEX

You can integrate Oracle Database Vault with Oracle APEX.

11.7.1 About Integrating Oracle Database Vault with Oracle APEX

Oracle APEX is Oracle's primary tool for developing Web applications with SQL and PL/SQL.

You can enable Oracle Database Vault to protect the applications that are developed on Oracle APEX. To use Oracle APEX in an Oracle Database Vault-enabled database, you must install Oracle APEX on the Oracle Database Vault-enabled server, and then perform the necessary authorizations in the appropriate pluggable databases (PDBs).

11.7.2 Installing or Upgrading Oracle APEX with Oracle Database Vault Enabled

When Oracle Database Vault is enabled, additional privileges are required to install or upgrade Oracle APEX.

  1. Log in to the root of the Oracle Database Vault-enabled database as a user with the DV_OWNER role.
  2. Grant the DV_PATCH_ADMIN role to SYS in all pluggable databases (PDBs).
    GRANT DV_PATCH_ADMIN TO SYS CONTAINER=ALL;
  3. Complete the installation of Oracle APEX as directed by Oracle Application Express Installation Guide.
    If this installation includes Oracle Rest Data Services (ORDS), then see Authorizing Oracle APEX to Proxy Users for Oracle Rest Data Services.
  4. As a user with the DV_OWNER role, in the container database revoke the DV_PATCH_ADMIN role from SYS from all PDBs.
    REVOKE DV_PATCH_ADMIN FROM SYS CONTAINER=ALL;

11.7.3 Authorizing the Oracle APEX Schema for Oracle Database Vault Activities

You must add the Oracle APEX schema (for example, APEX_SCHEMA) to Oracle Database Vault realms and authorizations that are required by Oracle APEX.

  1. Connect to the pluggable database (PDB) of the Oracle Database Vault-enabled database as a user with the DV_OWNER role.
  2. Authorize the Oracle APEX schema for the following realms, policies, and rules.
    For example, for an Oracle APEX schema called APEX_SCHEMA:
    BEGIN
     DBMS_MACADM.ADD_AUTH_TO_REALM(
     REALM_NAME      => 'Oracle Default Schema Protection Realm',
     GRANTEE         => 'APEX_SCHEMA',
     RULE_SET_NAME   => NULL,
     AUTH_OPTIONS    => DBMS_MACUTL.G_REALM_AUTH_OWNER);
    END;
    /
    
    BEGIN
     DBMS_MACADM.ADD_AUTH_TO_REALM(
     REALM_NAME      => 'Oracle System Privilege and Role Management Realm',
     GRANTEE         => 'APEX_SCHEMA',
     RULE_SET_NAME   => NULL,
     AUTH_OPTIONS    => DBMS_MACUTL.G_REALM_AUTH_OWNER);
    END;
    /
    
    BEGIN
     DBMS_MACADM.ADD_AUTH_TO_REALM(
     REALM_NAME     => 'Oracle Default Component Protection Realm',
     GRANTEE        => 'APEX_SCHEMA',
     RULE_SET_NAME  => NULL,
     AUTH_OPTIONS   => DBMS_MACUTL.G_REALM_AUTH_OWNER);
    END;
    /
    
    BEGIN
     DBMS_MACADM.ADD_AUTH_TO_REALM(
     REALM_NAME     => 'Database Vault Account Management',
     GRANTEE        => 'APEX_SCHEMA',
     RULE_SET_NAME  => NULL,
     AUTH_OPTIONS   => DBMS_MACUTL.G_REALM_AUTH_OWNER);
    END;
    /
    
    EXEC DBMS_MACADM.UPDATE_POLICY_STATE('Oracle Account Management Controls',DBMS_MACADM.G_PARTIAL);
    BEGIN 
     DBMS_MACADM.UPDATE_RULE('Is User Manager'
    ,'DVSYS.DBMS_MACUTL.USER_HAS_ROLE_VARCHAR(''DV_ACCTMGR'',SYS_CONTEXT(''userenv'',''current_user'')) = ''Y''');
    END;
    /
    
    BEGIN 
     DBMS_MACADM.UPDATE_RULE('Is Alter DVSYS Allowed'
    ,'DVSYS.DBMS_MACADM.IS_ALTER_USER_ALLOW_VARCHAR(SYS_CONTEXT(''userenv'',''current_user'')) = ''Y''');
    END;
    /

11.7.4 Authorizing Oracle APEX to Use Oracle Scheduler

Oracle APEX uses Oracle Scheduler and must be authorized to continue to do so.

  1. Connect the pluggable database (PDB) of the Oracle Database Vault-enabled database as a user with the DV_OWNER role.
  2. Authorize the SYS user to use its scheduler privileges on the Oracle APEX schema.
    For example, for an Oracle APEX schema named APEX_SCHEMA:
    EXEC DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('SYS','APEX_SCHEMA');
  3. Authorize the Oracle APEX user to use its job scheduler privileges.
    EXEC DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('APEX_SCHEMA','%');

11.7.5 Authorizing Oracle APEX to Perform DDL Tasks

You must authorize the Oracle APEX schema to use its DDL privileges on objects that it has access to but may be subject to additional Oracle Database Vault controls

  1. Connect the pluggable database (PDB) of the Oracle Database Vault-enabled database as a user with the DV_OWNER role.
  2. Authorize the Oracle APEX schema to use its DDL privileges
    For example, for an Oracle APEX schema named APEX_SCHEMA:
    EXEC DBMS_MACADM.AUTHORIZE_DDL('APEX_SCHEMA','%');

11.7.6 Authorizing Oracle APEX to Perform Information Lifecycle Maintenance Tasks

You must authorize the Oracle APEX schema to perform maintenance tasks.

  1. Connect the pluggable database (PDB) of the Oracle Database Vault-enabled database as a user with the DV_OWNER role.
  2. Authorize the Oracle APEX schema to use its DDL privileges.
    For example, for an Oracle APEX schema named APEX_SCHEMA:
    EXEC DBMS_MACADM.AUTHORIZE_MAINTENANCE_USER('APEX_SCHEMA','%');

11.7.7 Authorizing Oracle APEX to Proxy Users for Oracle Rest Data Services

If you use Oracle Rest Data Services (ORDS), then you must authorize proxy users.

  1. Connect the pluggable database (PDB) of the Oracle Database Vault-enabled database as a user with the DV_OWNER role.
  2. Find the existing proxy users and database users that they can proxy as.
    SELECT PROXY, CLIENT FROM PROXY_USERS;
  3. Authorize the proxying of users.
    EXEC DBMS_MACADM.AUTHORIZE_PROXY_USER('proxy','client');
  4. Repeat this step for each of the combinations listed in the PROXY_USERS query that you performed.

11.7.8 Oracle APEX and Application Objects Protected by Oracle Database Vault

Objects that are protected by Oracle Database Vault realms and command rules are still protected after you have integrated Oracle APEX.

The same privileges and authorizations must be met before Oracle Database Vault will grant access to these objects. For example, if you create an Oracle APEX workspace that requires access to the HR schema objects, and there is an Oracle Database Vault realm protected the HR schema objects, then the workspace will be required to have authorization to access the realm.

11.7.9 Troubleshooting the Oracle APEX and Database Vault Integration

If you have problems with the integration of Oracle APEX and Database Vault, then you can diagnose these problems using tracing and Oracle Database Vault simulation mode.

  • Tracing: Trace files enable you to track the Oracle Database Vault database instance for server and background process events. Use trace file to find out if the Oracle Database Vault policy authorization succeeded or failed. They are also useful for resolving issues such as bugs and other unexpected behavior.
  • Simulation mode: You can use simulation mode to capture violations in a simulation log instead of blocking SQL execution by Oracle Database Vault realms and command rules. Oracle Database Vault stores these errors in a central location so that you can easily analyze them.