Applied Oracle Security: Developing Secure Database and Middleware Environments- P34 potx

304 Part II: Oracle Database Vault FIGURE 7-1 EUS global schema mapping FIGURE 7-2 EUS Enterprise role and database global role Chapter 7: Applied Database Vault for Existing Applications 305 Once this configuration is complete, we can immediately leverage externally defined users in the organization as our realm administrators. A key point to this capability is that the membership in the EUS enterprise role SH_DATA_ADMIN_ENTERPRISE, a directory groupOfUniqueNames object, is also controlled externally and can be leveraged in more than just a single database in the organization. For example, if we log in as the EUS user JOE, we can see that his database session roles and privileges reflect being the Sales History application data administrator. sam_sec_mgr@aos>CONNECT joe Enter password: Connected. global_oid_tree1@aos>SELECT SYS_CONTEXT('USERENV','EXTERNAL_NAME') FROM dual; SYS_CONTEXT('USERENV','EXTERNAL_NAME') cn=joe,cn=users,dc=us,dc=oracle,dc=com 1 row selected. global_oid_tree1@aos> show the session roles that include global_oid_tree1@aos> the SH_DATA_ADMIN_0101 role FIGURE 7-3 EUS-based application security administrators 306 Part II: Oracle Database Vault global_oid_tree1@aos>SELECT * FROM session_roles ORDER BY 1; ROLE BASE_DATA_ADMIN_0101 DV_PUBLIC SH_DATA_ADMIN_0101 SH_DATA_ADMIN_GLOBAL 4 rows selected. global_oid_tree1@aos> show the session privileges global_oid_tree1@aos> that include privileges like AUDIT ANY (object) global_oid_tree1@aos>SELECT * FROM session_privs ORDER BY 1; PRIVILEGE CREATE SESSION DELETE ANY TABLE EXECUTE ANY INDEXTYPE EXECUTE ANY OPERATOR EXECUTE ANY PROCEDURE EXECUTE ANY TYPE INSERT ANY TABLE SELECT ANY SEQUENCE SELECT ANY TABLE UPDATE ANY TABLE 10 rows selected. global_oid_tree1@aos> attempt to use the SELECT ANY privilege global_oid_tree1@aos> on a table that is protected by the global_oid_tree1@aos> Sales History realm global_oid_tree1@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. global_oid_tree1@aos> attempt to use the SELECT ANY privilege Chapter 7: Applied Database Vault for Existing Applications 307 global_oid_tree1@aos> on a table that is protected by the global_oid_tree1@aos> Order Entry realm global_oid_tree1@aos>SELECT cust_last_name, date_of_birth, marital_status, income_level FROM oe.customers; FROM oe.customers * ERROR at line 2: ORA-01031: insufficient privileges With Oracle technologies such as Oracle Identity Manager, which is covered in Chapter 9, we could configure self-service workflows that allow a directory user such as JOE to remove himself temporarily from the application data administrator responsibility. The self-service workflow could allow JOE to delegate this function to another directory user. OIM can be configured to update the members of the SH_DATA_ADMIN_ENTERPRISE groupOfUniqueNames object with this information so that delegation of realm administration can be achieved. The use of the Oracle Virtual Directory (OVD) will even also allow us to extend the backend directory store for EUS users shown in this example to the Active Directory and Sun Java System Directory Server products. Refer to the OVD home page on the Oracle Technology Network (OTN) at www.oracle.com/technology/products/id_ mgmt/ovds/index.html for more details on this type of integration. We can extend the EUS example we’ve just presented with user identity attributes in a DBV rule set that controls the DBV realm authorization for the SH_DATA_ADMIN_0101 role. In Chapter 6 we introduced the user identity attributes that are exposed in the EUS session context’s SYS_LDAP_USER_DEFAULT namespace. Consider the case where JOE is a permanent employee and SALLY is a contractor. This fact can be stored in the identity attribute employeeType that is part of the inetOrgPerson directory object as shown in Figure 7-4. Business rules in the organization may dictate that contractors cannot delete financial data in systems such as the Sales History application. We can define a DBV rule set that leverages the employeeType attribute and the type of SQL command issued as follows: diego_dbvmgr@aos> create the rule to check for the DELETE diego_dbvmgr@aos> commands and the employeeType attribute diego_dbvmgr@aos> of PERMANENT, or DBA for non-EUS users diego_dbvmgr@aos>BEGIN dbms_macadm.create_rule( rule_name => 'DELETE By Permanent Employee Only' , rule_expr =>'(INSTR(DVSYS.DV_SQL_TEXT,''DELETE'') = 1 AND ' || 'NVL(SYS_CONTEXT(''SYS_LDAP_USER_DEFAULT'',''EMPLOYEETYPE''),''DBA'')' || ' IN (''PERMANENT'',''DBA''))' || ' OR (INSTR(DVSYS.DV_SQL_TEXT,''DELETE'') = 0)' ); END; / PL/SQL procedure successfully completed. diego_dbvmgr@aos> create the rule set and add this rule diego_dbvmgr@aos>BEGIN dbms_macadm.create_rule_set( rule_set_name =>'Sales History Data Administration Allowed', 308 Part II: Oracle Database Vault description =>'Authorizes data administration controls commands for the Sales History realm.', enabled =>dbms_macutl.g_yes, eval_options =>dbms_macutl.g_ruleset_eval_all, 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); END; / PL/SQL procedure successfully completed. diego_dbvmgr@aos>BEGIN dbms_macadm.add_rule_to_rule_set ( rule_set_name => 'Sales History Data Administration Allowed' , rule_name => 'DELETE By Permanent Employee Only' ); END; / PL/SQL procedure successfully completed. FIGURE 7-4 Identity attribute employeeType Chapter 7: Applied Database Vault for Existing Applications 309 Next we would update the realm authorization created for the SH_DATA_ADMIN_0101 role in Chapter 6 to use the new DBV rule set: diego_dbvmgr@aos>BEGIN dbms_macadm.update_realm_auth ( realm_name => 'Sales History' , grantee => 'SH_DATA_ADMIN_0101' , rule_set_name => 'Sales History Data Administration Allowed' , auth_options => dbms_macutl.g_realm_auth_participant ); END; / PL/SQL procedure successfully completed. Finally, we can test this externally controlled realm authorization using JOE and SALLY as our test accounts for a permanent and contract employee, respectively: diego_dbvmgr@aos>CONNECT joe Enter password: Connected. global_oid_tree1@aos>SELECT SYS_CONTEXT('SYS_LDAP_USER_DEFAULT','UID') USERNAME SYS_CONTEXT('SYS_LDAP_USER_DEFAULT','EMPLOYEETYPE') EMPLOYEETYPE FROM DUAL; USERNAME EMPLOYEETYPE joe PERMANENT global_oid_tree1@aos> JOE is a permanent employee and therefore global_oid_tree1@aos> is authorized for DELETE commands global_oid_tree1@aos>DELETE SH.COSTS WHERE ROWNUM < 2; 1 row deleted. global_oid_tree1@aos> next test with SALLY, who is a contractor, global_oid_tree1@aos> and attempt the same DELETE, which will not global_oid_tree1@aos> be authorized according to our DBV Rule global_oid_tree1@aos>CONNECT sally Enter password: Connected. global_oid_tree1@aos>SELECT SYS_CONTEXT('SYS_LDAP_USER_DEFAULT','UID') USERNAME SYS_CONTEXT('SYS_LDAP_USER_DEFAULT','EMPLOYEETYPE') EMPLOYEETYPE FROM DUAL; USERNAME EMPLOYEETYPE sally CONTRACTOR global_oid_tree1@aos>DELETE SH.COSTS WHERE ROWNUM < 2; DELETE SH.COSTS WHERE ROWNUM < 2 * ERROR at line 1: ORA-01031: insufficient privileges 310 Part II: Oracle Database Vault Identify End User Access Accounts and Roles for DBV SARs To identify end user access accounts, we can examine the query results for the query used to identify roles with direct object privileges for SELECT, DML, or EXECUTE on database objects in an object-owner account. The accounts that have been granted these roles are usually connection pool accounts used for end user access, and the roles themselves may even be used as global enterprise roles with the Oracle EUS technology. Due to the sensitive nature of the data accessed by these accounts and roles, you may want to consider the use of DBV SARs instead of traditional database roles. This approach allows you to apply the multifactored, rule-based control of the enablement of the role (a privilege set on sensitive objects) using some of the techniques we demonstrated with the roles SALES_MANAGER_APP_ROLE and SALES_WEB_SERVICE_APP_ROLE. We queried the view DBA_TAB_PRIVS earlier in the chapter to show accounts and roles with direct object privileges on an object-owner account’s objects. This is a first pass at the roles we need to consider as end user access accounts. We can also identify global schema accounts for EUS and externally identified accounts (for Advanced Security option (ASO)/Public Key Infrastructure (PKI)) using the following query: sys@aos>SELECT username, password FROM dba_users WHERE password IN ( 'GLOBAL' identified globally , 'EXTERNAL' identified externally ) ; USERNAME PASSWORD OPS$JEFFREY EXTERNAL OPS$APPSERVER_1 EXTERNAL GLOBAL_OID_TREE1 GLOBAL GLOBAL_OID_TREE2 GLOBAL 4 rows selected. We can identify which accounts may be used for proxy authentication, which is often used with JDBC connection pools and EUS together, using the following query: sys@aos>SELECT proxy, client FROM proxy_users ORDER BY 1; PROXY CLIENT OID_POOL_1 GLOBAL_OID_TREE1 OID_POOL_2 GLOBAL_OID_TREE2 2 rows selected. Finally, we can query the existing SARs in a database if we want to convert the application security logic used to enable these roles into DBV rules as part of any overall effort to consolidate security policies: sys@aos>SELECT * FROM dba_application_roles WHERE schema != 'DVSYS' ORDER BY 1; Chapter 7: Applied Database Vault for Existing Applications 311 ROLE SCHEMA PACKAGE CUSTOM_SECAPP_ROLE SECAPP ROLE_SECURITY 1 row selected. Identifying DBV Command Rules from Conditions To identify which commands in a database are candidates for DBV command rules, ask the following questions: What are the most sensitive transactions in the database that could affect the organization’s ability to meet compliance (or other) regulations? Which accounts are authorized to establish connections to the database, and what commands can those accounts perform? Under what conditions can each command be performed with respect to time, place, and methods (factors)? If the database supports a financial system, sensitive transactions may mean transactions related to sales (revenues) and costs (expenses). If the database supports a human resources system, this may mean transactions involving employee Social Security numbers, salaries, and health benefits. DBV command rules can be applied to these sensitive transactions to ensure that you have the highest level of assurance that they are executed within the appropriate context. The context refers to the category of factors outlined previously and can help validate whether a transaction was executed from the correct client (machines), software programs (such as PL/SQL code), business rules (such as two-person control), and within the appropriate timeframe(s). One method for determining the most sensitive transactions is to consider the frequency of each transaction with respect to other transactions in the database. In a typical financial system, we would expect “create or update” sales and costs transactions to be executed much more frequently than a “create product category” transaction. We can generate a detailed transaction frequency report that includes the database user and object being accessed in SELECT, DML, and EXECUTE transactions using the audit trail we’ve captured. This report not only provides an indicator of the most frequently occurring transactions but can also serve as the initial content for a Subject-Verb-Object-Conditions table we can use to develop a fine-grained security profile. The following query on the captured audit trail demonstrates this type of transaction frequency report: sys@aos> SELECT db_user subject, action_name verb, object_schema || '.'|| object_name object, COUNT(*) FROM aos_common_audit_trail WHERE object_schema NOT IN ( 'SYS','SYSMAN','DVF','DVSYS','LBACSYS','WK_TEST') AND ( action_name IN ( 'SELECT' ,'UPDATE' ,'DELETE' ,'INSERT' ) OR action_name LIKE '%EXECUTE%') AND object_type NOT LIKE '%PARTITION%' ■ ■ ■ 312 Part II: Oracle Database Vault GROUP BY db_user , action_name , object_schema || '.'|| object_name ORDER BY db_user , action_name , object_schema || '.'|| object_name ; SUBJECT VERB OBJECT COUNT(*) ALAN_ANALYST DELETE SH.COSTS 1 ANTHONY EXECUTE PROCEDURE SH.SALES_TRANSCTION 2 DEB_DATA_MGR DELETE SH.COSTS 1 JRUSSEL EXECUTE PROCEDURE SH.SALES_TRANSCTION 4 JRUSSEL INSERT SH.COSTS 1 JRUSSEL SELECT SH.CHANNELS 1 JRUSSEL SELECT SH.PRODUCTS 1 JRUSSEL SELECT SH.PROMOTIONS 1 MARY DELETE SH.COSTS 1 MARY DELETE SH.SALES 1 MARY EXECUTE PROCEDURE SH.SALES_TRANSCTION 2 MARY UPDATE SH.CUSTOMERS 1 OPS$APPSERVER_1 DELETE SH.SALES 1 OPS$APPSERVER_1 EXECUTE PROCEDURE SH.SALES_TRANSCTION 26 PTUCKER EXECUTE PROCEDURE SH.SALES_TRANSCTION 4 PTUCKER INSERT SH.COSTS 1 PTUCKER SELECT SH.CHANNELS 1 PTUCKER SELECT SH.PRODUCTS 1 PTUCKER SELECT SH.PROMOTIONS 1 20 rows selected. With this initial Subject-Verb-Object-Conditions table in place, we can identify the most important transactions based on the following: The frequency of the transactions Interviews with application experts to identify transactions that are either critical to the integrity of the system or corporate assets such as a balance sheet We can start the analysis to determine the conditions that bound each of these important transactions. We can develop DBV command rules for the types of transactions we uncovered in the query results once this final analysis of business conditions is completed. Limiting the Availability of Extremely Sensitive Transactions To add a level of security to sensitive transactions, you can use a database feature called Oracle External Tables (OETs). OETs provide a way to limit the ability to execute sensitive transactions to an externally controlled decision point, similar to the directory-based example we used for the realm authorizations earlier. OETs are read-only database tables that are based on information stored in flat files in the operating system. Using an approach based on OETs allows you to create a file that is owned by an OS account (or OS role) other than the Oracle software owner account (oracle). The account needs only read access to the file. The OS file will contain the information ■ ■ Chapter 7: Applied Database Vault for Existing Applications 313 that can be used to authorize or deny sensitive transactions. The OS file owner is the only account that can update the file. To implement this strategy, we use the root OS account to create a directory for the authorization file (/etc/dbv/external_authorize.conf). We will then configure the database to use the directory in the creation of the OET. In addition, we will create a directory (/var/log/dbv) for the logs generated by the OET. [root@node1 ~]# mkdir -p /etc/dbv [root@node1 ~]# mkdir -p /var/log/dbv Next we will set the permissions on these directories to allow Oracle to read the files that make up the OET and write to the supporting log file directory: [root@node1 ~]# touch /etc/dbv/external_authorize.conf [root@node1 ~]# chmod -R 750 /etc/dbv [root@node1 ~]# chown -R root:dba /etc/dbv [root@node1 ~]# chmod 750 /var/log/dbv [root@node1 ~]# chown oracle:dba /var/log/dbv The next step is to create the Oracle directories and an OET that will be based on the file. We can use our operational DBA role to create the directories and the DBVEXT account that contains extended DBV security capabilities for the OET object and supporting code: jean_oper_dba@aos> create the directories jean_oper_dba@aos>CREATE OR REPLACE DIRECTORY dbv_dir AS '/etc/dbv'; Directory created. jean_oper_dba@aos>CREATE OR REPLACE DIRECTORY dbv_dir_log AS '/var/log/dbv'; Directory created. jean_oper_dba@aos> grant privileges to the DBVEXT user jean_oper_dba@aos> to use the directories jean_oper_dba@aos>GRANT READ ON DIRECTORY dbv_dir TO dbvext; Grant succeeded. jean_oper_dba@aos>GRANT READ, WRITE ON DIRECTORY dbv_dir_log TO dbvext; Grant succeeded. jean_oper_dba@aos> create an OET under the DBVEXT object-owner account jean_oper_dba@aos>CONNECT dbvext Enter password: Connected. dvf@aos> CREATE TABLE external_authorize ( username VARCHAR2(30) , event VARCHAR2(30) , owner VARCHAR2(30) , object VARCHAR2(130) , status NUMBER ) . 304 Part II: Oracle Database Vault FIGURE 7-1 EUS global schema mapping FIGURE 7-2 EUS Enterprise role and database global role Chapter 7: Applied Database Vault for Existing Applications. connections to the database, and what commands can those accounts perform? Under what conditions can each command be performed with respect to time, place, and methods (factors)? If the database supports. Conditions To identify which commands in a database are candidates for DBV command rules, ask the following questions: What are the most sensitive transactions in the database that could affect the