1 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 up 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 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 hardware, software, personnel, efficiency, responsiveness, and so on. These management costs 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 on the Internet.

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 Security in an Internet World

Description of "Figure 1-1 Realms Needing Security in an Internet World"

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
Physical	Computers must be made physically inaccessible to unauthorized users by keeping them in a secure physical environment.
Personnel	The people responsible for the physical security, system administration, and data security of the site must be reliable. Performing background checks on DBAs before making hiring decisions is a wise protective measure.
Procedural	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 can be responsible for database backups. Her only role is to be sure the database is up and running. Another person can 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.
Technical	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 are addressing. All security problems do not necessarily 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:

Have another person cover for them while they're away
Clear the desk surface, locking all sensitive materials away, before leaving
Lock their doors, if they have private offices
Explicitly lock their computer screens before leaving the desk

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 an 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 5000. 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.

This type of complex environment demands speed and flexibility in granting or revoking access rights for any user and any resource. D elays 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 alter all access rights and privileges of an employee who is leaving the company. 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.

Desired Benefits of Identity Management

The goal of identity management is to create

Greater security, because a single point of control is inherently easier to secure and more responsive than multiple such points
Greater efficiency, because a single point of control automatically eliminates the duplication and delays inherent in a system where dispersed administrative responsibilities require multiple actions for the same accounts

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

One-time cost: Planning and implementing the identity management infrastructure should be a one-time cost, rather than a necessary part of each enterprise application deployment. In this way, new applications can be rapidly deployed, automatically benefiting from the infrastructure, but without having to re-create it. Examples could include portals, J2EE applications, and e-business applications.
Centralized management with distributable tools: Provisioning and managing identities should be done centrally, even if administered in multiple places using tools that can handle any account alteration needed.
S eamless timely distribution: Changes to user accounts, profiles, or privileges should be instantly available to all enterprise applications and rapidly communicated to distributed databases.
User single sign-on: The centralized security infrastructure should make single sign-on possible across enterprise applications. Single sign-on makes it unnecessary for users to remember multiple passwords and for security administrators to protect multiple password repositories and provisioning mechanisms.
Single point of integration: The centralized identity management infrastructure should provide a single point of integration between the enterprise environment and other identity management systems. It should eliminate any need for multiple custom point-to-point integration solutions.

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 Identity Management Infrastructure

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

Oracle Internet Directory is a scalable, robust, Lightweight Directory Access Protocol (LDAP) version 3 compliant directory service implemented on the Oracle9i Database.
Oracle Directory Integration and Provisioning is a part of Oracle Internet Directory, which enables synchronization between Oracle Internet Directory and other directories and user repositories. This service also provides automatic provisioning services for Oracle components and applications and, through standard interfaces, for third-party applications.
Oracle Delegated Administration Service is a part of Oracle Internet Directory, which provides trusted proxy-based administration of directory information by users and application administrators.
OracleApplication Server Single Sign-On provides single sign-on access to Oracle and third party web applications.
OracleApplication Server Certificate Authority generates and publishes X.509 version 3 Public Key Infrastructure (PKI) certificates to support strong authentication methods, secure messaging, and so on.

In addition to its use of Secure Socket Layer (SSL), Oracle Application Server Containers for J2EE, and Oracle HTTP Server, Oracle's Identity Management infrastructure has a built-in reliance on OracleAS Single Sign-On and Oracle Internet Directory. When OracleAS Certificate Authority is in use, it publishes each valid certificate in a directory entry for the distinguished name in use. The single sign-on server and other components can rely on these directory entries because the certificate authority removes revoked and expired certificates from the directory on a regular basis. Users authenticated by the single sign-on server, and who lack a certificate can rapidly acquire one directly from OracleAS Certificate Authority, enabling them to authenticate to any Oracle component or application that is configured to authenticate users with the single sign-on server.

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