Skip Headers
Oracle® Database Vault Administrator's Guide
11g Release 2 (11.2)

Part Number E16544-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

9 Integrating Oracle Database Vault with Other Oracle Products

This chapter contains:

Note:

If you plan to use Oracle Data Guard with Oracle Database Vault, see My Oracle Support (formerly OracleMetaLink) Note 754065.1. You can access My Oracle Support from the following Web site:

https://support.oracle.com

Using Oracle Database Vault with Oracle Enterprise Manager

This section contains:

Setting the Database Vault Administrator URL in Oracle Enterprise Manager

You can configure Database Control or Grid Control to use a specific Database Vault Administrator URL.

  1. Access Oracle Database Vault Home page from Oracle Enterprise Manager.

    See "Accessing Oracle Database Vault Page 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.

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

  3. 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
    
  4. To test the URL, click the Launch to test URL button.

  5. Click the Save button.

Propagating Oracle Database Vault Policies to Other Databases

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. Note that 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:

  1. 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 Page from Oracle Enterprise Manager".

  2. From the Database Vault home page, select the Administration subpage.

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

  4. Under Available Policies, select each policy that you want to propagate to another database.

    By default, all policies are selected.

    Description of dv_oem.gif follows
    Description of the illustration dv_oem.gif

  5. Under Destination Databases, click the Add button.

    Description of dv_oem2.gif follows
    Description of the illustration dv_oem2.gif

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

  7. Under Destination Databases, do the following:

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

    2. Select each database to which you want to propagate the policies.

    3. Enter the Database Vault administrator user name and password for each database.

    4. Click the Apply button.

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

  9. Click the OK button.

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

Using Enterprise Manager Grid Control Alerts for Oracle Database Vault Policies

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.

Using Oracle Database Vault-Specific Reports in Enterprise Manager Grid Control

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.

Changing the DBSNMP Account Password in an Oracle Database Vault Environment

Before you can change the password for the DBSNMP user account, you must revoke the DV_MONITOR role from this account. In an Oracle Database Vault environment, the DBSNMP user account is granted the DV_MONITOR role. (The DBSNMP user can change his or her own password directly, without having to have the DV_MONITOR role revoked first.)

To change the DBSNMP user password:

  1. Log in to SQL*Plus 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.

Alternatively, you can temporarily disable Oracle Database Vault, log on as a user who has been granted the ALTER USER privilege, and then modify the DBSNMP password. Afterward, re-enable Database Vault. See Appendix B, "Disabling and Enabling Oracle Database Vault," for more information.

Integrating Oracle Database Vault with Enterprise User Security

You can integrate Oracle Database Vault with Oracle Enterprise User Security. Enterprise User Security enables you to centrally manage 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 roles as needed, you can create a rule set for the Enterprise users to allow or disallow their access.

To configure an Enterprise User authorization:

  1. Create a rule to allow or disallow user access.

    Follow the instructions in "Creating a Rule to Add to a Rule Set" to create a new rule. In the Create Rule page, enter the following PL/SQL in the Rule Expression field:

    SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY') = 'user_domain_name'
    

    Replace user_domain_name with the domain, for example:

    SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY') = 'myserver.us.example.com'
    
  2. Add this rule to a new rule set.

    "Creating a Rule Set" explains how to create a new rule set, including how to add an existing rule to it.

  3. Add this rule set to the realm authorization for the database that you want to protect.

    "Defining Realm Authorization" explains how to create realm authorizations. In the Authorization Rule Set list, select the rule set that you created in Step 2. Afterward, the realm authorization applies to all users.

For more information about Enterprise User Security, see Oracle Database Enterprise User Security Administrator's Guide.

Integrating Oracle Database Vault with Transparent Data Encryption

Oracle Database Vault works with Transparent Data Encryption (TDE). With Transparent Data Encryption, an application administrator can use a single one line command to alter a table and encrypt a column. Subsequent inserts into that table column are written to disk encrypted transparent to the SQL. This means that no SQL modification, database triggers, or views are required.

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.

So, if you have Transparent Data Encryption enabled, Oracle Database Vault works with it seemlessly and without any additional configuration. Transparent Data Encryption also can be enabled in an Oracle Database Vault environment with any additional configuration.

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

Figure 9-1 Encrypted Data and Oracle Database Vault

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

Attaching Factors to an Oracle Virtual Private Database

