The Geek Diary

Extend rule sets by using factors in Oracle Database Vault

by

Using Factors

Factors are evaluated at the session-level. Each session that accesses the factor can have a different identity (value). For example, the Client_IP factor evaluates to the IP address of the client machine for each session. 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.

Database Vault provides a selection of factors that enable you to set controls on such components as your site’s domain, IP addresses, and databases. You can configure factors by using Cloud Control or the Database Vault APIs. You can create custom factors or customize the existing factors. Custom factors can be created by using your own PL/SQL retrieval methods. The USERENV variables of the SYS_CONTEXT function have been used for many default factors.

Factors can be used in rule sets as inputs to a conditional statement. A PL/SQL function is created for each factor with the name F$[factor_name] in the publicly available DVF schema. This function may be used in rules where a PL/SQL expression is required.

Predefined Factors

A set of predefined factors is automatically assigned values for each session. These factors can be used to create additional factors, or they can be customized for your site.

  • Client_IP: Returns the IP address of a client session if the client connects through the listener. Otherwise, the returned value is NULL.
  • Database_Hostname: Returns the host name of the database as seen in the V$INSTANCE view.
  • Proxy_User: Name of the database user who opened the current session on behalf of SESSION_USER.
  • Authentication_Method: Returns PASSWORD, KERBEROS, SSL, RADIUS, OS, or DCE, depending on the method of authentication. Proxy with certificate, distinguished name (DN), or username without using password returns NONE. You can use Identification_type to distinguish between external and enterprise users when the authentication method is Password, Kerberos, or SSL.
  • Database_Domain: Domain of the database as specified in the DB_DOMAIN initialization parameter.
  • Database_Instance: Returns the instance identifier as seen in the USERENV context • Database_IP: Returns the IP address of the database server on the basis of the hostname of the server.
  • Database_Name: Name of the database as specified in the DB_NAME initialization parameter.
  • Domain: Domain is a factor that does not have a predefined identity or method. It can be configured for your site. It is intended to be a named collection of physical factors, or configuration-specific or implementation-specific factors in the run-time environment. A domain can be identified via a number of factors, such as the host name, IP address, and database instance names. Each domain can be uniquely determined by using a combination of factor identifiers that identify the domain. These identifying factors and possibly additional factors can be used to define Maximum Security Label within the domain, restricting data access and commands, depending on the physical factors of the Database Vault session. Examples of domains of interest are Corporate Sensitive, Internal Public, Partners, and Customers.
  • Enterprise_Identity: The user’s enterprise-wide identity. For enterprise users, this returns the Oracle Internet Directory DN. For external users, this returns the external identity (Kerberos principal name, Radius and DCE schema names, OS username, and Certificate DN). For local users and SYSDBA and SYSOPER logins, this returns NULL. The value of the attribute differs by proxy method. For a proxy with DN, this returns the Oracle Internet Directory (OID) DN of the client. For a proxy with certificate, this returns the certificate DN of the client for external users. For global users, this returns the OID DN. For a proxy with username, this returns the OID DN if the client is an enterprise user and NULL if the client is a local database user.
  • Identification_Type: Returns the way the user’s schema was created in the database. Specifically, it reflects the IDENTIFIED clause in the CREATE/ALTER USER syntax. The syntax used during the schema creation is followed by the identification type returned. The IDENTIFIED BY password returns LOCAL. IDENTIFIED EXTERNALLY returns EXTERNAL. IDENTIFIED GLOBALLY returns GLOBAL SHARED. IDENTIFIED GLOBALLY AS DN returns GLOBAL PRIVATE.
  • Lang: The International Organization for Standardization (ISO) abbreviation for the language name, a shorter form than the existing LANGUAGE parameter.
  • Language: The language and territory currently used by your session, along with the database character set, in this form: language_territory.characterset.
  • Machine: Provides the client machine name for the current session.
  • Network_Protocol: Returns the network protocol being used for communication, as specified in the PROTOCOL=protocol portion of the connect string.
  • Proxy_Enterprise_Identity: Returns the OID DN when the proxy user is an enterprise user.
  • Session_User: For enterprise users, this returns the schema. This is the database user name by which the current user is authenticated. This value remains the same throughout the duration of the session.

Factors and Contexts

Database Vault provides several predefined factors whose values are set by calls to the USERENV context. Factors use context values because they are memory-based and fast. Factors provide several features that contexts do not, such as the following:

Factors can be:

  • Created without coding PL/SQL procedures
  • Set and used without changing the application code
  • Audited
  • Logically combined without programming
  • Assigned trust levels
  • Used with Oracle Label Security (OLS) to apply labels to sessions

Factors and contexts are similar because factors use context attributes. When a factor is created, the Database Vault packages create a context attribute for that factor. Factors have the advantages of contexts, without the coding. Factors add security features that are not available with contexts alone.

Factor Scenarios

Factors are useful in building security policies. They are building blocks that reduce the programming necessary to produce a robust security policy.

Suppose that only users connected through the internal network are allowed to access the HR schema. You can place the HR schema objects in a realm. Modify the Domain factor to identify the network source of the session. Create a rule set by using the factor that enforces “Do not allow HR realm access from the internet (Domain=INTERNET).”

You can define a similar rule set that does not allow any data manipulation language (DML) operations (insert, update, or delete) outside of the standard work hours. (WorkHours = WEEKEND or WorkHours = WEEKNIGHT).

You can ensure that users access the application schema objects only through the application server by using a secure application role. You can define a rule that says “This role can be enabled only when the session originates on the application server machine (Domain = SECURE) and the user is proxied by the application owner (Proxy_User = SH).” The Domain and Proxy User factors contribute to this scenario.

Factor Types

Factor types enable you to group factors into categories. Some predefined factor types include authentication method, host name, and instance. You can define your own factor types, such as application name or certificate information. Factor types are used only for grouping factors and have no effect on the factor or the factor display in Cloud Control. For example, the predefined factors (Session User, OS User, and Proxy User) are grouped in the User factor type.

The DBMS_MACADM package provides a function to create a factor type: 

CREATE_FACTOR_TYPE(name VARCHAR2, description VARCHAR2)

The TimeOfDay factor is assigned to the Time factor type.

Factor Identification

The value of a factor is the identity of that factor. The identity of a factor is assigned by a method, a constant, or other factors. On the Edit Factor or Create Factor page, there are three choices for factor identification:

  • By Method: This is the default option. When this option is chosen, a PL/SQL expression entered in the Retrieval Method field is evaluated to obtain the identity. The method can be any PL/SQL function that returns a VARCHAR2 data type. Examples can be seen in the predefined factors.
  • By Constant: When this option is selected, a constant value entered in the Retrieval Method field is assigned to the factor. This option assigns a single value to the factor, and the value is always the same. The constant is a VARCHAR2 string.
  • By Factors: When this option is selected, a mapping identity is used to evaluate a set of child factors. The result is assigned to the parent factor. This option is used to easily create a factor by using the results of multiple other factors that are already defined, without having to write a complex PL/SQL function.

The TimeOfDay factor is identified by factors to allow multiple names for the different times needed for security, such as Workhours, Weeknight, and Weekend. The value of a factor may also be set by the application by using the DVSYS.SET_FACTOR function.

Factor Evaluation

Factor evaluation determines when the identity is assigned.

  • For Session: With this option, the factor is evaluated once per session when the session is created. This option incurs less overhead and should be used with factors, such as Client_IP address or Session_User, that remain constant for the entire session.
  • By Access: With this option, the factor is evaluated when the session is created and each time the factor is accessed. This option forces the factor to be reevaluated. This option has a higher overhead, but ensures that factors that could change during the life of the session are assigned and validated properly. For example, Language-, Module-, and Time-based factors could change.

The TimeOfDay factor should be evaluated by access. This would prevent a session from continuing access or actions at a forbidden time of a day. Factors and rules cannot be avoided just by starting the session during a time when the actions being attempted are allowed or access is allowed.

Retrieval Method

The retrieval method is required if Factor Identification is set to By Constant or By Method. The entry in the Retrieval Method field is a PL/SQL expression. This expression may be a constant VARCHAR2 string or a data type that can be converted to VARCHAR2. This expression may be a packaged or a stand-alone function. The expression cannot be a complete SQL statement.

When you use a function as a retrieval method, it must be completely specified with a schema and a function name, such as JLS.MY_FUNCTION(…). The DVSYS user must have the EXECUTE privilege on the function. As with the JLS.MY_FUNCTION(DVF.F$HOST_IP) function, the value returned by another factor may be accessed by using the DVF-owned function for that factor either as a parameter or in the function body.

