You can propagate Database Vault configurations (such as a realm configuration) to other Database Vault-protected databases.

To view Oracle Database Vault alerts, you must be granted the DV_OWNER, DV_ADMIN, or DV_SECANALYST role.

The alerts are as follows:

• Database Vault Attempted Realm Violations. This alert helps the Oracle Database Vault security analyst (DV_SECANALYST role) to monitor violation attempts on the Database Vault database. This user can select the realms to be affected by the alert and filter these realms based on the different types of attempts by using error codes. You can enable this metric from the Metrics and Policy Settings page. By default, the attempted realm violations are collected every 24 hours.

• Database Vault Attempted Command Rule Violations. The functionality for this alert is the same as for Database Vault Attempted Realm Violations, except that it focuses on violations on command rules.

• Database Vault Realm Configuration Issues. This metric tracks and raises an alert if users misconfigure realms. This metric is enabled when you install Oracle Database vault, and by default it collects data every one hour.

• Database Vault Command Rule Configuration Issues. This functionality for this alert is that same as Database Vault Realm Configuration Issues, except that it focuses on configuration changes to command rules.

• Database Vault Policy Changes. This metric raises an alert on any change to any Database Vault policy, such as policies for realms and command rules. It provides a detailed policy changes report.

From the Database Vault home page, you can find information about violations.

These violations are as follows:

• Top five attempted violations on realm and command rule

• Top five attempted violations by database users and client host

• Time series-based graphical reports on attempted violations for more detailed analysis

To have full access to the Database Vault reports, you must log into Database Vault Administrator as a user who has been granted the DV_OWNER, DV_ADMIN, or DV_SECANALYST role.

Before you can change the password for the DBSNMP user account, you must revoke the DV_MONITOR role from this account.

1. Log into the database instance using an account that has been granted the DV_OWNER role.
2. Revoke the DV_MONITOR role from the DBSNMP user account.
3. Connect as a user who has been granted the DV_ACCTMGR role and then change the DBSNMP user account password.
4. Connect as the DV_OWNER user and then grant the DV_MONITOR role back to the DBSNMP user account.

Database administrators who use Oracle Data Pump in an Database Vault environment must have Database Vault-specific authorization to export and import data.

This type of user must have Database Vault privileges in addition to the standard Oracle Data Pump privileges. If these users want to perform Oracle Data Pump transportable tablespace operations, then they must have special authorization. You can check a user's authorizations for using Data Pump in an Oracle Database Vault environment by querying the DBA_DV_DATAPUMP_AUTH data dictionary view. You can grant this authorization to either individual users or to database roles.

You can use different authorization types for administrators who perform Oracle Data Pump export and import operations in a Database Vault environment.

• About Authorizing Users or Roles for Oracle Data Pump Regular Operations
  Users who have Oracle Data Pump authorization can perform regular Oracle Data Pump operations in a Database Vault environment.
• Levels of Database Vault Authorization for Oracle Data Pump Regular Operations
  Oracle Database Vault provides several levels of authorization required for Oracle Data Pump regular operations in a Database Vault environment.
• Authorizing Users or Roles for Oracle Data Pump Regular Operations in Database Vault
  You can authorize a database administrator or a role to use Data Pump for regular operations in an Oracle Database Vault environment.
• Revoking Oracle Data Pump Authorization from Users or Roles
  You can revoke authorization from the database administrator or role who is using Oracle Data Pump for regular operations.

You can grant authorization levels for users who must perform Oracle Data Pump transportable operations, either directly or through a role.

• About Authorizing Users for Oracle Data Pump Transportable Operations
  You can grant users (either directly or through a role) different levels of transportable operation authorization.
• Levels of Database Vault Authorization for Data Pump Transportable Operations
  Oracle Database Vault provides levels of authorization required for users who must perform export and import transportable operations in a Database Vault environment.
• Authorizing Users or Roles for Data Pump Transportable Operations in Database Vault
  You can authorize users or roles to perform Oracle Data Pump transportable export or import operations in a Database Vault environment.
• Revoking Transportable Tablespace Authorization from Users or Roles
  You can revoke authorization from the database administrator who is using Data Pump.

