Multi-Tenant bedeutet geteiltes Schicksal: Das verborgene Risiko regionaler Cloud-Hosting-Lösungen für regulierte Daten

Wichtige Erkenntnisse

1. Geteilte Infrastruktur bedeutet geteiltes Schicksal. Multi-Tenant-Plattformen nutzen gemeinsame Datenbanken, Runtimes und Betriebssysteme für Tausende von Kunden, wobei die Trennung lediglich durch Softwarelogik und nicht durch physische Grenzen erfolgt.
2. Ein einziger Exploit kann alle Mandanten betreffen. Eine Schwachstelle oder Fehlkonfiguration in der gemeinsamen Schicht kann sämtliche Kunden auf der Plattform gefährden und den Schaden weit über das ursprünglich betroffene Konto hinaus ausweiten.
3. Regional gehostet ändert nichts am Teilen. Datenresidenz-Labels verändern die zugrunde liegende Multi-Tenant-Architektur nicht, da regionale Bereitstellungen in der Regel weiterhin Datenbanken und administrativen Zugriff global teilen.
4. Single-Tenant beseitigt geteiltes Risiko. Dedizierte Datenbanken, Runtimes und gezielter Admin-Zugriff stellen sicher, dass die Gefährdung eines Kunden nicht auf andere übergreift und das geteilte Schicksal auf Infrastrukturebene entfällt.

Einleitung

Eine Multi-Tenant-Cloud-Plattform betreibt Tausende von Kunden auf denselben zugrunde liegenden Datenbanken, Anwendungs-Runtimes und Betriebssystemen, getrennt nur durch Softwarelogik statt durch physische Grenzen. Die meisten Unternehmenskunden akzeptieren diesen Kompromiss, ohne ihn genau zu hinterfragen, da Multi-Tenancy die Standardarchitektur hinter fast jedem gängigen SaaS-Produkt ist.

Dieser Kompromiss hat einen Namen, der in Marketingmaterialien der Anbieter selten auftaucht: geteiltes Schicksal. Wird Infrastruktur geteilt, gilt das auch für die Gefährdung. Eine einzige ausgenutzte Schwachstelle, eine falsch konfigurierte Berechtigung oder ein kompromittiertes Zugangskonto bleibt nicht auf die Daten eines einzelnen Kunden beschränkt. Sie kann alle Mandanten auf derselben gemeinsamen Schicht erreichen – unabhängig davon, unter welcher Landesflagge das Rechenzentrum läuft. Dieser Artikel beleuchtet, was Multi-Tenancy tatsächlich unter der Oberfläche eines Anbieters teilt und warum regulierte Unternehmen das Tenancy-Modell genauso sorgfältig prüfen sollten wie den Standort.

Erkenntnis 1: Multi-Tenant-Plattformen teilen Datenbanken, Runtimes und Betriebssysteme über Tausende von Kunden hinweg. Die Trennung erfolgt durch Softwarelogik, nicht durch physisch getrennte Infrastruktur.

Erkenntnis 2: Eine einzige Schwachstelle mit Mandanten-übergreifender Wirkung kann viele Kunden gleichzeitig gefährden. Der Schaden einer Multi-Tenant-Panne erstreckt sich auf jedes Unternehmen, das diese Infrastrukturschicht nutzt.

Erkenntnis 3: Ein regionales Hosting-Label beseitigt die Multi-Tenant-Gefährdung nicht. Regionale Bereitstellungen einer globalen Plattform teilen in der Regel weiterhin Datenbanken, Administrationskonsolen und Support-Zugänge mit dem weltweiten Betrieb des Anbieters.

Erkenntnis 4: Administrations- und Support-Zugänge stellen eine versteckte Angriffsfläche dar. Multi-Tenant-Anbieter behalten routinemäßig dauerhaften operativen Zugriff auf Kundenumgebungen, was regulierte Unternehmen selten hinterfragen.

Erkenntnis 5: Single-Tenant-Architektur beseitigt das geteilte Risiko auf Infrastrukturebene. Dedizierte Datenbanken, Dateisysteme und Runtimes verhindern, dass die Gefährdung eines Kunden zum Vorfall bei einem anderen wird.

Management Summary

