SaaS-Architektur: Mandantenfähigkeit sicher planen

Beispiel: Der erste zahlende SaaS-Kunde will einen Datenexport; der zweite verlangt getrennte Zugriffsrechte und eine andere Lastgrenze. Jetzt zeigt sich, ob die Architektur Kundenidentität, Datenzugriff und Betrieb sauber trennt. Wählen Sie Pool, Silo oder eine Mischform anhand von Datenrisiko, Last, Vertrag und Teamkapazität. Testen Sie vor der Freigabe nicht nur den Login, sondern auch Suche, Export, Hintergrundjobs und Wiederherstellung pro Mandant.

Mandantenmodell nach Risiko wählen

Im Pool-Modell teilen Mandanten Infrastruktur und Datenstrukturen; eine Mandantenkennung begrenzt den Zugriff. Im Silo-Modell sind Ressourcen stärker getrennt. Ein Bridge-Modell kombiniert beides. Die AWS-Dokumentation zu SaaS-Partitionierung beschreibt alle drei als gültige Muster mit unterschiedlichen Betriebs- und Isolationsfolgen.

Fragen Sie vor der Wahl: Müssen einzelne Kunden eigene Schlüssel, Datenregionen oder Wartungsfenster erhalten? Gibt es starke Lastunterschiede? Wie teuer wird eine kundenspezifische Migration? Wie testen Sie, dass ein Fehler niemals Daten eines anderen Mandanten offenlegt? Halten Sie fest, unter welchen Bedingungen Sie später einen Mandanten aus dem Pool auslagern würden.

Datentrennung tatsächlich testen

Bei gemeinsam genutzten Tabellen braucht jede mandantenbezogene Datenzeile eine verlässliche Zuordnung und jede Abfrage eine wirksame Zugriffskontrolle. Nicht jede Tabelle enthält Mandantendaten; globales Konfigurationswissen kann anders modelliert sein. Datenbankseitige Row-Level Security kann eine zusätzliche Schutzschicht bilden, ersetzt aber keine Prüfung von Rollen und Berechtigungen.

Die PostgreSQL-Dokumentation weist darauf hin, dass Superuser, Rollen mit BYPASSRLS und normalerweise Tabellenbesitzer Policies umgehen können. Testen Sie daher mit denselben Rollen, die Ihre Anwendung im Betrieb nutzt. Ein Negativtest sollte zeigen, dass Mandant A weder durch eine vergessene Filterbedingung noch über Export, Hintergrundjob oder Admin-Funktion Daten von B lesen kann.

Hintergrundjobs und Releases absichern

Große Exporte, Abrechnungen und Imports gehören oft in Hintergrundjobs. Übergeben Sie die Mandantenidentität und Berechtigung ausdrücklich an den Worker, begrenzen Sie parallele Last und machen Sie Wiederholungen sicher. Ein fehlgeschlagener Job darf weder fremde Daten bearbeiten noch die Warteschlange anderer Kunden dauerhaft blockieren.

Versionieren Sie Infrastruktur und Anwendung. Prüfen Sie Datenmigrationen zunächst an repräsentativen Mandanten und planen Sie Rücknahme oder Vorwärtskorrektur. Ein API-Gateway kann Authentifizierung und Quoten unterstützen; die Anwendung muss dennoch jede geschäftliche Berechtigung selbst korrekt durchsetzen.

Vier Isolationstests vor dem ersten zahlenden Mandanten

1. Direktzugriff: Ein Nutzer aus Mandant A versucht, die Kennung eines Datensatzes von B abzurufen. Die Antwort darf weder Daten noch Hinweise auf deren Existenz preisgeben.
2. Suche und Export: Filtern, Paginieren, CSV-Export und Hintergrundjobs liefern ausschließlich Daten des berechtigten Mandanten.
3. Rollenwechsel: Ein administrativer Dienst und ein Wartungsskript dürfen ihre erweiterten Rechte nur kontrolliert und protokolliert einsetzen.
4. Fehlerfall: Wenn Mandantenkontext fehlt oder ungültig ist, verweigert die Anwendung die Aktion, statt auf einen Standardmandanten zurückzufallen.

Automatisieren Sie diese Negativtests, weil ein späteres Refactoring dieselbe Sicherheitsgrenze erneut berührt. Prüfen Sie auch Logs, Caches und Objekt-Storage: Eine sichere Datenbankabfrage hilft wenig, wenn ein Export unter einer erratbaren URL liegt.

Ein SaaS-Beispiel ohne erfundene Architektur

Die Aurign-Referenz beschreibt eine Musikverlagsplattform mit Split Sheets und CWR-Prozessen. Sie nennt Funktionen und ein Entwicklungsteam, aber kein Mandantenmodell. Gerade diese Lücke zeigt, welche Fragen eine Architekturentscheidung erst beantworten muss: Wer ist ein Mandant: Verlag, Künstlerteam oder einzelnes Werk? Welche Rollen dürfen Anteile sehen oder ändern? Welche Exporte überschreiten Organisationsgrenzen? Aus der öffentlichen Referenz lässt sich weder Pool noch Silo als tatsächlich eingesetzte Lösung ableiten.

