The Create Factors page enables you to create the factor, starting with a general definition of the factor that you want to create.

1. Log in to Oracle Database Vault Administrator from Cloud Control as a user who has been granted the DV_OWNER or DV_ADMIN role and the SELECT ANY DICTIONARY privilege. Logging in to Oracle Database Vault from Oracle Enterprise Cloud Control explains how to log in.
2. In the Administration page, under Database Vault Components, click Factors.
3. In the Factors page, click Create to display the Create Factor page.
   
   
   Description of the illustration create_factor122.png
   
4. Starting with the General page, enter the following information, clicking Next to go to each subsequent page, and then clicking Done and Finish when the factor definition is complete.

   • Completing the General Page for Factor Creation

   • Configurations Page for Factor Creation

   • Options Page of Factor Creation

   • Creating and Configuring a Factor Identity

In the General page, you must enter general identifying information for the factor, such as its name.

The Configurations page defines settings such as the factor's identification and the evaluation method.

• Setting the Factor Identification Information
  Under Factor Identification, you must select how to resolve the identity of a factor. This attribute is mandatory.
• How Factor Identities Work
  A factor identity is the actual value of a factor (for example, the IP address for a factor that uses the IP_Address type).
• Setting the Evaluation Information for a Factor
  Under Evaluation, you must select how you want the factor to be evaluated and assigned an identity.
• Setting the Oracle Label Security Labeling Information for a Factor
  Under Factor Labeling, you must select how you want the factor identity to retrieve an Oracle Label Security (OLS) label.
• Setting the Retrieval Method for a Factor
  Under Retrieval Method, you must enter a PL/SQL expression that retrieves the identity of a factor or a constant.
• How Retrieval Methods Work
  The Retrieval Method identifies factors where the factor identification is by method or constant.
• Setting the Validation Method for a Factor
  A validation method uses a PL/SQL expression to return a Boolean value to validate the identity of a factor.

The Options page assigns a rule set to a factor, sets error options, and for non-unified auditing, sets audit options.

• Assigning a Rule Set to a Factor
  Under Assignment Rule Set, you select a rule set if you want to use a rule set to control setting a factor identity.
• Setting Error Options for a Factor
  Under Error Options, you set the processing that must occur when a factor identity cannot be resolved.
• Setting Audit Options for a Factor
  Under Audit Options, you can generate an audit trail if you are not using a unified audit environment.
• How Factor Auditing Works
  Whether you have unified auditing enabled affects how auditing is handled for factors.

An identity is the actual value of a factor, such an IP_Address factor identity being 192.0.2.4.

A factor identity for a given database session is assigned at run time using the Factor Identification and Retrieval Method fields described in Creating a Factor. You can further configure the identity for the following reasons:

• To define the known identities for a factor

• To add a trust level to a factor identity

• To add an Oracle Label Security label to a factor identity

• To resolve a factor identity through its child factors, by using identity mapping

Trust levels enable you to assign a numeric value to indicate the measure of trust allowed.

A trust value of 1 signifies some trust. A higher value indicates a higher level of trust. A negative value or zero indicates distrust. When the factor identity returned from a factor retrieval method is not defined in the identity, Oracle Database Vault automatically assigns the identity a negative trust level.

To determine the trust level of a factor identity at run time, you can use the GET_TRUST_LEVEL and GET_TRUST_LEVEL_FOR_IDENTITY functions in the DVSYS schema.

For example, suppose you have created a factor named Network. You can create the following identities for the Network factor:

• Intranet, with a trust level of 10

• VPN (virtual private network), with a trust level of 5

• Public, with a trust level of 1

You then can create rule expressions (or custom application code) that base policy decisions on the trust level. For example, you can use the GET_TRUST_LEVEL function to find trust levels greater than 5:

GET_TRUST_LEVEL('Network') > 5

Or, you can use a SELECT statement on the DBA_DV_IDENTITY data dictionary view to find trust levels for the Network factor greater than or equal to 5:

SELECT VALUE, TRUST_LEVEL FROM DBA_DV_IDENTITY 
   WHERE TRUST_LEVEL >= 5 
   AND FACTOR_NAME='Network'

Output similar to the following appears:

F$NETWORK GET_TRUST_LEVEL('NETWORK')
------------------------------------
VPN                                5
INTRANET                          10

In the preceding example, Network factor identity for VPN is trusted (value equals 5), and the identity for the INTRANET domain is 10, which implies a greater trust.