You can attach factors to an Oracle Virtual Private Database. To do so, define a policy predicate that is a PL/SQL function or expression. Then, for each function or expression, you can use the DVF.F$ PL/SQL function that is created for each factor.

For more information about Oracle Virtual Private Database, see Oracle Database Security Guide.

Integrating Oracle Database Vault with Oracle Label Security

This section includes the following topics:

How Oracle Database Vault Is Integrated with Oracle Label Security

When you integrate Oracle Database Vault with Oracle Label Security, it means that you can assign an Oracle Label Security label to an Oracle Database Vault factor identity.

In Oracle Label Security, you can restrict access to records 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 her VPN connection, she has 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. "Tutorial: Integrating Oracle Database Vault with Oracle Label Security" provides an example of how to accomplish this type of integration.

You can audit the integration with Oracle Label Security by using the Label Security Integration Audit Report. See "Label Security Integration Audit Report" for more information. Oracle Database Vault writes the audit trail to the DVSYS.AUDIT_TRAIL$ system file, described in Appendix A, "Auditing Oracle Database Vault."

You can use the Oracle Database Vault APIs to integrate Oracle Database Vault with Oracle Label Security. See Chapter 11, "Using the DVSYS.DBMS_MACADM Package," for more information.

For more information about Oracle Label Security labels, levels, and policies, see Oracle Label Security Administrator's Guide.

You can run reports on the Oracle Database Vault and Oracle Label Security integration. See "Related Reports and Data Dictionary Views" for more information.

Requirements for Using Oracle Database Vault with Oracle Label Security

You must have the following 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.

  • Ensure that you have the appropriate Oracle Label Security policies defined. For more information, see Oracle Label Security Administrator's Guide.

Using Oracle Database Vault Factors with Oracle Label Security Policies

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. See Oracle Label Security Administrator's Guide for more information about row labels and policies.

Use the following steps to define factors that contribute to the maximum allowable data label of an Oracle Label Security policy:

  1. Log in to Oracle Database Vault Administrator as a user who has been granted the DV_OWNER or DV_ADMIN role.

    "Starting Oracle Database Vault" explains how to log in.

  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.

    The LBACSYS account is created in Oracle Label Security using the Oracle Universal Installer custom installation option. Before you can create an Oracle Label Security policy for use with Oracle Database Vault, you must make LBACSYS an owner for the realm you plan to use. See "Defining Realm Authorization" for more information.

  3. In the Administration page, under Database Vault Feature Administration, click Label Security Integration.

  4. In the Label Security Policies page:

    • To register a new label security policy, click Create.

    • To edit an existing label security policy, select it from the list and then click Edit.

  5. Enter the following settings and then click OK:

General

Under General, enter the following settings:

  • Label Security Policy: From the list, select the Oracle Label Security policy that you want to use.

  • Algorithm: Optionally change the label-merging algorithm for cases when Oracle Label Security has merged two labels. In most cases, you may want to select 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.

    For more information on these label-merging algorithms, see Oracle Label Security Administrator's Guide. If you want to use the DVSYS.DBMS_MACADM package to specify a merge algorithm, see Table 11-57, "Oracle Label Security Merge Algorithm Codes" for a full listing of possible merge algorithms.

  • Label for Initialization Errors: Optionally enter a label for initialization errors. The label specified for initialization errors is set when a configuration error or run-time error occurs during session initialization. You can use this setting to assign the session a data label that prevents access or updates to any data the policy protects until the issue is resolved.

Label Security Policy Factors

To select a factor to associate with an Oracle Label Security policy:

  1. In the Available Factors list under Label Security Policy Factors, select the factor that you want to associate with the Oracle Label Security policy.

  2. Click Move to move the factor to the Selected Factors list.

    Note:

    You can select multiple factors by holding down the Ctrl key as you click each factor that you want to select.

After you associate a factor with an Oracle Label Security policy, you can label the factor identities using the labels for the policy. "Adding an Identity to a Factor" provides detailed information.

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.

Tutorial: Integrating Oracle Database Vault with Oracle Label Security

You can use Oracle Database Vault factors with Oracle Label Security and Oracle Virtual Private Database (VPD) technology to restrict access to sensitive data. 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.

This tutorial shows how you can integrate Oracle Database Vault with Oracle Label Security to grant two administrative users who normally have the same privileges different levels of access.

