7 Configuring Factors

About Factor Identities

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

Creating and Configuring a Factor Identity

To create and configure an identity:

1. In the Oracle Database Vault Administration page, select Factors.

2. In the Factors page, select the factor to which you want to add the identity.

3. Click Edit.

4. In the Edit Factor page, scroll down to Identities and click Create.

5. In the Create Identity page, enter the following settings and then click OK:

   • General

   • Label Identity

General

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)

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 DVSYS.GET_TRUST_LEVEL to find trust levels greater than 5:

DVSYS.GET_TRUST_LEVEL('Network') > 5

Or, you can use a SELECT statement on the DVSYS.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 DVSYS.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.

See Chapter 15, "Using the Oracle Database Vault PL/SQL Interfaces," for more information about the Oracle Database Vault functions.

Label Identity

You can assign 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. For more information about labels, see Oracle Label Security Administrator's Guide.) 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.

To label an identity:

1. In the Create Identity page, under Label Identity, select the OLS label from the Available OLS Labels 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.

   Note:

   You can select multiple labels by holding down the Ctrl key as you click each label that is to be selected.

2. Click Move to move the OLS label to the Selected OLS Labels list.

3. Repeat Step 1 and Step 2 to select more OLS labels.

   You can select only one label for each OLS policy.

4. Click OK to finish labeling the identity.

Editing a Factor Identity

To edit a factor identity:

1. In the Edit Factor page, scroll down to Identities and select the identity you want to edit.

2. Click Edit.

3. In the Edit Identity page, modify the identity as necessary.

4. Click OK.

Deleting a Factor Identity

Before you delete a factor identity, you can locate the various references to it by querying the factor-related Oracle Database Vault views. See "Oracle Database Vault Data Dictionary Views" for more information.

To delete a factor identity:

1. In the Edit Factor page, scroll down to Identities and select the identity you want to remove.

2. Click Remove.

3. In the Confirmation page, click Yes.

Using Identity Mapping to Configure an Identity to Use Other Factors

After you create, edit, and save the factor identity, you can map it. Identity mapping is the process of identifying a factor by using other (child) factors. This is a way to transform combinations of factors into logical identities for a factor or to transform continuous identity values (for example, temperature) or large discrete identity values (for example, IP address ranges) into logical sets. To check configuration issues in the mapping for an identity, see "Identity Configuration Issues Report". See also "Tutorial: Restricting User Activities Based on Session Data" for an example of how to use identity mapping.

To map an identity to a factor:

1. Create a parent factor and set the attribute Factor Identification to By Factors.

   "Creating a Factor" describes how to create factors.

2. For the parent factor, create a new factor identity.

   "Creating and Configuring a Factor Identity" describes how to create an identity.

3. Map the factor-identity pair of the parent to the factor-identity pairs of its children. Use the following process:

   1. In the Factors page, select the parent factor from the Factors page and then click Edit.

   2. In the Edit Factor page, under Identities, select the parent factor identity and then click Edit.

   3. In the Edit Identity page, click Create under Map Identity.

   4. In the Create Identity Map page, select a factor name from the Contributing Factor list.

      This is the child factor to which you want to map the parent factor.

   5. Select a Map Condition.

      This setting lets you select an operator to compare the contributing (child) factor values.

   6. Enter a value for the Low Value and High Value (optional) fields.

      For example, consider a scenario where the Contributing Factor to the Factor Network is set to Client_IP, the Map Condition is set to Between, the Low Value is set to 192.0.2.1 and the High Value is set to 192.0.2.24. This means that whenever the client IP address lies in the specified address range of 192.0.2.1 to 192.0.2.24, the parent factor evaluates to a predefined identity (for example, INTRANET).

   7. Click OK to map the parent factor-identity to the child factor-identity.

      You can map different identities of a parent factor to different identities of the contributing factor. For example, the INTRANET identity maps to an IP address range of 192.0.2.1 to 192.0.2.24. The REMOTE identity can map to an IP address range that excludes the address range 192.0.2.1 to 192.0.2.24.

      Based on identity mapping, you can create a security policy. For example, you can define a reduced set of privileges for an employee connecting over VPN (with REMOTE), as opposed to an employee connecting from within the corporate network (with INTRANET).

   8. Repeat Step c to Step g to add more contributing factors for a parent factor identity.

      For example, you can configure the Network factor to resolve to a value ACCOUNTING-SENSITIVE, when the Program factor resolves to "Oracle General Ledger" and the Client_IP is in between 192.0.2.1 and 192.0.2.24. So, if an authorized accounting financial application program, running on a client with IP address 192.0.2.12 accesses the database, then the Network factor is resolved to ACCOUNTING-SENSITIVE. A database session with the ACCOUNTING-SENSITIVE Network value would have more access privileges than one with the INTRANET Network value.

