Wenn mehrere Kunden dieselbe Software-Instanz nutzen, muss ein SaaS-Anbieter eine Grundfrage beantworten: Wie werden die Daten der einzelnen Mandanten voneinander getrennt? Die in der Branche verbreitetste Antwort ist eine gemeinsame Datenbank, in der jede Tabelle eine zusätzliche Spalte wie „tenant_id“ trägt, über die bei jeder Abfrage gefiltert wird. Das funktioniert, hängt aber vollständig davon ab, dass diese Filterung an jeder einzelnen Stelle im Code korrekt implementiert ist. 1Tool geht hier einen strukturell anderen Weg.
Eine eigene Datenbank pro Mandant statt einer gemeinsamen Tabelle
Bei 1Tool erhält jeder Mandant eine eigene, physisch separate Datenbank. Diese wird zur Laufzeit dynamisch verbunden – das System weiß beim Einloggen eines Nutzers, mit welcher Mandanten-Datenbank es sprechen muss, und stellt die Verbindung entsprechend her. Die Trennung findet damit nicht auf Anwendungsebene über eine Filterbedingung statt, sondern bereits auf Infrastrukturebene. Ein Programmierfehler, der bei einer gemeinsamen Datenbank theoretisch dazu führen könnte, dass die Filterbedingung vergessen wird und Daten eines anderen Kunden sichtbar werden, ist bei einer strikten Datenbank-pro-Mandant-Architektur von vornherein ausgeschlossen: Es gibt schlicht keine gemeinsame Tabelle, aus der versehentlich zu viel gelesen werden könnte.
Eigene Server für große Mandanten, eigener Cache für alle
Diese Trennung lässt sich bei Bedarf noch weiterführen. Für besonders große Mandanten kann 1Tool sogar einen komplett eigenen Datenbank-Server hinterlegen – mit eigenem Host und eigenen Zugangsdaten, statt die Datenbank auf derselben gemeinsamen Serverinfrastruktur wie andere Kunden laufen zu lassen. Damit lässt sich die Isolation von der logischen auf die physische Infrastrukturebene ausdehnen, wenn das für einen Kunden aus Sicherheits- oder Performance-Gründen sinnvoll ist. Ergänzend dazu verwaltet 1Tool auch den Cache tenant-spezifisch: Zwischengespeicherte Daten werden ebenfalls pro Mandant getrennt vorgehalten, sodass auch auf dieser Ebene keine Vermischung zwischen Kunden entstehen kann.
Feingranulare Berechtigungen innerhalb des Mandanten
Die Trennung zwischen Mandanten ist dabei nur eine Ebene der Zugriffskontrolle. Innerhalb eines einzelnen Mandanten regelt ein Berechtigungssystem mit Dutzenden spezialisierten Filterregeln – sogenannten Scopes – zusätzlich, welche einzelnen Datensätze ein bestimmter Nutzer überhaupt sehen darf. So lässt sich beispielsweise steuern, dass ein Vertriebsmitarbeiter nur seine eigenen Kontakte sieht, während eine Führungskraft einen vollständigen Überblick erhält – alles innerhalb derselben, bereits mandantenseitig isolierten Datenbank.
Für Unternehmen mit hohen Anforderungen an Datenschutz und Datensicherheit ist diese Kombination ein relevantes Argument bei der Anbieterauswahl. Eine gemeinsame Datenbank mit tenant_id-Spalten ist im Betrieb günstiger zu skalieren, verlangt aber, dass jede einzelne Abfrage im gesamten System korrekt gefiltert wird – über Jahre und über viele Entwicklergenerationen hinweg. Eine echte Datenbank-pro-Mandant-Architektur verschiebt diese Garantie von der Anwendungslogik auf die Infrastruktur selbst.
Häufig gestellte Fragen
Bedeutet eine eigene Datenbank pro Mandant, dass Daten physisch getrennt gespeichert werden?
Ja, jeder Mandant erhält eine eigene, separate Datenbank statt gemeinsam genutzter Tabellen mit einer Mandanten-Kennung als Filterspalte.
Können einzelne Mandanten auf einem komplett eigenen Server betrieben werden?
Für besonders große Mandanten ist das möglich – inklusive eigenem Host und eigenen Zugangsdaten, getrennt von der gemeinsamen Serverinfrastruktur.
Wie wird innerhalb eines Mandanten geregelt, wer welche Datensätze sieht?
Dafür sorgt ein Berechtigungssystem mit zahlreichen spezialisierten Filterregeln, die zusätzlich zur Datenbank-Trennung greifen und den Zugriff auf einzelne Datensätze je Nutzer einschränken.
Wie wichtig ist echte Datenbank-Isolation für die Datenschutz-Anforderungen Ihres Unternehmens?