In this tutorial:

Step 1: Create Users for This Tutorial

  1. Log in to SQL*Plus as a user who has been granted the DV_ACCTMGR role.

    For example:

    sqlplus amalcolm_dvacctmgr
    Enter password: password
    
  2. Create the following users:

    CREATE USER mdale IDENTIFIED BY password;
    CREATE USER jsmith IDENTIFIED BY password;
    

    Replace password with a password that is secure. See Oracle Database Security Guide for the minimum requirements for creating passwords.

  3. Connect as user SYS with the SYSDBA privilege and then grant administrative privileges to users mdale and jsmith.

    CONNECT SYS/AS SYSDBA
    Enter password: password
    
    GRANT CREATE SESSION, DBA TO mdale, jsmith;
    

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

Step 2: Create the Oracle Label Security Policy

  1. In SQL*Plus, connect as the Oracle Label Security administrator, LBACSYS.

    CONNECT LBACSYS
    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 amalcolm_dvacctmgr
    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.

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

  1. Connect to SQL*Plus as the Database Vault Owner.

    For example:

    CONNECT lbrown_dvowner
    Enter password: password
    
  2. Create the following rule set:

    EXEC DVSYS.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 DVSYS.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 DVSYS.DBMS_MACADM.ADD_RULE_TO_RULE_SET('PII Rule Set', 
     'Check OLS Factor');
    
  5. Synchronize the Check OLS factor rule.

    EXEC DVSYS.DBMS_MACADM.SYNC_RULES;
    COMMIT;
    

Step 4: Update the ALTER SYSTEM Command Rule to Use the Rule Set

  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 DVSYS.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 System Parameters rule set, has no object owner or name, and is enabled.

  3. Update the ALTER SYSTEM command rule to include the PII Rule Set.

    EXEC DVSYS.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.

Step 5: Test the Authorizations

  1. In SQL*Plus, log on as user mdale.

    CONNECT mdale
    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 AUDIT_TRAIL parameter.

    ALTER SYSTEM SET AUDIT_TRAIL=OS, EXTENDED SCOPE=SPFILE;
    System altered.
    

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

  4. Set the AUDIT_TRAIL parameter back to its original value, for example:

    ALTER SYSTEM SET AUDIT_TRAIL=DB, EXTENDED SCOPE=SPFILE;
    
  5. Log in as user jsmith and then issue the same ALTER SYSTEM statement:

    CONNECT jsmith
    Enter password: password
    
    ALTER SYSTEM SET AUDIT_TRAIL=OS, EXTENDED SCOPE=SPFILE;
    

    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.

  6. Now log in as user SYSTEM, who normally has the ALTER SYSTEM privilege, and issue the same ALTER SYSTEM statement:

    CONNECT SYSTEM
    Enter password: password
    

    The following output should appear:

    ERROR at line 1:
    ORA-01031: insufficient privileges
    

    SYSTEM no longer has sufficient privileges needed to perform an ALTER SYSTEM statement. Only users who have been assigned the Sensitive label, as with user mdale, can use the ALTER SYSTEM statement.

Step 6: Remove the Components for This Tutorial

  1. Connect as the Oracle Label Security administrator and remove the label policy and its components.

    CONNECT LBACSYS
    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 lbrown_dvowner
    Enter password: password
    
    EXEC DVSYS.DBMS_MACADM.UPDATE_COMMAND_RULE('ALTER SYSTEM', 'Allow System Parameters','%', '%', 'Y');
    EXEC DVSYS.DBMS_MACADM.DELETE_RULE_FROM_RULE_SET('PII Rule Set', 'Check OLS Factor');
    EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Check OLS Factor');
    EXEC DVSYS.DBMS_MACADM.DELETE_RULE_SET('PII Rule Set');
    COMMIT;
    
  3. Connect as the Database Vault Account Manager and remove users mdale and jsmith.

    CONNECT amalcolm_dvacctmgr
    Enter password: password
    
    DROP USER mdale;
    DROP USER jsmith;
    

Related Reports and Data Dictionary Views

Table 9-1 lists Oracle Database Vault reports that are useful for analyzing the integration of Oracle Database Vault and Oracle Label Security. See Chapter 16, "Oracle Database Vault Reports," for information about how to run these reports.

Table 9-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 9-2 lists data dictionary views that provide information about existing Oracle Label Security policies used with Oracle Database Vault.

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

