1. Administrator's Guide
  2. Configuring Factors

7 Configuring Factors

Factors allow you to create and use complex attributes through PL/SQL to make Oracle Database Vault authorization decisions.

7.1 What Are Factors?

A factor is a named variable or attribute, such as a database IP address, that Oracle Database Vault can recognize.

You can use factors for activities such as authorizing database accounts to connect to the database or creating filtering logic to restrict the visibility and manageability of data.

Oracle Database Vault provides a selection of factors that lets you set controls on such components as the domain for your site, IP addresses, databases, and so on. You also can create custom factors, using your own PL/SQL retrieval methods. However, for the vast majority of cases, you can use the SYS_CONTEXT PL/SQL function to create rules on the most commonly used factors that are readily available in the database. Such factors as Session_User, Proxy_User, Network_Protocol, and Module are available through the SYS_CONTEXT function.

Factors have powerful capabilities that are used in conjunction with Oracle Label Security and for other database attributes that are not already available through context parameters. Commonly available factors are listed in this section, but Oracle recommends that you use the SYS_CONTEXT function in the rule definitions for these factors. Only create and use factors that are not already available through SYS_CONTEXT.

Note the following:

  • You can use factors in combination with rules in rule sets. The DVF factor functions are factor-specific functions that you can use in rule expressions.

  • Factors have values (identities) and are further categorized by their factor types.

  • You also can integrate factors with Oracle Label Security labels.

  • You can run reports on the factors that you create in Oracle Database Vault.

  • You only can create factors in a PDB, not in the CDB root or the application root.

Related Topics

Parent topic: Configuring Factors

7.2 Default Factors

Oracle Database Vault provides a set of default factors.

For each of these factors, there is an associated function that retrieves the value of the factor.

You can create custom factors by using your own PL/SQL retrieval methods. A useful PL/SQL function you can use (which is used for many of the default factors) is the SYS_CONTEXT SQL function, which retrieves data about the user session. For example, you can use the CLIENT_PROGRAM_NAME attribute of SYS_CONTEXT to find the name of the program used for the database session. After you create the custom factor, you can query its values similar to the functions used to query the default factors.

The default factors are as follows:

  • Authentication_Method is the method of authentication. In the list that follows, the type of user is followed by the method returned:

    • Password-authenticated enterprise user, local database user, user with the SYSDBA or SYSOPER administrative privilege using the password file; proxy with user name using password: PASSWORD

    • Kerberos-authenticated enterprise user or external user (with no administrative privileges): KERBEROS

    • Kerberos-authenticated enterprise user (with administrative privileges): KERBEROS_GLOBAL

    • Kerberos-authenticated external user (with administrative privileges): KERBEROS_EXTERNAL

    • Transport Layer Security (TLS)-authenticated enterprise or external user (with no administrative privileges): SSL (Transport Layer Security replaces Secure Sockets Layer, but SSL-related settings will work with Transport Layer Security.)

    • Transport Layer Security-authenticated enterprise user (with administrative privileges): SSL_GLOBAL

    • Transport Layer Security-authenticated external user (with administrative privileges): SSL_EXTERNAL

    • Radius-authenticated external user: RADIUS

    • OS-authenticated external user, or user with the SYSDBA or SYSOPER administrative privilege: OS

    • Proxy with certificate, DN, or username without using password: NONE

    • Background process (job queue secondary process): JOB

    • Parallel Query Slave (secondary) process: PQ_SLAVE

    For non-administrative connections, you can use the Identification_Type factor to distinguish between external and enterprise users when the authentication method is PASSWORD, KERBEROS, or SSL. For administrative connections, the Authentication_Method factor is sufficient for the PASSWORD, SSL_EXTERNAL, and SSL_GLOBAL authentication methods.

  • Client Identifier is an identifier that is set by the application through the DBMS_SESSION.SET_IDENTIFIER procedure, the Oracle Call Interface (OCI) attribute OCI_ATTR_CLIENT_IDENTIFIER, or Oracle Dynamic Monitoring Service (DMS). Various Oracle Database components use this attribute to identify lightweight application users who authenticate as the same database user.

  • Client_IP is the IP address of the machine from which the client is connected.

  • Database_Domain is the domain of the database as specified in the DB_DOMAIN initialization parameter.

  • Database_Hostname is the host name of the computer on which the instance is running.

  • Database_Instance is the instance identification number of the current instance.

  • Database_IP is the IP address of the computer on which the instance is running.

  • Database_Name is the name of the database as specified in the DB_NAME initialization parameter.

  • DBlink_Info is the source of a database link session. The string has this form:

    SOURCE_GLOBAL_NAME=dblink_src_global_name, DBLINK_NAME=dblink_name,SOURCE_AUDIT_SESSIONID=dblink_src_audit_sessionid

    In this specification:

    • dblink_src_global_name is the unique global name of the source database

    • dblink_name is the name of the database link on the source database

    • dblink_src_audit_sessionid source database that initiated source database that initiated the connection to the remote database using dblink_name

  • Domain is a named collection of physical, configuration, or implementation-specific factors in the run-time environment (for example, a networked IT environment or subset of it) that operates at a specific sensitivity level. You can identify a domain using factors such as host name, IP address, and database instance names of the Database Vault nodes in a secure access path to the database. Each domain can be uniquely determined using a combination of the factor identifiers that identify the domain. You can use these identifying factors and possibly additional factors to define the Maximum Security Label within the domain. This restricts data access and commands, depending on the physical factors about the Database Vault session. Example domains of interest may be Corporate Sensitive, Internal Public, Partners, and Customers.

  • Enterprise_Identity is the enterprise-wide identity for the user:

    • For enterprise users: the Oracle Internet Directory-distinguished name (DN).

    • For external users: the external identity (Kerberos principal name, Radius and DCE schema names, operating system user name, certificate DN).

    • For local users and SYSDBA and SYSOPER logins: NULL.

    The value of the attribute differs by proxy method:

    • For a proxy with DN: the Oracle Internet Directory DN of the client.

    • For a proxy with certificate: the certificate DN of the client for external users; the Oracle Internet Directory DN for global users.

    • For a proxy with user names: the Oracle Internet Directory DN if the client is an enterprise user; NULL if the client is a local database user.

  • Identification_Type is the way the user schema was created in the database. Specifically, it reflects the IDENTIFIED clause in the CREATE USER and ALTER USER syntax. In the list that follows, the syntax used during schema creation is followed by the identification type returned:

    • IDENTIFIED BY password: LOCAL

    • IDENTIFIED EXTERNALLY: EXTERNAL

    • IDENTIFIED GLOBALLY: GLOBAL SHARED

    • IDENTIFIED GLOBALLY AS DN: GLOBAL PRIVATE

    • GLOBAL EXCLUSIVE for exclusive global user mapping

    • GLOBAL SHARED for shared user mapping

    • NONE when the schema is created with no authentication

  • Lang is the ISO abbreviation for the language name, a shorter form than the existing LANGUAGE parameter.

  • Language is the language and territory your session currently uses, along with the database character set, in the following form: 

    language_territory.characterset

    For example: 

    AMERICAN_AMERICA.WE8MSWIN1252

  • Machine is the host name for the database client that established the current session. If you must find out whether the computer was used for a client or server session, then you can compare this setting with the Database_Hostname factor to make the determination.

  • Module is the application name (module) that is set through the DBMS_APPLICATION_INFO PL/SQL package or OCI.

  • Network_Protocol is the network protocol being used for communication, as specified in the PROTOCOL=protocol portion of the connect string.

  • Proxy_Enterprise_Identity is the Oracle Internet Directory DN when the proxy user is an enterprise user.

  • Proxy_User is the name of the database user who opened the current session on behalf of SESSION_USER.

  • Session_User is the database user name by which the current user is authenticated. This value remains the same throughout the session.

Related Topics

Parent topic: Configuring Factors

7.3 Creating a Factor

In general, to create a factor, you first create the factor itself, and then you edit the factor to include its identity.

This procedure explains how to create the factor only, not how to configure an identity for it.
  1. Connect to the PDB as a user who has been granted the DV_OWNER or DV_ADMIN role.
    For example: 
    CONNECT c##sec_admin_owen@pdb_name
Enter password: password

    To find the available PDBs, query the PDB_NAME column of the DBA_PDBS data dictionary view. To check the current container, run the show con_name command.

  2. If necessary, create a rule set that the factor will use.
    The DBA_DV_RULE_SET data dictionary view lists existing rule sets.
  3. Run the DBMS_MACADM.CREATE_FACTOR procedure to create the factor.
    For example: 
    BEGIN
 DBMS_MACADM.CREATE_FACTOR(
  factor_name       => 'Sector2_DB', 
  factor_type_name  => 'Instance', 
  description       => 'Factor to restrict DBA access', 
  rule_set_name     => 'Limit_DBA_Access', 
  get_expr          => 'UPPER(SYS_CONTEXT(''USERENV'',''DB_NAME''))', 
  validate_expr     => 'dbavowner.check_db_access', 
  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_OFF, 
  fail_options      => DBMS_MACUTL.G_FAIL_SILENTLY); 
END;
/

    In this specification:

    • factor_name can be up to 128 characters in mixed-case, without spaces. The the DBA_DV_FACTOR data dictionary view lists existing factors. This parameter is mandatory.
    • factor_type_name can be up to 128 characters in mixed-case, without spaces. The DBA_DV_FACTOR_TYPE data dictionary view lists existing factor types. This parameter is mandatory. The
      Factor types have a name and description and are used only to help classify factors. A factor type is the category name used to classify the factor. The default physical factor types include authentication method, host name, host IP address, instance identifiers, database account information, and others. You can create user-defined factor types, such as application name, certificate information, and so on in addition to the installed factor types, such as time and authentication method. If you want to find factors that are associated with a particular factor type, query the DBA_DV_FACTOR view. For example: 
      SELECT NAME FROM DBA_DV_FACTOR 
