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

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.. ORA-06512:

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

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

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

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

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

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> 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;

*

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

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