Applied Oracle Security: Developing Secure Database and Middleware Environments- P27 pps

If the objects within object-owner accounts are static in nature, the use of a direct object privilege model can be leveraged for the application read-only and read-write roles.. The adm

/

PL/SQL procedure successfully completed.

These additional identities for the Client_IP and Session_User factors could also be incorporated into the Connection_Type DBV identity map presented in Chapter 5 to establish new connection classifications of INTERNAL_WEB and EXTERNAL_WEB

Read-only Application Users and Read-write Application Users

Read-only application users are typically found in reporting systems or in a privilege set that is

assigned to a “partner” application for a consolidated database with integrated object-owner accounts For example, we may define an HR read-only role for access to the objects in the HR schema and grant this HR read-only role to the SH schema or a SH-related read-write role

Read-write application users are typically found in transactional database systems as they require

INSERT, UPDATE, and DELETE commands against objects an application’s object-owner account

The users might also have access to execute PL/SQL procedures that are required to participate in the transactional nature of the system, especially in packaged applications for human resources or finance

The first things to consider before we create the end user access roles are the object access behaviors (the Verb-Object tables discussed earlier) the actors invoke in the use cases we defined for our system In our notional use case, we’ve defined SELECT (read) on several objects such as Products, Channels, and Promotions in the SH schema as well as INSERT (write) on the object Product Cost We also know that additional use cases in our system, such as the internal and external web services, will query Sales History objects

It becomes evident as we examine the Subject-Verb-Object-Condition tables we create that each use case will exhibit the need for read-only and read-write role pattern from Chapter 1 The difference among the use cases is the objects that are read from or written to It is perfectly acceptable to define the read-only or read-write roles required for each use case at the start—in other words, a role for each Subject-Verb-Object-Condition table—but we must iterate through each role definition to see where the roles for the use case are the same and can therefore be combined into common roles We must be careful not to combine them with reckless abandon,

as we want to stick with the least privilege principals and avoid exposing sensitive objects to use cases that would lead to compliance issues or policy violation issues For example, we want to avoid exposing read access to things like the company’s balance sheet numbers (compliance)

or Social Security numbers of employees (PII) to roles used in a use case such as a Partner Web Service Sales History Query

Once we’ve defined the distinct set of read-only and read-write roles we will need, we can establish a basic approach for defining these roles based on the nature of the objects involved The next topic to consider is how frequently objects are created or destroyed within object-owner accounts over the lifetime of the application(s) We also need to consider whether object-owner accounts are created and destroyed frequently, as this scenario can be found in many applications

If the objects within object-owner accounts are static in nature, the use of a direct object privilege model can be leveraged for the application (read-only and read-write) roles If object-owner accounts will be dynamic or have dynamically created objects, a system privilege model has

to be employed for the application (read-only and read-write) roles

We are left with a decision to create a finite set of roles for our use cases (or those that we are forced to use) and privilege sets that are based on either direct object privileges or system ANY privileges The decision is really based on the static or dynamic nature of the objects being protected

Database Administrator

“Database administrator” is an overloaded term that typically refers to a person who uses a highly privileged database administration account, such as the SYS account with the SYSDBA privilege, the SYSTEM account, or a named account with the DBA role These administrators can often cut across all application object-owner accounts and security controls to get the job done What’s needed is a methodology to categorize these administrators so that a separation of duty can be achieved A usable breakout of responsibilities that achieves this separation of duty among various database administrators is presented and demonstrates how DBV enables this separation

Application Administrator or Developer The application administrator or developer should

be granted a limited set of system ANY privileges that would allow him or her to maintain object types and roles that are protected by a DBV realm and are authorized within the appropriate realm DBV realms are set up to provide separation and areas of responsibility Different areas

of responsibility can be set up when more than one person does the same job but each has responsibilities for different types of data (such as sales or human resources data)

TIP

Define the areas of responsibility for determining realm authorizations.

The administrator would have the system ANY privileges SELECT ANY, INSERT ANY, UPDATE ANY, DELETE ANY, CREATE ANY, ALTER ANY, DROP ANY, EXECUTE ANY (where applicable), and AUDIT ANY (where applicable) on the following object types to read, write, execute, audit, and modify the objects owned by separate object-owner accounts that are protected in the realm:

CLUSTER

CONTEXT

DIMENSION

INDEX

INDEXTYPE