WHERE FACTOR_TYPE_NAME='Authentication Method';
    • description can have up to 1024 characters in mixed-case. This parameter is mandatory.
    • rule_set_name is the rule set name if you want to use a rule set to control when and how a factor identity is set. The DBA_DV_RULE_SET data dictionary view lists rules sets. This parameter is mandatory.

      This setting is particularly useful for situations where database applications, such as a Web application using a JDBC connection pool, must dynamically set a factor identity for the current database session. For example, a Web application may want to assign the geographic location for a database account logging in to the Web application. To do so, the Web application can use the JDBC Callable Statement, or Oracle Data Provider for .NET (ODP.NET) to run the PL/SQL function SET_FACTOR, for example: 

      BEGIN 
 SET_FACTOR('GEO_STATE','VIRGINIA');
END;

      Then you can create an assignment rule for the GEO_STATE factor to allow or disallow the setting of the GEO_STATE factor based on other factors or rule expressions.

    • get_expr is a valid PL/SQL expression that retrieves the identity of a factor. It can use up to 255 characters in mixed-case. The following retrieval method sets a value of the DB_NAME factor by retrieving the database name (DB_NAME) from the USERENV namespace in a user's session: 
      UPPER(SYS_CONTEXT('USERENV','DB_NAME'))
    • validate_expr is a valid PL/SQL expression that returns a Boolean value (TRUE or FALSE) to validate the identity of the factor being retrieved (with the GET_FACTOR function) or the value to be assigned to a factor (with the SET_FACTOR function). It can have up to 255 characters and be in mixed case. This parameter is mandatory.

      If the method is evaluated to false for the value being retrieved or to be assigned, then the factor identity is set to null. This feature provides an additional level of assurance that the factor is properly retrieved and set. You can include any package function or standalone function in the expression. Ensure that the expression is a fully qualified function, such as schema.function_name. Do not include complete SQL statements. If you are using application packages or functions, then you must provide DVSYS with the EXECUTE privilege on the object.

      The PL/SQL expression can use either of these formats:

      • FUNCTION IS_VALID RETURN BOOLEAN

        In this form, you can use the DVF.F$factor_name function inside the function logic. This is more appropriate for factors that are evaluated by session.

      • FUNCTION IS_VALID(p_factor_value VARCHAR2) RETURN BOOLEAN

        In this form, the factor value is passed to the validation function directly. This is more appropriate for factors that are evaluated by access. It is also valid for factors evaluated by session.

    • identify_by can be one of the following options for determining the identity of a factor, based on the expression set for the get_expr parameter:
      • DBMS_MACUTL.G_IDENTIFY_BY_CONSTANT: By constant
      • DBMS_MACUTL.G_IDENTIFY_BY_METHOD: By method. For example, suppose the expression retrieves the system date: to_char(sysdate,'yyyy-mm-dd'). On December 15, 2020, the following value would be returned: 2020-12-15
      • DBMS_MACUTL.G_IDENTIFY_BY_FACTOR: By factor. This setting determines the factor identity by mapping the identities of the child factor to its parent factor. A parent factor is a factor whose values are resolved based on a second factor, called a child factor. To establish their relationship, you map their identities. (You do not need to specify the get_expr parameter for this option.)
      • DBMS_MACUTL.G_IDENTIFY_BY_CONTEXT: By context
    • labeled_by controls how the factor identity retrieves an Oracle Label Security (OLS) label. This parameter is mandatory if you are using the Oracle Label Security integration.
      • DBMS_MACUTL.G_LABELED_BY_SELF labels the identities for the factor directly from the labels associated with an Oracle Label Security policy (default)
      • DBMS_MACUTL.G_LABELED_BY_FACTORS derives the factor identity label from the labels of its child factor identities.
    • eval_options evaluate the factor when the user logs on. This parameter is mandatory.
      • DBMS_MACUTL.G_EVAL_ON_SESSION evaluates the factor when the database session is created (default). Be aware that this setting may affect performance of the factor.
      • DBMS_MACUTL.G_EVAL_ON_ACCESS evaluates the factor each time the factor is accessed.
      • DBMS_MACUTL.G_EVAL_ON_STARTUP evaluates the factor on start-up.
    • audit_options applies only to traditional auditing, not unified auditing environments. Starting with Oracle Database release 21c, traditional auditing is deprecated. Oracle recommends that you create unified audit policies instead of using audit_options. Valid options for audit_options are as follows:
      • DBMS_MACUTL.G_AUDIT_OFF disables auditing
      • DBMS_MACUTL.G_AUDIT_ALWAYS always audits.
      • DBMS_MACUTL.G_AUDIT_ON_GET_ERROR audits if get_expr returns an error.
      • DBMS_MACUTL.G_AUDIT_ON_GET_NULL audits if get_expr is null.
      • DBMS_MACUTL.G_AUDIT_ON_VALIDATE_ERROR audits if the validation procedure returns an error.
      • DBMS_MACUTL.G_AUDIT_ON_VALIDATE_FALSE audits if the validation procedure is false.
      • DBMS_MACUTL.G_AUDIT_ON_TRUST_LEVEL_NULL audits if there is no trust level set.
      • DBMS_MACUTL.G_AUDIT_ON_TRUST_LEVEL_NEG audits if the trust level is negative.
    • fail_options sets options for reporting factor errors.
      • DBMS_MACUTL.G_FAIL_WITH_MESSAGE shows an error message (default).
      • DBMS_MACUTL.G_FAIL_SILENTLY does not show an error message.
    At this stage, the factor is complete and can be used. For more detailed and customized processing, you can configure an identity for the factor.

