164 Part II: Oracle Database Vault The following table depicts a new DBV factor Connection_Type and its identities. We can define these identities based on these notional environment conditions with the Authentication_ Method, Client_IP, and Session_User factors contributing to identify the Connection_Type factor. Connection_Type Identity Authentication_Method Client_IP Session_User LOCAL_DBA OS or PASSWORD NULL SYS, SYSTEM CORPORATE_SSL SSL LIKE '192.168.0.%' % CORPORATE_ PASSWORD PASSWORD LIKE '192.168.0.%' % OTHER % NOT LIKE '192.168.0.%' % The approach to identifying factors based on the identity of other factors requires the following steps: 1. Define the factor to be identified by other factors. The factor that is identified by other factors is called the parent factor. 2. Define factor links between the parent and contributing factors. With the DVA web application, this factor linking is done automatically with the underlying DBMS_ MACADM APIs. 3. Define the identities for the parent factor. 4. Define factors and identities for all factors that identify the parent factor. The factors that identify the parent factor are called child factors. 5. Define the identity maps that map the identities of the child factors to the parent factor. First we define the Connection_Type factor, which is our parent factor, with a get_expr parameter set to an expression that will resolve to one of our identities for the factor. This is simply a default expression before the other factors are resolved and it should default to our least trusted identity. BEGIN dbms_macadm.create_factor( factor_name => 'Connection_Type' , factor_type_name => 'Application', description => 'Categorizes the connection security level.', rule_set_name => NULL , get_expr => 'UPPER(''OTHER'')', validate_expr => NULL, identify_by => dbms_macutl.g_identify_by_factor, labeled_by => dbms_macutl.g_labeled_by_self, eval_options => dbms_macutl.g_eval_on_session, audit_options => dbms_macutl.g_audit_on_get_error, fail_options => dbms_macutl.g_fail_with_message); END; / PL/SQL procedure successfully completed. Chapter 5: Database Vault Fundamentals 165 Next we define factor links that identify all the child factors that could be used in our identity maps (which we will define in a bit) to identify the parent factor. The PL/SQL API should be called for each child factor you plan to use in at least one identity map. dbvowner@aos> create a link for the Client IP address dbvowner@aos> BEGIN dbms_macadm.add_factor_link( parent_factor_name =>'Connection_Type', child_factor_name =>'Client_IP', label_indicator => 'N'); END; / dbvowner@aos> create a link for the Authentication Method dbvowner@aos> BEGIN dbms_macadm.add_factor_link( parent_factor_name =>'Connection_Type', child_factor_name =>'Authentication_Method', label_indicator => 'N'); END; / dbvowner@aos> create a link for the Session User dbvowner@aos> BEGIN dbms_macadm.add_factor_link( parent_factor_name =>'Connection_Type', child_factor_name =>'Session_User', label_indicator => 'N'); END; / PL/SQL procedure successfully completed. The label_indicator parameter is required for DBV’s integration capability with OLS and should be set to ‘N’ (FALSE) by default. Next we define the identities for the parent factor based on the preceding table. Four possible classifications of the connection are shown next in order of the trust we have in the connection (highest to lowest). The trust_level parameter is a number that can be defined at your discretion. The level set for each identity should be indicative the trust you would place on a session that has the identity set relative to sessions with other identities. dbvowner@aos> BEGIN create identity for LOCAL_DBA value or connections on the database console dbms_macadm.create_identity(factor_name=>'Connection_Type', value=>'LOCAL_DBA',trust_level=>4); create identity for CORPORATE_SSL value or connections within the corporate network using PKI/SSL authentication dbms_macadm.create_identity(factor_name=>'Connection_Type', value=>'CORPORATE_SSL',trust_level=>3); create identity for CORPORATE_PASSWORD value or connections within the corporate network 166 Part II: Oracle Database Vault using username/password authentication dbms_macadm.create_identity(factor_name=>'Connection_Type', value=>'CORPORATE_PASSWORD',trust_level=>2); create identity for OTHER value or connections coming from outside the corporate network, such as over a VPN connection dbms_macadm.create_identity(factor_name=>'Connection_Type', value=>'OTHER',trust_level=>1); END; / PL/SQL procedure successfully completed. Next we define the child factors whose identities will be used to resolve the parent factor. The factors that are used in this example are all installed by DBV, so we’ve saved some time in this case. The Client_IP factor will use the LIKE comparison operator in this example, so we do not need to define identities for this factor. The DBV product installs all the possible identities for the Authentication_Method factor as the following query shows: dbvowner@aos> SELECT factor_name,value FROM dvsys.dv$identity WHERE factor_name = 'Authentication_Method' ORDER BY factor_name / FACTOR_NAME VALUE Authentication_Method DCE Authentication_Method KERBEROS Authentication_Method NONE Authentication_Method OS Authentication_Method PASSWORD Authentication_Method RADIUS Authentication_Method SSL 7 rows selected. The only child factor identities that remain are the trusted accounts we want to define for the database console, SYS and SYSTEM: dbvowner@aos> BEGIN dbms_macadm.create_identity(factor_name=>'Session_User', value=>'SYS',trust_level=>10); dbms_macadm.create_identity(factor_name=>'Session_User', value=>'SYSTEM',trust_level=>10); END; / PL/SQL procedure successfully completed. The last set of steps requires us to define a set of identity conditions for the child factors that will resolve each identity of our parent factor. These mappings of child factor identities to the identity of the parent factor are called identity maps. For the LOCAL_DBA identity of the Connection_Type factor, the following identity maps will consider the authentication method, the database client’s IP address, and the name of the user: Chapter 5: Database Vault Fundamentals 167 dbvowner@aos> BEGIN WHEN authenticating by OS, such as / AS SYSDBA, or by PASSWORD dbms_macadm.create_identity_map( identity_factor_name => 'Connection_Type' , identity_factor_value => 'LOCAL_DBA' , parent_factor_name => 'Connection_Type' , child_factor_name =>'Authentication_Method' , operation => '=' , operand1 => 'OS' , operand2 => NULL ); dbms_macadm.create_identity_map( identity_factor_name => 'Connection_Type' , identity_factor_value => 'LOCAL_DBA' , parent_factor_name => 'Connection_Type' , child_factor_name =>'Authentication_Method' , operation => '=' , operand1 => 'PASSWORD' , operand2 => NULL ); AND the client IP address is NULL, as is the case when logging into the database on the console outside the control of the database listener, or when the IP address is that of the database server when coming through the listener. dbms_macadm.create_identity_map( identity_factor_name => 'Connection_Type' , identity_factor_value => 'LOCAL_DBA' , parent_factor_name => 'Connection_Type' , child_factor_name =>'Client_IP' , operation => 'IS NULL' , operand1 => 'NULL' , operand2 => NULL ); dbms_macadm.create_identity_map( identity_factor_name => 'Connection_Type' , identity_factor_value => 'LOCAL_DBA' , parent_factor_name => 'Connection_Type' , child_factor_name =>'Client_IP' , operation => '=' , operand1 => '192.168.0.251' , operand2 => NULL ); AND the user is SYS or SYSTEM dbms_macadm.create_identity_map( identity_factor_name => 'Connection_Type' , identity_factor_value => 'LOCAL_DBA' , parent_factor_name => 'Connection_Type' , child_factor_name =>'Session_User' , operation => '=' , operand1 => 'SYS' , operand2 => NULL ); dbms_macadm.create_identity_map( identity_factor_name => 'Connection_Type' , identity_factor_value => 'LOCAL_DBA' 168 Part II: Oracle Database Vault , parent_factor_name => 'Connection_Type' , child_factor_name =>'Session_User' , operation => '=' , operand1 => 'SYSTEM' , operand2 => NULL ); END; / PL/SQL procedure successfully completed. It is important that you understand the processing logic for a DBV identity map that makes use of multiple child factors and more than one factor identity in the map configuration. The preceding map has three child factors that will be evaluated with AND logic. For multiple identities within each child factor, such as the case with the Authentication_Method, Client_IP, and Session_User identities used, the evaluation will use an OR logic within each child factor. In other words, the DBV identity map for the Connection_Type = 'LOCAL_DBA' will be TRUE when the following occurs: ( Authentication_Method = 'OS' OR Authentication_Method = 'PASSWORD' ) AND ( Client_IP IS NULL OR Client_IP = '192.168.0.251' ) AND (Session_User = 'SYS' OR Session_User = 'SYSTEM') For the CORPORATE_SSL identity, the following identity maps consider the authentication method and the database client’s IP address: dbvowner@aos> BEGIN WHEN the authentication method is PKI/SSL (certificate) dbms_macadm.create_identity_map( identity_factor_name => 'Connection_Type' , identity_factor_value => 'CORPORATE_SSL' , parent_factor_name => 'Connection_Type' , child_factor_name =>'Authentication_Method' , operation => '=' , operand1 => 'SSL' , operand2 => NULL ); AND the client's IP address is on the corporate network, which we have defined as the 192.168.0 subnet dbms_macadm.create_identity_map( identity_factor_name => 'Connection_Type' , identity_factor_value => 'CORPORATE_SSL' , parent_factor_name => 'Connection_Type' , child_factor_name =>'Client_IP' , operation => 'LIKE' , operand1 => '192.168.0%' , operand2 => NULL ); END; / PL/SQL procedure successfully completed. For the CORPORATE_PASSWORD identity, the following identity maps consider the authentication method and the database client’s IP address: Chapter 5: Database Vault Fundamentals 169 dbvowner@aos> BEGIN WHEN the authentication method is PASSWORD dbms_macadm.create_identity_map( identity_factor_name => 'Connection_Type' , identity_factor_value => 'CORPORATE_PASSWORD' , parent_factor_name => 'Connection_Type' , child_factor_name =>'Authentication_Method' , operation => '=' , operand1 => 'PASSWORD' , operand2 => NULL ); AND the client's IP address is on the corporate network, which we have defined as the 192.168.0 subnet dbms_macadm.create_identity_map( identity_factor_name => 'Connection_Type' , identity_factor_value => 'CORPORATE_PASSWORD' , parent_factor_name => 'Connection_Type' , child_factor_name =>'Client_IP' , operation => 'LIKE' , operand1 => '192.168.0%' , operand2 => NULL ); END; / PL/SQL procedure successfully completed. For the OTHER identity, the identity map is simply based on the database client’s IP address not being on the 192.168.0 subnet and is coming from some other network: dbvowner@aos> BEGIN dbms_macadm.create_identity_map( identity_factor_name => 'Connection_Type' , identity_factor_value => 'OTHER' , parent_factor_name => 'Connection_Type' , child_factor_name =>'Client_IP' , operation => 'NOT LIKE' , operand1 => '192.169.0.%' , operand2 => NULL ); END; / PL/SQL procedure successfully completed. dbvowner@aos>COMMIT; Commit completed. Now that DBV identity maps are defined, we can test them under various scenarios to understand how they work. If we log in as SYS on the database console, we should expect the Connection_Type factor to resolve to LOCAL_DBA: $ sqlplus / AS SYSDBA SQL*Plus: Release 11.1.0.6.0 - Production on Sat Feb 21 17:18:04 2009 Copyright (c) 1982, 2007, Oracle. All rights reserved. 170 Part II: Oracle Database Vault Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production With the Partitioning, Oracle Label Security, OLAP, Data Mining, Oracle Database Vault and Real Application Testing options sys@aos> SELECT DVSYS.GET_FACTOR('Connection_Type') Connection_Type , DVSYS.GET_FACTOR('Authentication_Method') Authentication_Method , DVSYS.GET_FACTOR('Client_IP') Client_IP FROM DUAL; CONNECTION AUTHENTICA CLIENT_IP LOCAL_DBA OS 1 row selected. If we log in as MARY on the corporate network using password authentication, for example, we should expect the Connection_Type factor to resolve to CORPORATE_PASSWORD: $ sqlplus mary@aos SQL*Plus: Release 11.1.0.6.0 - Production on Sat Feb 21 17:14:42 2009 Copyright (c) 1982, 2007, Oracle. All rights reserved. Enter password: Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production With the Partitioning, Oracle Label Security, OLAP, Data Mining, Oracle Database Vault and Real Application Testing options mary@aos>SELECT DVSYS.GET_FACTOR('Connection_Type') Connection_Type , DVSYS.GET_FACTOR('Authentication_Method') Authentication_Method , DVSYS.GET_FACTOR('Client_IP') Client_IP FROM DUAL; CONNECTION_TYPE AUTHENTICATION_METHO CLIENT_IP CORPORATE_PASSWORD PASSWORD 192.168.0.200 1 row selected. If we log in as MARY over a VPN connection, with an access point external to the corporate network, we should expect the Connection_Type factor to resolve to the value 'OTHER': C:\> sqlplus mary@aos SQL*Plus: Release 11.1.0.6.0 - Production on Sat Feb 21 17:14:42 2009 Copyright (c) 1982, 2007, Oracle. All rights reserved. Enter password: Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production With the Partitioning, Oracle Label Security, OLAP, Data Mining, Oracle Database Vault and Real Application Testing options mary@aos>SELECT DVSYS.GET_FACTOR('Connection_Type') Connection_Type , DVSYS.GET_FACTOR('Authentication_Method') Authentication_Method , DVSYS.GET_FACTOR('Client_IP') Client_IP FROM DUAL; Chapter 5: Database Vault Fundamentals 171 CONNECTION_TYPE AUTHENTICATION_METHO CLIENT_IP OTHER PASSWORD 10.10.10.10 1 row selected. This example demonstrates how to create a security-relevant factor whose foundation is based on multiple (other) factors using a declarative method that required no PL/SQL programming. The factors we used in this example are provided by the database kernel code, but your custom factors could also be used with this approach. You can establish a multifactor security policy when these factors are used DBV rule sets or in your own PL/SQL code. Consider the DBV CONNECT command rule example presented earlier. In this example, two DBV rules were used to authorize a connection to the database. The rules ‘Is Secure Authentication Method’ and ‘Is Console Client’ examined the authentication method and database client’s IP address in a manner similar to the way that the Connection_Type factor is identified. We can replace these two DBV rules with a single DBV rule, ‘Is Trusted Client’, to achieve the same result simply by checking for the factor Connection_Type not being ‘OTHER’, as shown in this example: dbvowner@aos> BEGIN dbms_macadm.create_rule( rule_name => 'Is Trusted Client' , rule_expr => 'DVSYS.GET_FACTOR(''Connection_Type'') <> ''OTHER''' ); END; / PL/SQL procedure successfully completed. To demonstrate multifactor security within PL/SQL, we can create a VPD policy on the CUSTOMERS table in the Sales History (SH) schema. In this policy, we will use the factor in the VPD policy function to provide either column-level or row-level security on the table. First we need to grant a named account the ability to manage VPD policy. The realm owner of the Sales History realm, MARY, is authorized to perform not only administration on objects in the SH object owner account, but she can also perform VPD policy administration on the objects. The only step that is required to enable this VPD administration is to grant MARY execute privileges on the VPD administration package, SYS.DBMS_RLS. This package is protected by the Oracle Database Vault realm and requires the DV_OWNER role to grant the privilege. dbvowner@aos> GRANT EXECUTE ON sys.dbms_rls TO mary; MARY must first create the VPD policy function that will leverage our factor to provide row-level security on the SH.CUSTOMERS table: mary@aos>CREATE OR REPLACE FUNCTION sh.customer_policy_function( schema_name IN VARCHAR2 , table_name IN VARCHAR2 ) RETURN VARCHAR2 AS BEGIN prevent access to sensitive customer data outside of the corporate network 172 Part II: Oracle Database Vault IF schema_name = 'SH' AND table_name = 'CUSTOMERS' THEN when the connection type factor is OTHER we know the database client has not connection from the corporate network IF DVSYS.GET_FACTOR('CONNECTION_TYPE') = 'OTHER' THEN RETURN '1=0'; for all other connection types allow access to all rows ELSE RETURN '1=1'; END IF; END IF; END; / Function created. Next MARY can create a VPD policy using the DBMS_RLS package. In this example policy, we will restrict just the ability to show sensitive columns such as date of birth, marital status, and income outside of the corporate network: mary@aos> BEGIN dbms_rls.add_policy( object_schema => 'SH' ,object_name => 'CUSTOMERS' ,policy_name => 'POLICY_CUSTOMERS' ,function_schema => 'SH' ,policy_function => 'CUSTOMER_POLICY_FUNCTION' || ,sec_relevant_cols => 'CUST_GENDER,CUST_YEAR_OF_BIRTH' || ',CUST_MARITAL_STATUS,CUST_INCOME_LEVEL,CUST_CREDIT_LIMIT' ,sec_relevant_cols_opt => dbms_rls.all_rows ); END; / PL/SQL procedure successfully completed. If MARY queries the SH.CUSTOMERS table from within the corporate network, the security sensitive columns are visible: mary@aos> show the Connection_Type factor and session context mary@aos>SELECT DVSYS.GET_FACTOR('Connection_Type') Connection_Type , DVSYS.GET_FACTOR('Authentication_Method') Authentication_Method , DVSYS.GET_FACTOR('Client_IP') Client_IP FROM DUAL; CONNECTION_TYPE AUTHENTICATION_METHO CLIENT_IP CORPORATE_PASSWORD PASSWORD 192.168.0.200 1 row selected. Chapter 5: Database Vault Fundamentals 173 mary@aos> query the SH.CUSTOMERS table mary@aos> SELECT cust_last_name , cust_year_of_birth , cust_marital_status , cust_income_level FROM sh.customers WHERE cust_state_province = 'TX' AND ROWNUM < 10 ORDER BY cust_last_name / CUST_LAST_ CUST_YEAR_OF_BIRTH CUST_MARIT CUST_INCOME_LEVEL Beiers 1982 single K: 250,000 - 299,999 Duval 1981 single H: 150,000 - 169,999 Greeley 1977 F: 110,000 - 129,999 Grover 1970 married D: 70,000 - 89,999 Hamilton 1961 single G: 130,000 - 149,999 Krider 1967 F: 110,000 - 129,999 Majors 1948 single G: 130,000 - 149,999 Rowley 1969 single H: 150,000 - 169,999 Stone 1978 single I: 170,000 - 189,999 9 rows selected. If MARY queries the SH.CUSTOMERS table from outside the corporate network, the security sensitive columns are not visible and VPD will set them to NULL in the result set returned: mary@aos> show the Connection_Type factor and session context mary@aos>SELECT DVSYS.GET_FACTOR('Connection_Type') Connection_Type , DVSYS.GET_FACTOR('Authentication_Method') Authentication_Method , DVSYS.GET_FACTOR('Client_IP') Client_IP FROM DUAL; CONNECTION_TYPE AUTHENTICATION_METHO CLIENT_IP OTHER PASSWORD 10.10.10.10 1 row selected. mary@aos> query the SH.CUSTOMERS table mary@aos> SELECT cust_last_name , cust_year_of_birth , cust_marital_status , cust_income_level FROM sh.customers WHERE cust_state_province = 'TX' AND ROWNUM < 10 ORDER BY cust_last_name / . 2007, Oracle. All rights reserved. 170 Part II: Oracle Database Vault Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production With the Partitioning, Oracle. operand1 => 'PASSWORD' , operand2 => NULL ); AND the client IP address is NULL, as is the case when logging into the database on the console outside the control of the database. (c) 1982, 2007, Oracle. All rights reserved. Enter password: Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production With the Partitioning, Oracle Label Security,