Applied Oracle Security: Developing Secure Database and Middleware Environments- P26 pptx

We can identify the following objects: Product Costs Products Sales Organization Sales Management Package User Credentials Social Security Number Salary Commission System Security Packag

programs and can be integrated into row-level security mechanisms such as Oracle VPD, Oracle OLS, Oracle FGA, and database views The implementation of factors as PL/SQL opens up these possibilities and just about any PL/SQL-based database feature such as database triggers or database jobs

Identify DBV Realms and Realm Objects

Based on Objects

The next step in the process of designing the DBV security policy is to examine the objects in our security profile to determine where we may have sensitive information that needs to be protected

We can identify the following objects:

Product Costs

Products

Sales Organization

Sales Management Package

User Credentials

Social Security Number

Salary

Commission

System Security Package

Products

Channels

Promotions

Audit Trail

Audit Notifications

Next, we can ask ourselves whether we can categorize the information by the following criteria: Application and access requirements

Content type

This high-level usage analysis can be done using the information in Table 6-3, with

requirements documents such as use case scenarios or UML sequence diagrams providing input into the analysis

■

■

■

■

■

■

■

■

■

■

■

■

■

■

■

■

Table 6-3 provides an interesting analysis in that we can clearly see a set of content type or application categories that will provide a nice break-out for our DBV realms Namely, we want

to investigate whether we need to provide DBV realms for the following:

Sales

Human Resources

Database

Yes, database! That seems odd, but the database itself is an application in that it operates in the same manner as custom applications that are loaded into it—tables, indexes, views, and programs are all found As discussed in Chapter 5, Oracle DBV creates a handful of realms for the Enterprise Edition itself so the concept that the database itself should be protected is built into the product

■

■

■

Product Costs Sales (SOX compliance) Sales Management Read, Write

this use case)

this use case) Promotions Sales Sales Management Read, Write (Read in

this use case) Sales Management

Package

Sales Organization Identity Management Human Resources Read

User Credentials Identity Management Human Resources Read

Social Security

Number

Identity Management (PII compliance)

Human Resources Prevent Read

Salary Identity Management

(privacy)

Human Resources Prevent Read

Commission Identity Management

(privacy)

Human Resources Prevent Read

System Security

Package

Identity Management Human Resources Read

TABLE 6-3 Information for High-level Usage Analysis

in many customer applications The Oracle database provides auditing components and features

to enable notifications, so we can leverage these capabilities (versus building them) and simply ensure they are properly protected

Our next step is to determine which database object-owner accounts and objects will be created (or exist) to support the application itself The use case we are examining is related to Sales Management, so there will certainly be a schema with database objects in it to support this use case This research will typically be conducted with the assistance of a system or application database administrator, but for this book, we will look at the sample schemas

We see the Sales History (SH) schema has tables such as COSTS, SALES, PRODUCTS,

PROMOTIONS, CHANNELS, and CUSTOMERS So in simply examining one use case, “Add Monthly Product Costs,” we have uncovered new areas of concern related to security and

compliance If the COSTS information is of concern for SOX compliance, we can only assume the SALES information should be treated with the same level of concern In addition, if we examine the CUSTOMERS table, we can see that privacy related information is being maintained in the organization’s databases and includes customer address, phone number, e-mail address, gender, marital status, and income data!

If we examine the candidate realm Human Resources, we have to consider how identity management is handled at the enterprise and application levels If a corporation is leveraging Oracle technologies such as EUS, it can integrate database authentication with LDAP-based directories, so our concern (at the database level) is more about protecting objects such as database roles used for EUS enterprise roles We also need to consider that an enterprise may delegate the authentication against directories (or even database tables) to the application tier logic, leaving the database interactions to be based on a shared pool account using a design pattern named “application proxy.” For the purposes of this chapter, we will not discuss all the available authentication mechanisms in use across the industry

For this chapter, we will consider the Human Resources realm to comprise tables in the HR schema, as we can associate database accounts to employee-related records in this schema’s tables quite easily to resolve organizational affiliation, such as whether the logged in user works for a Sales Department We want to address DBV security policy from the perspective of multiple object-owner accounts taking part in the example use case and leave it at that When we examine the HR schema, we find tables such as EMPLOYEES and DEPARTMENTS that would be used in read operations for the example use case In the case of the EMPLOYEES table, we have potential PII and privacy concerns, and our security profile even goes so far as to dictate requirements for column-level controls on data related to Social Security numbers, salary, and commission data that might be found in this table

Configure Standard Object-level Auditing

for Realm-protected Objects

At this point, we’ve uncovered a handful of security-relevant tables based on compliance and privacy criteria In particular, the SH tables SALES and COSTS and the HR table EMPLOYEES fall into this category For compliance and privacy concerns, or for mission-critical tables in general,