Related Topics

Parent topic: Configuring Factors

7.4 Adding an Identity to a Factor

After you create a new factor, you optionally can add an identity to it.

Parent topic: Configuring Factors

7.4.1 About Factor Identities

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 get_expr parameter (to retrieve the identity of a factor) and the identify_by parameter (to determine the identify of the factor) in the DBMS_MACADM.CREATE_FACTOR procedure. 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

Parent topic: Adding an Identity to a Factor

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

A factor can have several identities depending on its retrieval method or its identity mapping logic. For example, a factor such as Database_Hostname could have multiple identities in an Oracle Real Application Clusters environment; a factor such as Client_IP can have multiple identities in any database environment. The retrieval method for these types of factors may return different values because the retrieval method is based on the database session. Several reports allow you to track the factor identity configuration.

You can configure the assignment of a factor in the following ways:

  • Assign the factor at the time a database session is established.

  • Configure individual requests to retrieve the identity of the factor.

With the Oracle Label Security integration, you can label identities with an Oracle Label Security label. You can also assign an identity trust levels, which are numbers that indicate the magnitude of trust relative to other identities for the same factor. In general, the higher the trust level number is set, the greater the trust. Negative trust levels are not trusted.

Within a database session, a factor assigned identity is available to Oracle Database Vault and any application with a publicly accessible PL/SQL function that exists in the DVF schema (which contains functions that retrieve factor values) as follows:

dvf.f$factor_name

This allows the identifier for a factor to be accessed globally from within the Oracle database (using PL/SQL, SQL, Oracle Virtual Private Database, triggers, and so on). For example, in SQL*Plus:

CONNECT sec_admin_owen@pdb_name
Enter password: password	

SELECT DVF.F$DATABASE_IP FROM DUAL;

Output similar to the following appears:

SELECT DVF.F$DATABASE_IP FROM DUAL;

F$DATABASE_IP
-------------------------------------------------------------
192.0.2.1

You can also use the GET_FACTOR function to find the identity of a factor that is made available for public access. For example: 

SELECT GET_FACTOR('DATABASE_IP') FROM DUAL;

The following output appears:

GET_FACTOR('DATABASE_IP')
-------------------------------------------------------------
192.0.2.1

Related Topics

Parent topic: Adding an Identity to a Factor

7.4.3 About Trust Levels

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, the Network factor identity for VPN is trusted (value equals 5), and the identity for the INTRANET domain is 10, which implies a greater trust.

Related Topics

Parent topic: Adding an Identity to a Factor

7.4.4 About Label Identities

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. In the DBMS_MACADM.CREATE_FACTOR or DBMS_MACADM.UPDATE_FACTOR procedure, the labeled_by parameter setting determines whether a factor is labeled DBMS_MACUTL.G_LABELED_BY_SELF or DBMS_MACUTL.G_LABELED_BY_FACTORS. If you set labeled_by to DBMS_MACUTL.G_LABELED_BY_SELF, then you can associate OLS labels with the factor identities. If you set labeled_by to DBMS_MACUTL.G_LABELED_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.

Related Topics

Parent topic: Adding an Identity to a Factor

7.4.5 Creating and Configuring a Factor Identity

You can create and configure a factor identity for an existing factor.

  1. Connect to the PDB as a user who has been granted the DV_OWNER or DV_ADMIN role.
  2. Run the DBMS_MACADM.CREATE_IDENTITY procedure.
    For example: 
    BEGIN
 DBMS_MACADM.CREATE_IDENTITY(
  factor_name  => 'Sector2_ClientID', 
  value        => 'intranet', 
  trust_level  => 5); 
END;
/

    In this specification:

    • factor_name is the name of the existing factor. The DBA_DV_FACTOR data dictionary view lists factors.
    • value is the value of the factor, up to 1024 characters in mixed-case. For example, the identity of an IP_Address factor could be the IP address of 192.0.2.12.
    • trust_level indicates the magnitude of trust relative to other identities for the same factor. In general, the higher the trust level number is set, the greater the trust. A trust level of 10 indicates "very trusted." Negative trust levels are not trusted.
      • 10 is very trusted.
      • 5 is trusted.
      • 1 is somewhat trusted.
      • -1 is untrusted.
      • NULL is for a trust level that is not defined (default)
After you create a factor identity, you can use it in an identity map with two existing factors.

Related Topics

Parent topic: Adding an Identity to a Factor

7.4.6 Using Identity Mapping to Configure an Identity to Use Other Factors

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

Parent topic: Adding an Identity to a Factor

7.4.6.1 About Identity Mapping

While you are creating a factory 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, you can run the Identity Configuration Issues report.

You can map different identities of a parent factor to different identities of the contributing factor. For example, an INTRANET identity maps to an IP address range of 192.0.2.1 to 192.0.2.24. A 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).

If you need to change the identity mapping, you must delete and then recreate the identity map.

7.4.6.2 Mapping an Identity to a Factor

