Data Encryption at Rest and in Transit: A Practical Architecture Guide

Encryption is the last line of defense. If an attacker bypasses your firewalls, evades your IDS, and exfiltrates your database — encryption ensures they get ciphertext, not data. Modern systems must encrypt data both at rest (stored on disk) and in transit (moving across the network).

Encryption at Rest#

Encryption at rest protects stored data — database files, object storage, backups, and logs. If a disk is stolen, a snapshot is leaked, or an S3 bucket is misconfigured, the data remains unreadable without the encryption key.

AES-256#

The industry standard for symmetric encryption is AES-256 (Advanced Encryption Standard with a 256-bit key). It is approved by NIST, used by every major cloud provider, and considered computationally infeasible to brute-force.

Plaintext ──▶ AES-256-GCM Encrypt ──▶ Ciphertext + Auth Tag
                    ▲
                    │
              256-bit Key

AES-GCM (Galois/Counter Mode) is preferred because it provides both confidentiality and integrity — the authentication tag detects tampering.

Envelope Encryption#

Encrypting data directly with a master key is dangerous — if that key is compromised, everything is exposed. Envelope encryption adds a layer of indirection:

1. Generate a unique data encryption key (DEK) for each object or record.
2. Encrypt the data with the DEK.
3. Encrypt the DEK with a key encryption key (KEK) managed by your KMS.
4. Store the encrypted DEK alongside the ciphertext.

┌────────────────────────────────────────────────┐
│                  KMS                           │
│  ┌──────────────────────────────────────────┐  │
│  │  Key Encryption Key (KEK) — never leaves │  │
│  └──────────────┬───────────────────────────┘  │
│                 │                               │
│        Encrypt / Decrypt DEK                   │
└────────────────┬───────────────────────────────┘
                 │
                 ▼
┌────────────────────────────────────────────────┐
│  Encrypted DEK  +  Ciphertext (data)           │
│  Stored together in database / object store    │
└────────────────────────────────────────────────┘

Why envelope encryption:

• The KEK never leaves the KMS hardware boundary.
• Rotating the KEK only requires re-encrypting DEKs, not all data.
• Each object has a unique DEK — compromising one does not expose others.

Key Management Services#

AWS KMS#

AWS Key Management Service stores KEKs in FIPS 140-2 Level 2 validated hardware security modules (HSMs). Key features:

• Automatic key rotation every year (configurable).
• Key policies control which IAM principals can use each key.
• Audit trail via CloudTrail — every encrypt/decrypt call is logged.
• Grants allow temporary, scoped access to keys without modifying policies.

Google Cloud KMS and Azure Key Vault#

Google Cloud KMS and Azure Key Vault offer similar capabilities — HSM-backed key storage, automatic rotation, IAM integration, and audit logging. The envelope encryption pattern is identical across providers.

HashiCorp Vault#

Vault provides a cloud-agnostic secrets and key management platform:

• Transit secrets engine performs encryption/decryption without exposing keys to applications.
• Dynamic secrets generate short-lived database credentials on demand.
• Auto-unseal integrates with cloud KMS to unseal Vault without manual intervention.
• Key versioning supports rotation with automatic decryption using previous key versions.

Application ──▶ Vault Transit API ──▶ Ciphertext
                     │
                Vault never exposes
                the encryption key

The application sends plaintext to Vault and receives ciphertext. The key material stays inside Vault.

Encryption in Transit#

Encryption in transit protects data moving between clients and servers, between services, and between data centers.

TLS 1.3#

TLS 1.3 is the current standard for encryption in transit. Compared to TLS 1.2:

• One-round-trip handshake (down from two) reduces latency.
• Removed weak ciphers — no RSA key exchange, no CBC mode, no RC4.
• Forward secrecy is mandatory — every session uses ephemeral keys.

Client                          Server
  │── ClientHello ─────────────▶│
  │   (supported ciphers,       │
  │    key share)                │
  │                              │
  │◀── ServerHello ──────────────│
  │    (chosen cipher,           │
  │     key share, cert,         │
  │     Finished)                │
  │                              │
  │── Finished ────────────────▶│
  │                              │
  │◀═══ Encrypted Traffic ══════▶│

Certificate Management#

TLS requires certificates. Mismanaging them causes outages and security gaps:

• Automate issuance with ACME (Let's Encrypt) or an internal CA.
• Monitor expiry — set alerts at 30, 14, and 7 days before expiration.
• Pin certificates cautiously — pinning prevents MITM but causes outages if rotation is botched.

mTLS for Service-to-Service#

For internal traffic, mutual TLS authenticates both the client and server. Service meshes (Istio, Linkerd) automate mTLS across all service communication.

Field-Level Encryption#

Sometimes encrypting the entire database is not enough. Field-level encryption (FLE) encrypts individual fields — like social security numbers, credit card numbers, or health records — before they reach the database.

Application Layer
┌────────────────────────────────────────┐
│  { name: "Alice",                      │
│    ssn: encrypt("123-45-6789"),        │
│    email: "alice@example.com" }        │
└────────────────────┬───────────────────┘
                     │
                     ▼
Database Layer
┌────────────────────────────────────────┐
│  { name: "Alice",                      │
│    ssn: "AQFkgJ...encrypted...base64", │
│    email: "alice@example.com" }        │
└────────────────────────────────────────┘

Benefits:

• A database administrator can query non-sensitive fields without seeing PII.
• A full database dump does not expose encrypted fields.
• Different fields can use different keys — finance keys separate from HR keys.

MongoDB Client-Side Field Level Encryption and AWS DynamoDB client-side encryption are production-ready implementations of this pattern.

Transparent Data Encryption (TDE)#

TDE encrypts database files at the storage layer — the database engine handles encryption and decryption transparently. The application sees plaintext; the disk sees ciphertext.

Limitations of TDE:

• Does not protect data in memory or in query results.
• A DBA with access to the running database sees plaintext.
• Does not protect against SQL injection — the attacker queries through the engine.

TDE is a baseline, not a complete solution. Combine it with field-level encryption for sensitive columns and mTLS for network protection.

Encryption Architecture Decision Matrix#

Key Rotation Strategies#

Key rotation limits the blast radius of a compromised key:

• Automatic rotation — KMS rotates the KEK annually. Old versions remain available for decryption.
• Re-encryption — Periodically re-encrypt data with the latest key version. Required for some compliance frameworks.
• Crypto-shredding — Delete the key to render data permanently unrecoverable. Useful for GDPR right-to-erasure.

Key Takeaways#

• Encrypt data at rest with AES-256-GCM using envelope encryption — never encrypt directly with a master key.
• Use a KMS (AWS KMS, Vault, Cloud KMS) to manage key encryption keys in hardware-backed storage.
• Enforce TLS 1.3 for all traffic in transit. Use mTLS for service-to-service communication.
• Apply field-level encryption to PII and sensitive data — TDE alone is insufficient for defense in depth.
• Automate key rotation and certificate renewal. Manual processes lead to outages and security gaps.
• Log every key usage event for audit and forensic analysis.

Encryption is not a feature you bolt on later. It is a foundational architecture decision that shapes how you store, transmit, and manage data from day one.

---

Build and explore system design concepts hands-on at codelit.io.

Explore more system design guides at codelit.io/blog.