we absolutely want to form a database auditing policy, even for database accounts that are allowed to access or manipulate the data stored in these tables DBV will allow for the auditing

of violations to the realm security policy, but we want to leverage normal/core RDBMS auditing

to ensure that a database administrator can provide information sufficient to pass a compliance audit, which will need to include successful transactions as well as unsuccessful transactions It

is recommended that the following audit policy be applied to each sensitive table:

AUDIT SELECT ON <TABLE> BY ACCESS WHENEVER NOT SUCCESSFUL

AUDIT INSERT ON <TABLE> BY ACCESS

AUDIT DELETE ON <TABLE> BY ACCESS

AUDIT UPDATE ON <TABLE> BY ACCESS

AUDIT ALTER ON <TABLE> BY ACCESS

AUDIT AUDIT ON <TABLE> BY ACCESS

AUDIT COMMENT ON <TABLE> BY ACCESS

AUDIT GRANT ON <TABLE> BY ACCESS

AUDIT INDEX ON <TABLE> BY ACCESS

AUDIT RENAME ON <TABLE> BY ACCESS

This policy provides audit attribution for all write transactions to the sensitive tables as well

as any security-relevant operations on the table such as GRANT, REVOKE, AUDIT, and NOAUDIT Unsuccessful read attempts (SELECT) are captured and offer visibility to potential insider threats Note that in the policy we do not recommend that you audit all successful SELECT commands against the sensitive table unless your regulations absolutely require each access to be audited The reason for this omission is that for a heavily loaded system, with a large number of read transactions or a large number of users, the amount of audit data can become quite large The amount of audit data does not really provide a lot of value unless compliance regulations or audits would need to know about each read transaction It is important to consider applying this same table-based audit policy to database views as well

Many packaged database applications leverage PL/SQL stored procedures (packages,

procedures, and functions), and you can ensure proper auditing of these program units using

a policy similar to the following:

AUDIT EXECUTE ON <PROCEDURE> BY ACCESS WHENEVER NOT SUCCESSFUL

AUDIT RENAME ON <PROCEDURE> BY ACCESS

AUDIT GRANT ON <PROCEDURE> BY ACCESS

AUDIT AUDIT ON <PROCEDURE> BY ACCESS

We have a situation with auditing successful EXECUTE operations similar to that with SELECTs

on tables We audit the successful EXECUTE operations only if compliance regulations dictate that this be done and the volume of audit data generated does not become unmanageable

Configure RLS on Realm-protected Objects

As discussed in Chapter 5, Oracle DBV is geared to authorize commands against database objects,

or statement-level security (SLS), versus an implementation for row-level security (RLS) As we have done with auditing, we need to examine the security-relevant tables based on compliance and privacy criteria to determine whether any RLS policies are required Some environments demand absolute requirements for label-based controls, but in many environments, it’s up to the database administrators and developers how RLS requirements are defined, designed, and implemented RLS is the best place to put the data security, because it keeps the security as close to the data as possible In many cases, RLS requirements are implemented within the application tier and often require additional DBV security DBV would protect the security-relevant data and packages on which the application relies to enforce the data security from the application Not adding security

is analogous to locking the front door of your house with a dead bolt and leaving your side gate open with the back door unlocked In addition, if another application comes along that requires access to the same set of tables, you have to copy the existing source code and possibly retool the existing application Whenever possible, use the advanced RLS features of Oracle Database to implement the security policy within the database

in the section related to identifying DBV factors, our example security profile presents RLS examples based on the security profile conditions around the concept of “Weekly Maintenance Window” and “Product Ownership/Responsibility.” If we dig a little deeper into the conditions and the compliance-driven requirements these conditions impose, we see that controls are required on the visibility of end user Social Security numbers and salary information to the application Oracle VPD’s fine-grained access control for security-relevant column masking meets these compliance-based requirements

NOTE

Refer to David Knox’s Effective Oracle Database 10g Security By

Design (McGraw-Hill, 2009) for a comparison between Oracle VPD

and Oracle OLS Oracle OLS is a more intuitive and declarative

model to work with initially, while Oracle VPD has the flexibility

to create and support more complex PL/SQL function policies that

implement row-level security.

Identify Accounts, Roles, and DBV Realm

Authorizations from Use Case Actors

If we look at our security profile syntax, we’ve defined what must be protected (the object), the commands or privileges we need to control (the verb), and how they need be protected (the conditions, based on compliance, application, and business rules), but we haven’t spent time describing who (the subject) To define the subject-level aspects of our security profile, we need to consider the entire set of use cases that make up our system and not just the Sales Management– related use case

