member sign-in
Forgot password? Create new account Close

Database Encryption

Definition

Database encryption is the technology used data protection from databases. Encryption can applied to the contents through native database functions or externally with third party tool.
Database encryption can be classified in two basic types:
Transparent/External Encryption - term for the encryption of the entire database. This is provided by native encryption functions within the  database engine. Some database vendors offer column and table level granularity, but it is increasingly common to apply encryption to all the data. It’s called ‘transparent’ database encryption because it is invisible to the applications and users that use the data, and requires no changes to application logic. The principal use case is to prevent exposure of information due to loss of the physical media (disk, tape, etc.) or compromise of the database files in storage. Transparent encryption can also be handled through drive or OS/file system encryption, applying encryption on everything that gets written to disk.. Transparent encryption protects the database from users without database credentials, but does not protect data from authorized users.
User/Data Encryption - term describes encrypting specific columns, tables, or even data elements within the database. It is called ‘user’ encryption because the objects being encrypted are owned and managed on a per-user basis. Tokenization also falls into this category. The classic use case for this encryption model is encrypting credit card numbers within a database. The goal is to provide protection against inadvertent disclosure, or to enforce separation of duties on credentialed users of the database. The downside is that these variants are not invisible to the application and usually require code and database changes. The concept is to encrypt only the highly sensitive data the companies are worried about, reducing the overall performance impact, and minimizing code and database changes. How this is accomplished depends on how key management is handled, the use of internal vs. external encryption services, and how applications use the database.

User Benefits

  • Granular protection—Retain ownership of data throughout its life cycle with granular file- or column-level encryption.
  • Centralized administration—Simplify security administration and control costs with centralized management of keys, policies, and configurations.
  • Controlled access—Ensure regulatory compliance and reduce risks by setting policies for separation of administrative duties.
  • Productivity empowered—Encrypt information transparently, without disrupting business operations, database performance, or the end-user experience

Business Impact

Database Encryption technology delivers powerful protection for the sensitive corporate and customer information stored in databases. With Database Encryption technology, organizations have the flexibility to encrypt data at multiple levels and during multiple processes. Database Encryption technology helps to facilitate secure collaboration with comprehensive protection of the structured data. With Database Encryption technology, organizations gain the flexibility to encrypt data at the file, or column, level in databases, within the application layer, and during batch-driven data transformation and transaction processes.  
Most regulatory mandates require the separation of security administration from database administration to avoid the risks of "super-user" access. Database Encryption technology allows for "M of N" policies, which prevent any single administrator from making critical configuration changes without additional approvals of other administrators.

 


Products supporting this technology

Gemalto

Over the last two decades, database security has meant access controls and encryption. Access controls to gate who should or should not be allowed to access the database, and encryption to protect data at rest. The use of access control systems for databases is well documented, and the available solutions are very effective at providing basic security around who can access what data. Somewhat surprisingly, database encryption is still not in wide use. Data security professionals often view database encryption as a redundant control, only effective in the event other security measures and polices fail. Application developers have avoided database encryption because the burden of implementation would land on them, adding complexity to the design and implementation of both application and database schemas. IT managers as a rule dislike the additional complexity around backup, recovery, user provisioning, and key management. And everyone is worry of the specter of performance degradation. While there is validity to each of these perspectives, they are relevant only in particular circumstances. Regardless, these perceptions relegate database encryption to a secondary measure, to be considered as part of a ‘defense in depth’ strategy.

Two fundamental changes have occurred which alter perceptions of database encryption. First, several public data breaches could have been prevented or neutralized. In response, government and private regulations, such as the PCI Data Security Standard, have either endorsed or mandated encryption as a security measure to reduce data theft. Second, database and IT product vendors have dramatically improved the performance and manageability of their encryption offerings. Reduced implementation and, management burdens, coupled with (in many cases) reduced cost of encryption have reduced internal resistance.

The term database encryption is used to describe many different methods of data protection, implemented either outside or within the database engine. Conceptually, a database is a sophisticated box to put data in. Taking this analogy one step further, you can protect the entire box (File/OS), the entire contents of the box (Full database), or some subset of the content within the box (Column, Table, Schema). We encryption can applied to the contents through native database functions or externally with third party tools, but both are called database encryption. We also see growing use of tokenization as an alternative or complement to encryption, since it achieves many of the same goals, which is why we include it in this paper.

