# Per-Tenant Encryption Keys — Multi-Tenant SaaS Architecture

Source: https://www.skillbyai.com/en/multi-tenant-saas/mt-tenant-encryption-keys

> Explain envelope encryption with per-tenant keys, customer-managed keys and crypto-shredding, and what they do and do not protect against.

## Envelope encryption, one key per tenant

Cloud databases and disks are normally encrypted at rest already, but with keys the provider or platform controls for everyone. Some tenants want more: their data encrypted under a key that is theirs alone. The standard technique is **envelope encryption**. Data is encrypted with a **data key**; the data key is itself encrypted ("wrapped") by a **key-encryption key** held in a key management service (KMS) or HSM, which never releases it in plain form. With a key-encryption key per tenant, you get useful properties: access to that key can be audited per tenant, a customer can hold or control the key in their own KMS (**customer-managed keys**) and revoke it, and destroying it makes that tenant's data unreadable everywhere, backups included (**crypto-shredding**). Know the limit too: encryption at rest does not stop your own application, which can decrypt, from leaking data through a missing tenant filter.

## Envelope encryption per tenant

Plain data is encrypted with a data key, the data key is wrapped by the tenant's key-encryption key in the KMS, and only the wrapped key is stored next to the ciphertext.

![Four stages: plaintext tenant data, encryption with a data key, wrapping of the data key by the tenant's KMS key, storage of ciphertext with the wrapped key.](assets/figures/multi-tenant-saas/section-9-map.svg) — Figure 9.1: tenant data -> encrypt with data key -> wrap data key with tenant KMS key -> store ciphertext + wrapped key

## Locker and master key

Each family's valuables go in a box with its own small key (the data key). That small key is kept inside a bank locker that only the family's master key opens (the key-encryption key). Throw away the master key and every box becomes useless, wherever copies of it were stored.

## Know the cost of per-tenant keys

KMS calls add latency and usually cost money per request, so systems cache unwrapped data keys in memory for a short time. If a customer revokes their key, your service will fail for that tenant, so build clear error handling and alerts for that case.

**Quiz:** A customer revokes the customer-managed key used for their tenant. What is the expected effect?

- [ ] Nothing changes until the next deployment
- [x] The platform can no longer decrypt that tenant's data, so access to it fails
- [ ] All tenants on the same shard lose access
- [ ] The data is automatically re-encrypted with a platform key

*Answer:* The platform can no longer decrypt that tenant's data, so access to it fails. Revoking the key-encryption key means wrapped data keys can no longer be unwrapped, so that tenant's data becomes unreadable. Other tenants use different keys and are unaffected.