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.