Encryption at Rest - Learning Module

Loading content...

0/273

File System Encryption

Beyond the Database: Protecting All Persistent Data

Not all data lives in databases. Production systems generate vast amounts of unstructured data: log files containing sensitive information, configuration files with credentials, uploaded documents, media files, machine learning models, exported reports, and temporary files that applications create during processing. If you only encrypt your database while leaving these files in plaintext, you have a significant security gap.

Consider what's typically stored outside databases in a modern application:

Application logs (which may contain user data, IP addresses, error messages with sensitive context)
Configuration files (database passwords, API keys, service credentials)
User uploads (documents, images, files users trust you to protect)
Cache files (potentially containing decrypted sensitive data)
Temporary processing files (intermediate data during batch jobs)
Backup scripts and automation containing secrets
SSL/TLS certificates and private keys

File system encryption ensures that all data at rest is protected, not just data you explicitly marked as sensitive.

What You Will Learn

By the end of this page, you will understand the full spectrum of file system encryption options—full-disk encryption, volume encryption, file-level encryption, and cloud storage encryption. You'll learn how each approach works internally, when to use each, and how to implement encryption for different operating systems and cloud environments.

Understanding File System Encryption Layers

File system encryption can be implemented at several layers of the storage stack. Each layer has different characteristics for performance, security, and operational complexity.

The encryption stack from top to bottom:

File System Encryption Layers
Layer	What It Encrypts	Examples	Use Case
Application Layer	Specific files/content	GPG, OpenSSL, application code	Individual sensitive files
File System Layer	Files/directories transparently	eCryptfs, fscrypt, EFS	Home directories, specific folders
Block/Volume Layer	Entire disk partitions	LUKS, BitLocker, dm-crypt	Full system protection
Hardware Layer	All disk I/O	Self-Encrypting Drives (SED)	Maximum performance encryption

Understanding the tradeoffs:

Higher layers (application, file system) offer:

Granular control over what's encrypted
Encryption persists when files are copied/moved
Different files can use different keys
But: More complex to implement and operate

Lower layers (block, hardware) offer:

Complete coverage—everything is encrypted
No application changes required
Simpler key management (one key per volume)
Better performance (especially hardware)
But: Encryption doesn't persist if files are copied to unencrypted storage

The modern best practice: Use volume/block-level encryption as a baseline to catch everything, then add file or application-level encryption for the most sensitive data that needs protection beyond the storage boundary.

The 'Everything Running' Problem

Unlike database TDE where the database process handles decryption, full-disk encryption typically unlocks at boot time. Once the system is running and unlocked, all processes can read files (subject to permissions). Block-level encryption primarily protects against offline attacks—stolen devices, decommissioned disks, physical access to powered-off systems. It does NOT protect against malware on a running system.

Full Disk Encryption (FDE)

Full Disk Encryption (FDE) encrypts the entire contents of a storage device—operating system, applications, data, swap space, and temporary files. When the system boots, a passphrase or key (often from TPM or network key server) unlocks the disk, and all subsequent I/O is encrypted/decrypted transparently.

How FDE works:

During initial setup, the disk is encrypted with a randomly generated Data Encryption Key (DEK)
The DEK is encrypted by a Key Encryption Key (KEK), derived from the user's passphrase or stored in TPM/HSM
At boot, the system requests the passphrase or retrieves the KEK from secure storage
The KEK decrypts the DEK, which is held in memory
All disk I/O passes through an encryption layer that uses the DEK
When the system shuts down, the DEK is wiped from memory—disk contents are again encrypted and inaccessible

Full Disk Encryption Setup
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
# LUKS (Linux Unified Key Setup) is the standard for Linux disk encryption
 
# Step 1: Identify the device to encrypt
lsblk
# Example: We'll encrypt /dev/sdb1
 
# Step 2: Create LUKS encrypted container
# WARNING: This will destroy all data on the device!
sudo cryptsetup luksFormat --type luks2 /dev/sdb1
 
# You'll be prompted for a passphrase
# Use a strong, memorable passphrase or store in secrets management
 
# Step 3: Open the encrypted container
sudo cryptsetup luksOpen /dev/sdb1 encrypted_data
# This creates /dev/mapper/encrypted_data
 
# Step 4: Create a filesystem on the encrypted device
sudo mkfs.ext4 /dev/mapper/encrypted_data
 
# Step 5: Mount and use
sudo mount /dev/mapper/encrypted_data /mnt/secure_data
 
# Step 6: Add to /etc/crypttab for automatic unlock at boot
# Add line: encrypted_data /dev/sdb1 none luks
 
# Step 7: Add to /etc/fstab for automatic mounting
# Add line: /dev/mapper/encrypted_data /mnt/secure_data ext4 defaults 0 2
 
# === Key Management ===
 
# Add additional key (up to 8 key slots in LUKS2)
sudo cryptsetup luksAddKey /dev/sdb1
 
# Use a key file instead of passphrase
sudo dd if=/dev/urandom of=/root/luks_keyfile bs=4096 count=1
sudo chmod 400 /root/luks_keyfile
sudo cryptsetup luksAddKey /dev/sdb1 /root/luks_keyfile
 
# Backup LUKS header (critical for recovery!)
sudo cryptsetup luksHeaderBackup /dev/sdb1 \
    --header-backup-file /secure-backup/sdb1-luks-header.img
 
# Check encryption status
sudo cryptsetup status encrypted_data
 
# View LUKS header info
sudo cryptsetup luksDump /dev/sdb1

Recovery Key Management is Critical

If you lose both the encryption passphrase AND the recovery key, your data is permanently inaccessible. For enterprise deployments, always escrow recovery keys to a centralized secrets manager, Active Directory, or MDM solution. Test key recovery procedures regularly. Many organizations have lost access to critical data due to lost encryption keys.

Volume and Partition Encryption

Volume encryption encrypts specific partitions or logical volumes rather than entire disks. This is common in server environments where the operating system might not need encryption, but data volumes containing sensitive information require protection.

Use cases for volume encryption vs. full disk:

Full Disk Encryption

•Laptops and mobile devices
•Workstations with sensitive data access
•Systems where OS protection is important
•Compliance requiring 'all data' encryption
•When simplicity of management is priority

Volume Encryption

•Servers with separate data volumes
•Shared storage arrays (SAN/NAS)
•Container storage volumes
•Cloud block storage (EBS, Persistent Disks)
•When different data needs different keys

Cloud block storage encryption:

Cloud providers offer native encryption for their block storage services. This is essentially volume-level encryption managed by the provider:

AWS EBS Encryption:

Encryption at rest using AWS-managed or customer-managed KMS keys
Covers data on the volume, disk I/O, and snapshots
Encryption enabled at volume creation (can't change existing volumes)
Must copy unencrypted snapshots to encrypted snapshots to migrate

Google Cloud Persistent Disk:

All Persistent Disks are encrypted by default (AES-256)
Customer-supplied encryption keys (CSEK) for customer control
Cloud Key Management Service (Cloud KMS) for managed keys

Azure Managed Disks:

Server-Side Encryption (SSE) with platform-managed or customer-managed keys
Azure Disk Encryption uses BitLocker (Windows) or DM-Crypt (Linux)
Customer-managed keys in Azure Key Vault

Cloud Volume Encryption

# Create a customer-managed KMS key for EBS encryption
resource "aws_kms_key" "ebs_encryption" {
  description             = "KMS key for EBS volume encryption"
  deletion_window_in_days = 30
  enable_key_rotation     = true
  
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "Enable IAM User Permissions"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"
        }
        Action   = "kms:*"
        Resource = "*"
      },
      {
        Sid    = "Allow EBS to use the key"
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
        Action = [
          "kms:Encrypt",
          "kms:Decrypt",
          "kms:ReEncrypt*",
          "kms:GenerateDataKey*",
          "kms:DescribeKey"
        ]
        Resource = "*"
      }
    ]
  })
}
 
resource "aws_kms_alias" "ebs_encryption" {
  name          = "alias/ebs-encryption-key"
  target_key_id = aws_kms_key.ebs_encryption.key_id
}
 
