Applied Oracle Security: Developing Secure Database and Middleware Environments- P15 doc

system@aos>-- attempt to use the DBV administration package system@aos>-- using SYSTEM, the default Oracle DBA system@aos>-- to remove the DBV Realm for the database itself system@aos>BE

114 Part II: Oracle Database Vault

executed by the SYS account or enabling OS authentication, changing the database dump

destinations A complete list of security sensitive database initialization parameters that are

protected follows:

■ 07_DICTIONARY_ACCESSIBILITY

■ _dynamic_rls_policies

■ _system_trig_enabled

■ audit_file_dest

■ audit_sys_operations

■ audit_syslog_level

■ audit_trail

■ background_core_dump

■ background_dump_dest

■ background_dump_dest

■ control_files

■ core_dump_dest

■ core_dump_dest

■ db_create_file_dest

■ db_create_online_log_dest_1

■ db_create_online_log_dest_2

■ db_create_online_log_dest_3

■ db_create_online_log_dest_4

■ db_create_online_log_dest_5

■ db_recovery_file_dest

■ job_queue_processes

■ max_dump_file_size

■ optimizer_secure_view_merging

■ os_roles

■ plsql_debug

■ recyclebin

■ remote_os_roles

■ shadow_core_dump

■ sql92_security

■ user_dump_dest

■ user_dump_dest

■ utl_file_dir

Another control that is installed by DBV is the restriction that a database superuser account cannot modify the DBV policy using the DBMS_MACADM PL/SQL package or even grant the account the roles DV_OWNER or DV_ADMIN to use this package

system@aos> attempt to use the DBV administration package

system@aos> using SYSTEM, the default Oracle DBA

system@aos> to remove the DBV Realm for the database itself

system@aos>BEGIN

dvsys.dbms_macadm.delete_realm_cascade('Oracle Data Dictionary');

END;

/

dvsys.dbms_macadm.delete_realm_cascade('Oracle Data Dictionary');

*

ERROR at line 2:

ORA-06550: line 2, column 8:

PLS-00904: insufficient privilege to access object DVSYS.DBMS_MACADM

ORA-06550: line 2, column 2:

PL/SQL: Statement ignored

system@aos> attempt to grant the DBV owner role to SYSTEM which

system@aos> would offer control over the DBV policy configuration

system@aos>GRANT dv_owner TO system;

GRANT dv_owner TO system

*

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1

ORA-47401: Realm violation for grant role privilege on DV_OWNER.

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

ORA-06512: at line 31

With this triad of database administrators (security, account, and DBA) and the separation of duty that is created with the DBV installation, an enterprise can immediately operate with checks and balances to help meet whatever compliance regulations are required

Default Audit Policy

The Oracle DBV installation includes a comprehensive database audit policy designed to audit commands and activity related to DBV’s DVSYS and DVF accounts and the OLS product account LBACSYS This policy ensures that any changes (or attempts to change) to the configuration data

for these two products is captured Any subversive commands such as NOAUDIT, REVOKE, and RENAME against these object-owning accounts are also capture by this audit policy The

installation also includes a comprehensive audit policy for the database as a whole that audits the following categories of database activity:

Session login and logoff

Privilege management, such as GRANT and REVOKE commands

Database Account Management, such as CREATE, ALTER, and DROP USER commands Audit Policy, such as AUDIT and NOAUDIT commands

Structural Changes, such as tablespace management and object management with

command syntax such as CREATE <object>, ALTER <object>, and DROP <object>

Use of privileged commands including

o ADMINISTER DATABASE TRIGGER

o ALTER SESSION

o ALTER SYSTEM

o BECOME USER

o Flashback

o FORCE ANY TRANSACTION

o Restricted database sessions

o Use of system *ANY privileges

o Table truncation

This audit policy was developed from research conducted by leading government and commercial authorities on computer security that continuously publish up-to-date recommendations on this subject The protection of the DBV and OLS configuration was then added to this policy to audit these security-relevant features by default

Default Security-relevant DBV Factors

The DBV installation creates a number of DBV factors that an enterprise may find useful for developing custom DBV rule sets to control DBV command rules, DBV realm authorizations, and DBV secure application roles The installed factors can be categorized as follows:

