Applied Oracle Security: Developing Secure Database and Middleware Environments- P29 docx

254 Part II: Oracle Database Vault Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY TABLE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY TRIGGER TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY TYPE TO base_maint_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DROP ANY VIEW TO base_maint_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_maint_admin_0101; Role created. jean_oper_dba@aos>REVOKE sh_maint_admin_0101 FROM jean_oper_dba; Revoke succeeded. jean_oper_dba@aos>GRANT base_maint_admin_0101 TO sh_maint_admin_0101; Grant succeeded. This administrator’s privileges basically allow CREATE, ALTER, and DROP of objects that are owned by an application schema and protected by a realm. 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 participant. We are not concerned about privilege escalation, as this administrator does not have the underlying system privileges to grant privileges or roles. dbvowner@aos> authorize the Sales History maintenance dbvowner@aos> administrator role in the realm dbvowner@aos>BEGIN dbms_macadm.add_auth_to_realm ( realm_name =>'Sales History' , grantee => 'SH_MAINT_ADMIN_0101' , rule_set_name => NULL , auth_options => dbms_macutl.g_realm_auth_participant ); END; / PL/SQL procedure successfully completed. dbvowner@aos> protect the Sales History maintenance dbvowner@aos> administrator role in the realm dbvowner@aos>BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Sales History' ,object_owner => 'SH' ,object_name => 'SH_MAINT_ADMIN_0101' ,object_type => 'ROLE' ); END; / PL/SQL procedure successfully completed. dbvowner@aos> protect the base application maintenance role dbvowner@aos> in the Oracle Data Dictionary realm Chapter 6: Applied Database Vault for Custom Applications 255 BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Oracle Data Dictionary' ,object_owner => 'SYS' ,object_name => 'BASE_MAINT_ADMIN_0101' ,object_type => 'ROLE' ); END; / PL/SQL procedure successfully completed. Let’s examine how we create this type of administrator and how the privileges work: dbvacctmgr@aos> create the maintenance administrator account dbvacctmgr@aos> CREATE USER mark_maint_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 mark_maint_mgr 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 mark_maint_mgr; jean_oper_dba@aos> Grant succeeded. jean_oper_dba@aos> this won't work, the role is now protected GRANT sh_maint_admin_0101 TO mark_maint_mgr; jean_oper_dba@aos>GRANT sh_maint_admin_0101 TO mark_maint_mgr * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm violation for grant role privilege on SH_MAINT_ADMIN_0101. ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 jean_oper_dba@aos> we have to login as the Sales History Security jean_oper_dba@aos> administrator to perform the grant jean_oper_dba@aos>CONNECT sam_sec_mgr Enter password: Connected. sam_sec_mgr@aos>GRANT sh_maint_admin_0101 TO mark_maint_mgr; Grant succeeded. sam_sec_mgr@aos> now connect as the maintenance administrator sam_sec_mgr@aos> and see how it works sam_sec_mgr@aos>CONNECT mark_maint_mgr Enter password: ERROR: ORA-28001: the password has expired Changing password for mark_maint_mgr New password: 256 Part II: Oracle Database Vault Retype new password: Password changed Connected. mark_maint_mgr@aos> the account can see what the Sales History mark_maint_mgr@aos> COSTS table looks like mark_maint_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) mark_maint_mgr@aos> the account cannot query the COSTS table mark_maint_mgr@aos>SELECT * FROM sh.costs WHERE ROWNUM < 6; SELECT * FROM sh.costs WHERE ROWNUM < 6; * ERROR at line 1: ORA-01031: insufficient privileges mark_maint_mgr@aos> but the account can manage the mark_maint_mgr@aos> structure of the COSTS table mark_maint_mgr@aos>ALTER TABLE sh.costs MODIFY UNIT_COST NUMBER(10,2) NULL; Table altered. Application Data Manager (Data Steward) This administrator’s privileges are limited to performing queries (SELECT) and DML (INSERT, UPDATE, DELETE and EXECUTE) 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_data_admin_0101; Role created. jean_oper_dba@aos>REVOKE base_data_admin_0101 FROM jean_oper_dba; Revoke succeeded. jean_oper_dba@aos> grant the SELECT, DML and EXECUTE system jean_oper_dba@aos> privileges to this base role jean_oper_dba@aos>GRANT SELECT ANY SEQUENCE TO base_data_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT SELECT ANY TABLE TO base_data_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT INSERT ANY TABLE TO base_data_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT UPDATE ANY TABLE TO base_data_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT DELETE ANY TABLE TO base_data_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT EXECUTE ANY INDEXTYPE TO base_data_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT EXECUTE ANY OPERATOR TO base_data_admin_0101; Chapter 6: Applied Database Vault for Custom Applications 257 Grant succeeded. jean_oper_dba@aos>GRANT EXECUTE ANY PROCEDURE TO base_data_admin_0101; Grant succeeded. jean_oper_dba@aos>GRANT EXECUTE ANY TYPE TO base_data_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_data_admin_0101; Role created. jean_oper_dba@aos>REVOKE sh_data_admin_0101 FROM jean_oper_dba; Revoke succeeded. jean_oper_dba@aos>GRANT base_data_admin_0101 TO sh_data_admin_0101; Grant succeeded. This administrator’s privileges allow for read commands (SELECT), write commands (INSERT, UPDATE, DELETE) and finally execute (EXECUTE) commands on objects that are owned by an application schema and protected by a realm. This provides a named account capability for administrators that are restricted to managing data records, either directly or through an application’s PL/SQL APIs—hence the concept of a data steward. The administrator cannot modify the underlying data structures, indexes, or application code and has no control over the realm-protected roles. We must protect the base role and application role as realm-secured objects within the appropriate realm and authorize the data administration role in the realm as a realm participant. We are not concerned with privilege escalation, as this administrator does not have the underlying system privileges to grant privileges or roles. dbvowner@aos> authorize the Sales History data dbvowner@aos> administrator role in the realm dbvowner@aos>BEGIN dbms_macadm.add_auth_to_realm ( realm_name =>'Sales History' , grantee => 'SH_DATA_ADMIN_0101' , rule_set_name => NULL , auth_options => dbms_macutl.g_realm_auth_participant ); END; / PL/SQL procedure successfully completed. dbvowner@aos> protect the Sales History data dbvowner@aos> administrator role in the realm dbvowner@aos>BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Sales History' ,object_owner => 'SH' ,object_name => 'SH_DATA_ADMIN_0101' ,object_type => 'ROLE' ); END; / PL/SQL procedure successfully completed. dbvowner@aos> protect the base data administrator role 258 Part II: Oracle Database Vault dbvowner@aos> in the Oracle Data Dictionary realm BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Oracle Data Dictionary' ,object_owner => 'SYS' ,object_name => 'BASE_DATA_ADMIN_0101' ,object_type => 'ROLE' ); END; / PL/SQL procedure successfully completed. Here’s how we create this type of administrator and how the privileges work: dbvacctmgr@aos> create the data administrator account dbvacctmgr@aos>CREATE USER deb_data_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 deb_data_mgr 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 deb_data_mgr; Grant succeeded. jean_oper_dba@aos> this won't work, the role is now protected jean_oper_dba@aos>GRANT sh_data_admin_0101 TO deb_data_mgr; GRANT sh_data_admin_0101 TO deb_data_mgr * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm violation for grant role privilege on SH_data_admin_0101. ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 jean_oper_dba@aos> we have to login as the Sales History Security jean_oper_dba@aos> administrator to perform the grant jean_oper_dba@aos>CONNECT sam_sec_mgr Enter password: Connected. sam_sec_mgr@aos>GRANT sh_data_admin_0101 TO deb_data_mgr; Grant succeeded. sam_sec_mgr@aos> now connect as the data administrator sam_sec_mgr@aos> and see how it works sam_sec_mgr@aos>CONNECT deb_data_mgr Enter password: ERROR: ORA-28001: the password has expired Changing password for dba_data_mgr New password: Chapter 6: Applied Database Vault for Custom Applications 259 Retype new password: Password changed Connected. deb_data_mgr@aos> the account can query the COSTS table deb_data_mgr@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 5 rows selected. deb_data_mgr@aos> the account can delete the COSTS table deb_data_mgr@aos>DELETE sh.costs WHERE prod_id = 22; 1221 rows deleted. deb_data_mgr@aos>ROLLBACK; Rollback complete. deb_data_mgr@aos> demonstrate the account cannot change the deb_data_mgr@aos> structure of the COSTS table deb_data_mgr@aos>ALTER TABLE sh.costs MODIFY UNIT_COST NUMBER(10,2) NULL; ALTER TABLE sh.costs MODIFY UNIT_COST NUMBER(10,2) NULL * ERROR at line 1: ORA-01031: insufficient privileges Application Data Analyst This administrator’s privileges are simply SELECT with a scope of all objects protected within a realm. The implementation is as follows: jean_oper_dba@aos> create the base role jean_oper_dba@aos> grant the SELECT system privilege to this base role jean_oper_dba@aos>CREATE ROLE base_data_analyst_0101; Role created. jean_oper_dba@aos>REVOKE base_data_analyst_0101 FROM jean_oper_dba; Revoke succeeded. jean_oper_dba@aos>GRANT SELECT ANY TABLE TO base_data_analyst_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_data_analyst_0101; Role created. jean_oper_dba@aos>REVOKE sh_data_analyst_0101 FROM jean_oper_dba; Revoke succeeded. jean_oper_dba@aos>GRANT base_data_analyst_0101 TO sh_data_analyst_0101; Grant succeeded. This administrator’s privileges allow for read (SELECT) only on objects that are owned by an application schema and protected by a realm. This provides a named account capability for 260 Part II: Oracle Database Vault administrators that are restricted to querying data records. The administrator cannot modify the underlying data, data structures, indexes, or application code and has no control over the realm- protected roles. We now must protect the base role and application role as realm-secured objects within the appropriate realm and authorize the data analyst role in the realm as a realm participant. We are not concerned with privilege escalation, as this administrator does not have the underlying system privileges to grant privileges or roles. dbvowner@aos> authorize the Sales History data dbvowner@aos> analyst role in the realm dbvowner@aos>BEGIN dbms_macadm.add_auth_to_realm ( realm_name =>'Sales History' , grantee => 'SH_DATA_ANALYST_0101' , rule_set_name => NULL , auth_options => dbms_macutl.g_realm_auth_participant ); END; / PL/SQL procedure successfully completed. dbvowner@aos> protect the Sales History data dbvowner@aos> analyst role in the realm dbvowner@aos>BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Sales History' ,object_owner => 'SH' ,object_name => 'SH_DATA_ANALYST_0101' ,object_type => 'ROLE' ); END; / PL/SQL procedure successfully completed. dbvowner@aos> protect the base data analyst role dbvowner@aos> in the Oracle Data Dictionary realm BEGIN dbms_macadm.add_object_to_realm ( realm_name => 'Oracle Data Dictionary' ,object_owner => 'SYS' ,object_name => 'BASE_DATA_ANALYST_0101' ,object_type => 'ROLE' ); END; / PL/SQL procedure successfully completed. Here’s how we create this type of administrator and how the privileges work: dbvacctmgr@aos> create the data analyst account dbvacctmgr@aos> CREATE USER alan_analyst IDENTIFIED BY <password>; User created. dbvacctmgr@aos> expire the password for the account so they are Chapter 6: Applied Database Vault for Custom Applications 261 dbvacctmgr@aos> forced to change it to a password dbvacctmgr@aos> they can control at next login dbvacctmgr@aos>ALTER USER alan_analyst 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 alan_analyst; Grant succeeded. jean_oper_dba@aos> this won't work, the role is now protected GRANT sh_data_analyst_0101 TO alan_analyst; jean_oper_dba@aos>GRANT sh_data_analyst_0101 TO alan_analyst * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-47401: Realm violation for grant role privilege on sh_data_analyst_0101. ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55 ORA-06512: at line 31 jean_oper_dba@aos> we have to login as the Sales History Security jean_oper_dba@aos> administrator to perform the grant jean_oper_dba@aos>CONNECT sam_sec_mgr Enter password: Connected. sam_sec_mgr@aos>GRANT sh_data_analyst_0101 TO alan_analyst; Grant succeeded. sam_sec_mgr@aos> now connect as the data analyst sam_sec_mgr@aos> and see how it works sam_sec_mgr@aos>CONNECT alan_analyst Enter password: ERROR: ORA-28001: the password has expired Changing password for alan_analyst New password: Retype new password: Password changed Connected. alan_analyst@aos> the account can query the COSTS table alan_analyst@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 5 rows selected. alan_analyst@aos> demonstrate the account cannot delete alan_analyst@aos> data in the COSTS table alan_analyst@aos>DELETE sh.costs WHERE prod_id = 22; DELETE sh.costs WHERE prod_id = 22 262 Part II: Oracle Database Vault * ERROR at line 1: ORA-01031: insufficient privileges Create Named Account Administrators For account administrators, we will leverage the out-of-the-box DBV role DV_ACCTMGR because it has been granted the CREATE/ALTER/DROP USER and CREATE/ALTER/DROP PROFILE system privileges required for this type of administrator. Suppose we want to create a named account administrator, jim_acctmgr. We simply log in as the account that was specified as the DBV account administrator (DBVACCTMGR) at install time and execute the following statements to create this named account. The jim_acctmgr account can be used right away with no additional DBV realm or command rule changes to enforce the rules for this type of administrator. dbvacctmgr@aos> create the new account manager account dbvacctmgr@aos>CREATE USER jim_acctmgr 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 jim_acctmgr PASSWORD EXPIRE; User altered. dbvacctmgr@aos>GRANT DV_ACCTMGR TO jim_acctmgr; Grant succeeded. 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 jim_acctmgr; Grant succeeded. test that jim_acctmgr can use his account management privileges jean_oper_dba@aos>connect jim_acctmgr Enter password: ERROR: ORA-28001: the password has expired Changing password for jim_acctmgr New password: Retype new password: Password changed Connected. jim_acctmgr@aos>CREATE USER jims_test_acct IDENTIFIED BY <password>; User created. jim_acctmgr@aos>DROP USER jims_test_acct; User dropped. Create DBV Administrators and Analysts In Chapter 5 we discussed the three types of DBV security administrators that are established through the three roles installed with the product: DV_OWNER, DV_ADMIN, and DV_SECANALYST. The DV_OWNER and DV_ADMIN roles have the necessary privileges to modify DBV security configuration, so it is a good idea to follow the same model of creating named user accounts for the individuals who maintain this configuration. This approach ensures audit attribution for DBV configuration changes and separation of duty participants in your configuration management Chapter 6: Applied Database Vault for Custom Applications 263 process around activities such as the provisioning of named application administrators we’ve just described. Creating named user accounts that require read-only access to the DBV configuration, through the DV_SECANALYST role, might be required to meet reporting requirements for a compliance auditing scenario. Most organizations will probably elect to create DBV security administrators based on the DV_OWNER role as its privileges allow for full administration of DBV configuration and the granting and revoking of these DBV roles that would be required in the account provisioning activity. Here’s how we create a named account for the DBV security administrator: dbvacctmgr@aos> create the data analyst account dbvacctmgr@aos>CREATE USER diego_dbvmgr 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 diego_dbvmgr 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 diego_dbvmgr; Grant succeeded. jean_oper_dba@aos> we have to login as the original DBV Security jean_oper_dba@aos> Administrator to perform the grant of DV_OWNER jean_oper_dba@aos>CONNECT dbvowner Enter password: Connected. dbvowner@aos>GRANT dv_owner TO diego_dbvmgr; Grant succeeded. dbvowner@aos> now connect as the DBV Security administrator dbvowner@aos> and see how it works dbvowner@aos>CONNECT diego_dbvmgr Enter password: ERROR: ORA-28001: the password has expired Changing password for diego_dbvmgr New password: Retype new password: Password changed Connected. diego_dbvmgr@aos> the account can modify DBV configuration diego_dbvmgr@aos> immediately to protect a schema like OE diego_dbvmgr@aos>BEGIN dbms_macadm.create_realm( realm_name => 'Order Entry' , description => 'Realm to protect the Order Entry (OE) application.' , enabled => DBMS_MACUTL.G_YES , audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL ); . privileges allow for read commands (SELECT), write commands (INSERT, UPDATE, DELETE) and finally execute (EXECUTE) commands on objects that are owned by an application schema and protected by a realm role dbvowner@aos> in the Oracle Data Dictionary realm Chapter 6: Applied Database Vault for Custom Applications 255 BEGIN dbms_macadm.add_object_to_realm ( realm_name => &apos ;Oracle Data Dictionary' . basically allow CREATE, ALTER, and DROP of objects that are owned by an application schema and protected by a realm. We now protect the base role and application role as realm-secured objects within