Data Dictionary View Description

"DBA_DV_MAC_POLICY View"

Lists the Oracle Label Security policies defined

"DBA_DV_MAC_POLICY_FACTOR View"

Lists the factors that are associated with Oracle Label Security policies

"DBA_DV_POLICY_LABEL View"

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


Using Oracle Data Pump in an Oracle Database Vault Environment

This section contains:

About Using Oracle Data Pump in an Oracle Database Vault Environment

Oracle Data Pump administrators must have Oracle Database Vault-specific authorization, in addition to the standard Oracle Data Pump privileges, if they want to export and import data in an Oracle Database Vault environment.

The level of authorization that you must grant depends on the following scenarios:

  • An Oracle Data Pump administrator wants to export or import data in a schema that has no realm protection. In this case, this user only needs the standard Oracle Data Pump privileges, not the Oracle Database Vault authorization.

  • An Oracle Data Pump administrator wants to export or import data in his or her own schema. If this schema is protected by a realm, ensure that this user is authorized to access the realm that protects these objects. Normally, even when objects are protected by a realm, their owner still can perform DML operations on them without having to be authorized by a realm. This does not apply for Oracle Data Pump export and import operations. The object owner must be authorized for the realm that protects the schema. See "Defining Realm Authorization" for instructions on granting a user realm authorization. Other than the realm authorization, the administrator must have the standard system privileges normally required for using Oracle Data Pump.

  • An Oracle Data Pump administrator wants to export or import data in the schemas of other users. You must grant this user Database Vault-specific authorization by using the DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedure. This authorization applies to both the expdp and impdp utilities. Later on, you can revoke this authorization by using the DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER procedure.

    This type of authorization is strictly for Oracle Data Pump operations only. For example, a user who has been granted this privilege is permitted to export and import database objects, but he or she cannot perform other activities, such as SELECT queries on schema tables to which he or she normally does not have access. Similarly, if the user tries to perform a Data Pump operation on any objects outside the designated data objects, he or she will not be permitted.

  • An Oracle Data Pump administrator wants to export or import the contents of an entire database. In addition to the authorization granted by the DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedure, you must grant this user the DV_OWNER role. The reason you must do so is because a full database export will naturally require access to the DVSYS schema, which stores the Oracle Database Vault policies. Conversely, for a Data Pump import operation to apply the imported policies to the target database, it internally uses the DVSYS.DBMS_MACADM PL/SQL package, which in turn requires the Data Pump user to have the DV_OWNER role.

Granting an Oracle Data Pump Administrator Authorization for Oracle Database Vault

To authorize an Oracle Data Pump user for Oracle Database Vault:

  1. Log in to SQL*Plus as a user who has been granted the DV_OWNER or DV_ADMIN role.

  2. Ensure that the user to whom you want to grant authorization has been granted the EXP_FULL_DATABASE and IMP_FULL_DATABASE roles, which are required for using Oracle Data Pump.

    SELECT GRANTEE, GRANTED_ROLE FROM DBA_ROLE_PRIVS 
     WHERE GRANTED_ROLE LIKE '%FULL%';
    
  3. Grant this user Oracle Database Vault authorization.

    For example, to authorize the Data Pump user dp_mgr to export and import objects for an entire database:

    EXEC DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('dp_mgr');
    

    Optionally, you can restrict dp_mgr's activities to a specific schema or even a table, as shown in the following examples:

    EXEC DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR');
    
    EXEC DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR', 'EMPLOYEES');
    

    See "AUTHORIZE_DATAPUMP_USER Procedure" for detailed information about this procedure.

    After you run the DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedure, the authorization is stored as a rule in the Allow Oracle Data Pump Operation rule set, described in "Default Rule Sets". You can refer to this rule set by querying the DVSYS.DBA_DV_RULE_SET view if you want to check the user's authorizations.

  4. If the user must export the entire database, then grant the user the DV_OWNER role.

    GRANT DV_OWNER TO dp_mgr;
    
  5. Ensure that the Allow Oracle Data Pump Operation rule set has been enabled by querying the DVSYS.DBA_DV_RULE_SET data dictionary view as follows:

    SELECT ENABLED FROM FROM DVSYS.DBA_DV_RULE_SET 
     WHERE RULE_SET_NAME = 'Allow Oracle Data Pump Operation'; 
    

