There are several different ways to encrypt data stored within databases -- some residing inside the database, others outside. You can encrypt data programmatically at the application layer or at the database layer, and automatically by the OS/file system or by the database engine itself. Each has a slightly different use case, with differing degrees of data security, complexity, and impact on performance.

Early database encryption options were slow, complex, and bumbled key management. Application layer encryption was no less difficult to implement, but offered greater security and more flexible deployment options. Over time, the problems with database encryption have been mitigated, and the major issues surrounding key management, performance, and ease of deployment are history.

But the biggest change is the ability to deploy encryption transparently -- retrofitting systems without a major rewrite.

Market drivers have changed with the introduction of compliance requirements around data security and privacy. For many compliance initiatives, sensitive data must be encrypted, and the adoption of database encryption has surged in response.

Transparent encryption is the favored choice. Not because it offers greater security, but because these variants are the quickest to implement and the most cost-effective way to retrofit data processing systems to meet compliance mandates.

Transparent database encryption is provided by the database vendors and embedded within most relational database platforms. Cryptographic operations happen behind the scenes and are performed within the database kernel, usually encrypting data blocks before they are written to disk. The term "transparent" is used because it is invisible to the applications that use the database and most importantly, requires no alteration to application or database logic to use. It's almost entirely seamless, and can be activated through minor changes to the database's configuration.

Encryption is applied to all contents of the database, with encryption and decryption operations performed automatically on the user's behalf.

Each database vendor will have slight variations to this model, but they work in essentially the same manner. Some will use encryption keys stored within the database, while others will leverage external key management services. Some will offer table-level granularity, while others encrypt everything. These services are built into the database itself, but require additional licensing fees to use.

In the next post, I'll talk about OS/file-level database encryption, and provide analysis of this and transparent encryption.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.