# Create encrypted EBS volume
resource "aws_ebs_volume" "encrypted_data" {
  availability_zone = "us-east-1a"
  size              = 100
  type              = "gp3"
  iops              = 3000
  throughput        = 125
  
  encrypted   = true
  kms_key_id  = aws_kms_key.ebs_encryption.arn
  
  tags = {
    Name        = "encrypted-data-volume"
    Environment = "production"
    Sensitive   = "true"
  }
}
 
# Set account-level default encryption for all new EBS volumes
resource "aws_ebs_encryption_by_default" "enabled" {
  enabled = true
}
 
resource "aws_ebs_default_kms_key" "default" {
  key_arn = aws_kms_key.ebs_encryption.arn
}

Default Encryption Policies

All major cloud providers support account-level or organization-level policies to require encryption for all new storage. Enable these policies early—it's much easier to enforce encryption by default than to retrofit it later. AWS has 'EBS encryption by default', GCP has organization policies for encryption requirements, and Azure has policies that can require encryption on all managed disks.

File-Level Encryption

File-level encryption encrypts individual files or directories, allowing fine-grained control over what's protected. Unlike volume encryption, file-level encryption can travel with the file—if you copy an encrypted file to an unencrypted USB drive, the file remains encrypted.

When file-level encryption is appropriate:

Different files need different access permissions (e.g., per-user or per-project encryption)
Files will be transferred to other systems and protection must persist
Compliance requires encryption of specific data categories while other data can remain unencrypted
Backup/archive systems don't support volume encryption but you need encrypted backups
Multi-tenant systems where each tenant's data needs separate encryption keys

File-Level Encryption Examples
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# fscrypt is the native Linux file-level encryption system
# Supported on ext4, f2fs, and UBIFS filesystems
 
# Step 1: Enable encryption feature on filesystem
sudo tune2fs -O encrypt /dev/sda1
 
# Step 2: Install fscrypt tools
sudo apt install fscrypt libpam-fscrypt
 
# Step 3: Set up fscrypt on the filesystem
sudo fscrypt setup
sudo fscrypt setup /mnt/data
 
# Step 4: Create an encrypted directory
mkdir /mnt/data/sensitive
fscrypt encrypt /mnt/data/sensitive
 
# Choose protector type:
# 1 - Your login passphrase (pam_passphrase)
# 2 - A custom passphrase (custom_passphrase)
# 3 - A raw key in the keyring (raw_key)
 
# Step 5: Access the encrypted directory
# Files are only accessible when the directory is unlocked
ls /mnt/data/sensitive  # Works - directory is unlocked
 
# Step 6: Lock the directory when done
fscrypt lock /mnt/data/sensitive
 
# Now files appear as encrypted gibberish
ls /mnt/data/sensitive  # Shows encrypted filenames
 
# Step 7: Unlock directory again
fscrypt unlock /mnt/data/sensitive
 
# === For automated/service accounts ===
 
# Create a raw key protector (for services)
head -c 32 /dev/urandom > /root/fscrypt.key
fscrypt encrypt /mnt/data/app_secrets --source=raw_key --key=/root/fscrypt.key
 
# Store the key in secrets management (HashiCorp Vault, etc.)
 
# Unlock using the key file
fscrypt unlock /mnt/data/app_secrets --key=/root/fscrypt.key

File-level encryption in cloud storage:

Cloud object storage services also offer file-level encryption options:

AWS S3:

SSE-S3: S3-managed keys (default, simplest)
SSE-KMS: KMS-managed keys (audit trail, key control)
SSE-C: Customer-provided keys (you manage keys, S3 uses them)
Client-side: Encrypt before upload (strongest, most complex)

Google Cloud Storage:

Cloud Storage default: Google-managed keys
CMEK: Customer-managed keys in Cloud KMS
CSEK: Customer-supplied keys (provide with each request)
Client-side: Encrypt before upload

Azure Blob Storage:

Microsoft-managed: Default encryption
Customer-managed: Keys in Azure Key Vault
Customer-provided: Keys supplied with each request
Client-side: Encrypt in application before upload

Client-Side vs. Server-Side

With server-side encryption, the cloud provider performs encryption but technically has access to your data during processing. With client-side encryption, data leaves your systems already encrypted—the cloud provider never sees plaintext. Choose client-side for the highest security (e.g., regulated data), server-side for simplicity when you trust the provider.

Hardware Encryption: Self-Encrypting Drives

