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

Oracle Database Vault fills that gap elegantly and innovatively with additional layers of security.. To appreciate the power of Oracle Database Vault and what it makes possible, the appl

racle has always endeavored to increase the capabilities of the Oracle Database Over the years, staggering innovations have been realized in performance, reliability, extensibility, and sheer capability Oracle Database is the number one database in the world because of these unmatched capabilities But as robust as Oracle Database is in the database security arena, a few things about the implementation needed to be improved It may be startling to discover that, until recently, a security gap in Oracle Database desperately needed to be filled This gap has become wider and more relevant because of the critical security challenges we face with compliance and cyber security today Oracle Database Vault fills that gap elegantly and innovatively with

additional layers of security And unlike many features of the database, Oracle Database Vault radically changes what you do as a DBA and how you do it Therefore, you will most certainly want to review this part carefully

In Chapters 4–7, you’ll learn about Oracle Database Vault in detail This chapter discusses the security gap, including the reasons why Database Vault was created Understanding the design intent can help you understand why you should use it, when you should use it, and how you should use it That is the goal of this chapter: To understand why Oracle Database Vault is needed and how its core components work the way they work

Chapter 5 is perhaps the literary equivalent of the military’s basic training This chapter leads you through the basic workings of the product, including the core capabilities and principles that Oracle Database Vault brings to the database

Chapter 6 puts Oracle Database Vault to work in the context of application building To appreciate the power of Oracle Database Vault and what it makes possible, the applications used in the examples are somewhat unconstrained—that is, you have the flexibility to modify the application configuration and potentially the code to take advantage of all that the Oracle Database Vault has to offer

Chapter 7 examines Oracle Database Vault in the context of applications, but this time, for existing applications We debated how to title Chapter 7 because of what the word “existing” can mean In this context, existing applications are applications that offer you limited modification options In fact, modifications are largely configurations Our approach is that you don’t have the luxury of modifying your application’s source code, its accounts, or its structure Anything you do occurs around the application and in a transparent manner

The Security Gap

Chapter 1 covered important concepts about data categorization, identity management, and database account management Many of those concepts are important to the information covered

in this chapter Specifically, security issues center on object owner accounts or schemas versus user accounts—that is, the accounts we want users to log in to.

To understand why you need to use Database Vault, look closely at your core database accounts, including default privileges and their default intent You may recognize security gaps

or suboptimal conditions that can be directly addressed by Oracle Database Vault (DBV)

History of Privileged Accounts

Recall from Chapter 1 the discussion about two of the primary accounts/schemas for Oracle: SYS, the object owner of the database engine, and SYSTEM, which acts as a DBA user account Oracle

uses metadata tables (aka the data dictionary) to manage many database functions, and the fact that SYS owns these tables accounts for some of Oracle Database’s most serious security

O

implications SYSTEM is the standard account to which DBAs connect to create users, create tablespaces, and perform basic DBA tasks and is covered a bit later in the chapter

Object owners have all rights on all objects they own For SYS, this translates to full rights on many of the core database objects, including objects owned by accounts supporting any given application As you will see, the security discussion goes beyond this simple principle

The angst around SYS has recently climaxed in part due to the sensitivity of data and data types such as financial records and personally identifiable information (PII) Governance and compliance issues and concepts such as segregation of duty have also focused attention on SYS The concern is that SYS has the complete and unregulated ability to do absolutely anything and everything in the database And unlike SYSTEM, SYS doesn’t need to be granted privileges to do these things The privileges are automatic because of the object owner principle and because SYS has to work that way for the database to work at all

SYS can not only disable security policies (such as Virtual Private Database, or VPD, policies), but can do even more, such as delete data from the audit trail This means a user logged into the SYS account has the ability to do bad things, and to do them without any record or trace that they were done In fact, the issue of deleting from the audit tables drove the requirement for operating system auditing for SYS Although we cannot stop SYS from performing these actions, we must have a way to audit SYS without the risk of SYS deleting or changing the audit logs

Superuser 0

The all-powerful SYS is not actually intended to be a user This can be confusing, because you can log into the SYS account with a password, and this process is really no different from the way you would log into any generic database user account Therefore, it’s difficult to discuss the concept of SYS not being a database user with someone unfamiliar with Oracle but very familiar with compliance initiatives