Multi-Tenancy ist für Cloud-Anbieter ein effizientes Modell, für deren Kunden jedoch eine Risikokonzentration. Da Tausende von Unternehmen dieselben Datenbanken, Runtimes und Administrationswerkzeuge nutzen, kann ein einziger Fehler in dieser gemeinsamen Schicht weitreichende Folgen haben – weit über den Kunden hinaus, bei dem er zuerst entdeckt wurde. Für Unternehmensrisiko- und Compliance-Teams bedeutet das: Das Tenancy-Modell verdient die gleiche Aufmerksamkeit wie Verschlüsselung, Zugriffskontrolle oder Standort. Die Zusicherung eines Anbieters, dass Daten „regional gehostet“ werden, sagt nichts darüber aus, ob die zugrunde liegende Plattform weiterhin grundsätzlich geteilt ist. Zu verstehen, wo das Teilen tatsächlich stattfindet und was es offenlegt, ist der erste Schritt, um diese Lücke zu schließen.

Was Multi-Tenancy tatsächlich unter der Oberfläche teilt

Cloud-Anbieter beschreiben Multi-Tenancy selten in Begriffen, wie sie eine Unternehmensrisikofunktion verwenden würde. Die Außendarstellung dreht sich meist um Elastizität, Kosteneffizienz und schnelle Bereitstellung. Die architektonische Realität ist, dass ein einziger Satz von Datenbanken, Anwendungs-Runtimes und Betriebssystemen alle Kunden auf der Plattform gleichzeitig bedient, wobei Mandantengrenzen ausschließlich softwarebasiert durchgesetzt werden.

Die Effizienzlogik hinter Multi-Tenant-Design

Multi-Tenant-Architektur existiert, weil sie für den Anbieter tatsächlich effizient ist. Eine Infrastruktur bedient viele Kunden, verteilt Betriebskosten, vereinfacht Wartung und ermöglicht schnelles Skalieren, ohne für jedes Konto dedizierte Ressourcen bereitzustellen. Das ist eine nachvollziehbare wirtschaftliche Entscheidung für den Anbieter. Ob diese Effizienzlogik auch zum Risikoprofil eines Unternehmens mit regulierten Daten passt, ist jedoch eine ganz andere Frage – und sollte nicht verwechselt werden, nur weil das Preismodell eines Anbieters davon abhängt.

Was Regionalität wirklich ändert – und was nicht

Eine regionale Hosting-Option ändert in der Regel nur, wo die Daten eines Kunden im ruhenden Zustand gespeichert werden – also die Frage der Datenresidenz. Sie ändert jedoch meist nichts an der zugrunde liegenden Plattformarchitektur. Die meisten regionalen Bereitstellungen eines globalen Multi-Tenant-Produkts laufen weiterhin auf gemeinsamen Datenbanken, gemeinsamen Anwendungs-Runtimes und gemeinsamen Administrationskonsolen, die den gesamten weltweiten Betrieb des Anbieters abdecken. Das Regional-Label beantwortet eine geografische Frage. Die Frage nach dem Teilen – und damit nach der tatsächlichen Gefährdung – bleibt offen.

Wie geteilte Infrastruktur zum geteilten Risiko wird

Die praktische Folge geteilter Infrastruktur ist, dass Sicherheitsvorfälle Kundenabgrenzungen nicht so respektieren, wie es Verträge suggerieren. Sobald ein Angreifer oder eine Fehlkonfiguration die gemeinsame Schicht erreicht, folgt die Gefährdung der Architektur – nicht der Kontenstruktur.

Blast Radius: Wenn ein Exploit viele Kunden trifft

In einer Single-Tenant-Umgebung bleibt eine Schwachstelle in der Instanz eines Kunden definitionsgemäß auf diese Instanz beschränkt. In einer Multi-Tenant-Umgebung kann eine Schwachstelle in der gemeinsamen Datenbankschicht, im gemeinsamen Runtime-Stack oder in der gemeinsamen Identitäts- und Zugriffsverwaltung potenziell alle Mandanten betreffen, die diese Schicht zum Zeitpunkt des Angriffs nutzen. Öffentlich bekannt gewordene Multi-Tenant-Cloud-Sicherheitsvorfälle zeigen dieses Muster immer wieder: Schwachstellen in gemeinsamen Infrastrukturschichten haben Mandanten-übergreifende Auswirkungen, die weit über das ursprünglich betroffene Konto hinausgehen. Für regulierte Unternehmen verschiebt sich damit die Fragestellung von „Wie wahrscheinlich ist ein Vorfall mit unseren Daten?“ zu „Wie wahrscheinlich ist ein Vorfall mit der Plattform – und was bedeutet das für uns, unabhängig von unserer eigenen Sicherheitslage?“

Administrations- und Support-Zugänge als versteckte Angriffsfläche