You can map an identity to a factor by creating a parent-child relationship with two factors.

  1. Connect to the PDB as a user who has been granted the DV_OWNER or DV_ADMIN role.
  2. Ensure that you have created the factors and factor identities that you that you plan to use for the mapping.
    The DBA_DV_FACTOR data dictionary view lists the existing factors. The DBA_DV_IDENTITY data dictionary view lists the existing factor identities.
  3. Run the DBMS_MACADM.CREATE_IDENTITY_MAP procedure to create the identity map.
    For example: 
    BEGIN
 DBMS_MACADM.CREATE_IDENTITY_MAP(
  identity_factor_name  => 'Sector2_ClientID',
  identity_factor_value => 'intranet', 
  parent_factor_name    => 'HQ_ClientID', 
  child_factor_name     => 'Div1_ClientID', 
  operation             => '<', 
  operand1              => '192.0.2.50', 
  operand2              => '192.0.2.100');
END;
/

    In this specification:

    • identity_factor_name is the factor to be used for the identity map.
    • identity_factor_value is value the factor assumes if the identity map evaluates to TRUE.
    • parent_factor_name is the parent factor link to which the map is related. The DBA_DV_IDENTITY_MAP data dictionary view lists existing parent-child factor mappings.
    • child_factor_name is the child factor link to which the map is related.
    • operation is a relational operator for the identity map (for example, <, >, =, between, and so on).
    • operand1 is the left operand for the relational operator and refers to the low value you enter.
    • operand2 is the right operand for the relational operator and refers to the high value you enter.

    For example, consider a scenario where the child factor is set to Client_IP, operation is set to between, operand1 is set to 192.0.2.1, and operand2 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).

  4. Repeat this process 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.

7.4.6.3 Deleting an Identity Map

To remove the parent-child relationship between two factors, you must delete the identity map.

  1. Connect to the PDB as a user who has been granted the DV_OWNER or DV_ADMIN role.
  2. Query the DBA_DV_FACTOR_LINK data dictionary view to find the factors that have been used in parent-child mappings.
    For example:
    SELECT PARENT_FACTOR_NAME, CHILD_FACTOR_NAME FROM DBA_DV_FACTOR_LINK;

PARENT_FACTOR_NAME             CHILD_FACTOR_NAME
------------------------------ ------------------------------
Domain                         Database_Instance
Domain                         Database_IP
Domain                         Database_Hostname
  3. Query the DBA_DV_IDENTITY_MAP data dictionary view to find the definition of the mapping that you want to remove.
  4. Based on the definition of the mapping, run the DBMS_MACADM.DELETE_IDENTITY_MAP procedure.
    For example: 
    BEGIN
 DBMS_MACADM.DELETE_IDENTITY_MAP(
  identity_factor_name  => 'intranet-factor',
  identity_factor_value => 'intranet', 
  parent_factor_name    => 'Domain', 
  child_factor_name     => 'Database_IP', 
  operation             => 'between', 
  operand1              => '192.0.2.22', 
  operand2              => '192.0.2.99');
END;
/

7.4.7 Modifying a Factor Identity

You can use the DBMS_MACADM.UPDATE_IDENTITY procedure to modify a factor identity.

  1. Connect to the PDB as a user who has been granted the DV_OWNER or DV_ADMIN role.
  2. Find the factor identity and check its definition.
    For example:
    SELECT * FROM DBA_DV_IDENTITY ORDER BY FACTOR_NAME;
  3. Run the DBMS_MACADM.UPDATE_IDENTITY statement.
    For example: 
    BEGIN
 DBMS_MACADM.UPDATE_IDENTITY(
  factor_name  => 'Sector2_ClientID', 
  value        => 'intranet', 
  trust_level  => 7); 
END;
/

Related Topics

Parent topic: Adding an Identity to a Factor

7.4.8 Deleting a Factor Identity

Before delete a factor identity, you must remove references to it.

  1. Connect to the PDB as a user who has been granted the DV_OWNER or DV_ADMIN role.
  2. Query the DBA_DV_IDENTITY data dictionary view to find the factor identity to remove.
    For example: 
    SELECT * FROM DBA_DV_IDENTITY ORDER BY FACTOR_NAME;
  3. Run the DBMS_MACADM.DELETE_IDENTITY procedure.
    You must include the factor_name and value parameters. For example: 
    BEGIN
 DBMS_MACADM.DELETE_IDENTITY(
  factor_name => 'Sector2_ClientID', 
  value       => 'intranet'); 
END;
/

Related Topics

Parent topic: Adding an Identity to a Factor

7.5 Modifying a Factor

You can use the DBMS_MACADM.UPDATE_FACTOR procedure to modify the definition of a factor.

  1. Connect to the PDB as a user who has been granted the DV_OWNER or DV_ADMIN role.
    For example: 
    CONNECT c##sec_admin_owen@pdb_name
