 |
|
|
|
|
|
Security within most applications is a critical and increasingly complex subject. Database applications
have more stringent security requirements because of the centralized storage of information. Modern
multi-tier application architectures present additional security challenges because each level and
each network connection provides additional opportunities for data to be inappropriately viewed,
modified, or corrupted. When an application is exposed to the public Internet, all of these concerns
are magnified by the potential millions of users, at least some of whom are intensely interested in
bypassing the security measures to either see or manipulate data inappropriately.
This chapter focuses primarily on the security capabilities of the Oracle database. Application developers
will be connecting to the database from a variety of different application servers, and each of these has its
own set of both security issues and features. Even though we cannot attempt to cover the specifics of
each application server, we will provide an overview of the issues and concerns that an application
developer must consider when building an application that will connect to Oracle from a multi-tiered
environment.
Security Concepts
This book focuses on Oracle development, and this chapter, correspondingly, focuses on the security
capabilities provided by Oracle. Database security is a key concern because of the nature of the
data stored within corporate databases. However, it is critical that security is considered throughout
the entire application architecture including network transport, network access, and physical
protection of servers, as well as access points to the application and network.
This chapter first examines some of the issues and needs regarding security and explores the reasons
for applying security measures at the database level.
Confidentiality and Privacy
Databases hold data of all kinds. Some have no particular confidentiality concerns, such as a table
of all valid zip codes in the United States that are publicly available. Other data, though, may
identify personal information about individual employees, customers, patients, and so on and be
subject to both stringent legal as well as ethical constraints on who may see it. Still other data is of financial
concern such as credit card or banking account information, company customer lists, product costing, or
trade secrets (such as the source code for your software product!). The costs of failures in this arena can
literally be bankruptcy and prison time.
Preserving confidentiality and privacy would be relatively easy if nobody were allowed to see or modify
the data. The applications that you build, however, are only created because there is a need to provide
access to this and other data in the database. Your challenge, then, is to ensure that only those individuals,
who have a legitimate reason to see, create, and maintain that data are allowed to do so. Even that
requirement is overly simplistic; frequently one individual may have restricted rights to see only portions
of the available data (just his or her own personal information, for instance).
Your application systems must provide controlled access by properly identified users to perform specifically
authorized actions with appropriately restricted data.Integrity
In addition to controlling who is allowed to do what to subsets of our data, you also need to ensure that
the integrity of data is preserved throughout all of the processing. Integrity can be violated by intent
(such as fraud), by accident (e.g., batch purge job run with an incorrect parameter value), or by simple
corruption because of a network or disk failure.
You can do much to control the integrity of your data through access controls to ensure that only valid
actions are performed by authorized users through defined and tested programs. You can also document
various business rules that govern the integrity of the data and implement them within the logic of your
programs and directly in the database. Finally, you can transmit and store data using protocols that verify
that the data received is the data that was sent and provide mechanisms for recovery from any corruptions.
Why Database-Level Security?
For many developers who have not worked in a database environment, it seems intuitive that controls
on access and data modification should be part of the logic of their program. “If,” asks the programmer,
“my order entry program guarantees that only valid amounts are entered into a particular field, then
that should be the end of the issue, no?”
Unfortunately, this is rarely the case. That specific program is probably only one of several that needs to
be developed to work with a particular table in the database. In addition to your online form for customers
to use, there will need to be additional online programs for customer service staff and still others for
corrections by supervisors or accounting personnel. There may be various batch programs created to
move data from one database to another, change order status for back orders and shipments, post the
data to accounts receivable, and so on. The same logic will have to be incorporated into each of those
and maintained in each. “Well,” the programmer may say, “I’ll create a method that performs the validation
that can be called from each of those.” This is a good step forward as long as the developer of each of
those other programs is aware of the method and remembers to incorporate it.
But even if all of the authorized programs contain the same validation logic, you still have an exposure.
What about the unauthorized program? How do you prevent people from connecting to the database
from their own program (or even SQL*Plus!) and changing the value in that particular field? How do
you ensure that the same transfer of funds transaction that your program initiated wasn’t captured and
then executed a few hundred extra times?Imagine the royal family of the Duchy of Datastein. The walls, fences, gates, and guards keep most casual
intruders from ever reaching the ancestral family castle. But various delivery vans, household service
staff, repairmen, guards, and invited visitors enter the castle grounds each day. So the royal family installs
a security system in the castle that electronically monitors all of the doors and windows and even motion
within the chambers. Are they fully protected? Well, some of those guests, repairmen, and service staff—
like their maid, chauffeur, and gardener—may not be as trustworthy as others. If the valuable Datastein
crown jewels and royal treasury are left sitting around the castle, then they are still not secure. At this
point it might be wise to put the valuables into a safe with a combination known only to the duke,
duchess, and trusted lord chamberlain. Now the maid may dust the Waterford crystal and the chauffeur
can wash the Bentley (as their jobs require), but they can’t count the carets or tap the treasury.
This is an artificial example, of course, but the point is that security, to be most effective, has to be extended
from the periphery to as close to the item being secured as possible. As long as there are authorized
accesses through a particular level of security, there will continue to be some exposure. Each application
program is like one of the secured gates, doors, or windows into the castle. What you don’t know is
whether the ancestral castle has any secret tunnels, hidden passageways, or trapdoors. (In the movies
they all do, don’t they?)
No security plan is totally without exposure. Our royal family is still subject to embezzlement by that
lord chamberlain, but they now have a controlled environment in which very specific individuals can be
vetted and proper procedures put in place to observe and record accesses to the royal family vault.
In short, security measures established within the database cannot be bypassed by finding an alternative
access to the database. This provides greater protection than equivalent security measures established
only in each (known) program accessing the database. Besides, they are less work for the application
development team to implement and maintain!
Authentication
Okay, you’ve now considered the need for controlling who will be allowed to access your database. How
do you know that the person asking for Joe Smith’s account balance is really Joe Smith? This is the first
step in a security system. You must authenticate users before allowing them access to any controlled
information.SapereOnLine |
|
|
|
|
|
|
|
ORACLE
|
|
|
|
|
| |
|
 |
|
|
|
|