After you grant the Oracle Data Pump database administrator the proper authorization, this user can perform any export or import operations that are necessary.

Before this user begins work, he or she should follow these guidelines:

• Create a full backup of the database datafiles. This way, if you or other users do not like the newly-imported data, then you easily can revert the database to its previous state. This guideline is especially useful if an intruder had managed to modify Oracle Data Pump exported data to use his or her own policies.

• Decide how to handle exporting and importing multiple schemas or tables. You cannot specify multiple schemas or tables in the DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedure, but you can use either of the following methods to accomplish this task:

  • Run the DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedure for each schema or table, and then specify the list of these objects in the SCHEMAS or TABLES parameter of the EXPDP and IMPDP utilities.

  • Perform a full database export or import operation. If so, see the next guideline.

• When performing an export or import operation for an entire database, set the EXPDP or IMPDP FULL option to Y. Remember that this setting will capture the DVSYS schema, so ensure that the user or role has that you have authorized been granted the DV_OWNER role.

Note the following:

• You cannot use the legacy EXP and IMP utilities with the direct path option (direct=y) if Oracle Database Vault is enabled.

• Users, either through a direct grant or a role grant, that have been granted Database Vault-specific Oracle Data Pump authorization through the DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedure or transportable tablespace authorization through the DBMS_MACADM.AUTHORIZE_TTS_USER procedure can export and import database objects, but they cannot perform other activities, such as SELECT queries on schema tables to which they normally do not have access. Similarly, users are not permitted to perform Data Pump operations on objects outside the designated data objects.

• You must grant the DV_OWNER role to users who must export or import an entire database, because a full database export requires access to the DVSYS schema, which stores the Oracle Database Vault policies. However, you cannot export the DVSYS schema itself. Data Pump only exports the protection definitions. The target database must have the DVSYS schema in it and Database Vault enabled before you can begin the import process.) Conversely, for a Data Pump import operation to apply the imported policies to the target database, it internally uses the DBMS_MACADM PL/SQL package, which in turn requires the Data Pump user to have the DV_OWNER role.

The level of authorization that you must grant depends on the schema in which the administrator wants to perform a task.

Possible scenarios are as follows:

• An administrator wants to schedule a job in his or her own schema. An administrator who has been granted privileges to schedule database jobs can continue to do so without any Oracle Database Vault-specific authorizations, unless this schema is protected by a realm. In that case, ensure that this user is authorized to access the realm.

• An administrator wants to run a job in another schema, but this job does not access any Oracle Database Vault realm or command rule protected object. In this case, this user only needs job related system privileges, not the Oracle Database Vault privileges.

• An administrator wants to run a job under the schema of another user, including any schema in the database or a remote database. If this job accesses an Oracle Database Vault realm or command rule protected object, then you must grant this user Database Vault-specific authorization by using the DBMS_MACADM.AUTHORIZE_SCHEDULER_USER procedure. This authorization applies to both background and foreground jobs. For background jobs, the authorization applies to the last user who created or modified the job. In addition, ensure that the schema owner (the protected schema in which the job is created) authorized to the realm.

  Later on, you can revoke this authorization by using the DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER procedure. If the schema is not protected by a realm, then you do not need to run the DBMS_MACADM.AUTHORIZE_SCHEDULER_USER procedure for the user.

You can authorize a user to schedule database jobs in a Database Vault environment.

1. Log into the database instance as a user who has been granted the DV_OWNER or DV_ADMIN role.

   Only a user who has been granted either of these roles can grant the necessary authorization.

2. Ensure that the user to whom you want to grant authorization has been granted system privileges to schedule database jobs.

   These privileges include any of the following: CREATE JOB, CREATE ANY JOB, CREATE EXTERNAL JOB, EXECUTE ANY PROGRAM, EXECUTE ANY CLASS, MANAGE SCHEDULER. The DBA and SCHEDULER_ADMIN roles provide these privileges; however, when Oracle Database Vault is enabled, the privileges are revoked from these roles.

   For example:

   SELECT GRANTEE, PRIVILEGE FROM DBA_SYS_PRIVS 
    WHERE PRIVILEGE IN ('CREATE JOB', 'CREATE ANY JOB');
   

