
While the current versions of these products' client and server components use the automatic
public and private key exchange to verify each other's identity, future data-access security will
rely on digital certificates to authenticate sessions and messages. For example, Microsoft has
stated its desire to use digital certificates to maintain security in the forthcoming Windows NT
5.0. A network administrator will issue certificates to each client, and each client will include
that certificate with each network message it sends to a database server. Microsoft's proposed
use of digital certificates implies that you may swipe a magnetically encoded plastic card through
a reader to gain access to your database. Alternatively, future data-access middleware may use
your user ID and password, via the Lightweight Directory Access Protocol (LDAP), to obtain a
certificate from a third-party commercial certificate repository.
User IDs and passwords helped our database server authenticate its clients, but we also sought
application-level security. Fortunately, the ODBC driver products and Oracle's middleware
component let us specify which applications were authorized to use given database services. For
example, with SequeLink, we passed the value of a privileged key from within our test
application to the SequeLink server, which validated the key and allowed us to complete our
database update transactions. A Microsoft Access front end or other query tool, unable to supply
the correct key, could not perform a database update or insert operations with this configuration.
We used SequeLink's Dictionary Manager to designate just those database tables we wanted
each client to be able to access.
Administering database server message security in a proxy server environment requires planning
and diligent, ongoing maintenance. We experimented with OpenLink's proxy server on our test
network. Through what OpenLink calls a Rulebook, we specified, via a text editor, those clients
allowed to connect to the database, and how user IDs and passwords were to be processed. For
some clients, we instructed the OpenLink proxy server to perform user authentication; for
others, we indicated authentication should be performed by the RDBMS. Clients authenticated
by the proxy server acquired an indirect connection to the Oracle database. In this network
configuration, all database traffic flowed through the proxy server, with no direct connection
between client and database. In our tests, a well-planned proxy server along with keyed
encryption gave us a good degree of security, with a barely discernible loss in performance.
To allow anonymous access to one database but not others on the network, we used the Host,
Database, ServerType, UserID, Password and ReadOnly attributes within the OpenLink
Rulebook. We caused the firewall to make a connection to Oracle7 running on a database server
named DBServer, using an account named "scott" and the password "tiger." These entries
specified how the Proxy Agent should connect to the database. Next, we specified how clients
could connect to the Proxy Agent. Using a domain alias for clarity, the attributes and flags we
set in the Rulebook were Domain Aliases, rpc, Mapping Rules, rpc:anonparts, proxy_parts,
Program and ReUse. If we had omitted User ID and password from the Rulebook entry, the
client would need to supply them to make the database connection. We also used the Rulebook's
syntax to improve security further by restricting proxy server connectivity (and thus database
access) to certain machines.
For Your Eyes Only Encryption is the key to protecting database server traffic, but we found
any confabulation of the message contents sufficient to deter casual prying. While activating a
particular data-access method's security features gave us tough-to-crack DES- or RSA-encrypted
messages, just turning on a middleware product's compression option left message contents
illegible to anyone not using the same product with the same configuration settings.
DES, the Data Encryption Standard, is an encryption block cipher developed by IBM but
defined and endorsed by the U.S. government in 1977 as an official standard. A symmetric
cryptosystem, DES requires that both encoder and decoder know the same secret key. DES has
a 64-bit block size and uses a 56-bit key during encryption.
RC2 is a variable key-size block cipher designed as a "drop-in" replacement for DES. It has a
block size of 64 bits and is two to three times faster than DES in software. Like DES, it's a
symmetric encoding scheme. Some vendors have obtained permission to export RC2.
Theoretically, RC2 is more secure than the older DES, which has been successfully hacked.
RC4, a stream cipher from RSA Data Security, is another RSA encryption standard. It is a
variable key-size stream cipher with byte-oriented operations. The algorithm encrypts data by
altering it in a pseudo-random manner. Analysis shows that the period of the cipher (its
repeatability) is probably greater than 10100. Because only eight to 16 machine operations are
required for each encrypted output byte, RC4 encryption is much faster than both DES and
RC2.
|