Data Encryption at Rest - Full Disk & Database Encryption

Master data encryption at rest: full disk encryption, database encryption, envelope encryption, tokenization, cloud-native controls, and rekeying strategies.

Data encryption at rest protects data stored on physical media, reducing blast radius when storage devices, snapshots, or backups are exposed through theft, improper disposal, or unauthorized access. Security engineers select appropriate encryption layers, design for operational efficiency, and implement provable controls that demonstrate encryption effectiveness to auditors and compliance teams.

Encryption at rest provides defense-in-depth against physical media theft, insider threats with physical access, and cloud provider breaches. The NIST Cybersecurity Framework identifies data protection as a core function, and NIST SP 800-111 provides comprehensive guidance on storage encryption technologies.

Encryption Layers

Multiple encryption layers provide defense-in-depth, with each layer protecting against different threat vectors and providing different operational tradeoffs.

Full Disk Encryption

Full Disk Encryption (FDE) encrypts entire storage devices, protecting all data on physical media. FDE operates transparently to applications and operating systems, requiring no application changes. Modern implementations use AES-256 in XTS mode, as recommended by NIST SP 800-38E.

FDE protects against physical device theft and improper disposal but provides limited protection against attacks on running systems. Once systems boot and decrypt volumes, FDE provides no additional protection—an attacker with access to a running system sees decrypted data.

BitLocker (Windows), FileVault (macOS), and dm-crypt/LUKS (Linux) provide operating system-level FDE. Cloud providers offer encrypted volumes with provider-managed or customer-managed keys through AWS EBS Encryption, Azure Disk Encryption, and GCP Persistent Disk Encryption.

Filesystem and Volume Encryption

Filesystem and volume encryption provides per-volume encryption keys, enabling different encryption keys for different volumes on the same host. Per-volume keys are useful for multi-tenant hosts where different tenants require key separation, or when different data classifications require different key controls.

Volume encryption enables selective encryption of sensitive data while leaving less sensitive data unencrypted for performance. Encrypted volumes can be mounted and unmounted independently, enabling just-in-time decryption for sensitive workloads.

Cloud provider encrypted volumes integrate with key management services, enabling customer-managed keys with full audit logging. Encryption is transparent to applications accessing the volumes.

Database Encryption

Transparent Data Encryption (TDE) encrypts database pages and transaction logs, protecting data at rest within databases. SQL Server TDE, Oracle TDE, and PostgreSQL pgcrypto provide database-level encryption that operates transparently to applications without requiring query modifications.

Application-layer encryption encrypts specific fields or columns, enabling fine-grained encryption based on data sensitivity. Field-level encryption supports least-privilege access where different users can access different encrypted fields—a customer service representative might see masked credit card numbers while billing staff see full numbers.

Application-layer encryption complicates database operations including indexing, searching, and sorting on encrypted fields. Deterministic encryption enables equality searches but provides weaker security than randomized encryption by revealing when two values are equal.

Encryption Patterns

Different encryption patterns suit different use cases and threat models. Understanding tradeoffs enables selecting appropriate patterns for specific requirements.

Envelope Encryption

Envelope encryption separates Key Encryption Keys (KEKs) from Data Encryption Keys (DEKs), with KEKs stored in Hardware Security Modules or Key Management Services and DEKs encrypted by KEKs. This pattern, used by AWS KMS, Azure Key Vault, and Google Cloud KMS, provides the best balance of security and operational efficiency.

Envelope encryption enables KEK rotation without re-encrypting all data—only DEKs need re-encryption. This approach dramatically reduces re-encryption time from potentially days for large datasets to seconds for DEK metadata.

Per-object DEKs provide cryptographic isolation between objects, limiting blast radius from DEK compromise. Object-level DEKs enable fine-grained access control and key rotation for individual data objects.

Application-Level Encryption

Application-level encryption encrypts data before storage, providing end-to-end encryption where cloud providers never see plaintext data. Application-level encryption provides strongest protection but requires careful secrets management for encryption keys.

Field-level and record-level encryption enable selective encryption based on data sensitivity. Sensitive fields like credit card numbers or social security numbers can be encrypted while less sensitive fields remain plaintext for searching and indexing.

Searchable encryption techniques including deterministic encryption and order-preserving encryption enable limited searching on encrypted data, though with security tradeoffs. Libraries like Google Tink and AWS Encryption SDK simplify application-level encryption implementation.

Tokenization

Tokenization replaces sensitive data with non-sensitive tokens, with token-to-value mapping stored in secure token vaults. Irreversible tokenization uses cryptographic hash functions preventing token-to-value lookup.

Reversible tokenization enables token-to-value lookup for authorized users through token vault APIs. Token vaults should be hardened with strict access controls and comprehensive audit logging.

Tokenization reduces PCI DSS scope by removing credit card data from most systems, with only token vaults requiring PCI compliance. Format-preserving tokenization maintains data format (16-digit numbers remain 16-digit numbers), enabling use in legacy systems without schema changes.