Database and instance information

Database client network protocol

Database client language

Enterprise user information

Session authentication information

■

■

■

■

■

■

■

■

■

■

■

■

■

■

■

■

■

■

■

■

116 Part II: Oracle Database Vault

Summary: Database Vault Is Differentiating Security

In our efforts to create a richer summary section, we thought it would be good to place the summary in a discussion context As with some security capabilities in the past, people will often believe that they have created a security approach that is equal to DBV but that is implemented through some other clever set of (database) technologies Also similar to historical truth, they are misguided, and it’s important to understand this so that you, too, don’t try to build your own database vault To some degree, this is a buy-versus-build discussion In the next few paragraphs, we’ll tell you why DBV is not only unique in what it does, but unique in how it does it You cannot build an equivalent database vault—even if you could, the costs in doing so would far outweigh the costs of purchasing DBV from Oracle

One of the early ideas for creating a DBV used triggers DML triggers, and in particular DDL triggers, can be set to fire for a large number of commands Conceptually, this is similar to the concept of command rules The big difference, however, is that DBV is protected from nefarious

or unwitting actions even by administrators Triggers were not designed or intended to be used as security mechanisms Changing trigger code, disabling a trigger, and dropping a trigger can be performed by any user with the ALTER ANY TRIGGER or ALTER ANY TABLE system privilege Although DBV “uses DBV to secure DBV,” the security starts before you get to the database tables and PL/SQL code The security starts in the database kernel, as the DBV exists as a code linked into the Oracle binaries The importance of binary execution is that, unlike triggers that are implemented in PL/SQL, you are unlikely to see the source code or be able to modify it The code that is linked into the Oracle binaries supports the numerous commands you will find in the

“Oracle SQL Language Reference” and has undergone countless hours of regression testing with each database release This gives you higher assurance that it has not been tampered with As you saw when reviewing the installation of DBV, the core DBV controls are in a protected schema Even SYS is unable to tamper with DBV

The other differentiators for DBV come with its approach to implementation The declarative framework is at its core The invaluable security validation and verification capabilities are possible through the use of the framework This has been an absolute necessity for getting the security implemented and approved for operational production systems in very secure environments Transparency has also enabled DBV to succeed In Chapter 1, you learned about the

importance of transparency, and DBV has enabled this by tapping into the DB kernel The result

is that you can almost always enable DBV for an application and get things working in a more secure manner than ever before Simply add your objects of interest to a realm, add the right users

as realm participants or realm administrators, and you are on the right track This is simple to do and definitely increases your security with very little or no effort

Perhaps the most impressive statement about DBV is that it addresses security by taking an innovative approach to governing who gets access to what, where, when, and how Conditional security can be based on factors chained together in reusable rule sets and allows you to create

a myriad of realistic and useful security controls The factors are based on things you know or can validate They allow you to ensure that security is happening the way it’s supposed to be happening The ability to use multiple factors significantly increases the security of your access decisions The adaptive nature of the framework and the rules not only allow extensibility to your security, but they allow it to grow and shrink based on values that can be determined at runtime

In the next two chapters, you will see several examples of how to apply DBV to applications You’ll not only see how to get it set up and working, but you’ll learn how to blend design patterns This will not only give you a jump start on using the technology, but it will also help you solidify DBV concepts and your understanding of when and how to use it

Database Vault Fundamentals

117

118 Part II: Oracle Database Vault

his chapter presents a collection of examples that demonstrate the fundamentals behind how DBV components are configured using the DBMS_MACADM API The examples are built around the Sales History (SH) object-owner account included with Oracle Database’s sample schemas These examples cover the following component configurations and demonstrate how these components’ configurations impact sessions trying to access objects owned by the SH accounts:

Realms Provide boundaries around the use of system ANY privileges that administrators

typically have been granted Realms examples demonstrate how you can meet your organization’s compliance and consolidation requirements

Command rules Protect the use of more than 100 commands in the “Oracle SQL

Reference Guide.” Command rules allow you to implement security policies based

on the business rules maintained by your organization

Rule sets Serve as the library rules for your security policy engine We examine

