Protecting data in transit, at rest and in backups
Encryption is not a checkbox; it is a decision about who holds the key.
What you will be able to do
- Explain what TLS protects and what it does not
- Choose between hashing, encryption and tokenisation
- Design key rotation without downtime
- Reduce blast radius by minimising stored data
Transit
TLS terminates somewhere: at the load balancer, at the gateway, or inside each service. Once terminated, traffic inside the network is plaintext unless you re-encrypt. Most designs assume a trusted network and terminate at the edge; regulated data usually calls for mTLS between services so a compromised host cannot sniff the mesh.
- Certificates need lifecycle. Automated issuance and renewal, with alerts before expiry.
- Redirect and HSTS. Plain HTTP should never serve application data.
- Pin nothing casually. Certificate pinning breaks clients when you rotate; use it only with a rotation plan.
- Do not log headers. Authorization and cookies end up in logs more often than anyone expects.
At rest, and the three techniques
| Technique | Reversible | Use for |
|---|---|---|
| Hashing + salt | No | Passwords, API keys, deduplication fingerprints |
| Encryption (AES-GCM) | Yes, with a key | PII you must display, payment references, messages |
| Tokenisation | Via a vault | Card numbers, SSNs, anything a third party must not hold |
| Field-level encryption | Yes, per field | A few sensitive columns inside an otherwise normal table |
| Full-disk encryption | Transparent | Stolen disks and backups, not application access control |
row: { id, tenant, card_token, last4, created_at }
card_token -> vault/lookup service
vault holds the encrypted PAN under a key that the
application never sees directly (envelope encryption)Tokenisation is the strongest move because it removes the sensitive value from the system that has the most queries and the most bugs. The application stores a reference; the vault handles decryption, access logging and rotation.
Key rotation, briefly
The cheapest protection: not storing it
Every field you keep is a field that can leak, must be encrypted, must be backed up, and must be deleted on request. Ask in the design: do we need the full card number, or the last four and a token? Do we need a precise birth date, or an age band? Minimisation shrinks the blast radius before any cryptography is applied.
Worth remembering
- TLS protects the wire, not the endpoint — a compromised server still sees plaintext.
- Passwords are hashed with a slow algorithm and a per-user salt; they are never encrypted, because you must never need them back.
- Tokenisation replaces sensitive data with a reference, shrinking the scope of what must be encrypted.
- Keys belong in a managed key service with rotation, not in a config file or a repository.