MATERIALIZED VIEW

OPERATOR

OUTLINE

PROCEDURE

SEQUENCE

SYNONYM

TABLE

TRIGGER

TYPE

VIEW

■

■

■

■

■

■

■

■

■

■

■

■

■

■

■

The administrator would also have the following privileges for managing the roles protected

by a realm and privileges and objects that are protected by a realm:

GRANT ANY OBJECT PRIVILEGE To grant SELECT, UPDATE, and other direct object

privileges on realm protected objects

GRANT ANY ROLE To grant roles protected by the realm to accounts or other roles

This full-featured application database administrator concept is already provided within the DBV product in the DV_REALM_OWNER role and can be used to implement this type of account You may be concerned about the GRANT privileges, but remember that DBV includes the out-of-the-box realm Oracle Data Dictionary that protects against improper use of the privileges for Oracle COTS roles in the same way the functional application realm would enable the proper use

of the privilege among different application realms At this point, is this full-featured administrator role sufficient? It is sufficient to manage all aspects of the realm, but when viewed another way, it

is not sufficient or at least not tolerable It does not provide for the possibility that some organizations cannot tolerate a highly privileged database administrator within a given application, especially if that application contains sensitive data, where the application administrator could disable auditing

of the realm objects while he or she “fixes” the application

We can create a model for the application administrator role that further breaks this user profile into separate application administrator profiles with distinct and sufficient responsibilities

by grouping privilege (sets) granted to the role to perform a specific job

TIP

Break down privilege sets into administrator profiles that define a job.

This method still provides the possibility of combining profiles while maintaining separation

of duties Here’s a look at the profile breakout:

Application security administrator This administrator is an application realm owner

and can create roles, grant realm-protected roles, or grant realm-protected objects to other accounts or roles The administrator can also control the audit configuration for the objects protected by the realm We will demonstrate how to extend this profile to apply OLS policy objects protected by the realm

Application maintenance administrator This administrator’s privileges are limited to

performing in the DDL category of commands on the application realm’s objects The administrator is a participant in the application realm but the privileges do not allow for querying or manipulating data protected by the realm, controlling audit configuration for the objects protected in the realm, or granting of realm-protected roles or object privileges to realm-protected objects to other accounts or roles

Application data manager (data steward) This administrator is a participant in the

application realm and the privileges granted are limited to performing queries (read) and DML, or write, commands on the objects protected by the realm Very simply put, only

SELECT, INSERT, UPDATE, DELETE, and EXECUTE commands are allowed In certain

cases, it may be possible to use the privilege set provided by this profile for read-write end user access profile if we couple it with the Subject-Verb-Object-Condition paradigm presented earlier

■

■

■

■

■

Application data analyst A read-only end user profile whose scope is all objects within

a realm This type of profile is useful for accounts that need direct access to the database outside of an application (such as a web interface) and may use tools such as SQL*Plus

or SQL Developer to perform ad hoc queries on the application data Again, the Subject-Verb-Object-Condition paradigm presented earlier may apply here

Operational database administrator The operational DBA addresses the concern that

an organization too often provides the SYS password to the IT staff members that ensure database integrity, reliability, and performance This administrator has a wide range of system privileges for SELECT, DDL, DML, and system control commands to perform generic database administration related to storage, database jobs, Oracle COTS group account object maintenance (such as Oracle Spatial or Oracle Text), or performance tuning The role we create will be granted a subset of the privileges granted to the default Oracle DBA role in the Oracle DBV The fundamental differences between

the operational DBA role and the default DBA role is removal of the following:

o Account management privileges

o Administer database-level triggers privileges, and these would be installed on an as-needed basis for applications

o Oracle Data Change Notification (DCN) and Oracle Flashback privileges to prevent snooping of application realm–protected data

The operational DBA is not authorized in any application (functional) DBV realms and therefore cannot perform commands that should be executed by the application administrator However, the operational DBA is authorized as an owner in the Oracle Data Dictionary realm provided with the DBV installation so that named administrator accounts can be established to manage the objects and roles in this “application realm” The DBV policy limits security configuration for this operational DBA role to audit configuration and privilege management (GRANTs, ROLEs) within the Oracle Data Dictionary realm The operational DBA can grant system privileges, restricted to realm owners of the Oracle Data Dictionary realm The security controls in place for DBV prevent this role (or the DBA role) from modifying the DBV configuration or row-level security controls such as Oracle VPD or Oracle OLS

