Encryption - Implementing Database Security and Auditing - page 319

It is impractical to use this data from anything but the application.
For example, you will not be able to use your favorite SQL editor or
DBA tools. Note that in tight security environments this may be
viewed as an advantage, but for most of us it is too much of an incon-
venience.
This approach doesn't simplify anything; it merely passes the need
to deal with encryption to the application layer (i.e., it just makes it
someone else's problem—someone who is one step removed from
the data, meaning that it is often more difficult to debug and tune
the solution).
Encryption at the file system layer
The second approach takes the other extreme—passing the burden to the
operating system. This approach uses facilities that are usually available in
advanced file systems for storing data on disk within an encrypted format.
As an example, Windows implements the Encrypted File System (EFS),
and you can use EFS to encrypt the data files used by SQL Server on disk.
There are a few problems with this approach, too. Performance degrades
when this option is used because everything needs to be decrypted in order
to be used. In addition, this approach can only solve the problem of disk or
file theft; it does not address the issue of prying eyes because from an oper-
ating system perspective, all access is done by the SQL Server process, and
there is no way to distinguish between an unauthorized user—authorized to
use SQL Server but unauthorized to access the data—who is accessing the
data versus access made by the owner of the data.
Encryption within the database
Finally, we get to the most practical option—that of using the database to
encrypt and decrypt data. This category of implementation methods
includes both built-in database routines and the use of third-party exten-
sions to popular databases. In both cases, the important elements of a good
data encryption scheme are access to cryptographic functions, good key
management, and transparent handling of encrypted data.
Cryptographic functions are complex, and you certainly don't want to
write your own version of these algorithms. Look for a good, efficient
implementation within your database or external add-in. As an example,
in SQL 2005 you can access the Windows CryptoAPI, including func-
tions for DES, Triple DES, and AES, and you have support within T-SQL
through the DB_ENCRYPT and DB_DECRYPT functions. The