Schreiben Sie vor dem Datenmodell drei Negativtests für Ihre eigene Domäne: Nutzer eines Verlags ruft eine fremde Werk-ID direkt auf; ein Hintergrundexport enthält gemeinsame Mitwirkende mehrerer Verlage; ein Admin wechselt die Organisation während ein Job läuft. Definieren Sie für jeden Fall erlaubte Daten, erwartete Ablehnung und Protokoll. Erst danach entscheiden Sie, welche Teile eine gemeinsame Datenbank sicher tragen kann. Die Hosting-Entscheidung betrifft anschließend Betrieb und Wiederherstellung dieser Grenzen.

Wann die Architektur wachsen muss

Eine gemeinsame Infrastruktur spart anfangs Betriebsaufwand, kann aber laute Nachbarn und unterschiedliche Vertragsanforderungen schwerer abbilden. Definieren Sie einen Migrationsauslöser, etwa dauerhaft ungleiche Last, kundenspezifische Datenhaltung oder getrennte Wartungsfenster. Ein guter Entwurf macht den Wechsel möglich, ohne ihn für alle Kunden schon am ersten Tag zu bezahlen.

Dokumentieren Sie diese Entscheidung als Hypothese mit Messpunkt: „Wir starten im Pool, solange die p95-Latenz der Kernfunktion unter unserer vereinbarten Grenze bleibt und kein Kunde eigene Isolation verlangt.“ Die konkrete Grenze müssen Sie aus dem Produkt ableiten, nicht aus einer generischen SaaS-Vorlage.

Was Sie ab dem ersten Pilot messen sollten

• Antwortzeit und Fehlerrate je Mandant und Kernvorgang.
• Queue-Länge, Jobfehler und Wiederholungen.
• Kosten und Ressourcennutzung pro Mandant oder Tarif.
• Fehlgeschlagene Zugriffsversuche zwischen Mandanten.
• Dauer und Fehlerquote von Releases und Datenmigrationen.

Diese Kennzahlen helfen erst, wenn es Grenzwerte und eine verantwortliche Person gibt. Starten Sie mit wenigen aussagekräftigen Signalen statt einem Dashboard voller Zahlen.

Datenisolation und Lastisolation getrennt entscheiden

Eine Anwendung kann Kundendaten korrekt trennen und trotzdem durch einen einzelnen großen Kunden langsam werden. Prüfen Sie deshalb zwei Grenzen getrennt. Für Daten brauchen Sie Negativtests über API, Suche, Export, Cache und Hintergrundjobs. Für Last brauchen Sie Messwerte je Mandant, sinnvolle Quoten und einen Plan für teure Abfragen oder große Imports. Ein Test, der nur den Login prüft, deckt keine der beiden Grenzen vollständig ab.

Halten Sie für den ersten Pilot fest, welche Ressourcen gemeinsam bleiben und welche bei Bedarf getrennt werden können. Beispiel: Die Webanwendung bleibt gemeinsam, während ein großer Import über eine eigene Queue läuft. Testen Sie, ob Fehler und Wiederholungen in dieser Queue andere Mandanten beeinflussen. Diese Entscheidung muss sich später an Last und Vertrag ändern lassen, ohne die Identität und Berechtigung der Kunden neu zu erfinden.

Häufige Fragen

Kann ein Großkunde später aus einem gemeinsamen Pool ausziehen?

Ja, wenn Daten, Identitäten, Konfiguration und Abhängigkeiten von Beginn an zuordenbar sind. Planen Sie einen Export, eine Übernahme der Berechtigungen und einen Testlauf mit Rückweg. Ohne diese Vorbereitung wird ein späterer Wechsel oft zu einer riskanten Sondermigration, selbst wenn die Anwendung heute eine Mandantenkennung verwendet.

Wie prüfen wir eine Wiederherstellung für nur einen Mandanten?

Testen Sie mit einer Kopie, ob sich Daten und Konfiguration des betroffenen Mandanten in eine sichere Zielumgebung bringen lassen, ohne andere Mandanten offenzulegen oder zurückzusetzen. Dokumentieren Sie Abhängigkeiten, Zeitpunkt und tatsächlich benötigte Dauer. Ein vollständiges Datenbank-Backup allein beantwortet diese Frage bei gemeinsam genutzten Tabellen nicht.

Wann ist eine eigene Datenbank pro Kunde sinnvoll?

Das kann bei vertraglich geforderter Trennung, besonderer Datenregion, stark abweichender Last oder individuellen Wartungsfenstern passen. Rechnen Sie die zusätzlichen Aufgaben für Provisionierung, Updates, Überwachung und Migration mit. Wählen Sie das Modell anhand dokumentierter Anforderungen und Isolationstests, nicht wegen einer pauschalen Sicherheitsbehauptung.

Nächster Schritt

Scorpion Power entwickelt laut Leistungsübersicht SaaS-Plattformen und individuelle Software. Beschreiben Sie uns Ihre Mandanten, Daten und Lastannahmen, wenn Sie ein passendes Modell oder eine bestehende Architektur prüfen möchten.