Eine fehlende WHERE-Klausel. Mehr braucht es nicht.
Eine einzige Abfrage ohne Mandantenfilter. Mandant A sieht die Kundendaten von Mandant B. Ihr SaaS-Produkt wird zur Schlagzeile.
Mandantenübergreifende Datenlecks sind der schwerwiegendste Fehler in jedem Multi-Mandanten-System. In der EU macht die DSGVO daraus nicht nur ein technisches, sondern ein rechtliches Problem.
Wir haben Multi-Mandanten-Systeme geprüft, deren Datenisolierung auf dem Papier solide aussah. Dann haben wir die Tests durchgeführt. Überall Lücken.
Dieser Beitrag zeigt, wie Sie Mandantendaten wirklich absichern. Für die übergreifende Architektur empfehlen wir unseren kompletten SaaS-Architektur-Leitfaden.
Isolation auf Anwendungsebene
Die meisten Multi-Mandanten-Systeme nutzen gemeinsame Datenbanken mit einer tenant_id-Spalte. Die Anwendung erzwingt die Isolation: Jede Abfrage enthält WHERE tenant_id = ?.
Jeder API-Endpunkt leitet die Mandanten-ID aus dem Auth-Kontext ab. So die Theorie.
Die Gefahr: Ein Entwickler vergisst den Filter. Eine ORM-Fehlkonfiguration überspringt den Scope. Die Daten lecken lautlos.
Automatische Abfrage-Scoping
Verlassen Sie sich nie darauf, dass Entwickler den Mandantenfilter manuell setzen. Bauen Sie ihn in Ihre Datenzugriffsschicht ein.
Ihr ORM oder Repository bindet die Mandanten-ID bei der Konstruktion. Jede Abfrage wird automatisch gefiltert. In Rails funktionieren Default Scopes, in Node/Prisma injiziert Middleware den Filter, in Django erzwingen Custom Managers die Filterung.
Das Muster variiert je nach Stack. Das Prinzip bleibt gleich: Machen Sie ungefilterte Abfragen unmöglich.
Row-Level Security
PostgreSQLs Row-Level Security (RLS) ist Ihre zweite Verteidigungslinie. Selbst wenn die Anwendung eine ungefilterte Abfrage sendet, erzwingt die Datenbank den Filter.
Es gibt einen Performance-Overhead. RLS belastet jede Abfrage zusätzlich. Für die meisten Workloads ist das vernachlässigbar.
Für die wenigen Workloads, bei denen es spürbar wird, rechtfertigt die Sicherheitsgarantie den Aufwand trotzdem.
Isolation auf Datenbankebene
Isolation auf Anwendungsebene hat Grenzen. Für stärkere Garantien verlagern Sie die Isolation in die Datenbank.
Separate Schemas geben jedem Mandanten einen eigenen Namespace. Eine Abfrage im Schema von Mandant A kann physisch nicht auf die Tabellen von Mandant B zugreifen. Keine WHERE-Klausel nötig.
Database-per-Tenant bietet vollständige physische Isolation. Stärkste Isolation, höchste Kosten. Wir behandeln den vollständigen Vergleich in unserem Beitrag zu Multi-Tenancy-Mustern.
Die Wahl hängt von Ihren Compliance-Anforderungen ab. Gesundheitswesen und Finanzbranche brauchen typischerweise Database-per-Tenant. Die meisten B2B-SaaS-Produkte starten mit Shared Schema und RLS.
Verschlüsselung, die wirklich schützt
Verschlüsselung im Ruhezustand und bei der Übertragung ist die Grundlage. Jeder große Cloud-Anbieter aktiviert sie standardmäßig. Das allein reicht nicht.
Mandantenspezifische Verschlüsselungsschlüssel sind der Goldstandard. Die Daten jedes Mandanten werden mit einem eigenen Schlüssel verschlüsselt. Wird ein Schlüssel kompromittiert, ist nur ein Mandant betroffen.
AWS KMS, Azure Key Vault und Google Cloud KMS unterstützen dieses Muster. Speichern Sie die Schlüssel-IDs in Ihrer Mandantenkonfiguration.
Feldbasierte Verschlüsselung
Noch einen Schritt weiter geht die feldbasierte Verschlüsselung. Sensible Felder wie E-Mail, Telefonnummer und Personalausweisnummer werden einzeln verschlüsselt.
Der Rest des Datensatzes bleibt normal abfragbar. Sensible Felder erfordern eine explizite Entschlüsselung.
Ist das mehr Aufwand? Definitiv. Aber wenn ein Auditor fragt “Wie schützen Sie Mandantendaten im Ruhezustand?”, beendet mandantenspezifische Verschlüsselung das Gespräch.
Zugriffskontrollen jenseits von RBAC
Authentifizierung und Autorisierung sind das erste Tor. Unser SaaS-Auth-Leitfaden behandelt SSO, OAuth und RBAC im Detail.
Mandantengebundene API-Schlüssel. Jeder API-Schlüssel ist an genau einen Mandanten gebunden. Ein Schlüssel kann nicht auf die Daten eines anderen Mandanten zugreifen, unabhängig von Berechtigungen.
Audit-Logging. Wer hat was wann von wo aus aufgerufen? Unveränderliche Logs, die nicht manipuliert werden können. DSGVO Artikel 30 verlangt Aufzeichnungen über Verarbeitungstätigkeiten.
Regelmäßige Datenzugriffsprüfungen. Automatisierte Checks, die wöchentlich verifizieren, dass kein mandantenübergreifender Datenzugriff stattgefunden hat. Bei jeder Anomalie sofort alarmieren.
DSGVO-Konformität in Multi-Mandanten-Systemen
Die DSGVO betrifft jedes SaaS-Produkt, das personenbezogene Daten von EU-Bürgern verarbeitet. Unabhängig vom Serverstandort.
Datenspeicherort ist die erste Anforderung. EU-Mandantendaten bleiben in EU-Rechenzentren. Konfigurieren Sie Ihre Infrastruktur so, dass Mandantendaten in die richtige Region geleitet werden.
Recht auf Löschung (Artikel 17)
Wenn ein Mandant die Löschung beantragt, müssen Sie jedes Stück seiner Daten finden und entfernen. Datenbankeinträge, Backups, Logs, Cache, Analytics, Drittanbieter-Integrationen. Alles.
In Shared-Schema-Systemen ist das aufwendig. Sie löschen Zeilen, nicht Datenbanken. Bauen Sie eine Lösch-Pipeline, die jeden Datenspeicher abdeckt.
Datenportabilität (Artikel 20)
Mandanten können ihre Daten in maschinenlesbarem Format anfordern. Bauen Sie eine Export-API. JSON oder CSV.
Automatisieren Sie den Export, damit kein Entwickler manuell eingreifen muss. Bei einer Anfrage pro Monat ist das kein Problem. Bei zehn pro Woche brauchen Sie einen Self-Service-Prozess.
Auftragsverarbeiter-Management
Jeder Dritte, der Mandantendaten berührt, ist ein Auftragsverarbeiter unter der DSGVO. Stripe, Ihr E-Mail-Anbieter, Ihr Analytics-Tool.
Führen Sie ein Verzeichnis aller Auftragsverarbeiter. Stellen Sie sicher, dass jeder einen passenden Auftragsverarbeitungsvertrag (AVV) hat. Prüfen Sie die Liste quartalsweise.
Backups und Disaster Recovery
Backups sind ein Datenisolierungsthema. In Shared-Schema-Systemen enthalten Ihre Backups die Daten aller Mandanten. Eine Wiederherstellung betrifft jeden.
Was passiert, wenn ein Mandant bittet, seine Daten auf letzten Dienstag zurückzusetzen? Sie können nicht die gesamte Datenbank wiederherstellen, ohne alle anderen Mandanten zu beeinflussen.
Für Database-per-Tenant ist das einfach. Eine Datenbank wiederherstellen, fertig. Für Shared Schema brauchen Sie mandantenspezifische Export- und Import-Werkzeuge. Bauen Sie sie, bevor Sie sie brauchen.
Auch Aufbewahrungsfristen sind relevant. Die DSGVO verlangt Löschung auf Anfrage. Wenn Ihre Backups die Daten jahrelang nach der Löschung aufbewahren, sind Sie nicht konform.
Isolation testen
Standardtests finden keine Multi-Mandanten-Bugs. Sie brauchen mandantenspezifische Isolationstests.
Der Basistest: Zwei Mandanten anlegen, Daten als Mandant A erstellen, verifizieren dass Mandant B keinen Zugriff hat. Auf jedem API-Endpunkt durchführen.
Der gründliche Test: Daten als Mandant A anlegen, jede Abfrage im System als Mandant B ausführen. Null mandantenübergreifende Ergebnisse verifizieren. In CI automatisieren.
Was wir aus Lasttests gelernt haben
Ein Kunde entdeckte einen Caching-Bug während Lasttests. Dashboard-Daten von Mandant A wurden aus einem Cache-Eintrag bedient, der die Mandanten-ID nicht im Schlüssel enthielt.
Unter normalen Tests unsichtbar. Unter Last wurde der Bug sichtbar. Die Lektion: Chaostests mit parallelen Mandanten-Workloads sind nicht optional.
Führen Sie schwere Workloads als ein Mandant aus und überwachen Sie dabei andere Mandanten. Jede Performance-Verschlechterung oder Datenleckage aufdecken. Das fängt Noisy-Neighbor-Probleme und Isolationslücken.
Die häufigsten Fehler bei der Datenisolierung
Mandanten-ID nur in der Anwendung prüfen, nicht in der Datenbank. Eine einzige vergessene WHERE-Klausel reicht. RLS auf Datenbankebene ist die Absicherung.
Cache-Schlüssel ohne Mandanten-ID. Der häufigste Fehler, den wir in Audits finden. Wenn Redis-Keys nur den Datennamen enthalten, sieht Mandant B die gecachten Daten von Mandant A.
Logs ohne Mandantenkontext. Wenn ein Datenleck passiert, müssen Sie nachvollziehen können, welcher Mandant betroffen war. Ohne tenant_id in jedem Log-Eintrag ist das unmöglich.
Backups ohne Isolierungskonzept. Ihre Backups enthalten die Daten aller Mandanten. Haben Sie einen Plan, wie Sie die Daten eines einzelnen Mandanten extrahieren, ohne die anderen zu berühren?
Drittanbieter-Integrationen ohne Scoping. Ihr Webhook an Zapier enthält die Mandanten-ID? Ihr Export an ein Analytics-Tool separiert nach Mandant? Prüfen Sie jede externe Schnittstelle.
Unsere Checkliste zur Datenisolierung
Automatisches Query-Scoping auf ORM-Ebene. RLS auf allen mandantenbezogenen Tabellen aktiviert. Mandantenspezifische Verschlüsselungsschlüssel.
Unveränderliche Audit-Logs für jeden Datenzugriff. Lösch-Pipeline für jeden Datenspeicher. Export-API für Datenportabilität.
Mandanten-Isolationstests in CI. Regelmäßige Zugriffsüberprüfungen. Das ist keine optionale Arbeit. Es ist das Fundament, auf dem alles andere steht.
Müssen Sie die Datenisolierung in Ihrem Multi-Mandanten-System verbessern? Lassen Sie uns gemeinsam prüfen. Wir haben Multi-Mandanten-Plattformen für EU-Compliance abgesichert und wissen genau, wo die Lücken stecken.