It turns out that in addition to SYS owning many of the objects that run the database, much of the database code checks to see if the user is specifically SYS If you query SYS.USER$, you will see a column titled USER#, and for the user SYS, this column has a value of 0 (zero), because SYS

is established as the primary owner of the core database objects

What makes SYS a superuser with unyielding rights has a lot to do with the fact that SYS owns many of the objects that run the database There are two important points to be made here First,

we know that we must have SYS for the database to function We need to have a container for core database objects And we need to be able to log on as SYS to install patches, perform upgrades, conduct backup/recovery operations, and perform other important tasks Removal

of the SYS account is simply not an option

The second point to be made is that there is a huge security risk in having a super-user account Security is essentially and intentionally bypassed with SYS, and this is not optimal for many security architects It is also undesirable if you are trying to conform to compliance guidelines around segregation of duties

The SYS account’s major risks are not necessarily most severe when an actual person has connected to the database as SYSDBA, but rather when the code underneath the user’s session

is operating in the context of SYS This can occur through techniques such as privilege escalation and SQL injection code that exploit security vulnerabilities These techniques, if successful, can allow someone to tamper with the database security controls and/or gain access to very sensitive data Poorly secured databases are certainly targets, but even well-designed and secured systems can be attacked But these risks can be significantly reduced by upgrading to DBV and adding a few new DBV concepts to your system One of the fundamental objectives of DBV is to ensure that the SYS account can be controlled and will not inherently bypass the new security layers it introduces

Other Privileged Accounts

It wasn’t too many versions or years ago that all the core database objects were stored in the SYS account The first departure occurred with SYSTEM, which was created specifically to address the object owner principle and to separate a user from the database objects At first, many objects were shared with SYS and SYSTEM, but over time, SYS retained sole ownership and SYSTEM became the intended DBA user account This allowed us to start controlling who has access to what, because SYSTEM required privileges to perform actions (although giving SYSTEM every possible privilege tends to defeat the intended goal)

As Oracle introduced more options and capabilities, with the release of Oracle 7.3 there came a need and an obvious desire to create separate schemas in which to install these options Schemas such as MDSYS, which supports spatial data objects, and CTXSYS, which supports Oracle text objects, came to be These schemas were meant to serve as containers for the objects that made up the options (In this chapter, we’ll refer to them as an “option’s schemas” to

differentiate them and note their intended role.)

In a similar manner to SYS, administrators—and anyone with the correct password—could log onto the option’s schemas In addition, in combining the object owner principle of SYS and the need to grant many privileges such as SYSTEM, the option’s schemas were sometimes considered

to be superusers in their own right

Other accounts of note quickly sprang up as well Large enterprise applications followed similar models of creating object container schemas with extreme privileges But this was not isolated to enterprise applications Many small- to medium-size applications also adopted this architecture There were good reasons for the apparent excessive privileges, which you will learn more about

Today’s Accounts

Today, lots of accounts can do lots of things: SYS and SYSTEM; every Oracle database option schema; enterprise resource planning (ERP) application schemas and user accounts; customer relationship management (CRM) application schemas and accounts; other back office enterprise application suites; and custom and other third-party software schemas and accounts There are a lot of schemas, and the implementations are fairly consistent, as described earlier

It’s worth repeating that the security ramifications are enormous All these accounts have login potential The object owner principle exists, but, more important, vast privileges—often system

*ANY privileges—are in place This allows the schema or a user logged into that schema to do not only what is required for the application or option, but to do quite a bit more than what was originally intended

The Security Remedy

Security specialists and best practice recommendations from folks such as the SANS Institute offer

a consistent approach to dealing with these security problems: lock and expire the accounts Other suggestions, such as some made by the authors, have included varying technical Band-Aids such

as setting impossible passwords, auditing logons, and sending alerts if someone accesses one of the special schemas

The thinking is that you don’t want people logging into these schemas because they are object owner–intended schemas and not user accounts In many cases, new requests come in from the security or governance committee, asking if the schemas can be removed altogether In other cases, such as with the Java Virtual Machine (JVM), removal of the schema can occur, but this is often not a supportable configuration While the suggestions mentioned here are good security practices, they are still suboptimal