For this discussion, we divide database encryption into two basic types:
Transparent/External Encryption: These terms refer to encryption of the entire database. This is provided by native encryption functions within the database engine. Some database vendors offer column and table level granularity, but it is increasingly common to apply encryption to all the data. This can be called ‘transparent’ database encryption because it is invisible to the applications and users that use the data, and requires no changes to application logic. The principal use case is to prevent exposure of information due to loss of the physical media (disk, tape, etc.) or compromise of the database files in storage. Transparent encryption can also be handled through drive or OS/file system encryption, applying encryption on everything that gets written to disk. Although these options may lack some of the protections of native database encryption, both are invisible to the application and do not require alterations to the code or schemas. Transparent encryption protects the database from users without database credentials, but does not protect data from authorized users.

User/Data Encryption: These terms describe encrypting specific columns, tables, or even data elements within the database. This can be called ‘user’ encryption because the objects being encrypted are owned and managed on a per-user basis. Tokenization also falls into this category. The classic use case for this encryption model is encrypting credit card numbers within a database. The goal is to provide protection against inadvertent disclosure, or to enforce separation of duties on credentialed users of the database. The downside is that these variants are not invisible to the application and usually require code and database changes. The concept is to encrypt only the highly sensitive data we are worried about, reducing the overall performance impact, and minimizing code and database changes. How this is accomplished depends on how key management is handled, the use of internal vs. external encryption services, and how applications use the database.

It should be stressed that both user and transparent encryption protect media, but the granularity provided by user encryption comes at the cost of required modifications to code and/or database schemas. Some vendors offer transparent encryption applied to specific tables or columns, but the value proposition is still focused on lost media and file protection, not separation of duties.

Tokenization or Format Preserving Encryption are designed to reduce required external application changes, but still require internal database modifications.

In summary, transparent/external encryption protects data from compromise by attacks from outside the database, but does not protect against credentialed database users. User/data encryption can encrypt data and restrict access based on database users, but at a higher cost in terms of complexity, performance, and manageability.

The first thing to decide when looking at database encryption is what are we trying to protect and why. If we’re just going after the ‘PCI checkbox’ or worried about losing data from swapping out hard drives, someone stealing the files off the server, or misplaced backup tapes, then transparent encryption is the answer. Blanket encryption of all database content for media protection is much easier than encrypting specific columns and tables for separation of duties. If the goal is to protect data in the event of compromised accounts, rogue DBAs, or inadvertent disclosure things get a lot more complicated. The choice depends upon three things:

• What do you want to protect?
• What do you want to protect it from?
• What application changes and management tasks can you tolerate?

Whether the driver is security or compliance, the breakdown will be the same. Whether the company need to provide separation of duties for Sarbanes-Oxley, or protect against account hijacking, or keep credit card data from being viewed for PCI compliance, that means the company is worried about credentialed users. In this case you need a more granular approach to encryption and possibly external key management. This is called User Encryption. If the problem is related to missing tapes, physical server theft, copying/theft of the database files via storage compromise, or un-scrubbed hard drives being sold on eBay, the threat is outside the bounds of access control. For these cases transparent/external encryption through native database methods, OS support, file/folder encryption, or possibly drive encryption is appropriate.

Once the method is decided it is necessary to examine the basic technology variables that affect the database system and operations. With any form of database encryption there are many technology variables to consider for the deployment, but for determining the right strategy, there are only three to worry about. These three affect performance and which types of threats you can address. In each case we need to determine whether these operations will be performed internally by the database, or externally. They are:
1.  Where does the encryption engine reside?
2.  Where is key management performed?
3.  What performs the encryption operations?

Each option moved outside the database means more complexity and less application transparency, but (generally) stronger security through increased separation of duties. For example, with basic transparent encryption the encryption engine (the code that performs the encryption), key management, and encryption operations management are all within the database. The database administrator has full control of encryption operations and in many cases access to the keys as well. A more secure option might be to remove key management to an external application, so the DBA is never responsible for the keys, which improves separation of duties.
 

  • manufacturer