Quavon Development
SaaS4 Min. Lesezeit

Mandantenfähigkeit ist die Entscheidung, die man am teuersten nachrüstet

Fast jede SaaS-Plattform trifft diese Entscheidung zu spät. Was das später kostet, und wie wir es bei unseren eigenen Produkten gelöst haben.

Leopold LinkMitgründer & EntwicklerVeröffentlicht
Die kurze Antwort

Lege die Mandantentrennung vor der ersten Migration fest und erzwinge sie in der Datenbank, nicht in der Anwendung. Wird sie nachgerüstet, hängt die Trennung an einer Bedingung in jeder einzelnen Abfrage — und eine vergessene Bedingung ist ein Datenleck, kein Bug.

Mandantenfähigkeit heißt: Alle Kunden nutzen dieselbe Anwendung, aber jeder sieht ausschließlich seine eigenen Daten. Das klingt nach einer Anforderung wie jede andere. Es ist die einzige, die man praktisch nicht mehr nachrüsten kann, ohne die Datenbank neu zu schreiben.

Warum es beim Nachrüsten teuer wird

Wer ohne Mandantenkonzept beginnt, filtert irgendwann in der Anwendung. Jede Abfrage bekommt eine zusätzliche Bedingung auf die Organisation. Das funktioniert, solange alle Abfragen daran denken. Bei zweihundert Abfragen denkt eine nicht daran, und dann sieht Kunde A die Daten von Kunde B.

Der Unterschied zu einem gewöhnlichen Fehler ist die Klasse des Schadens. Ein falsch berechneter Rabatt ist ein Ticket. Ein Datenleck zwischen zwei Kunden ist ein meldepflichtiger Vorfall nach DSGVO, ein Vertrauensverlust und je nach Branche ein vertragliches Problem.

Wo die Trennung hingehört

In die Datenbank. Row Level Security in PostgreSQL erzwingt die Trennung dort, wo die Daten liegen: Eine Abfrage ohne gültigen Mandantenkontext liefert keine Zeilen zurück, unabhängig davon, was der Anwendungscode vergessen hat. Die Anwendung darf die Regel dann nicht mehr umgehen, weil sie sie nicht mehr kennt.

  • Mandant als Spalte auf jeder Tabelle, die Kundendaten hält — ohne Ausnahme
  • Row Level Security aktiviert, nicht nur definiert
  • Der Mandantenkontext kommt aus der Sitzung, nie aus einem Parameter der Anfrage
  • Ein Test, der ohne Kontext abfragt und beweist, dass nichts zurückkommt

Was das in der Praxis heißt

Bei Enclessa war Vertraulichkeit die Grundvoraussetzung des Produkts: Direktnachrichten sind Ende-zu-Ende verschlüsselt nach MLS (RFC 9420), gehostet in der EU. Bei TixFin geht es um Veranstalter, die Saalpläne und Zahlungen in Echtzeit teilen, ohne dass zwei Veranstalter je dieselbe Zeile sehen. Beide Produkte haben ihr Mandantenmodell vor der ersten Migration festgelegt, weil wir wussten, dass wir es sonst zweimal bauen.

Jede Entscheidung, die man später ändern kann, darf man später treffen. Die Datentrennung gehört nicht dazu.

Die Gegenprobe

Wenn Sie eine bestehende Plattform übernehmen, ist das die erste Frage: Woran hängt die Trennung? Steht die Antwort in der Anwendung, ist die ehrliche Schätzung für eine Umstellung kein Sprint, sondern eine Migration mit Ausfallfenster. Wir sehen uns deshalb den Code an, bevor wir ein Angebot schreiben.

FAQ

Fragen, die danach kommen

Kurz beantwortet, und jede Antwort so geschrieben, dass sie für sich steht — auch woanders zitiert sagt sie noch etwas Richtiges.

01Was bedeutet Mandantenfähigkeit bei einer SaaS-Anwendung?

Mandantenfähigkeit (englisch multi-tenancy) heißt, dass alle Kunden dieselbe laufende Anwendung und dieselbe Datenbank nutzen, jeder Kunde aber ausschließlich seine eigenen Daten sieht. Ein Mandant ist dabei die Organisation, nicht der einzelne Nutzer: Zehn Mitarbeiter einer Firma teilen sich einen Mandanten, zwei Firmen teilen sich nie einen.

02Warum lässt sich Mandantenfähigkeit nicht nachträglich einbauen?

Weil die Mandantenzugehörigkeit in jeder Tabelle stehen muss, die Kundendaten hält. Nachträglich heißt also: eine Spalte auf jede dieser Tabellen, ein Wert für jede bestehende Zeile, ein neuer Index auf jede Abfrage und eine Bedingung in jeder einzelnen Query. Das ist keine Änderung an einer Stelle, sondern eine Migration über den gesamten Datenbestand.

03Was ist Row Level Security und warum reicht ein Filter in der Anwendung nicht?

Row Level Security ist eine PostgreSQL-Funktion, die pro Tabellenzeile prüft, ob die aktuelle Sitzung sie sehen darf. Ein Filter in der Anwendung wirkt nur in den Abfragen, die daran denken; Row Level Security wirkt in allen, auch in denen, die jemand nächstes Jahr schreibt, und auch bei einem direkten Zugriff über die Konsole.

04Wann ist eine eigene Datenbank pro Mandant sinnvoll?

Wenn ein Kunde eine physische Trennung vertraglich verlangt, wenn einzelne Mandanten so groß sind, dass sie die Last der übrigen verzerren, oder wenn Aufbewahrungsfristen pro Kunde unterschiedlich sind. Der Preis ist Betrieb: Jede Migration läuft dann pro Datenbank, und ein Schemastand, der auseinanderläuft, wird sehr schnell teuer.

05Ist ein Datenleck zwischen zwei Mandanten nach DSGVO meldepflichtig?

In aller Regel ja. Sieht Kunde A personenbezogene Daten von Kunde B, ist das eine Verletzung des Schutzes personenbezogener Daten nach Art. 4 Nr. 12 DSGVO und nach Art. 33 DSGVO binnen 72 Stunden an die Aufsichtsbehörde zu melden, sofern ein Risiko für die Betroffenen nicht auszuschließen ist. Das ist eine rechtliche Einordnung, keine Rechtsberatung.

06Woran erkenne ich, ob eine bestehende Plattform sauber getrennt ist?

An einem Test, nicht an einer Zusage. Setzen Sie eine Abfrage ohne gültigen Mandantenkontext ab: Kommen Zeilen zurück, hängt die Trennung an der Anwendung. Zweite Prüfung: Suchen Sie eine Tabelle mit Kundendaten ohne Mandantenspalte. Findet sich eine, ist die Trennung dort bereits nicht mehr erzwingbar.

Starten wir durch

Sollen wir uns das ansehen?

Erzählen Sie uns, was entstehen soll. Sie bekommen eine ehrliche Einschätzung zu Umfang, Zeitrahmen und Risiken — und eine klare Antwort, ob wir das richtige Team dafür sind.

Antwort in der Regel innerhalb von 24 Stunden