When to Use Database Encryption

Often this section is found further toward the end of the chapter, but I felt it’s important to address this area first in hopes of ensuring that the example code isn’t put into place without an essential understanding of how effective or ineffective the database encryption solution may be.

The controversy surrounds the definition of the problem encryption is meant to solve: protection of data in an unprotected medium. This is worth consideration because the database is not an unprotected medium! This is only one chapter of an entire book dedicated to proving this very point.

When people ask me how to do database encryption, I usually respond with the question, “Why do you want to do database encryption?” It is important to answer this correctly and honestly. Doing so will help you determine how and when to encrypt your database.

Reasons Not to Encrypt

Encrypting data destined for the unprotected Internet is obviously a wise decision. Within the database, the choice to do encryption isn’t always as obvious. Your security decisions should be made by asking yourself, “Why am I trying to protect this, and who am I trying to protect it from?”

Let’s analyze the reasons to encrypt data in more detail. Consider an initial request to encrypt all the data in the EMP table. The request is issued in an attempt to abide by the following security policy:

• The data in the EMP table is sensitive. The data should only be viewed by people who are authorized to access the data. Authorized users are the DBAs and the users whose names appear in the ENAME column.

• All access should be controlled at the user level. That is, the identification and authorizations should be unique for each user.

• Release of data should be on a need-to-know basis only. Users can only see records within their department.

This policy could be applied to practically every data table. The good news is the database can satisfy all of these requirements without ever requiring the data be encrypted. Strong authentication of the users is the first step to providing requirements one and two. object privileges, and fine-grained access controls will satisfy all three requirements if you have a good identification and authentication process. Auditing can also be used to ensure the requirements are being met.

Encrypting the data provides no additional benefits to the requirements. For this request, answering why you want to encrypt illustrates an important point: a user is either authorized to see data, or they are not. If the data is encrypted, then you’ll have to decrypt it for the authorized personnel. If they are not authorized, then they should not and will not get access to the data in either its plaintext or encrypted form. It’s a bad industry practice to allow users access to encrypted sensitive data even if the data is protected by the encryption.

By encrypting the data unnecessarily, you may create unintended consequences. First, as just discussed, the encryption adds no measurable addition to the security. It may create a false sense of security if you believe that the encryption process determines user authorizations differently or better than the standard access controls. It does not, and it should not.

Encryption and decryption require computational resources. Consequently, you could be putting an extra load on a database server or stressing it to the point that response times become unsatisfactory. Also, consider the fact that the data is unusable in its encrypted state. The database can’t make effective comparisons of values, computations can’t be performed, and basic database operations will be ineffective on encrypted data. The encryption conceals the data not only from the users but also from the database.

With encryption comes a responsibility to manage the encryption keys. Failure to properly manage the keys can be disastrous on two accounts. First, if the keys are compromised, the data will be decrypted, thus defeating the entire process. Second, if the keys are lost, the data can never be decrypted.

The biggest example of misapplying database encryption is when it’s used to encrypt passwords that are stored in a database table. The section “Hashing,” later in the chapter, discusses why encryption is inappropriate and then shows you how to effectively secure passwords and allow them to be used for authentication.

Reasons to Encrypt

The preceding policy does not cite any strong reasons to encrypt data, but that does not mean that there aren’t any reasons. The two most common reasons people say they need to encrypt are to comply with a “regulation” (legal, industry, or organizational mandate) or to hide the data from the DBAs.

Encrypting data “just in case someone steals my server, raw database files, or backups” is also a valid request. However, you should consider the statements I just made regarding performance and usability of the encrypted data. Selectively encrypting the data generally provides the best solution. The performance impact is minimized, and security on the extra-sensitive data can be achieved.

Let’s now analyze how effective encryption is at hiding data from the DBAs.

Hiding Data from the DBA

Probably the strongest reason cited by people wanting to encrypt database data is to hide the data from the DBAs. Depending on your interpretation, this either makes perfect sense or represents a conflicting requirement. On the sensible side, if you want to ensure that the employees’ salaries or health status are kept private, you should encrypt the data to prevent the DBAs from seeing it. When it comes to privacy-related data, hiding data from the DBAs is a perfectly valid requirement.

The conflict is the requirement to allow DBAs access to data for administrative tasks, but to prevent access when the data is not being used for administrative tasks. This statement is clearly in conflict with itself. Table and database backups, rebuilds of indexes, etc., all require the DBAs to have access to all the data. However, you don’t want DBAs to access your data and see its value. The solution is in the phrase “see its value.” Encryption will allow you to restate the requirement as “full access to data for administrative tasks, but no access to the contents of the private data.” This is a valid requirement, but nevertheless a difficult if not impossible one to fulfill.

Encrypting the data to hide it from the DBAs is a valid request. The challenge remains in doing this successfully. If you are to encrypt the data in the database, then you will have to execute a program to perform the encryption and decryption operations. DBAs can execute any and all programs in the database. The problem now isn’t preventing the DBA from reading the data, but preventing them from executing the program that decrypts the data. In addition, unless the source code has been secured, the DBA can view the program’s source to determine how it works. No matter what you encrypt, the DBA can always destroy or change your data. This fact is important to acknowledge: if you don’t trust your DBAs, get new ones.

Recall that encryption and decryption require an algorithm and a key. If you can prevent the DBA from obtaining the encryption key (remember, the database only performs symmetric key encryption), then the data will be hidden. Hiding data from the DBAs turns into a problem of hiding the keys from the DBAs. Let’s talk more about the encryption keys in the “Key Management” section later in this chapter.