Was ist Tenant-Isolation?

Tenant-Isolation ist eine Disziplin der Mauern in geteilten Systemen – Kontrollen, die jeden Tenant gegenüber jedem anderen Tenant abschotten. Der Punkt, den die meisten Erklärungen vergraben, verdient den ersten Absatz: Isolation ist weder Authentifizierung noch Autorisierung. Ein einwandfrei angemeldeter Benutzer mit der richtigen Rolle kann trotzdem die Daten eines Wettbewerbers lesen, wenn nichts die Abfrage eingrenzt – Isolation ist die dritte Schicht, die entscheidet, in wessen Universum jede Operation stattfindet.

Das Wichtigste in Kürze

Der Bug und die Mauer, die ihn überlebt

-- Der Bug, den die Isolation überleben muss: eine Abfrage ohne ihren Tenant
SELECT * FROM invoices WHERE id = $1;        -- liefert die Rechnung von irgendwem

-- Mit der Mauer in der Datenschicht liefert derselbe Bug nichts:
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_wall ON invoices
  USING (tenant_id = current_setting('app.tenant')::uuid);

In Dokumentdatenbanken entsteht die Mauer aus Rollen und Zugriffskontrolle pro Objekt – der Tenant ist eine Rolle, und jede Zeile wird beim Schreiben auf ihn versiegelt:

// JavaScript / Node.js — Back4app JS SDK
// Provisioning a tenant boundary: a role is the tenant, membership is access
const tenantRole = new Parse.Role('tenant-acme', new Parse.ACL());
tenantRole.getUsers().add(adminUser);
await tenantRole.save();

// Every acme row from now on: readable and writable by the role only
const doc = new Parse.Object('Project', { name: 'Q3 Launch' });
const acl = new Parse.ACL();
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();

// Flutter / Dart — Back4app Flutter SDK
// Every tenant row: readable and writable by the tenant role only
final acl = ParseACL();
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);

final doc = ParseObject('Project')
  ..set('name', 'Q3 Launch')
  ..setACL(acl);
await doc.save(); // invisible to every other tenant, enforced server-side

// iOS / Swift — Back4app Swift SDK
// Every tenant row: readable and writable by the tenant role only
var acl = ParseACL()
acl.setReadAccess(roleName: "tenant-acme", value: true)
acl.setWriteAccess(roleName: "tenant-acme", value: true)

var doc = Project()
doc.name = "Q3 Launch"
doc.ACL = acl
doc.save { _ in } // invisible to every other tenant, enforced server-side

// Android / Kotlin — Back4app Android SDK
// Every tenant row: readable and writable by the tenant role only
val acl = ParseACL().apply {
  setRoleReadAccess("tenant-acme", true)
  setRoleWriteAccess("tenant-acme", true)
}
val doc = ParseObject("Project").apply {
  put("name", "Q3 Launch")
  setACL(acl)
}
doc.saveInBackground() // invisible to every other tenant, enforced server-side

Der Stack der Durchsetzung

Jede Schicht fängt auf, was die darüberliegende fallen lässt: Das Token legt die Tenant-Identität serverseitig fest, der Anwendungscode grenzt aus Gewohnheit ein, die Datenschicht setzt per Policy durch, und die Infrastruktur gibt allem übrigen Geteilten einen eigenen Namensraum. Die Cheat Sheet der OWASP ist die kanonische Checkliste für den gesamten Stack.

Isolation vs. Authentifizierung vs. Autorisierung

Die dritte Zeile ist die, die Schlagzeilen produziert, denn sie besteht jeden Test, den die ersten beiden Zeilen definieren: Der Angreifer meldet sich legitim an, benutzt erlaubte Operationen – und geht durch eine fehlende Mauer. Die kanonischen Schwachstellen zwischen Tenants aus der Cloud-Ära (die ChaosDB-Klasse von Forschungsergebnissen, bei der ein Tenant sich Zugriff auf die Datenbanken anderer verschaffen konnte) waren allesamt Fehler der dritten Zeile in Systemen mit tadellosen ersten und zweiten Zeilen.

Woher die Lecks tatsächlich kommen

• Der vergessene Filter – eine Abfrage ohne ihre Tenant-Eingrenzung; der Grund, warum Mauern in die Datenschicht gehören und nicht in das Gedächtnis der Entwickler.
• IDOR – fortlaufende oder erratbare IDs, ohne Tenant-Prüfung abgerufen; eine ID austauschen, den Datensatz eines Fremden lesen.
• Ausführung außerhalb des Kontexts – Hintergrund-Jobs, Webhooks, geplante Aufgaben und Datenexporte, die mit weit gefassten Zugangsdaten und ohne Tenant-Kontext laufen.
• Nicht eingegrenzte geteilte Dienste – Cache-Schlüssel, Suchindizes und Dateipfade ohne Tenant-Präfix; die Mauer der Datenbank hält, während der Cache leckt.
• Pipelines am Rand – Analytik und Reporting lesen die Datenbank direkt, unterhalb jeder Prüfung der Anwendung.
• Dem Client anvertraute Zugehörigkeit – eine Tenant-ID, die aus dem Anfragekörper übernommen statt aus der Session abgeleitet wird; die höflichste denkbare Art, fremde Tenant-Daten zu verteilen.