You can assign You Oracle Label Security (OLS) labels to factor identities.

In brief, a label acts as an identifier for a database table row to assign privileges to the row. The Factor Labeling attribute for a factor determines whether a factor is labeled By Self or By Factors. If you set the Factor Labeling attribute to By Self, then you can associate OLS labels with the factor identities. If you set the Factor Labeling attribute to By Factors, then Oracle Database Vault derives the factor identity labels from the labeling of child factor identities. When there are multiple child factor identities with labels, Oracle Database Vault merges the labels using the OLS algorithm associated with the applicable factor Oracle Label Security policy.

You can create and configure a factor identity in Oracle Database Vault Administrator.

1. In the Select Identities page of the Create Factor pages, select Add New Identity.

   The Add New Identity window appears.

   
   
   Description of the illustration factor_identity122.png
   
2. In the Identity subpage, enter the following values:

   • Value: Enter the value of the identity, up to 1024 characters in mixed-case. This attribute is mandatory.

   • Trust Level: Select one of the following trust levels:

     • Very Trusted: Assigns a trust level value of 10

     • Trusted: Assigns a trust level value of 5

     • Somewhat Trusted: Assigns a trust level value of 1

     • Untrusted: Assigns a trust level value of -1

     • Trust Level Not Defined: Assigns a trust level value of NULL (default)

     See About Trust Levels for detailed information about trust levels.

   • Label Identity: Optionally, select from the list of available Oracle Label Security policies and then click the Move button to move them to the Selected OLS Policies list.

     The list shows data labels from the Oracle Label Security installation for your site. For more information, refer to Oracle Label Security Administrator’s Guide.

     See About Label Identities for detailed information about label identities.

3. Click OK to return to the Create Factors : Identities page..
4. Click Next to review the factor settings.
5. Click Finish.

If you want to delete a factor identity, you can locate references to it by querying the factor-related Oracle Database Vault views.

1. Log in to Oracle Database Vault Administrator from Cloud Control as a user who has been granted the DV_OWNER or DV_ADMIN role and the SELECT ANY DICTIONARY privilege. Logging in to Oracle Database Vault from Oracle Enterprise Cloud Control explains how to log in.
2. In the Administration page, under Database Vault Components, click Factors.
3. Select the factor whose identity you want to delete, and then click Edit.
4. In the Edit Factor page, click Next until you reach the Identities page.
5. Select the factor identity that you want to remove.
6. Click Remove.
7. Click Done, then click Finish.

You can use identity mapping to use a group of factors to manage identity values.

• About Identity Mapping
  While you are creating a factory identity, you can map it.
• Mapping an Identity to a Factor
  You can map an identity to a factor by creating a parent-child relationship with two factors.

Oracle Database Vault evaluates the factors based on when a session begins.

When a database session is established, the following actions occur:

1. At the start of each database session, Oracle Database Vault begins to evaluate all default and user-created factors in the database instance.

   This evaluation occurs after the normal database authentication of the session and the initialization of the Oracle Label Security session information, if applicable.

2. In the factor evaluation stage, the factor initialization process executes the retrieval method for all factors that are identified by methods or constants, to resolve the factor identity for the session.

   The factor error options setting has no effect on the factor initialization process.

3. If a factor has a validation method defined, Oracle Database Vault validates the identity (value) of the factor by executing this validation method. If the validation method fails or returns false, the identity of the factor is undefined (NULL).

4. If a factor has any identities defined for it, Oracle Database Vault resolves the trust level of the factor based on the identities defined. If an identity of the factor is defined in this list of defined identities, then Oracle Database Vault assigns the trust level as configured; otherwise it sets it to -1. If there are no identities defined for the factor, the trust level is undefined (NULL).

5. Depending on the outcome of this factor evaluation, factor validation, and trust level resolution, Database Vault audits the details of the evaluation as dictated by the factor audit configuration.