Account administrator This administrator provides separation of duty/controls the

ability to create new database accounts or alter existing accounts (especially changing passwords) and database (password) profiles Many forms of privilege escalation attacks involve creating a new privilege account or modifying the existing privileged accounts

By removing this capability from the operational DBA or SYSDBA, as DBV does out of the box, we reduced the possibility of this form of attack The DBV product installs a role named DV_ACCTMGR, a DBV account management realm, along with a collection DBV command rules to model this separation-of-duty concept

DBV administrators and analysts The DBV product includes the roles DV_OWNER

and DV_ADMIN and the DBV realm that allow for a named account to manage the DBV policy and authorizations within the overall policy The responsibility is initially provided

to the named account that is granted the DV_OWNER role at the time of the option’s installation This account can create additional DBV administrators, so the use of named

■

■

■

■

■

■

■

accounts versus a group account is the direction we recommend for this administration function DBV also includes a role named DV_SECANALYST that can query (SELECT) from the DBV configuration tables and the DBV audit trail stored in the table DVSYS AUDIT_TRAIL$ In a compliance-regulated environment, or during an internal IT security review, you may need to set up named accounts and grant this read-only role to the account Figure 6-4 depicts the administrator model along with the types of actions each administrator can perform

This separation of duty model in the database administrator area may seem overly strict to the typical database administrator The intent is to demonstrate that a very fine-grained privileged model for administration is possible The level at which it is broken out can be tailored to any environment based on the unique requirements that exist The flexibility of DBV, in particular the rules-based approach that is central to the product, would not prevent you from assigning

FIGURE 6-4 Administrators and duties

multiple administrative duties to a single named account or a new profile that combines application data administrator and application analyst, for example Instead, the product lets you limit the use

of privileges with some externally controlled factor or second person using rules you define and

in the business context you desire Now that we have outlined the content and rules for our model, let’s implement it!

Example Implementation of Secure Schemas with DBV

The approach employed to achieve this separation of duties should strive to leverage roles whenever possible as this provides a solution that is the easiest to manage from the perspective

of granting system and object privileges The process presented here includes the code to create these roles and demonstrate how named accounts can be created to leverage these roles within the flow of the overall process We apply DBV policy as we proceed to help clarify its role in helping control the responsibilities of various actors

Create Operational Database Administrator Role and Accounts

Recall that our operational DBA is responsible for general database administration tasks such as storage management, job maintenance, performance tuning, and general COTS group account object maintenance related to the Oracle feature set The implementation of a role for this type of administrator is somewhat lengthy so is included as the script create_oper_dba.sql in the scripts that accompany this book These scripts can be found on www.OraclePressBooks.com on the Downloads page We can create this operation DBA role and accounts that require it as follows: sys@aos> create the role and grants

sys@aos>@create_oper_dba.sql script.

Role created.

Grant succeeded.

…

Grant succeeded.

sys@aos> authorize the role in the Oracle Data Dictionary realm

sys@aos>CONNECT dbvowner

Enter password:

Connected.

dbvowner@aos>BEGIN

dbms_macadm.add_auth_to_realm (

realm_name =>'Oracle Data Dictionary'

, grantee => 'OPER_DBA_0101'

, rule_set_name => NULL

, auth_options => dbms_macutl.g_realm_auth_owner );

END;

/

PL/SQL procedure successfully completed.

dbvowner@aos> add the role to the Oracle Data Dictionary realm

dbvowner@aos>BEGIN

dbms_macadm.add_object_to_realm (

realm_name => 'Oracle Data Dictionary'

,object_owner => 'SYS'

,object_name => 'OPER_DBA_0101'

,object_type => 'ROLE'

);

END;

PL/SQL procedure successfully completed.

dbvowner@aos> create a new named account who will serve as the Operational DBA

dbvowner@aos>CONNECT dbvacctmgr

Enter password:

Connected.

dbvacctmgr@aos>CREATE USER jean_oper_dba IDENTIFIED BY <password>;

User created.

dbvacctmgr@aos> expire the password for

dbvacctmgr@aos> the account so they are forced to

dbvacctmgr@aos> change it to something they can control at next login dbvacctmgr@aos>ALTER USER jean_oper_dba PASSWORD EXPIRE;

User altered.