Self-Encrypting Drives (SEDs) perform encryption in the drive controller hardware. Every write is encrypted, every read is decrypted, entirely in hardware—with no CPU overhead and no operating system involvement.

How SEDs work:

The drive generates a random Data Encryption Key (DEK) at manufacturing
All data written to the drive is encrypted with the DEK
An Authentication Key (AK) protects the DEK
By default, authentication is unlocked—the drive is 'always on'
When activated, the drive requires authentication at power-on to unlock
The DEK never leaves the drive in plaintext—only the AK is external
Cryptographic erase: Change the DEK → all data instantly inaccessible

SED Standards
Standard	Description	Use Case
TCG Opal	Trusted Computing Group specification for SEDs	Enterprise and consumer drives
TCG Enterprise	Extended Opal for data centers (e.g., multi-user)	Enterprise storage systems
ATA Security	Legacy password protection (avoid—weak)	Older systems only
IEEE 1667	Interoperability standard for secure storage	USB and portable devices

SED Advantages

•Zero CPU overhead—encryption is free
•No performance penalty at any workload
•Cannot be bypassed by boot media
•Instant cryptographic erase (milliseconds)
•Transparent to all software layers
•FIPS 140-2/3 certified options available

SED Limitations

•Requires hardware purchase/refresh
•No protection while system is running and unlocked
•Management software varies by vendor
•Key recovery can be complex
•Some vulnerabilities discovered in implementations
•Cannot use different keys for different data

Managing SEDs:

SEDs require management software to enable authentication and manage keys:

sedutil — Open-source TCG Opal management tool (Linux, Windows, macOS)
Samsung Magician — For Samsung SSDs
Intel SSD Toolbox — For Intel SSDs
Enterprise management — Dell, HPE, Lenovo offer fleet management tools

Instant Secure Erase:

One of the most valuable SED features is instant secure erase. By rotating the DEK, all data becomes unreadable instantly—without the hours required to overwrite every sector. This is invaluable for:

Decommissioning drives for disposal or resale
Reassigning drives between security domains
Responding to security incidents by rendering data unrecoverable

SED Security Caveats

In 2018, researchers discovered vulnerabilities in several SED implementations that allowed data recovery without the password. While many drives have been patched, this highlights that 'hardware encryption' doesn't automatically mean 'perfect security.' For the highest assurance, combine SEDs with software encryption (defense in depth), or use drives with FIPS 140-2+ certification that have undergone rigorous validation.

Encrypting Swap, Temporary Files, and Logs

Even with encrypted storage for your primary data, sensitive information can leak through system areas often overlooked: swap space, temporary files, and logs. A comprehensive encryption strategy must address these.

Swap space risks:

Swap (virtual memory) contains process memory pages written to disk when RAM is exhausted. This can include:

Decrypted application data currently in use
Cryptographic keys held in application memory
User session data, authentication tokens
Anything that was in RAM when swapped out

If swap isn't encrypted, an attacker with disk access can recover sensitive memory contents.

Encrypting System Areas
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# Method 1: Encrypted swap with random key (recommended)
# Key regenerates each boot - swap contents lost on shutdown (good!)
 
# Edit /etc/crypttab:
# cryptswap /dev/sdX /dev/urandom swap,cipher=aes-xts-plain64,size=256
 
# Edit /etc/fstab:
# /dev/mapper/cryptswap none swap sw 0 0
 
# Method 2: Encrypt existing swap partition with LUKS
 
# Disable existing swap
sudo swapoff -a
 
# Create encrypted container
sudo cryptsetup luksFormat /dev/sdX
 
# Open the container
sudo cryptsetup luksOpen /dev/sdX cryptswap
 
# Create swap filesystem
sudo mkswap /dev/mapper/cryptswap
 
# Add to /etc/crypttab for automatic unlock at boot
echo "cryptswap /dev/sdX none luks" | sudo tee -a /etc/crypttab
 
# Add to /etc/fstab
echo "/dev/mapper/cryptswap none swap sw 0 0" | sudo tee -a /etc/fstab
 
# Enable swap
sudo swapon /dev/mapper/cryptswap
 
# Method 3: Use encrypted file-based swap (flexible)
 