6. When the evaluation of all factors that are identified by method or constant completes, Oracle Database Vault resolves the factors that are identified by other factors by using the identity maps that are defined for the factor configured identities.

   The evaluation order of the factor-configured identities is by ASCII sort on the identity values: Oracle Database Vault uses the first alphabetically sorted identity mapping that it evaluates. For example, suppose factor TEST has identities X and Y. Furthermore, identities X and Y have identity maps that are dependent on identities for factors A, B, and C. The following mapping occurs:

   • X is mapped when A=1 and B=1

   • Y is mapped when A=1, B=1, and C=2

   In this case, the first one evaluated is X. Y is not evaluated, but what if its C mapping meets the criteria that is needed for the TEST factor's success? You would need to reverse the mapping, that is, map Y before X so that A, B, and C can be evaluated first. To reverse the mapping, rename Y to V (or some alphabetic value that sorts before X) so that it can be correctly resolved.

   This algorithm works if the ASCII sort ordering is correct and the identities map the same number factors at some level.

7. When the factor initialization completes, the Oracle Database Vault integration with Oracle Label Security occurs.

After this process completes, Oracle Database Vault checks to see if a command rule is associated with the CONNECT event. If a rule set associated with the CONNECT event, then Oracle Database Vault evaluates the rule set. If the rule set evaluates to false or results in an error, then the session is terminated. Oracle Database Vault executes any auditing or call handlers associated with the rule set before the session is terminated.

You can retrieve a factor in a database session at any time by using the DVF factor function or the GET_FACTOR function.

To find a listing of available factors, query the DBA_DV_FACTOR data dictionary view, described in DBA_DV_FACTOR View.

Example 7-1 shows an example of using the GET_FACTOR function.

SELECT GET_FACTOR('client_ip') FROM DUAL;

You can assign a factor identity at any time during a database session, but only if the factor assignment rule set evaluates to true.

You can do this in the application code by using the SET_FACTOR function. In Java code, you can use the JDBC class java.sql.CallableStatement to set this value. For example:

java.sql.Connection connection ; 
...
java.sql.CallableStatement statement = 
   connection.prepareCall("{call SET_FACTOR('FACTOR_X', ?)}");
statement.setString(1, "MyValue");
boolean result = statement.execute();
...

Applications that can execute Oracle PL/SQL functions can use this procedure (for example, applications written using Oracle Data Provider for .NET (ODP.NET)).

This concept is similar to the standard Oracle DBMS_SESSION.SET_IDENTIFIER procedure with an added feature that a rule set controls when a factor value can be set. If the rule set evaluates to true, Steps 2 through 5 under How Factors Are Processed When a Session Is Established occur.

If you have not associated a assignment rule set for the factor or if the rule set returns false (or returns errors), then Oracle Database Vault sends an error message if you attempt to set the factor using the SET_FACTOR function.

Many database applications contain features to explicitly control the actions of a user.

However, an ad hoc query tool, such as SQL*Plus, may not have these controls. As a result, a user could use an ad hoc tool to perform actions in the database that he or she would normally be prevented from performing in a database application. You can use a combination of Oracle Database Vault factors, rule sets, and command rules to prevent unauthorized access to the database by ad hoc query tools.

In the following tutorial, you prevent users HR and OE from using SQL*Plus. To accomplish this, you must create a factor to find the applications on your system and a rule and rule set to limit SQL*Plus to these four users. Then you create a command rule for the CONNECT SQL statement, which is associated with the rule set. This factor, Client_Prog_Name, uses the CLIENT_PROGRAM_NAME attribute of the SYS_CONTEXT SQL function USERENV namespace to find the names of the applications that are used to access the current instance of Oracle Database. The SYS_CONTEXT SQL function provides many useful methods for finding the state of a user session. SYS_CONTEXT is a valuable tool for creating custom factors.

You must use the HR and OE accounts later on when you test the Oracle Database Vault components for this tutorial.

1. Log into the database instance as a user who has been granted the DV_ACCTMGR role.

   For example:

   sqlplus bea_dvacctmgr
   Enter password: password
   

   In a multitenant environment, you must connect to the appropriate pluggable database (PDB).

   For example:

   sqlplus bea_dvacctmgr@hrpdb
   Enter password: password
   

   To find the available PDBs, run the show pdbs command. To check the current PDB, run the show con_name command.

2. Check the status of the HR account.

   SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'HR';
   

3. If the HR account is expired and locked, then enter the following statement to make it active:

   ALTER USER HR ACCOUNT UNLOCK IDENTIFIED BY password;
   

   Follow the guidelines in Oracle Database Security Guide to replace password with a password that is secure.

4. Repeat these steps for the OE account.

After you have ensured that the HR and OE accounts are active, you can create a factor.

