Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up




Improving Data Access Security

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.


Print This Page


e-mail E-mail this URL

Research and Reports

Hypervisor Derby
August 2011

Network Computing: August 2011

TechWeb Careers