Cloud Encryption Considerations

Cloud providers offer multiple encryption options with different security and operational characteristics. Understanding these options enables appropriate selection for specific workloads.

Provider-Managed vs. Customer-Managed Keys

Provider-managed keys including AWS SSE-S3 and GCP default encryption provide encryption at rest with minimal operational burden. Provider-managed keys are suitable for most workloads without regulatory key control requirements.

Customer-Managed Encryption Keys (CMEK) provide customer control over encryption keys, enabling key rotation, access control, and audit logging. CMEK is required for regulatory frameworks requiring key management separation from cloud providers, including some interpretations of GDPR and financial services regulations.

CMEK increases operational complexity through key lifecycle management, rotation, and access control. Organizations should use CMEK only when regulatory or business requirements demand it—the added complexity increases risk of operational failures.

Cross-Account Key Management

Cross-account KMS keys for backup vaults provide additional protection by separating backup encryption keys from production keys. Cross-account separation prevents production account compromise from affecting backup encryption.

Deny-by-default key policies require explicit grants for key usage, preventing accidental or unauthorized key access. Key policies should be reviewed regularly and audited comprehensively through AWS CloudTrail or equivalent logging.

Every decrypt operation should be logged with resource principal information, enabling detection of unauthorized decryption attempts. Anomaly detection on decrypt operations identifies unusual access patterns indicative of data exfiltration.

Key Rotation and Data Migration

Key rotation is essential for limiting the impact of key compromise and meeting compliance requirements. Effective rotation requires careful planning to avoid service disruptions.

Rolling Re-Encryption

Key rotation requires re-encrypting data with new keys, which can be time-consuming for large datasets. Rolling re-encryption processes data in batches, spreading re-encryption over time to avoid performance impact on production systems.

Re-encryption should be throttled to limit performance impact. Monitoring during re-encryption detects performance degradation or errors. Integrity verification after re-encryption ensures that data was correctly re-encrypted without corruption through cryptographic checksums and sample decryption tests.

Backpressure mechanisms prevent re-encryption from overwhelming systems, automatically slowing re-encryption when system load increases. Production traffic always takes priority over background re-encryption work.

Versioned Keys and Schemas

Key versioning enables multiple key versions to coexist during rotation, with data encrypted by different key versions. Applications should support decryption with any valid key version, selecting the appropriate version based on metadata stored with encrypted data.

Schema versioning enables gradual migration to new encryption schemes. Dual-read support enables applications to read data encrypted with old and new schemes during migration, writing new data with the new scheme while still reading legacy data.

Migration completion requires verifying that all data has been re-encrypted with new keys and that old keys can be safely retired without breaking decryption.

Encryption Telemetry and Compliance

Security metrics for encryption demonstrate control effectiveness and support compliance requirements.

Key Usage Logging

Comprehensive logging of key usage including encrypt and decrypt operations with resource principals enables detection of unauthorized key usage. Logs should include timestamp, principal, key ID, operation type, and success/failure status.

Anomaly detection on key usage patterns identifies unusual access including access from unexpected locations, unusual volumes, or access to unusual keys. Integration with SIEM systems enables automated alerting for rapid investigation.

Compliance Evidence

Auditors require evidence that encryption is properly implemented and operating effectively. Evidence includes encryption configuration exports, key policy snapshots, and usage logs demonstrating ongoing operation.

Signed policy snapshots provide cryptographic proof of encryption configuration at specific points in time. Snapshots should be retained for audit periods required by applicable regulatory compliance frameworks.

Encryption coverage reports demonstrate what percentage of data is encrypted, identifying unencrypted data requiring remediation. Coverage should approach 100% for sensitive data classifications.

Conclusion

Data encryption at rest requires selecting appropriate encryption layers, implementing efficient key management, and providing comprehensive audit evidence. Security engineers design encryption architectures that balance security with operational efficiency while meeting compliance requirements.

Success requires treating encryption as an operational capability requiring monitoring, key rotation, and continuous compliance validation. Organizations that invest in encryption at rest fundamentals protect data from physical theft and unauthorized access while demonstrating security controls to auditors and customers.

Related Articles

• Key Management - Cryptographic key lifecycle and HSM/KMS
• Secrets Management - Encryption key storage and rotation
• Defense in Depth - Encryption as a defense layer
• Data Loss Prevention - Data protection controls
• Privacy Engineering - Encryption for privacy compliance
• Cloud Security Fundamentals - Cloud encryption services

References

• NIST SP 800-111 — Guide to Storage Encryption Technologies for End User Devices
• NIST SP 800-38E — Recommendation for Block Cipher Modes of Operation: XTS-AES Mode
• PCI DSS Tokenization Guidelines — PCI Council guidance on tokenization
• FIPS 140-3 — Security Requirements for Cryptographic Modules
• AWS KMS Documentation — AWS Key Management Service best practices
• Azure Key Vault Documentation — Azure key management guidance
• Google Cloud KMS — Google Cloud key management documentation