1. Connect as a user who has been granted the DV_OWNER or DV_ADMIN role.

   For example:

   CONNECT leo_dvowner --Or, CONNECT leo_dvowner@hrpdb
   Enter password: password
   

2. Create the factor.

   BEGIN
    DBMS_MACADM.CREATE_FACTOR(
     factor_name       => 'Client_Prog_Name',
     factor_type_name  => 'Application',
     description       => 'Stores client program name that connects to database',
     rule_set_name     => NULL,
     validate_expr     => NULL,
     get_expr          => 'UPPER(SYS_CONTEXT(''USERENV'',''CLIENT_PROGRAM_NAME''))',
     identify_by       => DBMS_MACUTL.G_IDENTIFY_BY_METHOD,
     labeled_by        => DBMS_MACUTL.G_LABELED_BY_SELF,
     eval_options      => DBMS_MACUTL.G_EVAL_ON_SESSION,
     audit_options     => DBMS_MACUTL.G_AUDIT_ON_GET_ERROR,
     fail_options      => DBMS_MACUTL.G_FAIL_SILENTLY);
   END;
   /
   

   In this specification:

   • factor_type_name specifies that this is an application-based factor.

   • get_expr defines the expression for the factor. This expression calls the SYS_CONTEXT function, using the USERENV namespace and CLIENT_PROGRAM_NAME attribute, to find the programs that are logged into the Oracle database.

   • identify_by identifies the factor by method.

   • labeled_by labels the identities for the factor directly from the labels associated with an Oracle Label Security policy (default).

   • eval_options evaluates the factor when the database session is created.

   • audit_options audits if get_expr returns an error.

   • fail_silently does not show any error messages for the factor.

After you have created the factor, you can create a rule set and rules to work with the factor.

1. Create the Limit SQL*Plus Access rule set as follows:

   BEGIN
    DBMS_MACADM.CREATE_RULE_SET(
     rule_set_name    => 'Limit SQL*Plus Access',
     description      => 'Limits access to SQL*Plus for Apps Schemas',
     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_SHOW,
     fail_message     => 'SQL*Plus access not allowed for Apps Schemas',
     fail_code        => 20461,
     handler_options  => DBMS_MACUTL.G_RULESET_HANDLER_OFF,
     handler          => NULL,
     is_static        => FALSE);
   END;
   /
   

   In this specification:

   • fail_options enables an error message, set by fail_message, and error code, set by fail_code, to appear if there are errors.

   • is_static evaluates the rule set once during the user session. After that, the value is re-used.

2. Find the exact settings for the computer on which you want to apply the policy, based on what the CLIENT_PROGRAM_NAME attribute will return.

   SELECT SYS_CONTEXT('USERENV', 'CLIENT_PROGRAM_NAME') FROM DUAL;
   

   The output should be similar to the following:

   SYS_CONTEXT('USERENV','CLIENT_PROGRAM_NAME')
   ---------------------------------------------------------------
   sqlplus@nemosity (TNS V1-V3)
   

   For this tutorial, the name of the computer is nemosity. The (TN V1-V3) output refers to the version of the TNS connector.

3. Create the following rules.

   BEGIN
    DBMS_MACADM.CREATE_RULE(
     rule_name  => 'Prevent Apps Schemas Access to SQL*Plus',
     rule_expr  =>'UPPER (DVF.F$CLIENT_PROG_NAME) != ''SQLPLUS@NEMOSITY (TNS V1-V3)'' AND DVF.F$SESSION_USER IN (''HR'', ''OE'')');
   END;
   /
   BEGIN
    DBMS_MACADM.CREATE_RULE(
     rule_name  => 'Allow Non-Apps Schemas Access to SQL*Plus',
     rule_expr  =>'DVF.F$SESSION_USER NOT IN (''HR'', ''OE'')');
   END;
   /
   

   The rules translate to the following: "Prevent users HR and OE from logging into SQL*Plus, but allow other users access."

4. Add the rules to the Limit SQL*Plus Access rule set.

   BEGIN
    DBMS_MACADM.ADD_RULE_TO_RULE_SET(
     rule_set_name => 'Limit SQL*Plus Access',
     rule_name     => 'Prevent Apps Schemas Access to SQL*Plus',
     rule_order    => 1);
   END;
   /
   BEGIN
    DBMS_MACADM.ADD_RULE_TO_RULE_SET(
     rule_set_name => 'Limit SQL*Plus Access',
     rule_name     => 'Allow Non-Apps Schemas Access to SQL*Plus',
     rule_order    => 1);
   END;
   /
   

   The rule_order setting is required to enable the procedure to work.

