Skip to content
The Data EngineeringThe Data EngineeringBeta
About
Main content

Egress, exfiltration and multi-tenancy

What happens to data after an authorized read, and how do tenants leak to each other?

Egress and exfiltration

answers may this read? It says nothing about the copy that comes after, and the copy is the loss event. Real is overwhelmingly an authorized read followed by an unmonitored export, exactly the USB drive in Wei's review.

The mechanisms are all borrowed from other parts of the platform and all sit outside the security subsystem:

  • result-set governors and row limits (resource-governance tools used for a security purpose);
  • export and download restrictions in the BI tool and notebook surfaces;
  • network perimeters around the data plane, so work only from inside;
  • volume anomaly detection on read patterns.

They are weak almost everywhere for one reason. Each one blocks a legitimate workflow every day and prevents a loss once a decade. That is the law of , with an unusually bad ratio of daily cost to rare benefit.

The point to keep: access control divides the world into people who may read and people who may not. It never creates a group of people who can read but cannot copy. That group does not exist without an mechanism, and most platforms have none.

Multi-tenancy as a confidentiality boundary

A tenant is one customer, department or team sharing the platform. In performance engineering, tenant isolation is about noisy neighbours, quotas and fairness. The confidentiality version is a different problem with a different failure mode: shared compute, shared caches, shared metadata and shared query history leak across tenants through channels that carry no data in the usual sense.

Most of these leaks are (information leaking through behaviour instead of through the data itself):

  • Timing. A fast answer shows that a cached result existed, which shows that another tenant ran the same query.
  • Result-cache keys without the security context. The cache serves one tenant's rows to another. This is a real and repeated class of bug, and it is the second fault in Wei's review: the key was the query text only. A safe key must include the identity, role and policy version, for example hash(query_text, user_roles, policy_version).
  • Error messages that reveal that an object exists, when the caller may not read it ("table patients_oncology access denied" versus "table not found").
  • Shared statistics and metadata that reveal and shape.
  • Per-tenant encryption keys help only if the decryption boundary is also per tenant.

The isolation ladder is familiar: shared process, shared cluster with separate processes, separate cluster, separate account. The cost is the isolation-versus-utilization axis, paid in money (the more you separate, the more idle capacity you pay for). The rule: anything shared between tenants is a channel between tenants, including things that carry only timing.