Why this matters
As a Backend Engineer, you handle sensitive traffic and data. Strong encryption prevents eavesdropping, tampering, and data exposure if disks or backups leak. You will:
- Enable HTTPS/TLS for APIs and dashboards.
- Secure service-to-service calls with mTLS.
- Encrypt databases, files, and backups at rest.
- Design key rotation and respond to incidents safely.
- Meet compliance expectations (e.g., “encrypt in transit and at rest”).
Concept explained simply
Encryption in transit protects data while it moves between clients and services. Think of a private tunnel: outsiders can see packets moving, but not the contents.
Encryption at rest protects stored data (databases, disks, backups). Think of a locked safe: even if someone steals the safe, they can’t open it without the key.
Mental model
- Data states: moving (in transit) vs. sitting (at rest).
- Keys unlock data: protect keys more than the data.
- Layers: use TLS for the wire; use disk/DB/application encryption for storage. Layers complement each other.
- Rotation: assume keys age out. Plan to replace without downtime.
Key terms (quick expand)
- TLS: Protocol that encrypts data in transit (HTTPS, gRPC).
- mTLS: Both client and server present certificates to authenticate each other.
- TDE/Full-disk encryption: Storage-level encryption, transparent to apps.
- Application-level encryption: Your code encrypts specific fields before storage.
- Envelope encryption: Encrypt data with a Data Encryption Key (DEK), then encrypt the DEK with a Key Encryption Key (KEK, e.g., KMS).
- AES-GCM: Authenticated encryption mode; needs a unique nonce per encryption.
Worked examples
Example 1 — HTTPS API hardening
Goal: Serve an API only over TLS with modern settings and automatic HTTP→HTTPS redirect.
- Use TLS 1.2 and 1.3 only. Disable old protocols/ciphers.
- Redirect port 80 to 443 permanently.
- Enable HSTS so browsers prefer HTTPS.
- Enable OCSP stapling so clients can verify revocation efficiently.
What “good” looks like
- Protocols: TLSv1.2, TLSv1.3
- Ciphers: prioritize AEAD (e.g., AES-GCM, CHACHA20-POLY1305)
- Headers: Strict-Transport-Security with long max-age
- Redirects: 301 from http to https
Example 2 — mTLS between services
Goal: Only trusted services communicate. Both sides use certificates issued by your internal CA.
- Create a private CA (root) and issue per-service leaf certs.
- Each service trusts the CA (not each other directly).
- Server verifies client cert; client verifies server cert and hostname/SAN.
- Rotate certs regularly; keep overlap windows for zero-downtime rotation.
What “good” looks like
- Short-lived service certs (e.g., days/weeks).
- Automated issuance and rotation.
- Hostname/SAN validation and full chain verification.
Example 3 — At-rest encryption with envelope pattern
Goal: Encrypt a column like ssn with per-record DEKs and a KEK held by KMS.
- Generate a random 256-bit DEK per record.
- Encrypt data with AES-256-GCM using a unique 96-bit nonce. Include AAD (e.g., tenant_id, table, column, version).
- Encrypt the DEK with KMS (KEK) → eDEK.
- Store ciphertext, nonce, tag, eDEK, alg, version with the record.
- To decrypt: KMS decrypt eDEK → DEK; then AES-GCM decrypt and verify tag.
What “good” looks like
- Unique nonce per encryption (never reuse with GCM).
- Rotation: re-encrypt DEKs with a new KEK without touching ciphertexts.
- Keys and data stored separately; access strictly controlled.
Setup checklist
- [ ] All public endpoints force HTTPS with TLS 1.2+
- [ ] HSTS enabled after verifying HTTPS stability
- [ ] Internal service calls use TLS; high-trust paths use mTLS
- [ ] Databases/disks/backups encrypted at rest
- [ ] Sensitive fields use application-level encryption where needed
- [ ] Key rotation plan tested; old keys retired safely
- [ ] Secrets and keys never logged; access is auditable
Exercises
Note: Everyone can take exercises and the quick test. Only logged-in users will see saved progress.
Exercise 1 — Harden TLS for a public API (Nginx)
Create an Nginx config that:
- Redirects HTTP (80) to HTTPS (443).
- Enables TLS 1.2 and 1.3 only; uses modern AEAD ciphers.
- Sets Strict-Transport-Security for 1 year with includeSubDomains and preload.
- Enables OCSP stapling.
What to submit
A server block for :80 and a server block for :443 with the settings above. Use placeholder cert paths.
Hints
- Use a self-signed cert for local testing if needed.
- Prefer AES-GCM and CHACHA20-POLY1305 ciphers.
Exercise 2 — Design envelope encryption for a sensitive column
Write a short design that encrypts a field like ssn with per-record DEKs and a KEK in KMS.
- Describe generate, encrypt, store, decrypt, and rotate steps.
- Specify AES-256-GCM, 96-bit nonce, and AAD fields you include.
- Show an example of stored JSON fields for the encrypted column.
Hints
- DEK = random 32 bytes; eDEK = DEK encrypted by KMS.
- Store ciphertext + nonce + tag + eDEK + meta (alg, version).
Common mistakes and self-check
- Using outdated TLS (1.0/1.1). Self-check: scan your endpoints; your server config should only advertise TLS 1.2/1.3.
- Not validating hostnames in TLS. Self-check: ensure clients verify SAN/hostname and full chain.
- Reusing nonces with AES-GCM. Self-check: code generates a new 96-bit nonce per encryption.
- Storing keys with the data. Self-check: keys live in KMS/HSM or a separate secrets manager.
- Relying only on full-disk encryption. Self-check: sensitive columns also use application-level encryption when required.
- No rotation plan. Self-check: document and test KEK rotation and certificate rotation.
- Logging secrets or decrypted payloads. Self-check: log redaction enabled; access logs avoid sensitive values.
Practical projects
- Wrap an existing REST API with HTTPS and HSTS, then run a TLS scan locally to verify protocols/ciphers.
- Add application-level encryption to one sensitive column using envelope encryption with a mock KMS interface.
- Encrypt backups before upload; verify restore requires keys and integrity checks.
Who this is for
- Backend Engineers building user-facing or internal APIs.
- Platform/Infra Engineers responsible for service mesh and certificates.
- Developers handling sensitive data (PII, credentials, tokens).
Prerequisites
- Basic networking and HTTP knowledge.
- Familiarity with your web server (e.g., Nginx) or load balancer.
- Comfort with a programming language for sample code (any is fine).
Learning path
- Master TLS basics: certificates, chains, host validation.
- Set up HTTPS for public endpoints.
- Add mTLS for internal service-to-service calls.
- Implement at-rest encryption: disk/TDE, then field-level where needed.
- Introduce envelope encryption and automate key rotation.
- Add monitoring and incident runbooks.
Next steps
- Complete the exercises above and validate locally.
- Take the quick test below to lock in concepts.
- Pick one practical project and ship it this week.
Mini challenge
Configure mTLS between two local services and rotate one service certificate without downtime. Prove success by showing both old and new certs can connect during the overlap window, then only the new cert works after cutoff.