144 Part II: Oracle Database Vault Data Definition Language Database structure related commands that typically have the form CREATE <object type>, ALTER <object type>, and DROP <object type>, such as CREATE TABLE, ALTER TABLE, and DROP TABLE. This category also includes privilege-related commands such as GRANT and REVOKE, auditing commands such as AUDIT and NOAUDIT, and data table administration commands such as ANALYZE, COMMENT, FLASHBACK, PURGE, RENAME, and TRUNCATE. System control Commands such as ALTER SYSTEM and ALTER DATABASE. Session control Commands such as ALTER SESSION and SET ROLE. Transaction control Commands such as COMMIT and ROLLBACK. SELECT and DML commands cannot use '%' for both the object owner and object name, and command rules for these commands cannot be applied for the SYS or DVSYS account. DBV does not offer command rules for transaction control commands, as these commands are not security relevant nor do they operate on database objects. By security relevant, we mean the commands do not change session user, change the current user, or give the session user any additional system or object privileges for the session. Command rules cannot be defined on the ALTER DATABASE or ALTER SESSION commands. The SET ROLE command is not directly supported, but the DBV Secure Application Role feature offers a mechanism to control the activation of a database role with a DBV rule set providing the decision point. With the remaining command categories, more than 100 distinct commands can be controlled by the security administrator with DBV command rules. DBV CONNECT Command Rule One of the most powerful command rules available controls when accounts that have been granted specific roles can establish connections to the database. This command rule uses a special DBV database operation named CONNECT that simply implies a command rule that authorizes a database connection once the standard authentication processing within Oracle has completed. Using this command rule, we can offer higher levels of assurance around when and how (conditions) an account is able to connect to the database. Let s consider MARY, our senior DBA for Sales History data, in an example. Suppose the IT department wants to tighten the controls around database administrators connecting to the database. The data and applications with which they are working are very sensitive. The first step is to decide under what conditions MARY and other database administrators are allowed to perform administration tasks. If the IT departments allow MARY VPN access to the corporate network, doesn t that mean she can be sitting in a coffee shop with a laptop viewing sensitive financial data? VPN access is typically much less secure than access at the company s office building because the networks are more open to snooping and the environment is less secure from a physical perspective. Who else has access to her laptop if she walks away from her computer to take a break? Would the customers in the stored in the CUSTOMERS table approve of this access? With DBV command rules, we can simply define a rule set that resolves whether the database session is being established from a machine that is physically located within the company s building(s). The IT department could establish a policy that mandates the use of a secure authentication method to all sensitive databases. The Oracle Advanced Security option provides authentication methods based on Public Key Infrastructure (PKI)Secure Sockets Layer (SSL) or Kerberos that could be leveraged. The policy could also dictate that the credential stores used for
Chapter 5: Database Vault Fundamentals 145 this authentication could be limited (in deployment) to machines that are located in the company offices. Once the policy is established, a level of trust can be established for all connections to the database. The rule used in the DBV rule set would leverage the Oracle built-in, read-only application context USERENV that stores security-related attributes about the database session. The rule can read the application context values using the PLSQL function SYS_CONTEXT as follows: dbms_macadm.create_rule( rule_name => 'Is Secure Authentication Method', rule_expr => 'SYS_CONTEXT(''USERENV'', ''AUTHENTICATION_METHOD'') IN (''SSL'', ''KERBEROS'')' PLSQL procedure successfully completed. Requiring PKISSL or Kerberos is a well-founded requirement because it establishes something a client might have, such as a certificate, and reduces password-based hacking. This increases the assurance that the database access is from a machine physically located at the company. The IT department will also need to account for database administrators working on the console of a database server by inspecting the client IP address of the session. Console-based access to the database implies that the database session was not established through the Oracle database listener that enables remote connectivity to an Oracle database. With remote database clients, the USERENV application context maintains the IP address of the client. The second rule for the DBV rule set is then as follows: dbms_macadm.create_rule( rule_name => 'Is Console Client', rule_expr => 'SYS_CONTEXT(''USERENV'', ''IP_ADDRESS'') IS NULL' PLSQL procedure successfully completed. With the rules defined for both remote database clients and console clients, we can configure the DBV rule set required for the DBV CONNECT command rule. DBV includes a predefined DBV rule set named Allow Sessions that is intended for this usage. For this example, we need to reconfigure the eval_options parameter of this DBV rule set to return TRUE if either rule is valid (a secure authentication method or a console-based client), and then associate the DBV rules to the DBV rule set. The default configuration of the Allows Sessions DBV rule set is TRUE if all associated rules are valid. dbvowner@aos> -- Reconfigure the "eval_options" parameter to use dbvowner@aos> -- the "any rule true" algorithm dbms_macadm.update_rule_set( rule_set_name =>'Allow Sessions', description =>'Rule set that controls the ability to create a session in the database.',
146 Part II: Oracle Database Vault enabled =>dbms_macutl.g_yes, eval_options =>dbms_macutl.g_ruleset_eval_any, audit_options =>dbms_macutl.g_ruleset_audit_fail, fail_options =>dbms_macutl.g_ruleset_fail_show, fail_message =>NULL, fail_code =>NULL, handler_options =>dbms_macutl.g_ruleset_handler_off, handler =>NULL PLSQL procedure successfully completed. dbvowner@aos> -- Associate the two rules to the rule set dbms_macadm.add_rule_to_rule_set ( rule_set_name => 'Allow Sessions', rule_name => 'Is Secure Authentication Method' PLSQL procedure successfully completed. dbms_macadm.add_rule_to_rule_set ( rule_set_name => 'Allow Sessions', rule_name => 'Is Console Client' PLSQL procedure successfully completed. Finally, we need to create the DBV CONNECT command rule that uses this DBV rule set. One word of caution here regarding the DBV CONNECT command rule: Make sure you keep a SQL*Plus session open as your DBV security administrator (DBVOWNER) in case you have developed PLSQL rule expressions that are incomplete, inaccurate, or that produce errors at runtime. You could inadvertently lock out every account from the database, including the DBV security administrator, with these types of problems. Having this SQL*Plus session open allows you to disable or drop the DBV CONNECT command rule if problems arise in the development and testing of the authorization logic. dbms_macadm.create_command_rule ( command => 'CONNECT',rule_set_name => 'Allow Sessions',object_owner => '%',object_name => '%',enabled => 'Y' PLSQL procedure successfully completed.
Chapter 5: Database Vault Fundamentals 147 At this point, if MARY were to attempt to log into the database from her VPN connection, sitting in the coffee shop, the connection would not be authorized and the session would be terminated immediately by DBV: $ sqlplus mary@aos SQL*Plus: Release 11.1.0.6.0 - Production on Tue Mar 10 17:04:12 2009 Copyright (c) 1982, 2007, Oracle. All rights reserved. Enter password: ERROR: ORA-47400: Command Rule violation for CONNECT on LOGON These examples demonstrate the separation of duty for privileged administrators. Using DBV command rules, we can add a layer of control that accounts for business rules and IT policies an organization must support. The access controls provided by DBV realms and DBV command rules are configured in a protected account (DVSYS) with an enforcement mechanism integrated directly into the Oracle database kernel s SQL engine. Application logic that issues SQL to an Oracle database does not need to change to leverage these DBV access controls. The main benefit of this external enforcement point model is that DBV can help cover the gaps in your application s security model so that you can meet compliance regulations without the need to recode or redesign the application. Rule Sets A DBV rule is an elementary logic component that is evaluated by DBV. These logic components are written as Oracle PLSQL expressions to return Boolean results. A simple rule would be USER!= 'SYS'. This rule uses a standard Oracle PLSQL function, USER, that returns the database account that was logged into and returns a Boolean result of whether or not the account logged into is SYS. Your own DBV rules can use PLSQL code you have or will develop. A DBV rule can be associated in more than one DBV rule set so that you can develop a library of DBV rules that can be used throughout your DBV security policy. TIP You can create DBV rules as reusable security policy controls applicable to more than one application. We have demonstrated example usages of DBV rule sets with the two primary DBV access control components: DBV realms (authorizations) and DBV command rules. DBV rule sets can also control the assignment of DBV factors and the ability to enable DBV Secure Application Roles (SARs). The auditing of these components is controlled by the audit configuration of the DBV rule set. DBV rule sets can be configured to execute custom PLSQL procedures so that if a DBV command rule is violated, for example, you could pass this information to another system or alert the security administrator in real time. Rule Set Evaluation Mode The configuration of DBV Rule sets allows for the association of multiple DBV rules (PLSQL expressions). DBV rule sets have an evaluation mode that can be configured to require that all associated rules return TRUE, or at least one rule returns TRUE. To help in clarifying the runtime impact of the evaluation mode configuration, consider an example: Suppose we ve defined a
148 Part II: Oracle Database Vault DBV rule set, Rule Set #1, depicted in the following table. This DBV rule set has an evaluation mode of ALL TRUE with two DBV rules associated to it. The DBV rule set evaluation result is depicted for the various results returned by the two associated DBV rules. Rule Set Evaluation Mode Rule #1 Result Rule #2 Result Rule Set Result Rule Set #1 ALL TRUE FALSE FALSE FALSE Rule Set #1 ALL TRUE TRUE FALSE FALSE Rule Set #1 ALL TRUE FALSE TRUE FALSE Rule Set #1 ALL TRUE TRUE TRUE TRUE Now suppose we have a second DBV rule set, Rule Set #2, with an evaluation mode of ANY TRUE. The same two DBV rules are associated with this second DBV rule set. The following table depicts the evaluation results for this configuration of the evaluation mode. Rule Set Evaluation Mode Rule #1 Result Rule #2 Result Rule Set Result Rule Set #2 ANY TRUE FALSE FALSE FALSE Rule Set #2 ANY TRUE TRUE FALSE TRUE Rule Set #2 ANY TRUE FALSE TRUE TRUE Rule Set #2 ANY TRUE TRUE TRUE TRUE The DBV rule set configuration allows for a DBV rule set to be disabled. The net effect of disabling a DBV rule set is that the DBV rules engine will return TRUE if the rule set is evaluated within the context of its usage such as a DBV realm authorization or DBV command rule. To clarify the effect of disabling a DBV rule set, consider the example rule set Using Financials Application from the Command Rules section earlier in the chapter. If we disable the rule set, then all UPDATE statements on the SH.SALES table will be allowed if the session has direct object privileges or the realm authorization is valid. Rule Set Auditing When we configured the rule set Using Financials Application in the DBV command rule example, we used the constant dbms_macutl.g_ruleset_audit_fail, which means audit on failure only or audit when the DBV rule set evaluation is FALSE. DBV rule set failure can be stated simply as the access control decision points (DBV rules) returned FALSE and the access attempt failed. Let s examine the DBV rule set configuration using the DBV Administrator page, as shown in Figure 5-8. Auditing on a failed access attempt would be considered a minimum requirement for all DBV rule sets, yet some regulatory requirements may mandate auditing on any data access (in other words, the evaluation result of the DBV rule set). You just need to consider the performance impacts of this level of auditing, given the frequency of evaluation in your production system, as auditing in any software component has some associated overhead. When we examine the DBV audit trail for the DBV command rule example for an UPDATE on the SH.SALES table (Figure 5-9), we can see the audit trail contains both the DBV rule set and command that triggered the audit. This information can be very useful in developing a policy that can prove your stated security posture.
Chapter 5: Database Vault Fundamentals 149 FIGURE 5-8 DBV rule set configuration FIGURE 5-9 DBV command rule violation report
150 Part II: Oracle Database Vault Custom Event Handlers The DBV rule set auditing component can be extended using the custom event handlers feature of the rule set configuration. This feature allows you to integrate DBV with external alerting, systems management, and monitoring systems. Like DBV rule set auditing, this feature can be configured to trigger based on a failure only or on a success and failure. To enable this feature, you need to follow these steps: 1. Define a package procedure or stand-alone procedure that will be triggered when the DBV rule set is evaluated. 2. Grant EXECUTE on the procedure to DVSYS. The DVSYS account executes the DBV rules engine and calls the procedure. 3. Configure the DBV rule set to use the custom event handling procedure. The details of integrating with an external alerting or monitoring system is a bit beyond the scope of this book, so let s just look at a trivial table-based logging example for now: mary@aos> -- First create a table to hold the alerts mary@aos> create table sh.alerts ( msg varchar2(4000), msgdate date default sysdate Table created. mary@aos> -- next create a package to process the alerts mary@aos> CREATE OR REPLACE package sh.sales_alerts as PROCEDURE sales_update_alert(ruleset_name IN VARCHAR2, ruleset_result IN VARCHAR2 end; Package created. mary@aos> CREATE OR REPLACE PACKAGE BODY sh.sales_alerts AS PROCEDURE sales_update_alert(ruleset_name IN VARCHAR2, ruleset_result IN VARCHAR2) is PRAGMA AUTONOMOUS_TRANSACTION; BEGIN INSERT into sh.alerts (msg ) VALUES ('Alert for Rule Set:' ruleset_name ', result is ' ruleset_result COMMOT; Package created. mary@aos> -- GRANT EXECUTE on the handler package to DVSYS mary@aos> GRANT EXECUTE ON sh.sales_alerts TO dvsys; Grant succeeded. mary@aos> -- Update the rule set to use the handler package mary@aos> -- on rule set failure (failed access attempt)