Guidelines for Exporting or Importing Data in an Oracle Database Vault Environment

After you have granted the Oracle Data Pump user the necessary authorization, this user is ready to 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, you easily can revert the database to its previous state. This guideline is especially useful if an intruder had managed to modify 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 DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedure, but you can use either of the following methods to accomplish this task:

    • Run individual DVSYS.DBMS_MACADM.AUTHORIZE_DATAPUMP_USER procedures 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 has been granted the DV_OWNER role. For detailed information about Oracle Data Pump, see Oracle Database Utilities.

Revoking Authorization from Oracle Data Pump Administrators

To revoke authorization from the user:

  1. If you granted the user the DV_OWNER role, optionally revoke this role.

    REVOKE DV_OWNER FROM dp_mgr;
    
  2. Query the DVSYS.DBA_DV_RULE_SET data dictionary view and then make a note of the user's authorizations that have been defined in the Allow Oracle Data Pump Operation rule set.

    SELECT RULE_EXPR FROM DVSYS.DBA_DV_RULE_SET 
     WHERE RULE_SET_NAME = 'Allow Oracle Data Pump Operation';
    

    For example, if you had authorized user dp_mgr to perform export and import operations on the entire database, a rule defining this authorization appears in the list of rule expressions in the Allow Oracle Data Pump Operation rule set.

  3. Use the information you gathered from Step 2 to build the DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER command.

    For example:

    EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR');
    

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

    EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR');
    
    EXEC DVSYS.DBMS_MACADM.UNAUTHORIZE_DATAPUMP_USER('DP_MGR', 'HR', 'EMPLOYEES');
    

    See "UNAUTHORIZE_DATAPUMP_USER Procedure" for more information.

Scheduling Database Jobs in an Oracle Database Vault Environment

This section contains:

About Scheduling Database Jobs in an Oracle Database Vault Environment

Users who are responsible for scheduling database jobs must have Oracle Database Vault-specific administration, in addition to the standard system privileges required for scheduling database jobs.

The level of authorization that you must grant depends on the following scenarios:

  • 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. See "Defining Realm Authorization" for instructions on granting a user realm authorization.

  • 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 DVSYS.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 DVSYS.DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER procedure. If the schema is not protected by a realm, then you do not need to run the DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER procedure for the user.

Granting a Job Scheduling Administrator Authorization for Oracle Database Vault

To authorize a user to schedule database jobs:

  1. Log in to SQL*Plus 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 DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER('JOB_MGR');
    

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

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

    See "AUTHORIZE_SCHEDULER_USER Procedure" for detailed information about this procedure.

    After you run the DVSYS.DBMS_MACADM.AUTHORIZE_SCHEDULER_USER procedure, the authorization is stored as a rule in the Allow Scheduler Job rule set, described in "Default Rule Sets". You can refer to this rule set by querying the DVSYS.DBA_DV_RULE_SET view if you want to check the user's authorizations.

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

    SELECT GRANTEE,OBJECT_OWNER FROM DVSYS.DBA_DV_JOB_AUTH 
    WHERE GRANTEE = 'user_name';
    

Revoking Authorization from Job Scheduling Administrators

To revoke authorization from a user for scheduling database jobs.

  1. Query the DVSYS.DBA_DV_JOB_AUTH data dictionary view and then make a note of the user's authorizations that have been defined in the Allow Scheduler Job rule set.

    SELECT GRANTEE FROM DVSYS.DBA_DV_JOB_AUTH;
    

    For example, if you had authorized user job_mgr to perform schedule database jobs for the entire database, a rule defining this authorization appears in the list of rule expressions in the Allow Scheduler Job rule set.

  2. Use the information you gathered from Step 1 to build the DVSYS.DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER command.

    For example:

    EXEC DVSYS.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 DVSYS.DBMS_MACADM.UNAUTHORIZE_SCHEDULER_USER('JOB_MGR', 'HR');
    

    See "UNAUTHORIZE_SCHEDULER_USER Procedure" for more information.

Using Oracle Database Vault with Oracle Recovery Manager

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:

Using Oracle Streams in an Oracle Database Vault Environment

If you want to use Oracle Streams in an Oracle Database Vault environment, then you must be granted the DV_STREAMS_ADMIN role. See "DV_STREAMS_ADMIN Oracle Streams Configuration Role" for more information.