Skip Headers

Oracle® Database Security Guide
10g Release 1 (10.1)

Part Number B10773-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page

Go to previous page
Go to next page
View PDF

Security Requirements, Threats, and Concepts

Database security requirements arise from the need to protect data: first, from accidental loss and corruption, and second, from deliberate unauthorized attempts to access or alter that data. Secondary concerns include protecting against undue delays in accessing or using data, or even against interference to the point of denial of service. The global costs of such security breaches run to billions of dollars annually, and the cost to individual companies can be severe, sometimes catastrophic.

These requirements are dynamic. New technologies and practices continually provide new arenas for unauthorized exploitation, as well as new ways for accidental or deliberate misuse to affect even stable products and environments. Today's evolution involves a globally changing technological and cultural environment, in which security concerns necessarily affect both the use of existing solutions and the development of new ones.

As security requirements are understood with increasing clarity, certain general principles can be developed for satisfying them and for disabling the threats against them deriving from Internet vulnerabilities. Of course, principles can vary in effectiveness. Their implementations usually vary in cost: hardware and software acquisition and maintenance, administrative and programming personnel, and the impact of security measures on processing time and response time. Total cost also includes the costs of managing each of these areas -- hardware, software, personnel, efficiency, responsiveness, and so on -- management costs that can escalate with increasing volumes of users, transactions, and data types.

This book will address most of those issues, conceptually at first, and with increasing detail as it moves toward discussing specific choices and implementations.

The basic elements and operations of the database environment include connection to a server or a schema, table access and alteration, and application usage. Securing these against accidental or deliberate misuse is the responsibility of security officers, administrators, and application programmers. They must also administer and protect the rights of internal database users, and guarantee electronic commerce confidentiality as customers access databases from anywhere the Internet reaches.

In the Internet age, the full spectrum of risks to valuable and sensitive data, and to user access and confidentiality, is broader than ever before. Figure 1-1 shows the complex computing environment that security plans must protect.

Figure 1-1 Realms Needing Protection in an Internet World

Text description of net81070.gif follows

Text description of the illustration net81070.gif

The diagram shows several important parts of the security picture, illustrating client communities, connections, databases, and servers, all of which must be secured against inappropriate access or use. These different areas can require different techniques to achieve good security, and they must integrate so as to preclude or minimize security gaps or vulnerabilities.

Table 1-1 provides separate categories that are usable in focusing efforts to create secure operations in a secure environment. When these necessary components are consistent in their security focus, coherent in the ways they work together, and made complete by closing all known channels of attack and misuse, your security is as good as it gets.

These categories reappear in later chapters in discussing checklists and best practices.

Table 1-1  Security Issues by Category
Dimension Security Issues


Your computers must be made physically inaccessible to unauthorized users by keeping them in a secure physical environment.


The people responsible for your site's physical security, system administration, and data security must be reliable. Performing background checks on DBAs before making hiring decisions is a wise protective measure.


The procedures and policies used in the operation of your system must assure reliable data. It is often wise to separate out users' functional roles in data management.

For example, one person might be responsible for database backups. Her only role is to be sure the database is up and running.

Another person might be responsible for generating application reports involving payroll or sales data. His role is to examine the data and verify its integrity.

Further, you can establish policies that protect tables and schemas against unauthorized, accidental, or malicious usage.


Storage, access, manipulation, and transmission of data must be safeguarded by technology that enforces your particular information control policies.

When you think carefully about security risks, the solutions you adopt will apply well to the actual situation you're addressing; not all security problems have a technical fix. For example, employees must occasionally leave their desks unattended. Depending on the sensitivity of their work and on your required level of security, your security procedures could require them to do any of the following

No technical solution can fix a physically insecure work environment or a corrupt or disaffected employee. It is true, though, that procedural and technical protections might be able to limit the damage that a physical breach or a disgruntled employee (or ex-employee) can inflict.

Identity Management: Security in Complex, High Volume Environments

In addition to the general issues and categories of security, the sheer numbers of people and activities requiring a security focus add the dimension of complexity.

As the number of users, databases, applications, and networks grows from "a few" to dozens, hundreds, or thousands, the complexity of their interactions rises exponentially. So, too, do the risks, and the management tasks required to maintain security and efficiency.

For example, the number of interactions for ten users accessing any of five databases is potentially 50. Add 90 users and 45 databases, and you have 100 users accessing any of 50 databases, with potential interactions at 5,000. When you add to this example some number of applications and of networks, you begin to see extreme complexity, with directly proportional security risks. A security breach anywhere in a network can threaten the security of its databases and users, and that of other connected networks, databases, and users as well.

This type of complex environment demands speed and flexibility in granting or revoking access rights for any user and any resource. Delays in administrative processes, or their implementation on the corresponding databases, translate either to legitimate access delayed or to access granted when it should have been denied.

For example, when an employee with access to multiple applications and accounts on multiple databases leaves the company, his access to those applications and accounts should stop instantly. Achieving this can be difficult when administrative control and responsibility is distributed across nodes in the network and among different administrators and groups.

But what if an intelligent central repository could efficiently control data regarding identity, accounts, authentication, and authorization and rapidly communicate any needed information to any node or application? Then one change (or few) in one place could control the entirety of the departing employee's access rights and privileges. The assumption is that the intelligence imputed to this central repository and its software takes care of all such considerations and connections. Of course, all related system, database, and application routines would need to adjust to relying upon that central repository as the "single source of truth" regarding such information.

These considerations are the basis for an integrated Identity Management solution. Its components and integration are described in subsequent chapters, as the need for them becomes explicit in the context of general security functionality and dimensions.

See Also:

For a full discussion of Oracle's Identity Management Infrastructure, see the Oracle Identity Management Concepts and Deployment Planning Guide

As an overview, however, the following subsections provide an introduction:

Desired Benefits of Identity Management

The goal of identity management is to create

However, cost and complexity remain relevant measures of the viability of any such solution, which ideally should provide the following reductions in resource allocations:

An identity management solution meeting all these criteria at a high level would provide an enterprise with high availability, information localization, and delegated component administration. Further, each additional application deployed in that enterprise would then leverage the shared infrastructure for identity management services.

As a real-world example, the Oracle Identity Management Infrastructure uses integrated components to provide those benefits, as described in the next section.

Components of Oracle's Identity Management Infrastructure

The Oracle Identity Management infrastructure includes the following components and capabilities:

In a typical enterprise application deployment, a single Oracle Identity Management infrastructure is deployed, consisting of multiple server and component instances. Such a configuration in fact provides the high availability, information localization, and delegated component administration benefits mentioned earlier.