# Create encrypted swap file
sudo dd if=/dev/zero of=/swapfile bs=1M count=4096
sudo chmod 600 /swapfile
sudo cryptsetup luksFormat /swapfile
sudo cryptsetup luksOpen /swapfile cryptswap
sudo mkswap /dev/mapper/cryptswap
sudo swapon /dev/mapper/cryptswap

Defense in Depth for System Areas

For full coverage: (1) Use full-disk encryption as a baseline, (2) Encrypt swap with a random key regenerated each boot, (3) Use tmpfs for /tmp so temporary files never hit disk, (4) Ensure logs are either on encrypted volumes or shipped encrypted to remote storage, and (5) Implement log scrubbing to avoid logging sensitive data in the first place.

Encryption for Containers and Orchestrators

Containerized environments present unique encryption challenges. Containers are ephemeral, scaled dynamically, and often scheduled across diverse infrastructure. Traditional volume encryption that requires unlock at boot doesn't fit this model well.

Container storage encryption strategies:

Container Encryption Approaches

•Encrypted host nodes — Use full-disk encryption on container hosts. All container storage inherits encryption.
•Encrypted persistent volumes — Use encrypted storage classes in Kubernetes; CSI drivers handle encryption with cloud KMS.
•Encrypted container images — Encrypt container images at rest in registries; decrypt at pull time with authorized keys.
•Application-level encryption — Containers encrypt their own data; portable across any infrastructure.
•Secrets management — Use Vault, Kubernetes Secrets, or cloud secret managers for credentials; don't store secrets in container filesystems.

Container Storage Encryption
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
# Example: AWS EBS CSI with encryption
 
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: encrypted-ebs
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  encrypted: "true"
  # Optional: specific KMS key
  kmsKeyId: arn:aws:kms:us-east-1:123456789:key/abc123
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
 
---
# StatefulSet with encrypted volumes
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sensitive-app
spec:
  serviceName: sensitive-app
  replicas: 3
  selector:
    matchLabels:
      app: sensitive-app
  template:
    metadata:
      labels:
        app: sensitive-app
    spec:
      containers:
        - name: app
          image: myapp:latest
          volumeMounts:
            - name: data
              mountPath: /data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: encrypted-ebs  # Uses encrypted storage class
        resources:
          requests:
            storage: 50Gi

Ephemeral Storage Consideration

Container ephemeral storage (container filesystem, emptyDir volumes) typically lives on the host's disk. If hosts aren't encrypted, this data is unprotected. For sensitive workloads, either ensure hosts use full-disk encryption, use memory-backed emptyDir (medium: Memory), or only store sensitive data in encrypted persistent volumes.

Summary: File System Encryption

We've covered the breadth of file system encryption options. Let's consolidate the key insights:

Key Takeaways

•Encryption works at multiple layers — Application, file system, volume, and hardware. Each has tradeoffs between granularity and simplicity.
•Full-disk encryption (FDE) is the baseline — Use BitLocker, LUKS, or FileVault on all laptops and workstations. No exceptions.
•Volume encryption protects server data volumes — Cloud providers offer native encryption for block storage. Enable it everywhere.
•File-level encryption travels with data — Use when files will be transferred, backed up, or when different files need different keys.
•Self-encrypting drives offer zero-overhead protection — Great for performance-sensitive workloads, but verify implementation security.
•Don't forget swap, temp, and logs — Sensitive data leaks through these system areas. Encrypt swap, use tmpfs for /tmp, and protect logs.
•Container environments need special consideration — Encrypted storage classes, secrets management, and encrypted hosts combine for defense in depth.
•Recovery key management is critical — Lost keys mean lost data. Always escrow recovery keys securely and test recovery procedures.

What's next:

We've now covered database encryption and file system encryption—the two major categories of data at rest. Next, we'll dive deep into key management: the critical infrastructure that makes all encryption possible. Without proper key management, even the strongest encryption is only as secure as how you protect your keys.

Page Complete

You now understand the full spectrum of file system encryption options—from full-disk encryption to file-level encryption, hardware encryption, and container storage encryption. You can design comprehensive encryption strategies that protect not just primary data but also system areas like swap, temp, and logs. Next, we'll explore the key management systems that underpin all of this encryption.