UPPER(SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER'))

DVSYS.SET_FACTOR

A factor may be set from the session that is using the factor. This function provides a way for applications and application servers to set factor information that may be available only to the application. A factor cannot be set unless an assignment rule set is specified. The rule set is evaluated when the SET_FACTOR function is called to determine whether the factor is allowed to be set.

Because this function is executable by PUBLIC, it is recommended that a validation method is always specified for any factor that may be set by the SET_FACTOR function.

BEGIN 
	DVSYS.SET_FACTOR('DOMAIN','SECURE');
END;

Assignment Rule Sets for Factors

When you set an assignment rule set for a factor, it allows the factor to be set with a call to the DVSYS.SET_FACTOR procedure. Without an assignment rule set, a factor cannot be set. Therefore, the only way that it has a value is through its evaluation method. If there is no assignment rule set for the factor, you cannot call DVSYS.SET_FACTOR to set its value. If it has an assignment rule set, the rule set is evaluated when DVSYS.SET_FACTOR is called; if it evaluates to TRUE, the factor is set as requested; otherwise, it is not set.

You may want to set assignment rule sets when the evaluation of the factor cannot take into account certain aspects of the connection to the database. For example, an application server may authenticate a user, and then pool connections into a different database account. The application server may need to establish database privileges on behalf of the end user. This can be done by calling DVSYS.SET_FACTOR to force a factor to have a particular identity to provide certain privileges.

Validation Method

The validation method is evaluated each time the identity is retrieved, as an additional check on the value. The validation method can be any PL/SQL expression that returns a boolean value. The identity may be set in several ways—through defined method, constant, and other factors, and with the SET_FACTOR procedure. A validation method provides another check of the identity at each retrieval. Always use validation methods if the factor is assignable by the SET_FACTOR procedure, to verify that invalid entries are not submitted.

You can use a packaged or stand-alone function, or a condition as shown in the slide. There are two signatures available for the function:

  • FUNCTION is_valid RETURN BOOLEAN – This signature is more appropriate for factors that are evaluated by session. The DVF.F$factor_name function may be used inside this function.
  • FUNCTION is_valid (p_factor_value VARCHAR2) RETURN BOOLEAN

Factor Audit Options

Audit options control the generation of a custom Database Vault audit record. It is a mandatory attribute, although it can be set to Never. In a non-unified auditing environment, Oracle Database Vault writes the audit trail to the DVSYS.AUDIT_TRAIL$ table. If you have enabled unified auditing, this setting does not capture audit records. Instead, you can create and enable audit policies to capture this information.

Multiple audit options may be selected at one time. In the slide, the default options are shown for each of the values: Never, Always, and Sometimes. Each option is converted to a bit mask and added to determine the aggregate behavior. The following audit options are provided:

  • Retrieval Error: Create an audit record when a factor’s identity cannot be resolved and assigned due to an error (such as “No data found” or “Too many rows”).
  • Retrieval NULL: Create an audit record when a factor’s identity is resolved to NULL.
  • Validation Error: Create an audit record when the validation method (if provided) returns an error.
  • Validation False: Create an audit record when the validation method (if provided) returns FALSE.
  • Trust Level NULL: Create an audit record when the factor’s resolved identity has an assigned trust level of NULL.
  • Trust Level Less Than Zero: Create an audit record when the factor’s resolved identity has an assigned trust level that is less than zero.

Error Options

The error option is a required attribute that defaults to Show Error Message. Error options control the processing that occurs when the resolution of a factor identity fails. The possible options are:

  • Show Error Message: Displays an error message to the database session. This option is very useful for debugging.
  • Do Not Show Error Message: Suppresses the error message. This option does not give any additional information to an unauthorized user, but fails silently.

Purpose of Identities

A factor’s identity for a given database session is assigned at run time using the Factor Identification and Retrieval Method fields. Configuration of identities is optional and is used to serve the following purposes:

  • To define the known identities for a factor
  • To add a trust level to a factor’s identity
  • To add an OLS label to a factor’s identity
  • To resolve a factor’s identity through its child factors (identity mapping)

Identities must be configured to use trust level, OLS label, or child factors.

Example of mapping child factors

Example: When the Client_IP factor is not an address on the local subnet, the value INTERNET is assigned to the DOMAIN factor.

The value of an identity can be assigned by evaluating another factor called a child factor. In this case, the value INTERNET is assigned to the DOMAIN factor when the Client_IP factor is not an address on the local subnet. Each identity can have one or more child factors that determine when the identity is set. Mapping factors provides a convenient way to build a modular system. By using factors thus, you can reduce or eliminate the need to write PL/SQL retrieval methods.

Identity Example

The DOMAIN factor is defined with three identities: SECURE, INTRANET, and INTERNET. If the assignment rule set is Null or Disabled, these values are the only ones allowed that may be set with the SET_FACTOR function. The conditions that determine which identity is assigned are defined by the settings in the Map Identity region of the Create Identity or Edit Identity pages.

If the retrieval method returns a value that is not one of the defined identities, the identity is set to the returned value and the trust level is set to Untrusted. Each defined identity must have a trust level assigned, even if it is the Trust Level Not Defined option. The trust level value can be used in rule sets and validation functions. For example, you have a security rule that the HR.EMPLOYEES table cannot be accessed when the user connects from the Internet. You can create a factor named HR_EMP_ACCESS that determines the access to the HR.EMPLOYEES table. Then, attach a validation function and an assignment rule set that prevents the HR_EMP_ACCESS factor from being set if DOMAIN has a trust level of Untrusted or Trust Level Not Defined.

Trust Levels

The trust level represents the level of confidence in the factor/value pair. It is a mandatory attribute. A trust value of 1 signifies some trust. A higher value indicates a higher level of trust. A negative value indicates distrust. When the factor identity returned from a factor retrieval method is not defined in the identity table, the identity is automatically assigned a negative trust level.

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

To determine the trust level of a factor identity at run time, you can use the following functions in the DVSYS schema that are publicly available:

FUNCTION get_trust_level(p_factor IN VARCHAR2) RETURN NUMBER
FUNCTION get_trust_level_for_identity(p_factor IN VARCHAR2,
    p_identity IN VARCHAR2) RETURN NUMBER

For example:

SQL> SELECT dvf.f$domain, get_trust_level('DOMAIN')
     FROM dual;

F$DOMAIN      GET_TRUST_LEVEL('DOMAIN') 
------------  ------------------------- 
INTERNET      -1
SQL> SELECT get_trust_level_for_identity('DOMAIN','SECURE')
     FROM dual;

GET_TRUST_LEVEL_FOR_IDENTITY('DOMAIN','SECURE')
----------------------------------------------
10

In the preceding example, the INTERNET identity for the DOMAIN factor is untrusted (value equals –1) and the identity for the SECURE domain is 10, which implies a greater trust.

Trust-level information can be used in rule sets, validation methods, or directly from the application. The GET_TRUST_LEVEL and GET_TRUST_LEVEL_FOR_IDENTITY functions are executable by any user. For example, the application can check the trust level before allowing access to certain tables, or a validation method can check that a trust level must be above a certain level before it allows the application to set a factor.

Map Conditions

When you have multiple identities for the same factor, the first identity that is evaluated that returns TRUE for the map conditions is set. The identities are evaluated in the order of the identity name, in an ASCII sort. If the conditions overlap, the evaluation order can lead to unexpected results. For example, if the DOMAIN factor is assigned the INTRANET identity for sessions originating on any machine on the 139.185.35 subnet, except sessions originating on host 139.185.35.114, DOMAIN is assigned SECURE.

If INTRANET is defined as CLIENT_IP LIKE 139.185.35.% and SECURE as CLIENT_IP = 139.185.35.114, even sessions originating on the secure server would get the DOMAIN identity of INTRANET, instead of the expected SECURE, because the INTRANET identity is evaluated first.

Factor and Identities Views

The following views are in the DVSYS schema:

  • The DBA_DV_FACTOR view lists the existing factors in the current database instance.
  • The DBA_DV_FACTOR_LINK view shows the relationships of each factor whose identity is determined by the association of child factors.
  • The DBA_DV_FACTOR_TYPE view lists the names and descriptions of factor types used in the system.
  • The DBA_DV_IDENTITY view lists the identities for each factor.
  • The DBA_DV_IDENTITY_MAP view lists the mappings for each factor identity.

Reports Related to Factors and Their Identities

  • 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 audits 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.

Maintaining Factors and Identities

You must have the DV_OWNER role to maintain factors and identities. The DBMS_MACADM package in the DVSYS schema provides functions and procedures for the maintenance tasks.

Maintaining factors includes:

  • Creating factors, factor links, and factor types
  • Modifying factors and factor types
  • Deleting factors, factor links, and factor types

Publicly executable functions for factors include:

  • SET_FACTOR (p_factor, p_value)
  • GET_FACTOR (p_factor)
  • GET_TRUST_LEVEL (p_factor)
  • GET_TRUST_LEVEL_FOR_IDENTITY (p_factor, p_identity)

Maintaining identities includes:

  • Creating identities and identity maps
  • Modifying identities
  • Deleting identities and identity maps

You May Also Like