Encryption at Rest & in Transit

Data encryption addresses two threat models: an attacker intercepting data in flight (man-in-the-middle, network sniffing) and an attacker accessing stored data (stolen hard drives, compromised backups, insider access to database files). Encryption in transit and encryption at rest are complementary -- a system that only encrypts in transit is vulnerable to data breaches from stolen storage, and a system that only encrypts at rest is vulnerable to network eavesdropping.

Encryption in transit is implemented via TLS (Transport Layer Security). TLS 1.3, finalized in 2018, provides confidentiality (AES-256-GCM encryption), integrity (HMAC), and authentication (certificate-based identity verification) for all data moving between systems. Every HTTP request, database query, cache lookup, and message queue publish should use TLS. In microservice architectures, mTLS (mutual TLS) adds client-side certificates, enabling both parties to authenticate each other. Service meshes like Istio automate mTLS by injecting sidecar proxies that handle certificate management and encryption transparently.

Encryption at rest protects data stored on disk: databases, file systems, backups, and object stores. The standard approach is envelope encryption: the data is encrypted with a Data Encryption Key (DEK) using AES-256-GCM, and the DEK is wrapped (encrypted) with a Key Encryption Key (KEK) stored in a Key Management Service (KMS). The encrypted DEK is stored alongside the encrypted data. To decrypt, the service sends the wrapped DEK to the KMS, which returns the unwrapped DEK (never exposing the KEK), and the service uses the DEK to decrypt the data.

Envelope encryption provides several security benefits. The KEK never leaves the KMS (hardware security module backed), so even a complete database breach reveals only encrypted data and encrypted DEKs. Each data object can have its own DEK (per-row, per-file, per-tenant), enabling fine-grained key rotation without re-encrypting all data. Rotating the KEK requires only re-wrapping the DEKs (fast), not re-encrypting all data (slow). KMS access is logged and auditable, providing a clear record of who decrypted what and when.

Cloud providers offer transparent encryption at rest for managed services: AWS S3 (SSE-S3, SSE-KMS), RDS (TDE), DynamoDB, Azure Storage (AES-256), and GCP Cloud Storage all encrypt data automatically. The key decision is whether to use provider-managed keys (SSE-S3), customer-managed keys (SSE-KMS with your key in AWS KMS), or customer-provided keys (SSE-C where you supply the key per request). Customer-managed keys provide more control and auditability; provider-managed keys are simpler but give less visibility into key usage.

When storing a user's SSN, the application generates a random DEK (AES-256 key). It encrypts the SSN with the DEK. It calls AWS KMS to wrap (encrypt) the DEK with the tenant's KEK. It stores the encrypted SSN and the wrapped DEK in the database row. To read: the application retrieves the encrypted SSN and wrapped DEK, calls KMS to unwrap the DEK, decrypts the SSN, and returns it. If the database is stolen, the attacker has encrypted SSNs and encrypted DEKs -- both useless without KMS access, which requires IAM credentials and is fully audited.