244 Part II: Oracle Database Vault jean_oper_dba@aos>GRANT CREATE SESSION TO sh; Grant succeeded. jean_oper_dba@aos> connect as our object-owner jean_oper_dba@aos> account and create or application's objects jean_oper_dba@aos>CONNECT sh Enter password: Connected. sh@aos> install our application objects sh@aos> @install_sales_history_objects.sql Table created. Table created. Sequence created. View created. … sh@aos> now protect the application's objects in a DBV realm sh@aos>CONNECT dbvowner Enter password: dbvowner@aos>BEGIN dbms_macadm.create_realm( realm_name => 'Sales History' , description => 'Annual, quarterly, monthly, and weekly sales figures by product' , enabled => DBMS_MACUTL.G_YES , audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL ); END; / PL/SQL procedure successfully completed. BEGIN dbms_macadm.add_object_to_realm<A> ( realm_name => 'Sales History' ,object_owner => 'SH' ,object_name => '%' ,object_type => '%' ); END; / PL/SQL procedure successfully completed. we typically authorize the object-owner account in the realm if application code performs DDL activity on the realm BEGIN dbms_macadm.add_auth_to_realm( realm_name =>'Sales History' , grantee => 'SH' , rule_set_name => NULL , auth_options => DBMS_MACUTL.G_REALM_AUTH_OWNER ); END; / PL/SQL procedure successfully completed. Chapter 6: Applied Database Vault for Custom Applications 245 Create (Realm-based) Application Database Administrators We mentioned earlier that DBV comes with a predefined role named DV_REALM_OWNER that works nicely with the application database administrator concept. We do not want to grant the DV_REALM_OWNER role directly to the accounts and then authorize the accounts in the realm, as this yields higher maintenance costs on the DBV policy side for account provisioning. We also do not want to authorize the DV_REALM_OWNER role in each realm as this would provide access to all realms for anyone that has been granted this role. The solution is to define an application-centric role name for this administrator for each realm and simply grant this DV_ REALM_OWNER role to the application-centric role. We demonstrate with an example for the Sales History realm: jean_oper_dba@aos> login as our new jean_oper_dba@aos> Operational DBA for audit attribution jean_oper_dba@aos>CREATE ROLE sh_dba_role_0101; Role created. jean_oper_dba@aos> revoke the role from the account jean_oper_dba@aos> that created it or our privilege jean_oper_dba@aos> escalation realm authorization jean_oper_dba@aos> will fail. The Oracle Database jean_oper_dba@aos> performs an implicit and hidden jean_oper_dba@aos> GRANT of the role to the account jean_oper_dba@aos> that creates a role. jean_oper_dba@aos>REVOKE sh_dba_role_0101 FROM jean_oper_dba; Revoke succeeded. jean_oper_dba@aos> no we can grant the DBV realm owner role to the jean_oper_dba@aos> application-centric database administrator role jean_oper_dba@aos>GRANT dv_realm_owner TO sh_dba_role_0101 ; Grant succeeded. Once this named role is defined, we would authorize the role in the application realm as a realm owner for grantees of the role to manage the roles and object privilege grants that are protected by the realm as follows: dbvowner@aos>BEGIN dbms_macadm.add_auth_to_realm( realm_name =>'Sales History' , grantee => 'SH_DBA_ROLE_0101' , rule_set_name => NULL , auth_options => DBMS_MACUTL.G_REALM_AUTH_OWNER ); END; / PL/SQL procedure successfully completed. Depending on the organization’s IT policy or compliance-related security requirements, we may not necessarily want to use the DV_REALM_OWNER role as the base role for any number of reasons, discussed previously. We decided that we could have up to four profiles of application administrators, and we want a design that takes into account the need to maintain privilege sets for these profiles across any number of applications and their respective DBV realms. The system privilege model should be constructed so that it can be used by several applications in a hierarchical fashion. The approach is to start by defining a set of base roles that will be granted 246 Part II: Oracle Database Vault the ANY privileges appropriate to profile. We will then create a named application realm role that corresponds to appropriate base role, just as we did earlier. Easy enough; let’s implement our four application administrator roles. Application Security Administrator This administrator can create roles and grant realm- protected roles or realm-protected objects to other accounts or roles. The administrator can also control the audit configuration for the objects protected by the realm. The implementation is as follows: jean_oper_dba@aos> create the base role jean_oper_dba@aos>CREATE ROLE base_sec_admin_0101; Role created. jean_oper_dba@aos>REVOKE base_sec_admin_0101 FROM jean_oper_dba; Revoke succeeded. jean_oper_dba@aos> grant the security-relevant system privileges to this base role jean_oper_dba@aos> this privilege allows the administrator to jean_oper_dba@aos> grant roles to other accounts or roles jean_oper_dba@aos>GRANT GRANT ANY ROLE TO base_sec_admin_0101; Grant succeeded. jean_oper_dba@aos> this privilege allows the administrator jean_oper_dba@aos> to create roles for use in the realm jean_oper_dba@aos>GRANT CREATE ROLE TO base_sec_admin_0101; Grant succeeded. jean_oper_dba@aos> this privilege allows the administrator jean_oper_dba@aos> to change the authentication mode of the role jean_oper_dba@aos>GRANT ALTER ANY ROLE TO base_sec_admin_0101; Grant succeeded. jean_oper_dba@aos> this privilege allows the administrator jean_oper_dba@aos> to remove roles in the event they are jean_oper_dba@aos> no longer required jean_oper_dba@aos>GRANT DROP ANY ROLE TO base_sec_admin_0101; Grant succeeded. jean_oper_dba@aos> this privilege allows the administrator to jean_oper_dba@aos> grant object privileges on realm protected jean_oper_dba@aos> objects to roles or other accounts jean_oper_dba@aos>GRANT GRANT ANY OBJECT PRIVILEGE TO base_sec_admin_0101; Grant succeeded. jean_oper_dba@aos> this privilege allows the administer to configure jean_oper_dba@aos> audit policy on realm protected objects jean_oper_dba@aos>GRANT AUDIT ANY TO base_sec_admin_0101; Grant succeeded. jean_oper_dba@aos> create the role for the Sales History realm jean_oper_dba@aos> and grant the base role jean_oper_dba@aos>CREATE ROLE sh_sec_admin_0101; Role created. jean_oper_dba@aos>REVOKE sh_sec_admin_0101 FROM jean_oper_dba; Revoke succeeded. jean_oper_dba@aos>GRANT base_sec_admin_0101 TO sh_sec_admin_0101; Grant succeeded. The DROP ANY ROLE privilege is granted to the application security administrator in the event that a role is no longer required. As a matter of safeguarding against human error, DBV command rules around DROP commands may be worthy of consideration (for many commands) in your Chapter 6: Applied Database Vault for Custom Applications 247 production environments. This forces the DROP command to be approved by a second party, namely the DBV administrator, whose approval is the temporary disablement of the command rule or some factor-based modification to the rule that governs it. We want to create an initial named security administrator account before we protect the role within the DBV realm or we won’t be able to grant the first named account the role without disabling the realm. From this point on, we can use the initial named security administrator account to manage grants for all realm-protected roles. dbvacctmgr@aos>CREATE USER sam_sec_mgr 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 sam_sec_mgr PASSWORD EXPIRE; User altered. dbvacctmgr@aos>CONNECT jean_oper_dba Enter password: Connected. jean_oper_dba@aos>GRANT CREATE SESSION TO sam_sec_mgr; Grant succeeded. jean_oper_dba@aos>GRANT sh_sec_admin_0101 TO sam_sec_mgr Grant succeeded. We now protect the base role and application role as realm-secured objects within the appropriate realm and authorize the application administration role in the realm as a realm owner. With the application role, we will also add a realm authorization, keeping an eye on the privilege escalation concerns we demonstrated previously. dbvowner@aos> create a new rule set for privilege escalation dbvowner@aos> that is specific to realm application security dbvowner@aos>BEGIN dbms_macadm.create_rule_set( rule_set_name =>'Authorized Realm Security Command', description => 'Checks to verify the command is authorized for a realm application security administrator', 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. dbvowner@aos>BEGIN dbms_macadm.add_rule_to_rule_set( rule_set_name => 'Authorized Realm Security Command' , rule_name => 'Authorized Grant or Revoke' ); END; / 248 Part II: Oracle Database Vault PL/SQL procedure successfully completed. dbvowner@aos> authorize the Sales History realm's dbvowner@aos> application security administrator with this new rule set dbvowner@aos>BEGIN dbms_macadm.add_auth_to_realm ( realm_name =>'Sales History' , grantee => 'SH_SEC_ADMIN_0101' , rule_set_name => 'Authorized Realm Security Command' , auth_options => dbms_macutl.g_realm_auth_owner ); END; / PL/SQL procedure successfully completed. dbvowner@aos> protect the Sales History application dbvowner@aos> security role in the realm dbvowner@aos>BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Sales History' ,object_owner => 'SH' ,object_name => 'SH_SEC_ADMIN_0101' ,object_type => 'ROLE' ); END; / PL/SQL procedure successfully completed. dbvowner@aos> protect the base application security dbvowner@aos> role in the Oracle Data Dictionary realm dbvowner@aos>BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Oracle Data Dictionary' ,object_owner => 'SYS' ,object_name => 'BASE_SEC_ADMIN_0101' ,object_type => 'ROLE' ); END; / PL/SQL procedure successfully completed. Finally, we’ll examine how this role behaves when our named security administrator account executes commands against realm-protected objects: dbvowner@aos>CONNECT sam_sec_mgr Password: ERROR: ORA-28001: the password has expired Changing password for sam_sec_mgr New password: Retype new password: Password changed Connected. sam_sec_mgr@aos> review and confirm the session privileges sam_sec_mgr@aos>SELECT * FROM session_privs ORDER BY 1; Chapter 6: Applied Database Vault for Custom Applications 249 PRIVILEGE ALTER ANY ROLE AUDIT ANY CREATE ROLE CREATE SESSION DROP ANY ROLE GRANT ANY OBJECT PRIVILEGE GRANT ANY ROLE 7 rows selected. sam_sec_mgr@aos> review and confirm the session roles sam_sec_mgr@aos>SELECT * FROM session_roles ORDER BY 1; ROLE BASE_SEC_ADMIN_0101 DV_PUBLIC SH_SEC_ADMIN_0101 sam_sec_mgr@aos> the account can see what the Sales History sam_sec_mgr@aos> COSTS table looks like sam_sec_mgr@aos>DESCRIBE sh.costs Name Null? Type PROD_ID NOT NULL NUMBER TIME_ID NOT NULL DATE PROMO_ID NOT NULL NUMBER CHANNEL_ID NOT NULL NUMBER UNIT_COST NOT NULL NUMBER(10,2) UNIT_PRICE NOT NULL NUMBER(10,2) sam_sec_mgr@aos> the account cannot see the data in the table sam_sec_mgr@aos> which is what we want, note this is due sam_sec_mgr@aos> to the privileges versus DBV sam_sec_mgr@aos> SELECT * FROM sh.costs WHERE ROWNUM < 6; SELECT * FROM sh.costs WHERE ROWNUM < 6; * ERROR at line 1: ORA-01031: insufficient privileges sam_sec_mgr@aos> the account can create a role sam_sec_mgr@aos>CREATE ROLE sh_query; Role created. sam_sec_mgr@aos> the account cannot perform object privileges sam_sec_mgr@aos> just yet as we've added privilege escalation sam_sec_mgr@aos> logic to the realm authorization rule sam_sec_mgr@aos> and the account has the implicit grant on the role sam_sec_mgr@aos>GRANT SELECT ON sh.costs TO sh_query ; GRANT SELECT ON sh.costs TO sh_query 250 Part II: Oracle Database Vault * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm violation for grant object privilege on SH.COSTS ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 sam_sec_mgr@aos> revoke the role and we are in business sam_sec_mgr@aos>REVOKE sh_query FROM sam_sec_mgr; Revoke succeeded. sam_sec_mgr@aos>GRANT SELECT ON sh.costs TO sh_query ; Grant succeeded. drop the role as it was just a test sam_sec_mgr@aos>DROP ROLE sh_query; Role dropped. sam_sec_mgr@aos> the account can control the audit policy sam_sec_mgr@aos> on the table, which is also what we want to provide sam_sec_mgr@aos>AUDIT DELETE ON sh.costs; Audit succeeded. We can also grant these security administrator accounts the privileges required to maintain OLS policies on the tables protected by the realm. If we use the CUSTOMER_POLICY OLS policy from the examples in Chapter 5, we simply grant the OLS component APIs to our security administrator role and the CUSTOMER_POLICY_DBA role to the named account as follows: lbacsys@aos> these OLS label APIs can be granted to the lbacsys@aos> security administrator role lbacsys@aos>GRANT EXECUTE ON sa_components TO sh_sec_admin_0101; Grant succeeded. lbacsys@aos>GRANT EXECUTE ON sa_label_admin TO sh_sec_admin_0101; Grant succeeded. lbacsys@aos> this OLS user-label assignment API can be granted to the lbacsys@aos> security administrator role lbacsys@aos>GRANT EXECUTE ON sa_user_admin TO sh_sec_admin_0101; Grant succeeded. lbacsys@aos> in order to use this policy DBA role it lbacsys@aos> must granted directly to a named account lbacsys@aos>GRANT customer_policy_dba TO sam_sec_mgr ; Grant succeeded. We then authorize LBACSYS in the Sales History realm in the same way we did in Chapter 5 to allow the OLS CREATE TRIGGER commands to complete: dbvowner@aos>BEGIN dbms_macadm.add_auth_to_realm ( realm_name =>'Sales History' , grantee => 'LBACSYS' , rule_set_name => NULL , auth_options => dbms_macutl.g_realm_auth_participant ); END; / PL/SQL procedure successfully completed. Chapter 6: Applied Database Vault for Custom Applications 251 The result is that we have a named account, sam_sec_mgr, who can maintain an OLS policy’s label components, labels, and user-label assignments for an OLS policy that is specific to data protected in a realm. This account can also maintain enforcement for data tables protected by OLS for row-level security policy. sam_sec_mgr@aos> create a new OLS level for this policy sam_sec_mgr@aos>BEGIN sa_components.create_level( policy_name=> 'CUSTOMER_POLICY' , level_num => 40 , short_name => 'VERY_HIGH' , long_name => 'VERY HIGH CREDIT LIMIT' ); END; / PL/SQL procedure successfully completed. sam_sec_mgr@aos> create a new OLS label for this policy sam_sec_mgr@aos>BEGIN sa_label_admin.create_label( policy_name => 'CUSTOMER_POLICY' , label_tag => 40 , label_value => 'VERY_HIGH' ); END; / PL/SQL procedure successfully completed. sam_sec_mgr@aos> assign the labels ranges of data sam_sec_mgr@aos> records that ANTHONY can read and write sam_sec_mgr@aos>BEGIN sa_user_admin.set_user_labels( policy_name => 'CUSTOMER_POLICY' , user_name => 'ANTHONY' , min_write_label => 'LOW' , max_read_label => 'HIGH' , max_write_label => 'HIGH' , def_label => 'HIGH' , row_label => 'HIGH' ); END; / PL/SQL procedure successfully completed. sam_sec_mgr@aos> simple test to remove the table policy sam_sec_mgr@aos>BEGIN sa_policy_admin.remove_table_policy( policy_name => 'CUSTOMER_POLICY' , schema_name => 'SH' , table_name => 'CUSTOMERS' , drop_column => FALSE ); END; 252 Part II: Oracle Database Vault / PL/SQL procedure successfully completed. sam_sec_mgr@aos> simple test to add the table policy back sam_sec_mgr@aos>BEGIN sa_policy_admin.remove_table_policy( policy_name => 'CUSTOMER_POLICY' , schema_name => 'SH' , table_name => 'CUSTOMERS' , drop_column => FALSE ); END; / PL/SQL procedure successfully completed. This OLS policy control, in addition to the object privilege management, role management, and auditing of the objects protected by the realm, make for a complete application security administrator pattern that can be implemented in your environment. Application Maintenance Administrator This administrator’s privileges would be limited to performing in the DDL category of commands on the application realm’s objects. The implementation is as follows: jean_oper_dba@aos> create the base role jean_oper_dba@aos>CREATE ROLE base_maint_admin_0101; Role created. jean_oper_dba@aos>REVOKE base_maint_admin_0101 FROM jean_oper_dba; Revoke succeeded. jean_oper_dba@aos> grant the DDL system privileges to this base role jean_oper_dba@aos>GRANT ALTER ANY CLUSTER TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT ALTER ANY DIMENSION TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT ALTER ANY INDEX TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT ALTER ANY INDEXTYPE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT ALTER ANY MATERIALIZED VIEW TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT ALTER ANY OPERATOR TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT ALTER ANY OUTLINE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT ALTER ANY PROCEDURE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT ALTER ANY SEQUENCE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT ALTER ANY TABLE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT ALTER ANY TRIGGER TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT ALTER ANY TYPE TO base_maint_admin_0101; Grant succeeded. Chapter 6: Applied Database Vault for Custom Applications 253 jean_oper_dba@aos>GRANT COMMENT ANY TABLE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY CLUSTER TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY CONTEXT TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY DIMENSION TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY INDEX TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY INDEXTYPE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY MATERIALIZED VIEW TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY OPERATOR TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY OUTLINE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY PROCEDURE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY SEQUENCE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY SYNONYM TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY TABLE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY TRIGGER TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY TYPE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT CREATE ANY VIEW TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY CLUSTER TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY DIMENSION TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY INDEX TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY INDEXTYPE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY MATERIALIZED VIEW TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY OPERATOR TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY OUTLINE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY PROCEDURE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY SEQUENCE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY SYNONYM TO base_maint_admin_0101; . safeguarding against human error, DBV command rules around DROP commands may be worthy of consideration (for many commands) in your Chapter 6: Applied Database Vault for Custom Applications 247 production. ); END; / PL/SQL procedure successfully completed. Chapter 6: Applied Database Vault for Custom Applications 245 Create (Realm-based) Application Database Administrators We mentioned earlier that DBV. escalation realm authorization jean_oper_dba@aos> will fail. The Oracle Database jean_oper_dba@aos> performs an implicit and hidden jean_oper_dba@aos> GRANT of the role to the account jean_oper_dba@aos>