How to protect Oracle and Microsoft SQL Databases using Fortanix Self-Defending KMS with Transparent Data Encryption

Published:Feb 28, 2018
Reading Time:4 Minutes

The demand for database encryption keeps increasing, driven by cybersecurity risks and regulatory compliance. Databases contain some of the most sensitive data assets of an organization, making them attractive targets of attackers and malicious insiders. While encryption remains an effective data protection control, it is increasingly difficult to use to protect databases given rapid data growth, clustering of databases and distribution of databases across geographies, across clouds.

Transparent Data Encryption (TDE)

Commercial databases such as Oracle and Microsoft SQL Server allow you to encrypt data transparently. With TDE, the files written on physical storage media are encrypted by the database, rendering the data inaccessible if someone steals the storage media.

The master key used to encrypt the data encryption keys is managed and secured independently from the database in an external key store. This master key may be stored in a software key store, but a majority of security conscious organizations prefer to use a hardware security module (HSM) to store the master key.

TDE provides several benefits to an organization. The application using the database does not need to be aware of the TDE configuration on the database, so there is no impact of using TDE on application users or developers. This also allows for migration from an unencrypted database to an encrypted database, or a software key store to a HSM based key store to store the master key, without any impact on application or any downtime. TDE provides the quickest way for most organizations to meet regulatory requirements with encryption of personally identifiable data at rest.

With TDE, the files written on physical storage media are encrypted by the database

Database Encryption or Tokenization / Format preserving encryption

Transparent Data Encryption is often compared with Data-Centric security methods used with Databases, such as Format Preserving Encryption (FPE) or Tokenization. These methods allow data to be transformed while preserving its privacy and format, with minimal impact on the data processing requirements of legacy applications. See How to secure legacy applications using format-preserving encryption and tokenization for more details on these methods. While tokenization and FPE can provide greater flexibility for data security and can also provide increased privacy to data during query processing, they put additional burden on the application to implement or integrate with a tokenization or FPE provider. TDE, by contrast, can be enabled on existing databases, and can provide data-at-rest security with no change to the application.

TDE and the role of HSMs

The biggest security challenge when using TDE has to do with securing the master key (called master encryption key, or MEK in Oracle, and data encryption key, or DEK in SQL Server). If an attacker gets access to this key, all the intermediate keys used to encrypt column and tablespace data can be decrypted, and eventually, all data can be decrypted. The ideal solution for securing the master key is to store it in an HSM and perform the wrapping and unwrapping of intermediate keys inside the HSM.

Even though HSM provide the most secure way to store the master key, most organizations don’t use them. Traditional HSM work fine in lab environments, but often fall short when they are used in real world deployments of these databases. Databases are typically large and may contain several intermediate keys which are encrypted using the master key. A typical large database in an organization has a high “transactions per second” requirement. Large installations of Oracle and SQL Server databases may also be spread geographically. Traditional HSMs are unable to handle many of these requirements in an effective manner. Traditional HSM don’t cluster very well, and even if they do, they rely on a client for load balancing which becomes a bottleneck as well as a security vulnerability.

How to use Fortanix Self-Defending KMS for TDE

Fortanix Self-Defending KMS is a next-generation HSM solution equipped to handle the high transaction rates that large commercial databases demand, and the ability to replicate keys across geographically distributed sites with minimal latency and high consistency. Fortanix Self-Defending KMS is designed to be infinitely scalable, highly available, and resilient to disasters and faults. Fortanix Self-Defending KMS is being used in production at scale and in geographically distributed deployment models.

How to use Fortanix Self-Defending KMS for TDE

The following knowledge base articles explain how to use Fortanix Self-Defending KMS with Oracle and SQL Server TDE.

Share this post: