Die Entscheidung, wie die Daten der einzelnen Kunden gespeichert werden, ist eine Architekturfrage mit Folgen für Sicherheit, Betrieb und Weiterentwicklung des Produkts. Bei einem mandantenfähigen SaaS reicht es nicht, jedem Nutzer eine andere Oberfläche anzuzeigen: Das System muss kontrollieren, welche Daten ein Kunde abrufen und ändern darf – auch bei Programmierfehlern, Hintergrundaufgaben oder Konfigurationsänderungen.
Es gibt kein Modell, das grundsätzlich für alle Fälle am besten geeignet ist. Eine gemeinsame Datenbank kann den Betrieb vereinfachen, während eine dedizierte Datenbank bestimmte Anforderungen an die Isolierung leichter erfüllen kann. Sie bringt jedoch auch mehr Betriebsaufgaben und Kosten mit sich. Die passende Entscheidung hängt davon ab, welches Risiko reduziert werden soll, welche Zusagen gegenüber Kunden gelten und welche Architektur das Team tatsächlich zuverlässig betreiben kann.
Was bedeutet Datenisolierung pro Kunde?
Datenisolierung, auch Mandantenfähigkeit genannt, bedeutet, die Informationen der einzelnen Organisationen innerhalb eines gemeinsam genutzten Dienstes logisch voneinander zu trennen. Ein Mandant ist meist ein Unternehmenskunde, doch das Geschäftsmodell kann eine andere Einheit festlegen. Die Anwendung muss jede Anfrage, jeden Prozess und jeden Datensatz einem berechtigten Mandanten zuordnen und diese Zuordnung durchgängig durchsetzen.
Getrennte Speicherung beseitigt nicht automatisch alle Risiken. Eine fehlerhafte Berechtigungsprüfung kann Nutzern Zugriff auf Funktionen eines anderen Kunden ermöglichen. Auch ein exportiertes Protokoll oder ein Analysesystem kann Daten offenlegen, selbst wenn die Hauptdatenbank sauber segmentiert ist. Ebenso müssen Backups, Protokolle, Caches, Dateien, Integrationen und Supportumgebungen berücksichtigt werden.
Die entscheidende Frage lautet deshalb nicht nur, wo Daten gespeichert werden, sondern welche Kontrollen mandantenübergreifenden Zugriff verhindern und wie sich ihre Wirksamkeit überprüfen lässt. Die Speicherarchitektur ist eine Ebene dieser Strategie, kein Ersatz für Authentifizierung, Autorisierung, Codeprüfung oder den sicheren Betrieb.
Drei gängige Speichermodelle
Gemeinsame Datenbank
Alle Kunden verwenden dieselbe Datenbank und häufig auch dieselben Tabellen. Jeder Datensatz enthält eine Mandantenkennung, nach der Abfragen gefiltert werden müssen. Dieses Modell verringert oft den Aufwand für die Bereitstellung und erleichtert es, Schemaänderungen nur einmal anzuwenden. Es eignet sich, wenn das Produkt noch am Anfang steht, die Anforderungen der Kunden ähnlich sind und das Team verlässliche Kontrollen einrichten kann.
Das größte Risiko besteht darin, dass eine Abfrage oder ein Prozess den Filter vergisst. Dadurch könnten Daten eines anderen Kunden gelesen oder geändert werden. Zudem teilen sich die Kunden Ressourcen: Eine hohe Auslastung durch ein Unternehmen kann andere beeinträchtigen, wenn die Kapazität nicht verwaltet wird.
Eigenes Schema pro Kunde
Eine Datenbank enthält mehrere Schemas, jeweils eines pro Kunde, mit ähnlichen Tabellen. Die Trennung kann die Grenze zwischen Datensätzen sichtbarer machen und bestimmte kundenspezifische Vorgänge erleichtern. Sie verhindert jedoch weder Fehler bei der Zuordnung noch garantiert sie eine Trennung der Ressourcen. Migrationen und Werkzeuge müssen alle Schemas einheitlich berücksichtigen. Bei vielen Kunden kann es schwierig werden, Versionen und Ausnahmen zu verwalten.
Dedizierte Datenbank
Jeder Kunde oder eine kleine Kundengruppe erhält eine eigene Datenbank. Das kann die Datenlokalisierung, gezielte Wiederherstellungen und die Erfüllung vertraglicher Anforderungen erleichtern, wenn diese getrennte Ressourcen oder Zugriffsbeschränkungen verlangen. Je nach Bereitstellung der Dienste kann es außerdem die Auswirkungen hoher Auslastung oder eines Vorfalls auf andere Kunden verringern.
Der Nachteil liegt im Betriebsaufwand: Viele Datenbanken bereitzustellen, zu aktualisieren, zu überwachen, zu sichern und zu testen, erfordert Automatisierung und ausreichende Teamkapazität. Eine dedizierte Datenbank schützt auch nicht vor übermäßigen Berechtigungen, kompromittierten Zugangsdaten oder Fehlern in der Anwendung. Es muss geprüft werden, welche Isolierung die gewählte Plattform tatsächlich bietet.
Kriterien für die Entscheidung
Bewerten Sie die Modelle anhand der konkreten Produktanforderungen und nicht anhand einer abstrakten Vorliebe für stärkere Trennung. Dokumentieren Sie sowohl den aktuellen Bedarf als auch die Zusagen, die die weitere Entwicklung voraussichtlich beeinflussen werden.
- Risiko mandantenübergreifenden Zugriffs: Ermitteln Sie, welche Daten sensibel sind, wer darauf zugreift und an welchen Stellen der Mandantenkontext verloren gehen kann. Legen Sie vorbeugende Kontrollen fest und führen Sie negative Tests durch, die Zugriffe auf fremde Daten gezielt versuchen.
- Kundenanforderungen: Prüfen Sie vertragliche Pflichten sowie Anforderungen an Speicherort, Aufbewahrung, Wiederherstellung oder Auditierung. Behandeln Sie den Wunsch nach einer „dedizierten Datenbank“ nicht ohne Prüfung durch die zuständigen Stellen als gesetzliche Pflicht.
- Betrieb: Schätzen Sie den Aufwand für Bereitstellungen, Backups, Wiederherstellungen, Beobachtbarkeit, Support und Störungsmanagement. Berücksichtigen Sie, ob das Team diese Aufgaben zuverlässig automatisieren kann.
- Produktvielfalt: Kunden mit stark unterschiedlichen Versionen, Erweiterungen oder Richtlinien benötigen möglicherweise deutlichere Grenzen. Der Verzicht auf eine gemeinsame Plattform kann jedoch schwer wartbare Abweichungen schaffen.
- Änderungsaufwand: Überlegen Sie, wie ein Kunde umgezogen, die übertragenen Daten geprüft und die Dauer eines Übergangs eingeschätzt werden kann. Eine einfache Anfangsentscheidung ist sicherer, wenn sie künftige Alternativen nicht ausschließt.
Eine Entscheidungsmatrix macht Zielkonflikte sichtbar. Bewerten Sie jede Option anhand überprüfbarer Anforderungen und trennen Sie zwingende Kriterien von wünschenswerten. Wenn ein Kunde eine Bedingung verlangt, die ein gemeinsames Modell nicht erfüllen kann, sollte diese Einschränkung schwerer wiegen als eine allgemeine Präferenz für Einfachheit.
Kontrollen für ein gemeinsames Modell
Wenn Sie eine gemeinsame Datenbank wählen, muss die Mandantenkennung ein zentraler Bestandteil des Designs sein. Sie sollte aus einer vom Server geprüften Identität und einem validierten Kontext stammen und darf nicht einfach als beliebiger Wert aus dem Browser übernommen werden. Die Datenzugriffsschichten müssen diesen Kontext einheitlich erhalten und Abfragen ohne Mandantenbezug verhindern.
Richten Sie, soweit die eingesetzte Technologie es ermöglicht, Kontrollen auf mehreren Ebenen ein: Datenbankbeschränkungen, eingeschränkte Berechtigungen, Zugriffsrichtlinien und Prüfungen in der Anwendung. Diese Maßnahmen sind nicht austauschbar. Prüfen Sie, welche davon in Ihren Prozessen, Verbindungen und administrativen Aufgaben tatsächlich greifen. Übermitteln und validieren Sie den Mandantenkontext bei asynchronen Prozessen, Warteschlangen und geplanten Aufgaben ausdrücklich.
Automatisierte Tests sollten mindestens zwei Mandanten anlegen und Lese- und Schreibvorgänge, Suchfunktionen, Exporte sowie Supportoperationen überprüfen. Ergänzen Sie Prüfungen für neue Abfragen und beobachten Sie Anzeichen wie Autorisierungsfehler, Abfragen ohne Kontext und fehlgeschlagene Aufgaben. Protokolle sollten Untersuchungen von Vorfällen ermöglichen, ohne unnötig sensible Daten offenzulegen.
Wann ein hybrider Ansatz sinnvoll ist
Ein hybrides Modell nutzt für die meisten Kunden eine gemeinsame Datenbank und trennt die Speicherung bei Kunden, für die es einen sachlichen Grund gibt. Das kann sinnvoll sein, wenn nachweisbare Unterschiede bei Anforderungen, Datenvolumen, Speicherort oder Isolierung bestehen. So lässt sich ein gemeinsamer Betrieb einrichten und gezielt dort eine eigene Infrastruktur vorsehen, wo sie einen Mehrwert bietet.
Legen Sie die Regeln für Ausnahmen fest, bevor Sie sie einführen: Welche Anforderung rechtfertigt eine dedizierte Datenbank, wer genehmigt den Wechsel, wie werden die Kosten berechnet und welcher Support wird angeboten? Sorgen Sie für einen gemeinsamen Mechanismus, der den Speicherort jedes Mandanten ermittelt. Die Geschäftslogik sollte nicht von Datenbanknamen oder -adressen abhängen. Ohne klare Kriterien wird ein hybrider Ansatz zu einer Sammlung von Sonderfällen.
Migrationen einplanen und Entscheidungen überprüfbar halten
Trennen Sie von Anfang an die Identität eines Mandanten von seinem physischen Speicherort. Verwenden Sie eine Zugriffsschicht, die Vorgänge an den passenden Speicher weiterleiten kann, und automatisieren Sie Bereitstellung und Migrationen. Halten Sie Schemaänderungen während Übergängen nach Möglichkeit kompatibel und definieren Sie, wie Datensatzanzahlen, Integrität und Berechtigungen geprüft werden, bevor das Zielsystem aktiviert wird.
Für eine Migration kann es nötig sein, Daten zu kopieren, Schreibvorgänge anzuhalten oder Änderungen zu synchronisieren und die Weiterleitung umzustellen. Der Ablauf hängt von der Technologie und den Anforderungen an die Verfügbarkeit ab: Erproben Sie ihn, planen Sie eine Rückfallstrategie und kommunizieren Sie die erwarteten Auswirkungen. Gehen Sie nicht davon aus, dass sich eine dedizierte Datenbank immer einfacher verschieben lässt. Datenvolumen, Abhängigkeiten und Konsistenz bestimmen den Aufwand.
Beantworten Sie vor der endgültigen Entscheidung schriftlich folgende Fragen:
- Welche Einheit stellt einen Mandanten dar, und woher kommt dessen Kontext?
- Welche Anforderungen sind verbindlich und welche verhandelbare Präferenzen?
- Welche Kontrollen erkennen und verhindern Zugriffe zwischen Kunden?
- Wer verantwortet Backups, Wiederherstellungen, Bereitstellungen und Ausnahmen?
- Welche Signale würden einen Modellwechsel rechtfertigen, und wie ließe sich die Migration durchführen?
Wählen Sie das Modell, das die Anforderungen erfüllt und sich mit den verfügbaren Teamressourcen dauerhaft betreiben lässt. Überprüfen Sie die Entscheidung, wenn sich Kunden, Risiken oder Plattformmöglichkeiten ändern. Die passende Isolierung ist nicht die komplexeste, sondern diejenige, deren Kontrollen überprüfbar sind und die sich zuverlässig betreiben lässt.