If we consider the overall notional software architecture, we find actors such as sales data administrators, database administrators, batch program accounts, internal web service consumers, external (partner) web service consumers, and more subtlety accounts that will own objects and code In Chapter 1, we introduced the concept of “schema profiles” that include object owner accounts user access accounts The user access accounts included user profiles with read-only users, read-write users, application administrators/developers, and database administrators

We need to examine the actors in our use cases and classify them according to the profiles presented in Chapter 1 Next, we’ll create database roles and accounts for these actor classifications

so we can associate a real database identity to each actor Once this is done, we can authorize the appropriate role or account in the DBV realms we have identified To help clarify the process,

we will first look at the details of each profile’s relationship to DBV roles and concepts We then present a detailed implementation example that demonstrates how the profiles might be constructed

in DBV-enabled database

Secure Schemas Under DBV

We first want to examine the actors in our notional software architecture to determine how they can be categorized using the profiles presented in the first chapter and understand how DBV may shape the form of those profiles in implementation As we examine the profiles in more detail, you will discover that DBV helps enable the development of either a coarse-grained and fine-grained separation of duty model for some of the object owner and user access profiles

A fine-grained separation of duty model might be warranted in a system that contains highly

sensitive information or when compliance regulations are enforced Let’s examine each profile

in more detail to help clarify the approach to constructing these profiles as roles and accounts

Object-Owner Accounts

In this section, we introduce two types of object-owner accounts: commercial-off-the-shelf (COTS) accounts that may be required by a software product and database application and system accounts that may used in batch (database) processing jobs We will examine how these two types of object-owner accounts have common privilege models and how you can protect these accounts from being used in a manner in which they were not intended to be used

Group COTS or Application Account As discussed in Chapter 1, group accounts are installed

with vendor commercial off-the-shelf (COTS) products that are rarely accessed by privileged database administrators to perform software maintenance: MDSYS for a spatial or SH account is an example in our use case As discussed in Chapter 1, the SYS account falls into the category of a group account that is shared by many database administrators through access to an OS account’s credentials Typically, the non-SYS account would be locked with the password expired and controlled by the account administrator as described next The application account is typically granted a limited set of system privileges that enable the creation and maintenance of tables, views, and PL/SQL objects in its own schema Note that DBV includes the role DV_REALM_ RESOURCE that can be leveraged to create application accounts The role includes all the system privileges you’d find in the normal RESOURCE role with the addition of the CREATE VIEW and CREATE SYNONYM privileges This role includes the following system privileges:

CREATE CLUSTER

CREATE INDEXTYPE

CREATE OPERATOR

CREATE PROCEDURE

CREATE SEQUENCE

CREATE SYNONYM

CREATE TABLE

CREATE TRIGGER

CREATE TYPE

CREATE VIEW

CREATE SESSION

System Accounts Oracle products and your own applications will leverage accounts that

would never really be accessed by a database administrator if you are using the named user account pattern to maintain audit attribution to real end users For example, Oracle Enterprise Manager (EM) uses the SYSMAN and DBSNMP accounts for statistics collection and runs this collection processing through a database job Your own applications may have similar accounts that run on a scheduled basis as part of batch processing This processing might leverage Oracle Secure External Passwords to interact with the database to load or extract database records These accounts may own data tables, views, PL/SQL programs, and other objects that would be accessed

■

■

■

■

■

■

■

■

■

■

■

DBV realm, in the same way objects owned by the SYSMAN and DBSNMP accounts are protected

by the Oracle Enterprise Manager realm

These system accounts are typically associated with batch programs or database jobs, so the actual database access path is limited to the database servers running the database jobs or crontab processes Batch programs might also be run from a set of servers that are physically located near the database servers (for example, the same racks), such as a finite set of external application servers This

is a great opportunity to leverage DBV factors as the building blocks for the DBV rule sets that control the realm authorizations or even the DBV CONNECT command rule for these system accounts This approach can ensure that system accounts are used only under the appropriate conditions

To help illustrate this concept, consider the fact that the SH account’s objects are protected by the Sales History realm We might create a SH_BATCH account for batch processing on PL/SQL objects owned by the SH account We can then authorize SH_BATCH as a participant of this realm You can use DBV factors and DBV rules to control the conditions that allow SH_BATCH to

be authorized in this realm so that the authorization is valid only when issued from the database server (defined by the IP Address 192.168.0.251):

create the batch account

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

User created.

grant the appropriate system privileges to the batch account

CONNECT / AS SYSDBA

Connected.

sys@aos>GRANT CREATE SESSION TO sh_batch;

Grant succeeded.

sys@aos>GRANT EXECUTE ANY PROCEDURE TO sh_batch;

Grant succeeded.

create the DBV Rule Set that uses DBV Factors to authorize

the account in the realm under the conditions we want.

CONNECT dbvowner

Enter password:

Connected.

create a rule that we can use to limit

realm authorizations to sessions running on

the database server

