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

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 ,

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

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

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

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;

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

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

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

- 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%'

■

■

■

■

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

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