184 Part II: Oracle Database Vault mary@aos> query MARY's OLS authorization and mary@aos> the effective OLS session label mary@aos> SELECT sa_session.label('CUSTOMER_POLICY') "EFFECTIVE_SESSION_LABEL" FROM DUAL; EFFECTIVE_SESSION_LABEL LOW 1 row selected. mary@aos> attempt to set the session label to HIGH mary@aos> which MARY is in fact authorized but the mary@aos> session, under DBV control, is not mary@aos> EXECUTE sa_session.set_label('CUSTOMER_POLICY','HIGH'); BEGIN sa_session.set_label('CUSTOMER_POLICY','HIGH'); END; * ERROR at line 1: ORA-47905: OLS policy label HIGH is not allowed for policy CUSTOMER_POLICY ORA-06512: at "DVSYS.DBMS_MACUTL", line 38 ORA-06512: at "DVSYS.DBMS_MACUTL", line 381 ORA-06512: at "DVSYS.DBMS_MACOLS_SESSION", line 116 ORA-06512: at line 1 ORA-06512: at "LBACSYS.SA_SESSION", line 415 ORA-06512: at "LBACSYS.SA_SESSION", line 426 ORA-06512: at line 1 (2 Factor Assignment DBV factors can be configured to allow the identity to be assigned by a database session at runtime using the procedure DVSYS.SET_FACTOR. This feature may seem a little scary at first glance, as we must use caution designing application security around information provided by the client. The assignment of a DBV factor’s identity, if configured, is controlled by a DBV rule set that must be true for the assignment to be authorized. Accepting client information in an application is a common practice in Oracle database applications. For example, many three-tier systems (client, application server, database server) rely on the use of database connection pools from the application server to the database server. These connection pools use a dedicated database account and need a mechanism to assert information about the client (such as the identity of the user) as discussed in Chapter 1. The organization maintaining the application may not have the option to migrate the application to use Oracle Enterprise User Security (EUS) and Oracle Proxy Authentication, but the audit attribution is still required for any database actions performed on behalf of the user. The use of techniques such as setting CLIENT_IDENTIFIER through DBMS_SESSION.SET_ IDENTIFIER are standards used in many applications where information is accepted from the client to ensure the audit attribution, because this CLIENT_IDENTIFIER information is tracked within the standard Oracle RDMS audit trail. Another common practice in Oracle database applications is for developers to create an Oracle application context, and the associated PL/SQL package, using the CREATE CONTEXT <context_name> USING <package name> command. These application contexts are used to track information through the lifetime of the database session so that a “session variable” can be set at one point in time and accessed at a later point in time in the session. This technique is often used in conjunction with Oracle VPD policy functions. Chapter 5: Database Vault Fundamentals 185 DBV factor assignment offers the ability to support the CLIENT_IDENTIFIER technique and the requirements of Oracle application contexts with the following benefits: The ability to assign the information is controlled by a DBV rule set rather than being an open API. In other words, nothing prevents a database session in SQL*Plus from using DBMS_SESSION.SET_IDENTIFIER to masquerade the session’s activity as another end user from the perspective of the audit trail. The use of a DBV rule set provides your security administrator with a mechanism to control the sessions and the conditions that will allow the assignment. The level of trust is specific to your application environment. The approach requires less overhead and maintenance because the application developer does not need to create a new application context or supporting PL/SQL package. These database objects are already provided by DBV factors. The assignment can leverage DBV factor validation to ensure that the data assigned meets the criteria required by the application. DBV factor assignment can be audited through the use of the audit configuration of the DBV rule set that controls the assignment. DBV factor assignment can also be audited in the same manner that auditing the execution of DBMS_SESSION or an application context’s PL/SQL package, which is to AUDIT EXECUTE ON DVSYS.SET_FACTOR. To illustrate DBV factor assignment, consider the following scenario (see Figure 5-11). A web-based Sales History application is running on an application server. The application uses a dedicated account for connection pool and the application uses DBMS_SESSION.SET_IDENTIFIER to assert the real end user for audit attribution. To use DBV factor assignment in lieu of DBMS_ SESSION.SET_IDENTIFIER, we need to create a DBV factor and determine the conditions that must be met to authorize the assignment of this factor in a DBV rule set. We can use database session context information that is available when ASO PKI/SSL authentication is used from the application server to the database as a basis for these conditions. We can place some level of trust in the session because both the application server and database server must be configured to participate in a PKI trust relationship using Oracle wallets (something we have). If the organization’s certificate authority (CA) and PKI controls are sound and the physical access to the machines is controlled, we can place an even greater level of trust in the use of this information. The added benefit of the configuration is that all the network communications between the application server and the database server (in support of database session) are encrypted. For the sake of brevity, let’s assume we have configured ASO PKI/SSL authentication between our application server and database server. NOTE If you would like more details on how to set up this type of authentication for the enterprise and a formal CA, read Oracle Metalink note “736510.1 - Step by Step Guide to Configure SSL Authentication”. If you want to set up a development capability quickly using self-signed Oracle wallets, refer to Oracle Metalink note “762286.1 - End to End Examples of Using SSL with Oracle’s JDBC THIN Driver” or the white paper “SSL With Oracle JDBC Thin Driver” available on the Oracle Technology Network (OTN) at www .oracle.com/technology/tech/java/sqlj_jdbc/pdf/wp-oracle-jdbc_thin_ ssl_2007.pdf. These resources will walk you through how the steps to create and configure your Oracle wallets and the Oracle networking files for ASO PKI/SSL authentication. ■ ■ ■ 186 Part II: Oracle Database Vault Once configured, we can create the database account that is identified based on the client’s (our application server) wallet credentials as follows: dbvacctmgr@aos> create the account dbvacctmgr@aos> CREATE USER ops$appserver_1 IDENTIFIED EXTERNALLY AS 'CN=appserver_1'; User created. dbvacctmgr@aos> provide the ability to connect to the database dbvacctmgr@aos> CONNECT / AS SYSDBA Connected. sys@aos> GRANT CREATE SESSION TO ops$appserver_1; Grant succeeded. Creating this type of account requires the database initialization parameter setting OS_ AUTHENT_PREFIX=ops$, where ops$ can be customized for the particular environment. Once we have created this account, we can connect to the database to examine the type of session context information that can be used as conditions in our DBV rule set. Database authentication using ASO/PKI will expose the use of the Oracle Secure Transmission Control Protocol (TCPS), the authentication method, the subject of the certificate, and the context of the X.509 certificate (in HEX2 format) in the session context information. ops$appserver_1@aos> query the network protocol ops$appserver_1@aos>SELECT SYS_CONTEXT('USERENV','NETWORK_PROTOCOL') "NETWORK PROTCOL" FROM DUAL; NETWORK PROTCOL tcps 1 row selected. ops$appserver_1@aos> query the authentication method ops$appserver_1@aos>SELECT SYS_CONTEXT('USERENV','AUTHENTICATION_METHOD') "AUTHENTICATION METHOD" FROM DUAL; FIGURE 5-11 Oracle Advanced Security certificate usage Chapter 5: Database Vault Fundamentals 187 AUTHENTICATION METHOD SSL 1 row selected. ops$appserver_1@aos> query the subject of the X.509 certificate ops$appserver_1@aos>SELECT SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY') "X.509 ERTIFICATE SUBJECT" FROM DUAL; X.509 CERTIFICATE SUBJECT CN=appserver_1 1 row selected. ops$appserver_1@aos> query the context of the X.509 certificate ops$appserver_1@aos>SELECT SYS_CONTEXT('USERENV','AUTHENTICATION_DATA') "X.509 CERTIFICATE CONTEXT" FROM DUAL; X.509 CERTIFICATE CONTEXT 3082019B30820104020100300D06092A864886F70D010104050030163114301206035504030C0B61 70707365727665725F31301E170D3039303232353037303231315A170D3139303232333037303231 315A30163114301206035504030C0B6170707365727665725F3130819F300D06092A864886F70D01 0101050003818D00 1 row selected. In reviewing the session context information available under ASO/PKI authentication, we find that the network protocol is set to TCPS versus the typical TCP protocol. In addition, the authentication data that returns the X.509 certificate context will be unique for each wallet issued by our CA, so we can leverage this information to identify a client uniquely with the correct wallet. Using the network protocol and certificate context is another example of using multiple factors in your database security policy. This policy cannot replace physical security that protects the Oracle wallets from theft and defensive measures such as using the invited nodes feature of the listener to control the machines that can connect to the listener. The next step is for the DBV security administrator (DBVOWNER) to create a factor for the X.509 certificate context from the read-only session context maintained by the Oracle kernel. DBV is installed with a DBV factor for the network protocol, so we do not need to define it to use it in a DBV rule. dbvowner@aos> BEGIN dbms_macadm.create_factor( factor_name => 'Certificate_Context' , factor_type_name => 'Authentication Method', description => 'Retrieves the context of the X.509 certificate' ||' when used with the TCPS network protocol.', rule_set_name => NULL , get_expr => 'SUBSTR(SYS_CONTEXT(''USERENV'',''AUTHENTICATION_DATA''),1,255)', 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. 188 Part II: Oracle Database Vault The next step is to create our DBV rule set components that will control the assignment of the factor we create to store the Sales History application end user name. The DBV rules will leverage the DBV factors we’ve chosen. dbvowner@aos> create the rule that checks for an authorized client dbvowner@aos> certificate context dbvowner@aos> DECLARE l_certificate_context VARCHAR2(1024) := '3082019B30820104020100300D06092A864886F' || '70D010104050030163114301206035504030C0B61' || '70707365727665725F31301E170D30393032323530' || '37303231315A170D3139303232333037303231' || '315A30163114301206035504030C0B617070736572' || '7665725F3130819F300D06092A864886F70D01' || '0101050003818D0'; BEGIN dbms_macadm.create_rule( rule_name => 'Is Valid Certificate' , rule_expr => 'NVL(DVF.F$Certificate_Context,''0'') IN (''' || l_certificate_context || ''')' ); END; / PL/SQL procedure successfully completed. dbvowner@aos> create a rule that checks for a valid network protocol dbvowner@aos> BEGIN dbms_macadm.create_rule( rule_name => 'Is TCPS Protocol' , rule_expr => 'NVL(DVF.F$Network_Protocol,''0'') = ''TCPS''' ); END; / PL/SQL procedure successfully completed. dbvowner@aos> finally create a rule set that will group our rules dbvowner@aos> that allow session assignment. We will audit all dbvowner@aos> evaluations for the rule set for our demonstration dbvowner@aos> BEGIN dbms_macadm.create_rule_set( rule_set_name =>'Can Assign Client Identifier', description => 'Checks to verify that a DBV-based client identifier can be set.', enabled =>dbms_macutl.g_yes, eval_options =>dbms_macutl.g_ruleset_eval_all, audit_options =>dbms_macutl.g_ruleset_audit_fail + dbms_macutl.g_ruleset_audit_success, fail_options =>dbms_macutl.g_ruleset_fail_show, fail_message =>NULL, Chapter 5: Database Vault Fundamentals 189 fail_code =>NULL, handler_options =>dbms_macutl.g_ruleset_handler_off, handler =>NULL); END; / PL/SQL procedure successfully completed. dbvowner@aos> associate the client certificate rule to the rule set BEGIN dbms_macadm.add_rule_to_rule_set ( rule_set_name => 'Can Assign Client Identifier' , rule_name => 'Is Valid Certificate' ); END; / PL/SQL procedure successfully completed. dbvowner@aos> associate the network protocol rule to the rule set BEGIN dbms_macadm.add_rule_to_rule_set ( rule_set_name => 'Can Assign Client Identifier' , rule_name => 'Is TCPS Protocol' ); END; / PL/SQL procedure successfully completed. COMMIT; Commit complete. Given the fact that wallets can be changed as part of key management and more than one application server would be in use, we would want to store the certificates in a table (protected by a DBV realm). The rule ‘Is Valid Certificate’ is written for brevity’s sake, and it would be more ideal to create PL/SQL function for this rule and query the table of certificates. The goal of our example is to provide an alternative form of the procedure DBMS_SESSION.SET_IDENTIFIER that is based on trust. We cannot implement a separate capability that reproduces the behavior that CLIENT_IDENTIFIER is audited in the core RDBMS audit trail, SYSTEM.AUD$. In fact, we do not have to reproduce it. DBV factors will still let us use the native capability using a feature called factor validation. Factor Validation DBV factors can also be configured to allow for the identity of a factor to be validated with a callout to a PL/SQL routine. This PL/SQL routine will be called whenever the function DVSYS. GET_FACTOR is called, the DVF.F$ factor function is called, or the DVSYS.SET_FACTOR function is called. With this mechanism, we could establish a “trust but verify” model whereby DBV can verify that the identity is correct with respect to our own rules. In our example, the factor assignment may be authorized but we might also have a requirement to validate the end user value set against a table that contains user names. If the identity fails validation, it will be set to NULL so that other areas of DBV policy, such as subsequent use of the DBV factor in a DBV rule 190 Part II: Oracle Database Vault set, can handle this fact. This validation routine could also include all of the logic we might normally place in the PL/SQL package that supports an Oracle application context in use by an organization. To implement this feature, we simply need to define a PL/SQL function with the following signature: FUNCTION IS_VALID(p_factor_value VARCHAR2) RETURN BOOLEAN The following example code demonstrates how a very simple validation function may be defined for our scenario that uses DBMS_SESSION.SET_IDENTIFIER to preserve the audit behavior it provides: mary@aos> CREATE OR REPLACE FUNCTION sh.valid_client_identifier( p_factor_value IN VARCHAR2 ) RETURN BOOLEAN IS BEGIN a simple mechanism to test for a valid factor identity IF p_factor_value IS NULL OR p_factor_value = '0' THEN for demonstration let's populate CLIENT IDENTIFIER dbms_session.set_identifier('ANONYMOUS SALES HISTORY USER'); returning FALSE clears the factor value (NULL) RETURN FALSE; ELSE this logic preserves the audit attribution capability of the CLIENT IDENTIFIER feature in Oracle dbms_session.set_identifier(p_factor_value); the logic in this ELSE block could just as easily check a table for a list of valid application users or even connect to an external system to valid the user name supplied to the function returning TRUE preserves the factor value RETURN TRUE; END IF; END; / Function created. mary@aos> execute privileges on the validation routine must mary@aos> be granted to DVSYS mary@aos> GRANT EXECUTE ON sh.valid_client_identifier TO dvsys; Grant succeeded. With our DBV rule set for factor assignment in place, as well as a validation routine, we can define the Client_Identifier factor. In this procedure call, we supply the name of the DBV rule set that controls factor assignment in the rule_set_name parameter. We supply the object-owning schema and function name of our validation routine in the validate_expr parameter. Chapter 5: Database Vault Fundamentals 191 dbvowner@aos> create the DBV version of a client identifier dbvowner@aos> BEGIN dbms_macadm.create_factor( factor_name => 'Client_Identifier' , factor_type_name => 'User', description => 'Factor that holds the Sales History application end user' ||' when used with the TCPS network protocol.' ||' Alternative to the CLIENT IDENTIFIER feature.', rule_set_name => 'Can Assign Client Identifier', get_expr => 'TO_CHAR(0)', validate_expr => 'SH.VALID_CLIENT_IDENTIFIER', 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. COMMIT; Commit complete. We can now test the assignment of this DBV factor with our certificate-based application server account ops$appserver_1 using ASO PKI/SSL authentication to the database: ops$appserver_1@aos> the default state of the factor is NULL ops$appserver_1@aos> because our validation routine returned ops$appserver_1@aos> a boolean value of FALSE ops$appserver_1@aos> SELECT DVF.F$Client_Identifier FROM dual; F$CLIENT_IDENTIFIER 1 row selected. ops$appserver_1@aos> the CLIENT IDENTIFIER session context ops$appserver_1@aos> information also demonstrates the execution ops$appserver_1@aos> validation of our routine at session startup ops$appserver_1@aos> SELECT SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') FROM dual; SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') ANONYMOUS SALES HISTORY USER 1 row selected. ops$appserver_1@aos> we can now attempt to set the DBV version of ops$appserver_1@aos> client identifier and it will succeed based 192 Part II: Oracle Database Vault ops$appserver_1@aos> on the correct client certificate being asserted ops$appserver_1@aos> BEGIN dvsys.set_factor('Client_Identifier','jeffrey@mycompany.com'); END; / PL/SQL procedure successfully completed. ops$appserver_1@aos> the factor now has the identity supplied ops$appserver_1@aos> set appropriately because our validation ops$appserver_1@aos> routine returned a boolean value of TRUE ops$appserver_1@aos> SELECT DVF.F$Client_Identifier FROM dual; F$CLIENT_IDENTIFIER jeffrey@mycompany.com 1 row selected. ops$appserver_1@aos> the CLIENT IDENTIFIER session context ops$appserver_1@aos> is also populated as expected based on the code ops$appserver_1@aos> defined in the validation function ops$appserver_1@aos> SELECTSYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') FROM dual; SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') jeffrey@mycompany.com 1 row selected. We can also test the ability to perform the assignment of this DBV factor with a certificate- based desktop user account ops$jeffrey using ASO PKI/SSL authentication to the database with a different Oracle wallet than the one we defined as trusted. ops$jeffrey@aos> we attempt to set the DBV version of ops$jeffrey@aos> client identifier and it will fail based ops$jeffrey@aos> on an untrusted client certificate being asserted ops$jeffrey@aos> EXECUTE dvsys.set_factor('Client_Identifier','jeffrey@mycompany.com'); BEGIN dvsys.set_factor('Client_Identifier','jeffrey@mycompany.com'); END; * ERROR at line 1: ORA-47391: attempt to set Factor CLIENT_IDENTIFIER violates Rule Set Can Assign Client Identifier ORA-06512: at "DVSYS.DBMS_MACSEC", line 3 ORA-06512: at "DVSYS.DBMS_MACSEC", line 54 ORA-06512: at "DVSYS.SET_FACTOR", line 5 ORA-06512: at line 1 ops$jeffrey@aos> the default state of the factor is NULL ops$jeffrey@aos> and preserved when the rule set ops$jeffrey@aos> authorization fails ops$jeffrey@aos> SELECT DVF.F$Client_Identifier FROM dual; F$CLIENT_IDENTIFIER Chapter 5: Database Vault Fundamentals 193 1 row selected. ops$jeffrey@aos> the default CLIENT IDENTIFIER session context ops$jeffrey@aos> information is also preserved ops$jeffrey@aos> SELECT SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') FROM dual; SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') ANONYMOUS SALES HISTORY USER 1 row selected. The DBV security administrator can view the DBV audit records for the factor assignment test cases using the DVA web application. This report (shown in Figure 5-12) queries the table DVSYS.AUDIT_TRAIL$ and the information can be correlated with the standard Oracle RDBMS audit trail stored in the SYSTEM.AUD$ table and exposed through the DBA_AUDIT_TRAIL view. The database administrator can query the DBA_AUDIT_TRAIL view for audit events where the CLIENT_ID column is populated with the successfully assigned factor values from our test. We had integrated the DBMS_SESSION.SET_IDENTIFIER procedure that populates this CLIENT_ID column within the DBV factor validation method to ensure that our audit attribution capability remains intact. The following query shows audit records that would be created if the Sales History web application issued a DELETE statement on the SH.SALES table when using the connection pool account ops$appserver_1: sys@aos> SELECT username,client_id,action_name,owner,obj_name FROM dba_audit_trail WHERE owner = 'SH'; USERNAME CLIENT_ID ACTION_NAME OWNER OBJ_NAME OPS$APPSERVER_1 jeffrey@mycompany.com DELETE SH SALES FIGURE 5-12 Factor audit report . and configure your Oracle wallets and the Oracle networking files for ASO PKI/SSL authentication. ■ ■ ■ 186 Part II: Oracle Database Vault Once configured, we can create the database account that. DVSYS.AUDIT_TRAIL$ and the information can be correlated with the standard Oracle RDBMS audit trail stored in the SYSTEM.AUD$ table and exposed through the DBA_AUDIT_TRAIL view. The database administrator. Oracle RDMS audit trail. Another common practice in Oracle database applications is for developers to create an Oracle application context, and the associated PL/SQL package, using the CREATE