The CONNECT command rule controls the CONNECT SQL statement.

You do not need to restart your SQL*Plus session for the Oracle Database Vault changes to take effect.

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

   For example:

   CONNECT sec_admin_owen --Or, CONNECT sec_admin_owen@hrpdb for a PDB
   Enter password: password
   

2. Enter the following statement to drop the CONNECT command rule.

   EXEC DBMS_MACADM.DELETE_COMMAND_RULE ('CONNECT', '%', '%');
   

   Even though you have disabled Oracle Database Vault, you still can use its PL/SQL packages and Database Vault Administrator.

3. Check the policy components for any errors and then correct them. Recreate the CONNECT command rule, and then test it.

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

1. Remove the CONNECT command rule.

   EXEC DBMS_MACADM.DELETE_COMMAND_RULE ('CONNECT', '%', '%');
   

2. Remove the Client_Prog_Name factor.

   EXEC DBMS_MACADM.DELETE_FACTOR('Client_Prog_Name');
   

3. Remove the Limit SQL*Plus Access rule set.

   EXEC DBMS_MACADM.DELETE_RULE_SET('Limit SQL*Plus Access');
   

4. Remove the rules.

   EXEC DBMS_MACADM.DELETE_RULE('Prevent Apps Schemas Access to SQL*Plus');
   EXEC DBMS_MACADM.DELETE_RULE('Allow Non-Apps Schemas Access to SQL*Plus');
   

5. If necessary, as a user who has been granted the DBV_ACCTMGR role, lock the HR and OE accounts.

   CONNECT bea_dvacctmgr --Or, CONNECT amalcolumn_dbacctmgr@hrpdb
   Enter password: password
   
   ALTER USER HR ACCOUNT LOCK;
   ALTER USER OE ACCOUNT LOCK;

You can use factor identity mapping to set session-based user restrictions for database activities.

For example, suppose you wanted to restrict administrative access to a database using the following criteria:

• Ensure that the administrator is accessing the database from the correct IP address.

• Limit the database access to the standard business hours of the administrator.

This type of configuration is useful for restricting different types of administrators: not only local, internal administrators, but offshore and contract administrators as well.

In this tutorial, you modify the Domain factor to include identities for a secure and non-secure network access, which are based on the IP address of the computer the administrator is using. If the administrator tries to perform an action outside the standard working hours or from a different IP address, then Oracle Database Vault prevents him from doing so.

Before you can use this tutorial, you must create an administrative user.

1. In SQL*Plus, log in as a user who has been granted the DV_ACCTMGR role, and then create the user account mwaldron.

   For example:

   sqlplus bea_dvacctmgr
   Enter password: password
   
   CREATE USER mwaldron IDENTIFIED BY password;
   

   Follow the guidelines in Oracle Database Security Guide to replace password with a password that is secure.

   In a multitenant environment, you must connect to the appropriate pluggable database (PDB).

   For example:

   sqlplus bea_dvacctmgr@hrpdb
   Enter password: password
   

   To find the available PDBs, query the DBA_PDBS data dictionary view. To check the current PDB, run the show con_name command.

2. Connect as a user who privileges to grant the CREATE SESSION privilege and the DBA role, and then grant user mwaldron these privileges. This user must also be authorized as an owner of the Oracle System Privilege and Role Management realm.

   For example:

   CONNECT dba_psmith -- Or, CONNECT dba_psmith@hrpdb
   Enter password: password
   
   GRANT CREATE SESSION, DBA TO mwaldron;

Next, you must add identities to the Domain factor, which is a default factor.

1. Log in to Oracle Database Vault Administrator from Cloud Control as a user who has been granted the DV_OWNER or DV_ADMIN role and the SELECT ANY DICTIONARY privilege. Logging in to Oracle Database Vault from Oracle Enterprise Cloud Control explains how to log in.
2. In the Administration page, under Database Vault Components, click Factors.

   The Factors page appears.

3. Select the Show Oracle defined Factors check box to display the default factors.
4. Select the Domain factor and then select Edit.

   The Domain factor will be the parent factor.