Enter password: password

    To find the available PDBs, query the PDB_NAME column of the DBA_PDBS data dictionary view. To check the current container, run the show con_name command.

  2. Find the factor and check its definition.
    For example:
    SELECT * FROM DBA_DV_FACTOR ORDER BY NAME;
  3. Run the DBMS_MACADM.UPDATE_FACTOR statement.
    For example: 
    BEGIN
 DBMS_MACADM.UPDATE_FACTOR(
  factor_name       => 'Sector2_DB', 
  factor_type_name  => 'Instance', 
  description       => 'Factor to restrict DBA access in Sector2_DB', 
  rule_set_name     => 'Limit_DBA_Access', 
  get_expr          => 'UPPER(SYS_CONTEXT(''USERENV'',''DB_NAME''))', 
  validate_expr     => 'dbavowner.check_db_access', 
  identify_by       => DBMS_MACUTL.G_IDENTIFY_BY_METHOD, 
  labeled_by        => DBMS_MACUTL.G_LABELED_BY_SELF, 
  eval_options      => DBMS_MACUTL.G_EVAL_ON_ACCESS, 
  audit_options     => DBMS_MACUTL.G_AUDIT_ALWAYS, 
  fail_options      => DBMS_MACUTL.G_FAIL_WITH_MESSAGE); 
END;
/

Related Topics

Parent topic: Configuring Factors

7.6 Deleting a Factor

Before you delete a factor, you must remove references to the factor.

  1. Connect to the PDB as a user who has been granted the DV_OWNER or DV_ADMIN role.
    For example: 
    CONNECT c##sec_admin_owen@pdb_name
Enter password: password

    To find the available PDBs, query the PDB_NAME column of the DBA_PDBS data dictionary view. To check the current container, run the show con_name command.

  2. Query the DBA_DV_FACTOR data dictionary to find the name of the factor to delete.
    For example: 
    SELECT NAME FROM DBA_DV_FACTOR ORDER BY NAME;
  3. Query the DBA_DV_FACTOR_LINK data dictionary to find if the factor is a parent or a child factor.
    For example, assuming the factor is named Sector2_DB:
    SELECT PARENT_FACTOR_NAME, CHILD_FACTOR_NAME 
FROM DBA_DV_FACTOR_LINK
WHERE PARENT_FACTOR_NAME = 'Sector2_DB'
OR CHILD_FACTOR_NAME = 'Sector2_DB';
  4. If the factor is a parent or child factor, then delete the factor link.
    For example:
    BEGIN
 DBMS_MACADM.DELETE_FACTOR_LINK(
  parent_factor_name => 'Sector2_DB', 
  child_factor_name  => 'Div1_ClientID'); 
END;
/
  5. Query the DBA_DV_IDENTITY_MAP data dictionary view to find the definition for any identity maps that may use the factor.
    For example: 
    SELECT * FROM DBA_DV_IDENTITY_MAP
WHERE FACTOR_NAME = 'Sector2_DB';
  6. Run the DBMS_MACADM.DELETE_IDENTITY_MAP to delete the identity map.
    For example: 
    BEGIN
 DBMS_MACADM.DELETE_IDENTITY_MAP(
  identity_factor_name  => 'Sector2_DB',
  identity_factor_value => 'intranet', 
  parent_factor_name    => 'HQ_ClientID', 
  child_factor_name     => 'Div1_ClientID', 
  operation             => '<', 
  operand1              => '192.0.2.10', 
  operand2              => '192.0.2.15');
END;
/
  7. Query the DBA_DV_IDENTITY data dictionary view to find if the factor has a reference to any factor identities.
    Query for the factor name and the value. For example: 
    SELECT VALUE FROM DBA_DV_IDENTITY 
WHERE FACTOR_NAME = 'Sector2_DB'
  8. Run the DBMS_MACADM.DELETE_IDENTITY procedure to remove the factor reference.
    You must include both the factor_name and value parameters. For example: 
    BEGIN
 DBMS_MACADM.DELETE_IDENTITY(
  factor_name => 'Sector2_DB', 
  value       => 'intranet'); 
END;
/
  9. Run the DBMS_MACADM.DELETE_FACTOR to delete the factor.
    For example: 
    EXEC DBMS_MACADM.DELETE_FACTOR('Sector2_DB');

Related Topics

Parent topic: Configuring Factors

7.7 How Factors Work

Oracle Database Vault processes factors when a session is established.

Parent topic: Configuring Factors

7.7.1 How Factors Are Processed When a Session Is Established

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.

Note:

Be careful about associating command rules with the CONNECT event, because you can inadvertently lock out other users from of the database. In general, if you create a command rule for CONNECT, set its evaluation option of the associated rule set to Any True.

If you do inadvertently lock out users, then you should temporarily disable Oracle Database Vault, disable the CONNECT command rule, re-enable Oracle Database Vault, and then fix the factor code that is causing the problem. If the Test Fails provides an example of how to accomplish this.

Parent topic: How Factors Work

7.7.2 How Retrieval Methods Work

The Retrieval Method identifies factors where the factor identification is by method or constant.

If the factor identification is by factors, Oracle Database Vault identifies it by its identity mappings. You can create your own PL/SQL retrieval methods, or use the functions supplied with Oracle Database Vault. Oracle Database Vault provides factor-specific and general utility functions that you can use to build the retrieval method.

See also the default factors provided with Oracle Database Vault for examples of retrieval methods.

The get_expr parameter is mandatory if you have selected the following DBMS_MACADM.CREATE_FACTOR or DBMS_MACADM.CREATE_UPDATE settings for the identify_by parameter:

  • DBMS_MACUTL.G_IDENTIFY_BY_METHOD: Enter a method for the get_expr parameter.

  • DBMS_MACUTL.G_IDENTIFY_BY_CONSTANT: Enter a constant for the get_expr parameter.