3. Grant this user Oracle Database Vault authorization.

   For example, to authorize the user job_mgr to schedule jobs for any schema in the database:

   EXEC DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('JOB_MGR');
   

   Optionally, you can restrict job_mgr's activities to a specific schema, as follows:

   EXEC DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('JOB_MGR', 'HR');
   

4. Ensure that the user has been authorized by querying the DBA_DV_JOB_AUTH data dictionary view as follows:

   SELECT GRANTEE,SCHEMA FROM DBA_DV_JOB_AUTH WHERE GRANTEE = 'user_name';
   

You can revoke authorization from a user for scheduling database jobs.

1. Query the DBA_DV_JOB_AUTH data dictionary view to find the user's authorization.

   SELECT GRANTEE, SCHEMA FROM DBA_DV_JOB_AUTH WHERE GRANTEE='username';
   

2. Use the information you gathered from the preceding step to build the DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER command.

   For example:

   EXEC DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER('JOB_MGR');
   

   Ensure that this unauthorization complements the original authorization action. In other words, if you originally gave job_mgr authorization over the entire database, then the following command will not work:

   EXEC DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER('JOB_MGR', 'HR');
   

In an Oracle Database Vault-enabled database, only users who have Database Vault authorizations can mask data in Database Vault-protected database objects.

In a non-Database Vault environment, users who have been granted the SELECT_CATALOG_ROLE and DBA roles can perform data masking. However, with Database Vault, users must have additional privileges. This section describes three ways that you can use to enable users to mask data in Database Vault-protected objects.

If users do not have the correct privileges, then the following errors can occur while creating the masking definition or when the job is executing:

ORA-47400: Command Rule violation for string on string 

ORA-47401: Realm violation for string on string. 

ORA-47408: Realm violation for the EXECUTE command 

ORA-47409: Command Rule violation for the EXECUTE command 

ORA-01301: insufficient privileges

You can add data masking users to the Oracle Default Component Protection realm to give them data dictionary realm authorizations.

BEGIN
 DBMS_MACADM.ADD_AUTH_TO_REALM(
  realm_name   => 'Oracle Default Component Protection Realm', 
  grantee      => 'DBA_JSMITH', 
  auth_options => DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT);
END;
/

To give users access to tables or schemas that they want to mask, you must authorize them for the appropriate realm.

BEGIN
 DBMS_MACADM.ADD_AUTH_TO_REALM(
  realm_name   => 'Business Apps Realm', 
  grantee      => 'DBA_JSMITH', 
  auth_options => DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT;
END;
/

You must have privileges to manage tables, packages, and triggers before you can use data masking in an Oracle Database Vault environment.

1. Create the rule set rule.

   For example:

   BEGIN
    DBMS_MACADM.CREATE_RULE(
     rule_name  => 'Is HDRISCOLL or DBA_JSMITH User', 
     rule_expr  =>'USER IN(''HDRISCOLL'',''DBA_JSMITH'')';
   END;
   /
   

2. Create a rule set and then add the rule to it:

   BEGIN
    DBMS_MACADM.CREATE_RULE_SET(
     rule_set_name    => 'Allow Data Masking', 
     description      => 'Allows users HDRISCOLL and DBA_JSMITH access', 
     enabled          => 'Y',
     eval_options     => 1,
     audit_options    => 1,
     fail_options     => 1,
     fail_message     => 'You do not have access to this object.',
     fail_code        => 20461,
     handler_options  => 0, 
     is_static        => TRUE);
   END;
   /
   BEGIN
    DBMS_MACADM.ADD_RULE_TO_RULE_SET(
     rule_set_name => 'Allow Data Masking', 
     rule_name     => 'Is HDRISCOLL or DBA_JSMITH User'),
     rule_order    => 1);
   END;
   /
   

3. Create a command rule and then add this rule to it:

   BEGIN
    DBMS_MACADM.CREATE_COMMAND_RULE(
     command         => 'CREATE TABLE', 
     rule_set_name   => 'Allow Data Masking', 
     object_owner    => 'HR', 
     object_name     => 'EMPLOYEES', 
     enabled         => DBMS_MACUTL.G_YES);
   END; 
   /