Database Encryption: At-Rest, In-Transit, and Field-Level Techniques

Database encryption is the application of cryptographic algorithms to protect data stored in, moving through, or selectively held within database systems. This page describes the three primary technical approaches — at-rest, in-transit, and field-level encryption — their underlying mechanisms, the regulatory frameworks that compel their use, and the structural decision criteria that govern which technique applies in a given deployment context. The topic spans both relational and non-relational platforms and is governed by standards published by the National Institute of Standards and Technology (NIST) and sector-specific compliance regimes including HIPAA and PCI DSS.

Definition and scope

Database encryption is the systematic transformation of readable data (plaintext) into an unreadable form (ciphertext) using a cryptographic key, such that only authorized parties holding the correct key can reconstruct the original data. Within database systems, the practice subdivides into three structurally distinct protection layers, each addressing a different phase of the data lifecycle: storage, network transport, and individual data element protection.

The regulatory pressure behind encryption adoption is not abstract. The Health Insurance Portability and Accountability Act (HIPAA) Security Rule (45 CFR § 164.312(a)(2)(iv)) lists encryption of electronic protected health information (ePHI) as an addressable implementation specification. Payment Card Industry Data Security Standard (PCI DSS) v4.0, published by the PCI Security Standards Council, requires strong cryptography for cardholder data both at rest (Requirement 3.5) and in transit (Requirement 4.2). NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices, establishes baseline guidance for storage-layer protection applicable across enterprise database contexts.

This scope intersects directly with database security and access control and database auditing and compliance, where encryption operates alongside authentication, authorization, and audit logging as a layered defense.

How it works

Encryption at rest

Encryption at rest protects data physically written to disk — data files, tablespaces, backups, and write-ahead logs. The operating mechanism relies on a symmetric cipher applied at either the storage layer, the file system layer, or the database engine layer.

Transparent Data Encryption (TDE) is the dominant at-rest implementation in major relational platforms. The database engine encrypts data pages before writing them to disk and decrypts them upon read, entirely transparently to the application layer. Microsoft SQL Server, Oracle Database, and PostgreSQL (via pgcrypto extensions or filesystem-layer tools) all support TDE-pattern implementations.

The key hierarchy in TDE typically involves three tiers:

Data Encryption Key (DEK) — the symmetric key (commonly AES-256) that directly encrypts the data.
Key Encryption Key (KEK) — a master key that encrypts the DEK, preventing direct key exposure in storage.
Key Management System (KMS) — an external or internal vault (such as AWS KMS, Azure Key Vault, or a hardware security module) that holds and controls access to the KEK.

NIST SP 800-57, Recommendation for Key Management, Part 1, Revision 5, defines the key lifecycle management requirements that govern DEK rotation, revocation, and archival in compliant environments.

Encryption in transit

Encryption in transit protects data moving across a network connection between a client application and the database server, or between database nodes in a database replication topology. The standard protocol is TLS (Transport Layer Security), with TLS 1.2 and TLS 1.3 constituting the currently acceptable versions per NIST SP 800-52, Rev. 2.

The handshake process authenticates the server certificate, negotiates a cipher suite, and establishes a session key for symmetric encryption of the data stream. All major database drivers — JDBC for Java, psycopg2 for Python, and the .NET SqlClient — expose TLS configuration parameters. PCI DSS v4.0 Requirement 4.2.1 explicitly prohibits the use of SSL and early TLS versions for cardholder data transmission.

Field-level encryption

Field-level encryption (FLE) — also called column-level encryption in relational contexts — encrypts individual data elements before they reach the database engine. Encryption and decryption occur at the application layer or within a client-side driver, meaning the database server stores and queries only ciphertext for designated fields.

This approach differs fundamentally from TDE: a database administrator with full server access in a TDE-protected system can still read decrypted data. Under FLE, the server never holds plaintext for protected fields. MongoDB's Client-Side Field Level Encryption (CSFLE) and the deterministic encryption mode in SQL Server's Always Encrypted feature implement this pattern. The trade-off is query limitation — deterministic encryption supports equality queries, while randomized encryption does not support any server-side queries on the encrypted field.

Common scenarios

Database encryption applies across the following deployment contexts:

Healthcare electronic health records (EHR) systems — HIPAA ePHI fields such as Social Security Numbers, diagnosis codes, and prescription data use FLE to ensure database-tier staff cannot access identifiable patient data.
Payment processing platforms — PCI DSS-scoped databases holding primary account numbers (PANs) require at-rest encryption and TLS-enforced in-transit encryption on every connection traversing an untrusted network segment.
Cloud-hosted databases — Databases on managed platforms (AWS RDS, Google Cloud SQL, Azure SQL) expose native TDE by default in storage but require explicit TLS enforcement at the connection string level to protect in-transit channels. The cloud database services landscape has standardized TDE as a default-on feature as of each major provider's current documentation.
Data warehouse and analytical environments — Columnar stores used in data warehousing frequently encrypt full tablespaces at rest, since these platforms do not typically support granular FLE without performance penalties.
Backup and recovery chains — Encryption must extend to backup files and transaction logs. An unencrypted backup of an otherwise TDE-protected database represents a complete circumvention of at-rest protection, a gap addressed in database backup and recovery practice.

Decision boundaries

Selecting among the three approaches involves four structural criteria:

Threat model scope — TDE addresses physical media theft and storage-layer exposure. TLS addresses network interception. FLE addresses insider threats and compromised database credentials. A deployment facing all three threat vectors requires all three layers.

Query functionality requirements — FLE with randomized encryption cannot support range queries, sorting, or aggregation on encrypted fields. Deterministic FLE supports only equality predicates. Applications requiring full query flexibility on sensitive fields must rely on TDE plus access control rather than FLE.

Key custody and separation of duties — Where regulatory frameworks or organizational policy require that database administrators have no access to plaintext data, FLE or application-layer encryption is the only mechanism that enforces that separation. TDE alone does not achieve this.

Performance overhead — AES-256 hardware acceleration (AES-NI) is available in all modern x86-64 processors, making TDE overhead negligible for most transactional workloads. FLE introduces client-side computation and limits server-side indexing. Environments managing database performance tuning at scale should benchmark FLE overhead against query patterns before wide deployment.

The database management systems (DBMS) layer determines which native encryption features are available without third-party tooling. For organizations evaluating full-stack capabilities, the broader database systems landscape provides classification context across platform types and deployment models.

References

📜 1 regulatory citation referenced · 🔍 Monitored by ANA Regulatory Watch · View update log