How Factors Are Processed When a Session Is Established

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.

How Factors Are Retrieved

You can retrieve a factor in a database session at any time by using the DVF factor function or the DVSYS.GET_FACTOR function. To find a listing of available factors, query the DVS.DBA_DV_FACTOR data dictionary view, described in"DBA_DV_FACTOR View".

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

SELECT GET_FACTOR('client_ip') FROM DUAL;

You can use the factor values retrieved from the DVF factor function or the DVSYS.GET_FACTOR in the following ways:

• Oracle Database Vault rule expressions

• Custom application code that is available to all database sessions in an Oracle Database Vault environment

"Oracle Database Vault PL/SQL Factor Functions" describes DVF factor functions in detail.

If you had set the factor evaluation to By Session, then Oracle Database Vault retrieves the value from the session context established, as described under "How Factors Are Processed When a Session Is Established".

If you had set the factor evaluation to By Access, then Oracle Database Vault performs Step 2 through Step 5 (or Step 6), as described under "How Factors Are Processed When a Session Is Established", whenever the factor is retrieved.

If you had defined error options for the factor and if an error occurs, then Oracle Database Vault displays the error message.

How Factors Are Set

You can have a factor identity assigned at any time during a database session, but only if you have defined a factor assignment rule set and that rule set evaluates to true. You can do this in the application code by using the DVSYS.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 DVSYS.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 DVSYS.SET_FACTOR function.

About This Tutorial

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 regular 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 limit the use of SQL*Plus to only four users: the Database Vault Owner, the Database Vault Account Manager, SYSTEM, and SYS. 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. When you successfully complete this tutorial, then only the administrative users you specify should be able to connect to the database using SQL*Plus.

Step 1: Enable the SCOTT User Account

You must use the SCOTT account later on when you test the Oracle Database Vault components for this tutorial, so ensure that this account is active.

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. Check the status of the SCOTT account.

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

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

   ALTER USER SCOTT ACCOUNT UNLOCK IDENTIFIED BY password;
   

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

Step 2: Create the Module Factor

The Module factor uses the SYS_CONTEXT SQL function to find the names of the applications that are used to access the current instance of Oracle Database. As described previously, 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. See Oracle Database SQL Language Reference for more information about the SYS_CONTEXT function.

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. In the Administration page, select Factors.

   The Factors page appears.

3. Click Create to display the Create Factor page.

4. Enter the following information:

   • Name: Enter Module.

   • Description: Enter Factor to find applications that can access Oracle Database.

   • Factor Type: From the list, select Application.

   • Factor Identification: Select By Method.

   • Evaluation: Select By Access.

   • Factor Labeling: Select By Self.

   • Retrieval Method: Enter the following retrieval method:

     UPPER(SYS_CONTEXT('USERENV', 'MODULE'))
     

   • Validation Method: Leave blank.

   • Assignment Rule Set: From the list, select <Non Selected>.

   • Audit Options: Select Never.

   • Error Options: Select Show Error Message.

5. Click OK.

   Oracle Database Vault creates the factor. You now can query for the factor using the same syntax you would use to query the default factors, described "Oracle Database Vault PL/SQL Factor Functions".

6. In SQL*Plus, perform a quick test of the Module factor.

   For example:

   sqlplus lbrown_dvowner
   Enter password: password
   
   SELECT DVF.F$MODULE FROM DUAL;
   

   The following output should appear:

   F$MODULE
   -----------------------------
   SQLPLUS.EXE
   

   Do not exit SQL*Plus. You must use it later on when you test the factor components.

Step 3: Create the Limit SQL*Plus Access Rule and Rule Set

1. In Oracle Database Vault Administrator, return to the Administration page.

2. Under Administration, select Rule Sets.

   The Rule Sets page appears.

3. Click Create to display the Create Rule Set page.

4. Enter the following settings:

   • Name: Enter Limit SQL*Plus Access.

   • Description: Enter Rule set to limit access to SQL*Plus.

   • Status: Select Enabled.

   • Evaluation Options: Select All True.

   • Audit Options: Select Audit Disabled.

   • Error Handling Options: Select Show Error Message.

   • Fail Code, Fail Message: Leave blank.

   • Custom Event Handler Option: Select Handler Disabled.

   • Custom Event Handler Logic: Leave blank.