dbvowner@aos>BEGIN

dbms_macadm.create_rule(

rule_name => 'Is Client Connection From Database Server'

, rule_expr =>

'NVL(DVF.F$Client_IP,''0'') IN (''0'',''192.168.0.251'')'

);

END;

/

PL/SQL procedure successfully completed.

create the rule set to associate the rule to

dbvowner@aos>BEGIN

dbms_macadm.create_rule_set(

rule_set_name =>'Sales History Batch Allowed',

description =>

'Checks to authorize batch commands for the Sales History realm.',

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.

associate the rule to the rule set

dbvowner@aos>BEGIN

dbms_macadm.add_rule_to_rule_set (

rule_set_name => 'Sales History Batch Allowed'

, rule_name => 'Is Client Connection From Database Server'

);

END;

/

PL/SQL procedure successfully completed.

define the realm authorization for this batch account

that uses this rule set

dbvowner@aos>BEGIN

dbms_macadm.add_auth_to_realm (

realm_name => 'Sales History'

, grantee => 'SH_BATCH'

, rule_set_name => 'Sales History Batch Allowed'

, auth_options => dbms_macutl.g_realm_auth_participant

);

END;

/

PL/SQL procedure successfully completed.

In this example, we have established these types of rules to ensure that system accounts, such

as SH_BATCH, do not issue accounts from database client, such as an application server that hosts a web application We expect database sessions for enterprise users to be established from

these application servers and for them to issue a SELECT or DML command, but anything else,

such as a SH_BATCH session, is an anomaly Our goal to confine these privileged system accounts

to known access paths helps reduce the attack surface of an exploit such as a password-cracking algorithm

User Access Accounts

In this section, we examine categories for the User Access Accounts that were introduced in Chapter 1 User Access Accounts, which are used by many database applications, can be

categorized as follows:

System Access Accounts Enable a real end-user (person) to access database

applications without requiring a real database account for each end-user

Read-only or Read-write Application Users that are dedicated database accounts for

each real end-user (person)

■

■

to the database to maintain the database structure, database security, or the database applications that reside in a database

This section discusses how to identify these types of accounts within the use-case analysis paradigm we’ve discussed so far and how the Database Administrator type of account can be broken into a fine-grained separation of duty model The section serves to lay the groundwork for the detailed separation of duty model example presented in the next section

System Access Account

Oracle technologies such as proxy authentication and EUS require a real database account

to serve as an intermediary between the database and a directory These accounts are also not typically “directly” logged into but rather are used as part of a connection pool in application servers The system access accounts are typically granted the privilege sets on objects they do not own and they are a form of the Read-only Application User or Read-write Application User profiles we will discuss next Similar to the batch-program variety of system accounts, there are access path factors or other conditions that would define the “normal use” of these system accounts The situation is reverse here, so we allowed database connections and authorized realm activity from the application servers hosting our web applications and disallowed the account usage from the database servers and backend infrastructure

Our notional database application environment has internal and external web service consumers Suppose we are using EUS and the same directory server for authentication of employees and partners to these services; we can and should map the different base user trees to different global schemas (the system access account) since the privilege sets for the consumers may be different Figure 6-2 depicts the mapping defined in the Oracle Enterprise Security Manager (ESM) for internal users to the global schema GLOBAL_INTERNAL

Figure 6-3 depicts the mapping defined in the ESM for external users to the global schema GLOBAL_EXTERNAL

FIGURE 6-2 Enterprise Security Manager map for internal users

If the application servers that host the web services for the two different sets of users are different, we can then leverage this fact as a DBV factor to fine-tune the authorizations of SQL commands issued by these two global schemas Suppose the application servers that serve (internal) employees have IP addresses of 192.168.0.100 and 192.168.0.101 The application servers that serve external partners have IP addresses of 192.168.0.50 and 192.168.0.101.51 We can create DBV rules to be used in authorizations for these system access accounts as follows:

create a rule to authorize commands for an

internal global system access account

BEGIN

dbms_macadm.create_rule(

rule_name => 'Is Internal Web Service'

, rule_expr => 'NVL(DVF.F$Client_IP,''0'') IN '

|| '(''192.168.0.100'',''192.168.0.101'')'

|| ' AND DVF.F$Session_User = ''GLOBAL_INTERNAL'''

);

END;

/

PL/SQL procedure successfully completed.

create a rule to authorize commands for an

external global system access account

BEGIN

dbms_macadm.create_rule(

rule_name => 'Is External Web Service'

, rule_expr => 'NVL(DVF.F$Client_IP,''0'') IN '

|| '(''192.168.0.50'',''192.168.0.51'')'

|| ' AND DVF.F$Session_User = ''GLOBAL_EXTERNAL'''

FIGURE 6-3 Enterprise Security Manager map for external users