How do you design time partitioning (by day/hour) for large datasets?

Per tenant encryption at rest with BYOK (Bring Your Own Key) ensures every customer owns and controls their own encryption key while your system manages secure data storage and retrieval. This design not only improves trust and compliance but also strengthens isolation between tenants in a multi tenant SaaS platform.

Introduction

Bring Your Own Key allows each customer to supply or control their encryption key through their own cloud KMS or HSM. Your application encrypts data using tenant specific data keys, which are themselves wrapped with the customer’s key. This model enforces strong boundaries between tenants, enabling immediate revocation or rotation of keys when needed.

Why It Matters

BYOK enhances customer trust, supports enterprise compliance, and improves security posture by delegating key ownership to tenants. It’s frequently discussed in system design interviews because it demonstrates understanding of key hierarchies, data control, and how to balance performance with security in distributed systems.

How It Works (Step-by-Step)

1. Key Hierarchy

• The tenant manages a root key in their KMS or HSM.
• Your system generates a unique data key for encrypting the tenant’s data.
• The data key is wrapped (encrypted) using the tenant’s root key and stored securely with metadata.

2. Tenant Onboarding

• Tenant registers their key reference (KMS ARN or URI).
• Ownership verification occurs via a challenge decrypt or signed attestation.
• Only key references are stored—never plaintext keys.

3. Write Path

• Generate or retrieve a data key for the tenant.
• Encrypt data using AES 256 GCM (object level) or AES 256 XTS (disk level).
• Wrap the data key using the tenant’s root key and store it with the encrypted data.
• Record audit logs for traceability.

4. Read Path

• Retrieve the encrypted data and its metadata.
• Check in memory cache for unwrapped data keys (short TTL).
• If missing, call tenant’s KMS to unwrap.
• Decrypt and verify data before returning it.

5. Rotation and Rewrap

• Data key rotation: Generate a new data key for future writes.
• Root key rotation: Rewrap existing wrapped keys using the new root key.
• Use lazy rewrap—perform rewrap on read to avoid downtime.

6. Revocation and Offboarding

• Tenant disables or deletes the root key.
• Your system must fail closed—denying reads and evicting caches immediately.
• Recovery only occurs if the tenant restores decrypt permissions.

7. Performance Optimization

• Cache unwrapped data keys securely in memory.
• Use short TTLs and purge on key rotation events.
• Batch KMS requests and asynchronous rewrap jobs to minimize latency.

8. Multi Region Handling

• Store encrypted data globally but decrypt only in the same region as the tenant key.
• Use local KMS calls for compliance and latency efficiency.
• Implement safe fallback for regional outages using cached keys with strict TTL.

9. Auditing and Access Control

• Tie encrypt/decrypt permissions to service roles scoped per tenant.
• Maintain immutable logs for every cryptographic action with key ID and tenant ID.

Real World Example

Consider a SaaS file storage service like Dropbox Business. Each customer manages their own key through AWS KMS or Azure Key Vault. Files are encrypted using tenant data keys, and metadata includes the wrapped data key and tenant ID. When the tenant rotates or revokes their KMS key, new files use updated keys, and old ones become unreadable until rewrap. This model satisfies strict compliance (GDPR, HIPAA) while allowing immediate access control by the tenant.