The value returned as the factor identity must be a VARCHAR2 string or otherwise convertible to one.

You can include any package function or standalone function in the expression. Ensure that the expression is a fully qualified function, such as schema.function_name. Do not include complete SQL statements. If you are using application packages or functions, you must provide DVSYS with the EXECUTE privilege on the object.

Write the function signature using the following format: 

FUNCTION GET_FACTOR RETURN VARCHAR2

Related Topics

Parent topic: How Factors Work

7.7.3 How Factors Are Retrieved

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 .

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

Example 7-1 Using GET_FACTOR to Retrieve a Factor

SELECT GET_FACTOR('client_ip') FROM DUAL;

You can use the factor values retrieved from the DVF factor function or the 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

If you had set the DBMS_MACADM.CREATE_FACTOR or DBMS_MACADM.UPDATE_FACTOR eval_options parameter to factor evaluation to DBMS_MACUTL.G_EVAL_ON_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 DBMS_MACUTL.G_EVAL_ON_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.

Parent topic: How Factors Work

7.7.4 How Factors Are Set

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.

Parent topic: How Factors Work

7.7.5 How Factor Auditing Works

Whether you have unified auditing enabled affects how auditing is handled for factors.

In a traditional, non-unified auditing environment, Oracle Database Vault writes the audit trail to the DVSYS.AUDIT_TRAIL$ table. Be aware that traditional auditing is deprecated starting with Oracle Database release 21c.

If you have enabled unified auditing, then this setting does not capture audit records. Instead, you can create unified audit policies to capture this information.

You can use the Factor Audit Report to display the generated audit records. In addition, you can select multiple audit options at a time. Each option is converted to a bit mask and added to determine the aggregate behavior. Note that there is little performance impact in auditing, unless the factor has errors.

Related Topics

Parent topic: How Factors Work

7.8 Tutorial: Preventing Ad Hoc Tool Access to the Database

This tutorial demonstrates how to use factors to prevent ad hoc tools (such as SQL*Plus) from accessing the database.

Parent topic: Configuring Factors

7.8.1 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 they 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.

Related Topics

Parent topic: Tutorial: Preventing Ad Hoc Tool Access to the Database

7.8.2 Step 1: Enable the HR and OE User Accounts

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 PDB as a user who has been granted the DV_ACCTMGR role.

    For example: 

    sqlplus accts_admin_ace@pdb_name
Enter password: password

    To find the available PDBs, query the PDB_NAME column of the DBA_PDBS data dictionary view. To check the current container, 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;

    Replace password with a password that meets the password complexity requirements of the user's profile.

  4. Repeat these steps for the OE account.

Related Topics

Parent topic: Tutorial: Preventing Ad Hoc Tool Access to the Database

7.8.3 Step 2: Create the Factor

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

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

    For example: 

    CONNECT sec_admin_owen@pdb_name
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_OFF,
  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.

Parent topic: Tutorial: Preventing Ad Hoc Tool Access to the Database

7.8.4 Step 3: Create the Rule Set and Rules

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)
  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;
/
  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.

Parent topic: Tutorial: Preventing Ad Hoc Tool Access to the Database

7.8.5 Step 4: Create the CONNECT Command Rule

The CONNECT command rule controls the CONNECT SQL statement.

This command rule also applies to logging into SQL*Plus from the command line or other tools your site may use to access SQL*Plus.

  • Create the CONNECT command rule as follows:

    BEGIN
 DBMS_MACADM.CREATE_COMMAND_RULE(
  command         => 'CONNECT',
  rule_set_name   => 'Limit SQL*Plus Access',
  object_owner    => '%',
  object_name     => '%',
  enabled         => DBMS_MACUTL.G_YES);
END;
/

In this specification:

  • rule_set_name associates the Limit SQL*Plus Access rule set with the CONNECT command rule.

  • object_owner is set to % so that the command rule applies to all users.

  • object_name is set to % so that the command rule applies to all objects.

  • enabled enables the command rule so that it can be used right away.

Parent topic: Tutorial: Preventing Ad Hoc Tool Access to the Database

7.8.6 Step 5: Test the Ad Hoc Tool Access Restriction

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

  1. In SQL*Plus, try to connect to the PDB as user HR: 

    CONNECT HR@pdb_name
Enter password: password

    The following output should appear:

    ERROR:
ORA-47306: 20461: Limit SQL*Plus Access rule set failed

    User HR should be prevented from using SQL*Plus.

  2. Next, try to connect as user OE: 

    CONNECT OE@pdb_name
Enter password: password

    The following output should appear:

    ERROR:
ORA-47306: 20461: Limit SQL*Plus Access rule set failed

    User OE also should be prevented from using SQL*Plus.

  3. Now try to connect as user SYSTEM: 

    CONNECT SYSTEM@pdb_name
Enter password: password
Connected.

    User SYSTEM should be able to log in to the database instance. 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 the database instance as SYSTEM (or as any of the other administrative users listed in your rule expression), then you are prevented from using SQL*Plus.

You can remedy the problem as follows:

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

    For example: 

    CONNECT sec_admin_owen@pdb_name
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.

Parent topic: Tutorial: Preventing Ad Hoc Tool Access to the Database