5. Click OK.

   The Rule Sets page appears.

6. Select the Limit SQL*Plus rule set and then click Edit.

   The Edit Rule Set page appears.

7. Under Rules Associated To The Rule Set, click Create.

   The Create Rule page appears.

8. Enter the following settings:

   • Name: Enter Prevent non-admin access to SQL*Plus.

   • Rule Expression: Enter the following rule expression:

     DVF.F$MODULE != 'SQL*PLUS' AND DVF.F$SESSION_USER IN ('LBROWN_DVOWNER', 'AMALCOLM_DVACCTMGR', 'SYS', 'SYSTEM')
     

     Replace LBROWN_DVOWNER and AMALCOLM_DVACCTMGR with the user account names that you use for the Database Vault Owner and Database Vault Account Manager accounts. You must enter the user account names in upper case letters, because that is how the database stores user account names.

     This expression tells Oracle Database Vault only to allow these four users to use SQL*Plus. Another way to write the expression is to tell Database Vault to simply exclude certain users from using SQL*Plus. That way, everyone else has access to SQL*Plus. For example, to exclude users JSMITH and TSMITH from using SQL*Plus, you would create this expression:

     DVF.F$MODULE != 'SQL*PLUS' AND DVF.F$SESSION_USER NOT IN ('JSMITH', 'TSMITH')
     

     However, for this tutorial, use the first expression, in which only the four administrative users are allowed to use SQL*Plus.

9. Ensure that you have entered this rule expression exactly as shown in Step 8. If you enter it incorrectly, you cannot log in to SQL*Plus.

10. Click OK.

Step 4: Create the CONNECT Command Rule

The CONNECT command rule controls the CONNECT SQL statement. It also applies to logging into SQL*Plus from the command line or other tools your site may use to access SQL*Plus.

1. In Oracle Database Vault, return to the Administration page.

2. Select Command Rules.

   The Command Rules page appears.

3. Click Create to display the Create Command Rule page.

4. Enter the following settings:

   • Command: Select CONNECT from the list.

   • Status: Select Enabled.

   • Object Owner, Object Name: Set to % so that the command rule applies to anyone who logs in.

   • Rule Set: Select Limit SQL*Plus Access from the list.

5. Click OK.

Step 5: Test the Ad Hoc Tool Access Restriction

You have been logged in to SQL*Plus all along, but note that you do not need to restart your SQL*Plus session in order for the Oracle Database Vault changes to take effect. They take effect right away.

1. In SQL*Plus, try to connect as user SCOTT:

   CONNECT SCOTT
   Enter password: password
   

   The following output should appear:

   ERROR:
   ORA-47400: Command Rule violation for CONNECT on LOGON
   
   Warning: You are no longer connected to ORACLE. 
   

   User SCOTT should be prevented from using SQL*Plus.

2. Now try to connect as user SYSTEM:

   CONNECT SYSTEM
   Enter password: password
   Connected. 
   

   User SYSTEM should be able to log in to SQL*Plus. So should SYS, the Database Vault Owner account, and the Database Vault Account Manager account.

If the Test Fails

If you cannot log in to SQL*Plus as SYSTEM (or as any of the other administrative users listed in your rule expression), then you are prevented from using both SQL*Plus and Oracle Database Vault Administrator. But do not fear, you can remedy the problem as follows:

1. Temporarily disable Oracle Database Vault.

   See Appendix B, "Disabling and Enabling Oracle Database Vault," for instructions on disabling Oracle Database Vault. After you disable Oracle Database Vault, you can log in to SQL*Plus.

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

   For example:

   CONNECT lbrown_dvowner
   Enter password: password
   

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

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

4. Exit SQL*Plus.

5. Reenable Oracle Database Vault.

   See Appendix B, "Disabling and Enabling Oracle Database Vault," for instructions on enabling Oracle Database Vault.

6. In Oracle Database Vault Administrator, check the rule expression for any errors and then correct them. Recreate the CONNECT command rule, and then test it.

Step 6: Remove the Components for This Tutorial

1. In Database Vault Administrator, return to the Administrator page.

2. Select Command Rules.

3. In the Command Rules page, select the CONNECT command rule, and then click Remove. Select Yes in the Confirmation page.

4. In the Administrator page, select Rule Sets.

5. In the Rule Sets page, select the Limit SQL*Plus Access rule set and click Remove. Select Yes in the Confirmation page.

6. In the Administration page, select Factors.

7. In the Factors page, select the Module factor, and then click Remove. Select Yes in the Confirmation page.