5. Click the Next button until you reach the Identities page.
6. Select the Add New Identity button.
7. In the Identity tab of the Add New Identity and Mapping page, enter the following information:

   • Value: Enter HIGHLY SECURE INTERNAL NETWORK

   • Trust Level: Select Very Trusted

8. Click OK.
9. Repeat these steps to create a second identity called NOT SECURE, and then set its trust level to Untrusted.
   
   
   Description of the illustration add_identities_tutorial122.png
   

After you have added identities to the domain factory, you can map them to the Client_IP factor.

1. In Identities page, select the HIGHLY SECURE INTERNAL NETWORK identity and then select Edit.
2. In the Add New Identity and Mapping window, select the Map Identity subpage.
3. Select the Map Identity tab, and then select Add Mapping.
4. In the Add New Identity Mapping page, enter the following information:

   • Child Factor: Select Client_IP to be the child factor.

   • Operator: Select Equal.

   • Min Value: Enter the IP address for the Virtual Machine (for example, 192.0.2.12). (This is the computer that user mwaldron uses. For this tutorial, you can enter the IP address of your own computer. If you are using Microsoft Windows, use the IP address assigned to the Loopback Adapter.)

   • Max Value: Leave this field empty.

5. Click OK, and then click OK again to return to the Identities page.
6. Create the following two identity maps for the NOT SECURE identity, by editing this identity:

   Child Factor	Operator	Min Value	Max Value
   Client_IP	Less	192.0.2.5	(Leave blank)
   Client_IP	Greater	192.0.2.20	(Leave blank)

   The identity maps in the NOT SECURE identity are in a range of IP addresses outside the IP address that user mwaldron uses (192.0.2.12). The IP addresses here must be in any range outside mwaldron's IP address.

   This identity mapping creates the following condition: If the user logs in from the correct IP address, then Oracle Database Vault decides that the connection is secure, through the HIGHLY SECURE INTERNAL NETWORK identity. However, if the user logs in from an IP address that is less than 192.0.2.5 or greater than 192.0.2.20, then the connection is deemed not secure, through the NO SECURE identity.

7. Click OK.
8. Click Done, and then click Finish.
9. Test the factor identities.

   First, in SQL*Plus, connect as user mwaldron but do not specify a database instance.

   CONNECT mwaldron -- Or, CONNECT mwaldron@hrpdb
   Enter password: password
   
   SELECT DVF.F$CLIENT_IP FROM DUAL;
   

   The following output should appear:

   F$CLIENT_IP
   -------------------------------------
   

   Next:

   SELECT DVF.F$DOMAIN FROM DUAL;
   

   The following output should appear:

   F$DOMAIN
   -------------------------------------
   NOT SECURE
   

   Because user mwaldron is not connecting directly to the database instance, Oracle Database Vault does not recognize the IP address from which he is connecting. In this case, Oracle Database uses the IPC protocol to perform the connection, which sets the IP value to null. Therefore, the identity for this connection is set to NOT SECURE.

   Now connect to SQL*Plus by specifying the database instance (for example, orcl), and then check the factor identities again:

   CONNECT mwaldron@orcl
   Enter password: password
   
   SELECT DVF.F$CLIENT_IP FROM DUAL;
   

   The following output should appear:

   F$CLIENT_IP
   -------------------------------------
   192.0.2.12
   

   Next:

   SELECT DVF.F$DOMAIN FROM DUAL;
   

   The following output should appear:

   F$DOMAIN
   -------------------------------------
   HIGHLY SECURE INTERNAL NETWORK
   

   Now that user mwaldron is connecting to the orcl database instance, his IP address is recognized. This is because the database uses the TCP protocol, so now the host IP value can be populated appropriately. Because the IP address is within the correct range, the factor identity is set to HIGHLY SECURE INTERNAL NETWORK.

You must create a rule set to work with the factor that you modified.

1. In the Administration page, under Database Vault Components, select Rule Sets.
2. In the Rule Sets page, select Create.
3. In the Create Rule Set page, enter the following settings:

   • Name: Enter Internal DBA Standard Working Hours.

   • Status: Select Enabled.

   • Evaluation Options: Select All True.

   Leave the remaining settings at their defaults.

4. Click Next to display the Associate with Rule page.
5. Select Create Rule.
6. In the Create Rule window, enter the following settings:

   • Name: Internal DBA

   • Expression: DVF.F$SESSION_USER='MWALDRON'

     (When you create an expression with a user name, enter the user name in upper case letters, because that is how the database stores user names.)

