Applied Oracle Security: Developing Secure Database and Middleware Environments- P33 pot

294 Part II: Oracle Database Vault OBJECT_SCHEMA OBJECT_NAME OE CUSTOMERS 1 row selected. Identify Realm Objects Based on Row-level Security Policy The existence of row-level security (RLS) policies on any tables in the database should also serve as an indicator that the table contains sensitive data. If a table is being protected by Oracle VPD policy or Oracle Label Security (OLS) policy, creating DBV realms that protect these tables is also warranted. The following query will help identify those tables that are being protected by either an Oracle VPD policy or an Oracle OLS policy: sys@aos> allow LBACSYS to query the VPD configuration table sys@aos>GRANT SELECT ON sys.dba_policies TO lbacsys; sys@aos> connect as LBACSYS to run the query sys@aos>CONNECT lbacsys Enter password: Connected. lbacsys/oracle@aos>SELECT 'VPD' policy_type , object_owner , object_name FROM sys.dba_policies WHERE object_owner NOT IN ('XDB') UNION SELECT 'OLS' policy_type , schema_name object_owner , table_name object_name FROM lbacsys.dba_sa_table_policies ORDER BY 1,2,3; POL OBJECT_OWNER OBJECT_NAME OLS SH CUSTOMERS VPD OE PURCHASEORDER VPD SH CUSTOMERS VPD SYSTEM AUD$ 4 rows selected. lbacsys@aos> revoke the previous grant used to enable the query lbacsys@aos>CONNECT / AS SYSDBA Connected. sys@aos>REVOKE SELECT ON sys.dba_policies FROM lbacsys; Revoke succeeded. The Oracle Sample Schemas are installed with a VPD policy on the table OE.PURCHASEORDER. Our example application does not access this table so it was not accessed when we generated the test workload used to populate our audit trail. The configuration queries exposed an additional security policy defined in the database and exposed another sensitive data object we need to account for in the candidate DBV policy. Chapter 7: Applied Database Vault for Existing Applications 295 Identify Roles to Protect as Realm In many database applications, collections of database roles with direct object privileges are intended to be used to access or manipulate sensitive database objects. It is important to protect these roles in a DBV realm for the same reasons we recommended in Chapter 6 when discussing the security policy for new applications. We can inspect the database privilege configuration view DBA_TAB_PRIVS in conjunction with our captured audit trail to identify these roles: sys@aos> SELECT DISTINCT aud.object_schema , grt.grantee role FROM aos_common_audit_trail aud , dba_tab_privs grt , dba_roles rle WHERE grt.owner = object_schema AND rle.role = grt.grantee AND 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%' AND extended_timestamp > sysdate - 1 ORDER BY object_schema; OBJECT_SCHEMA GRANTEE SH SALES_ARCHIVE_ROLE SH SALES_SELECT_ROLE SH SH_EXEC_ROLE_0101 SH SH_QUERY SH SH_RO_ROLE_0101 SH SH_RW_ROLE_0101 6 rows selected. A complimentary strategy for determining which roles are candidates for protection in a DBV realm is to query the audit trail for roles that were recently used in a GRANT or REVOKE command. The following query will help determine the roles that meet these criteria: sys@aos>SELECT DISTINCT object_name role FROM aos_common_audit_trail WHERE action_name IN ('GRANT ROLE','REVOKE ROLE') AND extended_timestamp > sysdate - 1 ORDER BY object_name; ROLE BASE_DATA_ANALYST_0101 CUSTOMER_POLICY_DBA 296 Part II: Oracle Database Vault DV_ADMIN DV_OWNER SALES_SELECT_ROLE SH_DATA_ADMIN_0101 SH_DATA_ANALYST_0101 SH_EXEC_ROLE_0101 SH_RW_ROLE_0101 9 rows selected. DBV Realm Authorizations Recall that DBV realm authorizations are intended to allow database administrator accounts to leverage the system ANY privileges (SELECT ANY, CREATE ANY, and so on) on objects that are protected by a realm. The following query on the database audit trail will return the account names that leveraged system ANY privileges to access or manipulate the sensitive data objects in the object-owner accounts we’ve identified. We can use this query and some additional query logic to identify both the database accounts and database roles that would be candidates for DBV realm authorizations. sys@aos>SELECT DISTINCT db_user, action_name , object_schema || '.' || object_name object_name FROM aos_common_audit_trail WHERE object_schema IN ('SH', 'HR') AND priv_used LIKE '%ANY%' AND object_type NOT LIKE '%PARTITION%' AND extended_timestamp > sysdate - 1 ORDER BY 1,2,3; DB_USER ACTION_NAME OBJECT_NAME ANTHONY EXECUTE PROCEDURE SH.SALES_TRANSCTION DEB_DATA_MGR DELETE SH.COSTS JRUSSEL EXECUTE PROCEDURE SH.SALES_TRANSCTION JRUSSEL INSERT SH.COSTS JRUSSEL SELECT SH.CHANNELS JRUSSEL SELECT SH.PRODUCTS JRUSSEL SELECT SH.PROMOTIONS MARY CREATE PACKAGE BODY SH.SALES_ALERTS MARY DELETE SH.COSTS MARY DELETE SH.SALES MARY EXECUTE PROCEDURE SH.SALES_TRANSCTION MARY GRANT OBJECT SH.SALES_ALERTS MARY GRANT OBJECT SH.SALES_STAGING MARY UPDATE SH.CUSTOMERS OPS$APPSERVER_1 EXECUTE PROCEDURE SH.SALES_TRANSCTION PTUCKER EXECUTE PROCEDURE SH.SALES_TRANSCTION PTUCKER INSERT SH.COSTS PTUCKER SELECT SH.CHANNELS PTUCKER SELECT SH.PRODUCTS PTUCKER SELECT SH.PROMOTIONS SAM_SEC_MGR ALTER TABLE SH.CUSTOMERS Chapter 7: Applied Database Vault for Existing Applications 297 SYSTEM GRANT OBJECT SH.SALES 22 rows selected. We know from the DBV examples in Chapter 6 and methodology we’ve presented so far that many of the account names returned by this query actually leveraged database roles we created for realm administrators. We can leverage this query’s results as input into a second query to determine the database roles that may be candidates for DBV realm authorizations as shown here: sys@aos>DECLARE l_index NUMBER ; BEGIN FOR c_user IN ( SELECT DISTINCT db_user, object_schema FROM aos_common_audit_trail WHERE object_schema IN ( 'SH', 'HR') AND priv_used LIKE '%ANY%' AND object_type NOT LIKE '%PARTITION%' AND extended_timestamp > sysdate - 1 ORDER BY db_user, object_schema ) LOOP DBMS_OUTPUT.PUT_LINE ( 'User: '|| c_user.db_user || ', Object Owner: ' || c_user.object_schema); l_index := 1; FOR c_role IN ( SELECT grant_type,granted_role FROM ( SELECT NULL grantee ,username granted_role ,'USER' grant_type FROM all_users WHERE username = c_user.db_user UNION SELECT grantee ,granted_role ,'ROLE' grant_type FROM dba_role_privs ) WHERE grant_type = 'ROLE' START WITH grantee IS NULL CONNECT BY grantee = PRIOR granted_role ) LOOP IF l_index = 1 THEN DBMS_OUTPUT.PUT_LINE ( 'Roles:' ); END IF; DBMS_OUTPUT.PUT_LINE ( ' ' || c_role.granted_role ); l_index := l_index + 1; END LOOP; END LOOP; END; 298 Part II: Oracle Database Vault / User: ANTHONY, Object Owner: SH Roles: DBA <truncated for brevity> User: DEB_DATA_MGR, Object Owner: SH Roles: SH_DATA_ADMIN_0101 BASE_DATA_ADMIN_0101 User: JRUSSEL, Object Owner: SH Roles: SH_DATA_ADMIN_0101 BASE_DATA_ADMIN_0101 User: MARY, Object Owner: SH Roles: DBA <truncated for brevity> User: OPS$APPSERVER_1, Object Owner: SH User: PTUCKER, Object Owner: SH Roles: SH_DATA_ADMIN_0101 BASE_DATA_ADMIN_0101 User: SAM_SEC_MGR, Object Owner: SH Roles: CUSTOMER_POLICY_DBA SH_SEC_ADMIN_0101 BASE_SEC_ADMIN_0101 User: SYSTEM, Object Owner: SH Roles: AQ_ADMINISTRATOR_ROLE DBA <truncated for brevity> SALES_SELECT_ROLE PL/SQL procedure successfully completed. Based on the examples we’ve presented we know that SH_DATA_ADMIN_0101, SH_SEC_ ADMIN_0101, and SALES_SELECT_ROLE are candidate roles for DBV Realm Authorizations. In database applications that are being analyzed for the first time, it is up to you to work with application experts and system documentation identify the functional purpose of the roles you uncover in the query results such as those shown above. Once you’ve decided which roles should be authorized in the realm, the roles themselves also need to be protected by the realm from unauthorized GRANT/REVOKE commands. You can map the database roles you discover (or those you should create) to the fine-grained separation of duty model for database administrators presented in Chapter 6. To do this, simply rerun the query above with filters on the privilege used to determine which roles map to the Chapter 7: Applied Database Vault for Existing Applications 299 administrator profiles presented in Chapter 6. The filters would be constructed according to the types of privileges granted to each database administrator profile, as shown in the following table: Administrator Profile Privilege or Role Filter Operational database administrator CREATE/ALTER/DROP TABLESPACE, ALTER DATABASE, ALTER SYSTEM, or the use of the DBA role Application maintenance administrator CREATE ANY/ALTER ANY/DROP ANY <object_type>, e.g. INDEX, PROCEDURE, TABLE, VIEW, etc. Application data manager (data steward) SELECT ANY SEQUENCE SELECT ANY TABLE INSERT ANY TABLE UPDATE ANY TABLE DELETE ANY TABLE EXECUTE ANY INDEXTYPE EXECUTE ANY OPERATOR EXECUTE ANY PROCEDURE EXECUTE ANY TYPE Application security administrator GRANT ANY OBJECT PRIVILEGE GRANT ANY PRIVILEGE GRANT ANY ROLE AUDIT ANY AUDIT SYSTEM Account administrator CREATE/ALTER/DROP USER The following query block determines which accounts or roles could be application data managers (or application proxy accounts) by inspecting the audit records for SELECT, DML, and EXECUTE commands. If we look at the use of system ANY privileges for these types of commands being used, we can identify the candidate accounts and roles. sys@aos>SET SERVEROUT ON sys@aos> DECLARE l_index NUMBER ; BEGIN FOR c_user IN ( SELECT DISTINCT db_user, object_schema FROM aos_common_audit_trail WHERE (priv_used IN ( 'SELECT ANY TABLE' ,'INSERT ANY TABLE' ,'UPDATE ANY TABLE' ,'DELETE ANY TABLE' ,'EXECUTE ANY PROCEDURE' ) AND object_schema IN ('SH', 'HR')) AND object_type NOT LIKE '%PARTITION%' AND extended_timestamp > sysdate - 1 ORDER BY db_user, object_schema ) LOOP 300 Part II: Oracle Database Vault DBMS_OUTPUT.PUT_LINE ( 'User: '|| c_user.db_user || ', Object Owner: ' || c_user.object_schema); l_index := 1; FOR c_role IN ( SELECT grant_type,granted_role FROM ( SELECT NULL grantee ,username granted_role ,'USER' grant_type FROM all_users WHERE username = c_user.db_user UNION SELECT grantee ,granted_role ,'ROLE' grant_type FROM dba_role_privs ) WHERE grant_type = 'ROLE' START WITH grantee IS NULL CONNECT BY grantee = PRIOR granted_role ) LOOP IF l_index = 1 THEN DBMS_OUTPUT.PUT_LINE ( 'Roles:' ); END IF; DBMS_OUTPUT.PUT_LINE ( ' ' || c_role.granted_role ); l_index := l_index + 1; END LOOP; END LOOP; END; / User: ANTHONY, Object Owner: SH Roles: DBA <truncated for brevity> User: DEB_DATA_MGR, Object Owner: SH Roles: SH_DATA_ADMIN_0101 BASE_DATA_ADMIN_0101 User: JRUSSEL, Object Owner: SH Roles: SH_DATA_ADMIN_0101 BASE_DATA_ADMIN_0101 User: MARY, Object Owner: SH Roles: DBA <truncated for brevity> User: OPS$APPSERVER_1, Object Owner: SH User: PTUCKER, Object Owner: SH Chapter 7: Applied Database Vault for Existing Applications 301 Roles: SH_DATA_ADMIN_0101 BASE_DATA_ADMIN_0101 PL/SQL procedure successfully completed. The query results confirm the fact that accounts such as DEB_DATA_MGR, JRUSSEL, and PTUCKER use a role named SH_DATA_ADMIN_0101 and the role should considered as a DBV realm authorization. While MARY and ANTHONY used the DBA role, we want to avoid using the role in our application-specific realms in favor of the fine-grained administrator roles presented in Chapter 6. One final note regarding why the account OPS$APPSERVER_1 is shown in our results but has no role associated to it. Recall that this account was used in Chapter 6 to demonstrate DBV SARs and the dynamic enablement of a role that was granted the SH_DATA_ADMIN_0101 role. This role is not permanently granted directly or indirectly to the OPS$APPSERVER_1 account so it is not visible within the DBA_ROLE_PRIVS view. What If System ANY Privileges Are Not Being Used? It is possible that the preceding queries that filter on the use of system ANY privileges show no results. This condition has a handful of possible implications: End user accounts have direct object privileges for SELECT and DML on the application objects either granted directly to the account or through a database role. Applications perform SELECT and DML commands using the object-owner account. Application maintenance for DDL, AUDIT, GRANT, and other database administration commands are performed as the object-owner account. End-user accounts have object privileges for SELECT and DML through grants to PUBLIC. Database accounts or roles that have been granted object privileges do not require DBV realm authorizations, so this implication is not a concern. We demonstrated earlier how to discover the roles that fall into this category to protect them within a DBV realm. The worst-case scenario is that your applications do not use database roles and have unnecessary privilege management overhead by keeping all database accounts in synch with the required direct object privileges. The rest of the implications require more research to determine whether you should be concerned. SELECT, DML, DDL, and other database administration commands performed as the object-owner account could occur if your applications use this account as a connection pool account for SELECT and DML or database administrators log into the database as this account to perform object maintenance. The problem with this scenario is the loss of audit attribution and the lack of separation of duties. You can verify the existence of this scenario by issuing the following query on the audit trail, which determines whether the database user and object-owner are the same account: sys@aos>SELECT DISTINCT db_user , action_name || decode(grantee,NULL,'',' TO ' || grantee) action_name , object_schema || '.' || object_name object_name FROM aos_common_audit_trail WHERE object_schema IN ('SH', 'HR') AND db_user IN ('SH', 'HR') AND object_type NOT LIKE '%PARTITION%' ■ ■ ■ ■ 302 Part II: Oracle Database Vault AND extended_timestamp > sysdate - 1 ORDER BY 1,2,3; DB_USER ACTION_NAME OBJECT_NAME HR CREATE PACKAGE HR.EMPLOYEE_UTILITY HR CREATE PACKAGE BODY HR.EMPLOYEE_UTILITY SH ALTER TABLE SH.SALES SH AUDIT OBJECT SH.SALES SH CREATE PACKAGE SH.SALES_TRANSCTION SH CREATE PACKAGE BODY SH.SALES_RULES SH CREATE PACKAGE BODY SH.SALES_TRANSCTION SH DELETE SH.SALES SH GRANT OBJECT TO APP_OBJECT_OWNER SH.CUSTOMERS SH GRANT OBJECT TO SH_EXEC_ROLE_0101 SH.SALES_TRANSCTION SH GRANT OBJECT TO SH_RO_ROLE_0101 SH.COSTS SH GRANT OBJECT TO SH_RW_ROLE_0101 SH.COSTS SH SELECT SH.SALES 13 rows selected. In these results we find evidence of SELECT, DML, DDL, privilege management, and audit policy commands. For SELECT, DML, and possibly some Data Definition Language (DDL) commands that are issued from applications, we recommend the use of proxy authentication approach that is covered in great detail in David Knox’s book Effective Oracle Database 10g Security by Design. For DDL, privilege management, and audit policy commands, we recommend implementing the use of the application administrator profiles (roles) for realm authorizations as presented in Chapter 6. SELECT and DML privileges granted to PUBLIC mean that anyone who can connect to the database can access or manipulate objects owned by your application accounts. You can determine the application account objects that are accessible to PUBLIC with the following query: sys@aos>SELECT owner , table_name , privilege FROM dba_tab_privs WHERE grantee = 'PUBLIC' AND owner IN ('SH', 'HR') ORDER BY 1,2,3; OWNER TABLE_NAME PRIVILEGE HR COUNTRIES SELECT HR DEPARTMENTS SELECT HR LOCATIONS SELECT 3 rows selected. If the results of this query for your application accounts cause you concern from a security or compliance perspective, you need to develop a plan to change your security model. This plan should include the creation of database roles with the appropriate direct object privileges for Chapter 7: Applied Database Vault for Existing Applications 303 SELECT and DML on the application objects. Coupled with the use of the proxy authentication feature, these roles would be used with your business applications. For DDL, privilege management, and audit policy commands, we again recommend implementing the use of the application administrator profiles (roles) for realm authorizations, as discussed in Chapter 6. Externalizing Realm Authorizations In Chapter 6 we mentioned that we could leverage an external system, such as an Lightweight Directory Access Protocol (LDAP) directory, as the source of information for a realm authorization. We can demonstrate this concept using Oracle Enterprise User Security (EUS) as the mechanism to retrieve information required. To use Oracle EUS, we must first register our database with Oracle Internet Directory (OID) and then configure components such as global schemas and global roles. (Specific details about this registration and these components are also covered in David Knox’s book.) For our example, we will create a global schema, GLOBAL_OID_TREE1, to which we’ll map our EUS users. We will also create global role that will be used to enable the database privileges required for these users to act as application security administrators. jim_acctmgr@aos> create our global schema jim_acctmgr@aos>CREATE USER global_oid_tree1 IDENTIFIED GLOBALLY ; User created. jim_acctmgr@aos>CONNECT jean_oper_dba Enter password: Connected. jean_oper_dba@aos> create our global role, we do not need jean_oper_dba@aos> to revoke the role from the operational DBA jean_oper_dba@aos> as these roles cannot be GRANT-ed or jean_oper_dba@aos> REVOKE-ed in the SQL engine jean_oper_dba@aos>CREATE ROLE sh_data_admin_global IDENTIFIED GLOBALLY; Role created. jean_oper_dba@aos> allow the global schema to connect jean_oper_dba@aos>GRANT CREATE SESSION TO global_oid_tree1; Grant succeeded. jean_oper_dba@aos> grant the Application Data Manager role jean_oper_dba@aos> role to the global role we've created jean_oper_dba@aos>GRANT base_sec_admin_0101 TO sh_data_admin_global; Grant succeeded. We use the Oracle 11g Database Control to view and configure Oracle EUS in the same way that the Oracle Enterprise Security Manager was used with a 10g database. In this example, we’ve mapped our EUS users to the GLOBAL_OID_TREE1 global schema, as shown in Figure 7-1. Next we created a EUS enterprise role named SH_DATA_ADMIN_ENTERPRISE that maps to our database global role named SH_DATA_ADMIN_GLOBAL, as shown in Figure 7-2. We also mapped two EUS accounts, JOE and SALLY, to this EUS enterprise role, as shown in Figure 7-3. You may already maintain directory groups specific to your organization, under the base group distinguished name (DN) for a specific directory domain, in our example cn=Groups, dc=us,dc=oracle,dc=com. These are called (user defined) enterprise groups in OID. You can grant enterprise roles such SH_DATA_ADMIN_ENTERPRISE to these enterprise groups if they meet your requirements. This may avoid the need to map EUS users, as was done in Figure 7-3, and reduces your overall system maintenance requirements. . sh_data_admin_global; Grant succeeded. We use the Oracle 11g Database Control to view and configure Oracle EUS in the same way that the Oracle Enterprise Security Manager was used with a 10g database. In this example,. accounts we’ve identified. We can use this query and some additional query logic to identify both the database accounts and database roles that would be candidates for DBV realm authorizations. sys@aos>SELECT. records for SELECT, DML, and EXECUTE commands. If we look at the use of system ANY privileges for these types of commands being used, we can identify the candidate accounts and roles. sys@aos>SET