214 Part II: Oracle Database Vault e.g. SELECT, INSERT, EXECUTE on a specific object owner's objects or object FUNCTION assert_object_command( check_event IN VARCHAR2 , check_obj_owner IN VARCHAR2 , check_obj_name IN VARCHAR2 , sql_event IN VARCHAR2 , sql_obj_owner IN VARCHAR2 , sql_obj_name IN VARCHAR2 ) RETURN NUMBER; used to assert a specific weekly timeframe is true FUNCTION weekly_window( begin_day IN VARCHAR2 , begin_time IN VARCHAR2 , end_day IN VARCHAR2 , end_time IN VARCHAR2 , time_format IN VARCHAR2 DEFAULT 'HH24' , check_datetime IN DATE DEFAULT SYSDATE ) RETURN NUMBER; used to check if a grant or revoke operation is being attempted to the current database session user FUNCTION grant_or_revoke_to_self RETURN NUMBER; used to store the details of a SQL command being executed in an application context so the details can be used in DBV Rule Set custom handlers PROCEDURE set_event_context( command IN VARCHAR2 , session_user IN VARCHAR2 , instance_num IN NUMBER , database_name IN VARCHAR2 , obj_type IN VARCHAR2 , obj_owner IN VARCHAR2 , obj_name IN VARCHAR2 , sql_text IN VARCHAR2 ) ; END dbms_mac_extension; / Package created. dbvext@aos> create the package body dbvext@aos>@@@dbv_ext_body Package body created. dbvext@aos> grant DVSYS EXECUTE privileges so the code dbvext@aos> can be used in DBV Factors and DBV Rules dbvext@aos>GRANT EXECUTE ON dbvext.dbms_mac_extension TO dvsys; Grant succeeded. dbvext@aos> associate the SQL_EVENT application context dbvext@aos> to this package for the Chapter 7 example dbvext@aos>CREATE OR REPLACE CONTEXT sql_event Chapter 6: Applied Database Vault for Custom Applications 215 USING dbvext.dbms_mac_extension ; Context created. dbvext@aos>CONNECT / AS SYSDBA Connected. sys@aos> revoke the ability to connect to sys@aos> the database from DBVEXT sys@aos>REVOKE CREATE SESSION FROM dbvext; Revoke succeeded. dbvowner@aos>CONNECT dbvacctmgr Enter password: Connected. dbvacctmgr@aos> lock the account when the database objects dbvacctmgr@aos> owned by DBVEXT have been loaded dbvacctmgr@aos>ALTER USER dbvext ACCOUNT LOCK PASSWORD EXPIRE; User altered. We’ve taken the liberty of scripting this process and creating the DBVEXT.DBMS_MAC_ EXTENSION PL/SQL package. The script is named create_dbv_extension.sql in the scripts included with this book. You will need to replace the connection and password DEFINEs at the top of the script with the connection specifics for your environment to load it into your database. The decision to remove the realm authorization for DBVEXT in the DBV can be based on whether or not the code used issues Data Definition Language (DDL) statements on the objects owned by DBVEXT. If the code does not issue DDL, it is OK to remove the authorization as follows: dbvowner@aos> remove the realm authorization from dbvowner@aos>BEGIN dbms_macadm.delete_auth_from_realm ( realm_name => 'Oracle Database Vault' , grantee => 'DBVEXT' ); END; / PL/SQL procedure successfully completed. Even if the code does not issue DDL on DBVEXT objects, you may find it useful to leave the authorization in place for awhile to develop and debug the code stored in the DBVEXT account. Factors Based on Compliance DBV factors defined as constants can be used to support compliance regulations in your environment. In our notional example, we have a condition that states that audit trails must be maintained for period of seven years and certain types of administrators are restricted from altering an audit trail. We might also have compliance regulations that dictate the number of days a corporate officer must review internal controls. These conditions for compliance may change over time. DBV factors defined as constants allow for the potential for change and avoid the need to hard code the details of a compliance control in application code. For example, we may define a DBV factor Audit_Retention_Period as follows: dbvowner@aos>BEGIN dbms_macadm.create_factor( factor_name => 'Audit_Retention_Period' , factor_type_name => 'Organizational', 216 Part II: Oracle Database Vault description => 'A compliance control that dictates the' || 'number of years audit trails must be maintained.', rule_set_name => NULL , get_expr => '7', validate_expr => NULL, identify_by => dbms_macutl.g_identify_by_constant, labeled_by => dbms_macutl.g_labeled_by_self, eval_options => dbms_macutl.g_eval_on_access, audit_options => dbms_macutl.g_audit_on_get_error, fail_options => dbms_macutl.g_fail_with_message); END; / PL/SQL procedure successfully completed. COMMIT Commit complete. This factor’s function, DVF.F$Audit_Retention_Period, could be leveraged in PL/SQL code or Oracle VPD policy to ensure that audit records are not deleted in a manner that would violate the compliance policy. This type of configuration control is available to all applications in the database. Factors Based on Conflict of Interest or Separation of Duty To ensure the integrity of audit trails, a separation of duty control was specified to prevent database administrators from updating or deleting them. We can use a DBV factor to define the database administrator roles we want to restrict, such as DBA, OLAP_DBA, or IMP_FULL_ DATABASE, and the factor will return an indicator if the current database session has been granted one of these roles: dbvowner@aos>BEGIN dbms_macadm.create_factor( factor_name => 'Database_Administrator' , factor_type_name => 'User', description => 'The current session has database administrator roles.', rule_set_name => NULL, get_expr => 'dbvext.dbms_mac_extension.user_has_role( ''DBA,OLAP_DBA,IMP_FULL_DATABASE'')', validate_expr => NULL, 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_on_get_error, fail_options => dbms_macutl.g_fail_with_message); END; / PL/SQL procedure successfully completed. Using this approach, we can define factors around sensitive application or database roles that are used in our environment. This factor leverages the DBVEXT.DBMS_MAC_EXTENSION PL/SQL package’s user_has_role function, which checks the session against the roles to which it has access as defined in the SYS.DBA_ROLE_PRIVS view. It would be straightforward to create a complementary Chapter 6: Applied Database Vault for Custom Applications 217 function in this package to leverage the SYS.DBA_SYS_PRIVS view to determine whether a session has access to sensitive system privileges, such as BECOME USER, ADMINISTER DATABASE TRIGGER, or EXEMPT ACCESS POLICY, should your security policy require such checks. The user_has_priv function was included with the DBVEXT.DBMS_MAC_EXTENSION PL/SQL package to meet this need. It is important to configure these factors with an eval_options parameter set to dbms_ macutl.g_eval_on_access so that if the conditions change during the course of a database session, the factor’s retrieval method is executed to get the most current information available. Factors Based on Organizational Policy In our example use case, the organization policy dictates that a Product Manager can query the details only of products for which the manager is responsible. This condition might be based on a small number of product categories or product types in the system. Smaller user-driven lists or user-driven single values defined by organizational policy can be implemented as DBV factors. Consider the SH.PRODUCTS table, for example, and its small number of product categories: sh@aos>SELECT DISTINCT prod_category FROM sh.products ORDER BY 1; PROD_CATEGORY Electronics Hardware Peripherals and Accessories Photo Software/Other 5 rows selected. If an organization employs a single manager for one or more product categories, we can implement a simple PL/SQL function to return the product categories a logged in user manages and use this function as the retrieval method of a notional factor named Product_Categories_ Managed. The advantage of this approach is that the function is called at session startup and available for the remainder of the session as part of a DBV rule or in the PL/SQL that controls Virtual Private Database (VPD) or Oracle Label Security (OLS). Factors Based on Identity Management Identity management–related factors such as an end user’s job title or department could be resolved using enterprise-specific code that could leverage a human resources system or Lightweight Directory Access Protocol (LDAP) directory such as Oracle Internet Directory (OID). In Chapter 5, we presented an example for a User_Department_Name factor that queried the HR sample schema and used the database end user name as a linking element. This notional example demonstrates how identity management–related factors could be retrieved when the user-specific attributes or group membership information is stored in the database. A more typical scenario in an enterprise would have the user-specific attributes or group memberships stored in an external HR system or LDAP directory. The Oracle database includes several features and products for remote access such as UTL_TCP, UTL_HTTP, DBMS_LDAP, or Oracle Heterogeneous Services that can be used to access external systems. Oracle Enterprise User Security (EUS) is one technology that allows end users stored in LDAP to authenticate to the database. When this authentication has completed, the database will automatically populate an application context named SYS_LDAP_USER_DEFAULT with non-NULL values of the inetOrgPerson directory object for the user. This inetOrgPerson directory object class includes 218 Part II: Oracle Database Vault more than 40 attributes for an end user that can be leveraged with this technology. For example, when an Oracle EUS–based session is started, a DBV factor could be created to query the SESSION_CONTEXT view for specific LDAP attributes from the example context shown here: eus-user@aos>SELECT * FROM session_context WHERE namespace = 'SYS_LDAP_USER_DEFAULT'; NAMESPACE ATTRIBUTE VALUE SYS_LDAP_USER_DEFAULT UID eus.user SYS_LDAP_USER_DEFAULT TITLE ANALYST SYS_LDAP_USER_DEFAULT MANAGER eus.manager SYS_LDAP_USER_DEFAULT TELEPHONENUMBER +1 555 456 789 SYS_LDAP_USER_DEFAULT MAIL eus.user@mycompany.com SYS_LDAP_USER_DEFAULT EMPLOYEETYPE CONTRACTOR 6 rows selected. The approach defined in Oracle Metalink note 242156.1 “An Example of Using Application Context’s Initialized Globally” can also be used with EUS to extend this generic EUS capability to include group membership information or to extend the attributes of an end user that are not available in inetOrgPerson. Factors Based on Access Path or Operational Context In Chapter 5, we presented example scenarios for examining the access path to the database and the context of the transaction operation. We demonstrated a fairly complex multifactored approach to identifying the type of connection (a factor) based partially on the IP address (a factor) of the database client to account for the network access path to the database. We also demonstrated DBV rule sets that authorized a specific SQL command only if it had come from a trusted PL/SQL package that was resident on the PL/SQL call stack. In this second scenario, we defined the call stack check logic as a DBV factor using the DBVEXT.DBMS_MAC_EXTENSION PL/SQL package’s INSTR_CALL_STACK function. dbvowner@aos>BEGIN dbms_macadm.create_factor( factor_name => 'In_Sales_Transaction_Package' , factor_type_name => 'Application', description => 'The current transaction was called from the SH.SALES_TRANSACTION package.', rule_set_name => NULL , get_expr => 'dbvext.dbms_mac_extension.instr_call_stack(''SH.SALES_TRANSACTION'')', validate_expr => NULL, 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_on_get_error, fail_options => dbms_macutl.g_fail_with_message); END; / PL/SQL procedure successfully completed. Chapter 6: Applied Database Vault for Custom Applications 219 Our DBV rule definition is updated to leverage this new factor: dbvowner@aos> first lets create the conditional rule that dbvowner@aos> we are using the trusted sales transaction code dbvowner@aos>BEGIN dbms_macadm.update_rule( rule_name => 'Called From Sales Transaction Package' , rule_expr => 'DVF.F$In_Sales_Transaction_Package > 0' ); END; / PL/SQL procedure successfully completed. Factors Based on Time or Sequential Conditions In Chapter 5, we presented an example scenario for examining the day of the week and time of day to determine whether a SQL command should be allowed to execute. The IT department’s policy allowed for system maintenance to occur on Fridays from 5 to 11 P.M., so this was an organizational policy that used time-based factors. A word of caution: As you examine time-based factors, consider creating only factors that have meaning to your organization or enterprise. Factors such as Time of Day or Current Date are simply data points that can be resolved using normal PL/SQL routines such as TO_CHAR or SYSTIMESTAMP and do not provide a tremendous amount of value as DBV factors. You should focus on creating factors for the concept of a maintenance window or other named time windows in which an activity can occur. Creating these types of factors is useful when decisions are made outside of a DBV rule set, such as inside PL/SQL code blocks or in row-level security controls such as Oracle VPD. The DBVEXT.DBMS_MAC_EXTENSION PL/SQL package includes a utility function called weekly_window that can be used to create multiple named time windows. Our example from Chapter 5 could be expressed as a factor in the following way: dbvowner@aos>BEGIN dbms_macadm.create_factor( factor_name => 'Is_Maintenance_Window' , factor_type_name => 'Time', description => 'Returns an indicator that the system is inside weekly maintenance window.', rule_set_name => NULL , get_expr => 'dbvext.dbms_mac_extension.weekly_window(''FRIDAY'',''17:00'',' || '''FRIDAY'',''22:59'',''HH24:MI'')', validate_expr => NULL, 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_on_get_error, fail_options => dbms_macutl.g_fail_with_message); END; / PL/SQL procedure successfully completed. 220 Part II: Oracle Database Vault This factor can define a named time window by specifying the starting day of the week and time in the first two parameters and the ending day of the week in the third and fourth parameters. The function’s fifth parameter defines the Oracle datetime format model of the time-based parameters. With this factor in place, we return to the example presented in Chapter 5 and define the DBV rule Is Maintenance Timeframe as follows: dbvowner@aos> BEGIN dbms_macadm.create_rule( rule_name => 'Is Maintenance Timeframe' , rule_expr => 'DVF.F$Is_Maintenance_Window = 1' ); END; / PL/SQL procedure successfully completed. It is required that you configure time-based factors with an eval_options parameter set to dbms_macutl.g_eval_on_access, because this information does change during the course of a database session. Factors Based on Data or Events Stored Externally DBV factors can be created based on information stored in external systems, as we discussed with the use of Oracle EUS and DBV. The Oracle database includes several features and products for network-based access to external systems. UTL_TCP, UTL_HTTP, DBMS_LDAP, or Oracle Heterogeneous Services can be used for these scenarios. You can also leverage features such as external procedures written in C or Java to interact with the operating system on which the database runs to provide the information for these factors. Incorporating DBV Factors in Your Application The following guidelines offer different ways you can leverage DBV factors in your database applications. Factors in Oracle VPD Policy Functions Oracle VPD lets you enforce security to a fine level of row-level security (RLS) directly on tables, views, or synonyms with security policies that are attached directly to these objects. When a user directly or indirectly accesses a table, view, or synonym protected with a VPD policy, the server dynamically modifies the SQL statement of the user by adding or modifying the WHERE condition (known as a predicate) returned by a PL/SQL policy function implementing the security policy. VPD policies can be applied to SELECT, INSERT, UPDATE, and DELETE statements. One useful benefit of DBV factor functions being available in PL/SQL is that we can use them in Oracle VPD policy functions, as shown in the following example: CREATE OR REPLACE FUNCTION costs_policy_function( schema_name IN VARCHAR2 , table_name IN VARCHAR2 ) RETURN VARCHAR2 AS BEGIN no cost transaction during maintenance window IF DVF.F$Is_Maintenance_Window = 1 THEN Chapter 6: Applied Database Vault for Custom Applications 221 RETURN '1=0'; filter on costs related to the product categories the manager is responsible for managing ELSE RETURN 'EXISTS ( SELECT 1 FROM sh.products ' || 'WHERE sh.costs.prod_id = sh.products.prod_id ' || ' AND sh.products.prod_category_id IN (' || DVF.F$Product_Categories_Managed || '))' ; END IF; END; / In this example, we can restrict users from querying or updating any cost-related data during the weekly maintenance window and then use a factor called Product_Categories_Managed that holds the product category list that is maintained by the end user. Factors in OLS Labeling Functions and SQL Predicates OLS enables RLS by using Oracle VPD as well. With OLS, a label security administrator defines a set of labels for data and users, along with authorizations for users and program units that govern access to specified protected objects. An OLS policy is nothing more than a name associated with these labels, rules, and authorizations. Oracle OLS controls access to the contents of a record in a table by comparing a row’s label with a user’s label and privileges. To apply an OLS policy to a table, we would use the package procedure SA_POLICY_ADMIN.APPLY_TABLE_POLICY. This package procedure has the following signature: PROCEDURE APPLY_TABLE_POLICY ( policy_name IN VARCHAR2, schema_name IN VARCHAR2, table_name IN VARCHAR2, table_options IN VARCHAR2 DEFAULT NULL, label_function IN VARCHAR2 DEFAULT NULL, predicate IN VARCHAR2 DEFAULT NULL); The label_function parameter can be used to declare a PL/SQL function that returns a label value to use as the default label for a record that is created. For example, we could define an OLS PL/SQL label function that uses a notional Job_Title factor to increase the sensitivity of product costs records that a vice president can see: CREATE OR REPLACE FUNCTION costs_label RETURN LBACSYS.LBAC_LABEL IS BEGIN IF DVF.F$Job_Title = 'VICE PRESIDENT' THEN RETURN TO_LBAC_DATA_LABEL('COST_POLICY', 'SENSITIVE'); ELSE RETURN TO_LBAC_DATA_LABEL('COST_POLICY', 'CORPORATE'); END; This policy function can then be used in the label_function parameter in a SA_POLICY_ADMIN. APPLY_TABLE_POLICY as follows: , label_function => 'sh.costs_label' 222 Part II: Oracle Database Vault The predicate parameter is an additional SQL predicate that can be combined dynamically, using the AND or the OR logical operator, with the predicated returned from a label function. We can use a predicate similar to the VPD example presented earlier to combine label security with the operational concept of restricting access during the weekly maintenance window as follows: , predicate => ' AND DVF.F$Is_Maintenance_Window = 0' The same type of factor-based policy can be applied to the OLS package procedure SA_ POLICY_ADMIN.APPLY_SCHEMA_POLICY. This defines policies at the database schema level so that all existing or new tables in a particular schema can share the same (consistent) policy definition. Factors in Oracle Fine-Grained Auditing (FGA) Regular Oracle database auditing allows you to audit commands issued against a database object every time the command is issued. This can typically lead to more audit data than you may want to store when you really just want to audit when certain conditions are met. These conditions may be driven by compliance purposes and can be dynamic in nature. The Oracle FGA feature is designed to meet the needs of object-level auditing only when certain conditions are met. Consider the Sales History application and the table SH.CUSTOMERS that includes credit limit information for the customer in CUST_CREDIT_LIMIT. Our condition may be that we are interested in auditing only SELECT commands against this table only by users that are not members of the Sales Department and for customers with higher credit limits. Use of these commands may imply suspicious behavior on behalf of a non-sales staff member. In Chapter 5, we defined a DBV factor that exposes the user’s department name so we can leverage this factor in an FGA policy’s audit condition as follows: BEGIN dbms_fga.add_policy ( object_schema =>'SH' , object_name =>'CUSTOMERS' , policy_name =>'SUSPICIOUS_CUSTOMER_ACCESS' , audit_column => 'CUST_GENDER,CUST_YEAR_OF_BIRTH' || ',CUST_MARITAL_STATUS,CUST_INCOME_LEVEL,CUST_CREDIT_LIMIT' , audit_condition => 'CUST_CREDIT_LIMIT >= 10000' || ' AND DVF.F$User_Department_Name != ''Sales''' , statement_types => 'SELECT' ); END; Factors in Views Another form of RLS that has been used by many applications is to embed filter logic directly in database views. The implementation of factors as PL/SQL functions creates an opportunity to use them directly in view definitions. The following view for sales costs will prevent data being returned during the weekly maintenance window time frame: CREATE OR REPLACE VIEW sh.costs_view AS SELECT products.prod_name , promotions.promo_name , channels.channel_desc , costs.unit_cost , costs.unit_price FROM sh.costs, sh.products, sh.promotions,sh.channels Chapter 6: Applied Database Vault for Custom Applications 223 WHERE products.prod_id = costs.prod_id AND promotions.promo_id = costs.promo_id AND channels.channel_id = costs.channel_id AND DVF.F$Is_Maintenance_Window = 0 / Factors in Application Code (PL/SQL or SQL Statements) Factors can be used in application code that exists outside the database. The preceding examples show how factors can be embedded within other database objects. It is important to remember that factors are available as PL/SQL functions and can be included within SQL anywhere it may reside. The implementation of factors as PL/SQL functions can be very similar to the view in the preceding paragraph. The following SQL statement will be defined and executed from the application tier. The query of sales costs will prevent data from being returned during the weekly maintenance window time frame: SELECT products.prod_name , promotions.promo_name , channels.channel_desc , costs.unit_cost , costs.unit_price FROM sh.costs, sh.products, sh.promotions,sh.channels WHERE products.prod_id = costs.prod_id AND promotions.promo_id = costs.promo_id AND channels.channel_id = costs.channel_id AND DVF.F$Is_Maintenance_Window = 0 / The factor is resolved when executed within the database. The factor is evaluated and returned to the SQL statement, and then applied as a filter inside the statement itself. Factor functions are automatically granted to PUBLIC through a special DBV role named DV_PUBLIC. No special work is required to leverage them in PL/SQL code you write as packaged procedures as well as SQL statements that applications or end users issue. You can use the two forms of factor identity retrieval—the DVF schema’s factor function or the DVSYS GET_FACTOR function—as follows: IF DVF.F$Is_Maintenance_Window = 1 THEN … logic here END IF; Or equivalently, IF DVSYS.GET_FACTOR('Is_Maintenance_Window') = 1 THEN … logic here END IF; This simplifies application logic by reducing the need for common code to be copied or shared among projects and can help performance when the factors are evaluated at session startup (or when proxy authentication sessions start). The result is application code that is more declarative in nature with respect to security. The use of the function DVSYS.GET_FACTOR would be preferable when the name of the factor is dynamic depending on your implementation or project. . definition. Factors in Oracle Fine-Grained Auditing (FGA) Regular Oracle database auditing allows you to audit commands issued against a database object every time the command is issued. This can. Oracle Database Vault This factor can define a named time window by specifying the starting day of the week and time in the first two parameters and the ending day of the week in the third and. sh.promotions,sh.channels Chapter 6: Applied Database Vault for Custom Applications 223 WHERE products.prod_id = costs.prod_id AND promotions.promo_id = costs.promo_id AND channels.channel_id = costs.channel_id AND DVF.F$Is_Maintenance_Window