Applied Oracle Security: Developing Secure Database and Middleware Environments- P30 pdf

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 a

/

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

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

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

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.

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

■

■

■

SQL Command Owner Object Rules

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

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

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

, 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

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