Data Encryption in Practice: Disk, Database, and Transport

Data Encryption in Practice: Disk, Database, and Transport

Data encryption works at three layers: disk encryption for data at rest, database encryption at rest, and TLS for data in transit. Each layer has its own job: disk encryption protects against physical media theft, database encryption protects against leaked backups and unauthorized internal reads, and TLS protects against link eavesdropping. Most sites only implement the third layer (HTTPS) and often overlook the first two.

Disk encryption: LUKS and cryptsetup

LUKS is the mainstream disk encryption standard on Linux, backed by the kernel's dm-crypt. It can encrypt whole disks, partitions, RAID volumes, logical volumes, and even single file containers, transparently to the file system above.

cryptsetup luksFormat /dev/sdX
cryptsetup open /dev/sdX cryptroot

A few more commands worth knowing, covering backup and recovery:

# Back up the LUKS header (do this before writing any data)
cryptsetup luksHeaderBackup /dev/sdX --header-backup-file luks-header.bak
# Restore the header
cryptsetup luksHeaderRestore /dev/sdX --header-backup-file luks-header.bak
# Inspect encryption parameters and key slots
cryptsetup luksDump /dev/sdX

An automated /etc/crypttab for boot-time unlock looks like this — keyfiles should be chmod 400 and stored separately:

cryptroot /dev/sdX2 /etc/luks/root.key luks
cryptswap /dev/sdX3 /etc/luks/swap.key luks

Reference: the full ArchWiki dm-crypt page https://wiki.archlinux.org/title/Dm-crypt

Implementation notes:

• The swap partition must also be encrypted, otherwise memory contents get swapped out to plaintext disk.
• Automated unlock at boot can use /etc/crypttab with a keyfile; store the keyfile separately and restrict its permissions.
• Always back up the LUKS header (cryptsetup luksHeaderBackup); a damaged header makes the data permanently unreadable.
• In the cloud, encrypt the root partition and keep keys separate from data, combined with a Backup Strategy.

Database encryption: at rest and at field level

There are two common approaches at the database layer:

• Instance-level encryption at rest (TDE): MySQL/MariaDB and PostgreSQL encrypt data files automatically; it is transparent but the keys are usually managed by the database.
• Field-level encryption: the application encrypts sensitive fields (IDs, phone numbers, payment data) individually, with keys managed by the application or a Secrets Management system, offering stronger protection.

Field-level encryption forces trade-offs in queries, indexing, and sorting, so enable it only for genuinely sensitive fields, and combine it with SQL Injection Defense to prevent ciphertext from being bypassed.

The trade-offs between the two approaches:

TDE protects at the file level; field-level encryption protects at the field level, and they do not conflict. Using TDE for the great majority of fields while layering field-level encryption on top for truly sensitive ones — IDs, payment tokens — is the most cost-effective combination.

Transport encryption: TLS deployment

Transport encryption is the HTTPS we all know. For certificate issuance and automatic renewal see SSL Certbot Automation, and for full migration see the HTTPS Migration Guide. Beyond the web, internal links such as database replication and Redis should also use TLS or at least stay inside encrypted private networks or dedicated lines.

Key management and backup

The security of any encryption system ultimately rests on the keys:

• Store keys separately from ciphertext, never on the same machine or disk.
• Establish a key rotation plan; disk keys, database keys, and TLS private keys rotate on different cycles.
• Losing a key means the data is permanently unreadable, so key escrow and recovery drills are essential.

How the three layers work together

The three layers do not replace each other — they stack:

• Disk encryption keeps media confidential even if the drive is physically removed.
• Database encryption at rest keeps data files and backups confidential, so "having the backup" no longer equals "having the data".
• TLS keeps the transport confidential, blocking packet capture and man-in-the-middle tampering.

Here is what each layer defends against, who holds the keys, and the usual tools:

For compliance scenarios, all three layers are usually required at once, and the audit must show key lifecycle management is sound. System- and database-managed keys cover the disk and database layers; field-level keys and TLS private keys are best held by a Secrets Management system for easier rotation and audit.

A lesson from a real incident

A startup had HTTPS and database backups, but no disk encryption. During a data-center move, ops accidentally sent two old drives to e-waste — one of them was the primary database disk. The backups were intact, but the compliance audit treated "readable media leaving the building" as a reportable event requiring a data-exposure assessment, because there was no way to prove the plaintext database had never been touched. The audit and legal process dragged on for over two months.

Had they done full-disk LUKS encryption with the header properly backed up, that drive would have been nothing but ciphertext and the problem would have been far smaller. The lesson is blunt: disk encryption protects not only against theft, but against the inability to prove you were not stolen from.

Common mistakes

• Encrypting only the data disk and forgetting swap and temp directories.
• Leaving backups unencrypted, which is equivalent to copying out plaintext.
• Storing keys on the same machine and disk as the ciphertext, which defeats the point.
• Forgetting to back up the LUKS header — once it is damaged, the whole disk is unrecoverable.

16IDC Observation

For compliance-sensitive e-commerce, SaaS, and payment sites, three-layer encryption is a baseline, not a bonus. Smaller sites should at minimum achieve: full disk encryption + HTTPS + encrypted database backups, then round out the picture with the baseline approaches in the Security Hardening category.

Source: https://wiki.archlinux.org/title/Dm-crypt