264 Part II: Oracle Database Vault END; / PL/SQL procedure successfully completed. diego_dbvmgr@aos>BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Order Entry' ,object_owner => 'OE' ,object_name => '%' ,object_type => '%' ); END; / PL/SQL procedure successfully completed. diego_dbvmgr@aos>BEGIN dbms_macadm.add_auth_to_realm ( realm_name => 'Order Entry' , grantee => 'OE' , rule_set_name => NULL , auth_options => dbms_macutl.g_realm_auth_owner ); END; / PL/SQL procedure successfully completed. diego_dbvmgr@aos> the account is also able to grant the DV_OWNER or diego_dbvmgr@aos> DV_ADMIN role, resulting in a named account that diego_dbvmgr@aos> is able to perform DBV Security administration diego_dbvmgr@aos> as well as delegate that administration diego_dbvmgr@aos>GRANT dv_owner TO scott; Grant succeeded. Create Application Read-only, Read-write, and Execute Application Roles for End User Access Accounts To create read-only, read-write, and execute application roles for end user access accounts we have to understand the static or dynamic nature of the owner-owner accounts and objects being accessed by these accounts. Earlier, we stated that we should create a finite set of roles that use direct object privileges for accounts and objects that are static in nature. These types of roles should also be protected in the same DBV realm that protects the objects to which these roles are granted privileges. The following example demonstrates the use of a direct object privileges granted to the end user access roles for our Sales History schema: jean_oper_dba@aos> create the read-only SH application role jean_oper_dba@aos>CREATE ROLE sh_ro_role_0101; Role created. jean_oper_dba@aos>REVOKE sh_ro_role_0101 FROM jean_oper_dba; Revoke succeeded. jean_oper_dba@aos> create the read-write SH application role jean_oper_dba@aos>CREATE ROLE sh_rw_role_0101; Role created. jean_oper_dba@aos>REVOKE sh_rw_role_0101 FROM jean_oper_dba; Chapter 6: Applied Database Vault for Custom Applications 265 Revoke succeeded. jean_oper_dba@aos> create the execute SH application role jean_oper_dba@aos>CREATE ROLE sh_exec_role_0101; Role created. jean_oper_dba@aos>REVOKE sh_exec_role_0101 FROM jean_oper_dba; Revoke succeeded. jean_oper_dba@aos> we have to login as a DBV Security Administrator jean_oper_dba@aos> to protect the roles in the Sales History realm jean_oper_dba@aos>CONNECT diego_dbvmgr Enter password: Connected. diego_dbvmgr@aos>BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Sales History' ,object_owner => 'SH' ,object_name => 'SH_RO_ROLE_0101' ,object_type => 'ROLE' ); END; / PL/SQL procedure successfully completed. diego_dbvmgr@aos>BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Sales History' ,object_owner => 'SH' ,object_name => 'SH_RW_ROLE_0101' ,object_type => 'ROLE' ); END; / PL/SQL procedure successfully completed. diego_dbvmgr@aos>BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Sales History' ,object_owner => 'SH' ,object_name => 'SH_EXEC_ROLE_0101' ,object_type => 'ROLE' ); END; / PL/SQL procedure successfully completed. jean_oper_dba@aos> we have to login as the Sales History Security jean_oper_dba@aos> administrator to perform the object-level grants jean_oper_dba@aos>CONNECT sam_sec_mgr Enter password: Connected. sam_sec_mgr@aos>GRANT SELECT ON sh.costs TO sh_ro_role_0101; Grant succeeded. sam_sec_mgr@aos>GRANT SELECT, INSERT, UPDATE, DELETE ON sh.costs TO sh_rw_role_0101; 266 Part II: Oracle Database Vault Grant succeeded. sam_sec_mgr@aos>GRANT EXECUTE ON sh.sales_transaction TO sh_exec_role_0101; Grant succeeded. We can create and provision an account to use these roles using an approach similar to what we used for the application administrators: dbvacctmgr@aos> create the end-user access account dbvacctmgr@aos> CREATE USER ellen_enduser IDENTIFIED BY <password>; User created. dbvacctmgr@aos> expire the password for the account so they are dbvacctmgr@aos> forced to change it to a password dbvacctmgr@aos> they can control at next login dbvacctmgr@aos>ALTER USER ellen_enduser PASSWORD EXPIRE; User altered. dbvacctmgr@aos>CONNECT jean_oper_dba Enter password: Connected. jean_oper_dba@aos> provide the ability to connect to the database GRANT CREATE SESSION TO ellen_enduser; Grant succeeded. jean_oper_dba@aos> we have to login as the Sales History Security jean_oper_dba@aos> administrator to perform the grants jean_oper_dba@aos> of these end-user access roles jean_oper_dba@aos>CONNECT sam_sec_mgr Enter password: Connected. sam_sec_mgr@aos>GRANT sh_rw_role_0101 TO ellen_enduser; Grant succeeded. sam_sec_mgr@aos>GRANT sh_exec_role_0101 TO ellen_enduser; Grant succeeded. sam_sec_mgr@aos> now connect as the end-user account sam_sec_mgr@aos> and see how it works sam_sec_mgr@aos>CONNECT ellen_enduser Enter password: ERROR: ORA-28001: the password has expired Changing password for ellen_enduser New password: Retype new password: Password changed Connected. ellen_enduser@aos> the account can query the COSTS table ellen_enduser@aos>SELECT * FROM sh.costs WHERE ROWNUM < 6; PROD_ID TIME_ID PROMO_ID CHANNEL_ID UNIT_COST UNIT_PRICE 13 20-JAN-98 999 2 793.14 1205.99 13 30-JAN-98 999 3 783.03 1232.16 13 21-FEB-98 999 3 813.07 1237.31 13 25-FEB-98 999 3 798.69 1232.99 14 19-JAN-98 999 2 886.45 1108.99 Chapter 6: Applied Database Vault for Custom Applications 267 5 rows selected. ellen_enduser@aos> the account can delete the COSTS table ellen_enduser@aos>DELETE sh.costs WHERE prod_id = 22; 1221 rows deleted. ellen_enduser@aos> undo the transaction as it is only a test! ellen_enduser@aos>ROLLBACK; Rollback complete. An important note about the use of Oracle roles here regards the limitation of using object privileges granted through a role. If any application object, such as SH.SALES, must be queried or updated by another application account, such as HR, within a PL/SQL package, we need to perform a direct object privilege grant to the HR account. The read-only and read-write roles defined here are intended for application end user access to specific application object-owner accounts that will issue SQL statements outside of a PL/SQL package. As we mentioned earlier, if the object-owner accounts that are in use for your applications will be dynamic or have dynamically created objects, then a system privilege model for end user roles is appropriate. This model should be constructed so that it can be used by several applications in a hierarchical fashion. Start by defining a set of base application roles that will be granted the ANY privileges and then creating named application realm roles that correspond to each base application role. This is the same approach we took with the application administrator accounts described earlier and in particular the application data administrator (data steward) and application data analyst roles. The application data administrator role we created, SH_DATA_ADMIN_0101, and the application data analyst role, SH_DATA_ANALYST_0101, will be sufficient for the read- write and read-only end user access account provisioning. Post-configuration Account Provisioning Once the core separation of duty roles are created and the DBV policy that accompanies them is defined, the process of creating named accounts (for real end users or administrators) that use these roles can be activated for production use. Here’s the general process for this account creation: 1. Log in as the account administrator to create the named end user account with a default password, tablespace, temporary tablespace, and database profile. 2. Expire the password to force the named end user account to change the account password at first login to a password the user can control. 3. Log in as the operational DBA and grant the appropriate system privilege(s), such as CREATE SESSION, to the named end user account. 4. Log in as the realm security administrator and grant the appropriate role(s) to the named end user account. Establish DBV Command Rules from Conditions The Add Product Costs example use case has a handful of candidate DBV command rules we can create to meet the requirements documented. These can be discovered by examining the Subject- Verb-Object-Condition table we created at the beginning of the chapter and examined to identify DBV factors. By analyzing this table, we can develop a candidate list of DBV command rules, as shown in Table 6-4, and walk through a process to implement some of them as required. 268 Part II: Oracle Database Vault The first DBV command rule, INSERT on SH.COSTS, can make use of three categories of DBV factors to provide a multifactored approach to the policy for this operation: Factors based on identity management (sales department manager) Factors based on access or operational context (sales management package) Factors based on time (outside of the weekly maintenance window) First, we can define a factor to assert whether or not the current user is a sales manager. Consider the following queries that will show us the sales managers defined in the HR object- owner account’s tables: hr@aos> find the Sales department id hr@aos>SELECT department_id,department_name FROM hr.departments WHERE department_name ='Sales' / DEPARTMENT_ID DEPARTMENT_NAME 80 Sales 1 row selected. hr@aos> find the Sales department's managers hr@aos>SELECT employee_id,email,department_id FROM hr.employees emp WHERE emp.department_id = 80 AND EXISTS ( SELECT 1 FROM hr.employees reportees WHERE reportees.manager_id = emp.employee_id ■ ■ ■ SQL Command Owner Object Rules INSERT SH COSTS Only allowed by Sales Managers Outside the weekly maintenance window Only from a trusted Sales Management package SELECT HR EMPLOYEES Social Security number (SSN), salary, or commission columns are not part of the query SELECT SH PRODUCTS Return only for products for which the manager is responsible UPDATE SYSTEM AUD$ Not allowed by database administrators DELETE SYSTEM AUD$ Not allowed by database administrators Deletes allowed only for audit data more than seven years old TABLE 6-4 List of DBV Command Rules Chapter 6: Applied Database Vault for Custom Applications 269 AND reportees.department_id = emp.department_id ); EMPLOYEE_ID EMAIL DEPARTMENT_ID 145 JRUSSEL 80 146 KPARTNER 80 147 AERRAZUR 80 148 GCAMBRAU 80 149 EZLOTKEY 80 5 rows selected. hr@aos> find the Sales employees reporting to JRUSSEL hr@aos>SELECT employee_id, email FROM employees WHERE manager_id = 145; EMPLOYEE_ID EMAIL 150 PTUCKER 151 DBERNSTE 152 PHALL 153 COLSEN 154 NCAMBRAU 155 OTUVAULT 6 rows selected. We can extend the HR utility PL/SQL package, HR.EMPLOYEE_UTILITY, used in Chapter 5 to include a function that will return a TRUE/FALSE indicator if the logged-in database user is the manager of the department as follows: hr@aos>CREATE OR REPLACE PACKAGE hr.employee_utility IS FUNCTION get_user_department_id ( user_name IN VARCHAR2 DEFAULT SYS_CONTEXT('USERENV', 'SESSION_USER') ) RETURN NUMBER; FUNCTION get_user_department_name ( user_name IN VARCHAR2 DEFAULT SYS_CONTEXT('USERENV', 'SESSION_USER') ) RETURN VARCHAR2; FUNCTION is_department_manager ( user_name IN VARCHAR2 DEFAULT SYS_CONTEXT('USERENV', 'SESSION_USER') ) RETURN NUMBER; END; / PL/SQL procedure successfully completed. This function includes a set of queries similar to those we issued above to assert the fact that the logged-in user is a sales department manager. With this function in place, we can create an identity management–related factor for the department manager condition as follows: diego_dbvmgr@aos>BEGIN dbms_macadm.create_factor( factor_name => 'Is_Department_Manager' , factor_type_name => 'User', description => 270 Part II: Oracle Database Vault 'Returns an indicator that the user is a department manager.', rule_set_name => NULL , get_expr => 'hr.employee_utility.is_department_manager', 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; / COMMIT; Commit complete. Next we can use the example accounts from our operational and application administration model for realm authorizations to create the database access account. We will create one account for a sales manager named JRUSSEL and one account for a sales employee named PTUCKER who reports to JRUSSEL: jim_acctmgr@aos> use the DBV Account Administrator to jim_acctmgr@aos> create the account for the Sales Manager JRUSSEL jim_acctmgr@aos>CREATE USER jrussel IDENTIFIED BY <password>; User created. jim_acctmgr@aos> expire the password for the account so they are jim_acctmgr@aos> forced to change it to a password jim_acctmgr@aos> they can control at next login jim_acctmgr@aos>ALTER USER jrussel PASSWORD EXPIRE; User altered. jim_acctmgr@aos> create the account for the Sales employee PTUCKER jim_acctmgr@aos>CREATE USER ptucker IDENTIFIED BY <password>; User created. jim_acctmgr@aos> expire the password for the account so they are jim_acctmgr@aos> forced to change it to a password jim_acctmgr@aos> they can control at next login jim_acctmgr@aos>ALTER USER ptucker PASSWORD EXPIRE; jim_acctmgr@aos> use the operational DBA to grant these jim_acctmgr@aos> accounts database session privilege jim_acctmgr@aos>CONNECT jean_oper_dba Enter password: Connected. jean_oper_dba@aos>GRANT CREATE SESSION TO jrussel; Grant succeeded. jean_oper_dba@aos>GRANT CREATE SESSION TO ptucker; Grant succeeded. jean_oper_dba@aos> use the Sales History realms jean_oper_dba@aos> Application Security Administrator sam_sec_mgr jean_oper_dba@aos> to provide DML and EXECUTE privileges Chapter 6: Applied Database Vault for Custom Applications 271 jean_oper_dba@aos> to these accounts for Sales History data and jean_oper_dba@aos> Sales History application code jean_oper_dba@aos>CONNECT sam_sec_mgr Enter password: Connected. sam_sec_mgr@aos>GRANT sh_data_admin_0101 TO jrussel; Grant succeeded. sam_sec_mgr@aos>GRANT sh_data_admin_0101 TO ptucker; Grant succeeded. We can extend the SH.SALES transaction package from Chapter 5 to include a procedure named insert_product_cost that will be our trusted procedure to add new product costs: sh@aos>CREATE OR REPLACE PACKAGE sh.sales_transaction AS PROCEDURE update_sales(customer IN NUMBER, amount IN NUMBER); PROCEDURE insert_product_cost( product IN VARCHAR2 , promotion IN VARCHAR2 , channel IN VARCHAR2 , cost_date IN DATE , cost IN NUMBER , price IN NUMBER ); END; / Package created. Both the JRUSSEL and PTUCKER accounts can create new product cost data using standard SQL and the SH.SALES_TRANSACTION package at this point. sh@aos>CONNECT jrussel Enter password: ERROR: ORA-28001: the password has expired Changing password for jrussel New password: Retype new password: Password changed Connected. jrussel@aos>INSERT INTO sh.costs ( prod_id , time_id , promo_id , channel_id , unit_cost , unit_price ) SELECT prod.prod_id , TO_DATE('07-26-2000','MM-DD-YYYY') , promo.promo_id 272 Part II: Oracle Database Vault , chan.channel_id , 15.00 , 49.95 FROM sh.products prod , sh.promotions promo , sh.channels chan WHERE prod_name = 'Smash up Boxing' AND channel_desc = 'Direct Sales' AND promo_name = 'blowout sale' ; 1 row created. jrussel@aos>BEGIN sh.sales_transaction.insert_product_cost( product => '8.3 Minitower Speaker' , promotion => 'blowout sale' , channel => 'Direct Sales' , cost_date => TO_DATE('07-26-2000','MM-DD-YYYY') , cost => 25.00 , price => 99.99 ); END; / PL/SQL procedure successfully completed. jrussel@aos>CONNECT ptucker Enter password: ERROR: ORA-28001: the password has expired Changing password for ptucker New password: Retype new password: Password changed Connected. ptucker@aos>INSERT INTO sh.costs ( prod_id , time_id , promo_id , channel_id , unit_cost , unit_price ) SELECT prod.prod_id , TO_DATE('06-15-2002','MM-DD-YYYY') , promo.promo_id , chan.channel_id , 5.00 , 29.95 Chapter 6: Applied Database Vault for Custom Applications 273 FROM sh.products prod , sh.promotions promo , sh.channels chan WHERE prod_name = 'Adventures with Numbers' AND channel_desc = 'Direct Sales' AND promo_name = 'everyday low price' ; 1 row created. ptucker@aos>BEGIN sh.sales_transaction.insert_product_cost( product => 'Martial Arts Champions' , promotion => 'blowout sale' , channel => 'Direct Sales' , cost_date => TO_DATE('06-15-2002','MM-DD-YYYY') , cost => 5.00 , price => 19.99 ); END; / PL/SQL procedure successfully completed. We are now ready to create a DBV rule set to control for our example. We will use four of the factors we created in the DBV rules that make up this DBV rule set. Note that we already have a DBV rule named “Called From Sales Transaction Package” defined that uses the In_Sales_ Transaction_Package factor so we do not need to redefine this rule. diego_dbvmgr@aos> create the Sales department manager rule diego_dbvmgr@aos>BEGIN dbms_macadm.create_rule( rule_name => 'Is Sales Department Manager' , rule_expr => 'DVF.F$User_Department_Name = ''Sales''' || 'AND DVF.F$Is_Department_Manager = 1' ); END; / PL/SQL procedure successfully completed. create the outside of the system maintenance window rule BEGIN dbms_macadm.create_rule( rule_name => 'Outside System Maintenance Window ' , rule_expr => 'DVF.F$Is_Maintenance_Window = 0' ); END; / PL/SQL procedure successfully completed. diego_dbvmgr@aos> create the rule set to associate the rules to diego_dbvmgr@aos> using the dbms_macutl.g_ruleset_eval_all value diego_dbvmgr@aos> for the eval_options parameter as we need all . the named end user account. Establish DBV Command Rules from Conditions The Add Product Costs example use case has a handful of candidate DBV command rules we can create to meet the requirements. beginning of the chapter and examined to identify DBV factors. By analyzing this table, we can develop a candidate list of DBV command rules, as shown in Table 6-4, and walk through a process. sam_sec_mgr jean_oper_dba@aos> to provide DML and EXECUTE privileges Chapter 6: Applied Database Vault for Custom Applications 271 jean_oper_dba@aos> to these accounts for Sales History data and jean_oper_dba@aos>