7.8.7 Step 6: Remove the Components for This Tutorial

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 accts_admin_ace@pdb_name
Enter password: password

ALTER USER HR ACCOUNT LOCK;
ALTER USER OE ACCOUNT LOCK;

Parent topic: Tutorial: Preventing Ad Hoc Tool Access to the Database

7.9 Guidelines for Designing Factors

Oracle provides guidelines for designing factors.

  • You can use the Oracle utility packages such as UTL_TCP, UTL_HTTP, DBMS_LDAP, and DBMS_PIPE to integrate security or other contextual information about the session from external systems.

  • Do not specify a retrieval method (using the get_expr parameter in DBMS_MACADM.CREATE_FACTOR or DBMS_MACADM.UPDATE_FACTOR) if the identify_by parameter is set to DBMS_MACUTL.G_IDENTIFY_BY_FACTOR. Retrieval methods are only needed if you set the factor to DBMS_MACUTL.G_IDENTIFY_BY_CONSTANT or DBMS_MACUTL.G_IDENTIFY_BY_METHOD.

  • Consider using a validation method if a factor has an assignment rule set. Doing so helps to verify that invalid identities are not submitted.

  • Use the client-supplied factors such as Program, OS User, and others with caution, because the values that are supplied can only be trusted when the client software is trusted and the communications channel from the client software is known to be secure.

  • Only specify an evaluation option eval_options) of DBMS_MACUTL.G_EVAL_ON_ACCESS if the value returned by the retrieval method could change from one invocation to the next in the same session (for example, time-based factors).

  • Optimize the internal logic of a function used for the factor retrieval method using traditional SQL and PL/SQL optimization techniques.

  • If the discrete values returned by the retrieval method are known, be sure to define identities for each value so that you can assign trust levels for them. Trust levels add value to factors as you also can use the trust level in application logic based on factors.

  • A security policy based on more factors is generally considered stronger than one based on fewer factors. You can create a new factor that is identified by other factors to store combinations of factors into logical grouping using identity maps. This also makes it easier to label the parent factor when you integrate the factors with the Oracle Label Security labels.

  • It is generally easier to configure and debug a factor whose labeled_by parameter is set to DBMS_MACUTL.G_LABELED_BY_SELF than one labeled DBMS_MACUTL.G_LABELED_BY_FACTORS when integrating the Oracle Label Security.

  • You can design a database client application to pass one or more security, end-user, or environmental attributes so that they are available to an associated database session. To do this, create a single factor for each attribute and then use an assignment rule set to control when these attributes can be assigned (for example only when using a specific Web application on specified named application server computers). Oracle Database Vault factors used in this fashion are very much like the Oracle procedure DBMS_SESSION.SET_IDENTIFIER but also include a capability to control when they can be set.

Related Topics

Parent topic: Configuring Factors

7.10 How Factors Affect Performance

The complexity of factors affects the performance of your Oracle database instance.

Each factor has elements that are processed, such as its validation method, trust level, and so on. For factors that are evaluated by the session, such as Database_Hostname and Proxy_User, Oracle Database Vault performs this processing during session initialization, and then caches the results for subsequent requests for that value.

The default factors are cached because they are likely candidates for a typical security policy. However, if you only use five factors (for example, in rule sets or other components), then the other factors consume resources that could otherwise be used elsewhere. In this case, you should remove the unnecessary factors by deleting them. (Oracle Database Vault does not use any of these factors internally, so you can remove them if you do not need them.)

If you have a large number of users or if your application server frequently must create and destroy connections, the resources used can affect system performance. You can delete the unnecessary factors.

You can check system performance by running tools such as Oracle Enterprise Manager (including Oracle Enterprise Manager Cloud Control, which is installed by default with Oracle Database), Automatic Workload Repository (AWR), and TKPROF.

Related Topics

Parent topic: Configuring Factors

7.11 Factor Related Reports and Data Dictionary Views

Oracle Database Vault provides reports and data dictionary views that display information about factors and their identities.

Table 7-1 lists the Oracle Database Vault reports.

Table 7-1 Reports Related to Factors and Their Identities

Report Description

Factor Audit Report

Audits factors (for example, to find factors that failed to be evaluated)

Factor Configuration Issues Report

Lists configuration issues, such as disabled or incomplete rule sets, or to audit issues that may affect the factor

Factor Without Identities Report

Lists factors that have had no identities assigned yet

Identity Configuration Issues Report

Lists factors that have invalid label identities or no map for the identity

Rule Set Configuration Issues Report

Lists rule sets that have no rules defined or enabled, which may affect the factors that use them

Table 7-2 lists data dictionary views that provide information about existing factors and factor identities.

Table 7-2 Data Dictionary Views Used for Factors and Factor Identities

Data Dictionary View Description

DBA_DV_FACTOR

Lists the existing factors in the current database instance

DBA_DV_FACTOR_LINK

Shows the relationships of each factor whose identity is determined by the association of child factors

DBA_DV_FACTOR_TYPE

Lists the names and descriptions of factor types used in the system

DBA_DV_IDENTITY

Lists the identities for each factor

DBA_DV_IDENTITY_MAP

Lists the mappings for each factor identity

Related Topics

Parent topic: Configuring Factors