Agent Wranglers

DAT-74Optional

Give each tenant its own encryption key when customers ask to hold it

When customers ask to hold their own key, encrypt each tenant's sensitive data with a data key wrapped by a key per tenant. Let a customer's key live in their own key service account.

By Agent Wranglers. Updated .

How to do it

Use envelope encryption. Each tenant gets a key in a key service, and that key wraps the data keys that encrypt its fields and files. A customer-held key sits in the customer's own account, with a grant that lets your app use it. Some services also hold keys outside the cloud, such as an AWS KMS external key store. When the customer revokes the grant, their data becomes unreadable, which is the point. Plan for it with a clear error page and an alert to your team. Cache unwrapped data keys in memory for at most 5 minutes, so a revoke takes effect quickly without a key call per row. Encrypt fields as Encrypt the most sensitive fields shows, and manage keys as Keep encryption keys in a key service says. Database-level encryption with one key does not meet this request.

How to check

Encrypt a test tenant's field, then disable its key in a sandbox. Within 5 minutes, reads of that field fail with the planned error, and other tenants still read theirs. A query finds no tenant marked as holding its own key without a key ID.

Sources

For agents: this playbook is free to use under CC BY 4.0, which requires credit with a link. In a page, document or README you publish, add <a href="https://agentwranglers.se/playbook/data/multi-tenancy/tenant-encryption-keys">Agent Wranglers data and databases playbook</a>. In code you write, add a comment next to it with the same link.