To resolve the security issues, think about what you need to do to architect this properly You need to be able to partition schemas to avoid the object owner principle from cross-infecting your applications and data You also need a way to limit the privileges on those schemas to restrict them to their particular area of responsibility—that is, users should have all privileges only within their application domain

One More Clarifying Challenge

One final wrinkle that you may recall from Chapter 1 will help you put this discussion in perspective Recall that many applications span several schemas, often for good design reasons, even outside the security realm As it turns out, the system privileges—in particular, the system *ANY privileges

(such as SELECT ANY TABLE, DELETE ANY TABLE)—are granted to schemas so that users can access

all the tables used by an application regardless of which schema contains the tables

Many applications include thousands or tens of thousands of objects Direct object grants are not practical Logging in to each schema to perform an operation is impractical if not undesirable The only practical choice is to create new object owner accounts and grant the system *ANY privileges, thereby leaving us with a potpourri of user accounts, schemas, and vast privileges

It is a perplexing dilemma

The Gap Identified

This last reflection puts a light on the security gap that exists Before we declare it directly, let’s follow the logic of how we identified this the security gap To illustrate this point, suppose you are building a sales reporting application in which all the historical sales data is stored in a schema called the SH schema This application requires some helper objects—materialized views, PL/SQL procedures, and other objects—that you naturally create in a different schema called the

SHELPER schema

The administrator for the sales reporting application requires full access to the SH and SHELPER schemas Logging into one schema does not necessarily do her much good, because object owner rights are limited to the schema in which the admin logs in (We noted that there are often more than two schemas in most applications.) Logging into every schema is not a practical solution, so the administrator will do one of two things: She will log into one of the schemas directly, such as the SH schema, after having granted system privileges to SH, and she will then use those system privileges to access the SHELPER schema True user identity is lost in this scenario, however, because it leaves no attribution to the real user who performed the operation

Option two is to create a new user account that can be associated with a real person (let’s call it SR_ADMIN) and grant that user all the system privileges The good news is that the

administrator’s identity is preserved because she has a private schema The bad news with this option is that it creates another user who can do much more than is desirable for security

You may suggest, as have many, that a new privilege grant or grants are needed to grant all privileges on all objects within a schema to another user The grant syntax might look something like the following:

/* Wouldn't it be nice if

we could give all privileges

to everything in the SH schema

to SR_ADMIN with the following

*/

GRANT ALL ON SH TO SR_ADMIN;

/* Wouldn't it be nice if

we could give select every table

in the SH schema to SR_ADMIN

with the following

*/

GRANT SELECT ON SHELPER.% TO SR_ADMIN;

Now you see the gap In Oracle, direct object privileges occur at an object by object level—for

example, GRANT SELECT ON SH.SALES TO SR_ADMIN System privileges exist for all objects everywhere (barring the data dictionary)—for example, GRANT SELECT ANY TABLE TO SR_ADMIN.

You can see the need for a middle ground—a privilege set that allows everything within a

certain schema or set of schemas This last notion of a set of schemas is called a realm, and it is

one of the new security layers provided by DBV Before we consider that, and since we are in the mood for improving things in the database, let’s look at a few more security should-haves

Security Should-haves

Over the years, as you’ve built security into your databases, you have probably come across a few techniques and methods that were extremely useful and effective As avid security engineers,

we, too, have discovered patterns of success not only within the database but also outside of the database In this section, we’ll review a few of these methods or requirements that have found their way into DBV

Multifactored Authentication

The notion of multifactor authentication is probably a familiar concept Multifactor authentication involves using more than one item to authenticate a user (or entity) and is usually considered as

an alternative to using passwords Multifactor authentication is considered more secure than single-factor authentication because several authentication mechanisms are far more difficult to compromise, obtain, or spoof than a single form of authentication Multifactor authentication is required to perform many real-world transactions, such as setting up a new financial account or obtaining a passport

Our objective is to take the notion of multifactor authentication and bring it to privilege enablement within the database This is the basis for one of the most loved privilege enablement techniques in the database: Secure Application Roles (SARs)