the impact of rule evaluation semantics, auditing and how custom event handler

mechanisms can be enabled in response to DBV enforcement events

Factors Fundamental security policy attributes you define that form the building blocks

for DBV rule expressions and result in a multifactored security policy Example of factors linked into policies for Oracle Label Security (OLS) and Oracle Virtual Private Database (VPD) are also presented

Secure application roles Allow you to control the enablement of the more sensitive

privilege sets using business or application rules defined by your organization

Realms

A realm is a new security layer that provides containment and eliminates inadvertent access based on system ANY privileges System ANY privileges are required for many application and administration scenarios These privileges are heavily used in operating a database, but the privileges have no boundaries and therefore must be restricted The security gap exists between the database objects controlled by object privileges and the system controlled by system ANY privileges Realms were designed as a security mechanism that establishes boundaries around

a set of objects that limit the use of system ANY privileges to authorized realm users or roles Therefore, any attempt to access a realm protected object by an unauthorized user with system ANY privileges will be blocked and raise a realm violation Access based on object-level

privileges are not considered inadvertent and therefore are not enforced by the realm Object-level privileges are explicit permissions on individual objects that can be verified through

database dictionary views

Realms are a simple and critical security measure that address many of the issues we face today regarding compliance and separation of duties for different job responsibilities They also serve as an affective defensive measure for cyber security by limiting the extent to which system privileges can be exploited by an attacker Therefore, realms not only provide another layer of security, but they add another level of defense DBAs who are responsible for the health and well-being of production databases should consider the serious nature of realm violations, either legitimate or not For example, an application needing additional accesses is legitimate and a malicious attempt to access data within the database is not

■

■

■

■

■

T

In Chapter 4, we suggested that realms could be used to protect the security mechanisms that are protecting your application We know many customers have leveraged the existing database security technologies and other database mechanisms, such as triggers, views, and PL/SQL, to implement application security within the database Perhaps you have read David Knox’s

Effective Oracle 10g Database Security by Design that serves as one of the best foundations for

implementing good security practices in an Oracle database Security threats and challenges continue to surface every day and require that you update our security design and implementation

on an ongoing basis Therefore, simply maintaining an existing security approach can lure you into a false sense of security, which effectively decreases your security posture and increases your risk over time

TIP

Realm access = DB ANY privilege + Realm authorization.

Applying realms to existing security approaches increases your security posture and reduces your risk if you perform these simple steps:

1 Protect the data tables by adding them to a realm.

2 Protect security relevant objects by adding them to a realm This includes PL/SQL

procedures for VPD, PL/SQL procedures that perform trusted transactions, and

application database roles

Also consider the intent of any realm violation you encounter A realm violation will occur if

A new login session is created or an existing one is highjacked;

Key privileges are available or new privileges are gained;

Attempted access of a realm-protected object is determined to be unauthorized

Without DBV, the attempted access cannot be easily detected or blocked Realms allow application access paths and profiles to be contained and controlled It also allows for a system administrator or administrators to be better governed using both a context-based and a data content security model Realms allow you to govern security by the data semantics themselves Database administrators should consider the use of realms in production systems to update their database security to meet today’s security challenges

A good example of a need for security is personally identifiable information (PII) Within DBV realms, you can establish boundaries and controls over PII at a either the database schema level

or an object level Likewise, you can segment data as financials, personal health information, Sarbanes Oxley Act (SOX), and so forth across database schemas, so that your realm covers many objects over several database schemas

With realms for consolidation of IT resources and data, you can meet security for compliance and insider threat concerns, along with data integration for consolidation objectives Security should not be the primary excuse for not consolidating data into a fewer common databases Consolidation will clearly add more value to the processing of data that is usually transacted and queried together Consolidation will reduce operations and maintenance costs associated with multiple systems and offers these primary benefits:

Increased data availability with a reduction in the labor, power, and storage requirements

to increase this availability

■

■

■

■

120 Part II: Oracle Database Vault

Enhanced and centralized enterprise security that accounts for regulatory compliance controls

Universal access to data across the enterprise, without inefficient data movement Reduced inconsistencies due to fewer instances of data duplication

