Encryption is non-negotiable for any modern SaaS. The question isnโt โshould we encrypt?โ โ itโs โwhere, how, and who manages the keys?โ
This lesson covers the three states data lives in (at rest, in transit, in use), the encryption approaches for each, and the key management practices that make encryption actually meaningful.
The Three States of Data
๐พ
At rest
Stored data. Database, object storage, backups, logs. Encryption protects against media theft, unauthorized backup access, lost laptops.
๐
In transit
Data moving across the network. Client-server, service-to-service. Encryption protects against eavesdropping, MITM, network compromise.
๐ง
In use
Data being processed in memory. Encryption is much harder; emerging tech (homomorphic encryption, confidential computing). Mostly for highly regulated workloads.
For most SaaS, focus on at-rest and in-transit. In-use is the next frontier; not yet table stakes.
Encryption in Transit
TLS โ The Foundation
TLS (Transport Layer Security) encrypts and authenticates network connections. Modern TLS is TLS 1.2 or 1.3; older versions (SSL 2/3, TLS 1.0/1.1) are deprecated and insecure.
TLS 1.2
Still acceptable
Widely supported. 2 round-trips for handshake. Many cipher suites โ pick modern ones (AES-GCM, ChaCha20).
TLS 1.3
The modern default
Faster handshake (1 round-trip, 0-RTT for resumption). Forward secrecy mandatory. Simpler cipher suite choices. The right default for new systems.
Certificates and Public Key Infrastructure
Servers prove identity via certificates issued by Certificate Authorities (CAs).
๐
Let's Encrypt
Free, automated, ubiquitous. ACME protocol for issuance and renewal. Default for most modern projects.
โ๏ธ
AWS / GCP Certificate Manager
Cloud-managed certs. Free for use within the cloud. Auto-renewal. Tightly integrated with their load balancers.
๐ข
Commercial CAs
DigiCert, Sectigo. Used for EV certs (extended validation), wildcard certs at scale, internal PKI.
๐ง
Internal CAs
For service-to-service mTLS. SPIFFE/SPIRE, cert-manager (K8s), HashiCorp Vault PKI.
mTLS โ Mutual TLS
Both sides present certificates. Used for service-to-service authentication where you donโt want to rely on network position alone.
๐ค
How it works
Client and server each present a certificate. Each verifies the other's cert chain. Connection only succeeds if both authenticate.
Service mesh certs rotate hourly or daily. Compromised cert window is minimal.
๐ซ
When NOT to use
Public-facing endpoints. mTLS for "service A talks to service B," not "user talks to API." Use OAuth/OIDC there.
Encryption at Rest
Database Encryption
๐๏ธ
Transparent Data Encryption (TDE)
DB-level encryption. RDS, Aurora, Postgres TDE plugins. Files on disk are encrypted; SQL queries operate on plaintext.
๐ข
Column-level encryption
Encrypt specific columns (SSNs, credit cards) at the application layer. DB sees ciphertext. More work; granular control.
๐
Format-preserving encryption
Encrypted output has the same format as plaintext. Useful when DB schema or external systems require specific format.
๐ช
Tokenization
Replace sensitive values with non-sensitive tokens; original stored in a vault. PCI compliance pattern. Works without changing downstream systems.
Storage Encryption
๐ชฃ
S3 / Object storage
SSE-S3 (AWS-managed keys), SSE-KMS (your KMS keys), SSE-C (your keys). All transparent to the application.
๐พ
Block storage (EBS, persistent disks)
Volume-level encryption. Free; transparent to apps. Encrypt by default.
๐
File systems
EFS, Azure Files. Encrypted at rest. Plus filesystem-level (LUKS, dm-crypt) for self-managed.
๐ผ
Backups
Often forgotten. If your DB is encrypted but backups aren't, an attacker getting backup access bypasses everything.
Key Management
The hardest part of cryptography. Bad key management makes everything else moot.
KMS โ Key Management Service
Cloud-native KMS handles the operational complexity.
๐
AWS KMS
Managed keys. Hardware-backed (HSM available via CloudHSM). IAM-based access. Audit via CloudTrail.
๐ก๏ธ
GCP Cloud KMS
Equivalent on GCP. Multi-region, HSM-backed, integrated with all GCP services.
๐ฐ
Azure Key Vault
Equivalent on Azure. Plus secret storage, certificate management.
๐ชฃ
HashiCorp Vault
Self-hosted alternative. Strong fit for multi-cloud or specific compliance requirements.
Envelope Encryption
The standard pattern in cloud KMS:
1. Generate a Data Encryption Key (DEK) โ random AES key.2. Encrypt the data with the DEK (fast โ AES-GCM).3. Encrypt the DEK with a Key Encryption Key (KEK) stored in KMS.4. Store: ciphertext + encrypted DEK. KEK never leaves KMS.To decrypt:1. Send encrypted DEK to KMS.2. KMS decrypts and returns DEK.3. Decrypt data with DEK.4. Discard DEK.
Key Rotation
Best practice: rotate keys regularly.
๐
KMS automatic rotation
AWS KMS rotates KEKs annually by default. Old key version retained for decryption of old data.
โ๏ธ
Re-encryption
Periodically re-encrypt data with new DEKs. Cloud features (Aurora KMS rotation) handle this transparently for managed services.
๐จ
Compromise response
If a key is compromised, rotate immediately. Re-encrypt affected data. Audit access during the compromise window.
Compliance and Encryption
Various compliance frameworks have specific encryption requirements:
๐ณ
PCI DSS
Cardholder data must be encrypted with strong cryptography. Tokenization or strong encryption with key management. Quarterly key rotation often required.
๐ฅ
HIPAA
PHI must be encrypted at rest and in transit. Specific algorithms required (FIPS 140-2 validated).
๐ช๐บ
GDPR
Encryption of personal data is one way to satisfy "appropriate technical measures." Combined with proper access controls and breach notification.
๐
SOC 2
Auditors look for encryption at rest and in transit, key management practices, audit logs of key access.
Forward Secrecy
A property that limits the damage if your private key is later compromised.
Without forward secrecy
Past sessions exposed
Server's long-lived private key recovered โ attacker decrypts every past session ever recorded. Catastrophic.
With forward secrecy
Past sessions safe
Each session uses an ephemeral key derived via Diffie-Hellman. Long-lived key compromise doesn't expose past sessions.
TLS 1.3 mandates forward secrecy. TLS 1.2 supports it via ECDHE cipher suites โ make sure those are configured.
Encryption in Use (The Frontier)
For highly regulated workloads where data must remain encrypted even during processing:
๐
Confidential Computing
TEEs (Trusted Execution Environments) โ Intel SGX, AMD SEV, AWS Nitro Enclaves. Hardware-isolated execution; even cloud admin can't see the data.
๐งฎ
Homomorphic Encryption
Compute on ciphertext directly. Mathematically beautiful; orders of magnitude slower than plaintext computation. Limited practical use today.
๐
Multi-Party Computation
Multiple parties jointly compute over their inputs without revealing them. Banks computing aggregate statistics without sharing customer data.
These are emerging technologies. Most SaaS doesnโt need them yet โ but watch the space, especially if you serve regulated industries.
Recap
Three states: at rest, in transit, in use. Different threat models, different solutions.
TLS 1.3 for in-transit. mTLS for service-to-service in zero-trust environments.
Letโs Encrypt or cloud-managed certs for public TLS. Internal PKI (cert-manager, Vault) for mTLS.
At rest: TDE for DBs, transparent encryption for storage. Backups must also be encrypted.
KMS for managed key handling. Envelope encryption is the standard pattern.
Key rotation: automatic via KMS where possible, with rapid response procedures for compromises.
Forward secrecy is mandatory in TLS 1.3, recommended in 1.2 (ECDHE cipher suites).
Encryption-in-use (confidential computing, homomorphic encryption) is the frontier โ watch but donโt adopt prematurely.