Geteilte Infrastruktur bringt meist auch geteilte Administrationswerkzeuge mit sich. Das bedeutet, dass eine bestimmte Personengruppe – ob Mitarbeiter des Anbieters oder automatisierte Systeme im Auftrag des Anbieters – dauerhaften Zugriff auf viele Kundenumgebungen gleichzeitig behält. Dieser Zugriff ist in Sicherheitsprüfungen, die sich auf die eigene Konfiguration des Kunden konzentrieren, selten sichtbar, da er vollständig auf der Seite des Anbieters liegt. Unternehmen, die einen Multi-Tenant-Anbieter evaluieren, sollten daher nicht nur fragen, wie ihre eigenen Daten geschützt sind, sondern auch, wer sonst und was sonst einen dauerhaften Zugang zu der Schicht hat, in der diese Daten liegen.

Warum das Tenancy-Modell in die Risikoabwägung von Unternehmen gehört

Wer Standort und Tenancy gleichsetzt, führt Risiko- und Compliance-Teams dazu, eine Anbieterprüfung nach Bestätigung des Rechenzentrumsstandorts abzuschließen, ohne je zu fragen, ob dieses Rechenzentrum einem oder Tausenden von Kunden dient. Beide Fragen erfordern unterschiedliche Nachweise: Der Standort wird durch einen Hosting-Vertrag belegt. Das Tenancy-Modell lässt sich durch Architekturdokumentation nachweisen, die zeigt, ob Datenbanken, Dateisysteme, Runtimes und Betriebssysteme dediziert oder geteilt sind – und ob Administrations- und Support-Zugänge auf einen einzelnen Kunden beschränkt oder auf die gesamte Plattform des Anbieters ausgedehnt sind. Wird das Tenancy-Modell in die Risikoanalyse von Anbietern aufgenommen – neben Verschlüsselung und Zugriffskontrolle – schließt das eine Lücke, die eine reine Standortprüfung regelmäßig offenlässt.

Wie eine Data Control Plane das geteilte Risiko aus der Architektur entfernt

Um das geteilte Risiko zu vermeiden, muss ein Unternehmen keine eigene Infrastruktur aufbauen und betreiben. Entscheidend ist, eine Plattform zu wählen, bei der Mandantentrennung ein architektonisches Merkmal ist – und nicht eine Softwaregrenze, die über geteilte Ressourcen gelegt wird. Die Governance sensibler Daten muss dabei unabhängig vom Übertragungskanal konsistent durchgesetzt werden. Genau dafür ist eine Data Control Plane konzipiert: Sie bildet eine Governance-Schicht über alle Kanäle hinweg, über die Daten fließen – einschließlich E-Mail, Filesharing, APIs und KI-Agents – und steuert, wer unter welchen Bedingungen auf sensible Daten zugreifen, sie senden, teilen oder verschieben darf. Die Infrastrukturgrenzen kontrolliert dabei das Unternehmen selbst.

Kiteworks basiert von Grund auf auf Single-Tenant-Architektur, ohne jegliches Teilen von Datenbanken, Dateisystemen, Anwendungs-Runtimes oder Betriebssystemen zwischen Kunden. Unternehmen setzen die Lösung auf ihrer eigenen Infrastruktur ein – vollständig On-Premises, selbst gehostet in der eigenen Cloud-Tenancy oder als dedizierte gehostete Instanz. Administrations- und Support-Zugänge sind ausschließlich auf diese Instanz und diesen Kunden beschränkt – und nicht auf eine geteilte globale Plattform ausgedehnt. Auf diesem isolierten Fundament steuern datenbewusste, zero-trust-Kontrollen jeden Versand, jedes Teilen und jeden Zugriff über alle Kanäle hinweg. Jede Aktion wird in einem manipulationssicheren, ungedrosselten Audit-Trail erfasst, der direkt in SIEM-Tools eingespeist wird. So erhalten Security- und Compliance-Teams Belege für die Durchsetzung – statt sich auf die Zusicherung des Anbieters verlassen zu müssen, dass geteilte Infrastruktur ausreichend segmentiert ist. Damit wird das Tenancy-Modell selbst zu einer Kontrollmöglichkeit des Unternehmens – und nicht zu einem Risiko, das es aus der Kostenstruktur des Anbieters übernimmt.

Unternehmen, die wissen möchten, was Single-Tenant-Architektur für ihre regulierten Umgebungen bedeutet, können get back in CTRL – und erleben, wie sich eine dedizierte Data Control Plane im Vergleich zur aktuellen Plattform schlägt.