dbvacctmgr@aos> grant the Operational DBA role to new named account

dbvacctmgr@aos>CONNECT / AS SYSDBA

Connected.

sys@aos>GRANT oper_dba_0101 TO jean_oper_dba

Grant succeeded.

sys@aos>CONNECT jean_oper_dba

Enter password:

ERROR:

ORA-28001: the password has expired

Changing password for jean_oper_dba

New password:

Retype new password:

Password changed

Connected.

jean_oper_dba@aos> the account can manage roles as well as system

jean_oper_dba@aos> privileges that are protected by

jean_oper_dba@aos> the Oracle Data Dictionary

jean_oper_dba@aos>GRANT RESOURCE, CREATE SESSION TO scott;

Grant succeeded.

jean_oper_dba@aos> the account can grant object privileges in Oracle

jean_oper_dba@aos> COTS account that are protected by the Oracle Data jean_oper_dba@aos> Dictionary realm.

jean_oper_dba@aos> CTX_DDL is an object owned by CTXSYS,

jean_oper_dba@aos> the Oracle Text feature group account

jean_oper_dba@aos>GRANT EXECUTE ON CTX_DDL TO scott;

Grant succeeded.

jean_oper_dba@aos> the account can manage Oracle COTS account objects jean_oper_dba@aos> that are protected by the Oracle Data Dictionary

jean_oper_dba@aos>ALTER PACKAGE CTXSYS.CTX_DDL COMPILE BODY;

Package body altered.

jean_oper_dba@aos> the account can perform system level auditing

jean_oper_dba@aos>AUDIT CREATE TABLE BY ACCESS;

Audit succeeded.

jean_oper_dba@aos> the account is still subject to

jean_oper_dba@aos> application realm protections for SELECT

jean_oper_dba@aos>SELECT * FROM sh.costs WHERE ROWNUM < 6;

SELECT * FROM sh.costs WHERE ROWNUM < 6;

*

ORA-01031: insufficient privileges

jean_oper_dba@aos> the account is still subject

jean_oper_dba@aos> to application realm protections for GRANTs

jean_oper_dba@aos>GRANT SELECT ON sh.costs TO oper_dba_0101;

GRANT SELECT ON sh.costs TO oper_dba_0101

*

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1

ORA-47401: Realm violation for grant object privilege on SH.COSTS

ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55

ORA-06512: at line 31

jean_oper_dba@aos> the account is still subject

jean_oper_dba@aos> to application realm protections for AUDITs

jean_oper_dba@aos>AUDIT INSERT ON sh.costs BY ACCESS;

AUDIT INSERT ON sh.costs BY ACCESS

*

ERROR at line 1:

ORA-01031: insufficient privileges

jean_oper_dba@aos> tests for privilege escalation

jean_oper_dba@aos>GRANT ADMINISTER DATABASE TRIGGER TO oper_dba_0101;

Grant succeeded.

jean_oper_dba@aos>GRANT ADMINISTER DATABASE TRIGGER TO jean_oper_dba;

Grant succeeded.

We don’t want the operational DBAs granting themselves privileges we are trying to protect them from using! At the same time, we want them to be able to grant system privileges or roles protected in the Oracle Data Dictionary realm as part of their normal job responsibilities Sounds like a rule would be in order here—a DBV rule to be precise The expression that would check for roles being part of the grantee list could be quite complex, if you consider that nested roles could exist With this complexity, we might not have much luck with this as a simple DBV rule set expression We will need to create a PL/SQL function to hide the complexity of the logic and need to determine under which object-owner account the PL/SQL should be created

Centralizing PL/SQL Routines for DBV Rules We want to centralize the PL/SQL routines that

we use for DBV rules for the same reasons we centralized PL/SQL code used for DBV factors We can implement common PL/SQL routines to be used in DBV rule sets in the DBVEXT schema in the same way we did for DBV factors We’ve taken the liberty of creating a function named

GRANT_OR_REVOKE_TO_SELF in the PL/SQL package DBVEXT.DBMS_MAC_EXTENSION This

function is used to indicate whether a grant occurs for the current user or roles they have been granted This logic can be used to control the realm authorizations we are defining We added to this package the SQL event context logic and call stack logic that were used in the DBV rule sets examples of Chapter 5

Protecting Against Privilege Escalation: “NO GRANTS TO THYSELF” We can now revisit

