Tenant Isolation in Multi-Tenant Systems

The Isolation Problem in Shared Infrastructure

When multiple organisations share the same infrastructure, isolation is the contractual and technical guarantee that one tenant's data cannot be accessed, disrupted, or compromised by another tenant. In physical isolation, this guarantee is trivially provided — separate servers, separate databases, separate networks. In logical isolation (shared infrastructure with software-enforced boundaries), the guarantee depends entirely on the correctness and robustness of the isolation implementation.

Salesforce operates on logical isolation by default. Your data shares the same Oracle RAC database instances, the same application servers, and the same network infrastructure as your competitors' Salesforce orgs. The separation between your data and theirs is enforced by Salesforce's application layer — primarily through the universal OrgId discriminator and Governor Limits. Understanding how this works architecturally is essential for any honest security assessment of Salesforce as a platform for sensitive data.

Database Layer: How OrgId Enforces Isolation

The foundation of Salesforce's tenant isolation is the OrgId — a unique 15-character identifier assigned to each Salesforce organisation. Every row in every Salesforce database table includes an OrgId column. Every SOQL query executed in any context automatically includes an OrgId filter, enforced by the application layer before the query reaches the database engine.

The mechanism is not optional and cannot be bypassed through standard API or application means. When an Apex developer writes SELECT Id FROM Account, Salesforce's query engine translates this to include WHERE OrgId = 'YOUR_ORG_ID' before execution. The developer never writes the OrgId filter — the platform enforces it transparently. This is the core data isolation mechanism.

-- What a developer writes in SOQL:
SELECT Id, Name, AnnualRevenue
FROM   Account
WHERE  Industry = 'Technology'

-- What Salesforce actually executes against the shared database:
-- (simplified representation of internal query transformation)
SELECT Id, Name, AnnualRevenue
FROM   sf_core_objects
WHERE  org_id    = '00D1X000000XxXxXAX'   -- always injected
AND    type_name = 'Account'
AND    Industry  = 'Technology'

-- No SOQL query can return records from a different org
-- because the org_id filter is enforced at the platform level,
-- not the application code level

The database layer also enforces isolation at the DML level — inserts, updates, and deletes are similarly scoped to the issuing org's OrgId. A rogue Apex transaction that attempts to write to another org's data would require a vulnerability in the platform's OrgId enforcement, not just in the Apex code.

Compute Isolation: Governor Limits as the Security Boundary

Data isolation prevents one tenant's data from being read by another. Compute isolation prevents one tenant's code from consuming shared resources in ways that degrade other tenants' performance — or from using compute resources to probe the isolation boundary itself.

Governor Limits are Salesforce's primary compute isolation mechanism. The 10,000ms CPU limit per transaction, the 6MB heap limit, the 100 SOQL query limit — these prevent any single tenant's code from monopolising the shared application server's resources. They also prevent attacks that would require sustained compute access to succeed (e.g. timing-based attacks against the OrgId enforcement layer).

What Governs the Governor Limits Themselves

Governor Limits are enforced by a Salesforce runtime wrapper around the Apex execution environment. The wrapper instruments every query, DML operation, and memory allocation, and terminates the transaction when any limit is exceeded. This enforcement happens in the application server layer, before any database interaction — it's not enforced at the JVM level or the OS level, which has implications for certain security threat models.

Network and API Isolation

Salesforce provides network-level isolation for inbound traffic via its pod architecture. Each Salesforce instance (NA1, EU10, etc.) serves multiple tenants but maintains separate API endpoints per org (org-specific instance URL). Outbound API calls from Apex are subject to the same Governor Limits as other operations (callout timeout, number of callouts per transaction).

For organisations with strict network isolation requirements, Salesforce Private Connect provides a private network path between your infrastructure and Salesforce via AWS PrivateLink — data travels between your AWS VPC and Salesforce's infrastructure without traversing the public internet. This addresses network-layer isolation concerns for organisations where public internet transmission of sensitive data is a compliance concern, even when the data is encrypted in transit.

Historical Cases Where Isolation Was Imperfect

No system as complex as Salesforce has a perfect isolation track record. Understanding the historical cases where isolation boundaries were breached — and how Salesforce responded — is important context for a security assessment.

Salesforce has experienced incidents where metadata changes (not data access) propagated across tenant boundaries due to caching bugs. These incidents, disclosed via trust.salesforce.com, resulted in tenants seeing configuration from other orgs in their metadata cache. Salesforce's response was to improve cache invalidation logic and add additional cross-org validation at cache entry boundaries.

The pattern: Salesforce's isolation failures have historically been at the metadata/configuration layer, not the data layer. The OrgId enforcement at the data layer has been robust; the more complex caching and configuration management layers have occasionally had bugs that caused cross-tenant visibility of non-sensitive metadata. For data confidentiality assessments, this distinction matters.

Physical Isolation Options

For organisations where logical isolation is insufficient — typically due to regulatory requirements that mandate physical separation rather than technical equivalence — Salesforce offers two primary options.

Salesforce Hyperforce enables Salesforce to be deployed on a customer's preferred hyperscaler (AWS, Azure, GCP) within a specific geographic region. Data residency is guaranteed within the specified region. Compute and storage infrastructure is dedicated to the Salesforce Hyperforce deployment, providing physical separation from the standard multi-tenant infrastructure.

Government Cloud Plus is Salesforce's FedRAMP High-authorised environment for US federal agencies and their contractors. It runs on dedicated, physically isolated infrastructure with personnel security requirements (US persons only). It provides the physical isolation that certain federal data classification requirements mandate.

Both options carry significant cost premiums and impose some capability constraints (not all Salesforce products are available on Government Cloud). The decision to require physical isolation should be driven by genuine regulatory requirements, not by a general preference for "more security" — the cost-benefit calculation changes significantly when physical isolation is mandated by regulation vs chosen voluntarily.

What This Means for Your Data Security Assessment

A Salesforce data security assessment should cover three distinct questions: Is the isolation model technically sufficient for our data classification? Is Salesforce's implementation of that isolation model verified by independent audit? And does our regulatory framework require physical isolation or is logical isolation acceptable?

For the first question: Salesforce's logical isolation model is technically sufficient for most commercial data classifications, including personal data under GDPR, financial data under PCI-DSS (with appropriate configuration), and healthcare data under HIPAA (under Salesforce's BAA). The model has been independently audited under SOC 1, SOC 2, ISO 27001, and multiple other frameworks.

For the third question: regulatory requirements vary. Some frameworks require physical isolation; most accept technically equivalent logical isolation with independent audit. Work with your legal and compliance functions on this question — it's a regulatory interpretation question, not an architectural question.