Mandantentrennung, die den Security-Fragebogen übersteht

Der Moment ist in SaaS-Teams fast immer derselbe. Das Produkt läuft, die kleineren Kunden sind zufrieden, und dann kommt der erste ernsthafte Enterprise-Interessent — mit einem Security-Fragebogen, in dem eine Frage steht, die vorher niemand gestellt hat: Wie stellen Sie sicher, dass unsere Daten von denen anderer Kunden getrennt sind?

Die ehrliche Antwort lautet in vielen Fällen: durch eine Bedingung im Anwendungscode. Und das ist genau die Antwort, die den Deal ins Wanken bringt.

Warum der Filter nicht reicht

Technisch funktioniert WHERE tenant_id = ? einwandfrei. Als Nachweis funktioniert es nicht, aus einem einfachen Grund: Die Isolation hängt daran, dass jede einzelne Abfrage im System diese Bedingung enthält. Bei fünfzig Abfragen ist das überschaubar. Bei fünfhundert, verteilt über Reports, Hintergrundjobs, Exporte und eine API, ist es eine Frage der Zeit.

Und ein einziger vergessener Filter ist kein Bug, sondern eine Datenschutzverletzung mit Meldepflicht. Der Fragebogen will deshalb nicht wissen, ob Sie sorgfältig arbeiten. Er will wissen, was passiert, wenn jemand einmal nicht sorgfältig war.

Die vier üblichen Modelle

Filter in der Anwendung. Günstig, schnell, überall verbreitet. Die Isolation ist eine Disziplinfrage. Für kleine Kunden akzeptabel, für regulierte Branchen selten.

Row Level Security in der Datenbank. Die Bedingung wandert dorthin, wo sie nicht vergessen werden kann. Ein deutlicher Sprung in der Belegbarkeit, weil die Trennung nicht mehr vom Aufrufer abhängt.

Schema pro Mandant. Klare Grenzen, gut erklärbar, einzeln sicherbar und wiederherstellbar. Der Preis ist Betriebsaufwand: Migrationen laufen n-mal.

Datenbank oder Instanz pro Mandant. Die stärkste Form, meist für wenige große Kunden. Teuer, wenn man sie für alle macht.

In der Praxis gewinnt fast immer das Hybridmodell: viele kleine Mandanten gemeinsam, aber datenbankseitig isoliert, und einzelne große Kunden physisch getrennt. Wichtig ist, dass der Wechsel zwischen beiden Formen keine Neuentwicklung ist, sondern eine Konfigurationsentscheidung. Wer das erst beim zweiten Enterprise-Kunden einbaut, baut zweimal.

Was der Fragebogen wirklich prüft

Hinter den Formulierungen stehen vier Fragen, und keine davon beantwortet ein Architekturdiagramm:

• Kann ein Fehler in der Anwendung Daten anderer Mandanten sichtbar machen?
• Können Sie belegen, wer zu einem bestimmten Zeitpunkt Zugriff hatte?
• Können Sie einen einzelnen Mandanten löschen oder herausgeben, ohne die anderen anzufassen?
• Nutzen Sie unser Identity-System, oder müssen wir Ihnen Benutzerkonten überlassen?

Die letzte Frage wird unterschätzt. Enterprise-Kunden wollen ihre eigenen Konten, ihre eigenen Gruppen, ihre eigene Abschaltung von Zugängen — SSO ist keine Bequemlichkeit, sondern deren Sicherheitsprozess. Deshalb gehören Identität und Mandantentrennung in dieselbe Entscheidung; mit Keycloak lässt sie sich so bauen, dass Sie die Kontrolle behalten, statt sie an einen Anbieter abzugeben.

Berechtigungen brauchen eine Historie

Der Punkt, der in fast jeder Prüfung nachgereicht werden muss: Nicht nur das heutige Rechtemodell zählt, sondern der Stand von damals. Wer hatte vor sechs Monaten Zugriff, wer hat ihn erteilt, wann wurde er entzogen? Wenn Rechte nur als aktueller Zustand gespeichert sind, existiert diese Antwort nicht — dieselbe Lücke wie beim revisionssicheren Logging.

Der pragmatische Weg

Nicht alles auf einmal. Sinnvoll ist die Reihenfolge: Trennung datenbankseitig durchsetzen, damit ein vergessener Filter folgenlos bleibt. Dann Identität sauber anbinden, damit SSO und Rechteentzug beim Kunden liegen. Dann Berechtigungsänderungen historisieren. Danach beantwortet der Fragebogen sich weitgehend von selbst — und der zweite Enterprise-Deal kostet nichts Neues mehr.

Wo Ihr System heute steht, klärt der Nachweisfähigkeits-Check in zehn Fragen. Was daraus im Prüfungsfall wird, steht in der Umsetzungssicht auf NIS2.