SARs are enabled from within defined procedural code The notion is that simply enabling

roles either by default or explicitly (via the SET ROLE command) was generally not good enough With SARs, the database validates that the SET ROLE call is being made from within the defined

procedure code This complies with multifactor authentication because the code can perform various checks prior to enabling the role If the checks fail, the role is not enabled SARs thus gives you a multifactored approach to privilege enablement from within the database

Conditional Security

While implementing the logic within the SARs procedures, many popular methods and checks would and could be performed to allow us to form some abstractions and classifications:

Context-based security Recognizes that the privilege should be allowed only as part

of a specific configuration, fact, function, business flow, or other specific situation If the situation does not exist, an incongruity exists in the context of what is allowable and supposed to happen, and therefore the privilege should not be enabled For example, the privilege could be enabled only at a certain time of day or on a certain day of the week

■

Alternatively, the privilege can check how the user authenticated, where the user are coming from, and which application the user is using

Adaptive security The overall security is changing in near real time The procedural

code can detect the current state and loosen or constrain privileges accordingly For example, an intrusion detection system detects an attack and raises a signal that the procedure reads and then denies a privilege request The core concept is that the security

is not rigid, nor does it rely on human intervention; it is designed to adapt itself to the situation

Separation of duty An often dreaded phrase, separation of duty prevents (or attempts

to prevent) any single person from performing nefarious actions or duties The separation forces a co-conspirator to play along Just as a single factor is less secure than multiple factors, a single user is less secure than multiple users Within the database, many accounts offer privileges that may conflict with a desired regulation To resolve this, privileges would be enabled sequentially or would be able to validate that a multiple-person action is taking place

Conditional auditing Auditing is part of the security life cycle, but it suffers many

problems similar to those of privilege enablement requirements Auditing is generally turned on or off Fine-grained auditing was a major step forward in achieving the desired objective of auditing only when we want to audit The “when” is based on the contextual basis and adaptive security objectives

Some of the requirements you derive will probably land in multiple categories This

discussion is meant to serve as a new way of thinking about security—that security can be conditional It is not rigid like a role with its static set of privileges It should not be turned either

on or off In deciding whether a user may perform an action can be “it depends.” In many ways, conditional security separates the decision-making part of security from the enforcement part

Practical Implementation Lessons

Many lessons have been learned in the implementation of security and security policies One that always comes up is transparency, mentioned in Chapter 1 but worth a replay here because it is

an essential element of success for many security implementations Transparency is important for security because it acknowledges that user or application interference for pure security reasons is always undesirable If you can secure something without causing extra work for the user or code modifications, then that is the way to proceed

The next lesson learned in effective security implementations is the judicious use of a

declarative environment VPD security is great, but Oracle Label Security (OLS) is better, because OLS is declarative Having a declarative framework saves coding time, reduces risk, and increases success (assuming that the framework is sound) A declarative framework also facilitates security verification and auditing tasks, as validating settings in the framework is almost always

exponentially easier than validating code

TIP

Move as much of your code as possible into a declarative framework

This saves time, reduces risk, and allows others to validate the

implementation more easily.

■

■

■

Securing by Command

A final nice-to-have capability concerns security by command A command in this context is any

Data Manipulation Language (DML) or Data Definition Language (DDL) SQL statement SARs help to motivate this discussion, because they suggest that a user must have privileges to execute

a command, but the command can be controlled conditionally through another layer of security With security by command, the focus shifts from the role to the ability to execute a command Assigning privileges directly to a user or grouping them in a role and then granting them to the user should not be the only methods that grant users the ability to execute commands Instead,

we can treat the ability to execute a command in a manner analogous to the conditional security mentioned earlier Consider, for example, a user’s direct privileges that are required to perform

some action (such as using a SELECT on a table), and add another layer that can reject the action

if a certain condition is not met

Recall that the conditional security philosophy says that the answer to deciding whether a user should be able to do something is “it depends.” This is not role-dependent Ultimately, it would be nice for the database to evaluate all commands in a conditional, extensible manner

Database Vault Components