Simplification of the security management of your Oracle database and applications as centralized policies are not coded into each application To demonstrate how we meet these objectives for consolidation, consider the sample schemas that are available with Oracle Database The samples include the following schemas (a partial list):

Human Resources (HR)

Order Entry (OE)

Sales History (SH)

In many enterprises, this type of data is kept in separate databases and on separate servers This data as shown Figure 5-1

■

■

■

■

■

■

FIGURE 5-1 Preconsolidation databases

When viewed this way, it is easy to see the costs associated with maintaining these databases with respect to the power consumption, hardware costs, labor costs, software license costs, and recurring maintenance fees

With consolidation efforts in an enterprise, you can reduce the costs by hosting the databases

on a shared server platform with a smaller number of administrators, as shown in Figure 5-2 The challenge in this consolidated database architecture then becomes how to keep database administrators of the Human Resources (HR) data from accessing or manipulating the Sales History (SH) data, or vice versa To demonstrate, log into the database using the SYSTEM account,

a well-known Oracle database account The SYSTEM account has been granted the powerful DBA role and that role is granted many ANY privileges for TABLE objects:

system@aos> Display the system (ANY) privileges the account has

system@aos>select privilege name

from session_privs where privilege like '%TABLE%' or

privilege like '%GRANT%' order by 1;

NAME

-ALTER ANY TABLE

ALTER TABLESPACE

BACKUP ANY TABLE

COMMENT ANY TABLE

CREATE ANY TABLE

CREATE TABLE

CREATE TABLESPACE

DELETE ANY TABLE

DROP ANY TABLE

DROP TABLESPACE

FLASHBACK ANY TABLE

GRANT ANY ROLE

GRANT ANY PRIVILEGE

FIGURE 5-2 Consolidated databases

122 Part II: Oracle Database Vault

GRANT ANY OBJECT PRIVILEGE

INSERT ANY TABLE

LOCK ANY TABLE

MANAGE TABLESPACE

SELECT ANY TABLE

UNDER ANY TABLE

UNLIMITED TABLESPACE

UPDATE ANY TABLE

18 rows selected.

system@aos> Attempt to query the sales data using

system@aos> the SELECT ANY TABLE privilege

system@aos>select cust_id, amount_sold from sh.sales;

CUST_ID AMOUNT_SOLD

-

1258 23.75

1714 23.75

1842 23.75

system@aos> Grant object privileges on the table

system@aos> to another account

system@aos>grant select on sh.sales to scott;

Grant succeeded.

system@aos> Attempt to query the sales data using direct object

system@aos> privileges granted to the account SCOTT

system@aos>connect scott

Enter password:

Connected.

scott@aos>select cust_id, amount_sold from sh.sales;

CUST_ID AMOUNT_SOLD

-

1258 23.75

1714 23.75

1842 23.75

As you can see, the SYSTEM account has privileges not only to read or write the Sales History data using privileges such as SELECT ANY TABLE and UPDATE ANY TABLE, but the account can modify the structures in which the data is stored using a privilege such as ALTER ANY TABLE The same types of system ANY privileges are usually granted to named database administrator accounts, providing the same unbounded access to application data We must introduce a DBV realm around the SH and HR schemas to enforce the separation of duty and mitigate compliance concerns over unprotected access to PII or the integrity of financial numbers used in an audit

Realm Protection Patterns

A DBV realm can be defined as a boundary around all the objects in a database schema, a subset

of objects in a database schema, or a collection of objects in multiple schemas These example usages are shown in Figure 5-3

In Figure 5-3, a realm may be defined for objects in several schemas to support the concept

of an order management application The application may use a privileged account to access sensitive customer purchasing information and PII information for employees

In Figure 5-4, you can see a realm was created for a subset of the HR schema, where tables such as EMPLOYEES and EMP_DETAILS_VIEW can contain PII information and tables such as JOBS and JOB_HISTORY can include personal information such as an employee’s salary

In Figure 5-5, an entire Sales History schema is protected and may contain sensitive

information used for SOX compliance and auditing

FIGURE 5-3 Order Management realm (subset of object owner’s objects)

FIGURE 5-4 Human Resources realm (multiple objects, multiple object owners)