 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > Database access security: network authentication or data encryption? |
| |
|
|
|
|
| Chapter Download: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Table of Contents
It is no secret that performance penalties are a side effect of extended security. If you've ever developed an application that required security, we're sure that you've discovered this hard truth. We include this section in the book simply to point out the penalties that go along with security and to provide suggestions for limiting these penalties if possible. In this section, we discuss two types of security: network authentication and data encryption across the network (as opposed to data encrypted in the database). If your database driver of choice does not support network authentication or data encryption, you cannot use this functionality in your database application.
On most computer systems, an encrypted password is used to prove a user's identity. If the system is a distributed network system, this password is transmitted over the network and can possibly be intercepted and decrypted by malicious hackers. Because this password is the one secret piece of information that identifies a user, anyone knowing a user's password can effectively be that user. In your enterprise, the use of passwords may not be secure enough. You might need network authentication. Kerberos, a network authentication protocol, provides a way to identify users. Any time users request a network service, such as a database connection, they must prove their identity. Kerberos was originally developed at MIT as a solution to the security issues of open network computing environments. Kerberos is a trusted third-party authentication service that verifies users' identities. Kerberos keeps a database (the Kerberos server) of its clients and their private keys. The private key is a complex formula-driven value known only to Kerberos and the client to which it belongs. If the client is a user, the private key is an encrypted password. Both network services that require authentication and clients who want to use these services must register with Kerberos. Because Kerberos knows the private keys of all clients, it creates messages that validate the client to the server and vice versa. In a nutshell, here is how Kerberos works:
Figure 2-9 shows an example of requesting a database connection (a network service) when using Kerberos. An application user requests a database connection after a TGT has been obtained:
Figure 2-9 Kerberos Even when you don't use Kerberos, database connections are performance-expensive; they can require seven to ten network round trips (see the section, "Why Connections Are Performance-Expensive," page 11, for more details). Using Kerberos comes with the price of adding more network round trips to establish a database connection.
Data Encryption Across the Network
The native format is designed for fast transmission and can be decoded by interceptors given some time and effort. Because a native format does not provide complete protection from interceptors, you may want to use data encryption to provide a more secure transmission of data. For example, you may want to use data encryption in the following scenarios:
Data encryption is achieved by using a protocol for managing the security of message transmission, such as Secure Sockets Layer (SSL). Some database systems, such as DB2 for z/OS, implement their own data encryption protocol. The way the database-specific protocols work and the performance penalties associated with them are similar to SSL. In the world of database applications, SSL is an industry-standard protocol for sending encrypted data over database connections. SSL secures the integrity of your data by encrypting information and providing client/server authentication. From a performance perspective, SSL introduces an additional processing layer, as shown in Figure 2-10.
Figure 2-10 SSL: an additional processing layer
When encrypting data using SSL, the database connection process includes extra steps between the database driver and the database to negotiate and agree upon the encryption/decryption information that will be used. This is called the SSL handshake. An SSL handshake results in multiple network round trips as well as additional CPU to process the information needed for every SSL connection made to the database. During an SSL handshake, the following steps take place, as shown in Figure 2-11:
 Encryption is performed on each byte of data transferred; therefore, the more data being encrypted, the more processing cycles occur, which means slower network throughput. SSL supports symmetric encryption methods such as DES, RC2, and Triple DES. Some of these symmetric methods cause a larger performance penalty than others, for example, Triple DES is slower than DES because larger keys must be used to encrypt/decrypt the data. Larger keys mean more memory must be referenced, copied, and processed. You cannot always control which encryption method your database server uses, but it is good to know which one is used so that you can set realistic performance goals. Figure 2-12 shows an example of how an SSL connection can affect throughput. In this example, the same benchmark was run twice using the same application, JDBC driver, database server, hardware, and operating system. The only variable was whether an SSL connection was used.
Figure 2-12 Rows per second: SSL versus non-SSL Figure 2-13 shows the CPU associated with the throughput of this example. As you can see, CPU use increases when using an SSL connection.
Figure 2-13 CPU utilization: SSL versus non-SSL More on accessing data:
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