8. As the Database Vault Owner, log in to SQL*Plus and then remove the Prevent Non-admin access to SQL*Plus rule.

   For example:

   CONNECT lbrown_dvowner
   Enter password: password
   
   EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Prevent non-admin access to SQL*Plus');
    
   

9. If necessary, connect as the Oracle Database Vault Account Manager and then lock and expire the SCOTT account.

   For example:

   CONNECT amalcolm_dvacctmgr
   Enter password: password
   
   ALTER USER SCOTT ACCOUNT LOCK PASSWORD EXPIRE;
   

About This Tutorial

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.

Step 1: 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 amalcolm_dvacctmgr
   Enter password: password
   
   CREATE USER mwaldron IDENTIFIED BY password;
   

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

2. Connect as SYS using the SYSDBA privilege, and then grant user mwaldron DBA privileges.

   CONNECT SYS AS SYSDBA
   Enter password: password
   
   GRANT CREATE SESSION, DBA TO mwaldron;
   

Step 2: Add Identities to the Domain Factor

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. In the Administration page, select Factors.

   The Factors page appears.

3. Select the Domain factor and then select Edit.

   The Domain factor is the parent factor.

4. Under Identities, select Create.

5. In the Create Identity page, enter the following information:

   • Value: Enter HIGHLY SECURE INTERNAL NETWORK

   • Trust Level: Select Very Trusted

6. Click OK.

7. In the Edit Factor:Domain page, create a second identity called NOT SECURE, and then set its trust level to Untrusted.

Step 3: Map the Domain Factor Identities to the Client_IP Factor

1. In Oracle Database Vault Administrator, in the Edit Factor: Domain page, select the HIGHLY SECURE INTERNAL NETWORK identity and then select Edit.

2. Under Map Identity, select Create.

3. In the Create Identity Map page, enter the following information:

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

   • Map Condition: Select Equal, and then in the Low Value box, enter the IP address for the Virtual Machine (for example, 192.0.2.12). (This is the computer that user maldron 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.)

4. Click OK, and then click OK again to return to the Edit Factor: Domain page.

5. Create the following two identity maps for the NOT SECURE identity:

   	Child Factor Name	Operation Value	Operand 1	Operand 2
   	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.

6. Click OK to return to the Edit Factor: Domain page, then click OK again to return to the Factors page.

7. Test the factor identities.

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

   CONNECT mwaldron
   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.

Step 4: Create a Rule Set to Set the Hours and Select the Factor Identity

1. In Oracle Database Vault, return to the Administration page.

2. Select Rule Sets.

3. In the Rule Sets page, select Create.

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

5. Click OK.

6. In the Rule Sets page, select the Internal DBA Standard Working Hours rule set, and then select Edit.

7. In the Edit Rule Set: Internal DBA Standard Working Hours page, under Rules Associated To The Rule Set, select Create.

8. In the Create Rule page, create the following rules:

   • Name: Internal DBA

     Rule 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.)

   • 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 OK to return to the Rule Sets page.

Step 5: Create a Command Rule That Uses the Rule Set

1. In Oracle Database Vault Administrator, return to the Administration page.

2. Select Command Rules, and 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.

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

   Leave the remaining settings at their defaults.

4. Click OK.

Step 6: Test the Factor Identity Settings

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 December 14 2011, you would enter the following:

   su root
   Password: password
   
   date --set="14 DEC 2011 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 maldron 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 select from the OE.ORDERS table again.

   CONNECT mwaldron
   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.

Step 7: Remove the Components for This Tutorial

1. Log in to SQL*Plus as the DV_ACCTMGR user and drop user mwaldron.

   sqlplus amalcolm_dvacctmgr
   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 select Remove. In the Confirmation page, select Yes.

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

   In Oracle Database Vault Administrator, select Rule Sets in the Administration page. In the Rule Sets page, select the Internal DBA Standard Working Hours rule set, and then select Remove. In the Confirmation page, select Yes.

4. In SQL*Plus, delete the rules associated with the Internal DBA Standard Working Hours rule set.

   CONNECT lbrown_dvowner
   Enter password: password
   
   EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Internal DBA');
   EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Internal Network Only');
   EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Week Day');
   EXEC DVSYS.DBMS_MACADM.DELETE_RULE('Week Day Working Hours'); 
   COMMIT;
   

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

   Return to the Administration page and select Factors. Select the Domain factor, select Edit, and under Identities, remove the HIGHLY SECURE INTERNAL NETWORK and NOT SECURE factor identities. In the Confirmation page, select Yes.