the issue where jean_oper_dba was able to GRANT the ADMINISTER DATABASE TRIGGER privilege to the OPER_DBA_0101 role and her own account Let’s revoke the privilege and modify our DBV policy to prevent this in the future:

jean_oper_dba@aos>revoke administer database trigger

FROM oper_dba_0101;

jean_oper_dba@aos> revoke administer database trigger

FROM jean_oper_dba;

Revoke succeeded.

jean_oper_dba@aos>CONNECT dbvowner

Enter password:

Connected.

dbvowner@aos> create the rule that checks

dbvowner@aos> for grants to one's account or roles

dbvowner@aos>BEGIN

dbms_macadm.create_rule(

rule_name => 'Authorized Grant or Revoke'

, rule_expr =>

'dbvext.dbms_mac_extension.grant_or_revoke_to_self = 0'

);

END;

/

PL/SQL procedure successfully completed.

dbvowner@aos> create a general rule set

dbvowner@aos> for operation DBA command authorizations

dbvowner@aos>BEGIN

dbms_macadm.create_rule_set(

rule_set_name =>'Authorized Operational DBA Command',

description =>

'Checks to verify the command is authorized for an Operational DBA', enabled =>dbms_macutl.g_yes,

eval_options =>dbms_macutl.g_ruleset_eval_all,

audit_options =>dbms_macutl.g_ruleset_audit_fail,

fail_options =>dbms_macutl.g_ruleset_fail_show,

fail_message =>NULL,

fail_code =>NULL,

handler_options =>dbms_macutl.g_ruleset_handler_off,

handler =>NULL);

END;

/

PL/SQL procedure successfully completed.

dbvowner@aos> add the rule to the rule set

dbvowner@aos>BEGIN

dbms_macadm.add_rule_to_rule_set(

rule_set_name => 'Authorized Operational DBA Command'

, rule_name => 'Authorized Grant or Revoke'

);

END;

/

PL/SQL procedure successfully completed.

dbvowner@aos> modify the realm authorization to be rules-based dbvowner@aos>BEGIN

dbms_macadm.update_realm_auth(

realm_name =>'Oracle Data Dictionary'

, grantee => 'OPER_DBA_0101'

, rule_set_name => 'Authorized Operational DBA Command'

/

PL/SQL procedure successfully completed.

dbvowner@aos>CONNECT jean_oper_dba

Enter password:

Connected.

jean_oper_dba@aos> tests for privilege escalation

jean_oper_dba@aos>grant administer database trigger to oper_dba_0101;

grant administer database trigger to oper_dba_0101

*

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1

ORA-47401: Realm violation for grant system privilege on ADMINISTER DATABASE TRIGGER.

ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55

ORA-06512: at line 31

jean_oper_dba@aos>grant administer database trigger to jean_oper_dba;

grant administer database trigger to jean_oper_dba

*

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1

ORA-47401: Realm violation for grant system privilege on ADMINISTER DATABASE TRIGGER.

ORA-06512: at "DVSYS.AUTHORIZE_EVENT", line 55

ORA-06512: at line 31

This is much better We now have a named account with operational DBA privileges that can perform many of the database functions that SYS AS SYSDBA could perform with audit attribution

to a named user We have taken some precautions to prevent privilege escalation for this type of account using standard DBV capabilities and a simple PL/SQL function

Create (Group) Application Accounts

With DBV installed, creating application accounts and protecting them with a realm is quite simple, as you saw in Chapter 5 We need to present the end-to-end process starting with the creation of an object-owner account for the Sales History application We will do this with DBV already installed so you can understand the process within this context

dbvacctmgr@aos> create the Sales History

dbvacctmgr@aos> realm's object-owner account, SH

dbvacctmgr@aos>CREATE USER sh IDENTIFIED BY oracle DEFAULT TABLESPACE SYSAUX; User created.

dbvacctmgr@aos> ensure we establish quotas on object-owner

dbvacctmgr@aos> accounts whenever possible

dbvacctmgr@aos>ALTER USER sh QUOTA 500M ON SYSAUX

User created.

dbvacctmgr@aos>CONNECT jean_oper_dba

Enter password:

Connected.

jean_oper_dba@aos> grant the DBV role

jean_oper_dba@aos> target for object-owner accounts

jean_oper_dba@aos>GRANT dv_realm_resource TO sh;