Data protection: KMS, envelope encryption, tokenisation

Classify, minimise, encrypt, tokenise. Designing data protection that satisfies auditors without slowing the product down.

🔒 PROLesson·14 min read·Intermediate → Advanced

KMSencryptiontokenisationDLP

01Four levels of protection

✓What you will learn

Apply classification tiers to pick controls
Explain envelope encryption and implement it against a cloud KMS
Use encryption context to bind ciphertext to its owner and make the audit log useful
Compare encryption at rest, field-level encryption and tokenisation
Design for crypto-shredding and data residency without surprises in the backups

Start with classification, because it decides how much encryption tax you pay and where. A workable scheme has four tiers: public, internal, confidential (customer data, most PII) and restricted (card numbers, government IDs, health data, secrets). Each tier maps to a minimum control, so engineers pick from a table instead of debating each column.

Level	Protects against	Does not protect against	Example
Disk / volume encryption	Stolen disks, decommissioned hardware	Anyone with DB access	EBS, PD encryption
Database TDE	File-level theft, backups	Application-level compromise	RDS/Cloud SQL with CMK
Field-level encryption	DBA and most app bugs reading the field	Compromise of the service holding the DEK	PAN, SSN encrypted with per-tenant DEK
Tokenisation	Everything downstream: token is useless outside the vault	Compromise of the vault	Payment tokens, PII vault

Volume encryption is table stakes and satisfies almost nothing a real threat model cares about, because the database decrypts transparently for anyone who can query it. The decisions that matter are which fields get field-level encryption or tokenisation, and who holds the keys.