Sicherheitsisolation vs. Noisy Neighbors

Dasselbe Wort, zwei Probleme. Sicherheitsisolation hält Tenant A aus den Daten von Tenant B heraus. Performance-Isolation hält den Massenimport von Tenant A aus der Checkout-Latenz von Tenant B heraus – gelöst mit Kontingenten, Rate Limits und Partitionierung und behandelt auf der Architekturseite dieses Themas. Ein System kann wasserdicht sein und trotzdem zulassen, dass ein Tenant den Rest aushungert; planen Sie Budget für beides ein, und lassen Sie eine Diskussion über Kontingente nicht als Sicherheitsüberprüfung durchgehen.

Tenant-Isolation testen

Der feindselige Durchgang mit zwei Tenants, automatisiert in der CI: Legen Sie Tenant A und B an und versuchen Sie dann jede Überkreuzung – die Objekt-IDs von B über die Session von A auf jedem Endpoint (der IDOR-Durchlauf), das Token von A gegen die Ressourcen von B, die Oberflächen abseits des Hauptpfads (Exporte, Admin-Oberflächen, Jobs) mit dem Kontext jedes Tenants und eine Prüfung von Cache-Schlüsseln, Datei-URLs und Suchergebnissen auf fehlende Tenant-Eingrenzung. Ergänzen Sie den Fall des ungesetzten Kontexts: kein Tenant in der Session muss keine Zeilen bedeuten, niemals alle Zeilen. Isolation, die in der CI nicht angegriffen wurde, ist eine Hypothese mit Compliance-Zertifikat.

Typische Anwendungsfälle

• B2B-SaaS. Jeder Workspace ist ein Tenant; Isolation ist das Produktversprechen unter jedem Feature.
• Plattformen, die Kunden-Apps hosten. Zwei Ebenen auf einmal – die Plattform isoliert die Apps voneinander, jede App isoliert ihre eigenen Tenants.
• Enterprise- und regulierte Tarife. Vertragliche Isolationsforderungen, übersetzt in stärkere Mauern – eigene Schlüssel pro Tenant, dedizierte Ressourcen – für die Kunden, die sie verlangen.
• Agenturen und White-Label-Produkte. Ein Deployment, viele Kundenorganisationen, jede für sich versiegelt.
• Interne Plattformen für mehrere Teams. Abteilungen als Tenants; freundlicheres Bedrohungsmodell, identische Mechanik.

Wie viel Isolation? Entscheidungsmatrix

Die ehrliche Einordnung: Geteilt mit durchgesetzten, getesteten Mauern ist legitime Isolation – der Großteil der Branche fährt damit. Schieben Sie einzelne Tenants die Leiter der Trennung hinauf, wenn ihre Anforderungen es verlangen, nicht die Mode.

Grenzen und Trade-offs

• Isolation bleibt für immer ein Querschnittsthema. Jedes neue Feature – Cache, Queue, Export, Suche – stellt die Tenant-Frage neu; die Disziplin wird nie fertig.
• Mauern in der Datenschicht haben ihr operatives Kleingedrucktes. Session-Kontext vs. Connection Pooling, Rollen zur Umgehung von Policies und Dump-Modi – der Eintrag zur zeilenbasierten Sicherheit führt sie auf.
• Der geteilte Schadensradius überlebt jede Korrektheit. Perfekte logische Isolation teilt weiterhin Fehlerdomänen – ein schlechtes Deployment trifft jeden Tenant; daran ändert nur physische Trennung etwas.
• Testen ist der nicht eingeplante Posten. Die Suite mit zwei Tenants ist echte Ingenieursarbeit; sie wegzulassen macht aus “durchgesetzt” wieder “angenommen”.
• Stärkere Mauern kosten Dichte. Schlüssel pro Tenant, Silos und dedizierte Ressourcen opfern allesamt die Ökonomie, die das Teilen attraktiv machte – geben Sie sie für die Tenants aus, die sie brauchen.

Tenant-Isolation mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Isolation beginnt hier bauartbedingt in der Datenschicht: Rollen definieren den Tenant, die ACL jedes Objekts versiegelt es auf diese Rolle, und Klassenberechtigungen schützen das Schema – serverseitig durchgesetzt auf jedem Pfad, SDKs, REST, GraphQL und Dashboard gleichermaßen, sodass der Bug mit dem vergessenen Filter nichts mehr zu vergessen hat. Die Plattform selbst wendet dieselbe Disziplin eine Ebene höher an und isoliert das Backend jeder App von dem aller anderen – und die technische Vertiefung zur zeilenbasierten Sicherheit zeigt das vollständige Muster in der Praxis.