Database Encryption Solutions

Given recent well-publicized data leaks and beefed-up security regulations that require companies to publicly disclose when unencrypted data has been exposed, all companies not using database encryption should be asking themselves why not. At the simplest level, database encryption addresses the concern that an attacker might get through your network’s other defenses or that the attacker might be someone from inside the organization. Encrypting data helps keep your company’s name from appearing in the headlines next to disturbing phrases such as “security breach.”

Related: SQL Server Encryption Options

However, database encryption isn’t a one-size-fits-all solution. Your organization needs to evaluate what data needs protection, where the encryption should be performed (e.g., in the database, in the application where the data lies, above the database), and how much performance it’s willing to trade for increased security. You might have no choice in these factors if you must encrypt data to comply with particular regulatory standards such as The Payment Card Industry Data Security Standards or the Health Insurance Portability and Accountability Act. But how? And with what? The product table (part 1, part 2) compares features from the vendors who participated in our research, if you’d like to jump there now.

Why Not Go Native?

You could use the built-in encryption of Microsoft SQL Server 2005, but that often involves rewriting database and front-end code to make encryption work. In SQL Server 2008, the Extensible Key Management (EKM) feature introduces the option of using EKM-compatible third-party products along with built-in SQL Server encryption. And SQL Server 2008 will offer transparent database encryption (TDE), which is full database-level encryption that protects not only columns and rows but the data and log files, too. However, not everyone will move to SQL Server 2008 right away.

Additionally, some organizations prefer to use non-Microsoft solutions, or they require that encryption takes place outside of SQL Server. Also, because the best practice for implementing security solutions involves a layered approach, an encryption solution from a third party on top of SQL Server can provide the in-depth defense your database needs.

Choosing a Level of Encryption

After you decide to encrypt your database, you have a choice as to how much of it to encrypt. Database encryption products generally operate at one of two levels:

Additionally, some vendors offer encryption at the table level and the application level. Vendors wallpaper the Internet with white papers arguing for and against their various approaches. Your research will determine which type works best for your organization.

Deal Breakers and Deal Makers

To make the best choice of an encryption solution, you’ll need to consider who you want to protect data from and for whom you are protecting it. Let’s look at some of the factors that can make or break a given solution.

Compliance requirements. Compliance needs in your industry might drive your selection of an encryption solution. For example, PCI standards require encryption of data, but other aspects of its requirements, such as level of encryption, are open for interpretation. Some regulatory groups might require centralized storage of keys rather than distributed key storage.

Hardware versus software. Hardware solution providers tout scalability, but some software products also offer good scalability.

Split-key ability. Split-key solutions let two DBAs access parts of a key but not the whole key, preventing either one from having full access to the encryption of the database. If you already have access control, or monitoring and auditing of DBA activities, you might not require a split-key feature.

Key storage. Another consideration with keys is where they’re managed and stored. Hardware-based solutions store encryption keys on an appliance, offering a centralized location. Software-based encryption products store encryption keys on the servers where the encrypted data is located—a distributed approach to key storage—although some software vendors offer an optional appliance for key storage. Centralized storage offers an easy target for attack, but distributed storage is only as good as the most recent security patch on your server.

Ciphers used. Certain algorithms or ciphers are stronger or faster to process than others, so performance trade-offs might be involved. For example, the DES algorithm is considered less secure than other ciphers, but it’s faster than the Triple DES (3DES) algorithm; the RC5 cipher is considered a high-performing algorithm that’s also secure. Key size and how the product uses the algorithm also affect performance and security.

Performance. The current accepted wisdom is that column-level encryption causes a greater performance hit than whole-database encryption because column-level encryption works within SQL Server rather than between SQL Server and the file system. Know exactly what to expect and how your organization is prepared to deal with any trade-offs between performance and security.

Customer Service, Cost, and Complexity

Finally, as with any solution, you’ll want to consider customer service and cost. Does the solution provider offer multiple ways for you to contact its support people? And do they respond to problems efficiently during your evaluation period? Along with the actual cost of the product, consider the time required to implement it. Will intensive training be necessary? Will administration be easy to integrate with other IT duties? Implementing any encryption solution for your databases is sure to add some complexity to management—but if you find a product that meshes well with your management style, you’re well on your way to more secure data.