Multi-Tenant-SaaS: Isolation und Architekturentscheidungen

Vergleichen Sie gemeinsame und getrennte Ressourcen für Daten, Jobs und Betrieb. Machen Sie Mandantentrennung neben Authentifizierung ausdrücklich.

Drei getrennte dunkle Mandantenkammern an einer gemeinsamen Dienstestruktur.

Multi-Tenancy lässt mehrere Kundenorganisationen einen Dienst nutzen. Entscheidend ist, wo Ressourcen geteilt und Zugriff sowie Last begrenzt werden. Authentifizierung sagt, wer anfragt, nicht automatisch welche Mandantenressourcen erlaubt sind. Isolation muss jeden Pfad umfassen, einschließlich Support und Hintergrundverarbeitung.

Grenzen aus Anforderungen ableiten

Modell	Möglicher Vorteil	Betriebsfrage
Gemeinsame Tabellen mit Mandantenkennung	Effizienz und gemeinsame Migration	Wie wird Filterung überall erzwungen?
Separate Schemas oder Datenbanken	Klarere Datengrenze	Wie Migrationen und Backups skalieren?
Separate Deployments	Unabhängige Kapazität	Wie die wachsende Flotte betreiben?

Modelle können kombiniert werden. Gemeinsame Steuerung und isolierte Speziallast sind möglich, wenn begründet. Dokumentieren Sie Grund und Auswahl beim Provisionieren. Getrennte Datenbanken garantieren keine Isolation, wenn Zugangsdaten, Support oder Exporte unkontrolliert Grenzen überschreiten.

Vertrauenswürdigen Kontext weitergeben

Ermitteln Sie Mitgliedschaft und Rechte serverseitig. Eine übermittelte Mandantenkennung beweist keine Berechtigung. Führen Sie Kontext in Jobs, Cache-Schlüsseln, Dateipfaden und Auditdaten und validieren ihn beim Zugriff. Prüfen Sie mandantenübergreifende Administration separat und begrenzen sie auf ausdrückliche Zwecke.

Testkonten in zwei Mandanten mit getrennten Daten erstellen.
Lesen, Schreiben, Export und Dateien nach Rolle prüfen.
Jobs und Cache bei Kontextwechsel testen.
Akteur, Mandant und Supportzweck protokollieren.
Wiederherstellung und Löschung entlang der Grenze üben.

Auch Lastisolation prüfen

Ein großer Import kann andere Kunden verlangsamen, ohne Daten offenzulegen. Nutzen Sie Quoten, Planung oder Trennung und messen repräsentative Last. Halten Sie Mandanteninventar und Provisionierung versioniert, um unsichtbare Ausnahmen zu vermeiden. Überprüfen Sie Entscheidungen bei veränderten Kundenanforderungen.

Bewahren Sie Nachweise nach Pfad und Rolle. Ein Einzeltest beweist nicht das gesamte System. Eine gemeinsame Datenbank wiederherzustellen hat andere Folgen als einen Mandanten; Betreiber müssen das verstehen. Datenschutzgrenzen und stabile Leistung hängen zusammen, brauchen aber jeweils eigene Prüfungen.

Häufige Fragen

Genügt eine Kennung pro Tabelle?

Nein. Abfragen, Jobs, Cache, Dateien und Administration müssen vertrauenswürdigen Kontext anwenden.

Braucht jeder Mandant eine Datenbank?

Nicht immer. Entscheiden Sie nach Isolation, Wiederherstellung, Skalierung und Betrieb.

Ersetzt Trennung Autorisierung?

Nein. Anwendung und Betrieb brauchen weiterhin kontrollierte Rechte und Zugangsdaten.

Wie testen wir Isolation?

Mit autorisierten getrennten Testkonten für Lesen, Schreiben, Export, Jobs und Privilegien.

Was ist ein Noisy Neighbour?

Ein Mandant beansprucht gemeinsame Kapazität und beeinträchtigt andere auch ohne Datenleck.

Vom Vorhaben zu einem umsetzbaren Umfang

Teilen Sie Nutzerablauf, Schnittstellen und Rahmenbedingungen. Gemeinsam klären wir den Umfang und erstellen eine Schätzung mit Annahmen und Ausschlüssen.

Leistungsumfang ansehen →