This section contains:
Setting the Database Vault Administrator URL in Oracle Enterprise Manager
Propagating Oracle Database Vault Policies to Other Databases
Using Enterprise Manager Grid Control Alerts for Oracle Database Vault Policies
Using Oracle Database Vault-Specific Reports in Enterprise Manager Grid Control
You can configure Database Control or Grid Control to use a specific Database Vault Administrator URL.
Access Oracle Database Vault Home page from Oracle Enterprise Manager.
See "Accessing Oracle Database Vault Pages from Oracle Enterprise Manager".
If you want to save the Database Vault URL:
For Database Control: Ensure that in addition to being granted the DV_OWNER
or DV_ADMIN
role, that you are also an Enterprise Manager administrator.
For Grid Control: Ensure that you have been granted the OPERATOR
privilege on the target database.
Access the Database Vault Administrator URL page.
From the Database Vault Home page, click the Administration tab, and then under Policy Administration, click the Launch Database Vault Administrator link.
The Database Vault Administrator URL page appears.
In the Database Vault Administrator URL field, enter the Database Vault Administrator URL that you want to use.
For example:
https://myserver.us.example.com:1148/dva
To test the URL, click Launch to test URL button.
Click the Save button.
If you have Oracle Database Vault installed in an Oracle Enterprise Manager Grid Control Release 10.2.0.5 environment, then you can propagate Database Vault policies to other Database Vault-protected databases. You cannot use Grid Control to create Database Vault policies or perform the actions normally provided for in Database Vault Administrator. If you want to perform these functions, then use Database Vault Administrator.
To propagate Database Vault policies to other databases:
Access Oracle Database Vault Administrator from Oracle Enterprise Manager, and log in to Database Vault as a user who has been granted the DV_OWNER
or DV_ADMIN
role.
Ensure that you select the database that contains the policies that you want to propagate.
See "Accessing Oracle Database Vault Pages from Oracle Enterprise Manager".
From the Database Vault home page, select the Administration subpage.
In the Administration page, under Policy Propagation, select the Database Vault Policy Propagation link.
The Available Policies area in the Policy Propagation subpage lists a summary of the Oracle Database Vault policies that were created for the database that you selected in Step 1. From here, you can propagate these policies to another database.
Under Available Policies, select each policy that you want to propagate to another database.
By default, all policies are selected.
Under Destination Databases, click the Add button.
Under Search and Select: Database Vault Enabled Destination Databases, search for the destination databases, and then select each database to which you want to propagate the policies. Then click the Select button.
Under Destination Databases, do the following:
Under Apply credentials across destination database(s), enter the user name and password of the administrator of the Database Vault database that contains the policies you want to propagate.
This feature applies the Database Vault administrator's user name and password to all of the selected destination databases.
Select each database to which you want to propagate the policies.
Enter the Database Vault administrator user name and password for each database.
Click the Apply button.
In the Propagate Options page, select from the following options.
Any changes made to the seeded realms, command rules, rule sets, and so on will not be propagated to the destination databases. Only custom-created data are propagated.
Restore on failure: If the policy propagation encounters errors, then the propagation is rolled back. That is, the original policies on the destination database are restored. If you do not select this option, then the policy propagation on the destination database continues and ignores any errors.
Skip propagation if user defined policies exist: If the destination databases already have the user-defined policies, then the policy propagation is not attempted. If you do not select this option, then regardless of whether user-defined policies exist on the destination database, all the existing policies are cleared, and the policies from the source database are applied to the destination database.
Propagate Enterprise Manager metric thresholds for database vault metrics: If the source database has Oracle Database Vault metric thresholds set, then these thresholds are also propagated to the destination databases. If you do not select this option, then only policies are propagated and not the Oracle Database Vault thresholds.
Click the OK button.
In the Confirmation window, click OK.
A message indicating success or failure appears. If the propagation succeeds, then the policies are active right away in their destination databases.
Grid Control generates Oracle Database Vault-specific alerts. To view these 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 the following types of violations:
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 in to Database Vault Administrator as a user who has been granted the DV_OWNER
, DV_ADMIN
, or DV_SECANALYST
role.
You can use Recovery Manager (RMAN) in an Oracle Database Vault environment. The functionality of RMAN with Oracle Database Vault is the same as its functionality in a standard Oracle Database environment.
For more information about RMAN, see the following documentation:
This section contains:
About Data Masking in an Oracle Database Vault Enabled Database
Adding Data Masking Users to the Data Dictionary Realm Authorizations
Giving Users Access to Tables or Schemas That They Want to Mask
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
The Oracle Data Dictionary controls access to the Oracle Database catalog schemas, such as SYS
and SYSTEM
. (See "Default Realms" for a full list of these schemas.) It also controls the ability to grant system privileges and database administrator roles. If you add users to the Data Dictionary realm, and assuming these users already have the privileges associated with the Oracle Data Dictionary, then these users will have these same privileges in a Database Vault environment. Therefore, if you do add a user to this realm, ensure that this user is a trusted user.
For example:
BEGIN DBMS_MACADM.ADD_AUTH_TO_REALM( realm_name => 'Data Dictionary Realm', grantee => 'DBA_JSMITH', auth_options => DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT); END; /
If the table or schema of a table that is to be data masked is in a realm, then you must add the user responsible for data masking to the realm authorization as a participant or owner. If the table or schema has dependent objects that are in other realm-protected tables, then you must grant the user participant or owner authorization for those realms as well.
The following example shows how to grant user DBA_JSMITH
authorization for the HR.EMPLOYEES
table, which is protected by a realm called Business Apps 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; /
For data masking, users must have the CREATE TABLE
, SELECT TABLE
, ALTER TABLE
, and DROP TABLE
privileges for the masking objects and if there are any dependent objects to be created, the user must have the appropriate privileges such as CREATE PACKAGE
, CREATE TRIGGER
, and so on.
You can create command rules to control data masking privileges at a granular level. To do so, create a command rule that can either prevent or allow the user access to objects that must have to be data masked. For example, you can create a command rule called Allow Data Masking that checks if the user is in a list of users who are responsible for data masking. If the user logging in is one of these users, then the command rule evaluates to true and the user is permitted to create the data mask for the protected object.
To create this type of command rule:
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; /
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; /
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; /