7. Click OK.
8. Use the Create Rule page to create the following additional rules:

   • Name: Internal Network Only

     Rule Expression: DVF.F$DOMAIN='HIGHLY SECURE INTERNAL NETWORK'

   • Name: Week Day

     Rule Expression: TO_CHAR(SYSDATE, 'D') BETWEEN '2' AND '6'

   • Name: Week Working Day Hours

     Rule Expression: TO_CHAR(SYSDATE, 'HH24') BETWEEN '08' AND '19'

9. Click Done, and then click Finish.

You must create a command rule that uses the rule set that you created.

1. In the Administration page, select Command Rules.
2. In the Command Rules page, select Create.
3. In the Create Command Rule page, enter the following settings:

   • Command: Select CREATE TABLE from the list.

   • Status: Select Enabled.

   • Applicable Object Owner: Ensure it is set to % (the default).

   • Applicable Object Name: Ensure it is set to % (the default).

   • Evaluating Rule Set: Select Internal DBA Standard Working Hours from the list.

4. Click OK.

Test the settings by resetting the system clock, logging in as the mwaldron administrative user, and then trying to create a table.

1. Set the system time to 9 p.m.

   UNIX: Log in as root and use the date command to set the time. For example, assuming the date today is August 15, 2013, you would enter the following:

   su root
   Password: password
   
   date --set="15 AUG 2013 21:00:00"
   

   Windows: Double-click the clock icon, which is typically at the lower right corner of the screen. In the Date and Time Properties window, set the time to 9 p.m., and then click OK.

2. In SQL*Plus, connect as user mwaldron and try to create a table. In the following, replace orcl with the name of your database instance.

   CONNECT mwaldron@orcl
   Enter password: password
   
   CREATE TABLE TEST (num number);  
   

   The following output should appear:

   ORA-47400: Command Rule violation for create table on MWALDRON.TEST
   

   Because user mwaldron is create a table outside working hours, Database Vault prevents him.

3. Reset the system time back to the local time.
4. In SQL*Plus, as user mwaldron, try to create the table again.

   CREATE TABLE TEST (num number);
   
   Table created.
   
   DROP TABLE TEST;
   Table dropped.
   

   Now that user mwaldron is working during his local hours and from the IP address associated with the HIGHLY SECURE INTERNAL NETWORK identity, he can create tables.

5. Reconnect as user mwaldron but without adding the database instance name to the connection command, and then try to create the table again.

   CONNECT mwaldron -- Or, CONNECT mwaldron@hrpdb
   Enter password: password
   
   CREATE TABLE TEST (num number);
   

   The following output should appear:

   ORA-47400: Command Rule violation for create table on MWALDRON.TEST
   

   Even though user mwaldron is trying to create a table during the correct time, he cannot because is not directly logged in to the orcl database instance. Oracle Database Vault deems him to be using the NOT SECURE identity, and then denies him access.

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

1. Log into the database instance as the DV_ACCTMGR user and drop user mwaldron.

   sqlplus bea_dvacctmgr -- Or, CONNECT bea_dvacctmgr@hrpdb
   Enter password: password
   
   DROP USER mwaldron CASCADE;
   

2. Remove the CREATE TABLE command rule.

   Return the Administration page and select Command Rules. Select the CREATE TABLE command rule and then click Delete. In the Confirmation window, select Yes.

3. Remove the Internal DBA Standard Working Hours rule set.

   Select Rule Sets in the Administration page. In the Rule Sets page, select the Internal DBA Standard Working Hours rule set, and then select Delete. In the Confirmation window, select the Remove rules associated with the rule set check box, and then select Yes.

4. Remove the rules that were associated with the Internal DBA Standard Working Hours rule set.

   Select Rules in the Administration page. In the Rules page, select the Internal DBA, Internal Network Only, Week Day, and Week Day Working Hours rules, and then select Delete. Select Yes in the Confirmation window.

5. Remove the HIGHLY SECURE INTERNAL NETWORK and NOT SECURE factor identities from the Domain factor.

   In the Administration page and select Factors. Select the Domain factor, select Edit. Click Next until you reach the Identities page. Select the HIGHLY SECURE INTERNAL NETWORK and NOT SECURE factor identities and click Remove to remove each one. (Hold the Control key down to select multiple items.) In the Confirmation window, select Yes. Click Done, and then click Finish.