Three Data-at-Rest Encryption Strategies

Updated: Sep 20

Database encryption refers to the use of encryption techniques to transform a plaintext database into a (partially) encrypted database; thus, making it unreadable to anyone except those who possess the encryption key(s). Database security encompasses three main properties:

  • Confidentiality - preventing unauthorised disclosure

  • Integrity - guaranteeing that data cannot be corrupted in an invisible way

  • Availability - ensuring timely and reliable access to data

To preserve data confidentiality, enforcing access control policies defined on the database management system (DBMS) is a prevailing method. An access control policy can take different forms depending on the underlying data model (e.g. relational, XML), and the way by which authorisations are administered, following either a Discretionary Access Control (DAC), Role-Based Access Control (RBAC) or Mandatory Access Control (MAC).

Whatever the access control model, the authorisations enforced by the database server can be bypassed in a number of ways. For example,

  • An intruder can infiltrate the information system and try to mine the database footprint on disk.

  • Another source of threat comes from the fact that many databases are outsourced to Database Service Providers (DSPs). Data owners therefore, have no choice but to trust the word of the DSP who will argue that their systems are fully secured and their employees are trustworthy.

  • A database administrator has enough privileges to tamper the access control definition and to spy on the DBMS behaviour.

With Defence-in-depth, the resort to cryptographic techniques to complement and reinforce the access control model has received much attention from the database community. The purpose of database encryption is to ensure database opacity by keeping the information hidden to any unauthorised persons. Even if the attackers get through the firewall and bypass access control policies, they still need the encryption keys to decrypt data.

Encryption can provide strong security for data at rest, but developing a database encryption strategy must take many factors into consideration. For example,

  • where should you perform the encryption?

  • how much data should be encrypted to provide adequate security?

  • what should the encryption algorithm and mode of encryption be?

  • who should have access to the encryption keys?

  • how should you minimise the impact of database encryption on performance?

In this section, I will answer the question: "where should you perform the encryption?"


Storage-level encryption

It refers to encrypting data in the storage subsystem; thus protecting data at rest.

  • It is well-suited for encrypting files or entire directories in an operating system context.

From a database perspective

  • Storage-level encryption has the advantage to be transparent, thus avoiding any changes to existing applications.

  • On the other hand, since the storage subsystem has no knowledge of database objects and structure, the encryption cannot be related with user privileges (e.g., using distinct encryption keys for distinct users), nor data sensitivity.

Selective encryption therefore, is limited to file granularity. Moreover, selectively encrypting files is risky since one should ensure that no replica of sensitive data remains unencrypted (e.g., in log files, temporary files, etc).

Database-level encryption

It allows securing data as it is inserted to, or retrieved from the database.

  • The encryption strategy can be part of the database design and can be related to data sensitivity and/or user privileges.

  • Selective encryption is possible and can be done at various granularities, such as tables, columns, rows.

Depending on the level of integration between the encryption algorithm and the DBMS, the encryption process may incur some changes to the applications. It may also cause DBMS performance degradation since it forbids the use of indexing on encrypted data.

For both strategies (storage-level and database-level), data is decrypted on the database server at runtime. This means the encryption keys must be transmitted or kept with the encrypted data on the server side; providing a limited protection against the server administrator or any intruder usurping the administrator identity (privilege escalation).

Application-level encryption

It moves the encryption/decryption process to the applications that generate the data.

  • Encryption is performed within that application that introduces the data into the system.

  • The data is sent encrypted, and thus, naturally stored and retrieved encrypted, to be finally decrypted within the application.

This approach has the benefit of separating encryption keys from the encrypted data stored in the database, since the keys never have to leave the application side.


  • Applications need to be modified to adopt this solution

  • Depending on the encryption granularity, the application may have to retrieve a larger set of data than the one granted to the actual user, this opening a security breach.

  • It introduces performance overhead; that is

  • indexing encrypted data is not possible; and

  • it forbids the use of some advanced database functionalities on the encrypted data, like stored procedures and triggers.

In terms of granularity and key management, application-level encryption offers the highest flexibility since the encryption granularity and the encryption keys can be chosen depending on application logic.

185 views0 comments

Recent Posts

See All

© 2022 by CloudTAC