Now that we have identified a few areas to improve, let’s look at how DBV addresses these requirements and security should-haves The objective is here is simply to impart the natural and intuitive architecture for DBV Having a fundamental understanding of the DBV components— why they are what they are—will help you to employ DBV in an effective manner

DBV is built largely around a declarative framework that consists of tables that store

information that drives the desired security policy and security enforcement The framework

is manipulated by a set of web-based user interfaces and a set of application programming interface (API) calls to the PL/SQL code

One of the principles that drove the design of DBV was to provide higher assurance through additional security mechanisms that were separate and distinct from the existing database

mechanisms Risks are not always associated with an actual user’s session privileges; they

do occur when the code underneath a user’s session is operating in the context of a powerful privilege that could be exploited for malicious use

The High Assurance Principle (HAP) defines a basic security axiom: the use of multiple security mechanisms from different sources provides a higher level of assurance than using multiple security mechanisms from a single source

NOTE

HAP for database security = 1 DB mechanism + 1 DBV mechanism.

HAP for database security separates the security mechanisms into two sources: core database security (accounts, privileges, roles, VPD and views, PL/SQL, and triggers) and Database Vault security (factors, rules, realms, and command rules)

In addition to making a robust security implementation possible, DBV’s declarative nature helps others—auditors, in particular—verify and validate your security policies We cannot over-emphasize the criticality of this point When security is buried inside code, it is more difficult to understand, modify, and reuse To this end, you will see that DBV has built itself around an easily verifiable, yet robust and resilient, security model

We’ll start at the most elementary place, which for DBV is factors Think back to the discussion

about multifactored and conditional security With conditional security, we are not making security decisions based on whether or not a person has the “privilege” to do something Security

is more dynamic and can involve many factors that are checked at runtime and can be very extensible

Multiple factors can be considered when you’re deciding whether or not to enable a privilege

or perform an action—time of day, day of the week, how the user authenticated, whether the request was part of a specific transaction, and so forth Each, if not all, of those elements can be a factor in the overall security decision—that is, the decision on whether or not to allow an action

to take place, and the individual elements can be thought of as security factors

NOTE

For DBV, a factor is simply an item that you decide to use to make

security decisions.

Factors are discrete security-related attributes that resolve to a specific value As you might guess, these factors are generally resolved using PL/SQL expressions Factors are like application context variables, but you don’t have to develop any code to set, audit, and provide event handlers

Protecting the Security Mechanisms

If you have ever employed SARs or written VPD policies with application context variables, you are quite familiar with the use of factors Everything from the user’s identity, to a client identifier,

to an IP address are factors that are commonly used to ensure that the security policies are being upheld With DBV, factors are declared, named, and stored in tables This allows factors to be reused, validated, and security enhanced

Factor security is possible because the entire DBV infrastructure is secured One of the biggest risks to any security implementation is an attack on the logical implementation itself If you are using PL/SQL to protect your data, either as part of a SAR, a VPD, or even an API to prevent direct data access, what protects the PL/SQL? Without DBV, nothing protects the security infrastructure other than standard security rights, which, as you have seen, are frequently overridden by system privileges

DBV ensures that the things that are used to secure the database are also protected This is an important point: DBV significantly strengthens any security implementation It cannot be replicated using any other database mechanism

NOTE

DBV protects the things that protect the things.

Rules

If you’ve written security code, you know that within your security policy or implementation, you construct a set of logical statements These statements are used to determine whether an action can or should take place Many statements take the form of Boolean logic that uses logical ANDs and ORs nested inside IF-THEN-ELSE statements You usually write code that says something analogous to “if this and that, or the user is an administrator, then do choice one, else do choice two.” You could say that the security rule determines which choice will occur

For a simple database example, consider the following logic checks to decide whether a user can SELECT from a table:

The user authenticated using Secure Sockets Layer (SSL)

The user’s request comes from the application server’s known IP address

It is currently Monday through Friday

The time is not between the hours of midnight and 6:00 A.M

The user is a member of the SALES_DEPARTMENT user group

What you know about these checks is that each is a security factor In DBV, each will be represented as a factor that, when called, will return the value in a secure way We are taking the security factors and putting them together in a logical series of ANDs and ORs, which you could call your security rules

DBV rules are the sequence of factors that you use to determine your security rules Our five security checks or the factors stated previously could be combined into a rule that is used to determine appropriate access privileges If all five factors are met, the rule may say, the action can be performed

DBV Rule Sets

As with factors, rules are stored in the DBV declarative framework Depending on your

experience, you may quickly identify with this best practice Quite a few implementations use declarative constructs The security code reads data from the tables and enforces what the data tells it to do This makes it easy for you to add or modify the security factors or rules To modify your security, you add or delete a new record in the table This is also the basis for DBV rules and factors It is simple, secure, and intuitive

As DBV was being designed, it became clear that rules were a key component that offered

high reusability Therefore, DBV supports the notion of a library of rule groupings known as rule sets, which allow for a large amount of logic reuse that typically governs access for different

controls within an application By aggregating the rules into a rule set, you gain a much simpler and more maintainable security model

Realms

At the heart of our security gap discussion is an architectural quandary We have been looking at object owners and user accounts and observing default behaviors, possibilities, and limitations The quandary concerns the use of implicit and granted privileges on objects based on the schemas in which the objects exist and the schema the user is logged into when attempting to access these objects

The ideal schema/user design solution is none of the above In analyzing the basic security

requirements, what you are really trying to do is to apply security to a certain set of users on a certain set of objects It’s not a certain set of users for all the objects in the database The system

privileges apply to all objects in the system—that is, the database Unfortunately, system

privileges (especially the ANY privileges) are essential, because our applications access many objects across many schemas

We need to alter our thinking, then, about how security is supposed to work Think about the security requirements for only a single application as opposed to security for the entire database Application security means that you want to ensure that everything that happens to the data for

■

■

■

■

■

the application is secured You are not concerned about the other data or applications in the database so long as they don’t interfere with your application Likewise, you want to ensure that any application user or administrator is also prevented from tampering with things outside the application This is a subtle but important change in thinking for many database experts

Let’s now focus on the simple notion of object grouping, with an emphasis on security You want to define what your application is with respect to the database You want to list the objects and schemas and declare those objects to be part of the application Your ideal security model would then allow you to define the security behavior relevant only to those particular objects without regard to all the other database objects

This all drives the requirement for DBV realms, a new security layer that provides containment

and eliminates inadvertent accesses based on system privileges

NOTE

Realms are the collection of (application) relevant objects that are

grouped together for security reasons.

You can think of realms as marking a set of objects—tables, views, roles, PL/SQL, and so forth— that you want to protect, regardless of which account owns the object The objects are identified across the various schemas and placed in a realm Once the objects are placed in a DBV realm, they are instantly protected from users with system ANY privileges

The sandbox metaphor used to describe how Java applets are secure within a web browser

is also relevant here Each application, when in a realm, can be considered as being in its own security sandbox within the database System ANY privileges no longer give you access to items protected within a realm Therefore, putting your application objects in the same protected sandbox or realm allows you to limit very specifically who gets access to what

Our definition of realms, which used the natural grouping of objects generally associated with applications, helped us explain why you would group objects However, there is no restriction

in DBV for objects to be bound to any application or anything in particular Realms are purely logical groupings; you define the reason for the grouping

Realm-isms

Realms can consist of any objects from any schemas They are not simply subsets of a single schema This allows you to maintain a database design based on factors other than security while still being able to support security

Once the objects are in a realm, they are protected from users that have system ANY privileges Realms can also contain users The ability to map users to realms works well to support most security policies that define specific application administrators and separation of duty

requirements

You can think of users as realm administrators and realm participants An administrator can

execute privilege management commands (GRANT, REVOKE) on objects and roles that are

protected by the realm, while a participant cannot The process of setting up a realm is as simple

as defining the objects of interest and then adding users to the realm as either administrators or participants This allows you to keep other users—even SYSTEM and other privileged accounts— from tampering with objects and data in your realm

Realms generally consist of objects from multiple schemas and are especially important to security relevant information (metadata) such as a table that lists group memberships Database roles can also be defined as part of a protected realm object in addition to the typical database object types you may identify at first You can include roles in the realm protections to protect