Introduction: From “All or Nothing” Breaches to Bounded Blast Radius
Modern SaaS platforms sit on top of massive, multi-tenant data stores. When those stores are breached, the damage is rarely limited to a single record; it is often “wholesale” compromise of large slices of the user base. For a CISO or CTO, this is the critical risk: not that a record can be stolen, but that everything a given system knows becomes available in one incident.
Cloud providers and SaaS security guidance have converged on a simple principle: design for tenant isolation and blast radius reduction. You assume compromise is possible and work to ensure that any single failure affects as few tenants and as little data as possible, instead of the entire corpus. AWS Documentation
Database and infrastructure sharding emerged first as a scalability technique, but security literature increasingly frames sharding as a way to structurally prevent widespread data compromise, especially in multi-tenant SaaS. Amazon Web Services, Inc.+1
This article explains how sharding can be used as a deliberate security strategy and then introduces Mimir’s “Shard on User Access” model: a data-in-use protection paradigm where the server never has enough context (cryptographically or structurally) to “monkey-branch” from authorized data into data the user is not allowed to see.
1. Blast Radius as a First-Class Security Objective
Traditional access control focuses on whether a principal is allowed to access a resource. Blast-radius thinking focuses on how much can go wrong if that principal—or the infrastructure around it—is compromised.
Zero Trust guidance from major vendors emphasizes three recurring themes:
Explicit verification of identity and context. Least-privilege access aligned to business roles. Assume breach and limit impact, often described explicitly as reducing the “blast radius.”
From a data perspective, this means:
... continue reading