====== Encryption at Rest ======
**Encryption at rest** refers to the cryptographic protection of data stored in persistent storage systems to prevent unauthorized access in the event of physical compromise, theft, or breach of storage infrastructure. This foundational security practice applies cryptographic algorithms to data as it exists on disk, in databases, file systems, and other non-volatile storage media, ensuring that the data remains protected even when the storage device is offline or physically separated from its original system.

===== Overview and Definition =====
Encryption at rest operates on the principle that data should be protected throughout its entire lifecycle, particularly when stored in passive systems where it cannot actively defend itself. Unlike encryption in transit, which protects data as it moves across networks, encryption at rest focuses on the stationary state of data(([[https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175B.pdf|NIST - Guidelines for Media Sanitization (2014]])). The encrypted data becomes unreadable without the corresponding decryption key, rendering stolen or compromised storage media effectively useless to attackers without access to the cryptographic material.

Modern encryption at rest implementations typically employ **Advanced Encryption Standard (AES)** algorithms, most commonly AES-256, which provides 256-bit key strength and is considered secure against brute-force attacks for the foreseeable future(([[https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf|NIST - Advanced Encryption Standard (2001]])). Organizations implement encryption at rest across multiple data storage layers to create comprehensive protection—from database systems and backup archives to temporary compute caches and write-ahead logs.

===== Implementation Architectures =====
Encryption at rest can be implemented at multiple layers within data infrastructure, each with distinct advantages and operational considerations:

**Storage-layer encryption** operates at the physical storage device level, transparently encrypting all data written to disk. Self-encrypting drives (SEDs) and storage array encryption provide this capability with minimal application-level changes, though key management remains centralized within the storage infrastructure.

**Database-level encryption** provides encryption within the database management system itself, allowing granular control over which data structures are encrypted and enabling field-level or column-level encryption for sensitive columns. This approach offers flexibility but introduces computational overhead during query execution.

**Application-level encryption** implements encryption within the application code before data reaches storage systems, providing end-to-end encryption guarantees and ensuring that even database administrators cannot access plaintext data without application-level keys(([[https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175B.pdf|NIST - Guidelines for Media Sanitization (2014]])).

Modern data platforms extend encryption at rest beyond traditional database storage. For example, comprehensive encryption frameworks protect both persistence layers (write-ahead logs, data files) and ephemeral compute caches, ensuring protection across the entire data pipeline(([[https://www.databricks.com/blog/take-control-customer-managed-keys-lakebase-postgres|Databricks - Take Control: Customer-Managed Keys in Lakebase Postgres (2026]])). This holistic approach prevents unencrypted data exposure during intermediate processing stages.

===== Key Management Considerations =====
Effective encryption at rest requires robust key management practices that address key generation, storage, rotation, and access control. **Customer-managed keys (CMK)** allow organizations to maintain exclusive control over encryption keys, preventing cloud providers or infrastructure operators from accessing plaintext data. This approach aligns with regulatory requirements in sectors requiring data sovereignty and regulatory compliance.

Key rotation policies establish schedules for replacing encryption keys without decrypting and re-encrypting all data—a process that leverages key derivation and version management. Regular rotation limits the potential impact of key compromise and demonstrates compliance with security standards(([[https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf|NIST - Recommendation for Key Management (2020]])). Organizations must establish procedures for key escrow and recovery to prevent data loss if encryption keys are compromised or accidentally deleted.

===== Regulatory and Compliance Requirements =====
Multiple regulatory frameworks mandate encryption at rest for sensitive data categories. **HIPAA** (Health Insurance Portability and Accountability Act) requires encryption for protected health information stored at rest. **GDPR** (General Data Protection Regulation) mandates encryption as a security safeguard for personal data processing. **PCI DSS** (Payment Card Industry Data Security Standard) requires encryption of cardholder data stored in databases and storage systems. Federal standards including **NIST SP 800-171** specifically require encryption at rest for controlled unclassified information in government and defense contracting environments.

Compliance audits increasingly focus on encryption at rest implementation details, including key management procedures, encryption algorithm selection, and key rotation schedules. Organizations must document encryption policies, maintain audit logs of key access and use, and demonstrate that encryption keys are protected with the same rigor as the encrypted data itself.

===== Challenges and Limitations =====
Encryption at rest introduces performance considerations due to cryptographic computation overhead during data writes and reads. Key management complexity increases exponentially with the number of encrypted data stores and requires sophisticated infrastructure for key distribution, rotation, and access control. Performance testing is essential to quantify impact on write throughput and query latency in production environments.

Encrypted data remains vulnerable to inference attacks and pattern analysis, particularly when encryption occurs at the field level rather than at the complete data [[block|block]] level. Attackers with sufficient access to encrypted datasets may derive information through traffic analysis, timing analysis, or statistical patterns despite lacking access to plaintext. Properly implemented encryption at rest does not provide protection against application-level vulnerabilities, SQL injection attacks, or compromised user credentials that allow legitimate access to decryption keys.


===== See Also =====

  * [[envelope_encryption|Envelope Encryption]]
  * [[key_wrapping_unwrapping|Key Wrapping and Unwrapping Operations]]
  * [[ephemeral_compute_encryption|Ephemeral Compute Encryption]]

===== References =====